chap 3 key exchange protocols n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chap 3: Key exchange protocols PowerPoint Presentation
Download Presentation
Chap 3: Key exchange protocols

Loading in 2 Seconds...

play fullscreen
1 / 18

Chap 3: Key exchange protocols - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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.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
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
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
slide3
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?
slide4

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

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

slide9

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

slide12
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
  • 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.
slide14
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
slide15
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
slide17
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
authentication1
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)