ee579t / cs525t network security 6: ssl and set

Spring 2003© 2000-2003, Richard A. Stanley

EE579T/6 #1

EE579T / CS525TNetwork Security

6: SSL and SET

Prof. Richard A. Stanley


EE579T/6 #2

If IPSec is So Good...

• Why do we need anything else?– One could also ask, if C++ is such a good

programming language, why do we need Java?– SSL provides another choice for achieving security

over insecure networks (e.g. Internet)

• Where they are:– IPSec operates at the network level– SSL operates at the transport level– Other protocols operate at the application level


EE579T/6 #3

Network Level Security

HTTP FTP SMTP

TCP

IP/IPSec


EE579T/6 #4

Transport Level Security

SSL / TLS

HTTP FTP SMTP

TCP

IP/(IPSec)


EE579T/6 #5

Application Level Security

TCP

IP/(IPSec)

Kerberos

S/MIME PGP SET

UDP

SMTP HTTP


EE579T/6 #6

What’s a Socket?

• The name, Secure Sockets Layer, implies we are securing something called a socket. What is that?

• Remember that IP applications separate themselves by listening on one or more of 64K possible ports (i.e. addresses)

• A socket is a fully-specified IP address, e.g.10.1.7.203:80 or 192.168.5.7:23


EE579T/6 #7

Well-Known Ports

• Many common IP services operate on what are routinely called well-known ports– Port 80: HTTP– Ports 20, 21: FTP– Port 23: Telnet– Port 25: SMTP– Port 119: NNTP

• SSL operates on Port 443


EE579T/6 #8

SSL Factoids

• Developed by Netscape

• Current version is SSLv3, dates to mid-90’s

• Many efforts along the way to develop a multi-vendor approach, all of which have led to dead ends (i.e. Microsoft did not succeed in moving Netscape to their point of view)


EE579T/6 #9

SSL Provides

• Confidentiality– Using symmetric key cryptography

• Integrity– Using asymmetric key cryptography and

hashing

• Authenticity– Using digital signatures and certificates on

server, and optionally, on client side


EE579T/6 #10

SSL Architecture

• Two layers of protocols on top of TCP– Top level

• SSL Handshake protocol

• SSL ChangeCipherSpec protocol

• SSL Alert protocol

– SSL Record Protocol


EE579T/6 #11

SSL Architecture Overview

SSL Record Protocol

SSL Alert HTTP

TCP

IP/(IPSec)

SSL CipherChange Spec

SSL Handshake

NB: This diagram does not infer the order in which the protocols are applied.


EE579T/6 #12

Sessions and Connections

• An SSL session is a client/server association– Created by Handshake protocol– Defined security parameters

• An SSL connection is a transport that provides a service (e.g., HTTP)– Connections are transient– Many connections can exist within a single session


EE579T/6 #13

SSL Handshake Protocol

• Most complex part of SSL

• Starts when client connects to server

• Sets up session protocols

• Selects crypto system to be used

• Authenticates client and server

• Sets up basis for shared secret key, the MasterSecret


EE579T/6 #14

SSL Handshake OverviewClient Server

1. Supported ciphers, random number

2. Cipher choice, certificate, random number

3. PreMasterSecret (encrypted in server’s public key)

Verify certificate,Generate

PreMasterSecret

4. Generate keys4. Generate

keys

6. HMAC over handshake messages received

5. HMAC over handshake messages sent


EE579T/6 #15

Key Generation

Server random number

Client random number

PreMasterSecret

Label information

Key Generator

MasterSecret

SSL session keys


EE579T/6 #16

Client/Server Random Numbers

• Consist of– 32-bit timestamp– 28-byte random number generated by secure

RNG– So, 32 bytes long overall

• These random numbers serve as nonces

• Protect against replay attacks


EE579T/6 #17

PreMasterSecret

• Key to setting up secure exchange

• 48-byte random value, generated by client’s secure RNG

• Sent to server encrypted with server’s public key (from certificate sent in Step 2)

• Provides the secure basis for computing the MasterSecret


EE579T/6 #18

SSL-Supported Ciphers

Algorithm KeyLength

Algorithm KeyLength

IDEA 128 RC4-40 40RC2-40 40 RC4-128 128DES-40 40DES 563DES (TDEA) 168Fortezza 80

Block Ciphers Stream Ciphers


EE579T/6 #19

SSL Keys

• The MasterSecret allows calculation of four symmetric keys, used as follows:– Authentication key for client to server data– Authentication key for server to client data– Encryption key for client to server data– Encryption key for server to client data

• Use of symmetric keys in these areas allows for faster data transfer than asymmetric key


EE579T/6 #20

HMAC Revisited

• Hashed Message Authentication Code is a recursive MAC– I.e., it is a hash of data that includes a hash– Both hash functions inputs padded by repeated

instances of 5C hex (opad) or 36 hex (ipad)– Both the “internal” and “external” hash is

computed using a secret key, developed from the MasterSecret


EE579T/6 #21

SSL ChangeCipherSpec

• This protocol is used to change from one encryption algorithm to another– Called “strategies” in the RFC

• To change ciphers, client and server negotiate a new CipherSpec and keys– Then send ChangeCipherSpec message, which triggers

use of the new algorithm and keys

• CipherSpec usually changed at end of SSL handshake, but can be done anytime


EE579T/6 #22

SSL Alert Protocol• Used to provide connection management

• Involves messages such as\– Digital certificate status– Handshake failure– MD failure

• Two levels of alert– Warning: nonfatal problem– Fatal: immediately terminates session


EE579T/6 #23

SSL Record Protocol

• Provides two SSL services:– Confidentiality

• Using shared symmetric keys from MasterSecret

– Message integrity• Using MAC generated using shared symmetric keys

from MasterSecret

• Also provides for message fragmentation and (optionally) compression (lossless)


EE579T/6 #24

SSL Overview

• At a minimum, SSL authenticates the server to the client and establishes a secure data session (confidentiality + integrity)– This is what happens when the lock closes on your

browser while you are eShopping– Careful--JavaScript can make the lock close!

• Optionally, if the client has a certificate acceptable to the server, the session can be authenticated in both directions


EE579T/6 #25

SSL Versions

• Current version is Version 3.0

• Version 2.0 was the first version to actually see commercial service– Contains many security flaws– Don’t use it unless absolutely necessary!

• Current browsers all support SSL 3.0


EE579T/6 #26

How Do You Get It?

• SSL comes pre-configured on modern browsers, which also have a large suite of root certificates

• SSL must be enabled on the appropriate server during the server configuration process– Easy on IIS -- check boxes to select parameters– A completely different build for Apache


EE579T/6 #27

How Do You Know If You Have It?

• SSL is identified by the mnemonics HTTPS, FTPS, SMTPS

• Operates on port 443 rather than port 80 (used by HTTP)

• When operating with an HTTP connection, the URL will begin https://...

• Conversely, if SSL is enabled, it can be accessed by addressing https://...


EE579T/6 #28

After SSL: TLS

• Transmission Level Security (TLS) is an IETF approach to creating a “non-vendor specific” SSL

• TLS 1.0 is actually SSL v3.1, and the SSL handshake so identifies it– TLS uses a different suite of ciphers– TLS uses HMAC differently from SSL

• Supported by all current browsers


EE579T/6 #29

Before SSL: S-HTTP

• Before SSL was developed and fielded, another secure system was developed for signing and encrypting HTTP information

• S-HTTP includes some features that SSL omits, such as having previously signed documents on a server

• For all intents and purposes, S-HTTP is a dead-end protocol, not implemented in current browsers or other clients


EE579T/6 #30

SSL Summary

• SSL provides a means for secure transport layer communications in TCP/IP networks

• SSL is a commonly used protocol, developed by Netscape, but ubiquitously used in browsers, etc.

• The key element of SSL is the handshake protocol


EE579T/6 #31

SET: Secure Electronic Transaction

• Security specification to protect credit card transactions conducted over the Internet

• Product of MasterCard and Visa call for proposals to develop such a standard

• Differs from encryption standards so far discussed in its intent and implementation

• Introduced the concept of a dual digital signature, which can have other uses


EE579T/6 #32

SET Services

• Secure communications among all parties involved in a transaction

• Authentication using X.509v3 certificates

• Privacy, as only the information required by each party to the transaction is provided to that party– We will see some details of how this works

later


EE579T/6 #33

Key Concepts

• Order information (OI) and payment information (PI) are separate, but linked– Vendor needs order information to process the

order, but does not need payment information• Vendor needs to be paid, but doesn’t need the

details of the payment (e.g. credit card number)

– Payor does not need order information, but needs to be able to link order to payment info to prevent fraud


EE579T/6 #34

SET Overview• Confidentiality of PI and OI

• Integrity of all transmitted data

• Authentication– Card user is legitimate user of card– Merchant is authorized to accept card

• Independent of transport security

• Independent of platform, O/S, etc.

• Use well-reviewed cryptographic protocols


EE579T/6 #35

SET Cryptography

• Confidentiality– DES

• Data integrity– SHA-1

• Authentication– X.509v3 certificates, RSA digital signatures

• No choices! This is a single application with a single purpose, not a GP protocol


EE579T/6 #36

The Players• Cardholder (the customer!)

• Merchant (sells the goods or services)

• Issuer (of the customer’s credit card)

• Acquirer (has account with merchant, provides card authorization, EFT)

• Payment gateway (processes merchant payment messages)

• Certification Authority (CA)


EE579T/6 #37

Sequence of Events - 1

• Customer opens SET-capable account

• Customer receives digital certificate

• Merchant obtains certificates– Certificate for signing messages– Certificate for public key exchange– Payment gateway’s public key certificate

• Customer places order


EE579T/6 #38

Sequence of Events - 2

• Merchant verified to customer

• Order and payment info sent to merchant

• Merchant requests payment authorization

• Merchant confirms order

• Merchant provides goods and services

• Merchant requests payment


EE579T/6 #39

Dual Signature: Why?

• Merchant needs to know customer can pay for the goods, but does not need to know the details of the payment information

• Issuer of card needs to know payment information, but does not need to know the details of the order

• The order and payment info must be linked to prevent fraud


EE579T/6 #40

Dual Signature

PIMD

OIMD

Hash POMD En- crypt

Customer’sprivate key

Dual Sig.

Merchant

Bank

PI

OI Hash

Hash

Customer’spublic key


EE579T/6 #41

Now What?

• Merchant can compute– Decrypt of dual signature– Hash of OI (because it has OI) = OIMD– Hash of OIMD concatenated with PIMD =POMD

= decrypt of DS– If these are equal, OI and PI are linked

• it is infeasible to create or modify either and maintain the linkage (hashing basics)

• Bank can do the same with PI


EE579T/6 #42

Payment Processing

• Customer initiates purchase request– Purchase information (PI)

– Order information (OI)

– Cardholder certificate

• Merchant verifies cardholder certificate and dual signature, processes order

• Merchant requests payment through gateway, gets authorization, completes order


EE579T/6 #43

SET Summary

• SET provides a robust set of specialized protocols to facilitate Internet commerce

• The unique feature of SET is the dual signature, which could be applied elsewhere

• SET is not required to perform Internet commerce, and is not ubiquitous

• SET does not deal with security or privacy of customer data once it is stored


EE579T/6 #44

Homework

• Read Stallings, Chapter 9.1

• Do the following problems from Stallings, Chapter 7:– 7.1– 7.2

ee579t / cs525t network security 6: ssl and set

Documents