Authentication Protocols for Secure Communication Networks

Simple Authentication 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

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 3

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

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 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 Alice must prove her identity to Bob o 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 o Public keys, symmetric keys, hash functions, 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 7

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 8

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 9

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 11

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 12

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 13

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

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 Trudycannot use a response from Bob for the third message o 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 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 17

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, often 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 19

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 20

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 22

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 But, they can be recorded but not decrypted Part 3 Protocols 23

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 27

Zero Knowledge Proofs Part 3 Protocols 34

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 35

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 36

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 37