Outline Security Handshake Pitfalls (Chapter 11 & 12.2) Login Only Authentication (One Way) Login i w/ Shared Secret One-way Public Key Lamport s Hash Mutual Authentication Shared Secret Public Keys Timestamps Login w/ Shared Secret: Variant 1 Login With Shared Secret: Variant 2 I m I m lice Al a challenge R f(k -,R) K - {R} R Protocol 11-1 : challenge R, : f(k AB, R}, f can be hash or secret key based K AB could not be derived by the eavesdropper Problems: Authentication not mutual Connection hijacking after initial exchange if s address is spoofed Off-line password guessing attack (assume K is derived from password) Problems: Protocol 11-2 Requires reversible Cryptography Vulnerable to dictionary attack (if key K AB derived from passwd) For mutual authentication, R must be limited lifetime to foil the replaying of a K A-B {R}: if R is relevant to timestamp 1
Login With Shared Secret: One Way One-way Public Key Al B lice ob : K AB {timestamp} ; easy to add; efficient Problems: Requires synchronized clocks Replay attacks Eavesdropping and use the recorded message within clock skew window; if remember Use for other server if several servers share the same secret; if add server name Reuse if server clock can be set back Shared secret scheme is subject to impersonation attack if s database is disclosed Public key : hi; : R; : [R] A ( signs R) : hi; : {R} A ( encrypts using s public key); : R Database at only write-locked, not read-locked Problems: should not use the same key for two different purpose, unless Can trick into signing or decrypting message (if bob s address is spoofed) To fix: explicitly specifies the message type, type field (or, different keys) Lamport s Hash (Chapter 12.2) Lamport s Hash: Small n Attack s s Workstation s Workstation Safe from eavesdropping and database reading No public key cryptography (human + workstation): password (server): get username, n, hash n (password) during registration Authentication: Human: <, password> workstation; : name ; n ; : x = hash n-1 (password) ; : compares hash(x) with database, stores new <n-1, x>; n decrease by 1 Passwd reset if n gets to 1 No mutual authentication Trudy impersonates : Sends small n, say 50, to sends back hash 49 (password) Trudy then impersonates The actual n in the real bob is greater than 50 Trudy can compute hash 50, hash 51, hash n-1 workstation display n to human ; If remember 2
Mutual Authentication: Shared Secret Straightforward : I m ; : R 1 : K AB {R 1 } : R 2 : K AB {R 2 } Simplified: : I m, R 2 : R 1, K AB {R 2 } : K AB {R 1 } e I m R1 f(k-,r1} R2 f(k-,r2} Protocol 11-7 b Mutual Authentication: Reflection Attack First login connection by Trudy: Trudy : I m, R 2. Trudy: R 1, K AB {R 2 }. Can t do Trudy : K AB {R 1 } yet. Second login connection by Trudy: Trudy : I m, R 1. Trudy: R 3, K AB {R 1 }. Go back to first connection and do: Trudy : K AB {R 1 }. (Forget about the second connection). rudy Tr Mutual Authentication: Reflection Attack (Cont d) Fixes: General principle 1: & won t do same thing Different keys for initiator and responder Trudy can t get to encrypt using s key How? Different types of challenges for initiator and responder e.g., concatenate ca a e the name of party to the challenge e.g., initiator challenge be odd number General principle 2: the initiator should prove its identity first (e.g. Protocol 11-7 is not subject to reflection attack) Mutual Authentication: Public Keys I m,k,e{r 2} R 2,K,e{R 1} R1 : I m, {R 2 } B : R 2, {R 1 } A Protocol 11-12 Mutual authentication with public keys : R 1 Variant: Sign instead of encrypt Challenges: Public key distribution and storage Difficulty of deriving private key (e.g., RSA) from password Encrypt private key by password 3
Mutual Authentication: Timestamps (Shared Secret) Integrity/Encryption after Authentication: Establishing Session Keys Alic ce Eliminate exchanges of challenges : I m Im, K AB {t} : K AB {t +1} Problem: Trudy eavesdrops, gets K AB {t +1}, and uses it to impersonate (i.e., sends it to...) Fixes: remembers messages (timestamps) Includes direction flag b Bo Authentication i handshakes h to securely establish session keys: recall Kerberos! Using shared secret Using public keys One-way public key (only needs to have keys) Session Key: via Shared Secret Session Key: via Two-way Public Key (after public key based mutual authentication) : {R} B Trudy can impersonate and send her own {R} B to (hijackk com., pick her own R, & spoof s address) : I m : R : K AB{R} K AB {R+1} is bad: Trudy can eavesdrop to know R, then impersonate and trick to encrypt R+1, hence getting the session key btw and Use {K AB, R} based session keys??: many combinations! Good session key: one time; un-guessable; not consist of predictable X (=R+1) encrypted w/ K AB e.g. (K AB +n ) {R}; or other ways to modify K AB!!! : [{R} B ] A Trudy can record conversations, later break into, and decrypt (reading: p271) : {R 1 } B ; : {R 2 } A R 1 R 2 is session key, Trudy needs to break into both and Diffie-Hellman with signing: [g Ra mod p] A, [g Rb mod p] B; Session key: g RaRb mod p Even & are broken in, It is hard to deduce Ra, Rb 4
Session Key: via One-Way Public Key Mediated Authentication Only one of the parties has a public/private key : {K} B Trudy can record conversations, break into, and decrypt Diffie-Hellman with signing: g Ka mod p, [g Kb mod p] B; Session key: g KaKb mod p KDC: I want KDC: invents K AB KDC : K {use K AB for } KDC : K {use K AB for } Avoid race condition: KDC sends ticket = K {use K AB for } to, who then uses the ticket to contact Needham-Schroeder KDC: N 1, I want ; KDC : K A {N 1,, K AB, ticket} N 1 to authenticate KDC ticket= K B {K AB, } Ensure that t it is Messages 3, 4, & 5 to prevent replay attack & enforce mutual authentication. : ticket, K AB {N 2 } : K AB {N 2-1, N 3 } : K AB {N 3-1} Nonce (random no., seq. no, time stamp). Flaws: (Reading assignment: p275-277) Otway-Rees (reading assignment:p277-280) Idea: suspicious party should generate a challenge : N C,,, K A {N A, N C,, } KDC: K A {N A, N C,, }, K B {N B, N C,, } KDC uses N C to authenticate KDC : N C, K A {N A, K AB }, K B {N B, K AB } Ensure that both KDC and are legit : K A {N A, K AB } (ticket) : K AB {something readable} 5
Performance Considerations Metrics to evaluating performance No. of crypt. operations (blocks) using a private key No. of crypt. operations (blocks) using a public key No. of bytes encrypted/decrypted using a secret key No. of bytes to be hashed No. of messages transmitted Reading Assignment (Chapter 11.8): pp284-287 Authentication Protocol Checklist: organized around what Trudy might attempt to do. 6