1 / 18

Chap 3: Key exchange protocols

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.

kenaz
Download Presentation

Chap 3: Key exchange protocols

An Image/Link below is provided (as is) to download presentation 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

  17. 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)

More Related