1. Simple Authentication Protocols
Part 3  Protocols

2. Protocol Human protocols  Rules followed in human interactions
Example: Asking a question in class
Networking protocols  Rules followed in networked communication systems
Examples: HTTP, FTP, etc.
Security protocol  the (communication) rules followed in a security application
Examples: SSL, IPSec, Kerberos, etc.
Properties for the Ideal Security Protocol
Must satisfy security requirements:
Requirements need to be precise
Efficient:
Minimize computational requirement, Minimize bandwidth usage, delays…
Robust:
Works when attacker tries to break it, Works if environment changes (slightly)
Easy to implement, easy to use, flexible…
Difficult to satisfy all of these!
Part 3  Protocols

3. Examples Secure Entry to NSA ATM Machine Protocol
Insert badge into reader
Enter PIN
Correct PIN?
Yes? Enter
No? Get shot by security guard
ATM Machine Protocol
Insert ATM card
Enter PIN
Correct PIN?
Yes? Conduct your transaction(s)
No? Machine (eventually) eats card
Part 3  Protocols

4. Identify Friend or Foe (IFF)
Russian
MIG
Angola
2. E(N,K)
SAAF
Impala K
1. N
Namibia K
Part 3  Protocols

5. MIG in the Middle K Angola Namibia K 3. N SAAF Impala 4. E(N,K) 2. N
Russian
MiG
1. N
Namibia K
Part 3  Protocols

6. Authentication Protocols
Suppose that Alice must prove to Bob that she's Alice,
where Alice and Bob are communicating over a network.
Keep in mind that:
Alice can be a human or a machine, and ditto (the same thing again) for Bob.
In fact, in networked environment, Alice and Bob will almost invariably be machines, and this has important implications.
In many cases, it's sufficient for Alice to prove her identity to Bob, without Bob proving his identity to Alice.
But sometimes mutual authentication is necessary,
that is, Bob must also prove his identity to Alice.
Part 3  Protocols

7. Authentication Alice must prove her identity to Bob
Alice and Bob can be humans or computers
May also require Bob to prove that he is Bob (mutual authentication)
Probably need to establish a session key
May have other requirements, such as
Public keys, symmetric keys, hash functions, … etc.
Authentication on a stand-alone computer is relatively simple
For example, hash a password with a 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)
Part 3  Protocols

8. Simple Authentication
1. “I’m Alice”
2. Prove it
3. My password is “frank”
Alice
Bob
Simple and may be OK for standalone system
But highly insecure for networked system
Subject to a replay attack (next 2 slides)
Also, Bob must know Alice’s password
Authentication Attack
Alice
Bob
1. “I’m Alice”
2. Prove it
3. My password is “frank”
Trudy
Part 3  Protocols

9. Authentication Attack
1. “I’m Alice”
2. Prove it
3. My password is “frank”
Trudy
Bob
This is an example of a replay attack
How can we prevent a replay?
Simple Authentication
Alice
Bob
I’m Alice, my password is “frank”
More efficient, but…
… same problem as previous version
Part 3  Protocols

10. Better Authentication
1. “I’m Alice”
2. Prove it
3. h(Alice’s password)
Alice
Bob
This approach hides Alice’s password From both Bob and Trudy
But still subject to replay attack
To prevent replay, need ensure “freshness”
If 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: Challenge-Response
To ensure freshness, employ a nonce; Nonce == number used once
What should Alice do with the nonce?
That is, how to compute the response?
How can Bob verify the response?
Should we use passwords or keys?

11. Generic Challenge-Response
1. “I’m Alice”
2. Nonce
3. Something that could only be
from Alice, and Bob can verify
Bob
Alice
In practice, how to achieve this?
Bob
1. “I’m Alice”
2. Nonce
3. h(Alice’s password, Nonce)
Alice
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
Part 3  Protocols

12. Authentication Using Symmetric Keys
Hashed password works, but……encryption is much 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 cryptography
So, we assume crypto algorithms are secure
Note:
When discussing protocols, the primarily concern is attacks on protocols, not attacks on the cryptography used in protocols.
Consequently, we'll assume that the underlying cryptography is secure
Part 3  Protocols

13. Authentication: Symmetric Key
Alice and Bob share symmetric key K, which is known only to them
Alice will authenticate herself to Bob by proving that she knows the key
How to accomplish this?
Cannot reveal key, must prevent replay (or other) attack, must be verifiable, …
Alice, K
Bob, K
1. “I’m Alice”
2. R
3. E(R,K)
Secure method for Bob to authenticate Alice (prevents a replay attack)
But, Alice does not authenticate Bob (lacks mutual authentication)
So, how can we achieve mutual authentication?
Part 3  Protocols

14. Mutual Authentication?
1. “I’m Alice”, R
2. E(R,K)
3. E(R,K)
Alice, K
Bob, K
What’s wrong with this picture? “Alice” could be Trudy (or anybody else)! (2 vs. 3)
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 and Once for Alice to authenticate Bob
Alice, K
Bob, K
1. “I’m Alice”, RA
2. RB, E(RA, K)
3. E(RB, K)
This provides mutual authentication……or does it?
But, subject to reflection attack, which is a method of attacking a challenge-response authentication system

15. Mutual Authentication Attack: Reflection Attack
1. “I’m Alice”, RA
2. RB, E(RA, K)
5. E(RB, K)
Bob, K
Trudy
3. “I’m Alice”, RB
4. RC, E(RB, K)
Trudy
Bob, K
Note: non-mutual authentication protocol may not be secure for mutual authentication.
Part 3  Protocols

16. Mutual Authentication
Our one-way authentication protocol is not secure for mutual authentication
“obvious“ any simple changes to protocols can cause unexpected security problems
Also, if assumptions or environment change, protocol may not be secure
This is a common source of security failure
Symmetric Key Mutual Authentication
Alice, K
Bob, K
1. “I’m Alice”, RA
2. RB, E(“Bob”,RA,K)
3. E(“Alice”,RB,K)
Do these “insignificant” changes help?
Yes!
Encrypting user's identity together with the nonce (R) is sufficient to prevent the previous attack since Trudy cannot use a response from Bob for the third message
Part 3  Protocols

17. Authentication Using Public Keys
Remember that in public key cryptography:
anybody can do public key operations, while
only Alice can use her private key.
Public Key Notation
Encrypt M with Alice’s public key: C = {M}Alice  M = [C]Alice
Sign M with Alice’s private key: C = [M]Alice  M = {C}Alice
Then
[{M}Alice ]Alice = M : This is called Encrypt & Sign
{[M]Alice }Alice = M : This is called Sign & Encrypt
Anybody can use Alice’s public key
Only Alice can use her private key
Part 3  Protocols

18. Authentication with Public Key
Alice
Bob
1. “I’m Alice”
2. {R}Alice
3. R
Is this secure?
a replay attack is not feasible, Trudy cannot replay R from a previous iteration
But, Trudy can get Alice to decrypt anything! i.e. previously recorded C can be sent to Alice
not to use the same key pair for signing as you use for encryption.
Can we do better using digital signatures?
Alice
Bob
1. “I’m Alice”
2. R
3. [R]Alice
Is this secure?
Trudy can get Alice to sign anything!
Same as previous  should have two key pairs
…one key pair for encryption/decryption and signing/verifying signatures…
…and a different key pair for authentication
Note: in both cases Alice applies her private key to whatever shows up in message two

19. Session Key
Along with authentication, often we need to share a session key
Even when a symmetric key is used for authentication
We may need a distinct session keys to encrypt data within each connection
Usually, a session key is required
It is a temporary symmetric key for the current session
Used for confidentiality and/or integrity
Why session keys ?
Limits the amount of data encrypted with any one particular key and
Limits the damage if one session key is compromised
Thus, establishing the session key as part of the authentication protocol.
That is, when the authentication is complete, we will also have securely established a shared symmetric key
Therefore, when analyzing an authentication protocol, we need to consider attacks on the authentication itself, as well as attacks on the session key
Part 3  Protocols

20. Session Key
How to authenticate and establish a session key (i.e. shared symmetric key)?
When authentication completed, Alice and Bob share a session key
Trudy cannot break the authentication…and
Trudy cannot determine the session key
Authentication & Session Key
It looks to be straightforward to include a session key using the secure public key authentication protocol
Alice
Bob
1. “I’m Alice”, R
2. {R, K}Alice
3. {R +1, K}Bob
Is this secure?
Alice is authenticated and session key is secure
Alice’s “nonce” R is useless to authenticate Bob
The key K is acting as Bob’s nonce to Alice
No mutual authentication --only Alice is authenticated
Part 3  Protocols

21. Public Key Authentication and Session Key
Alice
Bob
1. “I’m Alice”, R
2. [R, K]Bob
3. [R +1, K]Alice
It uses digital signatures instead of public key encryption, Is this secure?
It does provide Mutual Authentication (very good),
but…fatal flaw… session key is not protected (very bad)
Can we combine these two to achieve both mutual authentication and a secure session key?
Alice
Bob
1. “I’m Alice”, R
2. {[R, K]Bob}Alice
3. {[R +1, K]Alice}Bob
It provides mutual authentication and a session key using sign and encrypt
Is this secure?
No! It’s subject to subtle/elusive MiM attack, See the next slide…

22. Public Key Authentication and Session Key
1. “I’m Alice”, R
2. “I’m Trudy”, R
4. {[R, K]Bob}Alice
3. {[R, K]Bob}Trudy
5. {[R +1, K]Alice}Bob
6. time out ???
Trudy
Alice
Bob
Trudy can get [R, K]Bob and K from 3. Then Trudy can apply Bob’s public key and get R and K
Alice uses this same key K
And Alice thinks she’s talking to Bob, and K now is with Trudy
Part 3  Protocols

23. Public Key Authentication and Session Key
What about the encrypt and sign approach?
1. “I’m Alice”, R
2. [{R, K}Alice]Bob
3. [{R +1, K}Bob]Alice
Alice
Bob
Is this secure?
Seems to be OK, but Anyone can see {R, K}Alice and {R +1, K}Bob,
Available to anyone who has access to Alice's or Bob's public keys
Which, by assumption, is anybody who wants them
But, they can be recorded but not decrypted
Part 3  Protocols

24. Timestamps instead of nonces (R)
Timestamps can be used instead of nonces
Assuming that the current time is known to both Alice and Bob
Alice sends the time she performed her calculation and Bob accepts if it is within the clock skew
A timestamp T is derived from current time (value in milliseconds)
current timestamp ensures freshness
Timestamps can be used to prevent replay (good)(i.e. Used in Kerberos protocol)
Timestamps reduce number of messages (good)
A challenge that both sides know in advance (potential for increased efficiency)
“Time” is a security-critical parameter (bad)
Attack Alice's system clock and then you cause Alice's authentication to fail
Clocks not same and/or network delays are present,
Thus, must allow for clock skew  creates risk of replay
How much clock skew is enough?
Too much: Trudy can do a replay.
Too little: the protocol will be unusable.

25. Public Key Authentication with Timestamp T
1. “I’m Alice”, {[T, K]Alice}Bob
2. {[T +1, K]Bob}Alice
Alice
Bob
It provides the timestamp version of the sign and encrypt protocol
Secure mutual authentication? Session key secure? Seems to be OK !?
Is the timestamp version of the following encrypt and sign also secure?
Bob
Alice
1. “I’m Alice”, [{T, K}Bob]Alice
2. [{T +1, K}Alice]Bob
Secure authentication and session key?
No, The obvious is not always correct!
Trudy can use Alice’s public key to find {T, K}Bob and then…open a connection and send it to Bob…then Bob will send the key K to Trudy

26. Public Key Authentication with Timestamp T
1. “I’m Trudy”, [{ T, K }Bob]Trudy
2. [{T +1, K}Trudy]Bob
Trudy
Bob
Trudy obtains Alice-Bob shared session key K.
Note: Trudy must act within clock skew
Can we improve/secure it?
Bob
Alice
1. “I’m Alice”, [{T, K}Bob]Alice
2. [{T +1}Alice]Bob
Is this “encrypt and sign” secure?
Yes, seems to be OK
Does “sign and encrypt” also work here?

27. Public Key Authentication
Sign and encrypt with nonce…
Insecure (MiM)
Encrypt and sign with nonce…
Secure
Sign and encrypt with timestamp…
Encrypt and sign with timestamp…
Insecure
Protocols can be subtle!
Part 3  Protocols

28. Zero Knowledge Proofs
Part 3  Protocols

29. Zero Knowledge Proof (ZKP)
Alice wants to prove that she knows a secret without revealing any info about it
Bob must verify that Alice knows secret
But, Bob gains no information about the secret
Process is probabilistic
Bob can verify that Alice knows the secret to an arbitrarily high probability, how? P
Bob’s Cave
Alice knows secret phrase to open path between R and S (“open sarsaparilla”)
Can she convince Bob that she knows the secret without revealing phrase? Q R S
Part 3  Protocols

30. Bob’s Cave Bob: “Alice, come out on S side” P
Alice (quietly): “Open sarsaparilla” Q
If Alice does not know the secret… R S
…then Alice could come out from the correct side with probability 1/2
If Bob repeats this n times and Alice does not know secret, she can only fool Bob with probability (1/2)n
Part 3  Protocols

31. Best Authentication Protocol?
It depends on…
The sensitivity of the application/data
The delay that is tolerable
The cost (computation) that is tolerable
What crypto is supported (public key, symmetric key, …)
Whether mutual authentication is required
Whether PFS, anonymity, etc., are concern
…and possibly other factors
Part 3  Protocols