Chapter 17: Web Security

1
Chapter 17 Web Security
//Modified by Prof. M. Singhal// Henric
Johnson Blekinge Institute of Technology,
Sweden http//www.its.bth.se/staff/hjo/ henric.joh
nson_at_bth.se
2
Outline

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

3
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.

4
Web Security Approaches

• 1. To use IPSec (At Network Level)
• gtProvides a general purpose solution.
• gtTransparent to end users and applications.
• gtIPSEc Filtering capability only selected
  traffic need incur the overhead of IPSec
  processing.

5
Web Security Approaches

• 2. Implement Just above TCP
• gtProvides a general purpose solution.
• gtExamples SSL/TLS.
• gtAs a part of underlying protocol suite,
• it is transparent to the applications.
• gtSSL can also be embedded in applications.
  (Explorer browsers are equipped with SSL.)

6
Web Security Approaches

• 3. Application Level
• gtSecurity services are embedded within an
  application.
• gtSecurity service can be tailored for specific
  needs of an application.
• gtExample Secure Electronic Transaction (SET).

7
Security facilities in the TCP/IP protocol stack
8
Secure Socket Layer (SSL)

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

9
SSL...

• SSL Architecture
• gtSSL runs on the top of TCP to provide
• reliable and secure end-to-end service.
• gtConsists of two layers (shown in next
• Slide).

10
SSL Architecture
11
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.

12
SSL Record Protocol

• Record protocol takes an application message and
  performs the following operations
• gtFragmentation.
• gtCompression
• gt Add a MAC (a shared secret key is used)
• gtEncryption (symmetric encryption)
• gtAppends an SSL record header.

13
SSL Record Protocol Operation
14
SSL Record Format
15
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.

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

17
(No Transcript)
18
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 exchanged
between C S.//
19
1. Hello and Negotiate Parameters

• Client sends server a plaintext message to
  suggest some parameters for conversation

20
1. Hello and Negotiate Parameters

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

21
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.

22
2. Key Agreement and Exchange

• The client generates a 48-byte 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.

23
2. Key Agreement and Exchange

• Generation of six shared secret keys
• ltgt Random values exchanged.
• ltgt Pre-master secret.
• ltgt Pseudo-random function generator.
• Example
• PRF(pre-master secret, random1 random2)
• Computed repeatedly.

24
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.
• ltgt The clients is now convinced that it is
  communicating with right server.
• //pre-master secret could only be decrypted with
  the servers private key.//

25
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.
• 3. It is time-consuming for server.

26
4. Confidentiality and Integrity

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

27
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).

28
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.

29
SET Overview

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

30
SET Participants
31
Sequence of events for transactions

• The customer opens an account.
• 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.)

32
Sequence of events for transactions

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

33
Sequence of events for transactions

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

34
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.
• gtCustomer wants to link these two items and also
  wants to keep them separate.

35
Dual Signature

• gtMerchant need not know about CC.
• gtBank need not know the details of customers
  order.
• gtgt However, these two items must be linked to
  resolve any dispute.
• gtgtCustomer can prove that this payment was
  intended for this order.
• //protects customer and merchant.//

36
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 EKRcH(H(PI)H(OI))

37
Dual Signature
38
Dual Signature

• Merchant has DS, OI, and PIMD.
• gtMerchant computers H(PIMDH(OI)).
• gtMerchant decrypts DS using customers public
  key.
• gtIf both these items are equal, the merchant has
  verified the DS.
• //Merchant is never sent the PI//

39
Dual Signature

• The bank has DS, PI, and OIMD.
• gtThe bank computers H(H(PI)OIMD).
• gtThe bank decrypts DS using customers public
  key.
• gtIf both these items are equal, the merchant has
  verified the DS.
• //The bank is never sent the OI.//

40
Payment Processing

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

41
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.//

42
Payment Processing

• A. Purchase-Related Information
• gtPI
• gtDual signature (DS)
• gtOIMD (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.//
• gtDigital envelope formed by encrypting Ks by the
  public key of payment GTW.

43
Payment Processing

• B. Order-Related Information
• gtOI //sent in clear//
• gtDual signature (DS)
• gtPIMD (needed to verify the DS)
• C. Cardholder certificate
• gtContains cardholders public key.
• gtNeeded by merchant and payment GTW.

44
Payment processing

• Cardholder sends Purchase Request

45
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
• gtMessage integrity
• gtMessage authentication.

46
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.

47
Payment processing
Merchant Verifies Customer Purchase Request
48
Payment processing

• Payment Authorization
• gtMercahnt authorizes the transaction with
  payment GTW.
• gt Guarantees that the merchant will receive
  payment.
• gt Consists of two messages
• Authorization Request
• Authorization Response

49
Payment processing

• Authorization Request
• gtMerchant to payment GTW.
• gtConsists of the following three items
• 1. Purchase-Related Information
• //Obtained from the customer.//
• gtPI
• gtDual Signature
• gtOIMD
• gtThe digital envelope

50
Payment processing

• 2. Authorization-Related Information
• //generated by the merchant.//
• gtAn authorization block
• //consists of transaction ID signed with
  merchants private key and encrypted with one
  time symmeric key.//
• gtA digital envelope
• //Formed by encrypting one time key with the
  payment GTWs public key.//

51
Payment processing

• 3. Certificates
• The following certificates are sent
• gtCardholders certificate
• //to verify DS.//
• gtThe Merchants certificate
• //to verify merchants signatures.//
• gtThe merchants key-exchange cert.
• //needed in the payment GTWs response.//

52
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.

53
Payment processing

• Authorization Response
• 1. Authorization-related information
• gtAuthorization block signed by payment GTWs
  private key and encrypted with a one-time
  symmetric key.
• gtA digital envelop that contains the one time
  symmetric key (encrypted with merchants public
  key).

54
Payment processing

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

55
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.//

56
Payment processing

• Capture Request...
• gtPayment amount
• gtTransaction ID
• gtCapture token received earlier for this
  transaction.
• gtMerchants certificate.
• gtMerchants key-exchange certificate.

57
Payment processing

• Payment Capture
• gtThe Payment GTW verifies the information in the
  capture request.
• gtSends a clearing request to the issuer over the
  private payment network.
• gtThe funds are transferred to merchants account.
• gtThe GTW notifies the merchant of the payment in
  a Capture Response msg.

58
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)