1. Cryptography in Mobile Networks
Mats Näslund
Communication Security Lab
Ericsson Research
March 6, 2009

2. Outline Overview of GSM Cryptography Some “attacks” on GSM
Lessons to be learnt
Overview of “3G” UMTS Cryptography
The new ”thing”: Cryptography in LTE

3. 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)
- User privacy
Early systems were not perfect and under restrictions...

4. GSM Cryptography Overview

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

6. GSM Architecture (”2G”)
MSC: Mobile Switching Center
BSC: Base Station Controller RBS: Radio Base Station
MS: Mobile Station
HLR: Home Location Register AuC: Authentication Center
SIM: Subcriber Identity Module K
HLR/AuC
Authentication,
shared key, A3 Algorithm
To other (mobile) network(s)
MSC
Encryption: A5/1, A5/3 (64 bit) A5/2 (”export” version)
A5/4 (128 bits, new)
BSC
RBS K
128-bit key MS
SIM

7. GSM Authentication: Overview
Home Network K
Req(IMSI)
AuC/HLR
RAND, XRES, Kc
RAND
RAND, Kc
RES
RES = XRES ?
MSC K
RBS
Visited Network

8. GSM Authentication: Details
A3 and A8: Authentication and key derivation (proprietary)
A5: encryption (A5/1-4, standardized)
Note: one-sided authentication
Phone
RAND (128)
SIM
Ki (128)
A3 A8
RES (32)
Kc (64)
data/speech
frame#
A5/x 
encrypted frame
Bit-by-bit, stream cipher

9.  Quick Note: LFSR (Linear feedback shift register)
key = 1
output 1
State: 1
...0  1
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

10. Lesson #1: Avoid using the same key for two different things
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
Lesson #1: Avoid using the same key for two different things
Only difference between frames is that frame number increases 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 channels contains known info and uses same key as speech channel!

11. Lesson #2: Signalling that controls the
Impact 1: Find key, eavesdrop (passive attack)
Impact 2: Active attacks in any network (False base-station/man-in-the-middle attacks)
Lesson #2: Signalling that controls the
security should be authentciated/integrity protected
2 RAND
1 RAND
4 RES
3 RES
6 Start encr: A5/2
5 Start encr: A5/1
8 Stop encr
9 Start encr: A5/1
Lesson #3: If you change encryption algorithm, change also the key
7 Attack  key

12. 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 to upgrade 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?)

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

14. UMTS Security Overview

15. 3G (UMTS) Security Described later
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
“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
Lesson #2…
Only feature common to GSM

16. UMTS Architecture (”3G”)
GSN: GPRS Support Node
SGSN: Serving GSN
GGSN: Gateway GSN RNC: Radio Network Controller
ME: Mobile Equipment
UMTS Architecture (”3G”) K
HLR/AuC
GPRS, ”2.5G”
Authentication, shared key Milenage (AES) algorithm
To other (mobile) network(s)
MSC
”Internet”
SGSN
GGSN
Encryption:
UEA1 or UEA2
RNC
”secure env”
”insecure env”
Signalling integrity:
UIA1 or UIA2
NodeB K ME
UMTS SIM (USIM)

17. UMTS Encryption Example: UEA1
COUNT || BEARER || DIR || 0…0 (64 bits)
Kasumi
m (const) 
c = 1
c = 2
c = B   
“Provably” secure under assumptions on Kasumi
Kasumi
Kasumi
Kasumi
Kasumi
CK (128 bits)
“keystream” XOR:ed with plaintext

18. 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!

19. LTE: Long Term Evolution

20. 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 ) you will not see the same names for keys etc

21. Background: Standardization
Mobile standards (including security functions) are defined by 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

22. LTE Thinking Starting from a UMTS network...
IP part, efficient, cheap, attaractive services:
keep and optimize!
HLR/AuC
split
Oldfashioned ”telephony”: get rid of it!
After  1 years of discussion in standardization it was decided to terminate (most) security in NodeB.
MSC
”Internet”
SGSN
GGSN ?
Powerful but complex, adds delay/latency
RNC
But what do we do with encryption?
”secure env”
New ”radio”, 100Mb/s
(OFDM)
”insecure env”
NodeB
High security: keep SIM concept ME

23. LTE - A simplified network -
HSS: Home Subscriber System
MME: Mobility Management Entity
eNodeB: Evolved NodeB
encryption
intgegrity K
HSS
Authentication, similar to UMTS
Internet &
IP services
”split” into control
and user plane
“Gateway”
MME
Re-encryption of user traffic (IPsec)
Encryption/integrity, for network control signalling
Encryption for user traffic
eNodeB
Encryption/integrity, for radio control signalling
5 different keys used... K
Same USIM as in UMTS but K may be up to 256 bits ME

24. 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):
Applications:
Key1 for algorithm1, Key2 for algorithm2
Key1 for encryption, Key2 for integrity
Key1 for user data, Key2 for control sign.
...etc...
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

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

26. LTE: Initial Attach K K eNB MME HSS - Does AUTN come from HSS?
- Have I seen it before?
ATTACH REQUEST (IMSI, SUPPORTED_ALGS)
AUTH VECT FETCH (IMSI)
1. Check (AES1(K, RAND), SQN, AUTN))
2. RES = AES2(K, RAND)
3. (Ck, Ik) = AES3(K, RAND)
RAND, XRES, AUTN, KA
RAND, AUTN
RAND = RANDOM() SQN = SQN + 1
AUTN = AES1(K, RAND, SQN)
RES = AES2(K, AND)
(Ck, Ik) = AES3(K, RAND) KA = F(Ck, Ik, ...)
Check: RES == XRES ??
RES, Ck, Ik
RES
Derive KA, Ke ....
KN-enc
KN-int KA F Ke
”OK”, SELECTED_ALG, SUPPORTED_ALGS
- Verify ”OK” - Switch ”on” security
[”OK”] Ke
Protected signaling
KeRRC-enc
KeRRC-int
KeUP-enc Ke F
Protected traffic

27. LTE: Key Hirearchy USIM/HSS ME/HSS ME/MME ME/eNB ME/MME
”Downward” derivation
by one-way function,
infeasible to get ”high”
key from a ”low” key
USIM/HSS CK IK
ME/HSS KA
ME/MME
KN-int
KN-enc Ke
ME/eNB
ME/MME
KeUP-enc
KeRRC-int
KeRRC-enc
PRF: infeasible to to get another key on ”same level”

28. Example Ck, Ik KA = F(Ck, Ik, ....) KA Ke = F(KA, ....) Ke HSS MME
eNodeB

29. LTE Key Handling at Handover (1/3)
”Backard Security”
Gateway KA
MME
Handover
Ke2 = F(Ke1,...)
Ke2
eNodeB1
Ke1
eNodeB2
Ke2
”Handover to eNodeB2”
KA, Ke1, ...

30. LTE Key Handling at Handover (2/3)
Gateway KA
MME
Handover
Ke2
eNodeB1
Ke1
eNodeB2
Ke2
Ke2 = F(Ke1,...)
KA, Ke1, ...

31. LTE Key Handling at Handover (3/3)
”Forward Security”
Ke2* = F(KA,...)
Gateway KA
MME
Handover
Ke2*
keys etc
eNodeB1
Ke1
eNodeB2
Ke2*
Ke2
Ke2 = F(Ke1,...)
KA, Ke1, ...
Ke2

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

33. Implicit Authetication
User already authenticated in GSM
... moves to UMTS
May need transatalantic communication...
HLR/AuC
KGSM
KUMTS = c(KGSM)
MSC
SGSN
KGSM
KUMTS
Also, c is a weak XOR-function
BSC
RNC
The fact that user was able to produce the correct KUMTS ”proves” that it is the same user
or...?
KGSM
RBS
NodeB
KGSM

34. LTE Inter-system Key Handling Example: UMTS  LTE
KUMTS
KLTE = F1(KUMTS)
SGSN
MME
KUMTS = F2(KLTE)
KLTE
RNC
NodeB
eNodeB
F1, F2 based on HMAC_SHA256

35. Note on ”Crypto capacity”
Dedicated Crypto HW
Quite high ”crypto load”,
say ~ 102 base stations
Gateway
May serve 3-6 ”cells” / ”phones”
600Mb/s
100Mb/s
NodeB
100Mb/s

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

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

38. Summary
Despite some attacks on GSM security, the security is so far pretty much a success story
Main reason: convenience and invisibility to user
UMTS crypto significantly improved, use with confidence
Main reason: free world, longer keys, “open” standard
The
End
LTE much more complex, needed to meet “at least as secure as 3G”
Main reason: security “ends” at the base station