Lecture 13
-
Upload
talhaaftab -
Category
Documents
-
view
214 -
download
0
description
Transcript of Lecture 13
![Page 1: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/1.jpg)
CMSC 414Computer and Network Security
Lecture 13
Jonathan Katz
![Page 2: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/2.jpg)
Keyed Authentication Protocols
![Page 3: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/3.jpg)
Symmetric-key setting
In what follows, k refers to a high-entropy cryptographic key– If k is low-entropy (e.g., derived from a password)
these protocols are vulnerable to off-line attacks
![Page 4: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/4.jpg)
Basic authentication protocols…
Server stores k; user sends k
Server stores H(k); user sends k
Server stores H(k); user sends H(k)
All the above are secure against client-impersonation attacks (only)– May be enough in some settings
– How about eavesdropping?
– How about server compromise?
![Page 5: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/5.jpg)
Challenge-response
To prevent replay, need to add something that distinguishes one session from another– Ensure “freshness”
General paradigm: server sends a “challenge” and the user provides a correct “response”
Challenge should (at least) be non-repeating– Counter,
– Time – though see later
– Random value (nonce)
![Page 6: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/6.jpg)
Challenge-response
Client and server share a key k
Generically: server sends R; user sends f(k, R)
What is the “right” f to use here?
Drawbacks– Dictionary attack (for eavesdropper) if k low entropy
– Insecure against server compromise
![Page 7: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/7.jpg)
“Friend-or-foe”
NamibiaK
1. R
2. FK(R)SAAFImpala
K
![Page 8: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/8.jpg)
MiG-in-the-middle – what went wrong?
NamibiaK
Angola
1. R
2. R
3. R
4. FK(R)
5. FK(R)
6. FK(R)
SAAFImpala
K
RussianMiG
![Page 9: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/9.jpg)
Challenge-response
What if R is non-repeating, but predictable (like a counter)?
![Page 10: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/10.jpg)
Single-flow protocol
User sends <time, MACK(time)>– What if she had used encryption, or a hash?
– What about just sending MACK(time)?
No server state; single message
Considerations?– Requires (loosely) synchronized clocks
– Must guard against replay…
– What if user has same key on multiple servers?
– Clock reset attacks; clock DoS attacks!
– No mutual authentication
![Page 11: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/11.jpg)
“Reverse” challenge-response
Server sends f(k, R) and client sends R– I.e., send a ciphertext and have user decrypt it
Mutual authentication (if decrypts “validly”)??
Weaknesses?– Uses encryption for authentication
• (Note that a MAC cannot, in general, be used)
– Vulnerable to off-line dictionary attack after client impersonation (eavesdropping unnecessary)
– Authentication of server assumes no replay…
![Page 12: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/12.jpg)
Better mutual authentication
Double challenge-response in 4 rounds1. Client sends their name
2. Server sends a nonce R
3. Client sends MACK(R) and R’
4. Server sends MACK(R’)
![Page 13: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/13.jpg)
Mutual authentication in 3 rounds?
Can we compress the previous protocol to 3 rounds?– Client sends their name, R’
– Server sends MACK(R’) and R
– Client sends MACK(R)
Seems ok…
![Page 14: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/14.jpg)
Mutual authentication in 3 rounds Insecure! (reflection attack using two server
connections…)– Also vulnerable to off-line password guessing without
eavesdropping– To improve security, make protocol asymmetric– No such attack on original protocol
• Security principle: let initiator prove its identity first
A good illustration that designing secure protocols is very subtle!– Another warning against modifying existing protocols
even in seemingly “innocuous” ways
![Page 15: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/15.jpg)
Overview
Protocol design is subtle– Small changes can make a protocol insecure!
– Another warning against modifying existing protocols even in seemingly “innocuous” ways
– Historically, designed in an “ad-hoc” way, by checking protocol for known weaknesses
– Great example of where provable security helps!
![Page 16: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/16.jpg)
Server compromise
The symmetric-key protocols we have seen are all vulnerable to server compromise– Can we address this?
![Page 17: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/17.jpg)
A public-key protocol w/ signatures
Server stores pk; user stores sk
Server sends R; user signs R– Using a secure signature scheme…
Is this secure against eavesdropping/server compromise?– What if we had used encryption instead?
Note: attacker can get user to sign anything…– Key should be used only for authentication
![Page 18: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/18.jpg)
Using public-key encryption?
Server chooses random R, sends EncPK(R)
User sends back R
Secure?– Note that an attacker can run a chosen-ciphertext attack– If we use a CCA-secure scheme, ok!
Attacker can get user to decrypt anything– Key should be used only for authentication– General principle: different keys for different purposes
![Page 19: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/19.jpg)
Server compromise?
Can we achieve security against eavesdropping and server compromise without public-key cryptography?
![Page 20: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/20.jpg)
Lamport’s protocol (S/Key)
Server stores Hn(pw), sends n; user sends Hn-1(pw)– Server updates user’s entry…
Can also add “salt” to hash– Server sends salt to user as first flow
– Allows user to use same password on different sites
– Can use same password (but different salt) when password “expires”
– Protects against pre-computation
![Page 21: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/21.jpg)
Some drawbacks…
Stateful protocol
Secret expires at some point and a new secret must be shared
Security against active attacks?
E.g., “low number” attack– Can use “paper-and-pencil” method to prevent this…
– …but at that point, better solutions are also possible!
![Page 22: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/22.jpg)
Session key establishment There are very few applications for which
authentication alone is sufficient!– Can you think of any?– What do you do once you are authenticated?
Generally, need to establish a session key to authenticate (and encrypt) subsequent communication– Also efficiency advantages to using symmetric-key
techniques even if public-key authentication is used– Advantages even if a symmetric key is already shared…
![Page 23: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/23.jpg)
Why use session keys?
Reduces effectiveness of cryptanalysis
If key compromised, only one session affected– Even if long-term key compromised, session keys
unaffected – forward secrecy
Prevents replay of messages from other sessions
![Page 24: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/24.jpg)
Adding key exchange
Not sufficient to simply “add on” key establishment before/after authentication– Splicing attack…
Need “authenticated key exchange”– Need to ‘bind’ the authentication and the key exchange
![Page 25: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/25.jpg)
Forward secrecy
(Past) session keys should remain secret even if the adversary compromises the long-term key(s) of the parties
![Page 26: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/26.jpg)
Establishing a session key
Use the (secure) double challenge-response protocol from earlier; let the session key be Fk(R+1)– Is this secure?
– How to fix?
– No forward secrecy…
![Page 27: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/27.jpg)
Public-key based…
Include Epk(session-key) in protocol?– No authentication of the ciphertext
Encrypt session key and sign the result?– No forward secrecy…– Potentially vulnerable to replay attacks
Client sends Epks(R1); server sends Epkc(R2); session key is R1+R2
– Reasonable…– Why isn’t it a problem that the ciphertexts are not
authenticated?– Implicit vs. explicit authentication
![Page 28: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/28.jpg)
Authenticated Diffie-Hellman
Add signatures/MACs and nonces to Diffie-Hellman protocol– Note: achieves forward secrecy
– Subtle details involved…need asymmetry
![Page 29: Lecture 13](https://reader035.fdocuments.us/reader035/viewer/2022062519/5695d0201a28ab9b029111fb/html5/thumbnails/29.jpg)
Using session keys
Generally, want to provide both secrecy and integrity for subsequent conversation– Use authenticated encryption (e.g., encrypt-then-MAC)
– Use sequence numbers to prevent replay attacks
– Use a directionality bit
– Periodically refresh the session key