Chap 3 Key exchange protocols In most systems

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

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

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

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

• 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. • How can the Interlock protocol mitigate the attack – What will be a good interlock: hash of the message, hash of the encryption result?

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 e. B Cathy Eve Bob’s pub key e. E Eve Alice { ks } e. E Eve intercepts message Eve { ks } e. B Bob

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 e. B Cathy Eve Bob’s pub key e. E Eve Alice Hash({ msg} e. E ) Eve intercepts message What should I send? Bob

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 e. B Cathy Eve Bob’s pub key e. E Eve Alice Hash( msg ) Eve intercepts message Eve Hash( msg ) Bob

• Improvement to protocol 2: – Public keys for Alice and Bob should be protected by the certificate from a TTP

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.

• 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

• 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; f. URfuu 4. 4 h. Y 0 U; /home/gigawalt

• 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

Authentication • Method 4: one key a time protocol – Hash chain – Unlimited one key a time system (2 possible solutions) • Both sides know a secret k • A knows R 1, and B knows hash(k, R 1) • During first login, A sends R 1 and hash(k, R 2)