Download presentation
Presentation is loading. Please wait.
1
CMSC 414 Computer and Network Security Lecture 18 Jonathan Katz
2
One-way authentication If only the server has a known public key (e.g., SSL) –Server sends R –Client sends E pk (R, password, session-key) Insecure in general!!! –But secure if encryption scheme is chosen appropriately Can extend to give mutual authentication
3
Authenticated Diffie-Hellman Add signatures/MACs and nonces to Diffie- Hellman protocol –Note: achieves forward secrecy –What if we had used encryption instead?
4
Using session keys Generally, want to provide both secrecy and integrity for subsequent conversation –Use encrypt-then-MAC –Use sequence numbers to prevent replay attacks –Use a directionality bit –Periodically refresh the session key
5
“Dos and Don’ts of Client Authentication on the Web” (Fu, et al.)
6
Authentication using “cookies” “Single sign-on” for users accessing a site Full-fledged key-exchange not practical due to limited client (and server!) computation No public keys, no third parties… Idea: use “authenticators” stored as cookies –No client-side computation at all But…must do this securely!
7
Minimal level of security? Any such scheme must be secure against “interrogative attacks” –These are trivial to mount Eavesdropping, server impersonation, and man-in-the-middle attacks are more difficult Confidentiality is an orthogonal issue…
8
Security “hints”… Use appropriate amount of security –Do you need fine-grained knowledge of the user-id or not? –Is confidentiality, etc. required or not? Use published schemes… No security through obscurity… Use cryptographic tools appropriately –E.g., don’t use crypt( ) as a MAC…
9
More “hints” Be careful of composing security schemes –E.g., using two authentication systems… Protect user passwords –Don’t send in the clear –Don’t include in cookie Re-authenticate before changing password Avoid predictable session identifiers Expiration…
10
A simple and secure approach… Cookie = (username/data, expiration, MAC)
11
Mediated authentication
12
E.g., using KDC Simple protocol: –Alice requests to talk to Bob –KDC generates K AB and sends it to Alice and Bob, encrypted with their respective keys –Note: no authentication here, but impostor can’t determine K AB
13
Improvement… Have KDC send to Alice the encryption of K AB under Bob’s key –Reduces communication load on KDC –Resilient to message delays in network
14
Needham-Schroeder A KDC: N 1, Alice, Bob KDC A: K A (N 1, Bob, K AB, ticket), where ticket = K B (K AB, Alice) A B: ticket, K AB (N 2 ) B A: K AB (N 2 -1, N 3 ) A B: K AB (N 3 -1)
15
Analysis? N 1 assures Alice that she is talking to KDC –Prevents key-replay, helps prevent attack when Bob’s key is compromised and then changed Important: authenticate “Bob” in message 2, and “Alice” in ticket Uses encryption to authenticate… –Leads to actual flaw if, e.g., ECB mode is used! Vulnerable if Alice’s key is compromised –Bob’s ticket is always valid –Use timestamps, or request (encrypted) nonce from Bob at the very beginning of the protocol
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.