Chap 3: Key exchange protocols

1. Chap 3: Key exchange protocols • In most systems, we distinguish the short term keys from the long term ones: • A short term key (session key) is used to protect one conversation • Long term key is used to distribute the session keys • Reduce the amount of traffic encrypted by each secret

2. Key exchange protocols • Protocols 1: using symmetric cryptography • We assume that every node shares a key with KDC • Steps • Alice requests a key from KDC • KDC encrypts the key with Alice and Bob’s keys respectively and sends both messages to Alice • Alice forward Bob’s copy to Bob

3. Problems of protocol 1 • Alice knows both the plaintext and cipher text for Bob. It becomes a known-plaintext attack for Bob • When Alice sends a copy to Bob, how can Bob makes sure this is a fresh key or the other party is actually Alice?

4. Freshness of the Key (or any packets) • Timestamp based approach: attach a timestamp to the encrypted component of the message • Problem: need synchronized clock • Nonce (random number based) • Each party needs to generate its own fresh random numbers. They are attached to the message • No synchronization

5. Protocol 2: Using public key • We assume that everyone has a public private key pair • Steps • Alice generates a session key and encrypts it with Bob’s public key • Bob decrypts the message and gets the session key • Now they can talk safely

6. Sounds easy. But several vulnerabilities exist • Forward search attack • If there are only a limited number of messages, the attacker can pre-compute and compare with the eavesdropped results • Similar attacks can be generalized to several other scenarios such as hash(), password, etc

7. Man-in-the-Middle Attack • If the public keys of the nodes do not have certificate with them, they can be fake keys. And a min-in-the-middle attack can be conducted. • How the min-in-the-middle attacks are conducted:

8. Man-in-the-Middle Attack I need Bob’s public key Eve intercepts request Alice Cathy I need Bob’s public key Cathy Eve Bob’s pub key eB Cathy Eve Bob’s pub key eE Eve Alice { ks } eE Eve intercepts message Bob Alice { ks } eB Bob Eve

9. What if the two parties have pre-determined the first pair of messages? Can this defend against MitM attack? • Unfortunately, no • Interlock protocol: mitigate the attack • What will be a good interlock: hash of the message, hash of the encryption result?

10. Interlock protocol (right way) I need Bob’s public key Eve intercepts request Alice Cathy I need Bob’s public key Cathy Eve Bob’s pub key eB Cathy Eve Bob’s pub key eE Eve Alice Hash({ msg} eE ) Eve intercepts message Bob Alice What should I send? Bob Eve

11. Interlock protocol (wrong way) I need Bob’s public key Eve intercepts request Alice Cathy I need Bob’s public key Cathy Eve Bob’s pub key eB Cathy Eve Bob’s pub key eE Eve Alice Hash(msg ) Eve intercepts message Bob Alice Hash(msg) Bob Eve

12. Improvement to protocol 2: • Public keys for Alice and Bob should be protected by the certificate from a TTP • Look at the settings of your browsers: look for certificates

13. Authentication • Authentication: prove that you are who you claim to be • Method 1: • The system stores your password, and compares it with the characters you type in every time you login • Problem: if the attacker gets access to the file, you are cooked.

14. Method 2: • The system stores the hash result of the password, now if the attacker sees the hash value, it cannot recover the plaintext. • Problem: • It is still not safe under dictionary attacks • The system can add a random number after the password, which is called salt • Public salt and private salt. • Salt protects the overall system, but not specific users • The same key combined with different salt will look differently in the system

15. Key management in some UNIX systems • don't use the shadow password files • the passwords are stored encrypted in the file /etc/passwd • Format of the stored record • Account; coded password data; homedir; • Gigawalt; fURfuu4.4hY0U; /home/gigawalt

17. Method 3: Using public-private key • The system knows the public key and the user keeps the private key • During login, the system sends a random number to user and user encrypts it with the private key • System decrypts with public key and verifies the user • Problems: • Blind signature • Chosen plaintext attack

18. Authentication • Method 4: one key a time protocol • Hash chain • Unlimited one key a time system • Both sides know a secret k • A knows R1, and B knows hash(k, R1) • During first login, A sends R1 and hash(k, R2)