Скачать презентацию IPsec Internet Headquarters 200 168 1 100 SA Скачать презентацию IPsec Internet Headquarters 200 168 1 100 SA

8c41324964bffb413337bee7ea405dee.ppt

  • Количество слайдов: 24

IPsec Internet Headquarters 200. 168. 1. 100 SA Branch Office 193. 68. 2. 23 IPsec Internet Headquarters 200. 168. 1. 100 SA Branch Office 193. 68. 2. 23 R 1 R 2 172. 16. 1/24 172. 16. 2/24 “enchilada” authenticated encrypted new IP header ESP hdr SPI original IP hdr Seq # Original IP datagram payload padding ESP trl ESP auth pad next length header 1

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

Inside the enchilada: “enchilada” authenticated encrypted new IP header ESP hdr SPI original IP Inside the enchilada: “enchilada” authenticated encrypted new IP header ESP hdr SPI original IP hdr Seq # Original IP datagram payload padding ESP trl ESP auth pad next length header 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 3

IPsec sequence numbers r For new SA, sender initializes seq. # to 0 r 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 4

Security Policy Database (SPD) r Policy: For a given datagram, sending entity needs to 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. 5

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

Internet Key Exchange r In previous examples, we manually established IPsec SAs in IPsec 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: 3 DES-cbc HMAC algorithm: MD 5 Encryption key: 0 x 7 aeaca… HMAC key: 0 xc 0291 f… r Such manually keying is impractical for large VPN with, say, hundreds of sales people. r Instead use IPsec IKE (Internet Key Exchange) 7

IKE: PSK and PKI r Authentication (proof who you are) with either m pre-shared 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. 8

IKE Phases r IKE has two phases m Phase 1: Establish bi-directional IKE SA 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 9

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

Lecture 22 Wireless Security CPE 401/601 Computer Network Systems All material copyright 1996 -2009 Lecture 22 Wireless Security CPE 401/601 Computer Network Systems All material copyright 1996 -2009 J. F Kurose and K. W. Ross, All Rights Reserved slides are modified from Jim Kurose & Keith Ross

Chapter 8 roadmap 8. 1 What is network security? 8. 2 Principles of cryptography Chapter 8 roadmap 8. 1 What is network security? 8. 2 Principles of cryptography 8. 3 Message integrity 8. 4 Securing e-mail 8. 5 Securing TCP connections: SSL 8. 6 Network layer security: IPsec 8. 7 Securing wireless LANs 8. 8 Operational security: firewalls and IDS

WEP Design Goals r Symmetric key crypto m Confidentiality m Station authorization m Data 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 • Unlike Cipher Block Chaining (CBC) in block ciphers r Efficient m Can be implemented in hardware or software 13

Review: Symmetric Stream Ciphers keystream generator keystream r Combine each byte of keystream with Review: Symmetric Stream Ciphers keystream generator keystream r Combine each byte of keystream with byte of r r r plaintext to get ciphertext m(i) = ith unit of message ks(i) = ith unit of keystream c(i) = ith unit of ciphertext c(i) = ks(i) m(i) ( = exclusive or) m(i) = ks(i) c(i) WEP uses RC 4 14

Stream cipher and packet independence r Recall design goal: each packet separately encrypted r 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: Key+IVpacket keystream generator keystreampacket 15

WEP encryption (1) r Sender calculates Integrity Check Value (ICV) over data m four-byte 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 key. ID (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 RC 4: m m m Bytes of keystream are XORed with bytes of data & ICV IV & key. ID are appended to encrypted data to create payload Payload inserted into 802. 11 frame encrypted IV Key data ID MAC payload ICV 16

WEP encryption (2) New IV for each frame 17 WEP encryption (2) New IV for each frame 17

WEP decryption overview encrypted IV Key data ID ICV MAC payload r Receiver extracts WEP decryption overview encrypted IV Key data ID ICV MAC payload 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). 18

End-point authentication w/ nonce Nonce: number (R) used only once –in-a-lifetime How: to prove 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 KA-B(R) Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice! 19

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

Breaking 802. 11 WEP encryption security hole: r 24 -bit IV, one IV per 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 … IV m Trudy sees: ci = di XOR ki knows ci di, so can compute ki. IV IV m Trudy knows encrypting key sequence k 1 k 2 k 3 … m Next time IV is used, Trudy can decrypt! m Trudy

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

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

EAP: extensible authentication protocol r EAP: end-end client (mobile) to authentication server protocol r 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) wired network EAP TLS EAP over LAN (EAPo. L) IEEE 802. 11 RADIUS UDP/IP