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 AliceCathy I need Bob’s public key Eve Cathy I need Bob’s public key Eve Cathy Bob’s pub key e B Alice Bob’s pub key e E Eve Alice Bob { k s } e E Eve Bob { k s } e B Eve intercepts request Eve intercepts message

Interlock protocol (right way) AliceCathy I need Bob’s public key Eve Cathy I need Bob’s public key Eve Cathy Bob’s pub key e B Alice Bob’s pub key e E Eve Alice Bob Hash ( { msg} e E ) Eve Bob What should I send? Eve intercepts request Eve intercepts message

Interlock protocol (wrong way) AliceCathy I need Bob’s public key Eve Cathy I need Bob’s public key Eve Cathy Bob’s pub key e B Alice Bob’s pub key e E Eve Alice Bob Hash ( msg ) Eve Bob Eve intercepts request Eve intercepts message Hash ( msg )

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; fURfuu4.4hY0U; /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 R1, and B knows hash(k, R1) During first login, A sends R1 and hash(k, R2)