1. Henric Johnson1 Chapter 8 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

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

3. Henric Johnson3 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 corporation’s entire computer complex.

4. Henric Johnson4 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.

5. Henric Johnson5 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.)

6. Henric Johnson6 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).

7. Henric Johnson7 Security facilities in the TCP/IP protocol stack

8. Henric Johnson8 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.

9. Henric Johnson9 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).

10. Henric Johnson10 SSL Architecture

11. Henric Johnson11 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. Henric Johnson12 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.

13. Henric Johnson13 SSL Record Protocol Operation

14. Henric Johnson14 SSL Record Format

15. Henric Johnson15 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. Henric Johnson16 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. Henric Johnson17 Handshake Protocol Action

18. Henric Johnson18 An SSL Session 1. Negotiation of cryptographic parameters //Two computers probably don’t know each other’s 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. Henric Johnson19 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

20. Henric Johnson20 1. Hello and Negotiate Parameters… 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

21. Henric Johnson21 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 CA’s public key to decrypt the certificate and obtains server’s public key and verifies the server.

22. Henric Johnson22 2. Key Agreement and Exchange The client generates a 48- byte random value (called pre-master secret), encrypts it with server’s public RSA key, and sends it to server. The server decrypts this message and generates six keys. DES secret Key Secret key for message integrity Secret key to initialize the cipher.

23. Henric Johnson23 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. DES secret Key Secret key for message integrity Secret key to initialize the cipher.

24. Henric Johnson24 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 server’s private key.//

25. Henric Johnson25 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. Henric Johnson26 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.

27. Henric Johnson27 Transport Layer Security (TLS) The same record format as the SSL record format. Defined in RFC 2246. Similar to SSLv3. Differences: –version number For current version of TLS, the major version is 3 and minor version is 1. –message authentication code TLS differs in actual algorithm and scope of the MAC calculation.

28. Henric Johnson28 Transport Layer Security (TLS) >TLS uses HMAC algorithm. (difference is how padding bits are used.) >TLS also covers the field ”TLSCompressed.version” field in MAC calculation. –pseudorandom function TLS makes use of a different function. (objective is to expand secret into blocks of data for purpose of key generation.)

29. Henric Johnson29 Transport Layer Security (TLS) - alert codes >TLS does not support ”no_certificate”. >In addition, TLS supports some additional alerts. –cipher suites >TLS does not support ”Fortezza” method of key exchange. >TLS does not support ”Fortezza” method of encryption.

30. Henric Johnson30 Transport Layer Security (TLS) - client certificate types >TLS does not support ”Fortezza”. –certificate_verify and finished message >In TLS, for certificate_cerify message, MD5 and SHA-1 hashes are calculated only over handshake_messages. (In SSL, hash calculation also includes the master secret and pads.)

31. Henric Johnson31 Transport Layer Security (TLS) >For finished_message, the calculation of hash is based on a different function. - cryptographic computations >Master secret computation in TLS uses different computation. (uses the same parameters as in SSL) –Padding >Can be of any size (<=255 bytes) so that the total length is a multiple of cipher’s block length.

32. Henric Johnson32 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).

33. Henric Johnson33 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.

34. Henric Johnson34 SET Overview Key Features of SET: –Confidentiality of information –Integrity of data –Cardholder account authentication –Merchant authentication

35. Henric Johnson35 SET Participants

36. Henric Johnson36 Sequence of events for transactions 1.The customer opens an account. 2.The customer receives a certificate. (contains customer’s 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.)

37. Henric Johnson37 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. > Customer’s 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.

38. Henric Johnson38 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.

39. Henric Johnson39 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.

40. Henric Johnson40 Dual Signature… >Merchant need not know about CC#. >Bank need not know the details of customer’s 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.//

41. Henric Johnson41 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))]

42. Henric Johnson42 Dual Signature

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

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

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

46. Henric Johnson46 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.//

47. Henric Johnson47 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 Ks by the public key of payment GTW.

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

49. Henric Johnson49 Payment processing Cardholder sends Purchase Request

50. Henric Johnson50 Payment Processing The merchant processes the message in the following way: 1. Verifies cardholder certificate with the CA’s key. 2. Verifies the dual signature. Insures: >Message integrity >Message authentication.

51. Henric Johnson51 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.

52. Henric Johnson52 Payment processing Merchant Verifies Customer Purchase Request

53. Henric Johnson53 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

54. Henric Johnson54 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 >The digital envelope

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

56. Henric Johnson56 Payment processing 3. Certificates: The following certificates are sent: >Cardholder’s certificate //to verify DS.// >The Merchant’s certificate //to verify merchant’s signatures.// >The merchant’s key-exchange cert. //for the payment GTW’s response.//

57. Henric Johnson57 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.

58. Henric Johnson58 Payment processing Authorization Response: 1. Authorization-related information: >Authorization block signed by payment GTW’s private key and encrypted with a one-time symmetric key. >A digital envelop that contains the one time symmetric key (encrypted with merchant’s public key).

59. Henric Johnson59 Payment processing Authorization Response: 2. Capture token information: //Used to effect the payment later.// >A signed, encrypted capture token. //Returned with payment request later.// >A digital envelope. //contains the one time symmetric key encrypted with merchant’s public key.//

60. Henric Johnson60 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.//

61. Henric Johnson61 Payment processing –Capture Request... >Payment amount >Transaction ID >Capture token received earlier for this transaction. >Merchant’s certificate. >Merchant’s key-exchange certificate.

62. Henric Johnson62 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 merchant’s account. >The GTW notifies the merchant of the payment in a Capture Response msg.

63. Henric Johnson63 Recommended Reading and WEB sites 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 Visa Electronic Commerce Site SETCo (documents and glossary of terms)