Outline

• Perfect Forward Security
• Timestamp Protocols
• HW Problem
• Real-world Protocols -- SSH

Perfect Forward Secrecy

• Consider this "issue"...
• Alice encrypts a message with shared key K and sends ciphertext to Bob
• Trudy records ciphertext and later attacks Alice's (or Bob's) computer to recover K
• Then Trudy decrypts recorded messages
• Perfect forward secrecy (PFS) means Trudy cannot later decrypt recorded ciphertext
• Even if Trudy gets key K or other secret(s)
• Is PFS possible?

Perfect Forward Secrecy - Session Keys

• Suppose Alice and Bob share key K
• For perfect forward secrecy, Alice and Bob cannot use K to encrypt
• Instead they must use a session key `K_S` and forget it after it's used
• Can Alice and Bob agree on session key `K_S` in a way that ensures PFS?

Naive Session Key Protocol

• Trudy could record `E(K_S, K)`
• If Trudy later gets `K` then she can get `K_S`
• Then Trudy can decrypt recorded messages

Perfect Forward Secrecy -- Diffie Hellman

• We use Diffie-Hellman for PFS
• Recall DH: Alice Bob share public g and p. Each have their own private `a` and `b`. Then do above.
• But Diffie-Hellman is subject to MiM
• How to get PFS and prevent MiM?

Ephemeral Diffie-Hellman

• Session key `K_S = g^(ab) mod p`
• Alice forgets `a`, Bob forgets `b`
• So-called Ephemeral Diffie-Hellman
• Neither Alice nor Bob can later recover `K_S`
• Are there other ways to achieve PFS?

Mutual Authentication, Session Key, and PFS

• Session key is `K = g^(ab) mod p`
• Alice forgets `a` and Bob forgets `b`
• If Trudy later gets Bob's and Alice's secrets, she cannot recover session key `K`

Timestamps

• A timestamp `T` is derived from current time
• Timestamps used in some security protocols -- Kerberos, for example
• Timestamps reduce number of messsages (good) -- Like a nonce that both sides know in advance
• "Time" is a security-critical parameter (bad)
• Clocks never exactly the same, so must allow for clock skew -- creates risk of replay
• How much clock skew is enough?

Public Key Authentication with Timestamp T -- Sign Encrypt

• Secure mutual authentication?
• Session key?
• Seems to be OK

Public Key Authentication with Timestamp T -- Encrypt Sign

• Secure authentication and session key?
• Trudy can use Alice's public key to find `{T, K}_(Bob)` and then...

Public Key Authentication with Timestamp T -- Replay

• Trudy obtains Alice-Bob session key K
• Note: Trudy must act within clock skew

Public Key Authentication

• Sign and encrypt with nonce... Secure
• Encrypt and sign with nonce... Secure
• Sign and encrypt with timestamp... Secure
• Encrypt and sign with timestamp... Insecure
• Protocols can be subtle!

Public Key Authentication with Timestamp T -- Secure Encrypt and Sign

• Is this "encrypt and sign" secure?
  Yes, seems to be OK
• Does "sign and encrypt" also work here?

HW Problem

Exercise 9.2. The insecure protocol from two slides back can be modified to the messages Alice-to-Bob: "I'm Alice", `[{T,K}_(Bob)]_(Alice)`; Bob-to-Alice: `[T+1]_(Bob)` to make a secure protocol. Give two other distinct ways to slightly modify the protocol from two slides back so that that the result is secure. Your protocols must use a timestamp and "encrypt and sign".

Answer. The protocol from one slide back is such an answer. Notice there we encrypt using Alice PK `T+1` -- this is slightly better in that we would also not leak the timestamp, although it is likely that Trudy knows the current time already.

Another possibility is Alice-to-Bob: "I'm Alice", `[{T}_(Bob)]_(Alice)`; Bob-to-Alice: `[{T+1,K}_(Alice)]_(Bob)`. Only Bob (besides Alice) can compute `T+1`; only Alice can decrypt to find `K`.

Real-World Protocols

Next, we look at real protocols...

• SSH -- a simple & useful security protocol
• SSL -- practical security on the Web
• IPSec -- security at the IP layer
• Kerberos -- symmetric key, single sign-on
• WEP -- "Swiss cheese" of security protocols

Secure Shell (SSH)

• Creates a "secure tunnel"
• Insecure commands sent thru SSH tunnel are then secure
• SSH used with things like rlogin
  • Why is rlogin insecure without SSH?
  • Why is rlogin secure with SSH?
• SSH is a relatively simple protocol

How SSH works

• SSH authentication can be based on:
  • Public keys, or
  • Digital certificates, or
  • Passwords
• Here, we consider certificate mode. For other modes, see book problems
• We consider slightly simplified SSH...

Simplified SSH

• `CP = `"crypto proposed", and `CS = `"crypto selected"
• `H = h(Alice,Bob,CP,CS,R_A,R_B,g^a mod p,g^b mod p,g^(ab) mod p)`
• `S_B = [H]_(Bob)`
• `S_A = [H, Alice, cer\t\i\f\i\c\ate_A]_(Alice)`
• `K = g^(ab) mod p`

MiM Attack on SSH?

• Where does this attack fail?
• Alice computes:
  `H_a = h(Alice,Bob,CP,CS,R_A,R_B,g^a mod p,g^t mod p,g^(at) mod p)`
• But Bob signs:
  `H_b = h(Alice,Bob,CP,CS,R_A,R_B,g^t mod p,g^b mod p,g^(bt) mod p)`