Model Checking 5G Security David Basin ETH Zurich Real World Crypto - PowerPoint PPT Presentation

Model Checking 5G Security David Basin ETH Zurich Real World Crypto January 2020

Thanks Tamarin Team Simon Meier Benedikt Schmidt Cas Cremers Ralf Sasse Jannik Dreier 5G (verified using Tamarin) Ralf Sasse Jannik Dreier Sasa Radomirovic Lucca Hirschi Vincent Stettler 2

A Typical Protocol IKE, Phase 1, Main Mode, Digital Signatures, Simplified (1) I → R : C I , ISA I Properties? (2) R → I : C I , C R , ISA R C I , C R , g x , N I (3) I → R : C I , C R , g y , N R (4) R → I : (5) I → R : C I , C R , { ID I , SIG I } SKEYID e (6) R → I : C I , C R , { ID R , SIG R } SKEYID e h( { N I , N R } , g xy ) SKEYID = h is keyed hash h(SKEYID , { g xy , C I , C R , 0 } ) SKEYID d = deriving key Does argument h(SKEYID , { SKEYID d , g xy , C I , C R , 1 } ) SKEYID a = authentication key order matter? h(SKEYID , { SKEYID a , g xy , C I , C R , 2 } ) SKEYID e = encryption key h(SKEYID a , { g x , g y , C I , C R , ISA I , ID I } ) HASH I = h(SKEYID a , { g y , g x , C R , C I , ISA R , ID R } ) HASH R = SIG I = { HASH I } K − 1 I Why all the nested SIG R = { HASH R } K − 1 R keyed hashes? 3

Protocol Design as an Art Best practices, design by committee, reuse of previous protocols, ... Whenever I made a roast, I always started o ff by cutting o ff the ends, just like my grandmother did. Someone once asked me why I did it, and I realized I had no idea. It had never occurred to me to wonder. It was just the way it was done. Eventually I asked my grandmother. “Why do you always cut o ff the ends of a roast?” She answered “Because my pan is small and otherwise the roasts would not fit.” — Anonymous 4

Protocol Design as a Science S cience in the root sense The discovery and knowledge of something that can be 
 demonstrated and verified within a community Formal methods as a way to better protocols • Precise specification of system, environment, properties • Tool support to debug, verify, and explore alternatives Progress is being made applying tools to protocols that matter • ISO/IEC 9798 , 5G , TLS 1.3, … • Companies are (slowly) becoming tool users 5

Where is the Di ffi culty? How does the What shall system operate? be achieved? Proof Security System Properties Specification satisfies And in what 
 Does the system meet environment? its requirements • Properties implicit 
 • D esign documents are • Undecidability or imprecise. 
 incomplete and imprecise • Even restricted E.g. “authenticate” • Unclear adversary model cases intractable 6

Weapon of Choice Theorem Prover Constraint solver Tamarin prover 7

Tamarin Prover Tamarin prover Solution exists: constraint ATTACK Property P from (not P) Dedicated constraint solver No solution constraints System S exists: PROOF from S Run out of time or memory Provide hints for the prover Interactive mode (e.g. invariants) Inspect partial proof 8

Specifying Protocols with Multiset Rewrite Rules LHS --[ actions ]-> RHS [ In( K ), premises (LHS) State( ThreadID, `step1’ ) ] actions --[ Accepted( ThreadID, K) ]-> [ Out( `ack` ), conclusions (RHS) State( ThreadID, `step2’, K ) ] Gives rise to a transition system with a trace semantics Accepted(tid3,key) {Out(`ack’), 
 … {In(key), 
 … State(tid3,`step2’,key), 
 State(tid3,`step1’), 
 …} …} 9

Specifying Protocols Example: client state machine Rules correspond to edges 10

Specifying Adversary Capabilities Example of “Session Reveal” [ State( ThreadID, … , Key ) ] --[ SessionKeyReveal( ThreadID, Key ) ]-> [ Out( Key ) ] Similar to oracles in computational model 11

Specifying Properties Guarded fragment of first order logic with timepoints lemma my_secret_key: “Forall tid key #i. Accepted( tid, key )@i => ( not Ex #j. K(key)@j ) ” Interpreted over traces Accepted(tid3,key) {Out(`ack’), 
 … {In(key), 
 State(tid3,`step2’,key), 
 State(tid3,`step1’), 
 …} …} 12

Does Protocol Satisfy Property? Or can the adversary attack it? ?

Modeling and Analyzing 5G New standard for mobile communication, standardized by 3GPP • Release 15 (5G Phase 1) adopted June 14, 2018 Worldwide commercial service in 2020 • 5 billion mobile subscribers in 2016 • 60% of world population has 4G access Numerous protocols including Authentication and Key Agreement (AKA) 
 D.B., Dreier, Hirschi, Radomirovic, Sasse, Stettler, 
 A Formal Analysis of 5G Authentication, CCS 2018. 14


 
 
 
 Authentication and Key Agreement Protocol to authenticate a user’s equipment and a serving network and establish shared session keys between them. 
 Subscriber Serving Network Home Network Phone (UE), USIM Base station (antenna) Subscriber’s carrier USIM and Home Network share: • Symmetric key K • Permanent identifier SUPI (Subscriber Permanent Identifier) 
 used later to derive a SUCI (Subscriber Concealed Identifier) • Sequence number SQN • Home Network’s public key pkH N 
 15

5G Initialization Subscriber sends his permanent identifier SUPI encrypted with 
 Home Network’s public key: SUCI = h aenc( h SUPI , R s i , pk HN ) , idHN i Serving Network Subscriber Home Network K , SUPI , K , SUPI , SNname SQN UE , SNname SQN HN Serving Network has initiated an authentication with the UE SUCI , SNname SUCI Get SUPI from SUCI Choose authentication method 16

AKA Protocol (Successful Authentication Case) Serving Network Subscriber Home Network K , SUPI , K , SUPI , SNname , SUCI SQN UE , SNname SQN HN , SNname new random R Challenge MAC f1 ( K , h SQN HN , R i ) AK f5 ( K , R ) CONC SQN HN � AK Fresh & authentic AUTN h CONC , MAC i xRES ⇤ Challenge ( K , R , SNname ) Expected response for SN HXRES ⇤ SHA256 ( h R , xRES ⇤ i ) Seed for key to be established K SEAF KeySeed ( K , R , SQN HN , SNname ) SQN HN SQN HN + 1 between Subscriber and SN R , AUTN , HXRES ⇤ , K SEAF R , AUTN Store key seed and response 
 h xCONC , xMAC i AUTN Forwards challenge and authentication information AK f5 ( K , R ) xSQN HN AK � xCONC MAC f1 ( K , h xSQN HN , R i ) Checks authenticity CHECK ( i ) xMAC = MAC and ( ii ) SQN UE < xSQN HN and freshness If ( i ) and ( ii ) (Expected Response) Computes authenticated response SQN UE xSQN HN RES ⇤ Challenge ( K , R , SNname ) and key seed K SEAF KeySeed ( K , R , x SQN HN , SNname ) RES ⇤ Confirm successful authentication if SHA256 ( h R , RES ⇤ i ) , HXRES ⇤ then abort RES ⇤ , SUCI if RES ⇤ , XRES ⇤ then abort SUPI Send Subscriber’s SUPI 17 Figure 3: The 5G AKA protocol (continuing Figure 2)

AKA Protocol (Failure Cases) Serving Network Subscriber Home Network K , SUPI , K , SUPI , SNname , SUCI SQN UE , SNname SQN HN , SNname MAC correct but xSQN of HN If ( i ) and ¬ ( ii ) (Synchronization Failure) too small (replay!) MACS f1 ∗ ( K , h SQN UE , R i ) Resync: Send UE’s SQN AK ∗ f5 ∗ ( K , R ) CONC ∗ SQN UE � AK ∗ concealed with private value AUTS h CONC ∗ , MAC ∗ i ’Sync Failure’ , AUTS ’Sync Failure’ , AUTS , R , SUCI Resynchronize SQN if CHECK ( i ) holds for MACS in AUTS then SQN HN SQN UE + 1 If ¬ ( i ) (MAC Failure) ’Mac Failure’ 18

So is Protocol Secure? Is home network talking to subscriber or an imposter? Privacy? Is subscriber traceable and by whom? Verification extremely challenging • Stateful protocol : sequence numbers and 14 possible protocol states • Use of XOR (a non-convergent theory) • Privacy requirements are equivalence properties • Unbounded number of sessions ⇒ Uses recent Tamarin extensions • Support for observational equivalence (for privacy) and XOR 19

Formal Analysis of AKA in Tamarin Formalized draft v1.0.0 of Release 15 from March 2018 • Followed standardization for ca. 1 year (part time) Extracted the protocol specification and security goals 
 from 3GPP Technical Specification • 722 pages over 4 documents Tamarin model: ~500 lines Specification of desired goals + lemmas for termination: ~1000 lines, 124 lemmas Identified minimal set of trust assumptions for each property • I.e., strongest possible adversary model Computation time: 5+ hours (also using “oracle” support) 20

Results: Authentication Standard specifies surprisingly few and weak authentication goals Agreement of Subscribers/SNs on session key K SEAF is not required and fails RES ∗ , SUCI • Last message of Home Network to Serving Network 
 if RES ∗ 6 = XRES ∗ then abort not bound to specific session SUPI Send Subscriber’s SUPI • Can result in session keys being associated to wrong SUPI 
 Could result in billing wrong subscriber for services! • Earlier draft of standard (0.7.1) did not have this flaw Standard only aims at implicit authentication, whereas many security goals require key confirmation • Potential for errors in subsequent protocols • Complicates security analysis • We proposed and verified two improvements 21