
8c41324964bffb413337bee7ea405dee.ppt
- Количество слайдов: 24
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 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 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 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 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. 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 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 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 • 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 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 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 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 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 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 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 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 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 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 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 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 key distribution r uses authentication server separate from access point
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 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