1 / 48

CSCI 467 – IP and Web Security

CSCI 467 – IP and Web Security. Chapter 16, 17 from Cryptography and Network Security, 4 th Edition, William Stallings. Jason Detchevery With slides adapted from Lawrie Brown April 1 st 2009. IP Security Chapter 16. IP Security. Chapter Goals Understand why we use IP Security (IPSec)

crete
Télécharger la présentation

CSCI 467 – IP and Web Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSCI 467 – IP and Web Security Chapter 16, 17 from Cryptography and Network Security, 4th Edition, William Stallings Jason Detchevery With slides adapted from Lawrie Brown April 1st 2009

  2. IP SecurityChapter 16

  3. IP Security • Chapter Goals • Understand why we use IP Security (IPSec) • To learn how IP Security works • Gain insight on the specific sections • The pros and cons of IP Security • Learn of specific implementations IP Security • Learn of IP Security Architecture and Standers

  4. IP Security • Purpose of IP Security • Application specific security measures insufficient • Organizations have needs of security which cut layers • IP-level security enhances both application security already in place, and provides to security to applications lacking security • What an IP Security system should provide • Three functional areas • Authentication • Confidentiality • Key management • Look at security architecture, then each of the functional areas

  5. IP Security Overview • IP Security: Known as “IPSec” • IPv6 (successor to IPv4) has authentication and encryption • IPSec was designed to be work with both IPv4 and IPv6 • In v6, IPSec’s implementation is mandatory • For IPv4, it’s still optional • Benefit is v6 security can be rolled out immediately, before v6 is mainstream

  6. IPSec Applications • Secure communications across a LAN • Indented uses of IPSec: • Companies can use Internet for secure intra-office communication • Secure remote access (VPN, dial systems) from external computer to secured network • Secure connectively of terminals between companies • Adding security to E – commerce (which as application level security)

  7. IPSec Applications

  8. IPSec Benefits • Applied on a router level to all traffic • Hard to bypass when used for firewall implementation • Below the transport layer: software is unaffected • Transparent to users • Can be customized to specific users • IPSec used in routing: • router advertisements are authentic • neighbor advertisements are authentic • verification of redirect messages • prevents update forges

  9. IP Security Architecture • Complex specification (many documents/specs) • Protocols specify: • Architecture • Encapsulating Security Payload (ESP) • Authentication Header (AH) • Encryption Algorithm • Authentication Algorithm • Key Management • Domain of Interpretation

  10. IPSec Services • Services at the IP Layer • Selecting protocols, algorithms, crypto-keys • Important security protocols: ESP and AH • ESP and AH services: • Access control • Connectionless integrity • Data origin authentication • Rejection of replayed packets • Confidentiality (cipher text) • Confidentiality with limited cipher text

  11. IPSec Services

  12. Security Associations • Very important concept (used throughout) • Association: one-way relationship between sender and receiver • Provides security on traffic between it • Can use two Security Associations (SA’s) for two way communication • Services provided to AH, ESP, but not both simultaneously (but can be combined, as seen later) • SA uniquely identified by three parameters: Security Parameters Index (SPI), IP Destination Address, Security Protocol Identifier

  13. SA Parameters • An SA must carry with it a number of important values • Sequence Number Counter • Sequence Counter Overflow • Anti-replay window • AH, ESP Information • Lifetime of the SA • Protocol mode (Tunnel/Transport, see in a moment) • MTU: Maximum transmission unit

  14. SA Selectors • IPSec: Flexibility on application of services to traffic • How to relate IP traffic to an SA? • Security Policy Database: • Simple idea: Table to relate subset of IP traffic to a specific SA • Becomes very complex (many to many relationship) • An entry: IP and upper-layer protocol field values • Known as selectors (filter outgoing traffic to SA) • Outgoing traffic: 1) compares fields of packet against SPD, finds match. 2) Determine the SA (if exists) 3) Do IPSec (AH ESP)

  15. SPD Entry • What does an SPD entry look like? • Destination IP Address – Single or Range (mask) • Source IP Address • UserID • Data Sensitivity Level • Transport Layer Protocol • Source and Destination Ports

  16. Transport and Tunnel Mode • Another important concept reused: • Transport mode: Protection of packet payload • Tunnel mode: Protection of entire packet • Transport mode used in end to end communication between hosts. • ESP: encrypts (+ authenticate) payload, not header • AH: Authenticates payload, selected header bits • Tunnel mode: new routing info added • ESP: encrypts (+ authenticate) packet(not outer header) • AH: authenticates entire packet, selected outer bits

  17. Authentication Header • Adds data integrity and authentication to IP packets • Integrity: avoid alteration of packets • Authentication: filter traffic correctly • Prevent spoof attacks and replay attacks • Uses a message authentication code (MAC) • Required shared secret key • Uses the following fields: • Next Header, Payload Length • Reserved, SPI • Sequence Number, Authentication Data

  18. Authentication Header

  19. Preventing Replays • Attacker grabs authentic packet, transmits later • Sequence Number tries to prevent this • Sequence Number is generated by sender for a new SA • Starts and 0 and increments to 232 – 1 • Incremented for each new packet, thus first value, 1 • Cannot be allowed to cycle. Passing limit must negotiate NEW SA with a NEW secret key • Since IP does not guarantee packet delivery order (or at all for that matter), the receiver uses the familiar sliding window concept for data transmission.

  20. Integrity Check Value • ICV value in the Authentication Data • Authentication code from a MAC algorithm • Can use HMAC-MD5-96 or HMAC-SHA-1-96 • Calculation of the MAC code: • Includes immutable fields and predictable fields • Other fields set to 0 • Authentication Data field = 0 • Includes all additional protocol information (TCP/IP), which should be immutable • Recalculated and destination

  21. Transport and Tunnel Modes

  22. Encapsulating Security Payload • Confidentiality services • ESP can optionally provide authentication • Parameters in an ESP Packet: • Security Parameters Index • Sequence Number • Payload Data • Padding • Pad Length • Next Header • Authentication Data (e.g. ICV value)

  23. Encapsulating Security Payload

  24. Encryption and Decryption • Uses any number symmetric encryption algorithms • Three-key DES • RC5 • Blowfish • More • Specified by the DOI • Padding: • Padding can indicate cipher text length, make plain text long enough • Used to align fields • Conceal actual payload length

  25. Transport and Tunnel Modes • Transport Mode • IP Header removed. Payload (including TCP header) encrypted/replaced by cipher text • Header attached/sent to destination • Destination detaches and decrypts payload • Tunnel Mode • Entire packet is encrypted • New IP Header added to cipher text and routed • Decrypts the packet at destination • Secondary header used for final routing

  26. Combining Security Associates/Keys • Can combine security associates (4 cases) • IPSec requires management of secret keys • Two types of key management: auto and manual • Oakley Key Determination Protocol (like Diffie-Hellman, but more secure) • Cookies against clog attacks • nonces to prevent replays • authenticate against man in the middle • Internet Security Association and Key Management Protocol (allows various key exchange algorithms)

  27. Web SecurityChapter 17

  28. Web Security Introduction • Need for security on the Transport Control Protocol (TCP) Layer • Uses Secure Socket Layer (SSL) and Internet standard SSL called Transport Layer Service • Allows TCP users to indentify security mechanisms • Particularly concerted with E – commerce security: Secure Electronic Transaction (SET)

  29. Web Security Considerations • Room for nearly all levels of security in the Web • E.g. previous considerations • Nevertheless: Web presents unique challenges • All communication two way thus doubling the opportunity for attack • Web integrated into business: high losses if security compromised • Security flaws in complex software • Web Servers may provide access to local intranet • Users not aware of security risks

  30. Threats Classifications

  31. Web Security Approaches • Different ways of implementing security • Similar in services and (to an extent) mechanisms • Differ with respect to scope and location with TCP/IP stack • Simple security: Use IP Security! IPSec runs over TCP • Another solution: Run security just above TCP, below IP • Basis of SSL and TLS • Choice: Make SSL/TLS transparent or integrate into applications? (advantage: tailored to needs, disadvantage: complexity)

  32. SSL and TLS • Current version is SSL v3. TLS is essentially SSLv3.1 • Not a “successor” exactly, just a different standard • SSL Architecture • Make TCP reliable/secure • Higher level protocols operate (HTTP for instance) on SSL • SSL uses three protocols: Handshake Protocol, Change Cipher Spec Protocol, Alter Protocol • Also a special “record” protocol • Used in management of SSL exchanges

  33. SSL Architecture

  34. SSL Session and Connection • Connection: A transport (recall OSI layers) providing suitable service types. Here, these are peer-to-peer connections and are transient (short lived). That is, connections associated with one session. • Session: An association between client and a server. The Handshake protocol initiates sessions, which define cryptographic parameters. The parameters may be shared: in fact we use sessions to avoid negotiation of new security parameters for each connection (expensive)

  35. Session and Connection States • Session state has following parameters • Session Identifier, Peer certificate (X509, etc) • Compression Method • Cipher spec (data encryption) and hash • Master secret • Is resumable? • Connection state: • Server and client randomness • Keys: Server/Client MAC, Server/Client Write • Initialization vectors • Sequence numbers

  36. SSL Record Protocol • SSL Record protocol provides two services: • Confidentiality • Using symmetric encryption with a shared secret key defined by Handshake Protocol • AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 • Message is compressed before encryption • Message integrity • Using a MAC with shared secret key • Similar to HMAC but with different padding • Concerns itself with: fragmentation, compression, authentication (MAC), encryption, header

  37. SSL Record Appearance

  38. Handshake Protocol • Allows server & client to: • Authenticate each other • To negotiate encryption & MAC algorithms • To negotiate cryptographic keys to be used • Comprises a series of messages in phases • Establish Security Capabilities • Server Authentication and Key Exchange • Client Authentication and Key Exchange • Finish

  39. Handshake Protocol

  40. SSL Change Cipher Spec Protocol • One of 3 SSL specific protocols which use the SSL Record protocol • A single message • Causes pending state to become current • Hence updating the cipher suite in use

  41. SSL Alert Protocol • Conveys SSL-related alerts to peer entity • Severity • Warning or fatal • Specific Alert • Fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter • Warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown • Compressed & encrypted like all SSL data

  42. Transport Layer Security • As stated, standard similar to SSL • Some differences: • Un record format version number • Uses HMAC for MAC • A pseudo-random function expands secrets • Has additional alert codes • Some changes in supported ciphers • Changes in certificate types & negotiations • Changes in crypto computations & padding

  43. Secure Electronic Transactions • Open encryption & security specification • To protect Internet credit card transactions • Developed in 1996 by Mastercard, Visa etc • Not a payment system • Rather a set of security protocols & formats • Secure communications amongst parties • Trust from use of X.509v3 certificates • Privacy by restricted info to those who need it

  44. SET Components

  45. SET Transaction • Customer opens account • Customer receives a certificate • Merchants have their own certificates • Customer places an order • Merchant is verified • Order and payment are sent • Merchant requests payment authorization • Merchant confirms order • Merchant provides goods or service • Merchant requests payment

  46. Purchase Request • SET purchase request exchange consists of four messages • Initiate Request - get certificates • Initiate Response - signed response • Purchase Request - of OI & PI • Purchase Response - ack order

  47. Payment Gateway Authorization • Verifies all certificates • Decrypts digital envelope of authorization block to obtain symmetric key & then decrypts authorization block • Verifies merchant's signature on authorization block • Decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment block • Verifies dual signature on payment block • Verifies that transaction ID received from merchant matches that in PI received (indirectly) from customer • Requests & receives an authorization from issuer • Sends authorization response back to merchant

  48. Payment Capture • Merchant sends payment gateway a payment capture request • Gateway checks request • Then causes funds to be transferred to merchants account • Notifies merchant using capture response

More Related