Key Exchange Protocols J. Mitchell CS 259

Next few lectures uToday 1/17 Brief cryptography background Key exchange protocols and properties uThursday 1/19 Wireless security: i Choose your project partner uNext Tues 1/24 Password authentication protocols uNext Thurs 1/26 Contract-signing protocols uProject presentation #1 2/2 Talk about protocols for a while before looking at more tools

uEncryption scheme: functions to encrypt, decrypt data key generation algorithm uSecret key vs. public key Public key: publishing key does not reveal key -1 Secret key: more efficient, generally key = key -1 uHash function, MAC Map input to short hash; ideally, no collisions MAC (keyed hash) used for message integrity uSignature scheme Functions to sign data, verify signature Basic Concepts in Cryptography

Cryptosystem uA cryptosystem consists of five parts A set P of plaintexts A set C of ciphertexts A set K of keys A pair of functions encrypt: K  P  C decrypt: K  C  P such that for every key k  K and plaintext p  P decrypt(k, encrypt(k, p)) = p

What is a “secure” cryptosystem? uOne idea If enemy intercepts ciphertext, cannot recover plaintext uIssues in making this precise What else might your enemy know? –The kind of encryption function you are using –Some plaintext-ciphertext pairs from last year –Some information about how you choose keys What do we mean by “cannot recover plaintext” ? –Ciphertext contains no information about plaintext –No efficient computation could make a reasonable guess –Cannot use ciphertext for any nontrivial purpose

Passive Adversary ChallengerAttacker m 0, m 1 E(m i ) guess 0 or 1

Chosen ciphertext CCA1 ChallengerAttacker m 0, m 1 E(m i ) guess 0 or 1 c D(c)

Chosen ciphertext CCA2 ChallengerAttacker m 0, m 1 E(m i ) guess 0 or 1 c D(c) c  E(m i ) D(c)

uDifferent keys to encrypt and decrypt encrypt(key, message) decrypt(key -1, encrypt(key, message)) = message uEncryption key does not help decrypt Cannot compute m from encrypt(key, m) and key, unless you have key -1 Public-key Cryptosystem key pair

Example: RSA uArithmetic modulo pq Generate secret primes p, q Generate secret numbers a, b with x ab  x mod pq uPublic encryption key  n, a  Encrypt(  n, a , x) = x a mod n uPrivate decryption key  n, b  Decrypt(  n, b , y) = y b mod n uMain properties This works Cannot compute b from n,a –Apparently, need to factor n = pq n

Cryptographic hash functions uLength-reducing function h Map arbitrary strings to strings of fixed length uOne way (“preimage resistance”) Given y, hard to find x with h(x)=y uCollision resistant Hard to find any distinct m, m’ with h(m)=h(m’) uAlso useful: 2 nd preimage resistance Given x and y=h(x) hard to find x’  x with h(x’)=h(x) Collision resistance  2 nd preimage resistance

Iterated hash functions uRepeat use of block cipher or custom function Pad input to some multiple of block length Iterate a length-reducing function f –f : 2 2k -> 2 k reduces bits by 2 –Repeat h 0 = some seed h i+1 = f(h i, x i ) Some final function g completes calculation Pad to x=x 1 x 2 …x k f g xixi f(x i-1 ) x

Applications of one-way hash uPassword files (one way) uDigital signatures (collision resistant) Sign hash of message instead of entire message uData integrity Compute and store hash of some data Check later by recomputing hash and comparing uKeyed hash for message authentication MAC – Message Authentication Code

Digital Signatures uPublic-key encryption Alice publishes encryption key Anyone can send encrypted message Only Alice can decrypt messages with this key uDigital signature scheme Alice publishes key for verifying signatures Anyone can check a message signed by Alice Only Alice can send signed messages

Properties of signatures uFunctions to sign and verify Sign(Key -1, message) Verify(Key, x, m) = uResists forgery Cannot compute Sign(Key -1, m) from m and Key Resists existential forgery: given Key, cannot produce Sign(Key -1, m) for any random or otherwise arbitrary m true if x = Sign(Key -1, m) false otherwise

uEncryption scheme: functions to encrypt, decrypt data key generation algorithm uSecret key vs. public key Public key: publishing key does not reveal key -1 Secret key: more efficient, generally key = key -1 uHash function, MAC Map input to short hash; ideally, no collisions MAC (keyed hash) used for message integrity uSignature scheme Functions to sign data, verify signature Basic Concepts in Cryptography

Key Management uOut of band Can set up some keys this way (Kerberos) uPublic-key infrastructure (PKI) Leverage small # of public signing keys uProtocols for session keys Generate short-lived session key Avoid extended use of important secret Don’t use same key for encryption and signing Forward secrecy Cryptography reduces many problems to key management

Key Distribution: Kerberos Idea Client KeyCenter Server Shared symmetric key Kc Shared symmetric key Ks {Kcs, {Kcs} Ks } Kc {Kcs} Ks { msg } Kcs Key Center generates session key Kcs and distributes using shared long-term keys

Public-Key Infrastructure Certificate Authority ClientServer Known public signature verification key Ka Sign(Ka, Ks), Sign(Ks, msg) Certificate Sign(Ka, Ks) Ks Server certificate can be verified by any client that has CA key Ka Certificate authority is “off line”

Key Exchange uParties may have initial information uGenerate and agree on session key Authentication – know ID of other party Secrecy – key not known to any others Avoid replay attack Forward secrecy Avoid denial of service Identity protection – disclosure to others Other properties you can think of???

Diffie-Hellman Key Exchange uAssume finite group G =  S,   Generator g so every x  S is x = g n Example: integers modulo prime p uProtocol g a mod p g b mod p A B Alice, Bob share g ab mod p not known to anyone else

Diffie-Hellman Key Exchange Authentication? Secrecy? Replay attack Forward secrecy? Denial of service? Identity protection? g a mod p g b mod p A B

IKE subprotocol from IPSEC A, (g a mod p) B, (g b mod p) Result: A and B share secret g ab mod p Signatures provide authentication, as long as signature verification keys are known AB m1 m2, signB(m1,m2) signA(m1,m2)

IPSec: Network Layer Security uAuthentication Header (AH) Access control and authenticate data origins replay protection No confidentiality uEncapsulated Secure Payload (ESP) Encryption and/or authentication uInternet Key management (IKE) Determine and distribute secret keys Oakley + ISAKMP Algorithm independent uSecurity policy database (SPD) discarded, or bypass

IKE: Many modes uMain mode Authentication by pre-shared keys Auth with digital signatures Auth with public-key encryption Auth with revised public-key encryption uQuick mode Compress number of messages Also four authentication options

Aug 2001 Position Statement u In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), … several security problems…, most notably IKE. uFormal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown … security problems in IKE stem directly from its complexity. uIt seems … only a matter of time before serious *implementation* problems become apparent, again due to the complex nature of the protocol, and the complex implementation that must surely follow. uThe Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE.

How to study complex protocol

General Problem in Security uDivide-and-conquer is fundamental Decompose system requirements into parts Develop independent software modules Combine modules to produce required system uCommon belief: Security properties do not compose Difficult system development problem

Example protocol Protocol P1 A  B : {message} KB A  B : KA -1 uThis satisfies basic requirements Message is transmitted under encryption Revealing secret key KA -1 does not reveal message

Similar protocol Protocol P2 B  A : {message’} KA B  A : KB -1 uTransmits msg securely from B to A Message is transmitted under encryption Revealing secret key KB -1 does not reveal message

Composition P1; P2 uSequential composition of two protocols A  B : {message} KB A  B : KA -1 B  A : {message’} KA B  B : KB -1 uDefinitely not secure Eavesdropper learns both keys, decrypts messages

STS family m=g x, n=g y k=g xy STS 0H STS a STS aH STS H STS 0 STS PH JFK 1 distribute certificates cookie open responder JFK 0 symmetric hash JFK protect identities RFK STS P

Example uConstruct protocol with properties: Shared secret Authenticated Identity Protection DoS Protection uDesign requirements for IKE, JFK, IKEv2 (IPSec key exchange protocol)

Component 1 uDiffie-Hellman A  B: g a B  A: g b Shared secret (with someone) –A deduces: Knows(Y, g ab)  (Y = A) ۷ Knows(Y,b) Authenticated Identity Protection DoS Protection

Component 2 uChallenge Response: A  B: m, A B  A: n, sig B {m, n, A} A  B: sig A {m, n, B} Shared secret (with someone) Authenticated –A deduces: Received (B, msg1) Λ Sent (B, msg2) Identity Protection DoS Protection

Composition uISO protocol: A  B: g a, A B  A: g b, sig B {g a, g b, A} A  B: sig A {g a, g b, B} Shared secret: gab Authenticated Identity Protection DoS Protection m := g a n := g b

Refinement uEncrypt signatures: A  B: g a, A B  A: g b, E K {sig B {g a, g b, A}} A  B: E K {sig A {g a, g b, B}} Shared secret: gab Authenticated Identity Protection DoS Protection

Transformation uUse cookie: JFK core protocol A  B: g a, A B  A: g b, hash KB {g b, g a } A  B: g a, g b, hash KB {g b, g a } E K {sig A {g a, g b, B}} B  A: g b, E K {sig B {g a, g b, A}} Shared secret: gab Authenticated Identity Protection DoS Protection (Here B must store b in step 2, but we’ll fix this later…)

Cookie transformation uTypical protocol Client sends request to server Server sets up connection, responds Client may complete session or not (DOS) uCookie version Client sends request to server Server sends hashed data back –Send message #2 later after client confirms Client confirms by returning hashed data Need extra step to send postponed message

Cookie in JFK uProtocol susceptible to DOS A  B: g a, A B  A: g b, E K {sig B {g a, g b, A}} A  B: E K {sig A {g a, g b, B}} uUse cookie: JFK core protocol A  B: g a, A B  A: g b, hash KB {g b, g a } A  B: g a, g b, hash KB {g b, g a }, eh2 B  A: g b, eh1 eh1 eh2

Efficiency: Reuse D-H key uCostly to compute g a, g b, g ab uSolution Keep medium-term g a, g b (change ~10 min) Replace g a by pair g a, nonce uJFKi, JFKr protocols (except cert or grpinfo, …) A  B: Na, g a, A B  A: Nb, g b, hash KB {Nb, Na, g b, g a } A  B: Na, Nb, g a, g b, hash KB {Nb, Na, g b, g a }, E K {sig A {Na, Nb, g a, g b, B}} B  A: g b, E K {sig B {Na, Nb, g a, g b, A}} Note: B does not need to store any short-term data in step 2

Conclusion uMany protocol properties Authentication Secrecy Prevent replay Forward secrecy Denial of service Identity protection uSystematic understanding is possible But be careful; easy to make mistakes State of the art: need to analyze complete protocol

Block cipher modes (for DES, AES, …) uECB – Electronic Code Book mode Divide plaintext into blocks Encrypt each block independently, with same key uCBC – Cipher Block Chaining XOR each block with encryption of previous block Use initialization vector IV for first block uOFB – Output Feedback Mode Iterate encryption of IV to produce stream cipher uCFB – Cipher Feedback Mode Output block y i = input x i encyrpt K (y i-1 ) +

Electronic Code Book (ECB) Plain Text t CipCiphe r Texher T Block Cipher Problem: Identical blocks encrypted identically No integrity check

Cipher Block Chaining (CBC) Plain Text t CipCiphe r Texher T Block Cipher IV Block Cipher Advantages: Identical blocks encrypted differently Last ciphertext block depends on entire input

Comparison (for AES, by Bart Preneel) Similar plaintext blocks produce similar ciphertext (see outline of head) No apparent pattern