DOC PREVIEW
GT CS 4803 - Computer and Network Security
School name Georgia Tech
Pages 5

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS 4803 Computer and Network SecurityAlexandra (Sasha) BoldyrevaAuthenticated key exchange1Diffie-Hellman key exchange•Secure against passive eavesdropping…•…but insecure against a man-in-the-middle attack2Adding key exchange•Not sufficient to simply “add on” key establishment before/after authentication•Need “authenticated key exchange”3Overview•Protocol design is subtle•Small changes can make a protocol insecure!•Historically, designed in an “ad-hoc” way, by checking protocol for known weaknesses•Great example of where provable security helps!4Example•“Reverse” challenge-response•I.e., send a ciphertext and have user decrypt it•Mutual authentication (if decrypts “validly”)??•Weaknesses?•Uses encryption for authentication5Example•User sends time, MACK(time)•What if she had used encryption, or a hash?•What about just sending MACK(time)?•Considerations?•Requires (loosely) synchronized clocks•Must guard against replay…•What if user has same key on multiple servers?•Clock reset attacks•No mutual authentication6Adding mutual authentication•Double challenge-response (symmetric key) in 4 rounds•Variant in which user sends nonce first?•Insecure (reflection attack)…•Also vulnerable to off-line password guessing without eavesdropping•To improve security, make protocol asymmetric•Security principle: let initiator prove its identity first7Using timestamps?•User sends time, MACK(time), server responds with MACK(time+1)•Vulnerabilities?8Establishing a session key•Double challenge-response; compute session key as FK(R+2)•Secure against passive attacks if F is a pseudorandom permutation…•Active attacks? And how to fix it…9Public-key based…•Include Epk(session-key) in protocol?•Encrypt session-key and sign the result?•Potentially vulnerable to replay attacks•User sends E(R1); server sends E(R2); session key is R1+R2•Reasonable…10One-way authentication•If only the server has a known public key (e.g., SSL)•Server sends R•Client sends Epk(R, password, session-key)•Insecure in general!!!•But secure if encryption scheme is chosen appropriately•Can extend to give mutual authentication11Authenticated Diffie-Hellman•Add signatures/MACs and nonces to Diffie-Hellman protocol•Variation: HMQV (improved MQV)12Using session keys•Generally, want to provide both secrecy and integrity for subsequent conversation•Use encrypt-then-MAC•Use sequence numbers to prevent replay attacks•Periodically refresh the session key13Mediated authentication•E.g., using KDC•Simple protocol:•Alice requests to talk to Bob•KDC generates KAB and sends it to Alice and Bob, encrypted with their respective keys•Note: no authentication here, but impostor can’t determine KAB14Improvement…•Have KDC send to Alice the encryption of KAB under Bob’s key•Reduces communication load on KDC•Resilient to message delays in network15Needham-Schroeder•A!KDC: N1, Alice, Bob•KDC!A: KA(N1, Bob, KAB, ticket), where ticket = KB(KAB, Alice)•A!B: ticket, KAB(N2)•B!A: KAB(N2-1, N3)•A!B: KAB(N3-1)16Analysis?•N1 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 protocol17Otway-Rees•A!B: NC, KA(NA, NC, Alice, Bob)•B!KDC: KA(…), KB(NB, NC, Alice, Bob)•KDC checks that NC is the same…•KDC!B: NC, KA(NA, KAB), KB(NB, KAB)•B!A: KA(…)•A!B: KAB(timestamp)•Note: KDC already authenticated Bob18Analysis?•NC should be unpredictable, not just a nonce•Otherwise, can impersonate B to KDC•Send first message: (next NC), “garbage”•B forwards to KDC along with encryption of the next NC• Next time A initiates a conversation, replay previous message from B•Still uses encryption for authentication… "•Serious attack if ECB is used•Replace KAB with NC19Kerberos•(May discuss in more detail later)•A!KDC: N1, Alice, Bob•KDC!A: KA(N1, Bob, KAB, ticket), where ticket = KB(KAB, Alice, expiration time)•A!B: ticket, KAB(time)•B!A:


View Full Document

GT CS 4803 - Computer and Network Security

Download Computer and Network Security
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Computer and Network Security and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Computer and Network Security 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?