Date post: | 14-Dec-2015 |
Category: |
Documents |
Upload: | kari-wooton |
View: | 217 times |
Download: | 2 times |
Cryptography in Mobile Networks
Mats Näslund
Communication Security Lab
Ericsson Research
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-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-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!
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-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-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