1. 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

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

3. 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?

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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 s,……
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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

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