SLIDE 1
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 - - 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
SLIDE 2
SLIDE 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 Design & Attacks Building blocks Attacks on Implementation s Cryptanalysis Real-World ES
SLIDE 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)
SLIDE 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]
SLIDE 6
THIS TALK
Ø Authenticated Key Exchange § Unilateral/Mutual Authentication § Desired Properties § Privacy in Authentication Ø The AKA Protocol § Description § Security (intuition) Ø AKA and Privacy § The case of the Hopeless Task
Elegant Ugly
SLIDE 7
PART II AUTHENTICATED KEY EXCHANGE
SLIDE 8
AUTHENTICATED KEY-EXCHANGE
Ø 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)
SLIDE 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
SLIDE 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
SLIDE 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, key-
reveal, concurrent sessions and interactions
Ø 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!
Symmetric Key Restriction: no terminal corruptions!
SLIDE 12
TERMINAL IMPERSONATION
Ø 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
SLIDE 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.
SLIDE 14
PRIVACY NOTIONS
Ø Weak : no corruptions Ø Forward : once A corrupts, only corruptions (find
past LoR connection)
Ø Strong : no restrictions Ø Narrow/wide: know result of honest sessions
DrawClient ¡ Corrupt ¡
SLIDE 15
IMPOSSIBILITY RESULTS
[Vau07]: Strong Privacy requires Key- Agreement [PV08]: Wide-Forward privacy with symmetric keys is impossible if all state is revealed*
SLIDE 16
PART III THE AKA PROTOCOL
SLIDE 17
PART III. 1 IDENTIFIERS & SECRETS
SLIDE 18
ELEGANT SYMMETRIC (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!
SLIDE 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 § Operator: has list of clients, whose data he knows
client key and operator key stored* in SIM
§ Local terminal: not always operator (think of
roaming) can authenticate/communicate with client must not know keys
SLIDE 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)
SLIDE 21
1001 IDENTIFIERS
Ø 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
𝑉𝐽𝐸 𝑉𝐽𝐸 𝑉𝐽𝐸 𝐵𝐿𝐵 𝑈𝐽𝐸 𝑈𝐽𝐸 𝑈𝐽𝐸 𝑜𝑈𝐽𝐸 𝑜𝑈𝐽𝐸 𝑡𝑙↓𝐷 𝑡𝑙↓𝑃 𝑄
SLIDE 22
1001 IDENTIFIERS (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
SLIDE 23
1001 IDENTIFIERS (SUMMARY)
𝑉𝐽𝐸 𝑉𝐽𝐸
Ø Multiple clients of same Operator
𝑀𝐵𝐽 𝑉𝐽𝐸↑ ∗ 𝑉𝐽𝐸↑ ∗
SLIDE 24
1001 IDENTIFIERS (SUMMARY)
𝑉𝐽𝐸 𝑉𝐽𝐸
Ø Multiple clients of same Operator
𝑀𝐵𝐽 𝑉𝐽𝐸↑ ∗ 𝑉𝐽𝐸↑ ∗ 𝑀𝐵𝐽↑∗
SLIDE 25
1001 IDENTIFIERS (SUMMARY)
𝑉𝐽𝐸 𝑉𝐽𝐸 𝐵𝐿𝐵 𝑜𝑈𝐽𝐸≠𝑈𝐽𝐸 𝑈𝐽𝐸, 𝑀𝐵𝐽 𝑈𝐽𝐸, 𝑀𝐵𝐽
Ø 𝑈𝐽𝐸 and 𝑉𝐽𝐸 in protocol run, same 𝑀𝐵𝐽
𝑜𝑈𝐽𝐸, 𝑀𝐵𝐽 𝑀𝐵𝐽 𝑈𝐽𝐸↔𝑉𝐽𝐸 Find 𝑉𝐽𝐸 𝐵𝐿𝐵↓𝑉𝐽𝐸
SLIDE 26
1001 IDENTIFIERS (SUMMARY)
𝑉𝐽𝐸 𝑉𝐽𝐸 𝐵𝐿𝐵 𝑜𝑈𝐽𝐸 𝑈𝐽𝐸, 𝑀𝐵𝐽↑∗ 𝑈𝐽𝐸, 𝑀𝐵𝐽↑∗
Ø 𝑈𝐽𝐸 and 𝑉𝐽𝐸 in protocol run, different 𝑀𝐵𝐽
𝑜𝑈𝐽𝐸, 𝑀𝐵𝐽 𝑀𝐵𝐽 𝑉𝐽𝐸 𝐵𝐿𝐵↓𝑉𝐽𝐸 𝑀𝐵𝐽↑∗ 𝑈𝐽𝐸 𝑉𝐽𝐸 𝑈𝐽𝐸, 𝑀𝐵𝐽↑∗ Possible (not likely) 𝒐𝑼 𝒐𝑼𝑱𝑬=𝑼𝑱𝑬 𝑼𝑱𝑬
SLIDE 27
SECRET KEYS, SECRET STATE
Ø Client associated with secret keys: 𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡
𝑡𝑢↓𝐷
§ All clients of the same operator share same 𝑡𝑙↓𝑃𝑄 Ø State ¡𝑡𝑢↓𝐷 is a sequence number § Used as “shared” randomness for authentication § Initially randomly chosen for each client § Then updated by update function (3 possibilities) § Unlike 𝑡𝑙↓𝑃𝑄 , ¡𝑡𝑙↓𝐷 , Terminals may know 𝑡𝑢↓𝐷 § Terminal also has a state 𝑡𝑢↓𝑃𝑄↑𝐷 w.r.t. that client
SLIDE 28
PART III. 2 UNDERLYING CRYPTOGRAPHY
SLIDE 29
CRYPTOGRAPHIC FUNCTIONS
Ø The seven dwarfs:
𝐺↓1 : used by terminal, for terminal
authentication input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆, ¡𝑇𝑟𝑜↓𝑃𝑄↑𝐷 , ¡𝐵𝑁𝐺)
𝐺↓2 : used by client, for client authentication
input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆)
𝐺↓3 , ¡𝐺↓4 : used by both for session-key
generation input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆)
𝐺↓1↑∗ : used by client in special procedure
input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆, ¡𝑇𝑟𝑜↓𝑃𝑄↑𝐷 , ¡𝐵𝑁𝐺)
𝐺↓5 : used by terminal for “blinding” key
input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆)
𝐺↓5↑∗ : used by client for “blinding” key, special
procedure input (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆)
SLIDE 30
MILENAGE
𝐺↓1 ¡ ¡ ¡ 𝐺↓1↑ ∗ 𝐺↓5 ¡ ¡ ¡ 𝐺↓2 𝐺↓3 𝐺↓4 𝐺↓5↑ ∗
SLIDE 31
TUAK
𝐺↓3 𝐺↓4 𝐺↓2 𝐺↓5 , 𝐺↓5↑ ∗
SLIDE 32
WHAT WE PROVED FOR TUAK
Ø Single function 𝐻 generalizing the seven
functions TUAK: 𝐻↓𝑈𝑉𝐵𝐿 is PRF assuming that the internal permutation of Keccak is PRF Stronger than “each function is PRF”!
Ø Intuition of 𝐻↓𝑈𝑉𝐵𝐿 : use handy truncation of
- utput
SLIDE 33
WHAT WE PROVED FOR MILENAGE
Ø Single function 𝐻 generalizing the seven
functions
§ Becomes 2 functions never used together in same call
MILENAGE: 𝐻↓𝑁𝐽𝑀 , ¡𝐻′↓𝑁𝐽𝑀 are PRF assuming that the AES permutation is PRF
Ø Intuition of 𝐻↓𝑁𝐽𝑀𝐹𝑂𝐵𝐻𝐹 : use handy XOR-ing in
all the right places
SLIDE 34
PART III. 3 THE PROTOCOL
SLIDE 35
AKA STRUCTURE (BASIC)
𝑀𝐵𝐽 Initial Identificatio n Handshak e 𝐵𝐿𝐵↓𝑉𝐽𝐸, 𝑡𝑢↓𝑃𝑄↑𝐷 Get 𝑉𝐽𝐸 Terminal Authenticatio n Client Authenticatio n 𝑡𝑢↓𝐷 𝑡𝑢↓𝑃𝑄↑𝐷 Check TAuth Resynch Procedure Update 𝑡𝑢↓𝐷 Update 𝑡𝑢↓𝑃𝑄↑𝐷 Notify OK Process Check: d(𝑡𝑢↓𝐷 , ¡ 𝑡𝑢↓𝑃𝑄↑𝐷 )≤ ¡𝜀
SLIDE 36
AKA STRUCTURE (REAL)
𝑀𝐵𝐽 Initial Identificatio n Handshakes 𝐵𝐿𝐵↓𝑉𝐽𝐸,𝑡𝑢↓𝑃𝑄↑𝐷 𝐵𝐿𝐵↓𝑉𝐽𝐸, ¡ 𝑉𝑞𝑒𝑏𝑢𝑓[𝑡𝑢↓𝑃𝑄↑𝐷 ] … 𝐵𝐿𝐵↓𝑉𝐽𝐸, ¡𝑉𝑞𝑒𝑏𝑢𝑓↑𝑂 [𝑡𝑢↓𝑃𝑄↑𝐷 ] Get 𝑉𝐽𝐸 𝑡𝑢↓𝑃𝑄↑𝐷 Update 𝑡𝑢↓𝑃𝑄↑𝐷 OK 𝑉𝑞𝑒𝑏𝑢𝑓[ 𝑡𝑢↓𝑃𝑄↑𝐷 ] 𝐵𝐿𝐵↓𝑉𝐽𝐸, 𝑡𝑢↓𝑃𝑄↑𝐷 𝐵𝐿𝐵↓𝑉𝐽𝐸, ¡𝑉𝑞𝑒𝑏𝑢𝑓[𝑡𝑢↓𝑃𝑄↑𝐷 ] Update 𝑡𝑢↓𝐷 Update 𝑡𝑢↓𝐷
SLIDE 37
INITIAL IDENTIFICATION
𝑀𝐵𝐽 ID Request (𝑈𝐽𝐸, ¡𝑀𝐵𝐽↑∗ ) Get 𝑉𝐽𝐸 𝑉𝐽𝐸 𝑉𝐽𝐸 Request
Fundamental privacy flaw: 𝑉𝐽𝐸 easily obtainable! easily obtainable! Security: even if 𝑉𝐽𝐸 replaced, still OK (authen- replaced, still OK (authen- tication automatically fails)
SLIDE 38
HANDSHAKE PREPARATION (1 BATCH)
𝑀𝐵𝐽 Set 𝑇𝑟𝑜=𝑉𝑞𝑒𝑏𝑢𝑓[𝑡𝑢↓𝑃𝑄↑𝐷 ] Generate R at random. Compute: 𝑁𝐵𝐷↓𝑃𝑄 = ¡𝐺↓1 (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆, ¡𝑇𝑟𝑜, ¡ 𝐵𝑁𝐺) 𝑁𝐵𝐷↓𝐷 = ¡𝐺↓2 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝐵𝐿=𝐺↓5 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝐵𝑣𝑢𝑜=(𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄 𝐷𝐿=𝐺↓3 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝐽𝐿=𝐺↓4 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝑉𝐽𝐸 𝑆 and everything Reveals Sqn
SLIDE 39
TERMINAL/CLIENT AKE
𝑀𝐵𝐽 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄 Compute: 𝐵𝐿=𝐺↓5 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) Retrieve 𝑇𝑟𝑜 and check 𝑁𝐵𝐷↓𝑃𝑄 If 𝑇𝑟𝑜 ¡∈ ¡ ¡{𝑡𝑢↓𝐷 , ¡…, ¡𝑡𝑢↓𝐷 +𝜀} Compute: 𝑆𝑡𝑞= ¡𝐺↓2 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝐷𝐿=𝐺↓3 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝐽𝐿=𝐺↓4 ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝑆𝑡𝑞 Check 𝑆𝑡𝑞=𝑁𝐵𝐷↓𝐷 Else Resynch!
SLIDE 40
RESYNCH PROCEDURE
𝑀𝐵𝐽 If 𝑁𝐵𝐷↓𝑃𝑄 verifies, but 𝑇𝑟𝑜 out of range Compute: 𝐵𝐿↑∗ =𝐺↓5↑∗ ¡(𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 , ¡𝑆) 𝑁𝐵𝐷↓𝐷↑∗ =𝐺↓1↑∗ (𝑡𝑙↓𝐷 , ¡𝑡𝑙↓𝑃𝑄 ,𝑡𝑢↓𝐷 , ¡ 𝐵𝑁𝐺, ¡𝑆) (𝑡𝑢↓𝐷 ¡XOR ¡𝐵𝐿↑∗ ) || 𝑁𝐵𝐷↓𝐷↑∗ Compute:𝐵𝐿↑∗ , get 𝑡𝑢↓𝐷 Check: out of range Check: 𝑁𝐵𝐷↓𝐷↑∗ Set 𝑡𝑢↓𝑃𝑄↑𝐷 = ¡𝑡𝑢↓𝐷 Start from there.
SLIDE 41
PART IV SECURITY OF AKA
SLIDE 42
CLEANER ABSTRACTION
SLIDE 43
SECURITY PROPERTIES
Key Secrecy: Attained under assumption of pseudorandomness of 𝐻
Advantage is linear in number of clients!
Client Impersonation: Attained under assumption of pseudorandomness of 𝐻
Advantage is linear in 𝑂↓𝐷 /2↑|𝑁𝐵𝐷↓𝐷 | and 𝑂↓𝐷 /2↑|𝑡𝑙↓𝐷 |
SLIDE 44
OFFLINE RELAYS
𝑀𝐵𝐽 Initial Identificatio n Get 𝑉𝐽𝐸 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄 Initial Identificatio n 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄
SLIDE 45
TERMINAL-IMPERSONATION RESISTANCE
Terminal Impersonation: Attained under assump-tion of pseudorandomness of 𝐻
Ø Attained as long as there are no offline relays § Thus weaker than Client Impersonation guarantee
Advantage is linear in 𝑂↓𝐷 /2↑|𝑁𝐵𝐷↓𝐷 | and 𝑂↓𝐷 /2↑|𝑡𝑙↓𝐷 |
SLIDE 46
PART V LACK OF PRIVACY & IMPOSSIBILITIES
SLIDE 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 Ø We PROVE AKA is: § NOT ID-Hiding – very easy to recover 𝑉𝐽𝐸 § Location-hiding – not really… § NOT Untraceable – see some attacks next slide Ø Their arguments: § Nobody knows 𝑉𝐽𝐸 and normally it is not used § Sequence number and keys are hidden in transcripts
SLIDE 48
DISTINGUISHING BY TERMINAL IMPERSONATION
𝑀𝐵𝐽 Get 𝑉𝐽𝐸 𝑡𝑢↓𝐷 Initial Identificatio n 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄
DrawClient ¡
Initial Identificatio n 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄
SLIDE 49
DISTINGUISHING BY RESYNCHRONIZATION
𝑀𝐵𝐽 Initial Identificatio n Get 𝑉𝐽𝐸 𝑡𝑢↓𝐷 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄 Update 𝑇𝑟𝑜 Repeat 𝜀 times
DrawClient ¡
Initial Identificatio n 𝑆 || (𝑇𝑟𝑜 ¡XOR ¡𝐵𝐿) || 𝐵𝑁𝐺 || 𝑁𝐵𝐷↓𝑃𝑄 𝑀𝐵𝐽 Get 𝑉𝐽𝐸 Update 𝑇𝑟𝑜 Clien t Auth Resynch!
SLIDE 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 𝑢 is enough to identify client
in (𝑢−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
SLIDE 51
PART VI CONCLUSIONS
SLIDE 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
Ø Authentication: § Unilateral : only one party authenticates the keys § Mutual: both parties authenticate the keys Ø Examples: TLS/SSL, AKA
SLIDE 53