TSG-SA WG3 (Security) meeting #4	TSGS-WG3#4(99)164
London, 16-18 June 1999	

Agenda Item:	

Source:	Vodafone

Title:	Key management for network wide encryption

Document for:	Information

___________________________________________________________________________

1.	Introduction
The purpose of this document is to provide some preliminary comments on a proposal for a key management scheme to support end-to-end security, as specified in Section 9.2.3 of [1].
2.	Brief description of proposal
2.1	The scheme
The scheme is intended to enable two UEs (User Equipments) on the same serving network to establish a shared secret key for use in ‘end to end’ encryption.  In fact there is nothing special about the key, and it could also be used for end-to-end integrity and origin authentication services.
It is also assumed that the UEs share an ‘access link cipher key’ with their VLR (and also with their RNC).  The establishment of this access link key is assumed to be an automatic by-product of the UE/VLR authentication process, and hence is available ‘for free’.
To establish a shared secret, the VLRs of the two UEs simply exchange the two UEs’ access link cipher keys.  That is, if UEa has VLRa and access link cipher key Ka, and UEb has VLRb and access link cipher key Kb, then VLRa passes Ka to VLRb, and vice versa.  The two VLRs then send the newly acquired keys to the respective UEs, i.e. VLRa sends Kb to UEa, and VLRb sends Ka to UEb.  Finally, both UEs compute the shared secret key as Ks = f(Ka, Kb).
2.2	Motivation
As mentioned above, the main motivation for using the access link cipher keys to establish the shared secret key is that these keys are present in any case (they are assumed to be an automatic by-product of the authentication process) and hence they are available for use ‘for free’.
One other motivation for the scheme is that both VLRs retain the capability to compute the session key Ks, which is desirable for key recovery purposes.
3.	Some comments on the proposal
3.1	Efficiency
Despite the fact that the keys Ka and Kb already exist, they have to be exchanged by the two VLRs.  This means that at least two messages have to be exchanged between VLRs to establish each session key, and so it hardly fair to claim that the process is ‘free’.  Indeed, as we discuss below, there are plenty of key establishment schemes with the same or even smaller overhead, which accomplish the same purpose.
3.2	Security properties
The design of the scheme means that VLRb, RNCb and UEb all have access to UEa’s access link cipher key Ka.  This may be highly undesirable if this key is used to protect sensitive data transferred to and from UEa.
4.	Alternative schemes
We now consider two alternative ways in which the desired session key can be established.  This is by no means an exhaustive list.
4.1	A Diffie-Hellman solution
i)	Preliminaries
We assume that there is a globally agreed modulus p, and also a globally agreed ‘base’ g (g will typically be an element of large prime multiplicative order modulo p).  All exponentiations are to be computed modulo p.
ii)	Protocol description
As in the previous solution, UEa and UEb establish a shared secret key using their respective access link secret keys Ka and Kb.  The scheme is very similar to the scheme in Section 9.2.3 of [1].
The main differences are as follows.  Instead of exchanging Ka and Kb, VLRa and VLRb exchange gKa and gKb.  This exchange does not need to preserve secrecy (as was the case in the previous scheme), although it does need to preserve data integrity.  Thus VLRb does not learn the secret key Ka, and VLRa does not learn the secret key Kb.  VLRa then forwards gKb to UEa, and VLRb forwards gKa to UEb.
UEa can now compute
Ks = (gKb)Ka = gKaKb.
Similarly, UEb can compute
Ks = (gKa)Kb = gKaKb.
iii)	Comments on the scheme
As already remarked, this scheme avoids the need for UEa and UEb to exchange keys Ka and Kb.  However, the possibilities for key recovery remain undiminished.  Thus it preserves the ‘best’ properties of the previous scheme, and avoids the main disadvantages.
4.2	A solution using conventional cryptography
i)	Preliminaries
The second alternative solution we consider is taken from a recent paper by Hoyle and Mitchell [2].  This scheme has the advantage that it avoids any need for on-line communications between VLRa and VLRb.  As previously, we assume that UEa and VLRa share a secret key Ka, and UEb and VLRb share the secret key Kb. Note that, as in [2], the described protocol does not provide entity authentication; this can be added by incorporating appropriate time variant parameters into the protocol.  To use this scheme it is necessary that VLRa and VLRb share a long term secret key K(VLRa, VLRb).
ii)	Protocol description
The description is an adapted version of the text appearing in Section 4.1 of [2].
1.	UEa sends VLRa a request for a key for communicating with UEb (and an indication of the identity of the VLR of UEb):
UEa  VLRa:  UEb, VLRb
2.	VLRa responds by sending UEa a pair of tokens.  Each contains a copy of the required session key Ks, one encrypted so that only UEa can read it and the other so that only UEb can read it.  The encryptions are performed using keys K*a and K*b.  VLRa also sends K*a to UEa, encrypted under Ka.
VLRa  UEa:  eKa(K*a), eK*a(Ks, IDUEa, IDUEb), eK*b(Ks, IDUEa, IDUEb)
where eK(X) denotes encryption of data X using key K, K*a = f(K(VLRa, VLRb), IDUEa), and K*b = f(K(VLRa, VLRb), IDUEb).
UEa first obtains the key K*a, and then decrypts the first token to obtain the session key Ks.
3.	When UEa wishes to commence secure communications with UEb, UEa protects the transmitted data using the session key Ks, and at the first opportunity sends both tokens to UEb:
UEa  UEb:  eK*a(Ks, IDUEa, IDUEb), eK*b(Ks, IDUEa, IDUEb)
4.	When UEb receives the tokens, there are two possible cases to consider (we assume that UEb knows which VLR UEa is using).  If UEb already knows K*b (which is a function only of the identity of VLRa), then the protocol is complete.  If UEb does not know K*b, then UEb sends a message to VLRb requesting a copy:
UEb  VLRb:  VLRa
5.	VLRa now computes K*b, using the function f and the shared secret key K(VLRa, VLRb), and sends it back to UEb:
VLRb  UEb:  eKb(K*b)
UEb can now recover Ks.
Both VLRs now possess all they need to perform key recovery, should they be required to do so (for further details see [2]).
iii)	Comments on the scheme
As already remarked, this scheme avoids any need for communication between VLRs.  It also avoids the need for UEb to obtain the key from VLRb (except on the first occasion that a key is received from a client of VLRa).  Perhaps most importantly, it avoids the need for UEa and UEb to exchange keys Ka and Kb, and at the same time also avoids the use of any computationally expensive public key cryptography.
5.	Concluding remarks
The key management scheme proposed in Section 9.2.3 of [1] has been briefly reviewed.  Two alternatives to the scheme have been described, which offer certain advantages.  Only when the exact requirements for the scheme are specified will it be possible to properly evaluate which solution is the most appropriate.
6.	References
[1]  3GPP – TR S3.03, 3G Security: Architecture.  V0.2.2, 1999-04.
[2]  M.P. Hoyle and C.J. Mitchell, ‘On solutions to the key escrow problem’.  In B. Preneel and V. Rijmen (eds.), COSIC ‘’97 Course, Springer-Verlag LNCS 1528 (1998) 307-331.