Cryptography in Mobile Networks
Mats Näslund
mats.naslund@ericsson.com
March 3, 2011
Outline
• Overview of GSM Cryptography
• Some “attacks” on GSM
– Lessons to be learnt
• Overview of “3G” UMTS Cryptography
• The new ”thing”: Cryptography in LTE
2
2011-03-02
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...
3
2011-03-02
GSM Cryptography Overview
4
2011-03-02
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
– Today 128 bits can be supported in GSM
• Basic user identity protection (“pseudonyms”)
5
2011-03-02
GSM Architecture (”2G”)
K
To other (mobile)
network(s)
Encryption:
A5/1, A5/3 (64 bit)
A5/2 (”export” version)
A5/4 (128 bits, new)
HLR/AuC
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
MSC
BSC
Authentication,
shared key, A3 Algorithm
RBS
K
MS
SIM
6
128-bit key
2011-03-02
GSM Authentication: Overview
Home Network
K
Req(IMSI)
RAND
K
RAND, Kc
RES
AuC/HLR
RAND, XRES, Kc
MSC
RBS
RES = XRES ?
Visited Network
7
2011-03-02
GSM Authentication: Details
A3 and A8: Authentication and key derivation (proprietary)
A5: encryption (A5/1-4, standardized)
Note: one-sided authentication
Phone
SIM Ki
(128) A3
A8
frame#
data/speech
RAND (128)
RES (32)
Kc (64)
A5/x

8
encrypted frame
Bit-by-bit, stream cipher
2011-03-02
Quick Note: LFSR
(Linear feedback shift register)
key = 0 1 1 0 1 0 1
State:
10 01
1
1
10
01
10
01
output
...0 1

XOR:ed with plaintext
Very efficient, rich theory, unfortunately very insecure…
• Add non-linear components
• Combine several LFSRs
Used by A5/1 and A5/2
• Irregular clocking
9
2011-03-02
August 2003: Attack on A5/2 Published
10
2011-03-02
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
number
Lesson
#1: Avoid
using
the
same
key
for two
increases by one.
different things
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
2011-03-02
Impact 1: Find key, eavesdrop (passive attack)
Impact 2: Active attacks in any network
Lesson
#2: Signalling that controls
(False
base-station/man-in-the-middle
attacks)the
security
1 RAND
2 RAND should be authentciated/integrity
4 RES
3
RES
protected
5 Start encr: A5/1
6 Start encr: A5/2
8 Stop encr
9 Start encr: A5/1
Lesson #3: If you change encryption
algorithm, change also the key
7 Attack  key
12
2011-03-02
Note
• A5/2 is an ”export” version, not used in Sweden
(or Europe)
• Attack does not apply to A5/1, A5/3
• 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 has already been implemented
13
2011-03-02
Inherent GSM Problem
• Originally designed for max 64 bit keys
• Sophisticated “dictionary” attacks possible: rainbow tables
– Hellman time-memory trade-off
r11
f
r12 f
…
f
r1m
r21
f
r22 f
…
f
r2m
…
rn1
f
…
rn2 f
…
(64-bit keys ~ 2TB storage)
Given: r = f(x)
f
…
r = r1 f
rnm
?
stored
r2 … rt
Could hope to find x if nt > 264
14
2011-03-02
Inherent GSM Problem (cont’d)
• Using current technology, this is within reach and tables for
A5/1 exist
– Nvidia GPUs
Support for 128 bit keys is essential!
– Bit-torrent
Support
added
in need
standard
2009
• Until recently
only was
obstacle
was
for aDecember
“GSM radio
interceptor”
(May in
however
• Developments
2010: not be widely deployed yet…)
- USRP (Software Defined Radio)
- Open BSS source code
~ $1500
15
+ OsmocommBB
~ $100
2011-03-02
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
16
2011-03-02
UMTS Security Overview
17
2011-03-02
3G (UMTS) Security
Described
later
• Mutual Authentication with Replay Protection
• Protection of signalling data
Lesson #2…
– Secure negotiation of protection algorithms
– Integrity protection and origin authentication
– Encryption
Only feature common
• Protection of user data payload
to GSM
– 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
18
2011-03-02
UMTS Architecture (”3G”)
K
To other (mobile)
network(s)
Encryption:
UEA1 or UEA2
GSN: GPRS Support Node
SGSN: Serving GSN
GGSN: Gateway GSN
RNC: Radio Network Controller
ME: Mobile Equipment
HLR/AuC
GPRS, ”2.5G”
MSC
SGSN
RNC
”secure env”
Signalling integrity:
UIA1 or UIA2
GGSN
”Internet”
Authentication, shared key
Milenage (AES) algorithm
”insecure env”
NodeB
K
UMTS SIM (USIM)
ME
19
2011-03-02
UMTS Encryption Example: UEA1
COUNT || BEARER || DIR || 0…0 (64 bits)
Kasumi
m
(const)
CK
(128 bits)


Kasumi
c=1
Kasumi

c=2
Kasumi

Kasumi
“keystream” XOR:ed with plaintext
20
c=B
2011-03-02
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!
21
2011-03-02
LTE: Long Term Evolution
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 standard ready 2008 after large efforts
- Example: considering only Ericsson and only security,
we had 240 contributions during 2008
• Commercial availability recently
23
2011-03-02
LTE Thinking
Starting from a UMTS network...
IP part, efficient, cheap,
attaractive services:
keep and optimize!
HLR/AuC
split
Oldfashioned
After  1 years of discussion in
”telephony”:
decided toGGSN
get rid ofstandardization
it!
MSC it was SGSN
terminate (most) security in NodeB.
Powerful but complex,
adds delay/latency
RNC
”secure env”
”insecure env”
New ”radio”, ~ 100Mb/s
(OFDM)
?
”Internet”
But what do we do
with encryption?
NodeB
High security: keep SIM concept
ME
24
2011-03-02
LTE
- A simplified network -
HSS:
Home Subscriber System
MME:
Mobility Management Entity
eNodeB: Evolved NodeB
encryption
intgegrity
HSS
K
”split” into control
and user plane
“Gateway”
Internet &
IP services
MME
Re-encryption of user traffic
(IPsec)
Authentication,
similar to UMTS
Encryption/integrity, for
network control signalling
eNodeB
Encryption/integrity, for
radio control signalling
5 different keys used...
Same USIM as in UMTS
but K may be up to 256 bits
K
25
ME
Encryption for user traffic
2011-03-02
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
F(Key, ”1”)
Key1
F(Key, ”2”)
Key2
Applications:
• Key1 for algorithm1, Key2 for algorithm2
• Key1 for encryption, Key2 for integrity
• Key1 for user data, Key2 for control sign.
• ...etc...
* Key1 can not be reverse-engineered from Key2 (or v.v.)
* Key can not be reverse-engineered from Key1 and/or Key2
26
2011-03-02
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
27
2011-03-02
LTE: Initial Attach
K
eNB
- Does AUTN come from
HSS?
MME
- Have I seen it before?
ATTACH REQUEST
(IMSI, SUPPORTED_ALGS)
= AES2(K, RAND)
3. (Ck, Ik) = AES3(K, RAND)
RES,
Ck, Ik
RES
Derive KA, Ke ....
K
AUTH VECT FETCH
(IMSI)
1. Check (AES1(K, RAND), SQN, AUTN))
2. RES
HSS
RAND, XRES,
AUTN, KA
RAND, AUTN
RAND = RANDOM()
Check: RES == XRES ??
SQN = SQN + 1
AUTN = AES1(K, RAND, SQN)
XRES = AES2(K, AND)
”OK”, SELECTED_ALG,
(Ck, Ik) = AES3(K,
KA RAND)
SUPPORTED_ALGS
F
KA = F(Ck, Ik, ...)
- Verify ”OK”
- Switch ”on” security
Ke
KN-int
[”OK”]
Ke
Protected signaling
Protected traffic
Ke
F
28
KeUP-enc
KeRRC-int
KeRRC-enc
2011-03-02
KN-enc
LTE: Key Hirearchy
K
”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”
29
2011-03-02
Example
Ck, Ik
HSS
KA = F(Ck, Ik, ....)
MME
KA
Ke = F(KA, ....)
Ke
eNodeB
30
2011-03-02
LTE Key Handling at Handover (1/3)
”Backward Security”
KA
Gateway
MME
Ke2 = F(Ke1,...)
eNodeB1
Ke1
Ke2
eNodeB2
Ke2
”Handover
to eNodeB2”
Ke2
KA, Ke1, ...
31
2011-03-02
LTE Key Handling at Handover (2/3)
KA
Gateway
MME
eNodeB1
Ke1
Ke2
eNodeB2
Ke2
Ke2 = F(Ke1,...)
Ke2
KA, Ke1, ...
32
2011-03-02
LTE Key Handling at Handover (3/3)
”Forward Security”
Ke2* = F(KA,...)
KA
Gateway
MME
Ke2*
eNodeB1
Ke1
keys etc
eNodeB2
Ke2 Ke2*
Ke2 = F(Ke1,...)
Ke2 Ke2*
KA, Ke1, ...
33
2011-03-02
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...
34
2011-03-02
Implicit Authetication
User already authenticated in GSM
May need transatalantic
communication...
HLR/AuC
KGSM
MSC
KGSM
BSC
KGSM
... moves to UMTS
SGSN
RNC
KUMTS = c(KGSM)
Also, c is a weak
XOR-function
KUMTS
NodeB
RBS
KGSM
The fact that user was
able to produce the
correct
KUMTS ”proves”
or...?
that it is the same user
KUMTS = c(KGSM)
35
2011-03-02
LTE Inter-system Key Handling
Example: UMTS  LTE
UMTS LTE
KLTE = F1(KUMTS)
KUMTS
SGSN
KLTE
MME
KUMTS = F2(KLTE)
RNC
NodeB
eNodeB
F1, F2 based on HMAC_SHA256
36
2011-03-02
Note on ”Crypto capacity”
Dedicated Crypto HW
Gateway
May serve 3-6
”cells” / ”phones”
Quite high ”crypto load”,
say ~ 102 base stations
600Mb/s
100Mb/s
NodeB
100Mb/s
37
2011-03-02
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 in so called Counter Mode
– SNOW 3G
– ZUC, ”The chineese algorithm”
38
2011-03-02
SNOW 3G
Basic design by T. Johansson & P. Ekdahl (U. Lund)
Improvements by ETSI SAGE
39
2011-03-02
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
• LTE much more complex, needed to meet
“at least as secure as 3G”
Main reason: security “ends” at the base station
40
2011-03-02