Authentication Protocols

1
Protocol
 Human protocols  the rules followed in human interactions
o Example: Asking a question in class
 Networking protocols  rules followed in networked communication
systems
o Examples: HTTP, FTP, etc.
 Security protocol  the (communication) rules followed in a security
application
o Examples: SSL, IPSec, Kerberos, etc.

2
Protocols
 Protocol flaws can be very subtle
 Several well-known security protocols have significant flaws
o Including WEP, GSM, and IPSec
 Implementation errors can also occur
o Recently, IE implementation of SSL
 Not easy to get protocols right…

3
Ideal Security Protocol
 Must satisfy security requirements
o Requirements need to be precise
 Efficient
o Minimize computational requirement
o Minimize bandwidth usage, delays…
 Robust
o Works when attacker tries to break it
o Works if environment changes (slightly)
 Easy to implement, easy to use, flexible…
Difficult to satisfy all of these!
4
Simple Security Protocols

5
Secure Entry to NSA

1. Insert badge into reader

2. Enter PIN
3. Correct PIN?
Yes? Enter
No? Get shot by security guard

6
ATM Machine Protocol

1. Insert ATM card

2. Enter PIN
3. Correct PIN?
Yes? Conduct your transaction(s)
No? Machine (eventually) eats card

7
Identify Friend or Foe (IFF)

Russian
MIG
Angola

SAAF 2. E(N,K)
Impala
K 1. N
Namibia
K
8
MIG in the Middle

3. N
SAAF
Impala 4. E(N,K)
K 2. N
Angola

5. E(N,K)

6. E(N,K)
Russian
MiG
1. N
Namibia
K
9
Authentication Protocols

10
Authentication

 Alice must prove her identity to Bob

o 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
o Public keys, symmetric keys, hash functions, …

o Anonymity, plausible deniability, perfect forward secrecy, etc.

11
Authentication
 Authentication on a stand-alone computer is relatively simple
o For example, hash a password with a salt
o “Secure path,” attacks on authentication software, keystroke logging, etc., can be
issues
 Authentication over a network is challenging
o Attacker can passively observe messages
o Attacker can replay messages
o Active attacks possible (insert, delete, change)

12
Simple Authentication
 Simple and may be OK for standalone system
 But highly insecure for networked system
o Subject to a replay attack (next 2 slides)
o Also, Bob must know Alice’s password

“I’m Alice”

Prove it

My password is “frank”
Alice Bob

13
Authentication Attack

“I’m Alice”

Prove it

My password is “frank”
Alice Bob

Trudy
14
Authentication Attack

“I’m Alice”

Prove it

My password is “frank”
Trudy Bob

 This is an example of a replay attack

 How can we prevent a replay?

15
Simple Authentication

I’m Alice, my password is “frank”

Alice Bob

 More efficient, but…

 … same problem as previous version

16
Better Authentication

“I’m Alice”

Prove it

h(Alice’s password)
Alice Bob

 This approach hides Alice’s password

o From both Bob and Trudy
 But still subject to replay attack
17
Challenge-Response
 To prevent replay, use challenge-response
o Goal is to ensure “freshness”
 Suppose Bob wants to authenticate Alice
o Challenge sent from Bob to Alice
 Challenge is chosen so that…
o Replay is not possible
o Only Alice can provide the correct response
o Bob can verify the response

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

19
Challenge-Response

“I’m Alice”

Nonce

h(Alice’s password, Nonce)

Alice Bob

 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

20
Generic Challenge-Response

“I’m Alice”

Nonce

Something that could only be

Alice from Alice, and Bob can verify Bob
 In practice, how to achieve this?
 Hashed password works, but…
 …encryption is much better here (why?)

21
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
o So, we assume crypto algorithms are secure

22
Authentication: Symmetric Key
 Alice and Bob share symmetric key KAB
 Key KAB known only to Alice and Bob
 Authenticate by proving knowledge of shared symmetric key
 How to accomplish this?
o Cannot reveal key, must not allow replay (or other) attack, must be
verifiable, …

23
Authenticate Alice Using Symmetric Key
“I’m Alice”
R
E(R,KAB)
Alice, KAB Bob, KAB

 Secure method for Bob to authenticate Alice

 But, Alice does not authenticate Bob
 So, can we achieve mutual authentication?

24
Mutual Authentication?

“I’m Alice”, R

E(KAB,R)

E(KAB,R)
Alice, KAB Bob, KAB

 What’s wrong with this picture?

 “Alice” could be Trudy (or anybody else)!

25
Mutual Authentication
 Sincewe have a secure one-way authentication protocol…
 The obvious thing to do is to use the protocol twice
o Once for Bob to authenticate Alice
o Once for Alice to authenticate Bob
 This has got to work…

26
Mutual Authentication

“I’m Alice”, RA
RB, E(RA, KAB)

E(RB, KAB)
Alice, KAB Bob, KAB
 This provides mutual authentication…
 …or does it? Subject to reflection attack
o Next slide

27
Mutual Authentication Attack

1. “I’m Alice”, RA
2. RB, E(RA, K)

5. E(RB, K)
Trudy Bob, K

3. “I’m Alice”, RB

4. RC, E(RB, K)

Trudy Bob, K
28
Mutual Authentication
 Our one-way authentication protocol is not secure for mutual
authentication
o Protocols are subtle!
o In this case, “obvious” solution is not secure
 Also, if assumptions or environment change, protocol may not be secure
o This is a common source of security failure
o For example, Internet protocols

29
Symmetric Key Mutual Authentication
 Do these “insignificant” changes help?
 Yes!
“I’m Alice”, RA

RB, E(“Bob”,RA,KAB)

E(“Alice”,RB,KAB)
Alice, KAB Bob, KAB

30
Public Key Notation
 Encrypt M with Alice’s public key: {M}KpubA
 Sign M with Alice’s private key: [M] KprA
 Then
o [{M} KpubA ] KprA = M
o {[M] KprA } KpubA= M

 Anybody can use Alice’s public key

 Only Alice can use her private key

31
Public Key Authentication
“I’m Alice”
Figure 9.13.
{R}KpubA Authentication
with public key
R encryption

Alice Bob
• This protocol allows Bob to authenticate Alice, since only Alice can
compute the private key operation that is required in order to reply
with R in the third message.
Suppose Trudy has previously intercepted a message encrypted with Alice’s
public key, say, C ={M}KpubA. Then Trudy can pose as Bob and send C to Alice in
message two, and Alice will decrypt it and send the plaintext to Trudy.

32
Public Key Authentication
“I’m Alice”
R

[R]KprA
Alice Bob

Figure 9.14. Authentication with digital signature.

 Is this secure?
 Trudy can get Alice to sign anything!
o Same a previous  should have two key pairs

33
Public Keys
 Generally, a bad idea to use the same key pair for encryption and
signing
 Instead, should have…
o …one key pair for encryption/decryption and signing/verifying
signatures…
o …and a different key pair for authentication

34
Session Key
 Usually, a session key is required
o A symmetric key for current session
o Used for confidentiality and/or integrity
 How to authenticate and establish a session key (i.e., shared symmetric
key)?
o When authentication completed, Alice and Bob share a session key
o Trudy cannot break the authentication…
o …and Trudy cannot determine the session key

35
Authentication & Session Key

“I’m Alice”, R
{R, K}Alice

{R +1, K}Bob
Alice Bob
Figure 9.15. Authentication and a session key.

 Is this secure?
o Alice is authenticated and session key is secure
o Alice’s “nonce”, R, useless to authenticate Bob
o The key K is acting as Bob’s nonce to Alice
 No mutual authentication 36
Public Key Authentication and Session Key
“I’m Alice”, R
[R, K]Bob

[R +1, K]Alice
Alice Bob
Figure 9.16. Signature-based authentication and session key

 Is this secure?
o Mutual authentication (good), but…
o … session key is not protected (very bad)

37
Public Key Authentication and Session Key
“I’m Alice”, R
{[R, K]Bob}Alice

{[R +1, K]Alice}Bob

Alice Bob
Figure 9.17. Mutual authentication and session key

 Is this secure?
 No! It’s subject to subtle MiM attack
o See the next slide…

38
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

Alice Trudy Bob

 Trudy can get [R, K]Bob and K from 3.

 Alice uses this same key K
 And Alice thinks she’s talking to Bob

39
Public Key Authentication and Session Key
“I’m Alice”, R
[{R, K}Alice]Bob

[{R +1, K}Bob]Alice

Alice Bob
Figure 9.18. Encrypt and sign mutual authentication

 Is this secure?
 Seems to be OK
o Anyone can see {R, K}Alice and {R +1, K}Bob

40
Perfect Forward Secrecy
 Consider this “issue”…
o Alice encrypts message with shared key K and sends ciphertext to Bob
o Trudy records ciphertext and later attacks Alice’s (or Bob’s) computer to recover K
o Then Trudy decrypts recorded messages
 Perfect forward secrecy (PFS): Trudy cannot later decrypt recorded
ciphertext
o Even if Trudy gets key K or other secret(s)
 Is PFS possible?

41
Perfect Forward Secrecy
 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 KS and forget it after it’s used
 Can Alice and Bob agree on session key KS in a way that provides PFS?

42
Naïve Session Key Protocol
E(KS, K)
E(messages, KS)

Alice, K Bob, K

Figure 9.19. A naïve attempt at PFS

 Trudy could record E(KS, K)

 If Trudy later gets K then she can get KS
o Then Trudy can decrypt recorded messages
 No perfect forward secrecy in this case
43
Perfect Forward Secrecy
 We can use Diffie-Hellman for PFS
 Recall: public g and p

ga mod p
gb mod p

Alice, a Bob, b

Figure 9.20. Diffie-Hellman

 But Diffie-Hellman is subject to MiM

 How to get PFS and prevent MiM? 44
Perfect Forward Secrecy
E(ga mod p, K)
E(gb mod p, K)

Alice: K, a Bob: K, b

Figure 9.21. Ephemeral Diffie-Hellman for PFS

 Session key KS = gab mod p

 Alice forgets a, Bob forgets b
 This is known as Ephemeral Diffie-Hellman
 Neither Alice nor Bob can later recover K
S
 Are there other ways to achieve PFS? 45
Mutual Authentication, Session Key and PFS
“I’m Alice”, RA
RB, [RA, gb mod p]Bob

[RB, ga mod p]Alice

Alice Bob

Figure 9.22. Mutual authentication, session key, and PFS.

 Session key is K = gab 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
46
Timestamps
 A timestamp T is derived from current time can be used in place of a
nonce, since a current time stamp ensures freshness.
 Timestamps can be used to prevent replay
o Used in Kerberos, for example
 Timestamps reduce number of msgs (good)
o A challenge that both sides know in advance
 “Time” is a security-critical parameter (bad)
o Clocks not same and/or network delays, so must allow for clock skew  creates
risk of replay
o How much clock skew is enough?

47
Public Key Authentication with Timestamp T
“I’m Alice”, {[T, K]Alice}Bob

{[T +1, K]Bob}Alice

Alice Bob

Figure 9.23. Authentication using a timestamp

 Secure mutual authentication?

 Session key secure?
 Seems to be OK

48
Public Key Authentication with Timestamp T

“I’m Alice”, [{T, K}Bob]Alice

[{T +1, K}Alice]Bob

Alice Bob
Figure 9.24. Encrypt and sign using a timestamp

 Secure authentication and session key?

 Trudy can use Alice’s public key to find

{T, K}Bob and then…

49
Public Key Authentication with Timestamp T

“I’m Trudy”, [{T, K}Bob]Trudy

[{T +1, K}Trudy]Bob

Trudy Bob

Figure 9.25. Trudy’s attack on encrypt and sign

 Trudy obtains Alice-Bob session key K

 Note: Trudy must act within clock skew

50
Public Key Authentication with Timestamp T
 Here there’s no reason to return the key K in the second
message, since Alice already knows K and the only purpose of
this message is to authenticate Bob.
 This secure version of the encrypt and sign protocol is illustrated
in Figure 9.26.

51
Public Key Authentication with Timestamp T
 Here there’s no reason to return the key K in the second
message, since Alice already knows K and the only purpose of
this message is to authenticate Bob.
“I’m Alice”, [{T, K}Bob]Alice

[{T +1}Alice]Bob

Alice Bob
 Is this “encrypt and sign” secure?
o Yes, seems to be OK
 Does “sign and encrypt” also work here?
52
Public Key Authentication
 Sign and encrypt with nonce…
o Insecure
 Encrypt and sign with nonce…
o Secure
 Sign and encrypt with timestamp…
o Secure
 Encrypt and sign with timestamp…
o Insecure
 Protocols can be subtle!

53
Authentication and TCP

54
TCP-based Authentication

 TCP not intended for use as an authentication

protocol
 But IP address in TCP connection may be (mis)used
for authentication
 Also, one mode of IPSec relies on IP address for
authentication

55
TCP 3-way Handshake

SYN, SEQ a
SYN, ACK a+1, SEQ b
ACK b+1, data
Alice Bob
 First message is a synchronization request, or SYN, whereas
 The second message, which acknowledges the synchronization request, is
a SYN-ACK, and the third message—which can also contain data—
acknowledges the previous message, and is simply known as an ACK.

56
TCP Authentication Attack
1. SYN, SEQ = t (as Trudy)
2. SYN, ACK = t+1, SEQ = b1

…
3. SYN, SEQ = t (as Alice)
Trudy Bob
5. ACK = b2+1, data

5. = b2
E Q
5. 1 , S
= t+
5. K
, AC
Y N
5. Alice 4.
S

57
TCP Authentication Attack

Initial SEQ numbers

Random SEQ numbers Mac OS X
 If initial SEQ numbers not very random…
 …possible to guess initial SEQ number…
 …and previous attack will succeed
58
TCP Authentication Attack
 Trudy cannot see what Bob sends, but she can send packets to Bob, while posing as
Alice
 Trudy must prevent Alice from receiving Bob’s response (or else connection will
terminate)
 If password (or other authentication) required, this attack fails
 If TCP connection is relied on for authentication, then attack might succeed
 Bad idea to rely on TCP for authentication

59
Zero Knowledge Proofs

60
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
o But, Bob gains no information about the secret
 Process is probabilistic
o Bob can verify that Alice knows the secret to
an arbitrarily high probability
 An “interactive proof system”

61
 Bob’s Cave
 Alice knows secret
phrase to open path P
between R and S
(“open sarsaparilla”)
 Can she convince Q
Bob that she knows R S
the secret without
revealing phrase?

62
 Bob’s Cave
 Bob: “Alice, come out on S side” P

 Alice (quietly):
“Open sarsaparilla”
Q
 If Alice does not
R S
know the secret…
 …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/2n

63
Fiat-Shamir Protocol
 Cave-based protocols are inconvenient
o Can we achieve same effect without the cave?
 Finding square roots modulo N is difficult
o Equivalent to factoring
 Suppose N = pq, where p and q prime
 Alice has a secret S
 N and v = S2 mod N are public, S is secret
 Alice must convince Bob that she knows S
without revealing any information about S
64
Fiat-Shamir
x = r2 mod N
e  {0,1}
y = r  Se mod N
Alice Bob
secret S random e
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r, Bob chooses e  {0,1}
 Bob verifies: y2 = x  ve mod N
o Note that y2 = r2  S2e = r2  (S2)e = x  ve mod N

65
Fiat-Shamir: e = 1
x = r2 mod N
e=1
y = r  S mod N
Alice Bob
secret S random e
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r, Bob chooses e =1
 If y2 = x  v mod N then Bob accepts it
o And Alice passes this iteration of the protocol
 Note that Alice must know S in this case
66
Fiat-Shamir: e = 0
x = r2 mod N
e=0
y = r mod N
Alice Bob
secret S random e
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r, Bob chooses e = 0
 Bob must checks whether y2 = x mod N
 “Alice” does not need to know S in this case!

67
Fiat-Shamir
 Public: modulus N and v = S2 mod N
 Secret: Alice knows S
 Alice selects random r and commits to r by sending x = r2 mod N to Bob
 Bob sends challenge e  {0,1} to Alice
 Alice responds with y = r  Se mod N
 Bob checks whether y2 = x  ve mod N
o Does this prove response is from Alice?

68
Does Fiat-Shamir Work?
 If everyone follows protocol, math works:
o Public: v = S2 mod N
o Alice to Bob: x = r2 mod N and y = r  Se mod N
o Bob verifies: y2 = x  ve mod N
 Can Trudy convince Bob she is Alice?
o If Trudy expects e = 0, she follows the protocol: send x = r2 in msg 1 and y = r in
msg 3
o If Trudy expects e = 1, she sends x = r2  v1 in msg 1 and y = r in msg 3
 If Bob chooses e  {0,1} at random, Trudy can only trick Bob with
probability 1/2

69
Fiat-Shamir Facts
 Trudy can trick Bob with probability 1/2, but…
o …after n iterations, the probability that Trudy can convince Bob that she is Alice is
only 1/2n
o Just like Bob’s cave!
 Bob’s e  {0,1} must be unpredictable
 Alice must use new r each iteration, or else…
o If e = 0, Alice sends r mod N in message 3
o If e = 1, Alice sends r  S mod N in message 3
o Anyone can find S given r mod N and r  S mod N

70
Fiat-Shamir Zero Knowledge?
 Zero knowledge means that nobody learns anything about the secret S
o Public: v = S2 mod N
o Trudy sees r2 mod N in message 1
o Trudy sees r  S mod N in message 3 (if e = 1)
 If Trudy can find r from r2 mod N, she gets S
o But that requires modular square root calculation
o If Trudy could find modular square roots, she could get S from public v
 Protocol does not seem to “help” to find S

71
ZKP in the Real World
 Public key certificates identify users
o No anonymity if certificates sent in plaintext
 ZKP offers a way to authenticate without revealing identities
 ZKP supported in MS’s Next Generation Secure Computing Base
(NGSCB), where…
o …ZKP used to authenticate software “without revealing machine identifying data”
 ZKP is not just pointless mathematics!

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

73