instance, A can extract SX¯ = SA¯+ sA¯PX¯ with her secret value sA¯, yielding a short-
term private key matching PX¯ = H1(IDAkIDXkJ_reqkPolicykLTAX), and send hSX¯, sAP0, sA¯P0i to X through a confidential and integrity protected channel. For a
third party to verify if the delegation has taken place, the verifier: (i) authenticates
X3, and (ii) checks if X knows the private key corresponding to P¯
X, through a challenge-response protocol such as the TLS handshake. This method is related to the delegation approach proposed in [41]. We opted for Protocol 3 in our proposal because it works similarly to the delegation protocol deployed in the GSI. Also, transmission of a signed delegation token in Protocol 3 does not require a secure channel that preserves data confidentiality and integrity4. Furthermore, confirming
condition (i) in the alternative approach requires an extra step from the delegator in producing and presenting a signature that proves its authenticity.
4.5
Key Management in IKIG
Here, we look at various aspects of key management including key generation, key update, key revocation and key storage, for our IKIG proposal.
4.5.1 Parameter Generation and TA Initialization
During the initial system setup phase, the TA runs a Bilinear Diffie-Hellman (BDH) parameter generator on input a security parameter k to generate groups G1, G2 of large prime order q and an admissible pairing ˆe : G1× G1 → G2. It then performs the Root Setup of the Gentry-Silverberg HIBE and HIBS schemes to produce a master secret s0 and its system parameters hG1, G2, ˆe, P0, Q0, H1, H2, H3, H4, H5i.
Currently the GT uses 1024-bit RSA public keys in public key certificates and 512 bit keys in proxy certificates. Smaller key sizes are used in proxy certificates mainly because of their frequent use in job submissions and also because of the computa-
3This is needed to convince the verifier that he is indeed interacting with X.
4It is common that delegation from one party to another can be performed after they have established a secure TLS channel. However, in the latest development of the GT4 (see Figure 2.8), credential delegation can be an independent service to a job request. Hence, a delegation technique without the need of a private and integrity protected channel can be seen as an advantage.
4.5 Key Management in IKIG
tionally intensive nature of RSA key pair generation [186]. Since IBC primitives use much smaller key sizes and have efficient key generation algorithms, our proposal has the luxury of using parameters of roughly similar security level to 1024-bit RSA keys for both users’ long-term and short-term credentials. This can be achieved by working with a supersingular elliptic curve of embedding degree 4 over F2271 [75, 77]. This choice results a corresponding group of prime order q approximately equal to 2252. Elements of this group can be represented using 272 bits. Since all arithmetic is carried out in fields of characteristic 2, group operations and pairing computations can be implemented efficiently [12]. In addition to the curve and group selections, we require hash functions for the Gentry-Silverberg HIBE and HIBS schemes. The outputs of H1 and H3 are elements of G1, while H4 gives an output with approxi-
mately log2(q) bits. Note that the size of outputs of H2 and H5 are dependent on
the bit length of plaintexts, n, and in our case, we assume that n = 256, since this is sufficient for our proposed protocol messages (e.g. pre-master secrets and hashed handshake messages). We remark that all these aforementioned parameters of the TA are assumed to be bootstrapped into the grid system.
4.5.2 User Registration
When a new grid user A goes to a nearby RA, the RA performs the following steps:
1. The RA verifies A’s identity by checking her passport (or an acceptable ID- card). Once the check succeeds, the RA compares A’s identity with its global identity list and subsequently assigns her a distinguished string IDA. We propose that the identifier has the form
“/C=UK/O=eScience/OU=RHUL/CN=Alice/Y=2006”, which is based on the syntax from [101].
2. The RA submits A’s application to the TA through its website using the HTTPS protocol (assuming the RA has an authentic and pre-distributed copy of the TA’s system parameters). One way for the TA to authenticate the RA is by using a shared secret, for example, a password. If A’s application is approved, the TA generates A’s long-term private key as SA = s0PA, where
4.5 Key Management in IKIG
PA= H1(IDA) is the matching long-term public key, and sends it back to the RA through the established secure TLS channel. The long-term credential for
A and the TA’s system parameters are distributed to A through a temporary
storage medium such as a pen drive.
3. A performs the Lower-level Setup algorithm of the Gentry-Silverberg
HIBE (or HIBS) scheme, picking a random sA∈ Z∗q which she will keep secret. She then defines her Q-values as hQ0 = s0P0, QA= sAP0i.
The user’s client must create a proxy credential every time the user “signs on” to the grid system. In IKIG, this is done as follows:
1. A runs the Extract algorithm of the Gentry-Silverberg HIBE (or HIBS)
scheme to generate a short-term private key SA¯ = SA+ sAPA¯, where PA¯ = H1(IDAkLTA) is the corresponding short-term public key.
2. She also performs the Lower-level Setup algorithm of the Gentry-Silverberg HIBE (or HIBS) scheme, picking a random sA¯ ∈ Z∗q which will be kept secret.
The Q-values for A’s proxy are hQ0 = s0P0, QA = sAP0, QA¯ = sA¯P0i. Note
that A’s TA does not know SA¯ and sA¯, and thus key escrow is limited, unless
the TA behaves maliciously in mounting an active attack to impersonate the user to other entities.
As described in Section 4.4.1, A’s short-term private key is stored temporarily in a local file system in unencrypted form. Only then is A ready and allowed to submit job requests.
It is worth noting that long-term keys used by hosting resources can be obtained using the above manner by the resource owners.
We have now explained how the long-term and short-term keys discussed in Table 4.2 are derived and used in our IKIG setting.
4.5 Key Management in IKIG
4.5.3 Key Update
A’s long-term public key is fixed as PA= H1(IDA), where the associated long-term private key is s0PA, and s0 is the master secret of the TA. In a grid environment,
it is normal practice to renew the user’s long-term keys on a yearly basis. In our proposal, this can be done through the TA issuing a new private key s0PA0 directly
to the user through a secure channel which can be established via Protocol 1. For example, A’s identifier can be updated by updating the year field as follows:
IDA0 = “/C=UK/O=eScience/OU=RHUL/CN=Alice/Y=2007”.
This is a more proactive approach as compared to current practice in PKI because the TA can easily compute the user’s new long-term public key without requesting a new public key from the user. However, we have to enforce a policy whereby, in the event of compromise of the user’s current private key right before the issuance of a new private key, the user must, upon her discovery of the incident, contact her RA in person to obtain a new private key.
The user creates a new short-term public/private key pair every time she signs on to the system. As with the current GSI setting, we assume the default lifetime for these keys is 12 hours. These short-term keys are used for various security services such as mutual authentication, single sign-on and delegation. Upon expiry of the proxy credential, these keys will be deleted from the local file system where they are temporarily stored. Should the validity of the proxy credential need to be extended, the user needs to be notified before the credential expires so that it can be renewed by the user. This may occur, for example, when a job execution takes longer than 12 hours and this event is not foreseen by the user concerned.
4.5.4 Key Revocation
For key revocation in the GSI, the user is expected to periodically check either a certificate revocation list (CRL) stored in a trusted directory or the CA’s web site, depending on the policy enforced by their local administrator. It is recommended that the user updates their local copies of CRLs at least once a day [8]. However, many users do not bother doing this in reality. This may not cause serious concern
4.5 Key Management in IKIG
as the CA can always instruct the user’s entry in a grid Gatekeeper’s (or a Resource Broker’s) grid-map file to be removed when the CA is notified about key compromise of the user. At the time of writing, the GSI still does not support online certificate status protocol (OCSP) [82].
In the IBC setting, a number of revocation mechanisms are possible. We could use a more fine-grained identifier [25]. For example, we could extend the user’s identifier to include another field which specifies a month, such as:
“/C=UK/O=eScience/OU=RHUL/CN=Alice/Y=2006/M=January”.
This allows automated expiry of public keys after one month (hence the window of exposure is also limited to a month). The granularity of the user identifier must not be so complex that it loses its predictability. In grid environments, only short-term keys are used to encrypt or sign data (recall in Section 2.2.2, we explained that one of the motivations for using proxy credentials in grid environments is to limit the exposure of long-term private keys). Hence, the above suggested granularity may be adequate for most applications. However, should this approach prove in- sufficient, e.g. in some grid applications requiring high security, then existing PKI revocation mechanisms such as CRLs and OCSP can be adapted to the IBC set- ting. See [144] for a longer discussion of key revocation in identity-based PKI and traditional certificated-based PKI.
Revocation of short-term keys is a minor concern here as these keys will be destroyed upon expiry of their validity periods. Again though, this might not be sufficiently quickly in high security applications. In any case, the current GSI revocation ap- proach would also need to be improved to handle this.
4.5.5 Integrating with MyProxy
MyProxy [15, 137], which we have discussed in Section 2.4, is gaining in popular- ity and is widely used in real grid applications. Being web-based, it serves as an online credential storage system that enables users’ long-term private keys to be ac- cessed from anywhere through the Internet with users being authenticated through a password-based mechanism. We envisage that this kind of service could be equally