Security handshake pitfalls How come nobody gets it right? CS349 Cryptography Department of Computer Science Wellesley College Getting it right o We mortals should never need to design our own cryptographic algorithms. o However, it may be the case that we will need to design security features into protocols. o We had better understand (at least some of) what can go wrong. Handshake pitfalls 18-2 1 Protocol 1. Login only Many protocols were designed in an environment where eavesdropping was not a concern. I’m Alice, the password is fiddlesticks Bob Alice o Handshake pitfalls 18-3 Protocol 2a. Shared secret a challenge R Bob Alice I’m Alice f(Kalice-Bob, R) o This is a big improvement over passwords in the clear. An eavesdropper cannot impersonate Alice based on overhearing the exchange. o However, the protocol is not without weakness. Handshake pitfalls 18-4 2 Protocol 2b. Shared secret, second try* KAlice-Bob{R} Bob Alice I’m Alice R *An attempt at mutual authentication. Handshake pitfalls 18-5 I’m Alice, KAlice-Bob{timestamp) Bob Alice Protocol 2c. Shared secret, attempt to abbreviate* *Requires that Bob and Alice have reasonably synchronized clocks. Handshake pitfalls 18-6 3 I’m Alice, timestamp, hash(KAlice-Bob,timestamp} Bob Alice Protocol 2d. Shared secret, a detail Handshake pitfalls 18-7 Protocol 3a. One-way public key o Our protocols based on shared secrets all have one major disadvantage. Our bad guy can impersonate Alice if she can read Bob’s database. o Protocols based on public key technology can avoid this. a challenge R Bob Alice I’m Alice [R]Alice Handshake pitfalls 18-8 4 Protocol 3b. One-way public key* [R]Alice Bob Alice I’m Alice R *A minor variant, possible with reversible public key schemes that avoids tricking Alice into signing away the farm. Handshake pitfalls 18-9 How can we avoid getting into trouble? o The general rule is that you should not use the same key for two different purposes unless the designs for all uses of the key are coordinated. o Part of the purpose of the Public-key Cryptography Standard is to impose enough structure to prevent this sort of problem. Handshake pitfalls 18-10 5 Protocol 4a. Mutual authentication base on a shared secret* I’m Alice f(Kalice-Bob, R1) R2 Bob Alice R1 f(Kalice-Bob, R2) *We could just do an authentication exchange in each direction. Handshake pitfalls 18-11 Protocol 4b. Optimized mutual authentication based on shared secret R1, f(Kalice-Bob, R2) Bob Alice I’m Alice, R2 f(Kalice-Bob, R1) Handshake pitfalls 18-12 6 Reflection attack Bob Trudy I’m Alice, R2 R1, f(Kalice-Bob, R2) “I can’t explain myself, I’m afraid sir,” said Alice, “because, I’m not myself, you see.” Alice in Wonderland Handshake pitfalls 18-13 Trudy opens a second session to Bob* R3, f(Kalice-Bob, R1) Bob Trudy I’m Alice, R1 *Which she still cannot complete. However, . . . Handshake pitfalls 18-14 7 Foiling reflection attacks o The general principle is simple: Don’t have Alice and Bob do exactly the same thing. o For example, we could have the key used to authenticate Alice be different from the key used to authenticate Bob. o Alternatively, we could insist that the challenge from Alice look different from the challenge from Bob. Handshake pitfalls 18-15 Protocol 4a does not suffer from reflection attack Moral of the story The initiator should be the first to prove its identity. . . . if you only spoke when you were spoken to, and the other person always waited for you to begin, you see nobody would ever say anything . . . Alice (in Through the Looking Glass) Handshake pitfalls 18-16 8 Password guessing o Optimized Protocol 4b suffers from an another security weakness. Trudy can mount an off-line password-guessing attack without needing to eavesdrop. R1, f(Kalice-Bob, R2) Bob Alice I’m Alice, R2 f(Kalice-Bob, R1) Handshake pitfalls 18-17 Protocol 4c. Less optimized mutual authentication base on shared secret I’m Alice f(Kalice-Bob, R1), R2 Bob Alice R1 f(Kalice-Bob, R2) Handshake pitfalls 18-18 9 Protocol 5. Mutual authentication using Timestamps o f(Kalice-Bob, timestamp+1) Bob Alice I’m Alice, f(Kalice-Bob, timestamp) The issues involving one-way authentication done with timestamps apply here as well (time must not go backwards, they must remember values used within the clock skew, and so forth . . .) Handshake pitfalls 18-19 Protocol 6. Mutual authentication with public keys R2, {R1}Alice Bob Alice I’m Alice, {R2}Bob R1 Handshake pitfalls 18-20 10 Key management o Techniques for the distribution of public keys fall into following schemes: o Public announcement; o Publicly available directory; o Public-key authority; or o Public-key certificates. Handshake pitfalls 18-21 Public announcement of public keys Handshake pitfalls 18-22 11 Publicly available directory Handshake pitfalls 18-23 Public-key authority Handshake pitfalls 18-24 12 Public-key certificates Handshake pitfalls 18-25 13
© Copyright 2024