Lecture 5: Protocols - Authentication and Key Exchange 12/31/2018 Lecture 5: Protocols - Authentication and Key Exchange CS 436/636/736 Spring 2016 Nitesh Saxena

Protocols: Authentication and Key Exchange Course Admin Mid-term graded, scored posted Will be distributed today Solution set was emailed Any questions regarding the exam Perhaps we can quickly review? 12/31/2018 Protocols: Authentication and Key Exchange

Course Admin HW3 has been posted Due at 11am on Apr 11 12/31/2018 Course Admin HW3 has been posted Due at 11am on Apr 11 Covers key distribution+protocols Questions?

Outline of Today’s lecture 12/31/2018 Outline of Today’s lecture Today we try to put everything together Encryption (public-key/private-key) MACs Signing Key-Distribution Secure protocols (for secure communication) Authentication We studied it somewhat while talking about key distribution (Authenticated-) Key Exchange Designing secure protocols is hard – we’ll only be able to learn the basics We’ll use the board extensively today – be prepared to take notes 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Protocol A protocol is a set of rules using which two or more entities exchange messages It consists of messages and rounds 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Messages and Rounds A message is a unit of information send from one entity to other A round is a basic unit of protocol time Wake up because of Alarm (or clock) Intial start or Receipt of message(s) from other(s) Compute something Send message(s) to other(s) Repeat 2-3 if needed Wait for message(s) or clock 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Types of Adversaries Passive Eavesdrop, delay, and replay messages Active Eavesdrop, delay, drop, replay and modify messages 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Model N parties Any party can initiate the protocol with any other party Each party can be running a number of sessions with any other party at any point 12/31/2018 Protocols: Authentication and Key Exchange

Properties of a Secure Protocol 12/31/2018 Properties of a Secure Protocol Correctness If entities taking part in the protocol behave honestly, (and also if there are no transmission errors) the protocol achieves its desired goal In other words, if everything works as expected, does the protocol satisfy its desired goal? Security No adversary can defeat the goal of the protocol (with a significantly high probability) Adversary could be passive or active, depending upon the application (we consider the latter) We won’t consider denial-of-service attacks 12/31/2018

Adversary and Security Model 12/31/2018 Adversary and Security Model Different session should use different keys Compromise of one session should not lead to the compromise of any other session Adversary is an active adversary and a part of the system “Simply forwarding” adversary is NOT considered an adversary against the protocol Why? Message authentication (m’) Key exchange

Protocols: Authentication and Key Exchange 12/31/2018 Authentication Focus Entity Authentication Verification of the identity of the sender of the message Authentication can be unilateral or mutual Origin authentication: forwarding a signed message (one can verify that the message was generated by the source but not from the party it is coming from) 12/31/2018 Protocols: Authentication and Key Exchange

Basis for Authentication 12/31/2018 Basis for Authentication Something you know e.g., a PIN, a password Something you have e.g., an access key or a card; a certificate; a smart card; an RFID tag Something you are e.g., biometric (such as fingerprint) 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Weak Authentication PINs, Passwords provide weak authentication Security is based upon how hard the the pin/password is to guess Usually, the passwords are short and weak Vulnerable to dictionary attacks Widely used in practice Unix, web emails,…… Protocol (A authenticates to B using a password P, that A shares with B) A B: Hi, this is A! B A: r (random challenge) A B: H(p,r) Problem? Talk about UNIX password authentication (look at HAC) 12/31/2018 Protocols: Authentication and Key Exchange

Strong Authentication 12/31/2018 Strong Authentication An entity authenticates to the other by proving the knowledge of a secret associated with that entity, without revealing anything meaningful about the secret itself Can be achieved through: Private/Public Key Encryption MAC Digital signatures Strong because the security reduces to the security of the underlying cryptographic primitive, which is assumed to be hard to break Our focus in the rest of the lecture We’ll study both private-key and public-key based authentication 12/31/2018 Protocols: Authentication and Key Exchange

Symm. Encryption-based authentication 12/31/2018 Symm. Encryption-based authentication Uses encryption to authenticate Alice to Bob (assuming Alice-Bob have established a shared secret K, say through Kerberos) A auth B A  B: Hi Bob, this is Alice! B  A: r (a challenge) A  B: EncK(r,B) (response) Why not simply send EncK(r) in msg 3? Reflection Attack 1 – 2 – 2 – 1 – 1 – 2 12/31/2018 Protocols: Authentication and Key Exchange

Security of the previous protocol 12/31/2018 Security of the previous protocol An attacker needs to come up with a valid response Impossible if encryption is secure r must not be re-used by Bob Why? 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Freshness Assurance that message has not been used previously and originated within an acceptably recent timeframe Two methods: Nonce (Number used once) Timestamps 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Nonces One-time random number We depended on B to make sure r is a good nonce Choose nonces “randomly” from a large space (such as 2128) to avoid re-use and for unpredictability – good RNG 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Timestamps Inclusion of date/time-stamp in the message allows recipient to check it for freshness Need to be protected with cryptographic means A  B: EncK(T,B) Results in fewer messages and rounds But, requires synchronized clocks hard to achieve in practice! 12/31/2018 Protocols: Authentication and Key Exchange

Encryption-based Mutual Authentication (1) 12/31/2018 Encryption-based Mutual Authentication (1) Run two copies of the uni-lateral authentication protocol  4 rounds We can piggyback common flows A  B: A, rA B  A: EncK(rB, rA, A) A  B: EncK(rA, rB) 12/31/2018 Protocols: Authentication and Key Exchange

Encryption-based Mutual Authentication (2) 12/31/2018 Encryption-based Mutual Authentication (2) A  B: A, EncK(T,B) B  A: EncK(T+1,A) 12/31/2018 Protocols: Authentication and Key Exchange

Session Key Exchange with KDC – Needham-Schroeder Protocol 12/31/2018 Session Key Exchange with KDC – Needham-Schroeder Protocol A -> KDC IDA || IDB || N1 (Hello, I am Alice, I want to talk to Bob, I need a session Key and here is a random nonce identifying this request) KDC -> A E KA( K || IDB || N1 || E KB(K || IDA)) Encrypted(Here is a key, for you to talk to Bob as per your request N1 and also an envelope to Bob containing the same key) A -> B E KB(K || IDA) (I would like to talk using key in envelope sent by KDC) B -> A E K(N2) (OK Alice, But can you prove to me that you are indeed Alice and know the key?) A -> B E K(f(N2)) (Sure I can!) 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Session Key Exchange with KDC – Needham-Schroeder Protocol (corrected version with mutual authentication) A -> KDC: IDA || IDB || N1 (Hello, I am Alice, I want to talk to Bob, I need a session Key and here is a random nonce identifying this request) KDC -> A: E KA( K || IDB || N1 || E KB(TS1, K || IDA)) Encrypted(Here is a key, for you to talk to Bob as per your request N1 and also an envelope to Bob containing the same key) A -> B: E K(TS2,B), E KB(TS1, K || IDA) (I would like to talk using key in envelope sent by KDC; here is an authenticator) B -> A: E K(TS2+1,A) (OK Alice, here is a proof that I am really Bob) 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Version 4 summary 12/31/2018 Protocols: Authentication and Key Exchange

MAC-based Authentication A  B: A, rA B  A: rB, HMACK(rB, rA, A) A  B: HMACK(rA, rB,B) Faster than enc-based protocols (computationally) 12/31/2018 Protocols: Authentication and Key Exchange

Public-key based authentication (Needham-Shroeder (NS) pk-based) Assuming public keys are distributed through CA(s) A  B: Encpkb(rA, A) B  A: Encpka(rA, rB) A  B: Encpkb(rB) 12/31/2018 Protocols: Authentication and Key Exchange

Attack and fix on PK-based NS protocol A  B: Encpkb(rA, A) B  A: Encpka(rA, rB,B) A  B: Encpkb(rB) bLowe’s attack A initiates a legitimate session with E E decrypts and forwards the same message encrypted with B’s key B’s message is simply fwded to A Finally, E auths B as A 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange Signature-based authentication (assuming public keys are distributed through CA) A auth B A  B: Hi Bob, this is Alice! B  A: r (a challenge) A  B: SigSKa(r,B) (response) A auth B, B auth A (run two copies; piggyback common flows) A  B: A, rA (could sign this too) B  A: rB, SigSKb(rB, rA, A) A  B: SigSKa(rA,rB,B) Why the destination identifier in each message (as in the standard protocol)? Why not the source identifier? See HAC An attack similar to Lowe’s attack can be launched 12/31/2018 Protocols: Authentication and Key Exchange

Authenticated Key Exchange (AKE) Public-key operations are costly Why not use public-key mutual authentication protocols to exchange a symmetric key use this symmetric key with a symmetric encryption to secure subsequent communication Parties share a key K, why do they need to establish new SESSION Keys? 12/31/2018 Protocols: Authentication and Key Exchange

Security Notion for AKE Launch protocol between any pair Reveal all session key except one Try to distinguish the key of the unrevealed session from random This captures: the compromise of other sessions should not lead to the compromise of any other session 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange AKE Protocol A  B: A, rA, EncPKb(K) (must sign this too??) B  A: rB, SigSKb(rB, rA, A) A  B: SigSKa(rA, rB, B) A and B output K as the authenticated key Such a protocol can be instantiated using RSA encryption/signing The way SSL/SSH establishes key But, generally only the server authenticates to the client, not vice versa 12/31/2018 Protocols: Authentication and Key Exchange

X.509: One-Way Authentication 1 message ( A->B) used to establish the identity of A and that message is from A message was intended for B integrity & originality of message A B 1-A {ta,ra,B,sgnData,KUb[Kab]} Ta-timestamp rA=nonce B =identity sgnData=signed with A’s private key 12/31/2018 Protocols: Authentication and Key Exchange

X.509: Two-Way Authentication 2 messages (A->B, B->A) which also establishes in addition: the identity of B and that reply is from B that reply is intended for A integrity & originality of reply A 1-A {ta,ra,B,sgnData,KUb[Kab]} B 2-B {tb,rb,A,sgnData,KUa[Kba]} 12/31/2018 Protocols: Authentication and Key Exchange

X.509: Three-Way Authentication 3 messages (A->B, B->A, A->B) which enables above authentication without the need for synchronized clocks 1- A {ta,ra,B,sgnData,KUb[Kab]} A B 2 -B {tb,rb,A,sgnData,KUa[Kab]} 3- A{rb} 12/31/2018 Protocols: Authentication and Key Exchange

Discrete Logarithm Assumption p, q primes such that q|p-1 g’ be the generator of Zp* g is an element of order q and generates a group Gq of order q; g = g’(p-1)/q x in Zq, y = gx mod p Given (p, q, g, y), it is computationally hard to compute x No polynomial time algorithm known p should be 1024-bits and q be 160-bits x becomes the private key and y becomes the public key Explain the math involved, in choosing the parameters. 12/31/2018 Protocols: Authentication and Key Exchange

Example of DL-based system Let’s construct an example KeyGen: p = 11, q = 2 or 5; let’s say q = 5 2 is a generator of Z11* g = 22 = 4 x = 2; y = 42 mod 11 = 5 12/31/2018 Protocols: Authentication and Key Exchange

Diffie-Hellman (DH) Key Exchange A  B: Ka = ga mod p B  A: Kb = gb mod p A outputs Kab = Kba B outputs Kba = Kab Note Kab = Kba = gab mod p 12/31/2018 Protocols: Authentication and Key Exchange

Security of DH key exchange No authentication of either party Secure only against a passive adversary Under the computational Diffie-Hellman assumption Given (g, ga,gb), hard to compute gab Not secure against an active attacker Man-in-the-middle attack… 12/31/2018 Protocols: Authentication and Key Exchange

Authenticated DH Key Exchange A  B: Ka = ga mod p B  A: Certb, Kb = gb mod p EncKba[SigSKb(Kb, Ka )] A  B: Certa, EncKab[SigSKa(Ka,Kb)] A outputs Kab = Kba B outputs Kba = Kab 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange Summary Designing secure protocols is not easy Becomes harder in a concurrent setting, where there are multiple parties, executing multiple instances of the protocols simultaneously Becomes even harder as the number of parties increase; n-party or group setting Use the protocols that are well-studied and standardized While designing a protocol, consider Reflection attacks Replay attacks Eliminating any symmetry in the messages 12/31/2018 Protocols: Authentication and Key Exchange

Protocols: Authentication and Key Exchange 12/31/2018 Further Reading HAC – chapter 10 Stallings – Chapter 15 12/31/2018 Protocols: Authentication and Key Exchange