Chapter 10: Network Security Topics Placement of the security function.

1. Chapter 10: Network Security • Topics • Placement of the security function. • Security & the layered model. • Secure Sockets Layer (SSL). • Secure Electronic Transactions (SET). • Transport Layer Security (TLS). • Internet Protocol (IP) security (IPSec). • Virtual Private Networks (VPN) (IP tunneling). • Data Link Layer Security (hardware/link • encryption) Chapter 10 Network Security

2. Placement of the Security Function Prominent approaches: Data Link Layer (DLL) security End-to-End security DLL security protects messages independently on each link of a network. End-to-end is from the source to the destination. Variations – end-to-end may mean from a computer to a gateway (e.g., a firewall) or from firewall-to-firewall). Traffic is protected between the firewall, but is not protected between the firewall and the end computer (e.g., on the LAN behind each firewall). Chapter 10 Network Security

3. Placement of the Encryption Function Data Link – not Protected in routers or other intermediate systems Protected Application Application Transport Transport Network Network Data Link Data Link End-to-End – Protected in routers and other intermediate systems Application Application Transport Transport Network Network Data Link Data Link Protected Chapter 10 Network Security

4. Data Link Layer Encryption Source Destination Connection points (e.g., telephone office) Links Links: phone lines, fiber cable, microwave, satellite, etc. The link is encrypted. Often, different keys are used on each link so subversion of one link does not affect all links. Stream ciphers are typically used and entire messages and headers are encrypted. Used in connection-oriented traffic (no intermediate processing, like routing). Chapter 10 Network Security

5. Data Link Layer Encryption Examples: Secure telephones, wireless network radio link (802.11), satellite pay television. Message and headers are protected – no traffic analysis. Keys are imbedded in devices - requires key change. Intermediate nodes must be secure since messages are decrypted and encrypted at each node. An adversary controlling a node can read unencrypted traffic. . Chapter 10 Network Security

6. Data Link Layer Encryption In nodes subjected to high volumes of traffic, cryptographic operations reduce maximum throughput. In a complex networks, the end user does not have control of the nodes and must trust an intermediary. Used in connection-oriented networks (telephone system), private networks, on single links (e.g., wireless). Not used in routed public networks. Chapter 10 Network Security

7. End-to-End Encryption The intent of end-to-end security is to protect messages over the entire path from source to destination. Ensures that any compromise of an intermediate node does not compromise the message. However, always remember that the clear text exists at the two ends points. A compromise their give clear text access to the adversary Can be implemented with a wide range of protection methods at different protocol layers. Chapter 10 Network Security

8. Gateway to Gateway Encryption A variation on end-to-end where end point may be: Firewall-to-firewall leaving firewall to end-host path Unprotected at both ends (clear text is available on the Internal network). Well suited for use in routed networks with a mix of protected and unprotected traffic. Protocols exist that can be applied at any layer in the Layered network model. Chapter 10 Network Security

9. Security & The Layered Model TypeLayerTypical Application Application proxies Application PGP, PEM (mail) Session proxies Transport SSL, TLS, Kerberos Packet filters Network IPSec Packet filters Data Link PPTP, L2TP Packet filters Physical hardware Lower layers are more generalized, encrypt data at all layers above. Higher layers protect above, but do not protect data added by lower layers (header data). Chapter 10 Network Security

10. Security - Placement of the Function All placements can use the same underlying mechanisms for authentication, integrity, and confidentiality. What is protected is different depending on the layer the security functionality is placed in. For example: Encrypting at the physical layer means everything is encrypted - also means we must: 1. Have a dedicated line with no intermediate routing 2. Have exactly the same equipment at the far end. Chapter 10 Network Security

11. Major Placements of the Security Function PGP Scope Application Application TLS Scope Transport Transport Network Network Application Application SSL Scope Scope IPSec Session Layer Transport Transport Network Network Application - Unique to each application, PGP, S/MIME. SSL - Multiple applications, but is shimmed between application and TCP (API per application). TLS - Same as SSL, except integrated into TCP stack. IPSec, most generic, protects everything encapsulated by IP. Chapter 10 Network Security

12. Security - Generalized Model Information Exchange Establishes connections, negotiates Algorithms. Manages keys, key exchanges. Authenticates users, systems, and/or Messages. Encrypts authenticators and/or Payloads. Key Management Authentication Encryption Chapter 10 Network Security

13. Secure Sockets Layer (SSL) Open system protocol, developed by Netscape Communications and embedded in the Netscape browser. Offered to the Internet Engineering Task Force (IETF) for consideration as an Internet standard. IETF made minor changes, called is Transport Layer Security (TLS) and adopted it. Now appears in all Browsers. Uses TCP for transport. Main use is to conduct secure Internet transactions (e-commerce). Chapter 10 Network Security

14. Secure Sockets Layer (SSL) • Uses public key cryptography to provide 4 basic services: • Secret key Exchange ------ Public key encryption & • Diffie-Hellman exchange • 2. Message privacy ------------ Secret key encryption • 3. Message integrity ----------- RSA digital signature • 4. Authentication -------------- X.509 certificates and • digital signature • Provides security at the session/application layer and • is used for many applications, including for web • commerce transactions. Chapter 10 Network Security

15. SSL - Fit in Layered Architecture Normal CommunicationsSSL Communications Application Application SSL I/O Calls I/O Calls SSL WinSock I/O Calls TCP Calls WinSock TCP TCP Calls TCP To Network To Network Chapter 10 Network Security

16. Secure Sockets Layer (SSL) - Web Commerce Chapter 10 Network Security

17. Secure Sockets Layer (SSL) 1.User accesses web site, fills shopping cart, goes to checkout. 2. The server sends a copy of the server's X.509 certificate. The certificate identifies the CA certifying the certificate. 3. The user's browser contacts the specified CA and requests certification. The CA sends a CA signed copy of the certificate to the user certifying the merchant certificate as un-expired and valid. 4. The browser encrypts a session key with the server's public key. 5. The server prompts the browser for a transaction. The browser sends its ID and credit card number encrypted with the session key. 6. The server decrypts the credit card number, validates it from the issuing bank, and completes the transaction. Notice that only the server has been authenticated. The user has not. However, the user's credit card has been validated for the purchase. There is no identity assurance between the user and the card. Chapter 10 Network Security

18. Secure Sockets Layer (SSL) SSL can support all the services available using Public Key Infrastructure (PKI). All transmissions between an SSL-enabled client and server can be encrypted using algorithms negotiated during SSL set-up. The private key and message digest ensures message and authentication of source. Confidentiality is provided by secret key exchange; the secret key is encrypted with the public key of the user and authenticated by private key encryption of the encrypted secret key digest. Mutual authentication is supported, but that requires the client (user) to hold a CA registered certificate. This is not common, but is supported by the basic technology of SSL. Chapter 10 Network Security

19. Secure Sockets Layer - Why Diffie-Hellman? Diffie-Hellman is a method of secret key exchange that does not require the use of certificates. Instead, a shared secret is developed using public keys and nonces. Diffie-Hellman can also be used with signing only keys. Finally, the patents on Diffie-Hellman expired in 1997 so it is now a public domain algorithm freely usable by anyone. Chapter 10 Network Security

20. SSL Applications Previous example was web access to support electronic commerce. SSL can be used for many applications. SSL architecture is: Handshake Change Cipher Alert SSL Record Protocol TCP IP Top part of SSL at the application layer provides 3 different functions, all using a common underlying record structure. SSL uses standard TCP for reliable transport. Chapter 10 Network Security

21. SSL Protocols Handshake - Establishes connection, initial authentication, negotiates cipher suite & keys. Change cipher - Used to re-negotiate ciphers and/or keys at any time during a session. Alert - Sends warning messages regarding any potential problems (e.g., no certificate, out-dated certificate, etc.) & used to terminate a session. Record - Main protocol used during actual exchange of information between the client and server. Chapter 10 Network Security

22. SSL Handshake Protocol A. Agree on SSL protocol version (version 3 is current) B. Agree on crypto algorithms (encryption, MAC, compression) C. Optionally authenticate each other (exchange certificates) D. Use public keys to generate a shared secret key. 1. Establish security capabilities (id SSL version, nonces, session id, algorithms, compression method). Is a negotiated agreement. 2. Server authentication and key exchange. 3. Client authentication and key exchange. If no certificate is available for client authentication, an ALERT message is sent. 4. Finish - completes the secure connection At end, two shared secret keys have been negotiated, one for encryption and one for a encrypting the message authentication code (MAC). Chapter 10 Network Security

23. SSL - Cipher Suites Supported The following suites are supported: IDEA, 128 bit key, block cipher RC2, 40 bit key, block cipher DES, 40 bit key, block cipher DES, 56 bit key, block cipher 3DES, 168 bit key, block cipher Fortezza, 80 bit key, block cipher RC4, 40 bit key, stream cipher RC4, 128 bit key, stream cipher Weak (e.g., 40 bit) keys appear in SSL because of federal encryption export control limitations that have now been lifted. Chapter 10 Network Security

24. SSL Record Protocol The workhorse - doing the message encryption and MAC Message Fragment Compress Add MAC Encrypt Handed off to TCP for transmission Add SSL Header Chapter 10 Network Security

25. SSL Change Cipher Spec & Alert Protocols Change Cipher Spec allows for notification that a different cipher suite needs to be negotiated (this is a 1 Byte notification message) Alert Protocol is used to notify the peer of any alert such as: Decompression or handshake failure. Illegal parameters. Certificate problem; no certificate, bad certificate, expired, revoked, unknown, unsupported. Close notification (this is the last message). Close notification is an alert message requiring action to confirm the close to avoid truncation attacks (one side decides to close, and an attacker attempts to continue with the other side). Chapter 10 Network Security

26. SSL - Summary SSL is robust, and widely used, but it can be hacked – here’s how: dsniff 2.3, is a man-in-the-middle SSL hack. To work: The intruder must be in the path between a client & server, or fool theuser into connecting to the intruder instead of the intended server, or Do arp spoofing to re-direct the connection between the user and server. In each case, the result is that the intruder is inserted between the user and the real server then and proxies all traffic while reading everything that goes by including passwords, credit card numbers, etc. Chapter 10 Network Security

27. SSL Hack • Minimal risk from outsiders due to the path requirements. If arp • spoofing is used the hacker leaves tracks and must be in the path. • That leaves fooling the user. This can be avoided as follows: • Insure the site in the browser bar is the site you wanted. • Check the SSL certificate to ensure it’s the right site and that • it is from a known CA, like Verisign. • 3. Like any other security method, if the machine you are on is • root compromised, the every I/O character can be captured, • stored, and analyzed looking for usernames, passwords, • passphrases to access keys, etc. Chapter 10 Network Security

28. Secure Electronic Transactions (SET) SET is a protocol develop for Mastercard & Visa to provide very secure e-commerce transactions. Joint development with; IBM, Microsoft, Netscape, RSA Data Security, Terisa, and VeriSign, circa 1996 (a 900+ page specification document). SET is a group of protocols and data formats intended to operate over the Internet, interface with the existing “payment” network while providing the encryption functionality of SSL plus several important additional features. 1. Users and merchants both hold certificates. 2. Users register with with the cardholder service (bank). 3. One certificate per card is required. 4. Merchants also register with a cardholder service (bank). Chapter 10 Network Security

29. Secure Electronic Transactions (SET) Chapter 10 Network Security

30. SET - The Players Two networks: The public Internet, a private payment network. Cardholders: Individuals authorized by a financial institution (the card issuer) to make transactions using the issuer’s card. Merchant: Company willing to accept the card as payment and is authorized by the acquirer and/or financial institution to accept credit card transactions. Issuer: The financial institution that issues the card. Acquirer: Usually a financial institution or subsidiary that establishes merchant accounts (i.e., the merchant’s bank) and processes transaction authorizations and payments. Payment gateway: A system operated for/by acquirer to process merchant payment notices and pass them to the appropriate issuer. Certificate Authority: Issuer of X.509 certificates for merchants, card holders, payment gateways, and issuers systems. Chapter 10 Network Security

31. SET - Requirements Card Issuer/Acquirer Proof transactions were authorized by the card holder. Proof transactions were authorized by the merchant. Merchant Proof transactions were authorized by the acquirer. Proof transactions were authorized by the card holder. Card Holder Proof transactions were authorized by the acquirer. Proof merchants are authorized with the acquirer. Proof of the purchase from the merchant (a receipt). Privacy of card number (don’t disclose to merchant). Privacy of transaction (don’t disclose to bank). All Ensuring that unauthorized payments are impossible! Chapter 10 Network Security

32. SET Transactions - Five Major Elements 1. Setup - install software and enroll. Card issuers set up a Certificate Authority. Merchants enroll to use the CA & payment system. Customers enroll to use the CA & payment system. On acceptance, the CA issues X.509 certificates and the public key of the CA. The merchant also needs the public key of the payment server. Both the merchant and customer require software. 2. Browsing - shopping for purchases. Customer browses the merchant’s site and puts items in a shopping cart - completing the merchants order form. Chapter 10 Network Security

33. SET Transactions - Five Major Elements (contd) 3. Purchase request - ordering goods When the customer selects purchase, the merchant completes an order form and sends it to the customer for final confirmation. All of these actions are similar to those followed by SSL (except the one associated with enrolling the customer). From here on, the actions are different. 4. Payment authorization - confirming payment is authorized 5. Payment capture - finalizing the order & payment Before discussing them, we need to look at a capability called the dual signature. Chapter 10 Network Security

34. SET - Dual Signature Similar to Digital Signature for authentication/non-repudiation. But, with a significant difference: Uses a dual signature Binds (links) the two signatures Function: The dual signature establishes a way to separate a customer’s Order Information (OI) from the customer’s Payment Information (PI). This allows the merchant to view the OI to fulfill the order, but blocks the merchant from viewing the PI - no need, keeps the credit card information out of the hands of the merchant. Also, the banks only need to see PI, not OI. The link between signatures is necessary to settle disputes. Chapter 10 Network Security

35. Dual Signature - Functional Generation Chapter 10 Network Security

36. Dual Signature - What it Does Provides the customer’s digital signature over the entire PI and OI package of information - non-repudiation of source. Because the PI and OI are hashed - in fact hashed twice, they can be individually and collectively tested for integrity such that they cannot be tampered with after being signed - integrity of contents. This is still not enough to be able to separate the information, so we need to look at the additional processing required to complete a purchase which consists of 4 parts: Initiate Purchase Initiate Response Purchase Request Purchase Response Chapter 10 Network Security

37. Completing the Purchase Customer sends an “Initiate Request” message to the merchant. This message requests two certificates: The merchants certificate, and the certificate of the merchant’s payment gateway It also contains the brand of the credit card, a message identifier, and a time stamp nonce. Merchant responds by sending an “Initiate Response” message back to the customer. A clear text part contains the both the merchants X.509 certificate and the certificate of the merchant’s payment gateway. Chapter 10 Network Security

38. Completing the Purchase (contd) The message contains the customer’s nonce, another nonce generated by the merchant, and a transaction identifier (a unique order number) and is signed by the merchant. The customer verifies both certificates with the CA and is now confident of the identity of the merchant and the payment server. The customer now creates the Order Information (OI) and Payment Information (PI) documents. The OI only needs to include the transaction identifier supplied by the merchant. The PI only needs to contain the customers credit card information (the number and expiration date). Chapter 10 Network Security

39. Completing the Purchase (contd) So far, the customer has: 1. Verified the identity of the merchant and the payment gateway. 2. Has prepared an order form (OI). 3. Has prepared a separate payment information document (PI). These are the two documents that are input to the dual signature process depicted on an earlier slide and can create: The PIMD, and OIMD (payment and order digests). A concatenated PIMD|OIMD and its hash = POMD. A signed version of the POMD by encrypting the POMD with the user’s private key. Now the customer can create a “Purchase Request”. Chapter 10 Network Security

40. Purchase Request Message Chapter 10 Network Security

41. Purchase Request Message The PI, dual signature, and OI Message Digest (OIMD) are combined into a single message (block) and DES encrypted using a one-time symmetric key producing an encrypted PI. The DES key is encrypted using the payment gateway’s public key (this is contained in the envelope). This denies the merchant access to the customer’s payment information (credit card information) since only the gateway’s private key will open the envelope. This information and PIMD, OI, the dual signature, and the customer’s X.509 certificate are sent back to the merchant. Chapter 10 Network Security

42. Merchant Information - From the Customer Encrypted PI Payment Information encrypted with a DES key, unreadable by the merchant. DES key encrypted with Payment server’s public key. Envelope PIMD PI Message digest to ensure integrity of PI. OI Clear text Order Information. Dual Signature for non-repudiation and integrity. Dual Sig. X.509 Customer’s X.509 Certificate. Chapter 10 Network Security

43. Merchant Actions 1. Verify the customer’s certificate with the CA. 2. Using OI, create OIMD, concatenate with PIMD, hash, and verify the result against the dual signature using the customer’s public key. 3. Forward the Payment information (encrypted PI & envelope) to the payment server (and get a response back authorizing). 4. Process the order for fulfillment and notify the customer to acknowledge the order, delivery date, etc. Customer notification is called “Purchase Response” and is a message containing the unique order number, signed by the merchant that cannot be repudiated by the merchant. The customer can validate this message with the merchant’s public key. Chapter 10 Network Security

44. Merchant Information - Customer to Merchant Encrypted PI Merchant can’t use - encrypted with DES key. Envelope PIMD POMD Merchant can and does do these computations to validate the POMD (Order Information). OI Hash OIMD COMPARE Decrypt Dual Sig. POMD X.509 Customer’s Public Key Chapter 10 Network Security

45. Payment Info - Merchant to Payment Gateway Encrypted PI When decrypted includes the PI, dual signature, and OIMD. DES key to decrypt PI block above, encrypted with the payment gateway’s public key - no merchant! Envelope # 1 Customer order number, signed with Merchant’s private key, and encrypted with a DES session key (notice - no order details) Transaction Identifier Envelope # 2 DES session key to open the transaction ID, encrypted with payment gateway’s public key. Customer’s Certificate Used to verify the dual signature. Merchant’s Certificate Used to verify the merchant’s signature. Chapter 10 Network Security

46. Payment Gateway Actions 1. Verifies customer & Merchant certificates. 2. Decrypts the digital envelope for the transaction identifier to get the symmetric DES key and decrypt the transaction identifier. 3. Verifies the merchant’s digital signature on the transaction id. 4. Decrypts the symmetric key on the purchase information to get the symmetric DES key and decrypt the purchase information (card #). 5. Verifies the dual signature. 6. Verifies that the transaction identifier supplied by the merchant in 2 above matches the transaction identifier supplied by the customer and contained in the purchase information. 7. Requests and receives an authorization from the customer card issuer. Passing these tests, the payment gateway issues an “Authorization Response” message to the merchant. Chapter 10 Network Security

47. Authorization Response - Gateway to Merchant 1. Authorization Information - an authorization block, signed with the payment gateway’s private key and encrypted with a symmetric DES key generated by the gateway. 2. An envelope containing the symmetric key, encrypted with the merchant’s public key-exchange key (not his signing key). 3. Capture token - Same form as 1 & 2 above, a token signed with the payment gateway’s private key and encrypted with a DES key. 4. An envelope containing the symmetric key, encrypted with the merchant’s public key (this notifies the merchant that payment is authorized and is a token used by the merchant to actually request payment. 5. The payment gateway’s signature key certificate. Chapter 10 Network Security

48. Authorization Response - Graphically Symmetric Key Authorization Information Authorization Information This information is sent to the merchant from the payment gateway. Signature Hash Gateway’s Private Signing Key Envelope # 1 Merchant’s Public Exchange Key Capture Token Information Capture Token Symmetric Key Gateway’s Private Signing Key Signature Hash Merchant’s Public Exchange Key Gateway’s Certificate Envelope # 2 Chapter 10 Network Security

49. Payment Capture - $ to the Merchant • The merchant generates, signs, and encrypts a capture request • block containing: payment amount and transaction identifier, the • capture token issued by the payment gateway, plus the merchant’s • signature and key exchange certificates. • 2. The payment gateways verifies the information and creates a • clearing request that goes to the customers card issuer (bank). • This cause funds to be transferred to the merchant’s bank. All of • this goes over the payment network. • 3. The gateway then notifies the merchant via a Capture Response, • encrypted and signed, that the payment has been authorized. The • merchant uses this information to reconcile payment when it • arrives. Chapter 10 Network Security

50. Summary - SET Characteristics 1. Application layer protocol 2. Does not support choice in cryptographic algorithms: DES for confidentiality RSA Digital Signature (signing & key exchange) SHA-1 Hash X.509, V 3 Certificates 3. Confidentiality & privacy of payment & ordering information – from third parties, payment information is withheld from merchants, order information is withheld from financial institutions. 4. Integrity through the use of Digital Signatures. 5. Authentication of card holder and merchants with Digital Signatures, certificates, and a registration process. 6. Can operate “over” or “on top of” other security protocols at lower layers in the IP stack (e.g., IPSec). Chapter 10 Network Security