SECURITY & PRIVACY IN 3G/4G/ 5G NETWORKS: THE AKA PROTOCOL WITH S.ALT, P.-A. FOUQUE, G. MACARIO-RAT, B. RICHARD

Size: px

Start display at page:

Download "SECURITY & PRIVACY IN 3G/4G/ 5G NETWORKS: THE AKA PROTOCOL WITH S.ALT, P.-A. FOUQUE, G. MACARIO-RAT, B. RICHARD"

Laurence Park
5 years ago
Views:

1 SECURITY & PRIVACY IN 3G/4G/ 5G NETWORKS: THE AKA PROTOCOL WITH S.ALT, P.-A. FOUQUE, G. MACARIO-RAT, B. RICHARD

2 ME, MYSELF, AND EMSEC Ø BSc. & MSc. Mathematics, TU Eindhoven Master thesis on multiparty pairing-based key exchange (supervisors: Tanja Lange, Bernhard Esslinger) Ø Ph.D. at CASED (Darmstadt) Thesis: Security aspects of Distance-Bounding Protocols (supervisor: Marc Fischlin) Ø Post-doc at IRISA (Rennes) 13-14: Privacy & Distance Bounding (CIDRE) 14-15: Privacy in geolocation (CIDRE/CAPPRIS) 15-16: TLS/SSL (EMSEC)

3 EMSEC Ø IRISA research team Founded 2014 Led by: Pierre-Alain Fouque (UR1) & Gildas Avoine (INSA) As of Sept. 2015: 5 permanents: 2 UR1, 2 INSA, 1 CNRS Ø Topics: Embedded Security and Cryptography Models & Proofs Attacks on Implementation s Design & Attacks Building blocks Cryptanalysis Real-World ES

4 WHAT I DO Ø Distance-Bounding Protocols Security framework [DFKO11, FO12, FO13b], Protocol assessment/comparison [FO13a, MOV14] Privacy-preserving DB [HPO13,GOR14, MOV14] Protocol with Secret Sharing [GKL+14] Implementations [GLO15] Ø Authenticated Key-Exchange OPACITY [DFG+13] TLS 1.3 [KMO+15], TLS 1.2&1.3 eprint version AKA [AFM+15, FMO+15] (submissions)

5 WHAT I DO (II) Ø Other primitives Signatures of knowledge [FO11] Redactable signatures for tree data [BBD+10] Anonymous PKE [KMO+13] Private asymmetric fingerprinting [FGLO14] Ø Projects ANR LYRICS [finished mid 14] CAPPRIS (Inria) [ongoing]

6 THIS TALK Ø Authenticated Key Exchange Unilateral/Mutual Authentication Elegant Desired Properties Privacy in Authentication Ø The AKA Protocol Description Security (intuition) Ø AKA and Privacy The case of the Hopeless Task Ugly

7 PART II AUTHENTICATED KEY EXCHANGE

8 AUTHENTICATED KEY-EXCHANGE Ø Allows two parties to communicate securely Peer-to-Peer or Server-Client Examples: TLS/SSL ( Ø Two steps: Compute session-specific keys (handshake) Use keys for secure communication (symmetric AE)

9 AKE WITH UNILATERAL AUTHENTICATION Ø Usually the case for Server-Client AKE Anybody can talk to the server Most common TLS mode Secure channel server/client or adv/server

authentication + password-based authentication in secure

10 AKE WITH MUTUAL AUTHENTICATION Ø Sometimes server-client, mostly peer-to-peer Can also be achieved by unilateral authentication + password-based authentication in secure channel [KMO +15] Client and server confirm partner s identities

11 AKE SECURITY PROPERTIES (UNILATERAL) Ø Key Secrecy [BR93], [BPR00], [CK01] : Adversary s goal: distinguishing the keys of an honest, fresh session from random keys of same length Rules of game: adaptive party corruptions, keyreveal, concurrent sessions and interactions Symmetric Key Restriction: no terminal corruptions! Ø Client-impersonation resistance Adversary s goal: impersonate client in fresh authentication session Rules of game: adaptive party corruptions, keyreveal, concurrent sessions and interactions, no relays!

12 TERMINAL IMPERSONATION Ø Terminal-impersonation resistance Adversary s goal: impersonate terminal in fresh authentication session Rules of game: adaptive party corruptions, keyreveal, concurrent sessions and interactions, no relays! Ø The eternal debate: first or second Should terminal authenticate first or second? VANET, MANET, RFID authentication: terminal first When optional, usually terminal second

13 PRIVACY IN AUTHENTICATION DrawClient Corrupt Ø Key Secrecy [JW00], [Vau07], [HPV+12] : Adversary s goal: find input bit to DrawProver Rules of game: DrawClient always takes same input bit, can corrupt*, interact, etc.

14 PRIVACY NOTIONS DrawClient Corrupt Ø Weak : no corruptions Ø Forward : once A corrupts, only corruptions (find past LoR connection) Ø Strong : no restrictions Ø Narrow/wide: know result of honest sessions

15 IMPOSSIBILITY RESULTS [Vau07]: Strong Privacy requires Key- Agreement [PV08]: Wide-Forward privacy with symmetric keys is impossible if all state is revealed*

16 PART III THE AKA PROTOCOL

17 PART III. 1 IDENTIFIERS & SECRETS

18 ELEGANT SYMMETRIC (A)KE [BR93] Ø Usual case for AKE: 2 parties, e.g. client/server Ø Share symmetric secret key sk Ø Sometimes public identifier UID Ø Elegant KE: use PRF keyed with sk AKE? No problem, use another PRF and switch! n S UID UID, n C UID Keys PRF sk ( n C, n S )

19 THE CASE OF 3G/4G/5G Ø Usual case for AKE: 2 parties, e.g. client/server Ø In 3G/4G/5G networks, 3 parties: Client: registering with (only one) operator client key and operator key stored* in SIM Operator: has list of clients, whose data he knows Local terminal: not always operator (think of roaming) can authenticate/communicate with client must not know keys

20 THE CASE OF 3G/4G/5G (CONTD.) Ø Some more restrictions: Connection Terminal Operator is expensive! Assumed to take place on secure channel Whenever PKI is used, in practice this means storing PKs and certificates in the phone No PKI for Terminals (too many of them)

21 1001 IDENTIFIERS Ø Client associated with secret keys: sk C, sk OP, st C All clients of the same operator share same sk OP Ø Other identifiers: Operator associates C with unique UID (permanent) Each terminal T i associates C with 4B TID (temporary), unique per terminal, updated per session sk C UID ntid TID TID UID AKA ntid TID UID sk O P

22 1001 IDENTIFIERS (CONTD.) Ø Each terminal has noncolliding list of TIDs Inter-terminal collisions possible No centralized DB of all TIDs Ø Each terminal is associa-ted with unique LAI Like ZIP code (TID, LAI) unique

23 1001 IDENTIFIERS (SUMMARY) Ø Multiple clients of same Operator LAI UID UID UID UID

24 1001 IDENTIFIERS (SUMMARY) Ø Multiple clients of same Operator LAI UID LAI UID UID UID

25 1001 IDENTIFIERS (SUMMARY) Ø TID and UID in protocol run, same LAI LAI TID, LAI UID TID, LAI Find TID UID UID UID AKA AKA UID ntid, LAI ntid TID

26 Possible (not likely) ntid=tid 1001 IDENTIFIERS (SUMMARY) Ø TID and UID in protocol run, different LAI TID, LAI LAI TID UID UID TID, LAI TID, LAI AKA LAI UID AKA UID UID ntid, LAI ntid

27 SECRET KEYS, SECRET STATE Ø Client associated with secret keys: sk C, sk OP, st C All clients of the same operator share same sk OP Ø State st C is a sequence number Terminal also has a state st OP C w.r.t. that client Used as shared randomness for authentication Initially randomly chosen for each client Then updated by update function (3 possibilities) Unlike sk OP, sk C, Terminals may know st C

28 PART III. 2 UNDERLYING CRYPTOGRAPHY

29 CRYPTOGRAPHIC FUNCTIONS Ø The seven dwarfs: F 1 : used by terminal, for terminal authentication F 1 input : used ( sk C by client, sk OP in, R, special Sqn OP C procedure, AMF) input ( sk C, sk OP, R, Sqn OP C, AMF) F 2 : used by client, for client authentication input ( sk C, sk OP, R) F 3, F 4 : used by both for session-key generation F 5 : used input by ( sk C terminal, sk OP for, R) blinding key input ( sk C, sk OP, R) F 5 : used by client for blinding key, special procedure input ( sk C, sk OP, R)

30 MILENAGE F 1 F 1 F 5 F 2 F 3 F 4 F 5

31 TUAK F 2 F 3 F 4 F 5, F 5

32 WHAT WE PROVED FOR TUAK Ø Single function G generalizing the seven functions TUAK: G TUAK is PRF assuming that the internal permutation of Keccak is PRF Stronger than each function is PRF! Ø Intuition of G TUAK : use handy truncation of output

33 WHAT WE PROVED FOR MILENAGE Ø Single function G generalizing the seven functions Becomes 2 functions never used together in same call MILENAGE: G MIL, G MIL are PRF assuming that the AES permutation is PRF Ø Intuition of G MILENAGE : use handy XOR-ing in all the right places

34 PART III. 3 THE PROTOCOL

35 AKA STRUCTURE (BASIC) LAI st C Check TAuth Initial Identificatio n Terminal Authenticatio n Get UID Handshak e AKA UID, st OP C st OP C Check: d( st C, Client st OP C ) δ Authenticatio Resynch n Procedure Process Notify OK Update st C Update st OP C

36 AKA STRUCTURE (REAL) LAI Update st C Update st C Initial Identificatio n AKA UID, st OP C Get UID AKA UID, Update[st OP C ] Handshakes AKA UID, st OP C AKA UID, Update[st OP C ] AKA UID, Update N [st OP C ] OK Update[ st OP C ] st OP C Update st OP C

37 INITIAL IDENTIFICATION LAI ID Request (TID, LAI ) UID Request Get UID UID Fundamental privacy flaw: UID easily obtainable! Security: even if UID replaced, still OK (authenreplaced, still OK (authentication automatically fails)

38 HANDSHAKE PREPARATION (1 BATCH) LAI UID Set Sqn=Update[ st OP C ] Generate R at random. Reveals Sqn R and everything Compute: MAC OP = F 1 ( sk C, sk OP, R, Sqn, AMF) MAC C = F 2 ( sk C, sk OP, R) AK= F 5 ( sk C, sk OP, R) Autn=(Sqn XOR AK) AMF MAC OP CK= F 3 ( sk C, sk OP, R) IK= F 4 ( sk C, sk OP, R)

39 TERMINAL/CLIENT AKE LAI Compute: AK= F 5 ( sk C, sk OP, R) Retrieve Sqn and check MAC OP R (Sqn XOR AK) AMF MAC OP If Sqn { st C,, st C +δ} Compute: Rsp= F 2 ( sk C, sk OP, R) CK= F 3 ( sk C, sk OP, R) IK= F 4 ( sk C, sk OP, R) Else Resynch! Rsp Check Rsp= MAC C

40 RESYNCH PROCEDURE LAI If MAC OP verifies, but Sqn out of range Compute: AK = F 5 ( sk C, sk OP, R) MAC C = F 1 ( sk C, sk OP, st C, AMF, R) ( st C XOR AK ) MAC C Compute: AK, get st C Check: out of range Check: MAC C Set st OP C = st C Start from there.

41 PART IV SECURITY OF AKA

42 CLEANER ABSTRACTION

43 SECURITY PROPERTIES Key Secrecy: Attained under assumption of pseudorandomness of G Advantage is linear in number of clients! Client Impersonation: Attained under assumption of pseudorandomness of G Advantage is linear in N C / 2 MAC C and N C / 2 sk C

44 OFFLINE RELAYS LAI Initial Identificatio n R (Sqn XOR AK) AMF MAC OP Get UID Initial Identificatio n R (Sqn XOR AK)

45 TERMINAL-IMPERSONATION RESISTANCE Ø Attained as long as there are no offline relays Thus weaker than Client Impersonation guarantee Terminal Impersonation: Attained under assump-tion of pseudorandomness of G Advantage is linear in N C / 2 MAC C and N C / 2 sk C

46 PART V LACK OF PRIVACY & IMPOSSIBILITIES

47 TRUTH OR DARE Ø 3 GPP claim AKA is: ID-Hiding nobody can identify client Location-hiding nobody can trace client location Untraceable nobody can link client sessions Ø Their arguments: Nobody knows UID and normally it is not used Sequence number and keys are hidden in transcripts Ø We PROVE AKA is: NOT ID-Hiding very easy to recover UID Location-hiding not really NOT Untraceable see some attacks next slide

48 DISTINGUISHING BY TERMINAL IMPERSONATION LAI st C Initial Identificatio n R (Sqn XOR AK) AMF MAC OP Get UID DrawClient Initial Identificatio n R (Sqn XOR AK) AMF MAC OP

49 DISTINGUISHING BY RESYNCHRONIZATION LAI Repeat δ times st C Initial Identificatio Get UID n Update Sqn R (Sqn XOR AK) AMF MAC OP Resynch! Clien t DrawClient Initial Identificatio n R (Sqn XOR AK) AMF MAC OP Get UID LAI Update Sqn

50 THE BIG IMPOSSIBILITY Ø Goal: make this protocol forward-private Trivial solution: just build a new protocol How do we do it without changing it too much? Ø The past kills your future In the AKA protocol the client is always one step behind the terminal/operator in state. Client corruption at time t is enough to identify client in (t 1)st transcript Generalizable attack: problem is that 3GPP do not want the client to choose anything But we can fix the protocol to get weak privacy

51 PART VI CONCLUSIONS

52 AKE PROTOCOLS Ø Authenticated Key Exchange Goal: construct a secure channel between two parties 2 steps: Handshake: derive keys for authenticated encryption Use the keys to encrypt and sign your communication Ø Examples: TLS/SSL, AKA Ø Authentication: Unilateral : only one party authenticates the keys Mutual: both parties authenticate the keys

53 THEORY VS. PRACTICE & AKA Ø AKA: symmetric-key AKE protocol with mutual authentication Ø 1001 identifiers, all more or less secret, some temporary and some not Ø 2 algorithm suites: Milenage: based on AES TUAK: based on Keccak Ø Security: Key Secrecy, Client Impersonation & some terminal impersonation security Ø Privacy: many attacks, impossible to really fix for stronger privacy notions

Part II Bellare-Rogaway Model (Active Adversaries)

Part II Bellare-Rogaway Model (Active Adversaries) 8th BIU Winter School on Key Exchange, 2018 Marc Fischlin 13. Oktober 2010 Dr.Marc Fischlin Kryptosicherheit 1 Active Attacks Adversary may tamper, drop,