Part III Protocols Part 3 Protocols 1 Protocol

Part III: Protocols Part 3 Protocols 1

Protocol q Human protocols the 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. Part 3 Protocols 2

Protocols q Protocol flaws can be very subtle q Several well-known security protocols have significant flaws o Including WEP, GSM, and IPSec q Implementation errors can also occur o Recently, IE implementation of SSL q Not easy to get protocols right… Part 3 Protocols 3

Ideal Security Protocol q Must satisfy security requirements o Requirements need to be precise q Efficient o Minimize computational requirement o Minimize bandwidth usage, delays… q Robust o Works when attacker tries to break it o Works if environment changes (slightly) Easy to implement, easy to use, flexible… q Difficult to satisfy all of these! q Part 3 Protocols 4

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 5

Secure Entry to NSA 1. 2. 3. Insert badge into reader Enter PIN Correct PIN? Yes? Enter No? Get shot by security guard Part 3 Protocols 6

ATM Machine Protocol 1. 2. 3. Insert ATM card Enter PIN Correct PIN? Yes? Conduct your transaction(s) No? Machine (eventually) eats card Part 3 Protocols 7

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

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 9

Authentication Protocols Part 3 Protocols 10

Authentication q 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) q Probably need to establish a session key q May have other requirements, such as q o Public keys, symmetric keys, hash functions, … o Anonymity, plausible deniability, perfect forward secrecy, etc. Part 3 Protocols 11

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

Simple Authentication “I’m Alice” Prove it My password is “frank” Alice Bob Simple and may be OK for standalone system q But highly insecure for networked system q o Subject to a replay attack (next 2 slides) o Also, Bob must know Alice’s password Part 3 Protocols 13

Authentication Attack “I’m Alice” Prove it My password is “frank” Bob Alice Trudy Part 3 Protocols 14

Authentication Attack “I’m Alice” Prove it My password is “frank” Trudy q This is an example of a replay attack q How can we prevent a replay? Part 3 Protocols Bob 15

Simple Authentication I’m Alice, my password is “frank” Alice q More efficient, but… q … same problem as previous version Part 3 Protocols Bob 16

Better Authentication “I’m Alice” Prove it h(Alice’s password) Alice q Bob This approach hides Alice’s password o From both Bob and Trudy q But still subject to replay attack Part 3 Protocols 17

Challenge-Response q To prevent replay, use challenge-response o Goal is to ensure “freshness” q Suppose Bob wants to authenticate Alice o Challenge sent from Bob to Alice q Challenge is chosen so that… o Replay is not possible o Only Alice can provide the correct response o Bob can verify the response Part 3 Protocols 18

Nonce q To ensure freshness, can employ a nonce o Nonce == number used once q What to use for nonces? o That is, what is the challenge? q What should Alice do with the nonce? o That is, how to compute the response? q How can Bob verify the response? q Should we use passwords or keys? Part 3 Protocols 19

Challenge-Response “I’m Alice” Nonce h(Alice’s password, Nonce) Alice 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 20

Generic Challenge-Response “I’m Alice” Nonce Alice Something that could only be from Alice, and Bob can verify Bob q In practice, how to achieve this? q Hashed password works, but… q …encryption is much better here (why? ) Part 3 Protocols 21

Symmetric Key Notation q Encrypt plaintext P with key K C = E(P, K) q Decrypt ciphertext C with key K P = D(C, K) q Here, we are concerned with attacks on protocols, not attacks on cryptography o So, we assume crypto algorithms are secure Part 3 Protocols 22

Authentication: Symmetric Key q Alice q Key and Bob share symmetric key K K known only to Alice and Bob q Authenticate by proving knowledge of shared symmetric key q How to accomplish this? o Cannot reveal key, must not allow replay (or other) attack, must be verifiable, … Part 3 Protocols 23

Authenticate Alice Using Symmetric Key “I’m Alice” R Alice, K E(R, K) Bob, K Secure method for Bob to authenticate Alice q But, Alice does not authenticate Bob q So, can we achieve mutual authentication? q Part 3 Protocols 24

Mutual Authentication? “I’m Alice”, R E(R, K) Alice, K E(R, K) Bob, K q What’s wrong with this picture? q “Alice” could be Trudy (or anybody else)! Part 3 Protocols 25

Mutual Authentication q Since we have a secure one-way authentication protocol… q The obvious thing to do is to use the protocol twice o Once for Bob to authenticate Alice o Once for Alice to authenticate Bob q This has got to work… Part 3 Protocols 26

Mutual Authentication “I’m Alice”, RA RB, E(RA, K) Alice, K E(RB, K) Bob, K q This provides mutual authentication… q …or does it? Subject to reflection attack o Next slide Part 3 Protocols 27

Mutual Authentication 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 Part 3 Protocols Bob, K 28

Mutual Authentication q Our one-way authentication protocol is not secure for mutual authentication o Protocols are subtle! o In this case, “obvious” solution is not secure q Also, if assumptions or environment change, protocol may not be secure o This is a common source of security failure o For example, Internet protocols Part 3 Protocols 29

Symmetric Key Mutual Authentication “I’m Alice”, RA RB, E(“Bob”, RA, K) E(“Alice”, RB, K) Alice, K Bob, K q Do these “insignificant” changes help? q Yes! Part 3 Protocols 30

Public Key Notation q Encrypt M with Alice’s public key: {M}Alice q Sign M with Alice’s private key: [M]Alice q Then o [{M}Alice ]Alice = M o {[M]Alice }Alice = M q Anybody can use Alice’s public key q Only Alice can use her private key Part 3 Protocols 31

Public Key Authentication “I’m Alice” {R}Alice R Alice Bob q Is this secure? q Trudy can get Alice to decrypt anything! Prevent this by having two key pairs Part 3 Protocols 32

Public Key Authentication “I’m Alice” R [R]Alice q Is this secure? q Trudy can get Alice to sign anything! Bob o Same a previous should have two key pairs Part 3 Protocols 33

Public Keys q Generally, a bad idea to use the same key pair for encryption and signing q Instead, should have… o …one key pair for encryption/decryption and signing/verifying signatures… o …and a different key pair for authentication Part 3 Protocols 34

Session Key q Usually, a session key is required o A symmetric key for current session o Used for confidentiality and/or integrity 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… o …and Trudy cannot determine the session key Part 3 Protocols 35

Authentication & Session Key “I’m Alice”, R {R, K}Alice q {R +1, K}Bob Is this secure? o Alice is authenticated and session key is secure o Alice’s “nonce”, R, useless to authenticate Bob o The key K is acting as Bob’s nonce to Alice q No mutual authentication Part 3 Protocols 36

Public Key Authentication and Session Key “I’m Alice”, R [R, K]Bob [R +1, K]Alice q Bob Is this secure? o Mutual authentication (good), but… o … session key is not protected (very bad) Part 3 Protocols 37

Public Key Authentication and Session Key “I’m Alice”, R {[R, K]Bob}Alice {[R +1, K]Alice}Bob Is this secure? q No! It’s subject to subtle Mi. M attack q o See the next slide… Part 3 Protocols 38

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

Public Key Authentication and Session Key “I’m Alice”, R [{R, K}Alice]Bob [{R +1, K}Bob]Alice q Is this secure? q Seems to be OK Bob o Anyone can see {R, K}Alice and {R +1, K}Bob Part 3 Protocols 40

Timestamps A timestamp T is derived from current time q Timestamps can be used to prevent replay q o Used in Kerberos, for example q Timestamps reduce number of msgs (good) o A challenge that both sides know in advance q “Time” is a security-critical parameter (bad) o Clocks not same and/or network delays, so must allow for clock skew creates risk of replay o How much clock skew is enough? Part 3 Protocols 41

Public Key Authentication with Timestamp T “I’m Alice”, {[T, K]Alice}Bob {[T +1, K]Bob}Alice Bob Secure mutual authentication? q Session key secure? q Seems to be OK q Part 3 Protocols 42

Public Key Authentication with Timestamp T “I’m Alice”, [{T, K}Bob]Alice [{T +1, K}Alice]Bob Alice Bob Secure authentication and session key? q Trudy can use Alice’s public key to find {T, K}Bob and then… q Part 3 Protocols 43

Public Key Authentication with Timestamp T “I’m Trudy”, [{T, K}Bob]Trudy [{T +1, K}Trudy]Bob Trudy obtains Alice-Bob session key K q Note: Trudy must act within clock skew q Part 3 Protocols 44

Public Key Authentication q Sign and encrypt with nonce… o Insecure q Encrypt and sign with nonce… o Secure q Sign and encrypt with timestamp… o Secure q Encrypt and sign with timestamp… o Insecure q Protocols can be subtle! Part 3 Protocols 45

Public Key Authentication with Timestamp T “I’m Alice”, [{T, K}Bob]Alice [{T +1}Alice]Bob Alice q Bob Is this “encrypt and sign” secure? o Yes, seems to be OK q Does “sign and encrypt” also work here? Part 3 Protocols 46

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

Perfect Forward Secrecy q q Suppose Alice and Bob share key K 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 48

Naïve Session Key Protocol E(KS, K) E(messages, KS) Alice, K q q Bob, K Trudy could record E(KS, K) 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 49

Perfect Forward Secrecy We can use Diffie-Hellman for PFS q Recall: public g and p q ga mod p gb mod p Alice, a Bob, b But Diffie-Hellman is subject to Mi. M q How to get PFS and prevent Mi. M? q Part 3 Protocols 50

Perfect Forward Secrecy E(ga mod p, K) E(gb mod p, K) Alice: K, a Bob: K, b Session key KS = gab mod p q Alice forgets a, Bob forgets b q This is known as Ephemeral Diffie-Hellman q Neither Alice nor Bob can later recover KS q Are there other ways to achieve PFS? q Part 3 Protocols 51

Mutual Authentication, Session Key and PFS “I’m Alice”, RA RB, [RA, gb mod p]Bob [RB, ga mod p]Alice Bob 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 q Part 3 Protocols 52

Authentication and TCP Part 3 Protocols 53

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

TCP 3 -way Handshake SYN, SEQ a SYN, ACK a+1, SEQ b ACK b+1, data Alice q Bob Initial sequence numbers: SEQ a and SEQ b o Supposed to be selected at random q If not, might have problems… Part 3 Protocols 55

TCP Authentication Attack 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 b 2 = Q 5. 5. 5. Part 3 Protocols E S 1, 5. Alice N, Y S. 4 t+ = K AC 56

TCP Authentication Attack Random SEQ numbers Initial SEQ numbers Mac OS X If initial SEQ numbers not very random… q …possible to guess initial SEQ number… q …and previous attack will succeed q Part 3 Protocols 57

TCP Authentication Attack q q q 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 58

Zero Knowledge Proofs Part 3 Protocols 59

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 q An “interactive proof system” Part 3 Protocols 60

Bob’s Cave q q Alice knows secret phrase to open path between R and S (“open sarsaparilla”) Can she convince Bob that she knows the secret without revealing phrase? Part 3 Protocols P Q R S 61

Bob’s Cave q q q Bob: “Alice, come out on S side” P Alice (quietly): “Open sarsaparilla” If Alice does not know the secret… Q 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 62

Fiat-Shamir Protocol q Cave-based protocols are inconvenient o Can we achieve same effect without the cave? q Finding square roots modulo N is difficult o Equivalent to factoring q Suppose N = pq, where p and q prime q Alice has a secret S q N and v = S 2 mod N are public, S is secret q Alice must convince Bob that she knows S without revealing any information about S Part 3 Protocols 63

Fiat-Shamir x = r 2 mod N e {0, 1} Alice secret S random r y = r Se mod N Bob random e q Public: Modulus N and v = S 2 mod N q Alice selects random r, Bob chooses e {0, 1} q Bob verifies: y 2 = x ve mod N o Note that y 2 = r 2 S 2 e = r 2 (S 2)e = x ve mod N Part 3 Protocols 64

Fiat-Shamir: e = 1 x = r 2 mod N e=1 Alice secret S random r y = r S mod N Bob random e Public: Modulus N and v = S 2 mod N q Alice selects random r, Bob chooses e =1 q If y 2 = x v mod N then Bob accepts it q o And Alice passes this iteration of the protocol q Note that Alice must know S in this case Part 3 Protocols 65

Fiat-Shamir: e = 0 x = r 2 mod N e=0 Alice secret S random r y = r mod N Bob random e Public: Modulus N and v = S 2 mod N q Alice selects random r, Bob chooses e = 0 q Bob must checks whether y 2 = x mod N q “Alice” does not need to know S in this case! q Part 3 Protocols 66

Fiat-Shamir q Public: modulus N and v = S 2 mod N q Secret: Alice knows S q Alice selects random r and commits to r by sending x = r 2 mod N to Bob q Bob sends challenge e {0, 1} to Alice q Alice responds with y = r Se mod N q Bob checks whether y 2 = x ve mod N o Does this prove response is from Alice? Part 3 Protocols 67

Does Fiat-Shamir Work? q If everyone follows protocol, math works: o Public: v = S 2 mod N o Alice to Bob: x = r 2 mod N and y = r Se mod N o Bob verifies: y 2 = x ve mod N q Can Trudy convince Bob she is Alice? o If Trudy expects e = 0, she follows the protocol: send x = r 2 in msg 1 and y = r in msg 3 o If Trudy expects e = 1, she sends x = r 2 v 1 in msg 1 and y = r in msg 3 q If Bob chooses e {0, 1} at random, Trudy can only trick Bob with probability 1/2 Part 3 Protocols 68

Fiat-Shamir Facts q Trudy can trick Bob with probability 1/2, but… o …after n iterations, the probability that Trudy can convince Bob that she is Alice is only 1/2 n o Just like Bob’s cave! q Bob’s e {0, 1} must be unpredictable q Alice must use new r each iteration, or else… o If e = 0, Alice sends r mod N in message 3 o If e = 1, Alice sends r S mod N in message 3 o Anyone can find S given r mod N and r S mod N Part 3 Protocols 69

Fiat-Shamir Zero Knowledge? q Zero knowledge means that nobody learns anything about the secret S o Public: v = S 2 mod N o Trudy sees r 2 mod N in message 1 o Trudy sees r S mod N in message 3 (if e = 1) q If Trudy can find r from r 2 mod N, she gets S o But that requires modular square root calculation o If Trudy could find modular square roots, she could get S from public v q Protocol does not seem to “help” to find S 70 Part 3 Protocols

ZKP in the Real World q Public key certificates identify users o No anonymity if certificates sent in plaintext q q ZKP offers a way to authenticate without revealing identities ZKP supported in MS’s Next Generation Secure Computing Base (NGSCB), where… o …ZKP used to authenticate software “without revealing machine identifying data” q ZKP is not just pointless mathematics! Part 3 Protocols 71

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 72

Chapter 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 73

Real-World Protocols q Next, we look at real protocols o SSH relatively simple & useful protocol o SSL practical security on the Web o IPSec security at the IP layer o Kerberos symmetric key, single sign-on o WEP “Swiss cheese” of security protocols o GSM mobile phone (in)security Part 3 Protocols 74

Secure Shell (SSH) Part 3 Protocols 75

SSH q Creates a “secure tunnel” q Insecure command sent thru SSH “tunnel” are then secure q SSH used with things like rlogin o Why is rlogin insecure without SSH? o Why is rlogin secure with SSH? q SSH is a relatively simple protocol Part 3 Protocols 76

SSH q SSH authentication can be based on: o Public keys, or o Digital certificates, or o Passwords q Here, we consider certificate mode o Other modes in homework problems q We consider slightly simplified SSH… Part 3 Protocols 77

Simplified SSH Alice, CP, RA Alice q q q CS, RB ga mod p gb mod p, certificate. B, SB E(Alice, certificate. A, SA, K) Bob CP = “crypto proposed”, and CS = “crypto selected” H = h(Alice, Bob, CP, CS, RA, RB, ga mod p, gb mod p, gab mod p) SB = [H]Bob SA = [H, Alice, certificate. A]Alice K = gab mod p Part 3 Protocols 78

Mi. M Attack on SSH? Alice, RA RB ga mod p RB gt mod p, cert. B, SB Alice E(Alice, cert. A, SA, K) q q Trudy gb mod p, cert. B, SB E(Alice, cert. A, SA, K) Bob Where does this attack fail? Alice computes Ha = h(Alice, Bob, CP, CS, RA, RB, ga mod p, gt mod p, gat mod p) q But Bob signs Hb = h(Alice, Bob, CP, CS, RA, RB, gt mod p, gbt mod p) Part 3 Protocols 79

Secure Socket Layer Part 3 Protocols 80

Socket layer q q “Socket layer” lives between application and transport layers SSL usually between HTTP and TCP Part 3 Protocols Socket “layer” application User transport OS network link NIC physical 81

What is SSL? SSL is the protocol used for majority of secure Internet transactions today q For example, if you want to buy a book at amazon. com… q o You want to be sure you are dealing with Amazon (authentication) o Your credit card information must be protected in transit (confidentiality and/or integrity) o As long as you have money, Amazon does not really care who you are… o …so, no need for mutual authentication Part 3 Protocols 82

Simple SSL-like Protocol I’d like to talk to you securely Here’s my certificate {K}Bob Alice protected HTTP q Is Alice sure she’s talking to Bob? q Is Bob sure he’s talking to Alice? Part 3 Protocols Bob 83

Simplified SSL Protocol Can we talk? , cipher list, RA certificate, cipher, RB {S}Bob, E(h(msgs, CLNT, K) Alice h(msgs, SRVR, K) Data protected with key K Bob S is the so-called pre-master secret q K = h(S, RA, RB) q “msgs” means all previous messages q CLNT and SRVR are constants q Part 3 Protocols 84

SSL Keys q 6 o o “keys” derived from K = h(S, RA, RB) 2 encryption keys: client and server 2 integrity keys: client and server 2 IVs: client and server Why different keys in each direction? q Q: Why is h(msgs, CLNT, K) encrypted? q A: Apparently, it adds no security… Part 3 Protocols 85

SSL Authentication q Alice authenticates Bob, not vice-versa o How does client authenticate server? o Why would server not authenticate client? q Mutual authentication is possible: Bob sends certificate request in message 2 o Then client must have a valid certificate o But, if server wants to authenticate client, server could instead require password Part 3 Protocols 86

SSL Mi. M Attack? Alice q q RA RA certificate. T, RB {S 1}Trudy, E(X 1, K 1) h(Y 1, K 1) E(data, K 1) certificate. B, RB {S 2}Bob, E(X 2, K 2) h(Y 2, K 2) E(data, K 2) Trudy Bob Q: What prevents this Mi. M “attack”? A: Bob’s certificate must be signed by a certificate authority (CA) q What does browser do if signature not valid? q What does user do when browser complains? Part 3 Protocols 87

SSL Sessions vs Connections q q q SSL session is established as shown on previous slides SSL designed for use with HTTP 1. 0 often opens multiple simultaneous (parallel) connections o Multiple connections per session q q SSL session is costly, public key operations SSL has an efficient protocol for opening new connections given an existing session Part 3 Protocols 88

SSL Connection session-ID, cipher list, RA session-ID, cipher, RB, h(msgs, SRVR, K) h(msgs, CLNT, K) Alice Protected data Bob q Assuming SSL session exists q So, S is already known to Alice and Bob q Both sides must remember session-ID q Again, K = h(S, RA, RB) q No public key operations! (relies on known S) Part 3 Protocols 89

SSL vs IPSec q IPSec discussed in next section o Lives at the network layer (part of the OS) o Encryption, integrity, authentication, etc. o Is overly complex, has some security “issues” q SSL (and IEEE standard known as TLS) o Lives at socket layer (part of user space) o Encryption, integrity, authentication, etc. o Relatively simple and elegant specification Part 3 Protocols 90

SSL vs IPSec q IPSec: OS must be aware, but not apps q SSL: Apps must be aware, but not OS q SSL built into Web early-on (Netscape) q IPSec often used in VPNs (secure tunnel) q Reluctance to retrofit applications for SSL q IPSec not widely deployed (complexity, etc. ) q The bottom line? q Internet less secure than it could be! Part 3 Protocols 91

IPSec Part 3 Protocols 92

IPSec and SSL IPSec lives at the network layer q IPSec is transparent to applications q SSL IPSec application User transport OS network link NIC physical Part 3 Protocols 93

IPSec and Complexity q IPSec is a complex protocol q Over-engineered o Lots of (generally useless) features q Flawed Some significant security issues q Interoperability is serious challenge o Defeats the purpose of having a standard! q Complex q And, did I mention, it’s complex? Part 3 Protocols 94

IKE and ESP/AH Two parts to IPSec… q IKE: Internet Key Exchange q o Mutual authentication o Establish session key o Two “phases” q like SSL session/connection ESP/AH o ESP: Encapsulating Security Payload confidentiality and/or integrity o AH: Authentication Header Part 3 Protocols for integrity only 95

IKE Part 3 Protocols 96

IKE q IKE has 2 phases o Phase 1 IKE security association (SA) o Phase 2 AH/ESP security association q Phase 1 is comparable to SSL session q Phase 2 is comparable to SSL connection q Not an obvious need for two phases in IKE o In the context of IPSec, that is q If multiple Phase 2’s do not occur, then it is more costly to have two phases! Part 3 Protocols 97

IKE Phase 1 q 4 different “key options” o Public key encryption (original version) o Public key encryption (improved version) o Public key signature o Symmetric key q For each of these, 2 different “modes” o Main mode and aggressive mode There are 8 versions of IKE Phase 1! q Need more evidence it’s over-engineered? q Part 3 Protocols 98

IKE Phase 1 q We discuss 6 of the 8 Phase 1 variants o Public key signatures (main & aggressive modes) o Symmetric key (main and aggressive modes) o Public key encryption (main and aggressive) q Why public key encryption and public key signatures? o Always know your own private key o May not (initially) know other side’s public key Part 3 Protocols 99

IKE Phase 1 q Uses ephemeral Diffie-Hellman to establish session key o Provides perfect forward secrecy (PFS) q Let a be Alice’s Diffie-Hellman exponent q Let b be Bob’s Diffie-Hellman exponent q Let g be generator and p prime q Recall that p and g are public Part 3 Protocols 100

IKE Phase 1: Digital Signature (Main Mode) IC, CP IC, RC, CS IC, RC, ga mod p, RA Alice IC, RC, gb mod p, RB IC, RC, E(“Alice”, proof. A, K) IC, RC, E(“Bob”, proof. B, K) CP = crypto proposed, CS = crypto selected q IC = initiator “cookie”, RC = responder “cookie” q K = h(IC, RC, gab mod p, RA, RB) q SKEYID = h(RA, RB, gab mod p) q proof. A = [h(SKEYID, ga mod p, gb mod p, IC, RC, CP, “Alice”)] Part 3 Protocols Alice Bob q 101

IKE Phase 1: Public Key Signature (Aggressive Mode) IC, “Alice”, ga mod p, RA, CP IC, RC, “Bob”, RB, gb mod p, CS, proof. B Alice q IC, RC, proof. A Bob Main differences from main mode o Not trying to hide identities o Cannot negotiate g or p Part 3 Protocols 102

Main vs Aggressive Modes q Main mode MUST be implemented q Aggressive mode SHOULD be implemented o So, if aggressive mode is not implemented, “you should feel guilty about it” q Might create interoperability issues q For public key signature authentication o Passive attacker knows identities of Alice and Bob in aggressive mode, but not in main mode o Active attacker can determine Alice’s and Bob’s identity in main mode Part 3 Protocols 103

IKE Phase 1: Symmetric Key (Main Mode) IC, CP IC, RC, CS IC, RC, ga mod p, RA Alice KAB q IC, RC, gb mod p, RB IC, RC, E(“Alice”, proof. A, K) IC, RC, E(“Bob”, proof. B, K) Bob KAB Same as signature mode except KAB = symmetric key shared in advance K = h(IC, RC, gab mod p, RA, RB, KAB) SKEYID = h(K, gab mod p) proof. A = h(SKEYID, ga mod p, gb mod Part 3 p, IC, RC, CP, “Alice”) Protocols o o 104

Problems with Symmetric Key (Main Mode) q Catch-22 o Alice sends her ID in message 5 o Alice’s ID encrypted with K o To find K Bob must know KAB o To get KAB Bob must know he’s talking to Alice! q Result: Alice’s IP address used as ID! q Useless mode for the “road warrior” q Why go to all of the trouble of trying to hide identities in 6 message protocol? Part 3 Protocols 105

IKE Phase 1: Symmetric Key (Aggressive Mode) IC, “Alice”, ga mod p, RA, CP IC, RC, “Bob”, RB, gb mod p, CS, proof. B Alice IC, RC, proof. A Bob q Same format as digital signature aggressive mode q Not trying to hide identities… q As a result, does not have problems of main mode q But does not (pretend to) hide identities Part 3 Protocols 106

IKE Phase 1: Public Key Encryption (Main Mode) IC, CP IC, RC, CS IC, RC, ga mod p, {RA}Bob, {“Alice”}Bob IC, RC, gb mod p, {RB}Alice, {“Bob”}Alice IC, RC, E(proof. A, K) IC, RC, E(proof. B, K) CP = crypto proposed, CS = crypto selected q IC = initiator “cookie”, RC = responder “cookie” q K = h(IC, RC, gab mod p, RA, RB) q SKEYID = h(RA, RB, gab mod p) q proof. A = h(SKEYID, ga mod p, gb mod Partp, IC, RC, CP, “Alice”) 3 Protocols Bob q 107

IKE Phase 1: Public Key Encryption (Aggressive Mode) IC, CP, ga mod p, {“Alice”}Bob, {RA}Bob IC, RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proof. B Alice IC, RC, proof. A Bob K, proof. A, proof. B computed as in main mode q Note that identities are hidden q o The only aggressive mode to hide identities o So, why have a main mode? Part 3 Protocols 108

Public Key Encryption Issue? q In public key encryption, aggressive mode… q Suppose Trudy generates o Exponents a and b o Nonces RA and RB q q Trudy can compute “valid” keys and proofs: gab mod p, K, SKEYID, proof. A and proof. B All of this also works in main mode Part 3 Protocols 109

Public Key Encryption Issue? IC, CP, ga mod p, {“Alice”}Bob, {RA}Bob IC, RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proof. B Trudy (as Alice) IC, RC, proof. A Trudy (as Bob) Trudy can create messages that appears to be between Alice and Bob q Appears valid to any observer, including Alice and Bob! q Part 3 Protocols 110

Plausible Deniability q Trudy can create fake “conversation” that appears to be between Alice and Bob o Appears valid, even to Alice and Bob! A security failure? q In IPSec public key option, it is a feature… q o Plausible deniability: Alice and Bob can deny that any conversation took place! q In some cases it might create a problem o E. g. , if Alice makes a purchase from Bob, she could later repudiate it (unless she had signed) Part 3 Protocols 111

IKE Phase 1 “Cookies” q IC and RC cookies (or “anti-clogging tokens”) supposed to prevent Do. S attacks o No relation to Web cookies q q q To reduce Do. S threats, Bob wants to remain stateless as long as possible But Bob must remember CP from message 1 (required for proof of identity in message 6) Bob must keep state from 1 st message on o So, these “cookies” offer little Do. S protection Part 3 Protocols 112

IKE Phase 1 Summary q Result of IKE phase 1 is o Mutual authentication o Shared symmetric key o IKE Security Association (SA) q But phase 1 is expensive o Especially in public key and/or main mode q Developers of IKE thought it would be used for lots of things not just IPSec o Partly explains the over-engineering… Part 3 Protocols 113

IKE Phase 2 q Phase 1 establishes IKE SA q Phase 2 establishes IPSec SA q Comparison to SSL… o SSL session is comparable to IKE Phase 1 o SSL connections are like IKE Phase 2 q IKE could be used for lots of things, but in practice, it’s not! Part 3 Protocols 114

IKE Phase 2 IC, RC, CP, E(hash 1, SA, RA, K) IC, RC, CS, E(hash 2, SA, RB, K) Alice q q q IC, RC, E(hash 3, K) Bob Key K, IC, RC and SA known from Phase 1 Proposal CP includes ESP and/or AH Hashes 1, 2, 3 depend on SKEYID, SA, RA and RB Keys derived from KEYMAT = h(SKEYID, RA, RB, junk) Recall SKEYID depends on phase 1 key method Optional PFS (ephemeral Diffie-Hellman exchange) Part 3 Protocols 115

IPSec q After IKE Phase 1, we have an IKE SA q After IKE Phase 2, we have an IPSec SA q q Authentication completed and have a shared symmetric key (session key) Now what? o We want to protect IP datagrams o But what is an IP datagram? o From the perspective of IPSec… Part 3 Protocols 116

IP Review q IP datagram is of the form IP header q data Where IP header is Part 3 Protocols 117

IP and TCP q Consider Web traffic, for example o IP encapsulates TCP and… o …TCP encapsulates HTTP IP header data IP header TCP hdr HTTP hdr app data q IP data includes TCP header, etc. Part 3 Protocols 118

IPSec Transport Mode q IPSec Transport Mode IP header data IP header IPSec header data q Transport mode designed for host-to-host q Transport mode is efficient o Adds minimal amount of extra header q The original header remains o Passive attacker can see who is talking Part 3 Protocols 119

IPSec: Host-to-Host q IPSec transport mode used here q There may be firewalls in between o If so, is that a problem? Part 3 Protocols 120

IPSec Tunnel Mode q IPSec Tunnel Mode IP header data new IP hdr IPSec hdr IP header data q Tunnel mode for firewall-to-firewall traffic q Original IP packet encapsulated in IPSec q Original IP header not visible to attacker o New IP header from firewall to firewall o Attacker does not know which hosts are talking Part 3 Protocols 121

IPSec: Firewall-to-Firewall q IPSec tunnel mode used here q Note: Local networks not protected q Is there any advantage here? Part 3 Protocols 122

Comparison of IPSec Modes q Transport Mode q o Host-to-host IP header data q Mode q IP header data q new IP hdr IPSec hdr Part 3 Protocols IP header data Tunnel Mode o Firewall-tofirewall IP header IPSec header data q Tunnel Transport Mode not necessary… …but it’s more efficient 123

IPSec Security q What kind of protection? o Confidentiality? o Integrity? o Both? q What to protect? o Data? o Header? o Both? q ESP/AH allow some combinations of these Part 3 Protocols 124

AH vs ESP q AH Authentication Header o Integrity only (no confidentiality) o Integrity-protect everything beyond IP header and some fields of header (why not all fields? ) q ESP Encapsulating Security Payload o Integrity and confidentiality both required o Protects everything beyond IP header o Integrity-only by using NULL encryption Part 3 Protocols 125

ESP NULL Encryption q According to RFC 2410 o NULL encryption “is a block cipher the origins of which appear to be lost in antiquity” o “Despite rumors”, there is no evidence that NSA “suppressed publication of this algorithm” o Evidence suggests it was developed in Roman times as exportable version of Caesar’s cipher o Can make use of keys of varying length o No IV is required o Null(P, K) = P for any P and any key K q Is ESP with NULL encryption same as AH ? Part 3 Protocols 126

Why Does AH Exist? (1) q Cannot encrypt IP header o Routers must look at the IP header o IP addresses, TTL, etc. o IP header exists to route packets! q AH protects immutable fields in IP header o Cannot integrity protect all header fields o TTL, for example, will change q ESP does not protect IP header at all Part 3 Protocols 127

Why Does AH Exist? (2) q q q ESP encrypts everything beyond the IP header (if non-null encryption) If ESP-encrypted, firewall cannot look at TCP header in host-to-host case Why not use ESP with NULL encryption? o Firewall sees ESP header, but does not know whether null encryption is used o End systems know, but not the firewalls Part 3 Protocols 128

Why Does AH Exist? (3) q The real reason why AH exists: o At one IETF meeting “someone from Microsoft gave an impassioned speech about how AH was useless…” o “…everyone in the room looked around and said `Hmm. He’s right, and we hate AH also, but if it annoys Microsoft let’s leave it in since we hate Microsoft more than we hate AH. ’ ” Part 3 Protocols 129

Kerberos Part 3 Protocols 130

Kerberos q In Greek mythology, Kerberos is 3 -headed dog that guards entrance to Hades o “Wouldn’t it make more sense to guard the exit? ” q In security, Kerberos is an authentication protocol based on symmetric key crypto o Originated at MIT o Based on Needham and Schroeder protocol o Relies on a Trusted Third Party (TTP) Part 3 Protocols 131

Motivation for Kerberos q Authentication using public keys o N users N key pairs q Authentication using symmetric keys o N users requires (on the order of) N 2 keys Symmetric key case does not scale q Kerberos based on symmetric keys but only requires N keys for N users q - Security depends on TTP + No PKI is needed Part 3 Protocols 132

Kerberos KDC q Kerberos Key Distribution Center or KDC o KDC acts as the TTP o TTP is trusted, so it must not be compromised KDC shares symmetric key KA with Alice, key KB with Bob, key KC with Carol, etc. q And a master key KKDC known only to KDC q KDC enables authentication, session keys q o Session key for confidentiality and integrity q In practice, crypto algorithm is DES Part 3 Protocols 133

Kerberos Tickets KDC issue tickets containing info needed to access network resources q KDC also issues Ticket-Granting Tickets or TGTs that are used to obtain tickets q Each TGT contains q o Session key o User’s ID o Expiration time q Every TGT is encrypted with KKDC o So, TGT can only be read by the KDC Part 3 Protocols 134

Kerberized Login q Alice enters her password q Then Alice’s computer does following: o Derives KA from Alice’s password o Uses KA to get TGT for Alice from KDC q Alice then uses her TGT (credentials) to securely access network resources q Plus: Security is transparent to Alice q Minus: KDC must be secure it’s trusted! Part 3 Protocols 135

Kerberized Login Alice wants Alice’s password a TGT E(SA, TGT, KA) Computer Alice KDC Key KA = h(Alice’s password) q KDC creates session key SA q Alice’s computer decrypts SA and TGT q o Then it forgets KA q TGT = E(“Alice”, SA, KKDC) Part 3 Protocols 136

Alice Requests “Ticket to Bob” I want to talk to Bob REQUEST Talk to Bob REPLY Alice q Computer KDC REQUEST = (TGT, authenticator) o authenticator = E(timestamp, SA) q REPLY = E(“Bob”, KAB, ticket to Bob, SA) o ticket to Bob = E(“Alice”, KAB, KB) q KDC gets SA from TGT to verify timestamp Part 3 Protocols 137

Alice Uses Ticket to Bob ticket to Bob, authenticator E(timestamp + 1, KAB) Alice’s Computer Bob ticket to Bob = E(“Alice”, KAB, KB) q authenticator = E(timestamp, KAB) q Bob decrypts “ticket to Bob” to get KAB which he then uses to verify timestamp q Part 3 Protocols 138

Kerberos q Key SA used in authentication o For confidentiality/integrity q Timestamps for authentication and replay protection q Recall, that timestamps… o Reduce the number of messages like a nonce that is known in advance o But, “time” is a security-critical parameter Part 3 Protocols 139

Questions about Kerberos q When Alice logs in, KDC sends E(SA, TGT, KA) where TGT = E(“Alice”, SA, KKDC) Q: Why is TGT encrypted with KA? A: Enables Alice to be anonymous when she later uses her TGT to request a ticket q q In Alice’s “Kerberized” login to Bob, why can Alice remain anonymous? Why is “ticket to Bob” sent to Alice? o Why doesn’t KDC send it directly to Bob? Part 3 Protocols 140

Kerberos Alternatives q Could have Alice’s computer remember password and use that for authentication o Then no KDC required o But hard to protect passwords o Also, does not scale q Could have KDC remember session key instead of putting it in a TGT o Then no need for TGT o But stateless KDC is major feature of Kerberos Part 3 Protocols 141

Kerberos Keys q In Kerberos, KA = h(Alice’s password) q Could instead generate random KA o Compute Kh = h(Alice’s password) o And Alice’s computer stores E(KA, Kh) q Then KA need not change when Alice changes her password o But E(KA, Kh) must be stored on computer q This alternative approach is often used o But not in Kerberos Part 3 Protocols 142

WEP Part 3 Protocols 143

WEP q q q WEP Wired Equivalent Privacy The stated goal of WEP is to make wireless LAN as secure as a wired LAN According to Tanenbaum: o “The 802. 11 standard prescribes a data linklevel 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 144

WEP Authentication Request R E(R, K) Alice, K Bob is wireless access point q Key K shared by access point and all users q o Key K seldom (if ever) changes q WEP has many, many security flaws Part 3 Protocols 145

WEP Issues q WEP uses RC 4 cipher for confidentiality o RC 4 can be a strong cipher o But WEP introduces a subtle flaw… o …making cryptanalytic attacks feasible q WEP uses CRC for “integrity” o Should have used a MAC, HMAC, or similar o CRC is for error detection, not crypto integrity o Everyone should know NOT to use CRC here… Part 3 Protocols 146

WEP Integrity Problems q WEP “integrity” gives no crypto integrity o CRC is linear, so is stream cipher (XOR) o Trudy can change ciphertext and CRC so that checksum on plaintext remains valid o Then Trudy’s introduced changes go undetected o Requires no knowledge of the plaintext! q CRC does not provide a cryptographic integrity check o CRC designed to detect random errors o Not to detect intelligent changes Part 3 Protocols 147

More WEP Integrity Issues Suppose Trudy knows destination IP q Then Trudy also knows keystream used to encrypt IP address, since q C = destination IP address keystream q Then Trudy can replace C with C = Trudy’s IP address keystream q And change the CRC so no error detected o Then what happens? ? q Moral: Big problems when integrity fails Part 3 Protocols 148

WEP Key q q Recall WEP uses a long-term key K RC 4 is a stream cipher, so each packet must be encrypted using a different key o Initialization Vector (IV) sent with packet o Sent in the clear, that is, IV is not secret o Note: IV similar to MI in WWII ciphers q Actual RC 4 key for packet is (IV, K) o That is, IV is pre-pended to long-term key K Part 3 Protocols 149

WEP Encryption IV, E(packet, KIV) Alice, K q Bob, K KIV = (IV, K) o That is, RC 4 key is K with 3 -byte IV pre-pended q The IV is known to Trudy Part 3 Protocols 150

WEP IV Issues q WEP uses 24 -bit (3 byte) IV o Each packet gets its own IV o Key: IV pre-pended to long-term key, K q Long term key K seldom changes q If long-term key and IV are same, then same keystream is used o This is bad, really bad! o Why? Part 3 Protocols 151

WEP IV Issues q Assume 1500 byte packets, 11 Mbps link q Suppose IVs generated in sequence o Since 1500 8/(11 106) 224 = 18, 000 seconds, an IV repeat in about 5 hours of traffic q Suppose IVs generated at random o By birthday problem, some IV repeats in seconds q Again, repeated IV (with same K) is bad Part 3 Protocols 152

Another Active Attack q Suppose Trudy can insert traffic and observe corresponding ciphertext o Then she knows the keystream for some IV o She can decrypt any packet that uses that IV q If Trudy does this many times, she can then decrypt data for lots of IVs o Remember, IV is sent in the clear q Is such an attack feasible? Part 3 Protocols 153

Cryptanalytic Attack q WEP data encrypted using RC 4 o Packet key is IV with long-term key K o 3 -byte IV is pre-pended to K o Packet key is (IV, K) q Recall IV is sent in the clear (not secret) o New IV sent with every packet o Long-term key K seldom changes (maybe never) q So Trudy always knows IV and ciphertext o Trudy wants to find the key K Part 3 Protocols 154

Cryptanalytic Attack 3 -byte IV pre-pended to key q Denote the RC 4 key bytes … o … as K 0, K 1, K 2, K 3, K 4, K 5, … o Where IV = (K 0, K 1, K 2) , which Trudy knows o Trudy wants to find K = (K 3, K 4, K 5, …) q Given enough IVs, Trudy can easily find key K q o o Regardless of the length of the key Provided Trudy knows first keystream byte Known plaintext attack (1 st byte of each packet) Prevent by discarding first 256 keystream bytes Part 3 Protocols 155

WEP Conclusions Many attacks are practical q Attacks have been used to recover keys and break real WEP traffic q How to prevent these attacks? q o Don’t use WEP o Good alternatives: WPA, WPA 2, etc. q How to make WEP a little better? o Restrict MAC addresses, don’t broadcast ID, … Part 3 Protocols 156

GSM (In)Security Part 3 Protocols 157

Cell Phones q First generation cell phones o Brick-sized, analog, few standards o Little or no security o Susceptible to cloning q Second generation cell phones: GSM o Began in 1982 as “Groupe Speciale Mobile” o Now, Global System for Mobile Communications q Third generation? o 3 rd Generation Partnership Project (3 GPP) Part 3 Protocols 158

GSM System Overview air interface Mobile Visited Network Part 3 Protocols Base Station Au. C VLR “land line” Base Station Controller PSTN Internet etc. HLR Home Network 159

GSM System Components q Mobile phone o Contains SIM (Subscriber Identity Module) q SIM is the security module o IMSI (International Mobile Subscriber ID) o User key: Ki (128 bits) o Tamper resistant (smart card) SIM o PIN activated (often not used) Part 3 Protocols 160

GSM System Components q Visited network where mobile is currently located o Base station one “cell” o Base station controller manages many cells o VLR (Visitor Location Register) info on all visiting mobiles currently in the network q Home network “home” of the mobile o HLR (Home Location Register) keeps track of most recent location of mobile o Au. C (Authentication Center) has IMSI and Part 3 Protocols Ki 161

GSM Security Goals q Primary design goals o Make GSM as secure as ordinary telephone o Prevent phone cloning q Not designed to resist an active attacks o At the time this seemed infeasible o Today such an attacks are clearly feasible… q Designers considered biggest threats to be o Insecure billing o Corruption o Other low-tech attacks Part 3 Protocols 162

GSM Security Features q Anonymity o Intercepted traffic does not identify user o Not so important to phone company q Authentication o Necessary for proper billing o Very, very important to phone company! q Confidentiality of calls over the air interface o Not important to phone company… o …except for marketing Part 3 Protocols 163

GSM: Anonymity q q IMSI used to initially identify caller Then TMSI (Temporary Mobile Subscriber ID) used o TMSI changed frequently o TMSI’s encrypted when sent q Not a strong form of anonymity q But probably useful in many cases Part 3 Protocols 164

GSM: Authentication q Caller is authenticated to base station q Authentication is not mutual q Authentication via challenge-response o Home network generates RAND and computes XRES = A 3(RAND, Ki) where A 3 is a hash o Then (RAND, XRES) sent to base station o Base station sends challenge RAND to mobile o Mobile’s response is SRES = A 3(RAND, Ki) o Base station verifies SRES = XRES q Note: Ki never leaves home network Part 3 Protocols 165

GSM: Confidentiality Data encrypted with stream cipher q Error rate estimated at about 1/1000 q o Error rate is high for a block cipher q Encryption key Kc o Home network computes Kc = A 8(RAND, Ki) where A 8 is a hash o Then Kc sent to base station with (RAND, XRES) o Mobile computes Kc = A 8(RAND, Ki) o Keystream generated from A 5(Kc) q Note: Ki never leaves home network Part 3 Protocols 166

GSM Security 1. IMSI 2. IMSI 4. RAND Mobile q 5. SRES 6. Encrypt with Kc 3. (RAND, XRES, Kc) Base Station Home Network SRES and Kc must be uncorrelated o Even though both are derived from RAND and Ki q Must not be possible to deduce Ki from known RAND/SRES pairs (known plaintext attack) q Must not be possible to deduce Ki from chosen RAND/SRES pairs (chosen plaintext attack) o With possession of SIM, attacker can choose RAND’s Part 3 Protocols 167

GSM Insecurity (1) q Hash used for A 3/A 8 is COMP 128 o Broken by 160, 000 chosen plaintexts o With SIM, can get Ki in 2 to 10 hours q Encryption between mobile and base station but no encryption from base station to base station controller Base Station VLR o Often transmitted over microwave link q Encryption algorithm A 5/1 o Broken with 2 seconds of known plaintext Part 3 Protocols Base Station Controller 168

GSM Insecurity (2) q Attacks on SIM card o Optical Fault Induction could attack SIM with a flashbulb to recover Ki o Partitioning Attacks using timing and power consumption, could recover Ki with only 8 adaptively chosen “plaintexts” q With possession of SIM, attacker could recover Ki in seconds Part 3 Protocols 169

GSM Insecurity (3) q Fake base station exploits two flaws 1. Encryption not automatic 2. Base station not authenticated RAND SRES Mobile q No encryption Call to destination Fake Base Station Note: GSM bill goes to fake base station! Part 3 Protocols 170

GSM Insecurity (4) q Denial of service is possible o Jamming (always an issue in wireless) q Can replay triple: (RAND, XRES, Kc) o One compromised triple gives attacker a key Kc that is valid forever o No replay protection here Part 3 Protocols 171

GSM Conclusion q Did GSM achieve its goals? o Eliminate cloning? Yes, as a practical matter o Make air interface as secure as PSTN? Perhaps… q q But design goals were clearly too limited GSM 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 172

3 rd Generation Partnership Project (3 GPP) q 3 G security built on GSM (in)security q 3 G fixed known GSM security problems o Mutual authentication o Integrity-protect signaling (such as “start encryption” command) o Keys (encryption/integrity) cannot be reused o Triples cannot be replayed o Strong encryption algorithm (KASUMI) o Encryption extended to base station controller Part 3 Protocols 173

Protocols Summary q Generic authentication protocols o Protocols are subtle! q SSH q SSL q IPSec q Kerberos q Wireless: Part 3 Protocols GSM and WEP 174

Coming Attractions… q Software and security o Software flaws buffer overflow, etc. o Malware viruses, worms, etc. o Software reverse engineering o Digital rights management o OS and security/NGSCB Part 3 Protocols 175