Chap 3: Key exchange protocols

1 / 18

# Chap 3: Key exchange protocols - PowerPoint PPT Presentation

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## Chap 3: Key exchange protocols

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
• 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
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?

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

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
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:
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

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

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

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