Chapter 17: Web Security

//Modified by Prof. M. Singhal//

Henric Johnson
Blekinge Institute of Technology, Sweden http://www.its.bth.se/staff/hjo/ henric.johnson@bth.se Henric Johnson
1

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

Henric Johnson

Web Security Considerations

The WEB is easily accessible worldwide. //more vulnerability// Complex software hide many security flaws. Users are not trained in computer security and are not aware of the risks. A Web server can be exploited as a launching pad into a corporations entire computer complex.
Henric Johnson 3

Web Security Approaches

1. To use IPSec: (At Network Level) >Provides a general purpose solution. >Transparent to end users and applications. >IPSEc Filtering capability: only selected traffic need incur the overhead of IPSec processing.
Henric Johnson 4

Web Security Approaches

2. Implement Just above TCP: >Provides a general purpose solution. >Examples: SSL/TLS. >As a part of underlying protocol suite, it is transparent to the applications. >SSL can also be embedded in applications. (Explorer browsers are equipped with SSL.)
Henric Johnson 5

Web Security Approaches

3. Application Level: >Security services are embedded within an application. >Security service can be tailored for specific needs of an application. >Example: Secure Electronic Transaction (SET).
Henric Johnson 6

Security facilities in the TCP/IP protocol stack

Henric Johnson

Secure Socket Layer (SSL)

Implements three cryptographic assurances: 1. Authentication. 2. Confidentiality. 3. Message integrity. > Also provides secure key exchange between a browser (client) and server. > Provides security parameters negotiation. > Does not offer non-repudiation.
Henric Johnson 8

SSL...
SSL Architecture: >SSL runs on the top of TCP to provide reliable and secure end-to-end service.
>Consists of two layers (shown in next Slide).
Henric Johnson 9

SSL Architecture

Henric Johnson

10

SSL Record Protocol

Provides two services for SSL connections: 1. Confidentiality: A shared secret key used for conventional encryption of SSL payload. 2. Message Integrity: A shared secret key is used to construct a message authentication code.
Henric Johnson 11

SSL Record Protocol

Record protocol takes an application message and performs the following operations: >Fragmentation. >Compression > Add a MAC (a shared secret key is used) >Encryption (symmetric encryption) >Appends an SSL record header.
Henric Johnson 12

SSL Record Protocol Operation

Henric Johnson

13

SSL Record Format

Henric Johnson

14

SSL Record Header

Content Type (8): Used by higher layers to process the enclosed fragment. Major Version (8): Indicates the major version of SSL used. Minor Version (8): Indicates the minor version of SSL used. Compressed length (16): The length of fragment in bytes.
Henric Johnson 15

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.
Henric Johnson 16

Handshake Protocol Action

Henric Johnson

17

An SSL Session
1. Negotiation of cryptographic parameters //Two computers probably dont know each others capabilities.// 2. Key Agreement. //C & S generate shared secret key.// 3. Authentication (client authenticates server). 4. Confidentiality and integrity. //private messages Johnson exchanged between C & Henric 18 S.//

1. Hello and Negotiate Parameters

Client sends server a plaintext message to suggest some parameters for conversation:
Version: SSL 3.1 if you can, else SSL 3.0 Key Exchange: RSA if you can, else Diffie-Hellman Secret Key Cipher Method: TripleDES if you can, else DES Message Digest: MD5 if you can, else SHA-1 Random #: 777,666,555
Henric Johnson 19

 Server responds by its choice of parameters in a plaintext message:

Version: SSL 3.1 Key Exchange: RSA Secret Key Cipher Method: TripleDES Message Digest: SHA-1 Random #: 444,333,222
Henric Johnson 20

1. Hello and Negotiate Parameters

 After responding to the hello message, the server sends the client its digital certificate. //A trusted CA signed this certificate.// The client uses the trusted CAs public key to decrypt the certificate and obtains servers public key and verifies the server.
Henric Johnson 21

1. Hello and Negotiate Parameters

 The client generates a 48byte random value (called pre-master secret), encrypts it with servers public RSA key, and sends it to server. The server decrypts this message and generates six keys.

2. Key Agreement and Exchange

DES secret Key Secret key for message integrity Secret key to initialize the cipher. DES secret Key Secret key for message integrity Secret key to initialize the cipher.

Henric Johnson

22

2. Key Agreement and Exchange

Generation of six shared secret keys: <> Random values exchanged. <> Pre-master secret. <> Pseudo-random function generator. Example: PRF(pre-master secret, random1+ random2) Computed repeatedly. Henric Johnson 23

3. Authentication
The client authenticates the server: The clients sends the server a message that is encrypted with the generated secret keys. //called the finished handshake message// The server responds with its own encrypted finished handshake message. <> The clients is now convinced that it is communicating with right server. //pre-master secret could only be decrypted with the servers private key.//
Henric Johnson 24

3. Authentication
Does server need to authenticate the client? In general yes, but in this situation it may not be necessary: Reasons: 1. It is not necessary because it will be done when the client gives his/her CC number. 2. A client may not have information to authenticate itself to the server. Henric Johnson 25

4. Confidentiality and Integrity

Client and server use the generated secret keys for confidential data transfer. <> The client uses its secret key to generate a HMAC for the message. <> The client encrypts message data + HMAC with its secret key and sends it to server. <> The server decrypts the received message with its secret key. <> The server checks the integrity of the message using HMAC.
Henric Johnson 26

Secure Electronic Transactions

An open encryption and security specification. Designed to 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 (enables users to employ existing CC payment infrastructure securely in an open environment).
Henric Johnson 27

SET Services
Provides three services: 1. Provides a secure communication channel among all parties involved in a transaction. 2. Provides trust by the use of X.509v3 digital certificates. 3. Ensures privacy: information is only available to involved parties.
Henric Johnson 28

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

Henric Johnson

29

SET Participants

Henric Johnson

30

1. The customer opens an account. 2. The customer receives a certificate. (contains customers public key) 3. Merchants have their own certificates. (Two certificates: one for signing messages and the other for key exchange.) 4. The customer places an order. 5. The merchant is verified. (merchant sends a copy of its certificate; the customer can verify it.)
Henric Johnson 31

Sequence of events for transactions

6. The order and payment are sent. >The payment information is encrypted in such a way that it can not be read by the merchant. > Customers certificate enables the merchant to verify the customer. 7. The merchant requests payment authorization. >Merchant sends the payment information to payment gateway, requesting authorization. 8. The merchant confirms the order. >Merchant sends confirmation to customer.
Henric Johnson 32

Sequence of events for transactions

9. The merchant provides the goods or service. >Merchant ships goods to customer. 10. The merchant requests payments. >Merchant sends payment request to the payment gateway, which handles payment processing.

Sequence of events for transactions

Henric Johnson

33

Dual Signature
Objective: to link two messages that are intended for two different recipients. Customer wants to send: 1. Order Information (OI) to merchant. 2. Payment information (PI) to bank. >Customer wants to link these two items and also wants to keep them separate. Henric Johnson 34

Dual Signature
>Merchant need not know about CC#. >Bank need not know the details of customers order. >> However, these two items must be linked to resolve any dispute. >>Customer can prove that this payment was intended for this order. //protects customer and merchant.//
Henric Johnson 35

Generation of Dual Sign.

Customer takes the hash (SHA-1) of PI. Customer takes the hash of OI. Concatenates these two and takes hash of the result. Customer signs the final hash with his private key. DS = EKRc[H(H(PI)||H(OI))]
Henric Johnson 36

Dual Signature
DS E KRc [ H ( H ( PI ) || H(OI))]

Henric Johnson

37

Dual Signature
Merchant has DS, OI, and PIMD. >Merchant computers H(PIMD||H(OI)). >Merchant decrypts DS using customers public key. >If both these items are equal, the merchant has verified the DS. //Merchant is never sent the PI//
Henric Johnson 38

Dual Signature
The bank has DS, PI, and OIMD. >The bank computers H(H(PI)||OIMD). >The bank decrypts DS using customers public key. >If both these items are equal, the merchant has verified the DS. //The bank is never sent the OI.//
Henric Johnson 39

Payment Processing
Look at three steps:
1. Purchase request 2. Payment authorization 3. Payment capture

Henric Johnson

40

Payment Processing
1. Purchase request: Cardholder prepares a purchase request message and sends it to merchant. The message has following information: A. Purchase-Related Information: //Forwarded to payment gateway by the merchant.//
Henric Johnson 41

Payment Processing
A. Purchase-Related Information: >PI >Dual signature (DS) >OIMD (needed to verify the DS) //all above items encrypted with a secret key Ks.// //Ks is not known to merchant. It is known to payment gateway.// >Digital envelope: formed by encrypting Henric Johnson 42 Ks by the public key of payment GTW.

Payment Processing
B. Order-Related Information: >OI //sent in clear// >Dual signature (DS) >PIMD (needed to verify the DS) C. Cardholder certificate: >Contains cardholders public key. >Needed by merchant and payment GTW.
Henric Johnson 43

Payment processing

Cardholder sends Purchase Request

Henric Johnson 44

Payment Processing
The merchant processes the message in the following way: 1. Verifies cardholder certificate with the CAs key. 2. Verifies the dual signature. Insures: >Message integrity >Message authentication.
Henric Johnson 45

Payment Processing
3. Processes the order and forwards the payment information to payment GTW for authorization. 4. Sends a purchase response message to the cardholder.

Henric Johnson

46

Payment processing

Merchant Verifies Customer Purchase Request

Henric Johnson 47

Payment processing
Payment Authorization: >Mercahnt authorizes the transaction with payment GTW. > Guarantees that the merchant will receive payment. > Consists of two messages: Authorization Request Authorization Response
Henric Johnson 48

Payment processing
Authorization Request: >Merchant to payment GTW. >Consists of the following three items: 1. Purchase-Related Information: //Obtained from the customer.// >PI >Dual Signature >OIMD Henric Johnson 49 >The digital envelope

Payment processing
2. Authorization-Related Information: //generated by the merchant.// >An authorization block //consists of transaction ID signed with merchants private key and encrypted with one time symmeric key.// >A digital envelope //Formed by encrypting one time key with the payment GTWs public key.//
Henric Johnson 50

Payment processing
3. Certificates: The following certificates are sent: >Cardholders certificate //to verify DS.// >The Merchants certificate //to verify merchants signatures.// >The merchants key-exchange cert. //needed in the payment GTWs response.//
Henric Johnson 51

Payment processing
Authorization Response: -Payment GTW processes the received information. -Obtains authorization from issuer. -Returns an authorization response to merchant. -Authorization response contains three items.
Henric Johnson 52

Payment processing
Authorization Response: 1. Authorization-related information: >Authorization block signed by payment GTWs private key and encrypted with a one-time symmetric key. >A digital envelop that contains the one time symmetric key (encrypted with merchants public key).
Henric Johnson 53

Authorization Response: 2. Capture token information: //Used to affect the payment later.// >A signed, encrypted capture token. //Returned with payment request later.// >A digital envelope. //contains the one time symmetric key encrypted with merchants public key.// 3. Certificate: Henric Johnson 54 Gateways signature key certificate.

Payment processing

Payment processing
Payment Capture: To obtain payment from payment GTW. Capture Request //Merchant sends this message to payment GTW.// //Merchant generates, signs, and encrypts a capture block that consists of the following items.//
Henric Johnson 55

Payment processing
Capture Request... >Payment amount >Transaction ID >Capture token received earlier for this transaction. >Merchants certificate. >Merchants key-exchange certificate.
Henric Johnson 56

Payment processing
Payment Capture: >The Payment GTW verifies the information in the capture request. >Sends a clearing request to the issuer over the private payment network. >The funds are transferred to merchants account. >The GTW notifies the merchant of the payment in a Capture Response msg.
Henric Johnson 57

Recommended Reading and WEB sites

Drew, G. Using SET for Secure Electronic Commerce. Prentice Hall, 1999 Garfinkel, S., and Spafford, G. Web Security & Commerce. OReilly and Associates, 1997 MasterCard SET site Visa Electronic Commerce Site SETCo (documents and glossary of terms)
Henric Johnson 58