1. Real Security Protocols 1. Securing e-mail 2. Securing TCP connections: SSL 3. Network layer security: IPsec 4. Securing wireless LANs Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley

2. Secure e-mail Alice:  generates random symmetric private key, K S.  encrypts message with K S (for efficiency)  also encrypts K S with Bob’s public key.  sends both K S (m) and K B (K S ) to Bob.  Alice wants to send confidential e-mail, m, to Bob. K S ( ). K B ( ). + + - K S (m ) K B (K S ) + m KSKS KSKS KBKB + Internet K S ( ). K B ( ). - KBKB - KSKS m K S (m ) K B (K S ) +

3. Secure e-mail Bob:  uses his private key to decrypt and recover K S  uses K S to decrypt K S (m) to recover m  Alice wants to send confidential e-mail, m, to Bob. K S ( ). K B ( ). + + - K S (m ) K B (K S ) + m KSKS KSKS KBKB + Internet K S ( ). K B ( ). - KBKB - KSKS m K S (m ) K B (K S ) +

4. Secure e-mail (continued) Alice wants to provide sender authentication message integrity. Alice digitally signs message. sends both message (in the clear) and digital signature. H( ). K A ( ). - + - H(m ) K A (H(m)) - m KAKA - Internet m K A ( ). + KAKA + K A (H(m)) - m H( ). H(m ) compare

5. Secure e-mail (continued) Alice wants to provide secrecy, sender authentication, message integrity. Alice uses three keys: her private key, Bob’s public key, newly created symmetric key H( ). K A ( ). - + K A (H(m)) - m KAKA - m K S ( ). K B ( ). + + K B (K S ) + KSKS KBKB + Internet KSKS

6. Real Security Protocols 1. Securing e-mail 2. Securing TCP connections: SSL 3. Network layer security: IPsec 4. Securing wireless LANs

7. 7 SSL: Secure Sockets Layer r Widely deployed security protocol m Supported by almost all browsers and web servers m https m Tens of billions $ spent per year over SSL r Originally designed by Netscape in 1993 r Number of variations: m TLS: transport layer security, RFC 2246 r Provides m Confidentiality m Integrity m Authentication r Original goals: m Had Web e-commerce transactions in mind m Encryption (especially credit-card numbers) m Web-server authentication m Optional client authentication m Minimum hassle in doing business with new merchant r Available to all TCP applications m Secure socket interface

8. 8 SSL and TCP/IP Application TCP IP Normal Application Application SSL TCP IP Application with SSL SSL provides application programming interface (API) to applications C and Java SSL libraries/classes readily available

9. 9 Could do something like PGP: But want to send byte streams & interactive data Want a set of secret keys for the entire connection Want certificate exchange part of protocol: handshake phase H( ). K A ( ). - + K A (H(m)) - m KAKA - m K S ( ). K B ( ). + + K B (K S ) + KSKS KBKB + Internet KSKS

10. 10 Toy SSL: a simple secure channel r Handshake: Alice and Bob use their certificates and private keys to authenticate each other and exchange shared secret r Key Derivation: Alice and Bob use shared secret to derive set of keys r Data Transfer: Data to be transferred is broken up into a series of records r Connection Closure: Special messages to securely close connection

11. 11 Toy: A simple handshake r MS = master secret r EMS = encrypted master secret hello certificate K B + (MS) = EMS

12. 12 Toy: Key derivation r Considered bad to use same key for more than one cryptographic operation m Use different keys for message authentication code (MAC) and encryption r Four keys: m K c = encryption key for data sent from client to server m M c = MAC key for data sent from client to server m K s = encryption key for data sent from server to client m M s = MAC key for data sent from server to client r Keys derived from key derivation function (KDF) m Takes master secret and (possibly) some additional random data and creates the keys

13. 13 Toy: Data Records r Why not encrypt data in constant stream as we write it to TCP? m Where would we put the MAC? If at end, no message integrity until all data processed. m For example, with instant messaging, how can we do integrity check over all bytes sent before displaying? r Instead, break stream in series of records m Each record carries a MAC m Receiver can act on each record as it arrives r Issue: in record, receiver needs to distinguish MAC from data m Want to use variable-length records lengthdataMAC

14. 14 Toy: Sequence Numbers r Attacker can capture and replay record or re-order records r Solution: put sequence number into MAC: m MAC = MAC(M x, sequence||data) m Note: no sequence number field r Attacker could still replay all of the records m Use random nonce

15. 15 Toy: Control information r Truncation attack: m attacker forges TCP connection close segment m One or both sides thinks there is less data than there actually is. r Solution: record types, with one type for closure m type 0 for data; type 1 for closure r MAC = MAC(M x, sequence||type||data) lengthtypedataMAC

16. 16 Toy SSL: summary hello certificate, nonce K B + (MS) = EMS type 0, seq 1, data type 0, seq 2, data type 0, seq 1, data type 0, seq 3, data type 1, seq 4, close type 1, seq 2, close encrypted bob.com

17. 17 Toy SSL isn’t complete r How long are the fields? r What encryption protocols? r No negotiation m Allow client and server to support different encryption algorithms m Allow client and server to choose together specific algorithm before data transfer

18. 18 Most common symmetric ciphers in SSL r DES – Data Encryption Standard: block r 3DES – Triple strength: block r RC2 – Rivest Cipher 2: block r RC4 – Rivest Cipher 4: stream Public key encryption r RSA

19. 19 SSL Cipher Suite r Cipher Suite m Public-key algorithm m Symmetric encryption algorithm m MAC algorithm r SSL supports a variety of cipher suites r Negotiation: client and server must agree on cipher suite r Client offers choice; server picks one

20. 20 Real SSL: Handshake (1) Purpose 1. Server authentication 2. Negotiation: agree on crypto algorithms 3. Establish keys 4. Client authentication (optional)

21. 21 Real SSL: Handshake (2) 1. Client sends list of algorithms it supports, along with client nonce 2. Server chooses algorithms from list; sends back: choice + certificate + server nonce 3. Client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server 4. Client and server independently compute encryption and MAC keys from pre_master_secret and nonces 5. Client sends a MAC of all the handshake messages 6. Server sends a MAC of all the handshake messages

22. 22 Real SSL: Handshaking (3) Last 2 steps protect handshake from tampering r Client typically offers range of algorithms, some strong, some weak r Man-in-the middle could delete the stronger algorithms from list r Last 2 steps prevent this m Last two messages are encrypted

23. 23 Real SSL: Handshaking (4) r Why the two random nonces? r Suppose Trudy sniffs all messages between Alice & Bob. r Next day, Trudy sets up TCP connection with Bob, sends the exact same sequence of records,. m Bob (Amazon) thinks Alice made two separate orders for the same thing. m Solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days. m Trudy’s messages will fail Bob’s integrity check.

24. 24 SSL Record Protocol data fragment data fragment MAC encrypted data and MAC encrypted data and MAC record header record header record header: content type; version; length MAC: includes sequence number, MAC key M x Fragment: each SSL fragment 2 14 bytes (~16 Kbytes)

25. 25 SSL Record Format content type SSL version length MAC data 1 byte 2 bytes3 bytes Data and MAC encrypted (symmetric algo)

26. 26 handshake: ClientHello handshake: ServerHello handshake: Certificate handshake: ServerHelloDone handshake: ClientKeyExchange ChangeCipherSpec handshake: Finished ChangeCipherSpec handshake: Finished application_data Alert: warning, close_notify Real Connection TCP Fin follow Everything henceforth is encrypted

27. 27 Key derivation r Client nonce, server nonce, and pre-master secret input into pseudo random-number generator. m Produces master secret r Master secret and new nonces inputed into another random-number generator: “key block” m Because of resumption: TBD r Key block sliced and diced: m client MAC key m server MAC key m client encryption key m server encryption key m client initialization vector (IV) m server initialization vector (IV)

28. Real Security Protocols 1. Securing e-mail 2. Securing TCP connections: SSL 3. Network layer security: IPsec 4. Securing wireless LANs

29. 29 What is confidentiality at the network-layer? Between two network entities: r Sending entity encrypts the payloads of datagrams. Payload could be: m TCP segment, UDP segment, ICMP message, OSPF message, and so on. r All data sent from one entity to the other would be hidden: m Web pages, e-mail, P2P file transfers, TCP SYN packets, and so on. r That is, “blanket coverage”.

30. 30 Virtual Private Networks (VPNs) r Institutions often want private networks for security. m Costly! Separate routers, links, DNS infrastructure. r With a VPN, institution’s inter-office traffic is sent over public Internet instead. m But inter-office traffic is encrypted before entering public Internet

31. 31 IP header IPsec header Secure payload IP header IPsec header Secure payload IP header IPsec header Secure payload IP header payload IP header payload headquarters branch office salesperson in hotel Public Internet laptop w/ IPsec Router w/ IPv4 and IPsec Router w/ IPv4 and IPsec Virtual Private Network (VPN)

32. 32 IPsec services r Data integrity r Origin authentication r Replay attack prevention r Confidentiality r Two protocols providing different service models: m AH m ESP

33. 33 IPsec Transport Mode r IPsec datagram emitted and received by end-system. r Protects upper level protocols IPsec

34. 34 IPsec – tunneling mode (1) r End routers are IPsec aware. Hosts need not be. IPsec

35. 35 IPsec – tunneling mode (2) r Also tunneling mode. IPsec

36. Two protocols r Authentication Header (AH) protocol m provides source authentication & data integrity but not confidentiality r Encapsulation Security Protocol (ESP) m provides source authentication,data integrity, and confidentiality m more widely used than AH 36

37. 37 Four combinations are possible! Host mode with AH Host mode with ESP Tunnel mode with AH Tunnel mode with ESP Most common and most important

38. 38 Security associations (SAs) r Before sending data, a virtual connection is established from sending entity to receiving entity. r Called “security association (SA)” m SAs are simplex: for only one direction r Both sending and receiving entites maintain state information about the SA m Recall that TCP endpoints also maintain state information. m IP is connectionless; IPsec is connection-oriented! r How many SAs in VPN w/ headquarters, branch office, and n traveling salesperson?

39. 39 193.68.2.23 200.168.1.100 172.16.1/24 172.16.2/24 SA Internet Headquarters Branch Office R1 R2 Example SA from R1 to R2 R1 stores for SA r 32-bit identifier for SA: Security Parameter Index (SPI) r the origin interface of the SA (200.168.1.100) r destination interface of the SA (193.68.2.23) r type of encryption to be used (for example, 3DES with CBC) r encryption key r type of integrity check (for example, HMAC with with MD5) r authentication key

40. 40 Security Association Database (SAD) r Endpoint holds state of its SAs in a SAD, where it can locate them during processing. r With n salespersons, 2 + 2n SAs in R1’s SAD r When sending IPsec datagram, R1 accesses SAD to determine how to process datagram. r When IPsec datagram arrives to R2, R2 examines SPI in IPsec datagram, indexes SAD with SPI, and processes datagram accordingly.

41. 41 IPsec datagram Focus for now on tunnel mode with ESP new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth encrypted “enchilada” authenticated padding pad length next header SPI Seq #

42. 42 What happens? 193.68.2.23 200.168.1.100 172.16.1/24 172.16.2/24 SA Internet Headquarters Branch Office R1 R2 new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth encrypted “enchilada” authenticated padding pad length next header SPI Seq #

43. 43 R1 converts original datagram into IPsec datagram r Appends to back of original datagram (which includes original header fields!) an “ESP trailer” field. r Encrypts result using algorithm & key specified by SA. r Appends to front of this encrypted quantity the “ESP header, creating “enchilada”. r Creates authentication MAC over the whole enchilada, using algorithm and key specified in SA; r Appends MAC to back of enchilada, forming payload; r Creates brand new IP header, with all the classic IPv4 header fields, which it appends before payload.

44. 44 Inside the enchilada: r ESP trailer: Padding for block ciphers r ESP header: m SPI, so receiving entity knows what to do m Sequence number, to thwart replay attacks r MAC in ESP auth field is created with shared secret key new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth encrypted “enchilada” authenticated padding pad length next header SPI Seq #

45. 45 IPsec sequence numbers r For new SA, sender initializes seq. # to 0 r Each time datagram is sent on SA: m Sender increments seq # counter m Places value in seq # field r Goal: m Prevent attacker from sniffing and replaying a packet Receipt of duplicate, authenticated IP packets may disrupt service r Method: m Destination checks for duplicates m But doesn’t keep track of ALL received packets; instead uses a window

46. 46 Security Policy Database (SPD) r Policy: For a given datagram, sending entity needs to know if it should use IPsec. r Needs also to know which SA to use m May use: source and destination IP address; protocol number. r Info in SPD indicates “what” to do with arriving datagram; r Info in the SAD indicates “how” to do it.

47. Summary: IPsec services r Suppose Trudy sits somewhere between R1 and R2. She doesn’t know the keys. m Will Trudy be able to see contents of original datagram? How about source, dest IP address, transport protocol, application port? m Flip bits without detection? m Masquerade as R1 using R1’s IP address? m Replay a datagram? 47

48. 48 Internet Key Exchange r In previous examples, we manually established IPsec SAs in IPsec endpoints: Example SA SPI: 12345 Source IP: 200.168.1.100 Dest IP: 193.68.2.23 Protocol: ESP Encryption algorithm: 3DES-cbc HMAC algorithm: MD5 Encryption key: 0x7aeaca… HMAC key: 0xc0291f … r Such manually keying is impractical for large VPN with, say, hundreds of sales people. r Instead use IPsec IKE (Internet Key Exchange)

49. 49 IKE: PSK and PKI r Authentication (proof who you are) with either m pre-shared secret (PSK) or m with PKI (pubic/private keys and certificates). r With PSK, both sides start with secret: m then run IKE to authenticate each other and to generate IPsec SAs (one in each direction), including encryption and authentication keys r With PKI, both sides start with public/private key pair and certificate. m run IKE to authenticate each other and obtain IPsec SAs (one in each direction). m Similar with handshake in SSL.

50. 50 IKE Phases r IKE has two phases m Phase 1: Establish bi-directional IKE SA Note: IKE SA different from IPsec SA Also called ISAKMP security association m Phase 2: ISAKMP is used to securely negotiate the IPsec pair of SAs r Phase 1 has two modes: aggressive mode and main mode m Aggressive mode uses fewer messages m Main mode provides identity protection and is more flexible

51. 51 Summary of IPsec r IKE message exchange for algorithms, secret keys, SPI numbers r Either the AH or the ESP protocol (or both) r The AH protocol provides integrity and source authentication r The ESP protocol (with AH) additionally provides encryption r IPsec peers can be two end systems, two routers/firewalls, or a router/firewall and an end system

52. Real Security Protocols 1. Securing e-mail 2. Securing TCP connections: SSL 3. Network layer security: IPsec 4. Securing wireless LANs

53. 53 WEP Design Goals r Symmetric key crypto m Confidentiality m Station authorization m Data integrity r Self synchronizing: each packet separately encrypted m Given encrypted packet and key, can decrypt; can continue to decrypt packets when preceding packet was lost m Unlike Cipher Block Chaining (CBC) in block ciphers r Efficient m Can be implemented in hardware or software

54. 54 Review: Symmetric Stream Ciphers r Combine each byte of keystream with byte of plaintext to get ciphertext r m(i) = ith unit of message r ks(i) = ith unit of keystream r c(i) = ith unit of ciphertext r c(i) = ks(i)  m(i) (  = exclusive or) r m(i) = ks(i)  c(i) r WEP uses RC4 keystream generator key keystream

55. 55 Stream cipher and packet independence r Recall design goal: each packet separately encrypted r If for frame n+1, use keystream from where we left off for frame n, then each frame is not separately encrypted m Need to know where we left off for packet n r WEP approach: initialize keystream with key + new IV for each packet: keystream generator Key+IV packet keystream packet

56. 56 WEP encryption (1) r Sender calculates Integrity Check Value (ICV) over data m four-byte hash/CRC for data integrity r Each side has 104-bit shared key r Sender creates 24-bit initialization vector (IV), appends to key: gives 128-bit key r Sender also appends keyID (in 8-bit field) r 128-bit key inputted into pseudo random number generator to get keystream r data in frame + ICV is encrypted with RC4: m Bytes of keystream are XORed with bytes of data & ICV m IV & keyID are appended to encrypted data to create payload m Payload inserted into 802.11 frame encrypted dataICVIV MAC payload Key ID

57. 57 WEP encryption (2) New IV for each frame

58. 58 WEP decryption overview r Receiver extracts IV r Inputs IV and shared secret key into pseudo random generator, gets keystream r XORs keystream with encrypted data to decrypt data + ICV r Verifies integrity of data with ICV m Note that message integrity approach used here is different from the MAC (message authentication code) and signatures (using PKI). encrypted dataICVIV MAC payload Key ID

59. 59 End-point authentication w/ nonce Nonce: number (R) used only once –in-a-lifetime How: to prove Alice “live”, Bob sends Alice nonce, R. Alice must return R, encrypted with shared secret key “I am Alice” R K (R) A-B Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice!

60. 60 WEP Authentication AP authentication request nonce (128 bytes) nonce encrypted shared key success if decrypted value equals nonce Not all APs do it, even if WEP is being used. AP indicates if authentication is necessary in beacon frame. Done before association.

61. Breaking 802.11 WEP encryption security hole: r 24-bit IV, one IV per frame, -> IV’s eventually reused r IV transmitted in plaintext -> IV reuse detected r attack: m Trudy causes Alice to encrypt known plaintext d 1 d 2 d 3 d 4 … m Trudy sees: c i = d i XOR k i IV m Trudy knows c i d i, so can compute k i IV m Trudy knows encrypting key sequence k 1 IV k 2 IV k 3 IV … m Next time IV is used, Trudy can decrypt!

62. 802.11i: improved security r numerous (stronger) forms of encryption possible r provides key distribution r uses authentication server separate from access point

63. AP: access point AS: Authentication server wired network STA: client station 1 Discovery of security capabilities 3 STA and AS mutually authenticate, together generate Master Key (MK). AP servers as “pass through” 2 3 STA derives Pairwise Master Key (PMK) AS derives same PMK, sends to AP 4 STA, AP use PMK to derive Temporal Key (TK) used for message encryption, integrity 802.11i: four phases of operation

64. wired network EAP TLS EAP EAP over LAN (EAPoL) IEEE 802.11 RADIUS UDP/IP EAP: extensible authentication protocol r EAP: end-end client (mobile) to authentication server protocol r EAP sent over separate “links” m mobile-to-AP (EAP over LAN) m AP to authentication server (RADIUS over UDP)