S ECURITY & P RIVACY IN 3G/4G/ 5G NETWORKS : T HE AKA P ROTOCOL W - PowerPoint PPT Presentation

S ECURITY & P RIVACY IN 3G/4G/ 5G NETWORKS : T HE AKA P ROTOCOL W ITH S.A LT , P.-A. F OUQUE , G. M ACARIO -R AT , B. R ICHARD

M E , 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)

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 Design & Models & Attacks Proofs Building blocks Attacks on Cryptanalysis Implementation Real-World ES s

W HAT I D O Ø 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)

W HAT I D O (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]

T HIS T ALK Ø Authenticated Key Exchange Elegant § Unilateral/Mutual Authentication § Desired Properties § Privacy in Authentication Ø The AKA Protocol § Description § Security (intuition) Ø AKA and Privacy Ugly § The case of the Hopeless Task

P ART II A UTHENTICATED K EY E XCHANGE

A UTHENTICATED K EY -E XCHANGE Ø Allows two parties to communicate securely § Peer-to-Peer or Server-Client § Examples: TLS/SSL (https://) Ø Two steps: § Compute session-specific keys (handshake) § Use keys for secure communication (symmetric AE)

AKE WITH U NILATERAL A UTHENTICATION Ø Usually the case for Server-Client AKE § “Anybody” can talk to the server § Most common TLS mode Secure channel server/client or adv/server

AKE WITH M UTUAL A UTHENTICATION Ø 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

AKE S ECURITY P ROPERTIES (U NILATERAL ) Ø 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, key- reveal, 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, key- reveal, concurrent sessions and interactions, no relays!

T ERMINAL I MPERSONATION Ø Terminal-impersonation resistance § Adversary’s goal : impersonate terminal in fresh authentication session § Rules of game : adaptive party corruptions, key- reveal, 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

P RIVACY IN A UTHENTICATION 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.

P RIVACY N OTIONS 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

I MPOSSIBILITY R ESULTS [Vau07]: Strong Privacy requires Key- Agreement [PV08]: Wide-Forward privacy with symmetric keys is impossible if all state is revealed*

P ART III T HE AKA P ROTOCOL

P ART III. 1 I DENTIFIERS & S ECRETS

E LEGANT S YMMETRIC (A)KE [BR93] Ø Usual case for AKE: 2 parties, e.g. client/server Ø Share symmetric secret key 𝑡𝑙 Ø Sometimes public identifier 𝑉𝐽𝐸 Ø Elegant KE: use PRF keyed with 𝑡𝑙 AKE? No problem, use another PRF and switch! ​𝑜↓𝑇 𝑉𝐽𝐸 , ¡ ​𝑜↓𝐷 𝑉𝐽𝐸 𝑉𝐽𝐸 𝐿𝑓𝑧𝑡 ¡ ¡≔ ​𝑄𝑆𝐺↓𝑡𝑙 ( ​𝑜↓𝐷 , ¡ ​ 𝑜↓𝑇 )

T HE 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

T HE 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)

1001 I DENTIFIERS Ø Client associated with secret keys: ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ ​ 𝑡𝑢↓𝐷 § All clients of the same operator share same ​𝑡𝑙↓𝑃𝑄 Ø Other identifiers: § Operator associates ¡ 𝐷 with unique 𝑉𝐽𝐸 (permanent) § Each terminal ​𝑈↓𝑗 associates 𝐷 with 4B 𝑈𝐽𝐸 (temporary), unique per terminal, updated per session ​𝑡𝑙↓𝐷 𝑈𝐽𝐸 𝑉𝐽𝐸 ​ 𝐵𝐿𝐵 𝑡𝑙↓𝑃 𝑄 𝑜𝑈𝐽𝐸 𝑉𝐽𝐸 𝑈𝐽𝐸 𝑉𝐽𝐸 𝑈𝐽𝐸 𝑜𝑈𝐽𝐸

1001 I DENTIFIERS ( CONTD .) Ø Each terminal has non- colliding list of 𝑈𝐽𝐸 s § Inter-terminal collisions possible § No “centralized” DB of all 𝑈𝐽𝐸 s Ø Each terminal is associa-ted with unique 𝑀𝐵𝐽 § Like ZIP code § ( 𝑈𝐽𝐸 , 𝑀𝐵𝐽 ) unique

1001 I DENTIFIERS ( SUMMARY ) Ø Multiple clients of same Operator 𝑀𝐵𝐽 𝑉𝐽𝐸 𝑉𝐽𝐸 ​ 𝑉𝐽𝐸↑ ∗ ​ 𝑉𝐽𝐸↑ ∗

1001 I DENTIFIERS ( SUMMARY ) Ø Multiple clients of same Operator 𝑀𝐵𝐽 𝑉𝐽𝐸 𝑉𝐽𝐸 ​ ​𝑀𝐵𝐽↑ ∗ 𝑉𝐽𝐸↑ ∗ ​ 𝑉𝐽𝐸↑ ∗

1001 I DENTIFIERS ( SUMMARY ) Ø 𝑈𝐽𝐸 and 𝑉𝐽𝐸 in protocol run, same 𝑀𝐵𝐽 𝑀𝐵𝐽 𝑈𝐽𝐸 , 𝑀𝐵𝐽 𝑉𝐽𝐸 𝑉𝐽𝐸 Find 𝑉𝐽𝐸 𝑈𝐽𝐸 , 𝑀𝐵𝐽 𝑈𝐽𝐸 ↔ 𝑉𝐽𝐸 ​𝐵𝐿𝐵↓𝑉𝐽𝐸 𝐵𝐿𝐵 𝑜𝑈𝐽𝐸 , 𝑀𝐵𝐽 𝑜𝑈𝐽𝐸 ≠ 𝑈𝐽𝐸

1001 I DENTIFIERS ( SUMMARY ) Ø 𝑈𝐽𝐸 and 𝑉𝐽𝐸 in protocol run, different 𝑀𝐵𝐽 𝑈𝐽𝐸 , ​𝑀𝐵𝐽↑ ∗ ​𝑀𝐵𝐽↑ ∗ 𝑈𝐽𝐸 𝑉𝐽𝐸 𝑀𝐵𝐽 𝑈𝐽𝐸 , ​ 𝑀𝐵𝐽↑ ∗ 𝑉𝐽𝐸 𝑉𝐽𝐸 𝑉𝐽𝐸 𝑈𝐽𝐸 , ​𝑀𝐵𝐽↑ ∗ ​𝐵𝐿𝐵↓𝑉𝐽𝐸 𝐵𝐿𝐵 𝑜𝑈𝐽𝐸 , 𝑀𝐵𝐽 𝑜𝑈𝐽𝐸 Possible (not likely) 𝑼𝑱𝑬 𝒐𝑼 𝒐𝑼𝑱𝑬 = 𝑼𝑱𝑬

S ECRET K EYS , S ECRET S TATE Ø Client associated with secret keys: ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ ​ 𝑡𝑢↓𝐷 § All clients of the same operator share same ​𝑡𝑙↓𝑃𝑄 Ø State ¡ ​𝑡𝑢↓𝐷 is a sequence number § Terminal also has a state ​𝑡𝑢↓𝑃𝑄↑𝐷 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 ​𝑡𝑙↓𝑃𝑄 , ¡ ​𝑡𝑙↓𝐷 , Terminals may know ​𝑡𝑢↓𝐷

P ART III. 2 U NDERLYING C RYPTOGRAPHY

C RYPTOGRAPHIC F UNCTIONS Ø The seven dwarfs: ​𝐺↓ 1 : used by terminal, for terminal authentication input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 , ¡ ​𝑇𝑟𝑜↓𝑃𝑄↑𝐷 , ¡ 𝐵𝑁𝐺 ) ​𝐺↓ 1 ↑ ∗ : used by client in special procedure input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 , ¡ ​𝑇𝑟𝑜↓𝑃𝑄↑𝐷 , ¡ 𝐵𝑁𝐺 ) ​𝐺↓ 2 : used by client, for client authentication input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 ) ​𝐺↓ 3 , ¡ ​𝐺↓ 4 : used by both for session-key generation input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 ) ​𝐺↓ 5 : used by terminal for “blinding” key input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 ) ​𝐺↓ 5 ↑ ∗ : used by client for “blinding” key, special procedure input ( ​𝑡𝑙↓𝐷 , ¡ ​𝑡𝑙↓𝑃𝑄 , ¡ 𝑆 )

M ILENAGE ​𝐺↓ 1 ¡ ¡ ¡ ​ ​𝐺↓ 3 ​𝐺↓ 4 ​𝐺↓ 5 ¡ ¡ ¡ ​ ​ 𝐺↓ 1 ↑ 𝐺↓ 2 𝐺↓ 5 ↑ ∗ ∗