Part III Protocols Part 3 Protocols 1 Protocol

Part III: 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

Chapter 9: Simple Security Protocols “I quite agree with you, ” said the Duchess; “and the moral of that is ‘Be what you would seem to be’ or if you'd like it put more simply ‘Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. ’ ” Lewis Carroll, Alice in Wonderland Seek simplicity, and distrust it. Alfred North Whitehead Part 2 Access Control 3

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 4

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

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 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 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 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 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, … etc. o Anonymity, plausible deniability, perfect forward secrecy, 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 8

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 9

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 10

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 12

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 13

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 14

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 non-mutual authentication protocol may not be secure for mutual authentication. Part 3 Protocols 16

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 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 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 18

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, 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 20

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 21

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 23

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 § They can be recorded but not decrypted Part 3 Protocols 24

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 28

Perfect Forward Secrecy (PFS) q 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 (ciphertext) q Perfect forward secrecy (PFS): Trudy cannot later decrypt recorded ciphertext o Even if Trudy gets key K or other secret(s) q q q 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? Part 3 Protocols 29

Naïve Session Key Protocol E(KS, K) E(messages, KS) Alice, K q q Bob, K Trudy could record E(KS, K)& E(messages, KS) If Trudy later gets K then she can get KS o Then Trudy can decrypt recorded messages q No perfect forward secrecy in this case Part 3 Protocols 30

Diffie-Hellman There actually several ways to achieve PFS, but the most elegant approach is to use the: ephemeral Diffie-Hellman (DH) key exchange However, the crucial weakness with Diffie-Hellman is that it is subject to a man-in-the-middle (MIM) attack Thus, if we are to use Diffie-Hellman for PFS, we must prevent the man-in-the-middleattack, and, of course, we must somehow assure PFS Part 1 Cryptography 31

Diffie-Hellman (DH) Key Exchange q q q Invented by Williamson (GCHQ) and, independently, by D and H (Stanford) A “key exchange” algorithm o Used to establish a shared symmetric key o Not for encrypting or signing Based on discrete log problem o Given: g, p, and gk mod p o Find: exponent k Let p be prime, Let g be a generator (i. e. gn mod p can take on any value between 1 and p− 1) o For any x {1, 2, …, p-1} there is n s. t. x = gn mod p Alice selects her private value a Bob selects his private value b Alice sends ga mod p to Bob sends gb mod p to Alice Both compute shared secret, gab mod p Shared secret can be used as symmetric key Part 1 Cryptography 32

Diffie-Hellman q q Public: g and p Private: Alice’s exponent a, Bob’s exponent b ga mod p gb mod p Alice, a q Alice computes (gb)a = gba = gab mod p q Bob computes (ga)b = gab mod p Bob, b q They can use K = gab mod p as symmetric key Suppose Bob and Alice use Diffie-Hellman to determine symmetric key K = gab mod p q Trudy can see ga mod p and gb mod p q o But… ga gb mod p = ga+b mod p gab mod p q If Trudy can find a or b, she gets K q If Trudy can solve discrete log problem, she can find a or b https: //www. doc. ic. ac. uk/~mrh/330 tutor/ch 06. html Part 1 Cryptography 33

Diffie-Hellman q Subject to man-in-the-middle (Mi. M) attack ga mod p gt mod p gb mod p Alice, a Trudy, t q Trudy shares secret gat mod p with Alice Trudy shares secret gbt mod p with Bob q Alice and Bob don’t know Trudy is Mi. M q How to prevent Mi. M attack? q Bob, b o Encrypt DH exchange with symmetric key o Encrypt DH exchange with public key o Sign DH values with private key o Other? q At this point, DH may look pointless… o …but it’s not (more on this later) q You MUST be aware of Mi. M attack on Diffie-Hellman Part 1 Cryptography 34

Perfect Forward Secrecy (PFS) q q We can use Diffie-Hellman for PFS Recall: public g and p ga mod p gb mod p Alice, a q Bob, b But Diffie-Hellman is subject to Mi. M, How to get PFS and prevent Mi. M? E(ga mod p, K) E(gb mod p, K) Alice: K, a q q q Bob: K, b Session key KS = gab mod p Alice forgets a, Bob forgets b This is known as Ephemeral Diffie-Hellman (lasting for a very short time) Neither Alice nor Bob can later recover KS Are there other ways to achieve PFS?

Mutual Authentication, Session Key & PFS q To put it all together and design a mutual authentication protocol that establishes a session key with PFS. (encrypt and sign protocol) “I’m Alice”, RA RB, [{RA, gb mod p}Alice]Bob [{RB, ga mod p}Bob]Alice q Session key is K = gab mod p q Alice forgets a and Bob forgets b q If Trudy later gets Bob’s and Alice’s secrets, she cannot recover session key K Part 3 Protocols Bob 37

Authentication and TCP • Is it possible to use TCP for authentication? • Note: TCP was not designed for use in authentication. • However, there is an undeniable temptation to use the IP address in a TCP connection for authentication • For example: Suppose that Bob decides to rely on the completed three-way handshake to verify that he is connected to a specific IP address, which he knows belongs to Alice Part 3 Protocols 38

TCP-based Authentication q TCP not intended for use as an authentication protocol q But IP address in TCP connection may be (mis)used for authentication q Also, one mode of IPSec relies on IP address for authentication q TCP 3 -way Handshake TCP Three Way Handshake (SYN, SYN-ACK, ACK) o 3 -messages transmitted by TCP to negotiate and start a TCP session 1. SYN, SEQ a 2. SYN, ACK a+1, SEQ b Alice q q 3. ACK b+1, data Bob Initial sequence numbers: SEQ a and SEQ b • Supposed to be selected at random • If Bob verifies that ACK b+1 appears in 3, he has some reason to believe that Alice, at her known IP address, has received message 2 and responded If not, might have problems…

TCP Authentication Attack An underlying assumption here is that Trudy can't see the SYN-ACK packet; otherwise she would know b and she could easily forge the ACK, but ? 1. SYN, SEQ = t (as Trudy) 2. SYN, ACK = t+1, SEQ = b 1 … 3. SYN, SEQ = t (as Alice) Trudy Bob 5. ACK = b 2+1, data 5. 5. 5. Do. S? 5. Part 3 Protocols Alice SY. 4 N CK A , +1 t = , b 2 = Q SE Suppose that Trudy can use b 1 to predict Bob's next initial SEQ value b 2 40

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

Zero Knowledge Proofs Part 3 Protocols 42

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 43

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 44

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 53