useful in our IKIG approach. We show how IKIG functionality can be exploited to support MyProxy.
As in the current MyProxy architecture, we assume that users’ long-term private keys are stored at the MyProxy server in an encrypted form, the encryption keys being derived from passwords shared between users and the MyProxy server. The user must first establish a secure channel with her MyProxy server through a server- authenticated TLS protocol. Then she would submit a proxy request which includes her identity, her password, and the desired lifetime of the proxy credential to the MyProxy over the secure channel. Unlike the current GSI and MyProxy approach (which requires new RSA short-term public/private key pair generation on the user side), in the IKIG setting, the MyProxy server can determine the user’s new short- term public key PA¯ = H1(IDAkLTA) directly from the user’s identifier and the indicated lifetime. If the MyProxy server is able to successfully decrypt the user’s encrypted long-term private key sA using the password, then it extracts the short- term private key SA¯= s0PA+ sAPA¯ associated with PA¯. The MyProxy server then
forwards the proxy credential (PA¯, SA¯) back to the user through the secure channel.
It is worth noting that the MyProxy server in such a setting is, in fact, providing a distribution service for private keys to its users roughly equivalent to private key distribution from a TA to its users in a typical identity-based cryptosystem. We remark that the design of MyProxy allows escrow of the user’s private key in the original GSI setting. A malicious administrator of the MyProxy server can always intercept the user’s valid password and later impersonate the user to other grid entities. Therefore, users must trust the MyProxy server to behave honestly. This places GSI operating with the MyProxy plug-in on roughly an equal footing with IKIG in terms of key escrow. We also note that, independent of the MyProxy protocol, the combined use of user passwords and the TLS protocol may have other security implications. We return to this issue in Chapter 6.
4.6
Security Analysis
One of the main objectives of designing a secure infrastructure for grid applications is to overcome security threats caused by malicious behavior of adversaries (who
4.6 Security Analysis
could be legitimate users or outsiders). By exploiting weaknesses that may be in- herited or overlooked in the design of the infrastructure, the adversary aims to gain unauthorized access to grid resources, modify sensitive records or files, steal valu- able or classified data and so on. When billing comes into place for commercial grid applications, the adversary will have even more incentive to attempt to get free use of grid resources. The adversary may realise his goals in causing security breaches, for example, by trying to:
• impersonate a legitimate user to a MyProxy server using guessed passwords in order to retrieve a valid proxy credential from the server;
• forge a signature and masquerade as a genuine job requestor in order to get access to a resource;
• re-use previously negotiated session keys for continued access to a resource; or
• break into a resource hosting server and modify the grid-map file residing in the server.
In this section, we informally analyse the security of the authenticated key agreement and delegation protocols (Protocols 1 and 3, respectively). The scope of the analysis is limited to our protocols since these form the core components of IKIG. In our analysis, we assume that the adversary is able to eavesdrop and manipulate, insert, re-route, and/or delete messages. The TA, however, is assumed to be curious but honest. This means the TA can intercept messages sent by its users but does not actively impersonate the users to other parties.
4.6.1 Mutual Authentication and Key Agreement
The security of the TLS protocol and its predecessor, SSL, have been well-studied. Results, for example in [110, 145, 184], show that the TLS (and SSL) protocol is adequately secure, providing it is implemented carefully. Otherwise, it could be vulnerable to various side channel attacks [38, 179]. In Protocol 1, we replaced certificates with identifiers. Here, we will discuss if the changes impact on the security of the TLS protocol.
4.6 Security Analysis
In step (2) of Protocol 1, we have removed the Certificate message that the server must send to the client in the original TLS specification. It has been replaced with ServerIdentifier which contains IDX and LTX. Also, the Certificate message in step (3) which is supposed to contain the client’s certificates has become ClientIdentifier, containing IDX and LTX. Entities A and X do not have to verify the validity of the respective identifier that they each received. Since we assume that the TA has carried out its responsibility appropriately, A and X can each trust that the exchanged identifier came from the genuine party if this party can prove possession of the associated private component. Thus, if X can successfully verify the signed handshake messages from A using a public key constructed from A’s identifier, then A is authenticated to X. On the other hand, for A to authenticate
X, she must receive the correct verification value in ServerFinished from X, which
was calculated based on the pre-master secret that she has chosen. This confirms that the server has recovered the correct pre-master secret that she sent encrypted under the public key that should belong to the server. Should the adversary attempt to impersonate either the user or the server, he must obtain their respective private keys or break the Gentry-Silverberg HIBE/HIBS schemes.
We conclude that the replacement of certificates with identifiers has not weakened the security protection that the original TLS protocol offers.
4.6.2 Delegation
We saw in Section 2.2.2 that delegation in the PKI approach requires the delegation target to transport a fresh public key to the delegator. We remark that this must be carried out using an authenticated and integrity protected channel. This can be established through, for example, the TLS protocol. The failure to do so allows a simple man-in-the-middle-attack. Let A be the delegator, X be the delegation target and E be the adversary. The attack can be illustrated as follows:
(1). X → E : P KX¯, SigX¯(proxy_request)
(2). E → A : P KX¯0, SigX¯0(proxy_request)