Cryptography in Mobile Networks

Mats Näslund

Communication Security Lab

Ericsson Research

mats.naslund@ericsson.com

March 6, 2009

2009-03-062

Outline

• Overview of GSM Cryptography• Some “attacks” on GSM

– Lessons to be learnt

• Overview of “3G” UMTS Cryptography• The new ”thing”: Cryptography in LTE

2009-03-063

History

• Mobile (wireless) communication has inherent threats– Eavesdropping– Impersonation– Connection hijacking – ...

• Except early systems (e.g. NMT), use of cryptography has been deemed necessary

- Protection of buisness (robust charging of subscribers)

• Early systems were not perfect and under restrictions...

- User privacy

2009-03-064

GSM Cryptography Overview

2009-03-065

GSM Security

• Use of a smart card SIM – Subscriber Identity Module, tamper resistant device holding critical information, – e.g. 128-bit key shared with Home Operator

• The SIM is the entity which is authenticated– Challenge response mechanism (one-sided)

• At the time (ca 1990) crypto was considered “weapon”– Initial GSM algorithms (were) not publicly available– Limited key size – Special “export version” of encryption algorithms

• GSM ciphering on “first hop” only: stream ciphers using 54/64 bit keys– In a “free” world, we will soon see 128 bits in GSM

• Basic user identity protection (“pseudonyms”)

GSM crypto is probably (one of) the most

frequently used crypto in the world.

2009-03-066

GSM Architecture (”2G”)

RBS

BSC

MSC

MS

To other (mobile) network(s)

HLR/AuC

MSC: Mobile Switching CenterBSC: Base Station ControllerRBS: Radio Base StationMS: Mobile StationHLR: Home Location RegisterAuC: Authentication CenterSIM: Subcriber Identity Module

SIM

Encryption: A5/1, A5/3 (64 bit) A5/2 (”export” version) A5/4 (128 bits, new)

Authentication,shared key, A3 Algorithm

K128-bit key

K

2009-03-067

GSM Authentication: Overview

RBSMSC

AuC/HLR

Visited Network

Home Network

Req(IMSI)

RAND, XRES, KcRES

RES = XRES ?

RAND RAND, Kc

K

K

2009-03-068

GSM Authentication: Details

A3 and A8: Authentication and key derivation (proprietary)A5: encryption (A5/1-4, standardized)

Ki(128)

RAND (128)

RES (32)

Kc (64)A5/x

PhoneSIM

encrypted frame

A3A8

Note: one-sided authentication

data/speech

frame#

Bit-by-bit, stream cipher

2009-03-069

Quick Note: LFSR(Linear feedback shift register)

0 1 1 0 1 0 1

key = 0 1 1 0 1 0 1

State: output1...0

1

1 0 1 1 0 1 0

XOR:ed with plaintext

Very efficient, rich theory, unfortunately very insecure…• Add non-linear components• Combine several LFSRs• Irregular clocking

Used by A5/1 and A5/2

2009-03-0610

Idea behind the attack

A5/2 is highly ”linear”, can be expressed as linear equation system in 660 unknown 0/1 variables, of which 64 is the key

If plaintext known, each 114-bit frame gives 114 equations

Only difference between frames is that frame numberincreases by one.

After 6 frames (in reality only 4) we have > 660 equations can solve! (Takes about 1sec on a PC)

Even if “speech” plaintext unknown, GSM control channelscontains known info and uses same key as speech channel!

Lesson #1: Avoid using the same key for twodifferent things

2009-03-0611

Impact 2: Active attacks in any network(False base-station/man-in-the-middle attacks)

6 Start encr: A5/2

2 RAND

8 Stop encr

9 Start encr: A5/1

5 Start encr: A5/1

1 RAND

7 Attack key

3 RES 4 RES

Impact 1: Find key, eavesdrop (passive attack)

Lesson #2: Signalling that controls thesecurity should be authentciated/integrityprotected

Lesson #3: If you change encryptionalgorithm, change also the key

2009-03-0612

Note

• A5/2 is an ”export” version, not used in Sweden (or Europe)

• Attack does not apply to A5/1, A5/3– …well almost….

• Various countermeasures proposed but expensive toupgrade all equipment– Adding integrity, change of keys as proposed on previous slide

fall into the ”not-for-free” category

• Simple and quite good solution is to phase out A5/2

- This is in progress (done?)

2009-03-0613

GSM Summary

• GSM was desiged in the ”dark ages” of crypto• It addresses the threats that were considered at the time• It targeted a 10-year ”economic lifetime”• The best feature of GSM security is that securiy is built-in

– as a user, you don’t need to do ”configuration” etc

2009-03-0614

UMTS Security Overview

2009-03-0615

3G (UMTS) Security

• Mutual Authentication with Replay Protection• Protection of signalling data

– Secure negotiation of protection algorithms– Integrity protection and origin authentication– Encryption

• Protection of user data payload– Encryption

• “Open” algorithms basis for security– AES for authentication and key agreement– Kasumi (block cipher) for confidentiality/integrity

• Security level (key sizes): 128 bits• Protection further into the network

Only feature commonto GSM

Lesson #2…

Describedlater

2009-03-0616

UMTS Architecture (”3G”)

NodeB

RNC

MSC

ME

To other (mobile) network(s)

HLR/AuC

SGSN GGSN ”Internet”

UMTS SIM (USIM)

”secure env”

”insecure env”

GSN: GPRS Support NodeSGSN: Serving GSNGGSN: Gateway GSNRNC: Radio Network Controller ME: Mobile Equipment

GPRS, ”2.5G”

Signalling integrity:UIA1 or UIA2

Encryption:UEA1 or UEA2

K

K

Authentication, shared keyMilenage (AES) algorithm

2009-03-0617

UMTS Encryption Example: UEA1

Kasumi

Kasumi Kasumi Kasumi

Kasumi

c = 1 c = 2 c = B

CK(128 bits)

m (const)

“keystream” XOR:ed with plaintext

COUNT || BEARER || DIR || 0…0 (64 bits)

“Provably” secure under

assumptions on Kasumi

2009-03-0618

Note

• There are no known security problems with UMTS• HSPA (a.k.a. ”Mobile broadband”, ”Turbo 3G”,...) is

from crypto/security point of view identical to 3G/UMTS– You can feel safe when using it!

LTE: Long Term Evolution

2009-03-0620

Disclaimer on Notation

• ”LTE” refers only to the radio part of the new standard• Also other parts of the mobile network is upgraded

– Refered to as EPC, ”Evolved Packet Core”

• Will for simplicty use ”LTE” to denote the entire architecture• If you do look at the standards document (3GPP TS 33.401)

you will not see the same names for keys etc

2009-03-0621

Background: Standardization

• Mobile standards (including security functions) are definedby 3GPP (part of ETSI)– Participation by mobile vendors and operators

• The cryptography is defined by SAGE (also part of ETSI)– Special Algorithm Group of Experts

• 2006: initiative for ”next generation”, LTE, started– Slogan: ”At least as secure as UMTS”

• First LTE release just finished after intense efforts- Example: considering only Ericsson and only security, we had 240 contributions during 2008

2009-03-0622

”secure env”

LTE ThinkingStarting from a UMTS network...

NodeB

RNC

MSC

ME

HLR/AuC

SGSN GGSN ”Internet”

High security: keep SIM concept

New ”radio”, 100Mb/s(OFDM)

Oldfashioned ”telephony”: get rid of it!

IP part, efficient, cheap, attaractive services:keep and optimize!

Powerful but complex,adds delay/latency

”insecure env”

But what do we dowith encryption??

splitAfter 1 years of discussion instandardization it was decided to terminate (most) security in NodeB.

2009-03-0623

LTE- A simplified network -

eNodeB

ME

HSS

“Gateway”

Internet &IP services

Same USIM as in UMTSbut K may be up to 256 bits

MME

HSS: Home Subscriber SystemMME: Mobility Management EntityeNodeB: Evolved NodeB encryption intgegrity

”split” into control and user plane

Authentication, similar to UMTS

Encryption for user traffic

Re-encryption of user traffic(IPsec)

Encryption/integrity, for radio control signalling

Encryption/integrity, for network control signalling

5 different keys used...

K

K

2009-03-0624

Recap of Lesson #1 and #3

”Don’t use the same key for two different things”

Suppose we have a function, F, from a set of pseudo random functions (outputs ”look” random):

Key

Key1

F(Key, ”1”)

Key2

F(Key, ”2”)

* Key1 can not be reverse-engineered from Key2 (or v.v.)* Key can not be reverse-engineered from Key1 and/or Key2

Applications:• Key1 for algorithm1, Key2 for algorithm2• Key1 for encryption, Key2 for integrity• Key1 for user data, Key2 for control sign.• ...etc...

2009-03-0625

Fasten Seatbelts...

• Notation: – black color for unprotected info– red color for encrypted into– yellow color for integrity protected info– blue color for encrypted and integrity protected

• Next slides does not show which-key-is-used-for-what• F denotes a PRF based on HMAC_SHA256• AES1, AES2, AES3 denotes 3 PRFs based on AES

2009-03-0626

LTE: Initial Attach

eNB MME

ATTACH REQUEST(IMSI, SUPPORTED_ALGS)

HSS

AUTH VECT FETCH

(IMSI)RAND, XRES, AUTN, KA

RAND, AUTN

K K

1. Check (AES1(K, RAND), SQN, AUTN))

2. RES = AES2(K, RAND)

3. (Ck, Ik) = AES3(K, RAND)

RES, Ck, Ik RES

Check: RES == XRES ??

KN-encKN-int

KAF

Ke

”OK”, SELECTED_ALG, SUPPORTED_ALGS

Derive KA, Ke ....

[”OK”]

RAND = RANDOM()SQN = SQN + 1AUTN = AES1(K, RAND, SQN)RES = AES2(K, AND)(Ck, Ik) = AES3(K, RAND)KA = F(Ck, Ik, ...)

Ke

Protected signaling

- Verify ”OK”- Switch ”on” security

- Does AUTN come from HSS?

- Have I seen it before?

Protected traffic

KeRRC-encKeRRC-intKeUP-enc

Ke

F

2009-03-0627

LTE: Key Hirearchy

KeRRC-encKeRRC-intKeUP-enc

KeKN-int KN-enc

KA

CK IK

K

USIM/HSS

ME/HSS

ME/MME

ME/eNBME/MME

”Downward” derivationby one-way function,infeasible to get ”high”key from a ”low” key

PRF: infeasible to to get another key on ”same level”

2009-03-0628

Example

eNodeB

HSS

MME

Ck, Ik

KA

Ke

KA = F(Ck, Ik, ....)

Ke = F(KA, ....)

2009-03-0629

eNodeB1

Ke1

LTE Key Handling at Handover (1/3)

MME

eNodeB2

Gateway

Ke2

KA, Ke1, ...

KA

HandoverKe2

Ke2

Ke2 = F(Ke1,...)

”Backard Security”

”Handoverto eNodeB2”

2009-03-0630

LTE Key Handling at Handover (2/3)

eNodeB1

Ke1

MME

eNodeB2

Gateway

Ke2

KA, Ke1, ...

KA

HandoverKe2

Ke2

Ke2 = F(Ke1,...)

2009-03-0631

LTE Key Handling at Handover (3/3)

eNodeB1

Ke1

MME

eNodeB2

Gateway

keys etc

KA, Ke1, ...

KA

HandoverKe2

Ke2

Ke2 = F(Ke1,...)

”Forward Security”

Ke2* = F(KA,...)

Ke2*

Ke2*

Ke2*

2009-03-0632

Inter-System Handover/Mobility

• 3GPP systems support optimized handover between systems,e.g. GSM UMTS during an ongoing call• Waiting for (re)authentication too expensive

-The ongoing call would be halted• Solution: key transfer and implict authentication...

2009-03-0633

Implicit Authetication

RBS

MSC

HLR/AuC

BSC

KGSM

KGSM

KGSM

User already authenticated in GSM

NodeB

SGSN

RNC

KGSM

KUMTS = c(KGSM)

KUMTS = c(KGSM)

KUMTS

... moves to UMTS

May need transatalanticcommunication...

The fact that user wasable to produce the correct KUMTS ”proves”that it is the same user or...?

Also, c is a weakXOR-function

2009-03-0634

LTE Inter-system Key HandlingExample: UMTS LTE

NodeB

SGSN

RNC

MMEKLTE

KUMTS

eNodeB

KUMTS = F2(KLTE)KLTE = F1(KUMTS)

F1, F2 based on HMAC_SHA256

UMTS LTE

2009-03-0635

Note on ”Crypto capacity”

NodeB

100Mb/s

Gateway

100Mb/s

May serve 3-6”cells” / ”phones” 600Mb/s

Quite high ”crypto load”, say ~ 102 base stations

Dedicated Crypto HW

2009-03-0636

LTE Crypto Algorithms...

• Key derivation (128 or 256 bits) functions using– AES on the USIM card– HMAC_SHA256 in ”the phone”

• Integrity protection– AES-CMAC– Function based on polynomials over finite fields

• Can be ”proven” to be secure

• Encryption – AES-CounterMode– SNOW 3G

2009-03-0637

SNOW 3G

Basic design by T. Johansson & P. Ekdahl (U. Lund)Improvements by ETSI SAGE

2009-03-0638

Summary

• Despite some attacks on GSM security, the security is so far pretty much a success story

Main reason: convenience and invisibility to user

The

End

• UMTS crypto significantly improved, use with confidence

• LTE much more complex, needed to meet “at least as secure as 3G”

Main reason: security “ends” at the base station

Main reason: free world, longer keys, “open” standard

2009-03-0639