Security Protocols and Authentication in Networks

Part III: Protocols Part 3 Protocols 1

Protocol Human protocols 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. Properties for the Ideal Security Protocol o Must satisfy securityrequirements: 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 Secure Entry to NSA Insert badge into reader Enter PIN Correct PIN? Yes? Enter No? Get shot by security guard 1. 2. 3. ATM Machine Protocol Insert ATM card Enter PIN Correct PIN? Yes? Conduct your transaction(s) No? Machine (eventually) eats card 1. 2. 3. 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 3. N SAAF Impala K 4. E(N,K) Angola 2. N 5. E(N,K) 6. E(N,K) 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 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 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, etc. o Anonymity, plausible deniability, perfect forward secrecy, etc. 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) 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 o Subject to a replay attack (next 2 slides) o Also, Bob must know Alice s password Authentication Attack 1. I m Alice 2. Prove it 3. My password is frank Alice Bob 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 I m Alice, my password is frank Alice Bob 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 Nonce: Challenge-Response But still subject to replay attack o To prevent replay, need ensure freshness To ensure freshness, employ a nonce; Nonce == number used once o If Bob wants to authenticate Alice Challenge sent from Bob to Alice What should Alice do with the nonce? That is, how to compute the response? o o Challenge is chosen so that Replay is not possible Only Alice can provide the correct response Bob can verify the response How can Bob verify the response? Should we use passwords or keys?

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? 1. I m Alice 2. Nonce 3. 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 Part 3 Protocols 12

Authentication Using Symmetric Keys Hashed password works, but encryption is much better here (why?) 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, notattacks 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? o Cannot reveal key, must prevent replay (or other) attack, must be verifiable, 1. I m Alice 2. R 3. E(R,K) Bob, K Alice, 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 mutualauthentication? 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 o Once for Bob to authenticate Alice and Once for Alice to authenticate Bob 1. I m Alice , RA 2. RB, E(RA, K) 3. E(RB, K) Alice, 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) Bob, K Trudy 3. I m Alice , RB 4. RC, E(RB, K) Bob, K Trudy non-mutual authentication protocol may not be secure for mutual authentication. Part 3 Protocols 16

Mutual Authentication Our one-way authentication protocol is notsecure 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 Symmetric Key Mutual Authentication 1. I m Alice , RA 2. RB, E( Bob ,RA,K) 3. E( Alice ,RB,K) Bob, K Alice, 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 o 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 EncryptMwith Alice s publickey: C = {M}Alice M = [C]Alice SignMwith Alice s privatekey: 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 Anybodycan 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 3. R Alice 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 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 3. [R]Alice Bob Alice Is this secure? Trudy can get Alice to sign anything! 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 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 distinctsession keys to encrypt data within each connection Usually, a session key is required o It is a temporary symmetric key for the current session o Used for confidentiality and/or integrity 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 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 How to authenticate and establish a session key (i.e. shared symmetric key)? o When authentication completed, Alice and Bob share a sessionkey o Trudy cannot break the authentication and o Trudy cannot determine the sessionkey Authentication & Session Key It looks to be straightforward to include a session key using the secure public key authentication protocol o 1. I m Alice , R 2. {R, K}Alice 3. {R +1, K}Bob Alice Bob Is this secure? o Alice is authenticated and sessionkey is secure o Alice s nonce R is useless to authenticate Bob o The key Kis acting as Bob s nonce to Alice 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 3. [R +1, K]Alice Bob Alice 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 3. {[R +1, K]Alice}Bob 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 MiM 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 6. time out ??? Trudy Bob Alice 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, 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) 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 timestampT 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 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 2. {[T +1, K]Bob}Alice Alice Bob It provides the timestampversion 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? 1. I m Alice , [{T, K}Bob]Alice 2. [{T +1, K}Alice]Bob 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

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? 1. I m Alice , [{T, K}Bob]Alice 2. [{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?

Public Key Authentication Public Key Authentication o Sign and encrypt with nonce Insecure (MiM) 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) Consider this issue o Alice encrypts message with shared keyK 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) Perfect forward secrecy (PFS): Trudy cannot later decrypt recorded ciphertext o Even if Trudy gets key K or other secret(s) For perfect forward secrecy, Alice and Bob cannot use K to encrypt Instead they must use a session key KSand 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

Nave Session Key Protocol E(KS, K) E(messages, KS) Bob, K Alice, 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 No perfect forward secrecy in this case Part 3 Protocols 30

Diffie-Hellman There are 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 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 gamod p to Bob Bob sends gbmod p to Alice Both compute shared secret, gabmod p Shared secret can be used as symmetric key Part 1 Cryptography 32

Diffie-Hellman Public:g and p Private:Alice s exponent a, Bob s exponent b ga mod p gb mod p Bob, b Alice, a Alice computes (gb)a = gba = gab mod p Bob computes (ga)b = gab mod p 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 Trudy can see ga mod p and gb mod p But ga gb mod p = ga+b mod p gab mod p o If Trudy can find a or b, she gets K If Trudy can solve discrete log problem, she can find a or b https://www.doc.ic.ac.uk/~mrh/330tutor/ch06.html Part 1 Cryptography 33

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

Perfect Forward Secrecy (PFS) We can use Diffie-Hellman for PFS Recall: public g and p ga mod p gb mod p Alice, a Bob, b But Diffie-Hellman is subject to MiM, How to get PFS and prevent MiM? E(ga mod p, K) E(gb mod p, K) Alice: K, a Bob: K, b Session key KS = gab mod p Alice forgetsa, Bob forgetsb 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 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 Bob Alice 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 Part 3 Protocols 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 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 TCP Three Way Handshake (SYN,SYN-ACK,ACK) TCP 3-way Handshake 3-messages transmitted by TCP to negotiate and start a TCP session o 1. SYN, SEQ a 2. SYN, ACK a+1, SEQ b 3. ACK b+1, data Bob Alice 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 ? Bob Trudy 5. 5. 5. DoS? Alice Suppose that Trudy can use b1 to predict Bob's next initial SEQ value b2 5. Part 3 Protocols 40

TCP Authentication Attack Initial SEQ numbers Mac OS X Random SEQ numbers If initial SEQ numbers not very random possible to guess initial SEQ number and previous attack will succeed 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 Part 3 Protocols 41

Zero Knowledge Proofs Part 3 Protocols 42

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, how? P Bob sCave Q o Alice knows secret phrase to open path between R and S( open sarsaparilla ) R S o Can she convince Bob that she knows the secret without revealing phrase? Part 3 Protocols 43

Bobs Cave Bob: Alice, come out on Sside 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 44

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 Part 3 Protocols 53