Alec Brusilovsky

October 26, 2007

Cellular Wireless Key Managament

Alec BrusilovskyWireless Architecture and Standards Development, Secure Communications

Wednesday, March 18, 2009

2

Cellular Wireless Key Management

AGENDA• Some GSM/UMTS security and history (if needed, see outtakes)

• Layered Security Approach in eUTRAN

• Reuse of UMTS AKA for authentication

– Security context/key derivation in eUTRAN is based on UMTS AKA

– AKA run and key change/derivation

• Key refresh

– On intra-MME HO

– On inter-MME HO

• What is wrong with that?

– Poisoned key chain…

– Inband key material transfer…

• How do we fix that?

– Key material transfer out of band

• 3 solutions


3


ePS - Non-Roaming Reference Architecture

SGiSGiSGiSGiPCRFPCRFPCRFPCRFS7S7S7S7S6aS6aS6aS6a HSSHSSHSSHSS

ePDGePDGePDGePDGS2bS2bS2bS2bServing SAE Serving SAE Serving SAE Serving SAE GatewayGatewayGatewayGatewayWnWnWnWn**** 3GPP AAA 3GPP AAA 3GPP AAA 3GPP AAA ServerServerServerServer

OperatorOperatorOperatorOperator’’’’s IP Services s IP Services s IP Services s IP Services (e.g. IMS, PSS etc.)(e.g. IMS, PSS etc.)(e.g. IMS, PSS etc.)(e.g. IMS, PSS etc.)Wm*Wm*Wm*Wm*

WxWxWxWx****

UntrustedUntrustedUntrustedUntrustedNonNonNonNon----3GPP IP Access3GPP IP Access3GPP IP Access3GPP IP AccessTrustedTrustedTrustedTrustedNonNonNonNon----3GPP IP Access3GPP IP Access3GPP IP Access3GPP IP Access WaWaWaWa**** Ta*Ta*Ta*Ta*HPLMNHPLMNHPLMNHPLMNNonNonNonNon----3GPP 3GPP 3GPP 3GPP Networks Networks Networks Networks

S1S1S1S1----UUUUS1S1S1S1----MMEMMEMMEMMEEUTRANEUTRANEUTRANEUTRAN2G/3G 2G/3G 2G/3G 2G/3G SGSNSGSNSGSNSGSN S4S4S4S4S3S3S3S3

S5S5S5S5 S6cS6cS6cS6cRx+Rx+Rx+Rx+

S2aS2aS2aS2aPDN SAE PDN SAE PDN SAE PDN SAE GatewayGatewayGatewayGatewayMMEMMEMMEMME S11S11S11S11S10S10S10S10

UEUEUEUES2cS2cS2cS2c

Trusted/Trusted/Trusted/Trusted/UntrustedUntrustedUntrustedUntrusted****NonNonNonNon----3GPP IP Access 3GPP IP Access 3GPP IP Access 3GPP IP Access or 3GPP Accessor 3GPP Accessor 3GPP Accessor 3GPP Access


4


Security Layers in eUTRAN

UE

eNB

eNB

Xu

Xu

MMES 1 - C

S 1 - CX 2

Evolved Packet Core

( EPC )

E -UTRAN

SAE GW

S 1 -U

S 1 -U

Security layer 1 Security layer 2

Security layer 1

ePS has two layers of protection instead of one layer perimeter security like in UMTS. First

layer is the Evolved UTRAN (eUTRAN) network (RRC security and UP protection) and

second layer is the Evolved Packet Core (ePC) network (NAS signalling security).


5


AKA run and key change/derivation

USIM / AuC

UE / MME

UE / ASME

KASME

K

CK, IK

KeNB-UP-enc KeNB-RRC- int

KeNBKNAS int

UE / HSS

UE / eNB

KNAS enc

KeNB-RRC-enc

K_ASME is

derived

from

CK&IK.

It never

leaves the

EPC

Result of

the AKA

run

K_eNB key is

transported to the

eNB from the EPC

when the UE

transitions to

LTE_ACTIVE

eNB derives the

UP and RRC

keys from

K_eNB

UE/ASME

When the UE goes into LTE_IDLE or LTE_DETACHED, the K_eNB, UP and RRC keys are

deleted from the eNB.

* An Access Security Management Entity (ASME) is an entity which receives the top-level

keys in an access network from the HSS. Kasme is bound to the serving network.


6


Key refresh on Intra-MME handover

HO decision

2. HO request, KeNB*

3. HO response (C-RNTI)

4. HO command (C-RNTI)

1. Derive KeNB* from KeNB.2. Derive new KeNB from KeNB* and C-RNTI. 3. Derive RRC/UP keys from new KeNB

5. HO confirm

6. HO complete7. UE location update

UE Source eNB Target eNB EPC

1. Measurement report

2. Derive new KeNB from KeNB*, and C-RNTI3. Derive RRC/UP keys from new KeNB

1. Derive KeNB* from KeNB

On intra MME handover the source eNB sends a handover request to the target eNB.

The target eNB replies with a handover response.

The handover response includes information required by UE (e.g., the C-RNTI).

The source eNB includes this information in the handover command it sends to UE.

* C-RNTI – Cell Radio Network Temporary Identity


7


Key refresh on Inter-MME handover

On inter-MME handover as on intra-MME handover, the fresh KeNB* is transferred to

the target eNB. A new KeNB is derived from the KeNB* and C-RNTI,

and K-RRCenc, K-RRCint, K-UPenc are refreshed with the help of this new KeNB.

HO decision



7. HO command (C-RNTI)

8. HO confirm

9. HO complete

UE Source eNB Target eNB Source MME Target MME

3. HO request, KeNB*, NAS

keys, K-ASME, COUNT,




1. Derive KeNB* from KeNB.

2. Derive new KeNB from KeNB* and C-RNTI. 3. Derive RRC/UP keys from new KeNB

2. Derive new KeNB from KeNB*, and C-RNTI

3. Derive RRC/UP keys from new KeNB

1. Derive KeNB* from KeNB


8


What is wrong with that?

•Poisoned key chain…

•Inband key material transfer…

•Key material is transferred inband;

•Key material for the key in the Step N+1 is available using the key from the Step N;

•The adversary needs to physically break into the first node to obtain the Key#1;

•All of the subsequent nodes will be transparent to the adversary without physical breaking in;

Solution: transferSolution: transfer keykey material out of bandmaterial out of band

Two requirements for the key secrecy:•Forward key secrecy – future transactions shall not be compromised with the present key;•Backward key secrecy – past transactions shall not be compromised with the present key;


9


Alternative 1 – forward secrecy from the Step 1

6a.HO decision

7. HO request ({KeNBTarget eNB_ID}MME-eNB_key[Target eNB_ID] )

8. HO response 9. HO command (Target eNB_ID)

10. HO confirm

11. HO complete

12. UE location update (List of potential target (i.e. neighbour) eNB)

UE Source eNB Target eNB MME


9A. Derive KeNB[ BS_ID ] = AESH_KEY(BS_ID),9B. Derive RRC/UP keys from the newKeNB 8A. Derive RRC/UP keys from the new KeNB that was derived earlier from MME.

Handover

Prior to handover

5. Forwards H_key, protected by NAS security

3A. Pick a random H_key; and3B. KeNBeNB_ID = AESH_KEY(eNB_ID), 3C. Encrypt KeNBBS_ID with respective MME-eNB_key = {KeNBBS_ID}MME-eNB_key[BS_ID].3.UE location update (List of potential target (i.e. neighbour) eNB)

4. List of {KeNBeNB_ID}MME-eNB_key[eNB_ID] for each potential target eNB.)7A. Recover KeNBBS_ID – decrypt using MME-eNB_key[BS_ID]

13. {KeNBBS_ID}MME-eNB_key[BS_ID] for each potential target eNB.)

2.Forward MME-eNB_key Initial SA

Establishment1. Pick a random MME-eNB_key


10



5. HO request (H_nonce, KeNB*)

6. HO response

8. HO confirm

9. HO complete

10. UE location update

UE Source eNB Target eNB MME


7A. Derive new KeNB from KeNB*, H_nonce, Target eNB_ID7B. Derive RRC/UP keys from the new KeNB

6A Derive new KeNB from KeNB*, H_nonce, Target eNB_ID6B. Derive RRC/UP keys from the new KeNB H

andover

Prior to handover

3. Forwards H_nonce, protected by NAS security

1. Pick a random H_nonce4A. HO decision

4B. Derive KeNB* from KeNB

7. HO command (Target eNB_ID)

2. Forwards H_nonce

Intra-MME


11



Inter-MME

5. HO request (H_nonce, KeNB*)

9. HO response (eNB_ID)

11. HO confirm

12. HO complete

UE Source eNB Target eNB Source MME


10A. Derive new KeNB from KeNB*, H_nonce, Target eNB_ID10B. Derive RRC/UP keys from the new KeNB

7A Derive new KeNB from KeNB*, H_nonce, Target eNB_ID7B. Derive RRC/UP keys from the new KeNB H

andover

3. Forwards H_nonce, protected by NAS security

1. Pick a random H_nonce4A. HO decision

4B. Derive KeNB* from KeNB

10. HO command (Target eNB_ID)

Target MME

6. HO request (H_nonce, KeNB*,

NAS keys, KASME, COUNT)7. HO request (H_nonce, KeNB*)

6. HO response (Target eNB_ID)

2. Forwards H_nonce


12


What did all of this teach us?

•Key derivation and forward/backward protection - key management includes all of the above;

•Complexity of the key management solution has to be adequate to the threats;

•Using out-of-band channels for the part of key material might be part of the solution;


13


Outtakes –GSM/UMTS

security/history


14


Security design challenges

Sometimes conflicting requirements…• Need to build something new and preserve the legacy at the same time;

• Need to cut corners to comply with the RF link budget, but to create something secure enough for the next 20 years;

• Need to compete with other 3.9-4G technologies (WiMax, UMB, etc.) in terms of features and delivery time;

• Panic fear of the “NYT attack”;

• Different geo-political understanding of security, privacy, etc. needs – competing requirements;

Controversy equalizes fools and wise men - and the fools know it.Oliver Wendell Holmes, 1809-1894


15


Before we start – little terminology

• LTE

• SAE

• SAE/LTE

eUTRAN – Enhanced UTRAN

ePC – Enhanced Packet Core

ePS – Enhanced Packet System

LTE (Long Term Evolution) became eUTRAN;SAE (System Architecture Evolution) became ePC;Together SAE/LTE became ePS;LTE and SAE are retained as purely 3GPP project names.

Are you insinuating that I am a purveyor of terminological inexactitudes?- Winston Churchill, responding to a journalist


16


Cellular Wireless access technologies

• Analog (AMPS) – supported till 2008, will be phased out after that

• TDMA – phased out to give spectrum to GSM/UMTS

• 3GPP2 side– CDMA-1, CDMA-2000-1XRTT, EVDO, EVDV

• 3GPP side– GSM, EDGE, GPRS, UMTS, LTE


17


Security in GSM

• Functions:

• Authentication – yes (GSM AKA)

• Integrity – no

• Confidentiality – yes

• Privacy – yes (Temporary Identity –TMSI)Security association is between mobile and HLR (shared root key Ki), AKA is executed between mobile and VLR and HLRCiphering Key is stored at the Base Station (BTS)


18


GSM AKA

HLR – Home location RegisterIMSI – International Mobile Subscriber IdentityMS – Mobile stationRAND – Random challenge

RES – Response to an authentication challengeVLR – Visited Location RegisterXRES – eXpected Response

MS VLR HLR

Register

IMSI Request for “triplets”

“triplets”

(RAND, XRES, Kc)

RAND

RES

Compute “triplets”

Validate RES = XRES

Compute RES and Kc

XRES = A3(RAND, Ki)Kc = A8(RAND, Ki)

RES = A3(RAND, Ki)Kc = A8(RAND, Ki)


19


GSM Security weaknesses

• Algorithmic deficiencies– The initially recommended A3 algorithm, Comp128, was broken soon after its creation. Its substitute, Comp128-2, is kept in secrecy. It is believed to be broken as well.

– The A5 confidentiality algorithm was created in multiple incarnations: “strong” A5/1, and “weak” A5/2. A5/1 is broken already. A5/3 is relatively new and is recommended

• Protocol deficiencies– GSM AKA leads to reuse of authentication triplets


20


Security in UMTS

• Functions:

• Authentication – yes (UMTS AKA)

• Integrity – yes (IK from AKA)

• Confidentiality – yes

• Privacy – yes (Temporary Identity –TMSI)


21


UMTS security is based on GSM security

• The improvements are:

• A change was made to defeat the false base station attack. The security mechanisms include a sequence numberthat ensures that the mobile can identify the network.

• Key lengths were increased significantly to allow for the utilization of stronger algorithms for encryption and integrity.

• Mechanisms were included to support security within and between networks.

• Security associations are terminated at the RNC rather than the base station as in GSM. Therefore the links between the base station and the RNC are protected .

• Integrity mechanisms for the terminal identity (IMEI) have been designed in from the start, rather than that introduced late into GSM.

And designed to be backwards compatible…


22


Authentication & Key Agreement (UMTS AKA) Protocol Objectives

• Authenticate user to network & network to user (mutual

authentication)

• Establish a cipher key CK (128 bit) and an integrity key IK (128

bit)

• Assure user and network that CK/IK have not been used before

(replay attack)

• Authenticated management field HE → USIM

– authentication key and algorithm identifiers

– limit CK/IK usage before USIM triggers a new AKA


23


UMTS AKA

AuC – Authentication CenterAUTH – Authentication vector (quintuplet)AUTN – Authentication TokenCK – Ciphering KeyHLR – Home location RegisterIK – Integrity Key

IMSI – International Mobile Subscriber IdentityMS – Mobile stationRAND – Random challengeRES – Response to an authentication challengeVLR – Visited Location RegisterXRES – eXpected Response

MS VLR HLR/AuC

Register

Authentication

Auth. Vectors

RES, IK, CK

Compute “quintuplets”

Validate RES = XRESSelect CK, IK

1. Check if SQN is in the

range2. Compute RES, CK, IK

USIM

data request

RAND, AUTNRAND, AUTN

RES

IMSI


24


UMTS AKA Prerequisites

• Authentication Center (AuC) and USIM share:– user specific secret key K (128 bit key)– message authentication functions f1, f1*, f2– key generating functions f3, f4, f5

• AuC has a random number generator

• AuC has scheme to generate fresh sequence numbers

• USIM has a scheme to verify freshness of received sequence numbers


25


AKA Variables and AKA Functions

• RAND = random challenge generated by AuC

• XRES = f2K (RAND) = expected user response computed by AuC

• RES = f2K (RAND) = actual user response computed by USIM

• CK = f3K (RAND) = cipher key

• IK = f4K (RAND) = integrity key

• AK = f5K (RAND) = anonymity key

• SQN = sequence number

• AMF = authentication management field

• MAC = f1K(SQN || RAND || AMF) = message authentication codecomputed over SQN, RAND and AMF

• AUTN = SQN⊕AK || AMF || MAC = network authenticationtoken, concealment of SQN with optional AK

• Quintet = (RAND, XRES, CK, IK, AUTN)


26


AKA Authentication Vector (68 –80 octets)

Variable Description Multiplicity Length

RAND Network challenge 1 128

(X)RES Expected response 1 32-128

CK Cipher key 1 128

IK Integrity key 1 128

AUTN Authentication token 1 128

SQNor

SQN ⊕⊕⊕⊕ AK

Sequence numberorConcealed sequence number

1 per AUTN 48

AMF Authentication Management Field 1 per AUTN 16

MAC-A Message authentication code for network authentication

1 per AUTN 64

Alec Brusilovsky

Documents

Transcript of Alec Brusilovsky