Date post: | 20-Jan-2016 |
Category: |
Documents |
Upload: | kristian-hensley |
View: | 219 times |
Download: | 0 times |
Lecture 5: Protocols - Authentication and Key Exchange
CS 436/636/736 Spring 2015
Nitesh Saxena
Course Admin
• Mid-Term Grading – Will be done very soon– Scores will be posted online and graded exams
distribute post-break– Will email the solution set too
• Any questions regarding the exam– Perhaps we can quickly review?
04/21/23Protocols: Authentication and Key
Exchange2
Course Admin
• HW3 will be posted by this weekend– Due in 12-14 days as usual– Covers key distribution+protocols
• Spring break next week
3
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 today
• We’ll use the board extensively today – be prepared to take notes
04/21/23Protocols: Authentication and Key
Exchange4
Protocol
• A protocol is a set of rules using which two or more entities exchange messages
• It consists of messages and rounds
04/21/23Protocols: Authentication and Key
Exchange5
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
1. Wake up because of 1. Alarm (or clock)2. Intial start or3. Receipt of message(s) from other(s)
2. Compute something3. Send message(s) to other(s)4. Repeat 2-3 if needed5. Wait for message(s) or clock
04/21/23Protocols: Authentication and Key
Exchange6
Types of Adversaries
• Passive– Eavesdrop, delay, and replay messages
• Active– Eavesdrop, delay, drop, replay and modify
messages
04/21/23Protocols: Authentication and Key
Exchange7
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
04/21/23Protocols: Authentication and Key
Exchange8
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
04/21/23 9
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 10
Authentication Focus
• Entity Authentication– Verification of the identity of the sender of the
message
• Authentication can be unilateral or mutual
04/21/23Protocols: Authentication and Key
Exchange11
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)
04/21/23Protocols: Authentication and Key
Exchange12
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)
1. A B: Hi, this is A!2. B A: r (random challenge)3. A B: H(p,r)
Problem?
04/21/23Protocols: Authentication and Key
Exchange13
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
04/21/23Protocols: Authentication and Key
Exchange14
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
1. A B: Hi Bob, this is Alice!2. B A: r (a challenge)3. A B: EncK(r,B) (response)
Why not simply send EncK(r) in msg 3? Reflection Attack
04/21/23Protocols: Authentication and Key
Exchange15
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?
04/21/23Protocols: Authentication and Key
Exchange16
Freshness
• Assurance that message has not been used previously and originated within an acceptably recent timeframe
• Two methods:– Nonce (Number used once)– Timestamps
04/21/23Protocols: Authentication and Key
Exchange17
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
04/21/23Protocols: Authentication and Key
Exchange18
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!
04/21/23Protocols: Authentication and Key
Exchange19
Encryption-based Mutual Authentication (1)
• Run two copies of the uni-lateral authentication protocol 4 rounds
• We can piggyback common flows
1. A B: A, rA2. B A: EncK(rB, rA, A)
3. A B: EncK(rA, rB)
04/21/23Protocols: Authentication and Key
Exchange20
Encryption-based Mutual Authentication (2)
1. A B: A, EncK(T,B)
2. B A: EncK(T+1,A)
04/21/23Protocols: Authentication and Key
Exchange21
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!)
04/21/23Protocols: Authentication and Key
Exchange22
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)
04/21/23Protocols: Authentication and Key
Exchange23
Version 4 summary
04/21/23Protocols: Authentication and Key
Exchange24
MAC-based Authentication
1. A B: A, rA2. B A: rB, HMACK(rB, rA, A)
3. A B: HMACK(rA, rB,B)
• Faster than enc-based protocols (computationally)
04/21/23Protocols: Authentication and Key
Exchange25
Public-key based authentication(Needham-Shroeder (NS) pk-based)
• Assuming public keys are distributed through CA(s)
1. A B: Encpkb(rA, A)
2. B A: Encpka(rA, rB)
3. A B: Encpkb(rB)
04/21/23Protocols: Authentication and Key
Exchange26
Attack and fix on PK-based NS protocol
• Attack:
• Fix:
1. A B: Encpkb(rA, A)
2. B A: Encpka(rA, rB,B)
3. A B: Encpkb(rB)
04/21/23Protocols: Authentication and Key
Exchange27
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)
04/21/23Protocols: Authentication and Key
Exchange28
Authenticated Key Exchange (AKE)
• Public-key operations are costly• Why not
1. use public-key mutual authentication protocols to exchange a symmetric key
2. use this symmetric key with a symmetric encryption to secure subsequent communication
04/21/23Protocols: Authentication and Key
Exchange29
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
04/21/23Protocols: Authentication and Key
Exchange30
AKE Protocol
1. A B: A, rA, EncPKb(K) (must sign this too??)
2. B A: rB, SigSKb(rB, rA, A)
3. A B: SigSKa(rA, rB, B)
4. 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
04/21/23Protocols: Authentication and Key
Exchange31
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
04/21/23Protocols: Authentication and Key
Exchange32
A B1-A {ta,ra,B,sgnData,KUb[Kab]}
Ta-timestamp rA=nonce B =identitysgnData=signed with A’s private key
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
04/21/23Protocols: Authentication and Key
Exchange33
A B
1-A {ta,ra,B,sgnData,KUb[Kab]}
2-B {tb,rb,A,sgnData,KUa[Kba]}
X.509: Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables above authentication without the need for synchronized clocks
04/21/23Protocols: Authentication and Key
Exchange34
A B
1- A {ta,ra,B,sgnData,KUb[Kab]}
2 -B {tb,rb,A,sgnData,KUa[Kab]}
3- A{rb}
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
04/21/23Protocols: Authentication and Key
Exchange35
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
04/21/23Protocols: Authentication and Key
Exchange36
Diffie-Hellman (DH) Key Exchange
1. A B: Ka = ga mod p
2. B A: Kb = gb mod p
3. A outputs Kab = Kba
4. B outputs Kba = Kab
• Note Kab = Kba = gab mod p 04/21/23
Protocols: Authentication and Key Exchange
37
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…
04/21/23Protocols: Authentication and Key
Exchange38
Authenticated DH Key Exchange
1. A B: Ka = ga mod p
2. B A: Certb, Kb = gb mod p EncKba[SigSKb(Kb, Ka )]
3. A B: Certa, EncKab[SigSKa(Ka,Kb)]
4. A outputs Kab = Kba
5. B outputs Kba = Kab
04/21/23Protocols: Authentication and Key
Exchange39
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
04/21/23Protocols: Authentication and Key
Exchange40
Further Reading
• HAC – chapter 10• Stallings – Chapter 15
04/21/23Protocols: Authentication and Key
Exchange41