1 / 102

CSE 331: Introduction to Networks and Security

Learn about SSL protocol, its features like server authentication, client authentication, integrity checksum, confidentiality, and its importance in e-commerce. Understand the SSL handshake protocol, key exchange, bulk encryption, and MAC calculation. Explore SSL key exchange protocols and bulk encryption protocols. Gain insights into the SSL handshake protocol phases and the messages exchanged between the client and the server.

bmarie
Download Presentation

CSE 331: Introduction to Networks and 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. CSE 331: Introduction to Networks and Security Slide Set 7 Fall 2000 Instructor: Carl A. Gunter

  2. Secure Socket Layer (SSL) • Session protocol with: • Server authentication. • Client authentication optional. • Integrity checksum. • Confidentiality. • Possibly the most important security-related ecommerce protocol. • Connection sets up security parameters. • Many sessions possible within a given connection.

  3. Network Layer Security HTTP FTP SMTP TCP IP/IPSec

  4. Transport Layer Security HTTP FTP SMTP SSL or TLS TCP IP

  5. Application Layer Security PGP SET S/MIME Kerberos SMTP HTTP TCP UDP IP

  6. SSL Protocol Stack Change Cipher Spec Alert HTTP Handshake SSL Record Protocol TCP IP

  7. Content Type Major Version Minor Version Length SSL Record Payload

  8. Content Types • Handshake • Change Cipher Spec • Alert • Opaque Content 1 byte 3 bytes  0 bytes Type Length Content 1 byte 1 1 byte 1 byte Level Alert  1 bytes Higher-Level Protocol Content

  9. Creating Opaque Content • Begin with application data. • Fragment it into blocks of 2**14 bytes or less. • Optionally compress the fragments. • Add a message authentication code (MAC) to the compressed data to ensure integrity. • Encrypt the data to ensure confidentiality. • Add SSL record header (4 fields).

  10. What Is Needed? • Negotiation of cryptographic protocols. • Initial authentication. • Key exchange to set up: • Bulk encryption. • MAC.

  11. How is this Done? • The handshake protocol negotiates the protocols to be used for authentication and bulk encryption. • The handshake protocol carries out initial authentication. • The handshake protocol establishes a 48 byte pre-master secret. • Client and server use this to derive a 48 byte master secret. • The master secret is used to generate a key block of sufficient length to supply all needed cryptographic parameters.

  12. MAC Calculation • A MAC write secret, MACWS, is extracted from the key block. • A hash function H is selected: either MD5 or SSH. • The MAC is defined as follows. H( MACWS || pad2 || H( MACWS || pad1 || seq_no || SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment ))

  13. SSL Key Exchange Protocols • RSA • Fixed Diffie-Hellman • Ephemeral Diffie-Hellman • Anonymous Diffie-Hellman • Fortezza

  14. SSL Bulk Encryption Protocols Protocol (type, key length) • IDEA (block, 128) • RC2-40 (block, 40) • DES-40 (block, 40) • DES (block, 56) • 3DES (block, 168) • Fortezza (block, 80) • RC4-40 (stream, 40) • RC4-128 (stream, 128)

  15. SSL Handshake Protocol Phases • Establish Security Capabilities • Server Authentication and Key Exchange • Client Authentication and Key Exchange • Finish

  16. Establish Security Capabilities Client Server Client Hello Time Server Hello

  17. Client Hello • Highest version number understood by client. • 32-bit timestamp and 28-bit nonce. • Session identifier. • Nonzero value: update parameters of existing connection. • Zero value: new connection and session. • CipherSuite list in order of preference. A CipherSuite identifies a key exchange protocol and other parameters. • List of compression methods.

  18. CipherSuite • BulkCipherAlgorithm (as given earlier). • MACAlgorithm (SHA-1 or MD5). • CipherType (stream or block). • IsExportable (true or false). • HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes.

  19. Server Hello • Highest version number supplied by client and acceptable to server. • Time and nonce from server (independent of same from client). • Session identifier. • If non-zero from client then same value from server. • Otherwise proposed by server. • First cipher suite proposed by client and supported by server. • First compression method proposed by client and supported by server.

  20. Server Key Exchange Server Hello Done Certificate Request Certificate Server Auth & Key Exchange Client Server Time Optional

  21. Certificate • List of x.509 certificates. • Required for all protocols except anonymous Diffie-Hellman.

  22. Server Key Exchange • Protocol-dependent keying material. • Needed for all except RSA and fixed Diffie-Hellman. • Example: in anonymous Diffie-Hellman this message consists of a prime number, a primitive root for it, and the Diffie-Hellman public key for the server.

  23. Certificate Request • Requests a certificate type (e.g. DSS for ephemeral Diffie-Hellman). • Specifies a list of certificate authorities.

  24. Server Done • Indicates that all messages in the server authentication phase have been sent and server is now awaiting a client response.

  25. Client Auth & Key Exchange Client Server Time Certificate Client Key Exchange Optional Certificate Request Optional

  26. Certificate • Client sends an X.509 certificate as requested by server or sends a No Certificate Alert.

  27. Client Key Exchange • Protocol-dependent keying material. • Example: In RSA the client generates a 48 byte secret and encrypts it using the public key of the server (from the Server Key Exchange message).

  28. Certificate Verification • Contains explicit verification of client certificate. • Client signs the hash of a concatenation of the master secret and handshake messages.

  29. Client Auth & Key Exchange Client Server Change Cipher Spec Time Finish Change Cipher Spec Finish

  30. Client and Server • The Change CipherSpec message causes the CipherSpec to become active. This is not a handshake record, but a record in the Change CipherSpec protocol. • Each party sends the Finished message under the new CipherSpec. • The message contains hashes using MD5 and SHA-1 containing the master secret and the handshake messages.

  31. Master Secret • The Master Secret is computed from the Pre-Master Secret as follows: MasterSecret = MD5( PreMasterSecret || SHA(“A” || PreMasterSecret || ClientHello.random || ServerHello.random)) || MD5( PreMasterSecret || SHA(“BB” || PreMasterSecret || ClientHello.random || ServerHello.random)) || MD5( PreMasterSecret || SHA(“CCC” || PreMasterSecret || ClientHello.random || ServerHello.random))

  32. Cryptographic Parameters • The remaining cryptographic parameters are computed by iterating the following pattern. KeyBlock = MD5( MasterSecret || SHA(“A” || MasterSecret || ClientHello.random || ServerHello.random)) || MD5( MasterSecret || SHA(“BB” || MasterSecret || ClientHello.random || ServerHello.random)) || MD5( MasterSecret || SHA(“CCC” || MasterSecret || ClientHello.random || ServerHello.random)) ||

  33. Cryptographic Parameters • Client write MAC secret. • Server write MAC secret. • Client write key. • Server write key. • Client write IV. • Server write IV.

  34. Alerts • Unexpected message. • Bad MAC. • Decompression failure. • Handshake failure, unable to negotiate an acceptable set of security protocols. • Illegal parameter in handshake message. • Close notify.

  35. Alerts, Continued • No certificate. • Bad certificate. • Unsupported certificate. • Certificate revoked. • Certificate expired. • Certificate unknown: an unspecified issue arose in certificate verification.

  36. Electronic Commerce • Electronic data interchange. • Some illustrative scenarios. • Tools supporting ecommerce. • Public key infrastructure.

  37. EDI • Electronic data interchange (EDI) is a format for computer-to-computer business exchanges like: • Purchase orders, • Invoices, • Payment advices. • Standards. • ANSI x12. • United nations economic commission for Europe: EDI for administration, commerce, and transport (EDIFACT).

  38. EDI on the Internet • Early use of EDI was mainly on Value Added Networks (VAN’s) based primarily on dedicated and dailup links, and terminal emulation. • Internet offers a lower cost option and more flexibility. • Connecting VAN’s to the Internet. • Using electronic messaging (MIME).

  39. E-Commerce and Security • Security is the primary technical issue for expanding electronic commerce. • Cryptography is one tool among many for achieving the necessary guarantees. • Approaches to e-commerce must be delivered using widely-accepted tools and techniques.

  40. Secure E-Mail • Privacy Enhanced Mail (PEM). • MIME Object Security Services (MOSS). • S/MIME. (Applying PKCS #7 to MIME body parts.) • ITU X.400 secure messaging protocols. (Not compatible with Internet messaging.) • Message Security Protocol (MSP). (Comprehensive set of DoD protocols.)

  41. Web Security • Secure Socket Layer (SSL). • Secure HTTP (S-HTTP). Request/response protocol. • https:// versus shttp://

  42. Mobile or Downloadable Code • Java. • Protection via language runtime system guarantees. • ActiveX. • Microsoft Authenticode.

  43. Other Protocols • EDI security: ANSI X12.58 or S/MIME. • Secure Electronic Transaction (SET). Visa and MasterCard. • CyberCash. Intermediary between Web-based merchants and credit card banks. • CheckFree. Electronic checks. • First Virtual. Credit card payments via email.

  44. Public Key Infrastructure • Mutual authentication of participants in a transaction requires a system of identities. • Principals are identified by public keys. • These keys can be used for authentication, but only if “spoofing” is prevented. • A PKI provides a basis for establishing trust.

  45. PKI Systems • ITU X.509 (viz. IETF PKIX). • PGP “web of trust”. • DNS sec. • Simple public key infrastructure (SPKI - IETF alternative to X.509). • QCM (Web-like system from Penn/AT&T).

  46. X.509 • Part of the X.500 series of standards: the ISO/ITU Directory. • Originally intended to support access control for the directory as part of the Directory Access Protocol (DAP). • Dominant candidate now for PKI to support electronic commerce, although adoption has been slow.

  47. Subject Name Subject Public Key CA Name CA Signature X.509 Certificates X.509 certificates bind a subject to a public key. This binding is signed by a Certificate Authority (CA). Subject Name Subject Public Key CA Name CA Signature

  48. Joe Smith Subject Joe’s Key Subject’s Key Philly CA Issuer Philly CA Philly CA Key Pennsylvania CA Pennsylvania CA Pennsylvania CA Key USA CA Chaining

  49. Certificate Distribution • Certificate accompanying signature. • Directory service. • DAP. • LDAP. • DNS SEC. • Email (S/MIME and MOSS). • Primary technique: cut and paste from web pages!

  50. X.509 Certificate Format (v3) • Required fields. • Optional fields.

More Related