Outline

• Authentication Protocols
• Simple Authentication - With Nonces, With Symmetric Key
• HW Problem
• Mutual Authentication
• Public Key Authentication

Authentication Protocols

• Alice must prove her identity to Bob
  • Alice and Bob can be humans or computers
• May also require Bob to prove he's Bob (mutual authentication)
• Probably need to establish a session key
• May have other requirements, such as
  • Use public keys
  • Use symmetric keys
  • Use hash functions
  • Anonymity, plausible deniability, etc., etc

Authentication

• Authentication on a stand-alone computer is relatively simple
  • Hash password with salt
  • "Secure path," attacks on authentication software, keystroke logging, etc., can be issues
• Authentication over a network is challenging
  • Attacker can passively observe messages
  • Attacker can replay messages
  • Active attacks possible (insert, delete, change)

Simple Authentication

• Simple and may be OK for standalone system
• But insecure for networked system
  • Subject to a replay attack (next 2 slides)
  • Also, Bob must know Alice's password

Authentication Attack

Authentication Attack

• Now that Trudy has seen the messages that Alice sent she can replay them.
• This is an example of a "replay" attack
• How can we prevent a replay?

Simple Authentication -- Single Message

• More efficient, but...
• ...same problem as previous version

Better Authentication

• Better since it hides Alices password
  • From both Bob and Trudy
• But still subject to replay

Challenge-Response

• To prevent replay, use challenge-response
  • Goal is to ensure "freshness" of messages
• Suppose Bob wants to authenticate Alice
  • Challenge sent from Bob to Alice
• Challenge is chosen so that...
  • Replay is not possible
  • Only Alice can provide the correct response
  • Bob can verify the response

Nonce

• To ensure freshness, can employ a nonce
  • Nonce == number used once
• What to use for nonces?
  • That is, what is the challenge?
• What should Alice do with the nonce?
  • That is, how to compute the response?
• How can Bob verify the response?
• Should we rely on passwords or keys?

Challenge-Response with Nonce

• Nonce is the challenge
• The hash is the response
• Nonce prevents replay, ensures freshness
• Password is something Alice knows
• Note: Bob must know Alice's pwd to verify

Generic Challenge-Response

• In practice, how to achieve this?
• Hashed password works, but...
• Encryption is better here (Why?)

Symmetric Key Notation

• Encrypt plaintext `P` with key `K`
  `C = E(P,K)`
• Decrypt ciphertext `C` with key `K`
  `P = D(C,K)`
• Here, we are concerned with attacks on protocols, not attacks on crypto
  • So, we assume crypto algorithms are secure

Authentication: Symmetric Key

• Alice and Bob share symmetric key `K`
• Key `K` known only to Alice and Bob
• Authenticate by proving knowledge of shared symmetric key
• How to accomplish this?
  • Cannot reveal key, must not allow replay (or other) attack, must be verifiable,...

Authentication with Symmetric Key

• Secure method for Bob to authenticate Alice
• Alice does not authenticate Bob
• So, can we achieve mutual authentication?

Mutual Authentication?

• What's wrong with this picture?
• "Alice" could be Trudy (or anybody else)!

HW Problem

Problem 9.4 Consider the following mutual authentication protocol, where `K_(AB)` is a shared symmetric key.

Give two different attacks that Trudy can use to convince Bob that she is Alice.

Answer. Trudy could send the message "I'm Alice, R + 1". Then when Bob sends `E(R+1, K_(AB))`, Trudy sends the message "I'm Alice, R". When Bob sends `E(R, K_(AB))`, Trudy can reply with `E(R+1, K_(AB))` she saw earlier. Alternatively, if Trudy watched the complete exchange of Alice and Bob, she could just replay all the messages.

Mutual Authentication

• Since we have a secure one-way authentication protocol...
• The obvious thing to do is to use the protocol twice
  • Once for Bob to authenticate Alice
  • Once for Alice to authenticate Bob
• This has got to work...

Mutual Authentication -- One-way Protocol Twice

• This provides mutual authentication...
• ...or does it? See the next slide

Mutual Authentication Attack

Mutual Authentication Observations

• Our one-way authentication protocol is not secure for mutual authentication
  • Protocols are subtle!
  • The "obvious" thing may not be secure
• Also, if assumptions or environment change, protocol may not be secure
  • This is a common source of security failure
  • For example, Internet protocols

Symmetric Key Mutual Authentication

• Do these "insignificant" changes help?
• Yes!

Public Key Notation

• Encrypt `M` with Alice's public key: `{M}_(Alice)`
• Sign `M` with Alice's private key: `[M]_(Alice)`
• Then
  `[{M}_(Alice)]_(Alice) = M`
• Anybody can use Alice's public key
• Only Alice can use her private key

Public Key Authentication Attempt 1

• Is this secure?
• What if Trudy pretends to be Bob.
• What Trudy really wants is to decrypt some message that someone else encrypted with Alice's public key.
• Using this message as R, Trudy (posing as Bob) can get Alice to decrypt anything!
  So, should have two key pairs

Public Key Authentication Attempt 2

• Is this secure? This has similar problems to the previous protocol.
• Now Trudy can get Alice to sign anything!
  Same as previous -- should have two key pairs

Public Keys

• Generally, a bad idea to use the same key pair for encryption and signing
• Instead, should have...
  • ...one key pair for encryption/decryption...
  • ...and a different key pair for signing/verifying signatures

Session Key

• Usually, a session key is required
  • I.e., a symmetric key for a particular session
  • Used for confidentiality and/or integrity
• How to authenticate and establish a session key (i.e., shared symmetric key)?
  • When authentication completed, want Alice and Bob to share a session key
  • Trudy cannot break the authentication...
  • ...and Trudy cannot determine the session key

Authentication and Session Key (with Public Keys)

• Is this secure?
  • Alice is authenticated and session key is secure
  • Alice's "nonce", `R`, useless to authenticate Bob
  • The key `K` is acting as Bob's nonce to Alice
• No mutual authentication

Public Key Authentication and Session Key (with Private Keys)

• Is this secure?
  • Mutual authentication (good), but...
  • ...session key is not secret (very bad)

Public Key Authentication and Session Key -- At Last 1

• Is this secure?
• Seems to be OK
• Mutual authentication and session key!

Public Key Authentication and Session Key -- At last 2?

• Is this secure?
• Seems to be OK
• However, anyone can see `{R,K}_(Alice)` and `{R +1,K}_(Bob)`