1 / 76

Chapter 10: Network Security Topics Overview Specific Protocols/Products

Chapter 10: Network Security Topics Overview Specific Protocols/Products 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).

ova
Download Presentation

Chapter 10: Network Security Topics Overview Specific Protocols/Products

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. Chapter 10: Network Security • Topics • Overview • Specific Protocols/Products • 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) (also called IP tunneling). • Data Link Layer Security (hardware/link encryption) Chapter 10 Network & Applications Security

  2. Placement of the Security Function There are two prominent approaches to network security: Data Link Layer (DLL) security End-to-End security DLL security protects messages independently on each link of a network. End-to-end security protects messages all the way from the source to the destination. There are some variations – for example, end-to-end may mean from a remote computer to a gateway (e.g., a firewall) or firewall-to-firewall). In the later case, 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 & Applications Security

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

  4. Data Link Layer Encryption Source Destination Connection points (telephone office) Links Links might be telephone lines, fiber cable, microwave, satellite, etc. Each 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 message and protocol headers are typically encrypted. Used in connection-oriented traffic where there is no intermediate processing (e.g., no routing). Examples: Secure telephones, wireless network radio link (802.11), satellite pay television. Chapter 10 Network & Applications Security

  5. Data Link Layer Encryption Since entire message and headers are protected – no traffic analysis. Keys are imbedded in devices - requires key change method. Intermediate nodes must be secure since messages are decrypted and encrypted at each node. An adversary controlling a node can read all the traffic. In nodes subjected to high volumes of traffic, cryptographic operation reduce maximum throughput. In a complex network, 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 routed public networks. Chapter 10 Network & Applications Security

  6. End-to-End Encryption The intent of end-to-end securityis to protect messages over the entire path from source to destination. In addition, to ensure that any compromiseof an intermediate node does not compromise the message. End-to-end may mean different end points such as: Source to destination host or process-to-process on end hosts. Firewall-to-firewall leaving firewall to end-host path unprotected. Better suited for use in routed networks with a mix of protected and unprotected traffic than DLL protection. Wider range of protection methods at different protocol layers. Chapter 10 Network & Applications Security

  7. Security & The Layered Model Security can be applied at any layer in the network layered model: Type Layer Typical Application Application proxies Application PGP, PEM (mail) n/a Presentation n/a Session proxies Session SSL, SOCKS Session proxies Transport TLS, Kerberos Packet filters Network IPSec Packet filters Data Link PPTP, L2TP Packet filters Physical Hardware Encryption Lower layers are more generalized, protect all layers above. Higher layers are more specialized, don’t protect lower layers. Chapter 10 Network & Applications Security

  8. Security - Placement of the Function All placements can use the same (conceptually) underlying mechanisms of authentication, integrity, and confidentiality The scope of coverage is significantly different depending on the layer the security functionality is placed in - by scope we mean what is protected. For example, if we encrypt at the physical layer by adding a crypto box between the computer and transmission line, 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 & Applications Security

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

  10. 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 & Applications Security

  11. Secure Sockets Layer (SSL) Open systems protocol, developed by Netscape Communications and offered to the Internet Engineering Task Force (IETFI. In IETF terms, it is known as Transport Layer Security (TLS). Uses TCP as the transport protocol. Primary purpose is to conduct secure internet transaction (e-commerce). Uses public key cryptography to provide 4 basic services: 1. Secret key Exchange ------ Public key encryption & Diffie-Hellman 2. Message privacy ------------ Secret key encryption 3. Message integrity ----------- RSA digital signature 4. Mutual 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 & Applications Security

  12. 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 & Applications Security

  13. Secure Sockets Layer (SSL) - Web Commerce Chapter 10 Network & Applications Security

  14. Secure Sockets Layer (SSL) 1. Browser access web site, users 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 certificate as un-expired and valid for the merchant. 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, except that 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 & Applications Security

  15. Secure Sockets Layer (SSL) SSL is capable of supporting 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. SSL uses the private key and message digest to ensure message and authentication of source. Confidentiality is provided by secret key exchange with the secret key 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 & Applications Security

  16. Secure Sockets Layer - Why Diffie-Hellman is Supported 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 & Applications Security

  17. SSL Applications Example given was web access to support, for example, electronic commerce. SSL can be used for many applications. The generic architecture of SSL 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 & Applications Security

  18. 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 & Applications Security

  19. SSL Handshake Protocol A. Agree on 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 & Applications Security

  20. 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 & Applications Security

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

  22. 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 (when one side decides to close, then an attacker attempts to continue with the other side). Chapter 10 Network & Applications Security

  23. 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 the user 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 and proxies all traffic while reading everything That goes by including passwords, credit card numbers, etc. Chapter 10 Network & Applications Security

  24. 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. Chapter 10 Network & Applications Security

  25. Secure Electronic Transactions (SET) SET is a protocol develop for Mastercard & Visa to provide very secure e-commerce transactions. Joint specification development with participants including; IBM, Microsoft, Netscape, RSA Data Security, Terisa, and VeriSign, circa 1996 (a 900+ page document). SET is a set of protocols and data formats intended to operate over the Internet, interface with the existing “payment” network while providing all the encryption functionality of SSL plus several important additional features. 1. Users and merchants both hold certificates. 2. User 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 & Applications Security

  26. Secure Electronic Transactions (SET) Chapter 10 Network & Applications Security

  27. Secure Electronic Transactions (SET) - The Players 1. Two networks - The public Internet, a private payment network. 2. Cardholder - individual authorized by a financial institution (the card issuer) to make transactions using the card. 3. Merchant - willing to accept the card as payment and is authorized by the acquirer and/or financial institution to accept credit card transactions. 4. Issuer - the financial institution that issues the card. 5. Acquirer - usually a financial institution or subsidiary that establishes merchant accounts (i.e., the merchant’s bank) and processes transaction authorizations and payments. 6. Payment gateway - System operated for/by acquirer to process merchant payment notices and pass them to the appropriate issuer. 7. Certificate Authority - issues X.509 certificates for merchants, card holders, payment gateways, and issuers systems. This is a complex infrastructure! Chapter 10 Network & Applications Security

  28. Secure Electronic Transactions (SET) - Requirements Card Issuer/Acquirer Proof that the transaction was authorized by the card holder Proof that the transaction was authorized by the merchant Merchant Proof the the transaction was authorized by the acquirer Proof that the transaction was authorized by the card holder Card Holder Proof the transaction was authorized by the acquirer Proof the merchant is 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) Everyone is interested in ensuring unauthorized payments are impossible Chapter 10 Network & Applications Security

  29. SET Transactions - Five Major Elements 1. Setup - install software and enroll. Card issuers sets 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 & Applications Security

  30. 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 the dual signature. Chapter 10 Network & Applications Security

  31. 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 provides for 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 & Applications Security

  32. Dual Signature - Functional Generation Chapter 10 Network & Applications Security

  33. Dual Signature - What it Does Provides the customers 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 (continuing from our earlier step 3): Initiate Purchase Initiate Response Purchase Request Purchase Response Chapter 10 Network & Applications Security

  34. Completing the Purchase Customer sends an “Initiate Request” message to the merchant. Requests the merchant’s certificate and the certificate of the payment gateway used by the merchant. It also contains the brand of the credit card, a message identifier, and a time stamp nonce. Merchant prepares an “Initiate Response” message to the customer. A clear text part contains the merchants X.509 certificate and certificate of the merchant’s payment gateway. The merchant signs a response containing the customer’s nonce, another nonce generated by the merchant, and a transaction identifier (a unique order number). The customer verifies the certificates with the CA and is now confident in the identity of the merchant and the payment server. Chapter 10 Network & Applications Security

  35. Completing the Purchase (contd) 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 (#, expiration date). 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). And is now ready to complete the transaction. This is done by creating a “Purchase Request”. Chapter 10 Network & Applications Security

  36. Purchase Request Message Chapter 10 Network & Applications Security

  37. 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 shown as the envelope). This denies the merchant access to the customer’s payment information (credit card information). This information and PIMD, OI, the dual signature, and the customer’s X.509 certificate are sent back to the merchant. Chapter 10 Network & Applications Security

  38. Merchant Information - From the Customer Encrypted PI Payment Information encrypted with a DES key, unreadable b the merchant Envelope DES Key encrypted with Payment server’s public key 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 & Applications Security

  39. 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 with the unique order number, signed by the merchant that cannot be repudiated by the merchant. The customer can validate this message. Chapter 10 Network & Applications Security

  40. Merchant Information - From Customer - Graphically Encrypted PI Merchant can’t use - encrypted with DES key Envelope PIMD POMD OI Hash OIMD COMPARE Decrypt Dual Sig. POMD X.509 Customer’s Public Key Chapter 10 Network & Applications Security

  41. Payment Information - From the Merchant to Payment Gateway Encrypted PI When decrypted includes the PI, dual signature, and OIMD Contains 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 # 1 DES session key 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 & Applications Security

  42. Payment Gateway Actions 1. Verifies customer & Merchant certificates. 2. Decrypts the digital envelope for the transaction identifier to get the symmetric key and decrypts the transaction identifier. 3. Verifies the merchant’s digital signature on the transaction identifier. 4. Decrypts the symmetric key on the purchase information to get the symmetric key and decrypts the purchase information. 5. Verifies the dual signature contained with the purchase information. 6. Verifies that the transaction identifier supplied by the merchant (2 above) matches the transaction identifier supplied by the customer (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 & Applications Security

  43. Authorization Response - Information to the Merchant 1. Authorization Information - an authorization block, signed with the payment gateways private key and encrypted with a symmetric 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 symmetric 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 gateways signature key certificate. Chapter 10 Network & Applications Security

  44. Authorization Response - Graphically Symmetric Key Authorization Information Authorization Information This information is sent to the merchant. 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 & Applications Security

  45. Payment Capture - Capture Request ($ to the Merchant) 1. 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 & Applications Security

  46. 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 witheld from financial institutions. 4. Integrity through the use of Digital Signatures. 5. Authentication of card holder with Digital Signatures & certificates. 6. Authentication of merchant’s identity and authority to accept credit card purchases from the card holder. 7. Can operate “over” or “on top of” other security protocol at lower layers in the IP stack. Chapter 10 Network & Applications Security

  47. SET Status SET is not being widely embraced or implemented SET is technically elegant, but practically difficult Big problem is speed - 30-60 seconds for transaction processing Protocol is code heavy in first release Resistance on the part of merchants - SSL is simpler, easier Some early supporters have abandoned SET in favor of SSL Chapter 10 Network & Applications Security

  48. Transport Layer Security Essentially an IETF standards version of SSL. Current SSL version is 3.0, TLS 1.0 is effectively SSL version 3.1 Few differences compared to SSL, but are enough that TLS 1.0 & SSL 3.0 are not interoperable Version numbers are different MAC algorithm is different TLS has more alert codes Does not support Fortezza token encryption Padding is different Differences are not in concepts, but in: 1. Not shimmed, but a part of the TCP layer. 2. The fact it is an open standard with the forces of the IETF. Chapter 10 Network & Applications Security

  49. Transport Layer Security Defines standard ports assigned by IANA for specific services. All use TCP as the transport protocol. Some of the ports are: Keyword Port Description https 433 http protocol over TLS/SSL sshell 614 secure shell over SSL ldaps 636 ldap protocol over TLS/SSL ftps - data 989 ftp protocol - data over TLS/SSL ftps 990 ftp protocol - control over TLS/SSL telnets 992 telenet protocol over TLS/SSL pop3s 995 pop3 protocol over TLS/SSL NOTE: Like all port, a pair of systems can negotiate any port pair for these services - these are the assigned default ports. Chapter 10 Network & Applications Security

  50. Internet Protocol Security - IPSec A suite of protocols & documents providing security services at the network layer. RFC 2401 Architecture RFC 2406 RFC 2402 Encapsulating Security Payload Protocol Authentication Header Encryption Algorithm(s) Authentication Algorithm(s) RFC 2405 RFC 2407 RFC 2104 Domain of Interpretation Key Management RFC 2409 Chapter 10 Network & Applications Security

More Related