CSCE 815 Network Security Lecture 16 Web Security Secure Sockets Layer (SSL) March 18, 2003

Overview PGP one more time Key distribution SSL SET Note session key will be automatically generated pgp –h // help pgp –k // help on keys pgp –g // help on groups Key distribution SSL SET

PGP Key distribution Generating key and getting it into a file pgp –kg pgp –kx matthews mykey.pgp Approaches Page 137 Physical – write to floppy, hand to friend Verify key by telephone Read the key in radix 64 over the phone (not cell phone) Email key then verify by having PGP generate 160 bit SHA-1 digest of the key, read the hex digits (fingerprint) Obtain key from a trusted mutual friend Obtain key from a certifying authority

Web Security Outline Web Security Considerations Secure Socket Layer (SSL) and Transport Layer Security (TLS) Secure Electronic Transaction (SET)

Security facilities in the TCP/IP protocol stack

SSL and TLS SSL was originated by Netscape TLS working group was formed within IETF First version of TLS can be viewed as an SSLv3.1

SSL Architecture

SSL Record Protocol Services Confidentiality – the handshake protocol defines a shared key for encryptions of SSL payloads Message Integrity – the handshake protocol defines a shared key used to form message authentication code (MAC)

SSL Record Protocol Operation

Mac Calculation Hash(MAC_secret_key || pad2 || hash(MAC_secret_key || pad1 || seqNum || SSLcompressed.type || SSLcompressed.length || SSLcompressed.fragment)) Where: Mac_secret_key – pad1 = 0x36 repeated 48 times for MD5 40 times for SHA-1 pad2 = 0x5C repeated … SSLcompressed.type = the higher level protocol used to process this fragment Similar to HMAC figure 3.9 p67 (SSL based on draft)

Encryption Methods for SSL Fragments 214 = 16384 bytes Compression must be lossless and must not increase length more than 1024 No compression algorithm specified in SSLv3 – default no compression Block Cipher Encryption Methods IDEA (128) RC2-40, DES-40, DES (56), 3DES (168), Fortezza(80) Stream Cipher Encryption choices RC4-40, RC4-128 Fortezza used in smart cards

SSL Record Format

SSL Record Protocol Payload

Change Cipher Spec and Alert Protocols Change Cipher Spec Protocol consists of a single message of a single byte with value 1 it means copy pending state to current state Alert Protocol – use to convey SSL-related alerts Two Bytes: Level – severity of alert 1=warning, 2=fatal Alert type: Unexpected message Bad-record_mac Decompression failure Handshake failure Illegal_parameter …

Handshake Protocol The most complex part of SSL. Allows the server and client to authenticate each other. Negotiate encryption, MAC algorithm and cryptographic keys. Used before any application data are transmitted. Message Fields Type (8) Length (24) Content (>= 1 byte) parameters

SSL Handshake Protocol Message Types Table 7.2 Message type Parameters Hello-request null Client-hello version,random(32B), sessionID, cipher suite, compression method Server_hello ditto Certificate chain of X.509v3 certificates Server_key_exchange parameters, signature Certificate_request type, authorities Server_done null Certificate_verify signature Client_key_exchange parameters, signature Finished hash value

Handshake Protocol Action

Handshake Protocol Phase 1 Establish security capabilities Client_hello  Version = highest SSL understood by client Random 32 bit time stamp + 28 random bytes (secure random number generator) sessionID: 0 establish new connection, non-zero means update parameters of an existing session Ciphersuite: sequence of cryptographic algorithms in decreasing order of preference (key exchange + CipherSpec) Compression methods: sequence of compression methods Server_hello  is sent back same as above but confirmation Highest common version, new random field, same sessionID if nonzero, new sessionID otherwise, the selected ciphersuite and the selected compression technique

Handshake Protocol Phase 1 Key Exchange methods RSA – secrt key is encrypted with receiver’s RSA public key Fixed Diffie-Hellman Ephemeral Diffie Hellman Anonymous Diffie-Hellman Fortezza CipherSpec follows containing the fields Cipher algorithm MAC algorithm CipherType: block or stream Hash size: 0, 16 for MD5 or 20 for SHA-1 bytes Key material – sequence of bytes used to generate keys IV size of Initial Value for Cipher Block Chaining (CBC)

Handshake Protocol Phase 2 Server Authentication and Key Exchange Server sends Certificate: X.509 certificate chain (not required for anonymous Diffie-Hellman) Server_key_exchange (not always need e.g. fixed Diffie-Hellman) Hash(Client_hello.random||ServerHello.random||ServerParms) Certificate_request: certificate type and certificate authorities Server_hello_done: I’m done and I’ll wait on response

Handshake Protocol Phase 3 Client Authentication and Key Exchange Client verifies server certificate a checks the server hello paramters Client sends Certificate: if requested Client_key_exchange message must be sent Certificate_verify message to provide explicit verification of client certificate

Handshake Protocol Phase 4 Finish up: switch to next cipher_spec Client sends Change_cipher_spec message Finished message under new algorithms, keys (new cipher_spec) Server sends back

Transport Layer Security The same record format as the SSL record format. Defined in RFC 2246. Similar to SSLv3. Differences in the: version number message authentication code pseudorandom function alert codes cipher suites client certificate types certificate_verify and finished message cryptographic computations padding

Secure Electronic Transactions An open encryption and security specification. Protect credit card transaction on the Internet. Companies involved: MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign Not a payment system. Set of security protocols and formats.

SET Services Provides a secure communication channel in a transaction. Provides tust by the use of X.509v3 digital certificates. Ensures privacy.

SET Overview Key Features of SET: Confidentiality of information Integrity of data Cardholder account authentication Merchant authentication

SET Participants

Sequence of events for transactions The customer opens an account. The customer receives a certificate. Merchants have their own certificates. The customer places an order. The merchant is verified. The order and payment are sent. The merchant request payment authorization. The merchant confirm the order. The merchant provides the goods or service. The merchant requests payments.

Dual Signature

Payment processing Cardholder sends Purchase Request

Payment processing Merchant Verifies Customer Purchase Request

Payment processing Payment Authorization: Payment Capture: Authorization Request Authorization Response Payment Capture: Capture Request Capture Response

Recommended Reading and WEB sites http://web.mit.edu/network/isakmp/ Drew, G. Using SET for Secure Electronic Commerce. Prentice Hall, 1999 Garfinkel, S., and Spafford, G. Web Security & Commerce. O’Reilly and Associates, 1997 MasterCard SET site http://www.mastercardintl.com/newtechnology/set/ Visa Electronic Commerce Site http://usa.visa.com/personal/about_visa/newsroom/visa_security.html SETCo (documents and glossary of terms) http://www.setco.org/set_specifications.html