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

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

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 3

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 4

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 5

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? 6

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 7

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 8

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? 9

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 10

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 11

12. Mutual Authentication (1) Problem: inefficient 12

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

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 14

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 K Alice-Bob and Alice encrypt with K Alice-Bob +1, etc. Different challenges: initiator (Alice) sends odd R, responder (Bob) sends even R, etc. 15

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) 16

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 17

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 18

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 19

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 20

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 [{R 1 } Bob ] Alice, Bob sends Alice [{R 2 } Bob ] Alice, and the session key is R = R 1 XOR R 2 - Trudy needs to overrun both Alice and Bob Diffie-Hellman key establishment: Alice sends Bob [g R1 mod p] Alice, Bob sends Alice [g R2 mod p] Bob, and the session key is R = g R1R2 mod p - Doesn’t help even if Trudy overruns both Alice and Bob 21

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 g R1 mod p, Bob sends Alice [g R2 mod p] Bob, and the session key is R = g R1R2 mod p Trudy can impersonate Alice in either case 22

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 23 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 24

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

26. Reading Assignment 26 [Kaufman] Chapter 11