CSCE 465 Lecture 24

« previous | Thursday, April 18, 2013 | next »

Authentication Protocols

Examples:

• Wi-Fi (WPA, WEP, tamulink-wpa uses WPA2-Enterprise suite of encryption/authentication protocols)
• Printing (CUPS, HPLIP, Samba, etc.)
• Kerberos

Roadmap

• Authentication Handshakes
• Login only (one-side authentication)
• mutual authentication (both sides authenticate)
• Integrity/encryption of data
• Mediated authentication (with KDC)

Authentication Handshakes

Secure communication almost always includes an ititial handshake

• Authenticate each other
• Establish session keys
• not trivial; flaws undermine security

Authentication with Shared Secret

1. Alice: "I'm Alice."
2. Bob: "Alice, I challenge you with this random number $R$."
3. Alice: "$f(K_{\text{Alice-Bob}},R)$

Multiple variations are possible: e.g. send encrypted random number and ask Alice to decrypt

Weaknesses:

• Authentication is not mutual: Trudy can convince Alice that she is Bob
• Trudy can hijack conversation after initial exchange
• If shared key is derived from password, Trudy can mount offline password-guessing attack
• Trudy may comprimise Bob's database and later impersonate Alice

Authentication with Public Key

1. Alice: "I'm Alice."
2. Bob: "Alice, I challenge you with this random number $R$."
3. Alice: "${\text{Sign}}_{\text{Alice}}\{R\}$."

Variation: send $R$ encrypted with Alice's public key, ask for decrypted $R$.

Bob's database is more secure; less information can be obtained if hacked, BUT

Weaknesses:

• Authentication is still not mutual: Trudy can still convince Alice that she is Bob
• Trudy can still hijack conversation after initial exchange.
• NEW: Trudy can trick Alice into signing something
  • Alice should use different private key for authentication than for other purposes.

Mutual Authentication

(both sides authenticate)

Shared Secret Key

1. Alice: "I'm Alice."
2. Bob: "Alice, I challenge you with this random number $R_{1}$."
3. Alice: "$f(K_{\text{Alice-Bob}},R_{1})$"
4. Alice: "Bob, I challege you with this random number $R_{2}$."
5. Bob: "$f(K_{\text{Alice-Bob}},R_{2})$"

This can be optimized to just

1. Alice: "I'm Alice. Bob, I challenge you with this random number $R_{2}$."
2. Bob: "$f(K_{\text{Alice-Bob}},R_{2})$. Alice, I challenge you with this random number $R_{1}$."
3. Alice: "$f(K_{\text{Alice-Bob}},R_{1})$"

Reflection Attack

It's still possible for trudy to impersonate Alice

• 1. Open connection as usual, and get $R_{1}$ from Bob
  2. Open a new connection, send $R_{1}$ as the first "$R_{2}$" and receive the result back
  3. Send result of second connection over first connection

Lesson: don't have Alice and Bob do exactly the same thing.

• Use different keys: totally different or $K_{\text{Alice-Bob}}=K_{\text{Bob-Alice}}+1$
• Refuse to compute challenge for old random number
• Initiator should be the first to prove identity (assumption: initiator is more likely to be bad guy)

Password Guessing

Since Bob sends back $f(K_{\text{Alice-Bob}},R_{2})$, it's possible to attempt password guessing attack

Countermeasure:

1. Alice: "I'm Alice."
2. Bob: "Alice, I challenge you with this random number $R_{1}$."
3. Alice: "$f(K_{\text{Alice-Bob}},R_{1})$. Bob, I challenge you with this random number $R_{2}$."

Timestamp

Requires synchronized clocks

1. Alice: send encrypted value of current timestamp
2. Bob: Reply with encrypted value of timestamp + 1

Establishment of Session Keys

Suppose following authentication happened:

1. Alice: "I'm Alice"
2. Bob: "$R$"
3. Alice: "$K_{\text{Alice-Bob}}\{R\}$"

• Can't use $K_{\text{Alice-Bob}}\{R\}$ as session key (already transmitted over network)
• Can't use $K_{\text{Alice-Bob}}\{R+1\}$ as session key (Trudy could impersonate Bob and get $R+1$ from Alice
• In general, something should be done with key, not $R$.

Two-Way Public Key Based Authentication

Better Approach:

• Alice chooses and encrypts $R_{1}$ with Bob's public key
• Bob chooses and encrypts $R_{2}$ with Alice's public key
• Session key is $R_{1}\oplus R_{2}$
• Trudy will have to compromise both Alice and Bob

Even better:

• Alice and Bob establish session key with Diffie-Hellman key exchange
• Alice and Bob sign quantity they send
• Trudy can't learn anything about session key even if she compromises both Alice and Bob (since key is negotiated through Diffie-Hellman)

One-Way Public Key Based Authentication

Often it's only necessary to authenticate the server (e.g. SSL)

1. Encrypt $R$ with Bob's public key
2. Diffie-Hellman key exchange (Bob signs D-H key)

Mediated authentication (with KDC)

Trusted, third-party Server controls authentication to other machines

In principle:

1. Alice to KDC: Alice wants Bob
2. KDC generates $K_{AB}$
3. KDC to Alice: $K_{\text{Alice}}\{K_{AB}\}$
4. KDC to Bob: $K_{\text{Bob}}\{K_{AB}\}$

Concerns:

• Trudy may claim to be Alice and talk to KDC (may not get anything useful)
• Messages encrypted by Alice may get to Bob before KDC's message (Bob does not have key from KDC yet)
• May be difficult for KDC to connect to Bob

In practice:

1. Alice to KDC: Alice wants Bob
2. KDC generates $K_{AB}$
3. KDC to Alice: $K_{\text{Alice}}\{K_{AB}\}$ and $K_{\text{Bob}}\{K_{AB}\}$
4. Alice to Bob: $K_{\text{Bob}}\{K_{AB}\}$ (this is called a ticket)

Solves second issue, but still not completely secure.