Chapter 11

Chapter 11: Security Handshake Pitfalls

You should not design their own crypto algorithms (Kerckhoff's Principle)
But you may need to design a security protocol
Protocols flaws can be very subtle
Topics to be covered
- Challenge/response (login only)
- Mutual authentication
- Integrity/encryption of data
- Mediated authentication
- Nonce types
- Picking random numbers
- Performance considerations
- Authentication protocol checklist
Challenge/response
1. A bad idea
  - Alice sends name and password in clear (across network) to Bob
  - Bob verifies name and password and communication proceeds
2. Better idea using shared secret
  - Implications
    - Authentication is not mutual
    - How to encrypt subsequent conversation?
    - If key derived from a password, offline password guessing is possible
    - Bob knows K_Alice-Bob so if Bob's database is compromised, attacker can impersonate Alice
  - Implications
    - Requires reversible cryptography (hash will not work)
    - If R is known and key derived from password, dictionary attack is possible by simply claiming to be Alice
    - If R has a limited lifetime, Alice can authenticate Bob (mutual authentication)
  - Implications
    - Easy to modify "bad idea" to this form, since no additional messages
    - More efficient
    - Bob does not need to maintain state
    - Eavesdropper can impersonate Alice (within acceptable clock skew); might also be possible to impersonate Alice to another server
    - If Bob sets his clock back, intercepted authentication messages can be replayed
    - Setting time (and agreeing on time) is a security issue
  - Implications
    - Same as above, but using a hash
    - Why transmit timestamp in the clear?
3. Better idea using public key crypto
  (Notation: [R]_Alice means sign with private key and {R}_Alice means encrypt with public key.)
  - Implications
    - Compromise of Bob's database will not allow attacker to impersonate Alice
    - Attacker may be able to trick Alice into signing anything
  - Implications
    - Compromise of Bob's database will not allow attacker to impersonate Alice
    - Attacker may be able to trick Alice into decrypting anything
Mutual authentication
1. Reflection attack
  - Implications
    - Authenticated exchange in each direction
    - Inefficient?
  - Implications
    - More efficient
    - Easy to get chosen plaintext
    - Subject to a reflection attack
  - Attack
    - Trudy opens 1st session to Bob
    - Trudy opens 2nd session to Bob in order to get information needed to complete 1st session
  - Solution?
    - Alice and Bob should not do exactly the same thing
    - Have Bob encrypt with K_Alice-Bob and Alice encrypt with K_Alice-Bob+1 or
    - Initiator sends odd R, responder sends even R, etc.
2. Password guessing (chosen plaintext)
  - Implications
    - One "extra" message and Alice cannot obtain chosen plaintext
3. Public keys
  - Implications
    - How to obtain public keys?
    - How can workstation obtain private key from password? (Easy with symmetric key crypto, not so easy with public key crypto.)
    - Identity-based encryption is an active research area
4. Timestamps
  - Implications
    - Only 2 messages
    - Alice and Bob must encrypt different things
    - Everyone must agree on the time
    - Time is now security-critical
How to establish a session key?
1. Shared secret
  - Implications
    - Why not use K_Alice-Bob as session key?
    - Why not use K_Alice-Bob+1 as session key?
    - Why not use K_Alice-Bob+1 to encrypt R to obtain session key?
    - Why not use K_Alice-Bob to encrypt R+1 to obtain session key?
2. Two-way public key authentication
  1. Alice sends {K}_Bob to Bob
    
    Issues: Trudy can hijack the conversation
  2. Alice sends [{K}_Bob]_Alice to Bob
    
    Issues: If Trudy records conversation and later overruns Bob, she can recover K
  3. Alice sends {K₁}_Bob and Bob sends {K₂}_Alice to Bob. The session key is K₁ ⊕ K₂
    
    Issues: Trudy can cause confusion, but cannot recover K
  4. Alice and Bob do a Diffie-Hellman key exchange, and sign the quantities: Alice sends [g^a mod p]_Alice to Bob and Bob sends [g^b mod p]_Bob to Alice
    
    Issues: Even if Trudy overruns both Alice and Bob, she cannot recover K
3. One-way public key authentication --- similar to two-way public key authentication
4. Privacy and integrity --- key rollover
Mediated Authentication with key distribution center (KDC)
1. In priciple
  - Implications
    - KDC does not authenticate Alice but only Alice can decrypt K_AB sent to "Alice"
    - Message from Alice to Bob could arrive before Bob gets his key
2. In practice
  - Implications
    - Alice and Bob must still mutually authenticate
3. Kerberos
  - Implications
    - Everyone must agree on time
Nonce types
1. Unpredictable nonce required
2. Predictable nonce is OK
Picking random numbers
1. Different application require different types of "random" numbers
2. For pseudo-random number generator, seed value is critical
3. Interesting mistakes listed in book
Performance considerations
1. Number of crypto operations (private key, public key, symmetric key, hash)
2. Number of messages transmitted
3. Cache previous state? (more speed, less security)
Authentication protocol checklist --- play role of Trudy
1. Eavesdrop
  - data?
  - replay?
  - off-line password (or other secret) guessing?
2. Pretend to be Alice
  - convince Bob?
  - off-line password guessing?
  - replay (e.g., impersonate Alice, impersonate Bob)?
  - get Bob to decrypt or sign something?
3. Pretend to be Bob (accept connection from Alice)
  - convince Alice?
  - off-line password guessing?
  - replay?
  - get Alice to decrypt or sign something?
4. Read Alice's database (can impersonate Alice)
  - impersonate Bob to Alice?
  - decrypt old conversations?
5. Read Bob's database (can impersonate Bob)
  - impersonate Alice?
  - decrypt old conversations?
6. Examine and/or modify data sent between Alice and Bob
  - off-line password guessing?
  - read data?
  - hijack conversation?
  - modify messages without detection?
7. Any combination of the above
  - For example, even after overrunning both Alice and Bob's databases, it should not be possible to decrypt recorded conversations