ECE 454/CS594 Computer and Network Security

1. ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011

2. Security Handshake Pitfalls Login only Mutual authentication Integrity/encryption after authentication Nonce types Picking random numbers

3. Security Protocol • An agreement between communication parties about the process and the format of security bootstrap, authentication, key establishment, encryption/hashing algorithm and parameter negotiation, etc. • Typically include: - Authentication handshake - Session key negotiation, algorithm/parameter negotiation - Data encryption and/or integrity protection

4. Security Bootstrap Shared secret: • Password (for human users) • Pre-shared key (between firewalls) • Ticket by KDC (among a large number of participates) Public key: • Manually configured • Certificate by CA

5. Login Only: A Bad Idea • Alice sends name and password in clear (across network) to Bob • Bob verifies name and password and communication proceeds

6. Login Only: A Better Idea Using Shared Secret (1) • f(K,R) can be K{R} or h(K,R) • Authentication is one way: impersonation of Bob, offline password guessing, database reading • How to encrypt subsequent conversation?

7. Login Only: A Better Idea Using Shared Secret (2) • Problems: same as the previous one • Requires reversible cryptography (hash will not work) • If R is a recognizable number, this protocol does mutual authentication • Can make R recognizable but with limited lifetime, e.g., timestamp. It however requires clock synchronization

8. Login Only: A Better Idea Using Shared Secret (3) Advantages: • It can be easily added to an existing protocol • More efficient: it saves two message exchanges • Bob is stateless Problems: • Replay attack (single server, multiple servers) • Reset clock attack

9. Login Only: A Better Idea Using Shared Secret (4) • Same as the previous one, but using a hash • Why transmit timestamp in the clear?

10. Login Only: A Better Idea Using PKC (1) Implications: • Compromise of Bob's database will not allow attacker to impersonate Alice • Attacker may be able to trick Alice into signing anything

11. Login Only: A Better Idea Using PKC (2) Implications: • Compromise of Bob's database will not allow attacker to impersonate Alice • Attacker may be able to trick Alice into decrypting anything

12. Mutual Authentication (1) • Problem: inefficient

13. Mutual Authentication (2) – Optimized Implications: • More efficient • Subject to reflection attack: easy to obtain chosen plaintext

14. Reflection Attack • Trudy opens 1st session to Bob • Trudy opens 2nd session to Bob in order to get information needed to complete 1st session

15. Reflection Attack (Cont’d) Solution: • Alice and Bob should not do exactly the same thing: different keys, different challenges • Different keys: have Bob encrypt with KAlice-Bob and Alice encrypt with KAlice-Bob+1, etc. • Different challenges: initiator (Alice) sends odd R, responder (Bob) sends even R, etc.

16. Mutual Authentication (3) – Less Optimized Implications: • One "extra" message and Trudy cannot obtain chosen plaintext Rule: the initiator should be the first to prove its identity (the assumption is that the initiator is more likely the bad guy)

17. Mutual Authentication (4) Implications: • How to obtain public keys? • Store Bob’s public key encrypted with Alice’s password • Store Bob’s public key certificate signed by Alice

18. Mutual Authentication (5) Implications: • Can be easily added to existing challenge/response protocols • Alice and Bob must encrypt different things • Clock synchronization: time is now security-critical • Reflection attack

19. Integrity/Encryption After Authentication • How to establish a session key during authentication? • By shared secret • By two-way public key • By one-way public key

20. Shared Secret After this authentication: • Can we use K{R+1} as the shared session key? • How about K XOR R, K{K+R}, K+K{R}, h{K|R}? In general, a good session key is • different for each session • unguessable by attacker

21. Two Way Public Key • Alice and Bob each has a public/private key pair • How about Alice picks a random R, and sends {R}Bob to Bob - Trudy can impersonate Alice • How about Alice sends [{R}Bob]Alice to Bob - Trudy can obtain R by overrunning Bob and decrypt old messages • Alice sends Bob [{R1}Bob]Alice, Bob sends Alice [{R2}Bob]Alice, and the session key is R = R1 XOR R2 - Trudy needs to overrun both Alice and Bob • Diffie-Hellman key establishment: Alice sends Bob [gR1 mod p]Alice, Bob sends Alice [gR2 mod p]Bob, and the session key is R = gR1R2mod p - Doesn’t help even if Trudy overruns both Alice and Bob

22. One Way Public Key • Only Server Bob has a public/private key pair, Client Alice won’t bother having keys and certificate: SSL • Alice picks a random R, and sends {R}Bob to Bob - Trudy can decrypt old messages by overrunning Bob • Diffie-Hellman key establishment: Alice sends Bob gR1 mod p, Bob sends Alice [gR2 mod p]Bob, and the session key is R = gR1R2mod p • Trudy can impersonate Alice in either case

23. Nonce Types • Nonce: a quantity used only once - Large random number: unguessable, unpredictable, non-reuse w.h.p., makes the best nonce - Timestamp: requires clock synchronization - Sequence number: needs to maintain state unpredictability is important unpredictability is not required

24. Picking Random Numbers • Different applications require different types of random numbers • A common approach for cryptographic operations: pseudorandom number generator - seed value is critical - common mistakes: seed is from a small space, hashing the current time when a random value is needed, divulging the seed value

25. Authentication Protocol Checklist Authentication protocols protect against • eavesdropping • impersonation • database reading • message modification • combinations of the above

26. Reading Assignment • [Kaufman] Chapter 11