Lecture 06 SSL, TLS, and SET Asst.Prof.Supakorn Kungpisdan, Ph.D. [email protected] 1 ITEC4614-NETE0519

Lecture 06SSL, TLS, and SET

Asst.Prof.Supakorn Kungpisdan, [email protected]

1ITEC4614-NETE0519

ITEC4614-NETE0519 2

Web Security Considerations SSL and TLS Secure Electronic Transaction (SET)

Roadmap

ITEC4614-NETE0519 3

A Comparison of Threats on the Web

ITEC4614-NETE0519 4

Relative Location of Security Facilities in the TCP/IP Protocol Stack

ITEC4614-NETE0519 5

Web Security Considerations SSL and TLS

Secure Socket Layer Transport Layer Security

Secure Electronic Transaction (SET)

Roadmap

ITEC4614-NETE0519 6

SSL (Secure Socket Layer)

transport layer security service originally developed by Netscape version 3 designed with public input subsequently became Internet standard known as TLS

(Transport Layer Security) uses TCP to provide a reliable end-to-end service SSL has two layers of protocols

ITEC4614-NETE0519 7

SSL Architecture

ITEC4614-NETE0519 8

SSL Session & Connection

Connection: a transport that provides a suitable type of service Peer-to-peer relationship Every connection is associated with one session

Session: an association between a client and a server created by handshake protocol Session defines a set of cryptographic parameters used among

multiple connections. One session may contain several connections

ITEC4614-NETE0519 9

SSL Record Protocol Services

message integrity using a MAC with shared secret key similar to HMAC but with different padding

confidentiality using symmetric encryption with a shared secret key defined by

Handshake Protocol AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40,

RC4-128 message is compressed before encryption

ITEC4614-NETE0519 10

SSL Record Protocol

Services provided: Confidentiality by encryption and Message integrity by MAC


SSL Record Format


Steps in SSL Record Protocol

1. Fragmentation data fragmented into blocks of 214 bytes (16384 bytes) or less

2. Compression (optional): Lossless compression function applied May increase message length by 1024 bytes No compression in SSLv3 and TLS (null)


Steps in SSL Record Protocol: 3. MAC

data


Steps in SSL Record Protocol (cont.)

4. Encryption May increase the length by 1024 bytes so the total length must

not exceed 214+2048 bytes

1024 bytes from encryption +1024 bytes from compression



For stream encryption: message + MAC are encrypted For block encryption: padding and its length (1 byte) may

be attached after MAC so that the size of the message is a multiple of cipher’s clock length E.g. data = 58 bytes, MAC = 20 bytes (SHA-1), MAC length = 1

byteeach block length is 8 bytes (64 bits using DES)so pad length must be 1 byte so that 58+20+1+1 = 80 bytes (divisible by 8)



5. Append header Content Type (8 bits)

Higher layer protocol used to process enclosed fragment Types: change_cipher_spec, alert, handshake, application_data

Major Version (8 bits) For SSLv3.0, the value is 3

Minor Version (8 bits) For SSLv3.0, the value is 0

Compressed Length (16 bits) Length of final message (max. 214+2048 bytes)


SSL Protocols above Record Protocol

Change Cipher Spec Protocol Alert Protocol Handshake Protocol

Seen as applications of SSL Record protocol, these protocols are compressed and encrypted using SSL Record protocol


SSL Record Protocol Payload

≥

≥


Change Cipher Spec Protocol

One of 3 SSL specific protocols which use the SSL Record protocol Simplest among SSL protocols To cause the pending state to be copied into the current state, which

updates the cipher suite to be used on this connection Basically, it tells the Record protocol to use the new set of

encryption parameters specified in phase 1 of Handshake protocol


Alert Protocol

Used to convey SSL-related alerts to peer entity Compressed & encrypted like all SSL data Message consists of 2 bytes

1st byte contains warning (1) or fatal (2) If 2, SSL immediately terminates connection, and no new connection

may be established. Then client must establish a new session. 2nd byte contains a code indicating specific alert


Alert Protocol (cont’d)

Alerts that are always fatal unexpected_message: impropriate message received bad_record_mac: incorrect MAC received decompression_failure: the function received improper

input handshake_failure: sender is unable to negotiate an

acceptable set of security parameter illegal_parameter: a field in handshake message is

inconsistent with other fields


Handshake Protocol

Allows server and client to authenticate each other Also to negotiate encryption and MAC keys used to protect

data sent in SSL Each Handshake protocol message contains 3 fields

Type (1 byte): indicates one of 10 messages Length (3 bytes): message length in bytes Content (≥ 1 byte): Type-related parameters


SSL Handshake Protocol Msg Types


Handshake Protocol Action

Change Cipher Spec protocol message


Phase1: Establish Security Capabilities

To initiate logical connection and to establish security capabilities associated with it

client_hello contains Version: SSL version Random: 32-bit timestamp and 28 bytes random number

generated by a secure random generator. Served as nonce during key exchange

Session ID: Non-zero value client wants to update connection parameters or

create a new connection on current session Zero value client wants to create a new connection on a new session


Phase1: Establish Security Capabilities (cont.)

Ciphersuite Contains a list of key exchange algorithms supported by the

client (for the server to select one of these) and a CipherSpec (definition of key exchange method)

Compression Method List of compression method supported by client


Phase1: Establish Security Capabilities (cont.)

server_hello contains Version

Same as that in client_hello Random:

generated by server, independent of client’s Random Session ID

If client’s Session ID is non-zero, Server’s is also contains the same value If zero, server’s Session ID contains the new value for a new session

CipherSuite: a single cipher suite selected by server from those proposed by client

Compression Method: the selected method from those proposed by client


CipherSuite

CipherSuite contains key exchange methods and CipherSpec Key exchange methods:

RSA (secret key is encrypted with RSA public key) Fixed DH (fixed public keys), Ephermeral DH (use one-time public key signed by sender), Anonymous DH (no verification of public-key sender) Fortezza scheme

CipherSpec: includes the following: CipherAlgorithm: encryption algo MACAlgorithm: MD5 or SHA-1 CipherType: Stream or Block HashSize: 0, 16 (MD5) or 20 (SHA-1) bytes Key Material: a data used to generating the write keys IV Size: size of IV for CBC encryption


Phase2: Server Authentication and Key Exchange

Server sends its certificate if needed. certificate msg is required except in anonymous DH server_key_exchange (to exchange DH keys) is sent if

required except two instances: Server has sent a certificate with fixed DH parameters (already sent in certificate message)

RSA key exchange is to be used (no DH parameters used) The parameters in server_key_exchange is used to

generate a pre-master secret using DH key exchange. The pre-master secret will be later used to create a master secret.


Phase2: Server Authentication and Key Exchange (cont.)

Server can request a cert from client. certificate_request includes:

Certificate_type: indicates public-key algo used Certificate_authorities: list of acceptable CAs

server_done Indicate the end of server hello. Server then waits for a client

response


Phase3: Client Authentication and Key Exchange

Client verifies server’s cert and checks if server_hello parameters are acceptable

If server requests for client’s cert, client sends certificate. If client doesn’t have a cert, client sends no_certificate alert instead

client_key_exchange contains (DH) key exchange parameters used to generate a pre-master secret and then later a master secret

Client may send certificate_verify to provide explicit verification of a client cert.

CertificateVerify.signature.md5_hashMD5(master_secret||pad_2||MD5(handshake_messages|| master_Secret||

pad_1))Certificate.signature.sha_hash

SHA(master_secret||pad_2||SHA(handshake_messages|| master_secret||pad_1))

All handshake msgs sent or received since client_hello except this msg


Phase4: Finish

Client sends change_cipher_spec and copies the pending CipherSpec into current CipherSpec (change cipher spec protocol message is sent)

Client also sends finished under new algos, keys, and secrets. finished verifies that key exchange and authentication were

successful. finished contains two values:

MD5(master_secret||pad2||MD5(handshake_messages|| Sender||master_secret||pad1))

SHA(master_secret||pad2||SHA(handshake_messages|| Sender||master_secret||pad1))

Server sends its own change_cipher_spec and finished to complete Handshake protocol

All handshake msgs sent or received since client_hello except this msg


Master Secret Creation

The shared 48-byte pre-master secret is one-time generated for this session for secure key exchange Exchange pre_master_secret Calculate master_secret

Exchange pre_master_secret RSA: client encrypts pre_master_secret with server’s RSA public

key and sends it to server DH: client and server generates DH public key and create

pre_master_secret


Create master_secret

master_secret = MD5(pre_master_secret||SHA(‘A’||pre_master_secret|| ClientHello.random||ServerHello.random))||MD5(pre_master_secret||SHA(‘BB’||pre_master_secret|| ClientHello.random||ServerHello.random))||MD5(pre_master_secret||SHA(‘CCC’||pre_master_secret|| ClientHello.random||ServerHello.random))

Until 48 bytes of secret are produced

Master Secret Creation (cont.)


Generation of Cryptographic Parameters

CipherSpecs require the following parameters Client write MAC secret Server write MAC secret Client write key Server write key Client write IV Server write IV

These values are generated from the master secret Such values will be later used for SSL Record protocol


Generation of Cryptographic Parameters (cont.)

Key_block = MD5(master_secret||SHA(‘A’||master_secret|| ServerHello.random||ClientHello.random))||

MD5(master_secret||SHA(‘BB’||master_secret|| ServerHello.random||ClientHello.random))||

MD5(master_secret||SHA(‘CCC’||master_secret|| ServerHello.random||ClientHello.random))||…

Until enough output has been generated.


Web Security Considerations SSL and TLS

Secure Socket Layer Transport Layer Security

Secure Electronic Transaction (SET)

Roadmap


Difference btw SSL and TLS

Version TLS Record protocol is the same as SSL Record protocol In TLS, major version is 3 and minor version is 1

Message Authentication Code Alert Codes:

TLS supports all SSLv3 alerts and provides additional alerts CipherSuites

Key Exchange: TLS supports all SSLv3 key exchange except Fortezza

Encryption algos: TLS supports all SSLv3 encryption except Fortezza


Web Security Considerations SSL and TLS Secure Electronic Transaction (SET)

Roadmap


Secure Electronic Transaction


Services Provided by SET

Secure communications channel among involved parties Trust by using X.509 certs Party privacy: parties will receive only the information that

they are intended to receive


SET Requirements

Provide confidentiality of payment and ordering information Ensure the integrity of all transmitted data Provide authentication that a cardholder is a legitimate user of a

credit card account Provide authentication that a merchant can accept credit card

transactions through its relationship with a financial institution Ensure the use of the best security practices and system design

techniques to protect all legitimate parties in an e-commerce transactions

Create a protocol that neither depends on transport security mechanisms nor prevents their use


Secure Electronic Transaction

12

34, 6

5, 10, 11

79

8

12


SET Transaction Overview

1. Client opens an account2. Client receives a certificate3. Merchants have their own certs4. The client places an order (C M)5. The merchant is verified (M C)6. The order and payment are sent (C M)7. The merchant requests payment authorization (M PG)8. Payment is approved (PG I, I A, I,A PG)9. The merchant receives authorization response (PG M)10. The merchant confirms the order (M C)11. The merchant provides goods or service (M C)12. The merchant requests payment (M A)


Dual Signature

In SET, two messages for two intended recipients are sent in one message Order Information (OI) from client to merchant -> not revealed to the bank Payment Information (PI) from client to the bank -> not revealed to the

merchant DS = EKRc[H(H(PI)||H(OI))] DS provides link btw OI and PI for the client

If merchant receives DS, H(PI), merchant can prove that client has sent purchase request (because merchant has OI).

If bank receives DS, H(OI), the bank can prove that client has request it to deduct money from client’s account (because the bank has PI).

Dual Signature (cont.)

C M: EKRc[H(H(PI)||H(OI))], h(PI)

Merchant decrypts EKRc[H(H(PI)||H(OI))]Merchant knows OI, create h(OI)Merchant creates H(H(PI)||H(OI)) and compares with the received H(H(PI)||H(OI))



M PG: EKRc[H(H(PI)||H(OI))], h(OI)

PG decrypts EKRc[H(H(PI)||H(OI))]PG knows PI, create h(PI)PG creates H(H(PI)||H(OI)) and compares with the received H(H(PI)||H(OI))





Questions?

Documents

Lecture 06 SSL, TLS, and SET Asst.Prof.Supakorn Kungpisdan, Ph.D. [email protected] 1 ITEC4614-NETE0519