Cellular Wireless Key Managament

Alec Brusilovsky Wireless Architecture and Standards Development, Secure Communications

October 26, 2007

Wednesday, March 18, 2009

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

Cellular Wireless Key Management

2

Wednesday, March 18, 2009

ePS - Non-Roaming Reference Architecture

HSS

Wx* Wx*
PCRF S7 Rx+ SGi PDN SAE Gateway S6c S2b Wm* Operator Operators IP Services (e.g. IMS, PSS etc.)

2G/3G SGSN

S4 S3 MME S11

S6a

S1S1-MME S10 EUTRAN S1S1-U

Serving SAE Gateway

S5

Cellular Wireless Key Management

S2c HPLMN NonNon-3GPP Networks

S2a

ePDG

Wn* Wn*
Untrusted NonNon-3GPP IP Access Wa* Wa*

3GPP AAA Server

Trusted/Untrusted Trusted/Untrusted* Untrusted* Non-3GPP IP Access Non or 3GPP Access

Trusted NonNon-3GPP IP Access

UE

Ta*

Wednesday, March 18, 2009

Security Layers in eUTRAN

Security layer 1 Security layer 2

eNB Xu UE Cellular Wireless Key Management Xu eNB

Security layer 1

S 1-C S 1 -U

MME SAE GW

X2

S 1-C S 1 -U
Evolved Packet Core ( EPC )

E - UTRAN

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).

Wednesday, March 18, 2009

AKA run and key change/derivation

Result of the AKA run
USIM / AuC K

CK, IK

UE / HSS
KASME

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
KeNB-RRC-enc

Cellular Wireless Key Management

K_ASME is derived from CK&IK. It never leaves the EPC

UE / ASME UE/ASME
KNAS enc KNAS int KeNB

UE / MME
KeNB-UP-enc KeNB-RRC- int

UE / eNB

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.

Wednesday, March 18, 2009

Key refresh on Intra-MME handover

UE Source eNB
1. Measurement report HO decision 1. Derive KeNB* from KeNB 2. HO request, KeNB* 3. HO response (C-RNTI) 4. HO command (C-RNTI)

Target eNB

EPC

Cellular Wireless Key Management

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

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

6. HO complete

7. UE location update

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

Wednesday, March 18, 2009

Key refresh on Inter-MME handover

UE Source eNB
1. Measurement report HO decision 1. Derive KeNB* from KeNB 2. HO request, KeNB* 3. HO request, KeNB*, NAS keys, K-ASME, COUNT, 4. HO request, KeNB* 5. HO response (C-RNTI)

Target eNB

Source MME

Target MME

Cellular Wireless Key Management

2. Derive new KeNB from KeNB*, and C-RNTI 3. Derive RRC/UP keys from new KeNB 6. HO response (C-RNTI) 7. 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 8. HO confirm 9. HO complete

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.

Wednesday, March 18, 2009

What is wrong with that?

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; Key material is transferred inband;

Cellular Wireless Key Management

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; Poisoned key chain Inband key material transfer All of the subsequent nodes will be transparent to the adversary without physical breaking in;

Solution: transfer key material out of band

Wednesday, March 18, 2009

Alternative 1 forward secrecy from the Step 1

Initial SA Establishment Handover Prior to handover

UE

Source eNB

Target eNB

MME
1. Pick a random MMEeNB_key

2.Forward MME-eNB_key
3.UE location update (List of potential target (i.e. neighbour) eNB) 3A. Pick a random H_key; and 3B. KeNBeNB_ID = AESH_KEY(eNB_ID), 3C. Encrypt KeNBBS_ID with respective MME-

eNB_key = {KeNBBS_ID}MME-eNB_key[BS_ID].

4. List of {KeNBeNB_ID}MME-eNB_key[eNB_ID] for each potential target eNB.)

Cellular Wireless Key Management

5. Forwards H_key, protected by NAS security 6. Measurement report

6a.HO decision
7. HO request ({KeNBTarget eNB_ID}MME-eNB_key[Target eNB_ID] )
7A. Recover KeNB using MME-eNB_key[BS_ID]

BS_ID decrypt

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

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.

10. HO confirm 11. HO complete 12. UE location update (List of potential target (i.e. neighbour) eNB)
13. {KeNBBS_ID}MME-eNB_key[BS_ID] for each potential target eNB.)

Wednesday, March 18, 2009

Alternative 2 forward secrecy from the Step 2 Intra-MME

Prior to handover Handover

UE

Source eNB

Target eNB

MME
1. Pick a random H_nonce

2. Forwards H_nonce 3. Forwards H_nonce, protected by NAS security 4. Measurement report 4A. HO decision 4B. Derive KeNB* from KeNB

Cellular Wireless Key Management

5. HO request (H_nonce, KeNB*) 6. HO response 7. HO command (Target eNB_ID)

7A. Derive new

KeNB from KeNB*, H_nonce, Target eNB_ID KeNB

6A Derive new

KeNB from KeNB*, H_nonce, Target eNB_ID

7B. Derive RRC/UP keys from the new

6B. Derive RRC/UP keys from the new KeNB

8. HO confirm 9. HO complete 10. UE location update

10

Wednesday, March 18, 2009

Alternative 2 forward secrecy from the Step 2 Inter-MME

UE Source eNB Target eNB Source MME
1. Pick a random H_nonce

Target MME

2. Forwards H_nonce 3. Forwards H_nonce, protected by NAS security

4. Measurement report 4A. HO decision 4B. Derive KeNB* from KeNB

Cellular Wireless Key Management

5. HO request (H_nonce, KeNB*) 7. HO request (H_nonce, KeNB

7A Derive new

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

7B. Derive RRC/UP keys from

10. HO command (Target eNB_ID)

10A. Derive new

6. HO response (Target eNB_ID) 9. HO response (eNB_ID)

the new KeNB

KeNB from KeNB*, H_nonce, Target eNB_ID KeNB 11. HO confirm 12. HO complete

10B. Derive RRC/UP keys from the new

11

Handover

KeNB from KeNB*, H_nonce, Target eNB_ID

Wednesday, March 18, 2009

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;

Cellular Wireless Key Management

12

Cellular Wireless Key Management

Wednesday, March 18, 2009

13

Outtakes GSM/UMTS security/history

Wednesday, March 18, 2009

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;

Cellular Wireless Key Management

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

14

Wednesday, March 18, 2009

Before we start little terminology

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.

LTE
Cellular Wireless Key Management

eUTRAN Enhanced UTRAN

SAE SAE/LTE

ePC Enhanced Packet Core

ePS Enhanced Packet System

15

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

Wednesday, March 18, 2009

Cellular Wireless access technologies

Analog (AMPS) supported till 2008, will be phased out after that TDMA phased out to give spectrum to GSM/UMTS

Cellular Wireless Key Management

3GPP2 side CDMA-1, CDMA-2000-1XRTT, EVDO, EVDV 3GPP side GSM, EDGE, GPRS, UMTS, LTE

16

Wednesday, March 18, 2009

Security in GSM
Functions: Authentication yes (GSM AKA) Integrity no Confidentiality yes

Cellular Wireless Key Management

Privacy yes (Temporary Identity TMSI)

Security association is between mobile and HLR (shared root key Ki), AKA is executed between mobile and VLR and HLR Ciphering Key is stored at the Base Station (BTS)

17

Wednesday, March 18, 2009

GSM AKA

MS Register IMSI

VLR

HLR

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

Request for triplets

triplets Cellular Wireless Key Management (RAND, XRES, Kc) RAND Compute RES and Kc RES RES = A3(RAND, Ki) Kc = A8(RAND, Ki) HLR Home location Register IMSI International Mobile Subscriber Identity MS Mobile station RAND Random challenge RES Response to an authentication challenge VLR Visited Location Register XRES eXpected Response Validate RES = XRES

18

Wednesday, March 18, 2009

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

Cellular Wireless Key Management

19

Wednesday, March 18, 2009

Security in UMTS
Functions: Authentication yes (UMTS AKA) Integrity yes (IK from AKA) Confidentiality yes

Cellular Wireless Key Management

Privacy yes (Temporary Identity TMSI)

20

Wednesday, March 18, 2009

UMTS security is based on GSM security

And designed to be backwards compatible The improvements are: A change was made to defeat the false base station attack. The security mechanisms include a sequence number that 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.

Cellular Wireless Key Management

21

Wednesday, March 18, 2009

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)

Cellular Wireless Key Management

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

22

Wednesday, March 18, 2009

UMTS AKA

USIM

MS Register IMSI

VLR

HLR/AuC

Compute quintuplets

Authentication data request Auth. Vectors

Cellular Wireless Key Management

1. Check if SQN is in the range 2. Compute RES, CK, IK

RAND, AUTN RES, IK, CK

RAND, AUTN Validate RES = XRES Select CK, IK

RES

AuC Authentication Center AUTH Authentication vector (quintuplet) AUTN Authentication Token CK Ciphering Key HLR Home location Register IK Integrity Key

IMSI International Mobile Subscriber Identity MS Mobile station RAND Random challenge RES Response to an authentication challenge VLR Visited Location Register XRES eXpected Response

23

Wednesday, March 18, 2009

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

Cellular Wireless Key Management

24

Wednesday, March 18, 2009

AKA Variables and AKA Functions

RAND = random challenge generated by AuC XRES = f2K (RAND) = expected user response computed by AuC RES CK IK = f2K (RAND) = actual user response computed by USIM = f3K (RAND) = cipher key = f4K (RAND) = integrity key = f5K (RAND) = anonymity key = sequence number = authentication management field = f1K(SQN || RAND || AMF) = message authentication code computed over SQN, RAND and AMF

Cellular Wireless Key Management

AK SQN AMF MAC

AUTN = SQNAK || AMF || MAC = network authentication token, concealment of SQN with optional AK Quintet = (RAND, XRES, CK, IK, AUTN)

25

Wednesday, March 18, 2009

AKA Authentication Vector (68 80 octets)

Variable RAND (X)RES CK IK Network challenge Expected response Cipher key Integrity key Authentication token Sequence number or Concealed sequence number Authentication Management Field Message authentication code for network authentication Description 1 1 1 1 1 1 per AUTN Multiplicity Length 128 32-128 128 128 128 48

Cellular Wireless Key Management

AUTN SQN or SQN AK AMF MAC-A

1 per AUTN 1 per AUTN

16 64

26