Protocols

Part 3 Protocols 1Part III: Protocols Part 3 Protocols 2ProtocolHuman protocols the rules followed in human interactionsExample: Asking a question in classNetworking protocols rules followed in networked communication systemsExamples: HTTP, FTP, etc.Security protocol the (communication) rules followed in a security applicationExamples: SSL, IPSec, Kerberos, etc. Part 3 Protocols 3ProtocolsProtocol flaws can be very subtleSeveral well-known security protocols have significant flawsIncluding WEP, GSM, and IPSecImplementation errors can occurRecent IE implementation of SSLNot easy to get protocols right Part 3 Protocols 4Ideal Security ProtocolMust satisfy security requirementsRequirements need to be preciseEfficientSmall computational requirementSmall bandwidth usage, minimal delaysRobustWorks when attacker tries to break itWorks even if environment changesEasy to use & implement, flexibleDifficult to satisfy all of these!Chapter 9: Simple Security Protocols I quite agree with you, said the Duchess; and the moral of that isBe what you would seem to be orif you'd like it put more simplyNever imagine yourself not to beotherwise than what it might appear to others that what you wereor 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 5 Part 3 Protocols 6Secure Entry to NSAInsert badge into readerEnter PINCorrect PIN?Yes? EnterNo? Get shot by security guard Part 3 Protocols 7ATM Machine ProtocolInsert ATM cardEnter PINCorrect PIN?Yes? Conduct your transaction(s)No? Machine (eventually) eats card Part 3 Protocols 8Identify Friend or Foe (IFF)NamibiaKAngola1. N2. E(N,K)SAAFImpalaKRussianMIG

Part 3 Protocols 9MIG in the MiddleNamibiaKAngola1. N2. N3. N4. E(N,K)5. E(N,K)6. E(N,K)SAAFImpalaKRussianMiG

Part 3 Protocols 10Authentication Protocols Part 3 Protocols 11AuthenticationAlice must prove her identity to BobAlice and Bob can be humans or computersMay also require Bob to prove hes Bob (mutual authentication)Probably need to establish a session keyMay have other requirements, such asUse public keysUse symmetric keysUse hash functionsAnonymity, plausible deniability, etc., etc. Part 3 Protocols 12AuthenticationAuthentication on a stand-alone computer is relatively simpleHash password with saltSecure path, attacks on authentication software, keystroke logging, etc., can be issuesAuthentication over a network is challengingAttacker can passively observe messagesAttacker can replay messagesActive attacks possible (insert, delete, change) Part 3 Protocols 13Simple AuthenticationAliceBobIm AliceProve itMy password is frankSimple and may be OK for standalone systemBut insecure for networked systemSubject to a replay attack (next 2 slides)Also, Bob must know Alices password

Part 3 Protocols 14Authentication AttackAliceBobIm AliceProve itMy password is frankTrudy

Part 3 Protocols 15Authentication AttackBobIm AliceProve itMy password is frankTrudyThis is an example of a replay attackHow can we prevent a replay?

Part 3 Protocols 16Simple AuthenticationAliceBobIm Alice, my password is frankMore efficient, but same problem as previous version

Part 3 Protocols 17Better AuthenticationAliceBobIm AliceProve ith(Alices password)Better since it hides Alices passwordFrom both Bob and TrudyBut still subject to replay

Part 3 Protocols 18Challenge-ResponseTo prevent replay, use challenge-responseGoal is to ensure freshness Suppose Bob wants to authenticate AliceChallenge sent from Bob to AliceChallenge is chosen so that Replay is not possibleOnly Alice can provide the correct responseBob can verify the response Part 3 Protocols 19NonceTo ensure freshness, can employ a nonceNonce == number used once What to use for nonces?That is, what is the challenge?What should Alice do with the nonce?That is, how to compute the response?How can Bob verify the response?Should we rely on passwords or keys? Part 3 Protocols 20Challenge-ResponseBobIm AliceNonceh(Alices password, Nonce) Nonce is the challenge The hash is the response Nonce prevents replay, ensures freshness Password is something Alice knows Note: Bob must know Alices pwd to verifyAlice

Part 3 Protocols 21Generic Challenge-ResponseBobIm AliceNonceSomething that could only beAlicefrom Alice (and Bob can verify)In practice, how to achieve this?Hashed password works, butEncryption is better here (Why?)

Part 3 Protocols 22Symmetric Key NotationEncrypt 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 cryptoSo, we assume crypto algorithms are secure Part 3 Protocols 23Authentication: Symmetric KeyAlice and Bob share symmetric key KKey K known only to Alice and BobAuthenticate by proving knowledge of shared symmetric keyHow to accomplish this?Cannot reveal key, must not allow replay (or other) attack, must be verifiable, Part 3 Protocols 24Authentication with Symmetric KeyAlice, KBob, KIm AliceE(R,K) Secure method for Bob to authenticate Alice Alice does not authenticate Bob So, can we achieve mutual authentication?R

Part 3 Protocols 25Mutual Authentication?Alice, KBob, KIm Alice, RE(R,K)E(R,K)Whats wrong with this picture?Alice could be Trudy (or anybody else)!

Part 3 Protocols 26Mutual AuthenticationSince we have a secure one-way authentication protocolThe obvious thing to do is to use the protocol twiceOnce for Bob to authenticate AliceOnce for Alice to authenticate BobThis has got to work Part 3 Protocols 27Mutual AuthenticationAlice, KBob, KIm Alice, RARB, E(RA, K)E(RB, K)This provides mutual authenticationor does it? See the next slide

Part 3 Protocols 28Mutual Authentication AttackBob, K1. Im Alice, RA2. RB, E(RA, K)TrudyBob, K3. Im Alice, RB4. RC, E(RB, K)Trudy5. E(RB, K)

Part 3 Protocols 29Mutual AuthenticationOur one-way authentication protocol is not secure for mutual authentication Protocols are subtle!The obvious thing may not be secureAlso, if assumptions or environment change, protocol may not be secureThis is a common source of security failureFor example, Internet protocols Part 3 Protocols 30Symmetric Key Mutual AuthenticationAlice, KBob, KIm Alice, RARB, E(Bob,RA,K)E(Alice,RB,K)Do these insignificant changes help?Yes!

Part 3 Protocols 31Public Key NotationEncrypt M with Alices public key: {M}AliceSign M with Alices private key: [M]AliceThen [{M}Alice ]Alice = M {[M]Alice }Alice = M Anybody can use Alices public key Only Alice can use her private key Part 3 Protocols 32Public Key AuthenticationAliceBobIm Alice{R}AliceRIs this secure?Trudy can get Alice to decrypt anything!So, should have two key pairs

Part 3 Protocols 33Public Key AuthenticationAliceBobIm AliceR[R]AliceIs this secure?Trudy can get Alice to sign anything!Same a previous should have two key pairs

Part 3 Protocols 34Public KeysGenerally, a bad idea to use the same key pair for encryption and signingInstead, should haveone key pair for encryption/decryptionand a different key pair for signing/verifying signatures Part 3 Protocols 35Session KeyUsually, a session key is requiredI.e., a symmetric key for a particular sessionUsed for confidentiality and/or integrityHow to authenticate and establish a session key (i.e., shared symmetric key)?When authentication completed, want Alice and Bob to share a session keyTrudy cannot break the authenticationand Trudy cannot determine the session key Part 3 Protocols 36Authentication & Session KeyAliceBobIm Alice, R{R,K}Alice{R +1,K}BobIs this secure?Alice is authenticated and session key is secureAlices nonce, R, useless to authenticate BobThe key K is acting as Bobs nonce to AliceNo mutual authentication

Part 3 Protocols 37Public Key Authentication and Session KeyAliceBobIm Alice, R[R,K]Bob[R +1,K]AliceIs this secure?Mutual authentication (good), but session key is not secret (very bad)

Part 3 Protocols 38Public Key Authentication and Session KeyAliceBobIm Alice, R{[R,K]Bob}Alice{[R +1,K]Alice}BobIs this secure?Seems to be OKMutual authentication and session key!

Part 3 Protocols 39Public Key Authentication and Session KeyAliceBobIm Alice, R[{R,K}Alice]Bob[{R +1,K}Bob]AliceIs this secure?Seems to be OKAnyone can see {R,K}Alice and {R +1,K}Bob

Part 3 Protocols 40Perfect Forward SecrecyConsider this issueAlice encrypts message with shared key K and sends ciphertext to BobTrudy records ciphertext and later attacks Alices (or Bobs) computer to recover KThen Trudy decrypts recorded messagesPerfect forward secrecy (PFS): Trudy cannot later decrypt recorded ciphertextEven if Trudy gets key K or other secret(s)Is PFS possible? Part 3 Protocols 41Perfect Forward SecrecySuppose Alice and Bob share key K For perfect forward secrecy, Alice and Bob cannot use K to encryptInstead they must use a session key KS and forget it after its usedCan Alice and Bob agree on session key KS in a way that ensures PFS? Part 3 Protocols 42Nave Session Key Protocol Trudy could record E(KS, K) If Trudy later gets K then she can get KS Then Trudy can decrypt recorded messagesAlice, KBob, KE(KS, K)E(messages, KS)

Part 3 Protocols 43Perfect Forward SecrecyWe use Diffie-Hellman for PFSRecall: public g and pBut Diffie-Hellman is subject to MiMHow to get PFS and prevent MiM?Alice, aBob, bga mod pgb mod p

Part 3 Protocols 44Perfect Forward SecrecySession key KS = gab mod pAlice forgets a, Bob forgets bSo-called Ephemeral Diffie-HellmanNeither Alice nor Bob can later recover KSAre there other ways to achieve PFS?Alice: K, aBob: K, bE(ga mod p, K)E(gb mod p, K)

Part 3 Protocols 45Mutual Authentication, Session Key and PFSAliceBobIm Alice, RARB, [{RA, gb mod p}Alice]Bob[{RB, ga mod p}Bob]AliceSession key is K = gab mod pAlice forgets a and Bob forgets bIf Trudy later gets Bobs and Alices secrets, she cannot recover session key K

Part 3 Protocols 46TimestampsA timestamp T is derived from current timeTimestamps used in some security protocolsKerberos, for exampleTimestamps reduce number of msgs (good)Like a nonce that both sides know in advanceTime is a security-critical parameter (bad)Clocks never exactly the same, so must allow for clock skew creates risk of replayHow much clock skew is enough? Part 3 Protocols 47Public Key Authentication with Timestamp TBobIm Alice, {[T, K]Alice}Bob{[T +1, K]Bob}AliceAliceSecure mutual authentication?Session key?Seems to be OK

Part 3 Protocols 48Public Key Authentication with Timestamp TBobIm Alice, [{T, K}Bob]Alice[{T +1, K}Alice]BobAliceSecure authentication and session key?Trudy can use Alices public key to find {T, K}Bob and then

Part 3 Protocols 49Public Key Authentication with Timestamp TBobIm Trudy, [{T, K}Bob]Trudy[{T +1, K}Trudy]BobTrudyTrudy obtains Alice-Bob session key KNote: Trudy must act within clock skew

Part 3 Protocols 50Public Key AuthenticationSign and encrypt with nonceSecureEncrypt and sign with nonceSecureSign and encrypt with timestampSecureEncrypt and sign with timestampInsecureProtocols can be subtle! Part 3 Protocols 51Public Key Authentication with Timestamp TBobIm Alice, [{T, K}Bob]Alice[{T +1}Alice]BobAliceIs this encrypt and sign secure?Yes, seems to be OKDoes sign and encrypt also work here?

Part 3 Protocols 52Authentication and TCP Part 3 Protocols 53TCP-based AuthenticationTCP not intended for use as an authentication protocolBut IP address in TCP connection often used for authenticationOne mode of IPSec relies on IP address for authentication Part 3 Protocols 54TCP 3-way HandshakeAliceBobSYN, SEQ aSYN, ACK a+1, SEQ bACK b+1, data Recall the TCP three way handshake Initial sequence numbers: SEQ a and SEQ b Supposed to be selected at random If not

Part 3 Protocols 55TCP Authentication AttackAliceBobTrudy1. SYN, SEQ = t (as Trudy)2. SYN, ACK = t+1, SEQ = b13. SYN, SEQ = t (as Alice)4. SYN, ACK = t+1, SEQ = b25. ACK = b2+1, data5.5.5.5.

Part 3 Protocols 56TCP Authentication Attack

Random SEQ numbersInitial SEQ numbersMac OS X If initial SEQ numbers not very random possible to guess initial SEQ number and previous attack will succeed Part 3 Protocols 57TCP Authentication AttackTrudy cannot see what Bob sends, but she can send packets to Bob, while posing as AliceTrudy must prevent Alice from receiving Bobs packets (or else connection will terminate)If password (or other authentication) required, this attack failsIf TCP connection is relied on for authentication, then attack can succeedBad idea to rely on TCP for authentication Part 3 Protocols 58Zero Knowledge Proofs Part 3 Protocols 59Zero Knowledge Proof (ZKP)Alice wants to prove that she knows a secret without revealing any info about itBob must verify that Alice knows secretBut, Bob gains no info about the secretProcess is probabilisticBob can verify that Alice knows the secret to an arbitrarily high probabilityAn interactive proof system Part 3 Protocols 60Bobs CaveAlice knows secret phrase to open path between R and S (open sarsaparilla)Can she convince Bob that she knows the secret without revealing phrase?PQRS Part 3 Protocols 61

Bob: Alice come out on S sideAlice (quietly): Open sarsaparillaIf Alice does not know the secretIf Bob repeats this n times, then Alice (who does not know secret) can only fool Bob with probability 1/2nthen Alice could come out from the correct side with probability 1/2PQRSBobs Cave Part 3 Protocols 62Fiat-Shamir ProtocolCave-based protocols are inconvenientCan we achieve same effect without the cave?Finding square roots modulo N is difficultEquivalent to factoringSuppose N = pq, where p and q primeAlice has a secret SN and v = S2 mod N are public, S is secretAlice must convince Bob that she knows S without revealing any information about S Part 3 Protocols 63Fiat-ShamirPublic: Modulus N and v = S2 mod NAlice selects random r, Bob chooses e {0,1} Bob verifies: y2 = x ve mod N Why? Because y2 = r2 S2e = r2 (S2)e = x ve mod N Alicesecret Srandom rBobrandom ex = r2 mod Ne {0,1}y = r Se mod N

Part 3 Protocols 64Fiat-Shamir: e = 1Public: Modulus N and v = S2 mod NAlice selects random r, Bob chooses e =1 If y2 = x v mod N then Bob accepts itI.e., Alice passes this iteration of the protocolNote that Alice must know S in this caseAlicesecret Srandom rBobrandom ex = r2 mod Ne = 1 y = r S mod N

Part 3 Protocols 65Fiat-Shamir: e = 0Public: Modulus N and v = S2 mod NAlice selects random r, Bob chooses e = 0Bob must checks whether y2 = x mod N Alice does not need to know S in this case!Alicesecret Srandom rBobrandom ex = r2 mod Ne = 0 y = r mod N

Part 3 Protocols 66Fiat-ShamirPublic: modulus N and v = S2 mod NSecret: Alice knows SAlice 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 NBob checks whether y2 = x ve mod N Does this prove response is from Alice? Part 3 Protocols 67Does Fiat-Shamir Work?If everyone follows protocol, math works:Public: v = S2 mod N Alice to Bob: x = r2 mod N and y = r Se mod N Bob verifies: y2 = x ve mod N Can Trudy convince Bob she is Alice?If Trudy expects e = 0, she sends x = r2 in msg 1 and y = r in msg 3 (i.e., follow the protocol)If Trudy expects e = 1, sends x = r2 v1 in msg 1 and y = r in msg 3If Bob chooses e {0,1} at random, Trudy can only trick Bob with probability 1/2 Part 3 Protocols 68Fiat-Shamir FactsTrudy can trick Bob with probability 1/2, butafter n iterations, the probability that Trudy can convince Bob that she is Alice is only 1/2nJust like Bobs cave!Bobs e {0,1} must be unpredictableAlice must use new r each iteration, or elseIf e = 0, Alice sends r mod N in message 3If e = 1, Alice sends r S mod N in message 3Anyone can find S given r mod N and r S mod N Part 3 Protocols 69Fiat-Shamir Zero Knowledge?Zero knowledge means that nobody learns anything about the secret SPublic: v = S2 mod NTrudy sees r2 mod N in message 1Trudy sees r S mod N in message 3 (if e = 1)If Trudy can find r from r2 mod N, gets SBut that requires modular square rootIf Trudy could find modular square roots, she could get S from public vProtocol does not seem to help to find S Part 3 Protocols 70ZKP in the Real WorldPublic key certificates identify usersNo anonymity if certificates sent in plaintextZKP offers a way to authenticate without revealing identitiesZKP supported in MSs Next Generation Secure Computing Base (NGSCB), whereZKP used to authenticate software without revealing machine identifying dataZKP is not just pointless mathematics! Part 3 Protocols 71Best Authentication Protocol?It depends onThe sensitivity of the application/dataThe delay that is tolerableThe cost (computation) that is tolerableWhat crypto is supported (public key, symmetric key, )Whether mutual authentication is requiredWhether PFS, anonymity, etc., are concernand possibly other factorsChapter 10: Real-World Protocols The wire protocol guys don't worry about security because that's really a network protocol problem. The network protocol guys don't worry about it because, really, it's an application problem. The application guys don't worry about it because, after all, they can just use the IP address and trust the network. Marcus J. Ranum

In the real world, nothing happens at the right place at the right time. It is the job of journalists and historians to correct that. Mark Twain Part 2 Access Control 72 Part 3 Protocols 73Real-World ProtocolsNext, we look at real protocolsSSH a simple & useful security protocolSSL practical security on the WebIPSec security at the IP layerKerberos symmetric key, single sign-onWEP Swiss cheese of security protocolsGSM mobile phone (in)securitySecure Shell (SSH) Part 3 Protocols 74

SSHCreates a secure tunnelInsecure command sent thru SSH tunnel are then secureSSH used with things like rloginWhy is rlogin insecure without SSH?Why is rlogin secure with SSH?SSH is a relatively simple protocol Part 3 Protocols 75SSHSSH authentication can be based on:Public keys, orDigital certificates, orPasswordsHere, we consider certificate modeOther modes, see homework problemsWe consider slightly simplified SSH Part 3 Protocols 76Simplified SSHCP = crypto proposed, and CS = crypto selectedH = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gb mod p,gab mod p)SB = [H]BobSA = [H, Alice, certificateA]AliceK = gab mod p

Part 3 Protocols 77

AliceBobAlice, CP, RACS, RBga mod p

gb mod p, certificateB, SBE(Alice, certificateA, SA, K)MiM Attack on SSH?Where does this attack fail?Alice computes:Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)But Bob signs:Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)

Part 3 Protocols 78

AliceBobAlice, RARBga mod p

gb mod p, certB, SBE(Alice,certA,SA,K)Alice, RARBgt mod pgt mod p, certB, SBE(Alice,certA,SA,K)Trudy

Part 3 Protocols 79Secure Socket Layer

Part 3 Protocols 80Socket layerSocket layer lives between application and transport layersSSL usually between HTTP and TCPapplication

transport

network

link

physicalSocketlayerOSUserNIC Part 3 Protocols 81What is SSL?SSL is the protocol used for majority of secure transactions on the InternetFor example, if you want to buy a book at amazon.comYou want to be sure you are dealing with Amazon (authentication)Your credit card information must be protected in transit (confidentiality and/or integrity)As long as you have money, Amazon does not care who you areSo, no need for mutual authentication Part 3 Protocols 82Simple SSL-like ProtocolAliceBobId like to talk to you securelyHeres my certificate{K}Bobprotected HTTPIs Alice sure shes talking to Bob?Is Bob sure hes talking to Alice?

Part 3 Protocols 83Simplified SSL ProtocolAliceBobCan we talk?, cipher list, RAcertificate, cipher, RB{S}Bob, E(h(msgs,CLNT,K),K)Data protected with key Kh(msgs,SRVR,K)S is known as pre-master secretK = h(S,RA,RB)msgs means all previous messagesCLNT and SRVR are constants

Part 3 Protocols 84SSL Keys6 keys derived from K = h(S,RA,RB)2 encryption keys: send and receive2 integrity keys: send and receive2 IVs: send and receiveWhy different keys in each direction?Q: Why is h(msgs,CLNT,K) encrypted?A: Apparently, it adds no security Part 3 Protocols 85SSL AuthenticationAlice authenticates Bob, not vice-versaHow does client authenticate server?Why would server not authenticate client?Mutual authentication is possible: Bob sends certificate request in message 2Then client must have a valid certificateBut, if server wants to authenticate client, server could instead require password Part 3 Protocols 86SSL MiM Attack?AliceBobRAcertificateT, RB{S1}Trudy,E(X1,K1)E(data,K1)h(Y1,K1)Q: What prevents this MiM attack?A: Bobs certificate must be signed by a certificate authority (CA)What does browser do if signature not valid?What does user do when browser complains?TrudyRAcertificateB, RB{S2}Bob,E(X2,K2)E(data,K2)h(Y2,K2)

Part 3 Protocols 87SSL Sessions vs ConnectionsSSL session is established as shown on previous slidesSSL designed for use with HTTP 1.0HTTP 1.0 often opens multiple simultaneous (parallel) connectionsMultiple connections per sessionSSL session is costly, public key operationsSSL has an efficient protocol for opening new connections given an existing session Part 3 Protocols 88SSL ConnectionAliceBobsession-ID, cipher list, RAsession-ID, cipher, RB, h(msgs,SRVR,K) h(msgs,CLNT,K)Protected dataAssuming SSL session existsSo, S is already known to Alice and BobBoth sides must remember session-IDAgain, K = h(S,RA,RB)No public key operations! (relies on known S)

Part 3 Protocols 89SSL vs IPSecIPSec discussed in next sectionLives at the network layer (part of the OS)Encryption, integrity, authentication, etc.Is overly complex, has some security issuesSSL (and IEEE standard known as TLS)Lives at socket layer (part of user space)Encryption, integrity, authentication, etc.Relatively simple and elegant specification Part 3 Protocols 90SSL vs IPSecIPSec: OS must be aware, but not appsSSL: Apps must be aware, but not OSSSL built into Web early-on (Netscape)IPSec often used in VPNs (secure tunnel)Reluctance to retrofit applications for SSLIPSec not widely deployed (complexity, etc.)The bottom line Internet less secure than it should be! Part 3 Protocols 91IPSec Part 3 Protocols 92IPSec and SSLIPSec lives at the network layerIPSec is transparent to applicationsapplication

transport

network

link

physicalSSLOSUserNICIPSec Part 3 Protocols 93IPSec and ComplexityIPSec is a complex protocolOver-engineeredLots of (generally useless) featuresFlawedSome significant security issuesInteroperability is serious challengeDefeats the purpose of having a standard!ComplexAnd, did I mention, its complex? Part 3 Protocols 94IKE and ESP/AHTwo parts to IPSecIKE: Internet Key ExchangeMutual authenticationEstablish session keyTwo phases like SSL session/connectionESP/AHESP: Encapsulating Security Payload for encryption and/or integrity of IP packetsAH: Authentication Header integrity only Part 3 Protocols 95IKE Part 3 Protocols 96IKEIKE has 2 phasesPhase 1 IKE security association (SA)Phase 2 AH/ESP security associationPhase 1 is comparable to SSL session Phase 2 is comparable to SSL connection Not an obvious need for two phases in IKEIf multiple Phase 2s do not occur, then it is more costly to have two phases! Part 3 Protocols 97IKE Phase 1Four different key optionsPublic key encryption (original version)Public key encryption (improved version)Public key signatureSymmetric keyFor each of these, two different modesMain mode and aggressive modeThere are 8 versions of IKE Phase 1!Need more evidence its over-engineered? Part 3 Protocols 98IKE Phase 1We discuss 6 of 8 Phase 1 variantsPublic key signatures (main & aggressive modes)Symmetric key (main and aggressive modes)Public key encryption (main and aggressive)Why public key encryption and public key signatures?Always know your own private keyMay not (initially) know other sides public key Part 3 Protocols 99IKE Phase 1Uses ephemeral Diffie-Hellman to establish session keyProvides perfect forward secrecy (PFS)Let a be Alices Diffie-Hellman exponentLet b be Bobs Diffie-Hellman exponentLet g be generator and p primeRecall that p and g are public Part 3 Protocols 100IKE Phase 1: Digital Signature (Main Mode)CP = crypto proposed, CS = crypto selectedIC = initiator cookie, RC = responder cookieK = h(IC,RC,gab mod p,RA,RB)SKEYID = h(RA, RB, gab mod p)proofA = [h(SKEYID,ga mod p,gb mod p,IC,RC,CP,Alice)]AliceAliceBobIC, CPIC,RC, CSIC,RC, ga mod p, RAIC,RC, E(Alice, proofA, K)IC,RC, gb mod p, RBIC,RC, E(Bob, proofB, K)

Part 3 Protocols 101IKE Phase 1: Public Key Signature (Aggressive Mode)Main difference from main modeNot trying to protect identitiesCannot negotiate g or pAliceBobIC, Alice, ga mod p, RA, CPIC,RC, Bob, RB, gb mod p, CS, proofBIC,RC, proofA

Part 3 Protocols 102Main vs Aggressive ModesMain mode MUST be implementedAggressive mode SHOULD be implementedSo, if aggressive mode is not implemented, you should feel guilty about itMight create interoperability issuesFor public key signature authenticationPassive attacker knows identities of Alice and Bob in aggressive mode, but not in main modeActive attacker can determine Alices and Bobs identity in main mode Part 3 Protocols 103IKE Phase 1: Symmetric Key (Main Mode)Same as signature mode exceptKAB = symmetric key shared in advance K = h(IC,RC,gab mod p,RA,RB,KAB)SKEYID = h(K, gab mod p)proofA = h(SKEYID,ga mod p,gb mod p,IC,RC,CP,Alice)AliceKABBobKABIC, CPIC,RC, CSIC,RC, ga mod p, RAIC,RC, E(Alice, proofA, K)IC,RC, gb mod p, RBIC,RC, E(Bob, proofB, K)

Part 3 Protocols 104Problems with Symmetric Key (Main Mode)Catch-22Alice sends her ID in message 5Alices ID encrypted with KTo find K Bob must know KABTo get KAB Bob must know hes talking to Alice!Result: Alices ID must be IP address!Useless mode for the road warriorWhy go to all of the trouble of trying to hide identities in 6 message protocol? Part 3 Protocols 105IKE Phase 1: Symmetric Key (Aggressive Mode)Same format as digital signature aggressive modeNot trying to hide identitiesAs a result, does not have problems of main modeBut does not (pretend to) hide identitiesAliceBobIC, Alice, ga mod p, RA, CPIC,RC, Bob, RB, gb mod p, CS, proofBIC,RC, proofA

Part 3 Protocols 106IKE Phase 1: Public Key Encryption (Main Mode)CP = crypto proposed, CS = crypto selectedIC = initiator cookie, RC = responder cookieK = h(IC,RC,gab mod p,RA,RB)SKEYID = h(RA, RB, gab mod p)proofA = h(SKEYID,ga mod p,gb mod p,IC,RC,CP,Alice)AliceBobIC, CPIC,RC, CSIC,RC, ga mod p, {RA}Bob, {Alice}BobIC,RC, E(proofA, K)IC,RC, gb mod p, {RB}Alice, {Bob}AliceIC,RC, E(proofB, K)

Part 3 Protocols 107IKE Phase 1: Public Key Encryption (Aggressive Mode)K, proofA, proofB computed as in main modeNote that identities are hiddenThe only aggressive mode to hide identitiesSo, why have a main mode?AliceBobIC, CP, ga mod p,{Alice}Bob, {RA}BobIC,RC, CS, gb mod p, {Bob}Alice, {RB}Alice, proofBIC,RC, proofA

Part 3 Protocols 108Public Key Encryption Issue?In public key encryption, aggressive modeSuppose Trudy generatesExponents a and bNonces RA and RBTrudy can compute valid keys and proofs: gab mod p, K, SKEYID, proofA and proofBThis also works in main mode Part 3 Protocols 109Public Key Encryption Issue?Trudyas AliceTrudyas BobTrudy can create exchange that appears to be between Alice and BobAppears valid to any observer, including Alice and Bob!IC,RC, CS, gb mod p, {Bob}Alice, {RB}Alice, proofBIC,RC, proofAIC, CP, ga mod p,{Alice}Bob, {RA}Bob

Part 3 Protocols 110Plausible DeniabilityTrudy can create conversation that appears to be between Alice and BobAppears valid, even to Alice and Bob!A security failure?In this IPSec key option, it is a featurePlausible deniability: Alice and Bob can deny that any conversation took place!In some cases it might create a problemE.g., if Alice makes a purchase from Bob, she could later repudiate it (unless she had signed) Part 3 Protocols 111IKE Phase 1 CookiesIC and RC cookies (or anti-clogging tokens) supposed to prevent DoS attacksNo relation to Web cookiesTo reduce DoS threats, Bob wants to remain stateless as long as possibleBut Bob must remember CP from message 1 (required for proof of identity in message 6)Bob must keep state from 1st message onSo, these cookies offer little DoS protection Part 3 Protocols 112IKE Phase 1 SummaryResult of IKE phase 1 is Mutual authenticationShared symmetric keyIKE Security Association (SA)But phase 1 is expensiveEspecially in public key and/or main modeDevelopers of IKE thought it would be used for lots of things not just IPSecPartly explains the over-engineering Part 3 Protocols 113IKE Phase 2Phase 1 establishes IKE SAPhase 2 establishes IPSec SAComparison to SSL SSL session is comparable to IKE Phase 1SSL connections are like IKE Phase 2IKE could be used for lots of thingsbut in practice, its not! Part 3 Protocols 114IKE Phase 2Key K, IC, RC and SA known from Phase 1Proposal CP includes ESP and/or AHHashes 1,2,3 depend on SKEYID, SA, RA and RBKeys derived from KEYMAT = h(SKEYID,RA,RB,junk)Recall SKEYID depends on phase 1 key methodOptional PFS (ephemeral Diffie-Hellman exchange)AliceBobIC,RC,CP,E(hash1,SA,RA,K)IC,RC,CS,E(hash2,SA,RB,K)IC,RC,E(hash3,K)

Part 3 Protocols 115IPSecAfter IKE Phase 1, we have an IKE SAAfter IKE Phase 2, we have an IPSec SABoth sides have a shared symmetric keyNow what?We want to protect IP datagramsBut what is an IP datagram?Considered from the perspective of IPSec Part 3 Protocols 116

IP ReviewWhere IP header is IP headerdataIP datagram is of the form Part 3 Protocols 117IP and TCPConsider Web trafficIP encapsulates TCP andTCP encapsulates HTTPIP headerTCP hdrHTTP hdrapp dataIP headerdataIP data includes TCP header, etc. Part 3 Protocols 118IPSec Transport ModeIPSec Transport ModeIP headerdataIP headerESP/AHdataTransport mode designed for host-to-hostTransport mode is efficientAdds minimal amount of extra headerThe original header remainsPassive attacker can see who is talkingIPSec: Host-to-HostIPSec transport mode Part 3 Protocols 119

There may be firewalls in betweenIf so, is that a problem? Part 3 Protocols 120IPSec Tunnel ModeIPSec Tunnel ModeIP headerdatanew IP hdrESP/AHIP headerdataTunnel mode for firewall-to-firewall trafficOriginal IP packet encapsulated in IPSecOriginal IP header not visible to attackerNew IP header from firewall to firewallAttacker does not know which hosts are talkingIPSec: Firewall-to-FirewallIPSec tunnel mode Part 3 Protocols 121

Local networks not protectedIs there any advantage here? Part 3 Protocols 122Comparison of IPSec ModesTransport ModeTunnel ModeIP headerdataIP headerESP/AHdataIP headerdatanew IP hdrESP/AHIP headerdataTransport ModeHost-to-hostTunnel ModeFirewall-to-firewallTransport Mode not necessarybut its more efficient Part 3 Protocols 123IPSec SecurityWhat kind of protection?Confidentiality?Integrity?Both?What to protect?Data?Header?Both?ESP/AH do some combinations of these Part 3 Protocols 124AH vs ESPAH Authentication HeaderIntegrity only (no confidentiality)Integrity-protect everything beyond IP header and some fields of header (why not all fields?)ESP Encapsulating Security PayloadIntegrity and confidentiality both requiredProtects everything beyond IP headerIntegrity-only by using NULL encryption Part 3 Protocols 125ESPs NULL EncryptionAccording to RFC 2410NULL encryption is a block cipher the origins of which appear to be lost in antiquityDespite rumors, there is no evidence that NSA suppressed publication of this algorithmEvidence suggests it was developed in Roman times as exportable version of Caesars cipherCan make use of keys of varying lengthNo IV is requiredNull(P,K) = P for any P and any key KBottom line: Security people can be strange Part 3 Protocols 126Why Does AH Exist? (1)Cannot encrypt IP headerRouters must look at the IP headerIP addresses, TTL, etc.IP header exists to route packets!AH protects immutable fields in IP headerCannot integrity protect all header fieldsTTL, for example, will changeESP does not protect IP header at all Part 3 Protocols 127Why Does AH Exist? (2)ESP encrypts everything beyond the IP header (if non-null encryption)If ESP-encrypted, firewall cannot look at TCP header (e.g., port numbers)Why not use ESP with NULL encryption?Firewall sees ESP header, but does not know whether null encryption is usedEnd systems know, but not the firewalls Part 3 Protocols 128Why Does AH Exist? (3)The real reason why AH exists:At one IETF meeting someone from Microsoft gave an impassioned speech about how AH was uselesseveryone in the room looked around and said `Hmm. Hes right, and we hate AH also, but if it annoys Microsoft lets leave it in since we hate Microsoft more than we hate AH. Part 3 Protocols 129Kerberos

Part 3 Protocols 130KerberosIn Greek mythology, Kerberos is 3-headed dog that guards entrance to HadesWouldnt it make more sense to guard the exit?In security, Kerberos is an authentication protocol based on symmetric key cryptoOriginated at MITBased on work by Needham and SchroederRelies on a Trusted Third Party (TTP) Part 3 Protocols 131Motivation for KerberosAuthentication using public keysN users N key pairsAuthentication using symmetric keysN users requires (on the order of) N2 keysSymmetric key case does not scaleKerberos based on symmetric keys but only requires N keys for N usersSecurity depends on TTP No PKI is needed Part 3 Protocols 132Kerberos KDCKerberos Key Distribution Center or KDCKDC acts as the TTPTTP is trusted, so it must not be compromisedKDC shares symmetric key KA with Alice, key KB with Bob, key KC with Carol, etc.And a master key KKDC known only to KDCKDC enables authentication, session keysSession key for confidentiality and integrityIn practice, crypto algorithm is DES Part 3 Protocols 133Kerberos TicketsKDC issue tickets containing info needed to access network resourcesKDC also issues Ticket-Granting Tickets or TGTs that are used to obtain ticketsEach TGT containsSession keyUsers IDExpiration timeEvery TGT is encrypted with KKDCSo, TGT can only be read by the KDC Part 3 Protocols 134Kerberized LoginAlice enters her passwordThen Alices computer does following:Derives KA from Alices passwordUses KA to get TGT for Alice from KDCAlice then uses her TGT (credentials) to securely access network resourcesPlus: Security is transparent to AliceMinus: KDC must be secure its trusted! Part 3 Protocols 135Kerberized LoginAliceAlicesAlice wantspassword a TGTE(SA,TGT,KA)

KDCKey KA = h(Alices password)KDC creates session key SAAlices computer decrypts SA and TGTThen it forgets KATGT = E(Alice, SA, KKDC)Computer

Part 3 Protocols 136Alice Requests Ticket to BobAliceTalk to BobI want totalk to BobREQUESTREPLY

KDCREQUEST = (TGT, authenticator)authenticator = E(timestamp, SA)REPLY = E(Bob, KAB, ticket to Bob, SA)ticket to Bob = E(Alice, KAB, KB)KDC gets SA from TGT to verify timestampComputer

Part 3 Protocols 137Alice Uses Ticket to Bobticket to Bob, authenticatorE(timestamp + 1, KAB)ticket to Bob = E(Alice, KAB, KB)authenticator = E(timestamp, KAB)Bob decrypts ticket to Bob to get KAB which he then uses to verify timestampAlices ComputerBob

Part 3 Protocols 138KerberosKey SA used in authentication For confidentiality/integrityTimestamps for authentication and replay protectionRecall, that timestampsReduce the number of messageslike a nonce that is known in advanceBut, time is a security-critical parameter Part 3 Protocols 139Kerberos QuestionsWhen Alice logs in, KDC sends E(SA, TGT, KA) where TGT = E(Alice, SA, KKDC)Q: Why is TGT encrypted with KA?A: Extra work for no added security!In Alices Kerberized login to Bob, why can Alice remain anonymous?Why is ticket to Bob sent to Alice?Why doesnt KDC send it directly to Bob? Part 3 Protocols 140Kerberos AlternativesCould have Alices computer remember password and use that for authenticationThen no KDC requiredBut hard to protect passwordsAlso, does not scaleCould have KDC remember session key instead of putting it in a TGTThen no need for TGTBut stateless KDC is major feature of Kerberos Part 3 Protocols 141Kerberos KeysIn Kerberos, KA = h(Alices password)Could instead generate random KA Compute Kh = h(Alices password)And Alices computer stores E(KA, Kh)Then KA need not change when Alice changes her passwordBut E(KA, Kh) must be stored on computerThis alternative approach is often usedBut not in KerberosWEP Part 3 Protocols 142

WEPWEP Wired Equivalent PrivacyThe stated goal of WEP is to make wireless LAN as secure as a wired LANAccording to Tanenbaum:The 802.11 standard prescribes a data link-level security protocol called WEP (Wired Equivalent Privacy), which is designed to make the security of a wireless LAN as good as that of a wired LAN. Since the default for a wired LAN is no security at all, this goal is easy to achieve, and WEP achieves it as we shall see. Part 3 Protocols 143WEP AuthenticationBob is wireless access pointKey K shared by access point and all usersKey K seldom (if ever) changesWEP has many, many, many security flaws

Part 3 Protocols 144Alice, KBob, KAuthentication RequestRE(R, K)

WEP IssuesWEP uses RC4 cipher for confidentialityRC4 is considered a strong cipherBut WEP introduces a subtle flawmaking cryptanalytic attacks feasibleWEP uses CRC for integrityShould have used a MAC or HMAC insteadCRC is for error detection, not crypto integrityEveryone knows NOT to use CRC for this Part 3 Protocols 145WEP Integrity ProblemsWEP integrity gives no crypto integrityCRC is linear, so is stream cipher (XOR)Trudy can change ciphertext and CRC so that checksum remains correctThen Trudys introduced errors go undetectedRequires no knowledge of the plaintext!CRC does not provide a cryptographic integrity checkCRC designed to detect random errorsNot able to detect intelligent changes

Part 3 Protocols 146More WEP Integrity IssuesSuppose Trudy knows destination IPThen Trudy also knows keystream used to encrypt IP address, since C = destination IP address keystreamThen Trudy can replace C with C = Trudys IP address keystreamAnd change the CRC so no error detected!Then what happens??Moral: Big problem when integrity fails

Part 3 Protocols 147WEP KeyRecall WEP uses a long-term secret key: KRC4 is a stream cipher, so each packet must be encrypted using a different keyInitialization Vector (IV) sent with packetSent in the clear, that is, IV is not secretNote: IV similar to MI in WWII ciphersActual RC4 key for packet is (IV,K)That is, IV is pre-pended to long-term key K Part 3 Protocols 148WEP EncryptionKIV = (IV,K)That is, RC4 key is K with 3-byte IV pre-pendedNote that the IV is known to Trudy Part 3 Protocols 149Alice, KBob, KIV, E(packet,KIV)

WEP IV IssuesWEP uses 24-bit (3 byte) IV Each packet gets a new IVKey: IV pre-pended to long-term key, KLong term key K seldom changesIf long-term key and IV are same, then same keystream is usedThis is bad, bad, really really bad! Why? Part 3 Protocols 150WEP IV IssuesAssume 1500 byte packets, 11 Mbps linkSuppose IVs generated in sequenceSince 1500 8/(11 106) 224 = 18,000 secondsan IV must repeat in about 5 hoursSuppose IVs generated at randomBy birthday problem, some IV repeats in secondsAgain, repeated IV (with same K) is bad! Part 3 Protocols 151Another Active AttackSuppose Trudy can insert traffic and observe corresponding ciphertextThen she knows the keystream for some IVShe can decrypt any packet(s) that uses that IVIf Trudy does this many times, she can then decrypt data for lots of IVsRemember, IV is sent in the clearIs such an attack feasible? Part 3 Protocols 152Cryptanalytic AttackWEP data encrypted using RC4Packet key is IV and long-term key K3-byte IV is pre-pended to KPacket key is (IV,K)Recall IV is sent in the clear (not secret)New IV sent with every packetLong-term key K seldom changes (maybe never)So Trudy always knows IVs and ciphertextTrudy wants to find the key K Part 3 Protocols 153Cryptanalytic Attack3-byte IV pre-pended to keyDenote the RC4 key bytesas K0,K1,K2,K3,K4,K5, Where IV = (K0,K1,K2) , which Trudy knowsTrudy wants to find K = (K3,K4,K5, )Given enough IVs, Trudy can find key KRegardless of the length of the key!Provided Trudy knows first keystream byteKnown plaintext attack (1st byte of each packet)Prevent by discarding first 256 keystream bytes Part 3 Protocols 154WEP ConclusionsMany attacks are practicalAttacks have been used to recover keys and break real WEP trafficHow to prevent WEP attacks?Dont use WEPGood alternatives: WPA, WPA2, etc.How to make WEP a little better?Restrict MAC addresses, dont broadcast ID, Part 3 Protocols 155 Part 3 Protocols 156GSM (In)Security

Part 3 Protocols 157Cell PhonesFirst generation cell phonesBrick-sized, analog, few standardsLittle or no securitySusceptible to cloningSecond generation cell phones: GSMBegan in 1982 as Groupe Speciale MobileNow, Global System for Mobile CommunicationsThird generation?3rd Generation Partnership Project (3GPP) Part 3 Protocols 158

GSM System OverviewMobileHomeNetworkland lineair interfaceBaseStationBaseStationControllerPSTNInternetetc.Visited NetworkVLRHLRAuC

Part 3 Protocols 159GSM System ComponentsMobile phoneContains SIM (Subscriber Identity Module)SIM is the security moduleIMSI (International Mobile Subscriber ID)User key: Ki (128 bits)Tamper resistant (smart card)PIN activated (usually not used)

SIM Part 3 Protocols 160GSM System ComponentsVisited network network where mobile is currently locatedBase station one cellBase station controller manages many cellsVLR (Visitor Location Register) info on all visiting mobiles currently in the networkHome network home of the mobileHLR (Home Location Register) keeps track of most recent location of mobileAuC (Authentication Center) has IMSI and Ki Part 3 Protocols 161GSM Security GoalsPrimary design goalsMake GSM as secure as ordinary telephonePrevent phone cloningNot designed to resist an active attacksAt the time this seemed infeasibleToday such an attacks are feasibleDesigners considered biggest threats to beInsecure billingCorruptionOther low-tech attacks Part 3 Protocols 162GSM Security FeaturesAnonymityIntercepted traffic does not identify userNot so important to phone companyAuthenticationNecessary for proper billingVery, very important to phone company!ConfidentialityConfidentiality of calls over the air interfaceNot important to phone companyMay be important for marketing Part 3 Protocols 163GSM: AnonymityIMSI used to initially identify callerThen TMSI (Temporary Mobile Subscriber ID) usedTMSI changed frequentlyTMSIs encrypted when sentNot a strong form of anonymityBut probably sufficient for most uses Part 3 Protocols 164GSM: AuthenticationCaller is authenticated to base stationAuthentication is not mutual Authentication via challenge-responseHome network generates RAND and computes XRES = A3(RAND, Ki) where A3 is a hashThen (RAND,XRES) sent to base stationBase station sends challenge RAND to mobileMobiles response is SRES = A3(RAND, Ki)Base station verifies SRES = XRESNote: Ki never leaves home network! Part 3 Protocols 165GSM: ConfidentialityData encrypted with stream cipherError rate estimated at about 1/1000Error rate is high for a block cipherEncryption key KcHome network computes Kc = A8(RAND, Ki) where A8 is a hashThen Kc sent to base station with (RAND,XRES)Mobile computes Kc = A8(RAND, Ki)Keystream generated from A5(Kc)Note: Ki never leaves home network! Part 3 Protocols 166GSM SecuritySRES and Kc must be uncorrelatedEven though both are derived from RAND and KiMust not be possible to deduce Ki from known RAND/SRES pairs (known plaintext attack)Must not be possible to deduce Ki from chosen RAND/SRES pairs (chosen plaintext attack)With possession of SIM, attacker can choose RANDs MobileBase Station4. RAND5. SRES6. Encrypt with Kc1. IMSIHomeNetwork3. (RAND,XRES,Kc)2. IMSI

Part 3 Protocols 167

GSM Insecurity (1)Hash used for A3/A8 is COMP128Broken by 160,000 chosen plaintextsWith SIM, can get Ki in 2 to 10 hoursEncryption between mobile and base station but no encryption from base station to base station controllerOften transmitted over microwave linkEncryption algorithm A5/1Broken with 2 seconds of known plaintextBaseStationBaseStationControllerVLR

Part 3 Protocols 168GSM Insecurity (2)Attacks on SIM cardOptical Fault Induction could attack SIM with a flashbulb to recover KiPartitioning Attacks using timing and power consumption, could recover Ki with only 8 adaptively chosen plaintextsWith possession of SIM, attacker could recover Ki in seconds Part 3 Protocols 169

GSM Insecurity (3)Fake base station exploits two flawsEncryption not automaticBase station not authenticatedMobileBase StationRANDSRESFake Base StationNoencryptionCall todestinationNote: GSM bill goes to fake base station!

Part 3 Protocols 170GSM Insecurity (4)Denial of service is possibleJamming (always an issue in wireless)Can replay triple: (RAND,XRES,Kc)One compromised triple gives attacker a key Kc that is valid foreverNo replay protection here Part 3 Protocols 171GSM ConclusionDid GSM achieve its goals?Eliminate cloning? Yes, as a practical matterMake air interface as secure as PSTN? PerhapsBut design goals were clearly too limitedGSM insecurities weak crypto, SIM issues, fake base station, replay, etc.PSTN insecurities tapping, active attack, passive attack (e.g., cordless phones), etc.GSM a (modest) security success? Part 3 Protocols 1723GPP: 3rd Generation Partnership Project3G security built on GSM (in)security3G fixed known GSM security problemsMutual authenticationIntegrity-protect signaling (such as start encryption command)Keys (encryption/integrity) cannot be reusedTriples cannot be replayedStrong encryption algorithm (KASUMI)Encryption extended to base station controller Part 3 Protocols 173Protocols SummaryGeneric authentication protocolsProtocols are subtle!SSHSSLIPSecKerberosWireless: GSM and WEP Part 3 Protocols 174Coming AttractionsSoftware and securitySoftware flaws buffer overflow, etc.Malware viruses, worms, etc.Software reverse engineeringDigital rights managementOS and security/NGSCB