Presentation on theme: "Cryptography in Mobile Networks Mats Näslund Communication Security Lab Ericsson Research March 6, 2009."— Presentation transcript:
Cryptography in Mobile Networks Mats Näslund Communication Security Lab Ericsson Research March 6, 2009
Outline Overview of GSM Cryptography Some “attacks” on GSM –Lessons to be learnt Overview of “3G” UMTS Cryptography The new ”thing”: Cryptography in LTE
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
GSM Cryptography Overview
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.
GSM Architecture (”2G”) RBS BSC MSC MS To other (mobile) network(s) 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 SIM Encryption: A5/1, A5/3 (64 bit) A5/2 (”export” version) A5/4 (128 bits, new) Authentication, shared key, A3 Algorithm K 128-bit key K
GSM Authentication: Overview RBS MSC AuC/HLR Visited Network Home Network Req(IMSI) RAND, XRES, Kc RES RES = XRES ? RAND RAND, Kc K K
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 Phone SIM encrypted frame A3 A8 Note: one-sided authentication data/speech frame# Bit-by-bit, stream cipher
Quick Note: LFSR (Linear feedback shift register) key = State: output 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
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 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! Lesson #1: Avoid using the same key for two different things
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 the security should be authentciated/integrity protected Lesson #3: If you change encryption algorithm, change also the key
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?)
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
UMTS Security Overview
G (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 common to GSM Lesson #2… Described later
UMTS Architecture (”3G”) NodeB RNC MSC ME To other (mobile) network(s) HLR/AuC SGSNGGSN ”Internet” UMTS SIM (USIM) ”secure env” ”insecure env” GSN: GPRS Support Node SGSN: Serving GSN GGSN: Gateway GSN RNC: Radio Network Controller ME: Mobile Equipment GPRS, ”2.5G” Signalling integrity: UIA1 or UIA2 Encryption: UEA1 or UEA2 K K Authentication, shared key Milenage (AES) algorithm
UMTS Encryption Example: UEA1 Kasumi c = 1c = 2c = B CK (128 bits) m (const) “keystream” XOR:ed with plaintext COUNT || BEARER || DIR || 0…0 (64 bits) “Provably” secure under assumptions on Kasumi
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
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
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
”secure env” LTE Thinking Starting from a UMTS network... NodeB RNC MSC ME HLR/AuC SGSNGGSN ”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 do with encryption? ? split After 1 years of discussion in standardization it was decided to terminate (most) security in NodeB.
LTE - A simplified network - eNodeB ME HSS “Gateway” Internet & IP services Same USIM as in UMTS but K may be up to 256 bits MME HSS: Home Subscriber System MME: Mobility Management Entity eNodeB: 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
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...
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
LTE: Initial Attach eNBMME 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-enc KN-int KA F Ke ”OK”, SELECTED_ALG, SUPPORTED_ALGS Derive KA, Ke.... [”OK”] RAND = RANDOM() SQN = SQN + 1 AUTN = 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-int KeUP-enc Ke F
LTE: Key Hirearchy KeRRC-encKeRRC-intKeUP-encKeKN-intKN-encKACKIKK 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 PRF: infeasible to to get another key on ”same level”
Example eNodeB HSS MME Ck, Ik KA Ke KA = F(Ck, Ik,....) Ke = F(KA,....)
eNodeB1 Ke1 LTE Key Handling at Handover (1/3) MME eNodeB2 Gateway Ke2 KA, Ke1,... KA Handover Ke2 Ke2 = F(Ke1,...) ”Backard Security” ”Handover to eNodeB2”
LTE Key Handling at Handover (2/3) eNodeB1 Ke1 MME eNodeB2 Gateway Ke2 KA, Ke1,... KA Handover Ke2 Ke2 = F(Ke1,...)
LTE Key Handling at Handover (3/3) eNodeB1 Ke1 MME eNodeB2 Gateway keys etc KA, Ke1,... KA Handover Ke2 Ke2 = F(Ke1,...) ”Forward Security” Ke2* = F(KA,...) Ke2*
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...
Implicit Authetication RBS MSC HLR/AuC BSC K GSM User already authenticated in GSM NodeB SGSN RNC K GSM K UMTS = c(K GSM ) K UMTS... moves to UMTS May need transatalantic communication... The fact that user was able to produce the correct K UMTS ”proves” that it is the same user or...? Also, c is a weak XOR-function
LTE Inter-system Key Handling Example: UMTS LTE NodeB SGSN RNC MME K LTE K UMTS eNodeB K UMTS = F2(K LTE ) K LTE = F1(K UMTS ) F1, F2 based on HMAC_SHA256 UMTS LTE
Note on ”Crypto capacity” NodeB 100Mb/s Gateway 100Mb/s May serve 3-6 ”cells” / ”phones” 600Mb/s Quite high ”crypto load”, say ~ 10 2 base stations Dedicated Crypto HW
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
SNOW 3G Basic design by T. Johansson & P. Ekdahl (U. Lund) Improvements by ETSI SAGE
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