Simple Authentication Protocols Part 3 Protocols 1 Protocol

Simple Authentication Protocols Part 3 Protocols 1

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

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

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

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

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 6

Authentication q Alice must prove her identity to Bob o Alice and Bob can be humans or computers q q q 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 o Public keys, symmetric keys, hash functions, … etc. q 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 q Authentication over a network is challenging o Attacker can passively observe messages o Attacker can replay messages o Active attacks possible (insert, delete, change) Part 3 Protocols 7

Simple Authentication 1. “I’m Alice” 2. Prove it 3. My password is “frank” Alice q q Bob 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 q Authentication Attack 1. “I’m Alice” 2. Prove it 3. My password is “frank” Alice Part 3 Protocols Bob Trudy 8

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

Better Authentication 1. “I’m Alice” 2. Prove it Alice q q 3. h(Alice’s password) Bob This approach hides Alice’s password From both Bob and Trudy But still subject to replay attack q Nonce: Challenge-Response o To prevent replay, need ensure q To ensure freshness, employ a nonce; o If Bob wants to authenticate Alice q What should Alice do with the nonce? “freshness” § Challenge sent from Bob to Alice o Challenge is chosen so that… § Replay is not possible § Only Alice can provide the correct response § Bob can verify the response Nonce == number used once o That is, how to compute the response? q How can Bob verify the response? q Should we use passwords or keys?

Generic Challenge-Response 1. “I’m Alice” 2. Nonce Alice q 3. Something that could only be from Alice, and Bob can verify Bob In practice, how to achieve this? 1. “I’m Alice” 2. Nonce Alice 3. h(Alice’s password, Nonce) Bob Nonce is the challenge q The hash is the response q Nonce prevents replay (ensures freshness) q Password is something Alice knows q Note: Bob must know Alice’s pwd to verify q Part 3 Protocols 11

Authentication Using Symmetric Keys q Hashed password works, but……encryption is much better here (why? ) q Symmetric Key Notation o Encrypt plaintext P with key K C = E(P, K) o Decrypt ciphertext C with key K P = D(C, K) o 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 12

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

Mutual Authentication? 1. “I’m Alice”, R 2. E(R, K) Alice, K q q q 3. E(R, 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 o Once for Bob to authenticate Alice and Once for Alice to authenticate Bob 1. “I’m Alice”, RA 2. RB, E(RA, K) Alice, K q q 3. E(RB, K) Bob, K This provides mutual authentication……or does it? But, subject to reflection attack, which is a method of attacking a challenge-response authentication system

Mutual Authentication Attack: Reflection Attack 1. “I’m Alice”, RA 2. RB, E(RA, K) Trudy 5. E(RB, K) Bob, K 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 15

Mutual Authentication q Our one-way authentication protocol is not secure for mutual authentication o “obvious“ any simple changes to protocols can cause unexpected security problems o Also, if assumptions or environment change, protocol may not be secure o This is a common source of security failure q Symmetric Key Mutual Authentication 1. “I’m Alice”, RA 2. RB, E(“Bob”, RA, K) Alice, K 3. E(“Alice”, RB, K) q Do these “insignificant” changes help? q Yes! Bob, K o 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 16

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 Sign M with Alice’s private key: C = [M]Alice M = [C]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 17

Authentication with Public Key 1. “I’m Alice” 2. {R}Alice q q q Bob 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 o q 3. R not to use the same key pair for signing as you use for encryption. Can we do better using digital signatures? 1. “I’m Alice” 2. R Alice q q q 3. [R]Alice Is this secure? Trudy can get Alice to sign anything! Bob o 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

Session Key q Along with authentication, often we need to share a session key o Even when a symmetric key is used for authentication o We may need a distinct session keys to encrypt data within each connection q Usually, a session key is required o It is a temporary symmetric key for the current session o Used for confidentiality and/or integrity q Why session keys ? o Limits the amount of data encrypted with any one particular key and o Limits the damage if one session key is compromised q Thus, establishing the session key as part of the authentication protocol. o That is, when the authentication is complete, we will also have securely established a shared symmetric key o 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 19

Session Key q 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…and o Trudy cannot determine the session key q Authentication & Session Key o It looks to be straightforward to include a session key using the secure public key authentication protocol 1. “I’m Alice”, R 2. {R, K}Alice q 3. {R +1, K}Bob Is this secure? o Alice is authenticated and session key is secure o Alice’s “nonce” R is useless to authenticate Bob o The key K is acting as Bob’s nonce to Alice q No mutual authentication --only Alice is authenticated Part 3 Protocols 20

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

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

Public Key Authentication and Session Key q What about the encrypt and sign approach? 1. “I’m Alice”, R 2. [{R, K}Alice]Bob Alice q q 3. [{R +1, K}Bob]Alice Bob Is this secure? Seems to be OK, but Anyone can see {R, K}Alice and {R +1, K}Bob, o 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 23

Timestamps instead of nonces (R) q Timestamps can be used instead of nonces o 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 o A timestamp T is derived from current time (value in milliseconds) § current timestamp ensures freshness o Timestamps can be used to prevent replay (good)(i. e. Used in Kerberos protocol) o Timestamps reduce number of messages (good) § A challenge that both sides know in advance (potential for increased efficiency) o “Time” is a security-critical parameter (bad) § Attack Alice's system clock and then you cause Alice's authentication to fail q Clocks not same and/or network delays are present, o Thus, must allow for clock skew creates risk of replay o How much clock skew is enough? § Too much: Trudy can do a replay. § Too little: the protocol will be unusable.

Public Key Authentication with Timestamp T 1. “I’m Alice”, {[T, K]Alice}Bob Alice 2. {[T +1, K]Bob}Alice q Bob It provides the timestamp version of the sign and encrypt protocol q Secure mutual authentication? Session key secure? Seems to be OK !? q Is the timestamp version of the following encrypt and sign also secure? 1. “I’m Alice”, [{T, K}Bob]Alice 2. [{T +1, K}Alice]Bob Alice q Secure authentication and session key? q q Bob 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

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

Public Key Authentication q Public Key Authentication o Sign and encrypt with nonce… § Insecure (Mi. M) o Encrypt and sign with nonce… § Secure o Sign and encrypt with timestamp… § Secure o Encrypt and sign with timestamp… § Insecure o Protocols can be subtle! Part 3 Protocols 27

Zero Knowledge Proofs Part 3 Protocols 34

Zero Knowledge Proof (ZKP) q q 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 q Process is probabilistic o Bob can verify that Alice knows the secret to an arbitrarily high probability, how? q P Bob’s Cave o Alice knows secret phrase to open path between R and S (“open sarsaparilla”) Q R S o Can she convince Bob that she knows the secret without revealing phrase? Part 3 Protocols 35

Bob’s Cave q q Bob: “Alice, come out on S side” P Alice (quietly): “Open sarsaparilla” Q q q 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 36

Best Authentication Protocol? q 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 q …and possibly other factors Part 3 Protocols 37