1. CV G

2. Web Security  Web now widely used by business, government, individuals  but Internet & Web are vulnerable  have a variety of threats integrity integrity confidentiality confidentiality denial of service denial of service authentication authentication  need added security mechanisms

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

4. SSL Architecture

5.  SSL connection a transient, peer-to-peer, communications link a transient, peer-to-peer, communications link associated with 1 SSL session associated with 1 SSL session  SSL session an association between client & server an association between client & server created by the Handshake Protocol created by the Handshake Protocol define a set of cryptographic parameters define a set of cryptographic parameters may be shared by multiple SSL connections may be shared by multiple SSL connections

6.  Session state is defined by  Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.  Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.  Compression method: The algorithm used to compress data prior to encryption.  Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash_size.

7. Session State  Master secret: 48-byte secret shared between the client and server.  Is resumable: A flag indicating whether the session can be used to initiate new connections.

8. Connection State  Server and client random: Byte sequences that are chosen by the server and client for each connection.  Server write MAC secret: The secret key used in MAC operations on data sent by the server.  Client write MAC secret: The secret key used in MAC operations on data sent by the client.  Server write key: The conventional encryption key for data encrypted by the server and decrypted by the client.  Client write key: The conventional encryption key for data encrypted by the client and decrypted by the server.

9. SSL Record Protocol Services  message integrity using a MAC with shared secret key using a MAC with shared secret key similar to HMAC but with different padding similar to HMAC but with different padding  confidentiality using symmetric encryption with a shared secret key defined by Handshake Protocol 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 AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 message is compressed before encryption message is compressed before encryption

10. SSL Record Protocol Operation

11. SSL Record Protocol  Record Protocol takes an application message to be transmitted, fragments the data into blocks, compresses the data, applies MAC, encrypts, adds a header and transmits resulting unit in a TCP segment  Received data are decrypted, verified, decompressed and reassembled and delivered to higher level users

12. SSL Record Protocol  Fragmented into blocks of 2 14 bytes or less  Compression must be lossless and may not increase the content length by more than 1024 bytes  In SSLv3 no compression alg is specified so default compression alg is null MAC

13. MAC Computation  hash(MAC_write_secret || pad_2 ||  hash(MAC_write_secret || pad_1 || seq_num ||  SSLCompressed.type ||  SSLCompressed.length || SSLCompressed.fragment))

15. SSL Record Protocol  For stream encryption, the compressed message plus the MAC are encrypted.  For block encryption, padding may be added after the MAC prior to encryption.  An example is a plaintext (or  compressed text if compression is used) of 58 bytes, with a MAC of 20 bytes (using SHA-1), that is encrypted using a block length of 8 bytes (e.g., DES). With the padding.length byte, this yields a total of 79 bytes. To make the total an integer multiple of 8, one byte of padding is added.

16. SSL Record Protocol

17.  the compressed message plus the MAC are encrypted using symmetric encryption.

18. SSL Record Protocol  The final step of SSL Record Protocol processing is to prepend a header, consisting of the following fields:  Content Type (8 bits): The higher layer protocol used to process the enclosed fragment.  Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.

19. SSL Record Protocol  Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.  Compressed Length (16 bits): The length in bytes of the plaintext fragment (or compressed fragment if compression is used).  The maximum value is 2 14 + 2048.

20. SSL Record Format

21. SSL Change Cipher Spec Protocol  one of the 3 SSL specific protocols which use the SSL Record protocol  a single message  causes pending state to become current  hence updating the cipher suite in use

22. SSL Alert Protocol  conveys SSL-related alerts to peer entity  severity warning or fatalwarning or fatal  specific alert fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameterfatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknownwarning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown  compressed & encrypted like all SSL data

23. SSL Alert Protocol  unexpected_message: An inappropriate message was received.  bad_record_mac: An incorrect MAC was received.  decompression_failure: The decompression function received improper input (e.g., unable to decompress or decompress to greater than maximum allowable length).  handshake_failure: Sender was unable to negotiate an acceptable set of security parameters given the options available.  illegal_parameter: A field in a handshake message was out of range or inconsistent with other fields.  The remainder of the alerts are the following:

24. SSL Alert Protocol  close_notify: Notifies the recipient that the sender will not send any more messages on this connection. Each party is required  to send a close_notify alert before closing the write side of a connection.  no_certificate: May be sent in response to a certificate request if no appropriate certificate is available.  bad_certificate: A received certificate was corrupt (e.g., contained a signature that did not verify).

25. SSL Alert Protocol  unsupported_certificate: The type of the received certificate is not supported.  certificate_revoked: A certificate has been revoked by its signer.  certificate_expired: A certificate has expired.  certificate_unknown: Some other unspecified issue arose in processing the certificate, rendering it unacceptable.

26. SSL Alert Protocol

27. SSL Handshake Protocol  allows server & client to: authenticate each other authenticate each other to negotiate encryption & MAC algorithms to negotiate encryption & MAC algorithms to negotiate cryptographic keys to be used to negotiate cryptographic keys to be used  comprises a series of messages in phases 1. Establish Security Capabilities 2. Server Authentication and Key Exchange 3. Client Authentication and Key Exchange 4. Finish

28. SSL Handshake Protocol  The Handshake Protocol consists of a series of messages exchanged by client and server  Each message has three fields:  Type (1 byte): Indicates one of 10 messages. Table 17.2 lists the defined message types.  Length (3 bytes): The length of the message in bytes.  Content ( 0 bytes): The parameters associated with this message2

29. SSL Handshake Protocol

31. Phase 1 Establish Security Capabilities  Version: The highest SSL version understood by the client.  Random: A client-generated random structure, consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator. These values serve as nonces and are used during key exchange to prevent replay attacks.  Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to update the parameters of an existing connection or create a new connection on this session. A zero value indicates that the client wishes to establish a new connection on a new session.  CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec;  Compression Method: This is a list of the compression methods the client supports.

32. Phase 1 Establish Security Capabilities  RSA: The secret key is encrypted with the receiver's RSA public key. A public-key certificate for the receiver's key must be made available.  Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange in which the server's certificate contains the Diffie-Hellman public parameters signed by the certificate authority (CA). That is, the public-key certificate contains the Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman public key parameters either in a certificate, if client authentication is required, or in a key exchange message. This method results in a fixed secret key between two peers, based on the Diffie-Hellman calculation using the fixed public keys.  Ephemeral Diffie-Hellman: This technique is used to create ephemeral (temporary, one-time) secret keys. In this case, the Diffie-Hellman public keys are exchanged, signed using the sender's private RSA or DSS key. The receiver can use the corresponding public key to verify the signature. Certificates are used to authenticate the public keys. This would appear to be the most secure of the three Diffie-Hellman options because it results in a temporary, authenticated key.  Anonymous Diffie-Hellman: The base public Diffie-Hellman parameters to the other, with no authentication. This approach is vulnerable to man-in- the-middle attacks, in which the attacker conducts anonymous Diffie- Hellman with both parties.  Fortezza: The technique defined for the Fortezza scheme.

33. Phase 1 Establish Security Capabilities  CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza  MACAlgorithm: MD5 or SHA-1  CipherType: Stream or Block  IsExportable: True or False  HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes  Key Material: A sequence of bytes that contain data used in generating the write keys  IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC) encryption

34. Phase 2. Server Authentication and Key Exchange  The certificate message is required for any agreed-on key exchange method except anonymous Diffie-Hellman.  Next, a server_key_exchange message may be sent if it is required. It is not required in two instances: (1) The server has sent a certificate with fixed Diffie- Hellman parameters, or (2) RSA key exchange is to be used

35. Phase 2. Server Authentication and Key Exchange  The server_key_exchange message is needed for the following:  Anonymous Diffie-Hellman: The message content consists of the two global Diffie-Hellman values (a prime number and a primitive root of that number) plus the server's public Diffie- Hellman key  Ephemeral Diffie-Hellman: The message content includes the three Diffie-Hellman parameters provided for anonymous  Diffie-Hellman, plus a signature of those parameters.

36. Phase 2. Server Authentication and Key Exchange  RSA key exchange, in which the server is using RSA but has a signature-only RSA key( Public Key plus signature)  Fortezza  signature is created by taking the hash of a message and encrypting it with the sender's private key. In this case the hash is defined as

37. Phase 2. Server Authentication and Key Exchange  The certificate_request message includes two parameters: certificate_type and certificate_authorities  The certificate type indicates the  public-key algorithm and its use:  RSA, signature only  DSS, signature only  RSA for fixed Diffie-Hellman; in this case the signature is used only for authentication, by sending a certificate signed with RSA  DSS for fixed Diffie-Hellman; again, used only for authentication  RSA for ephemeral Diffie-Hellman  DSS for ephemeral Diffie-Hellman  Fortezza

38.  The final message in Phase 2, and one that is always required, is theserver_done message, which is sent by the server to indicate the end of the server hello and associated messages

39. Phase 3. Client Authentication and Key Exchange  the client should verify that the server provided a valid certificate if required and check that the server_hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server.

40. Phase 3. Client Authentication and Key Exchange  client_key_exchange message, which must be sent in this phase  The content of the message depends on the type of key exchange, as follows:  RSA: The client generates a 48-byte pre-master secret and encrypts with the public key from the server's certificate or temporary RSA key from a server_key_exchange message. Its use to compute a master secret is explained later.  Ephemeral or Anonymous Diffie-Hellman: The client's public Diffie-Hellman parameters are sent.  Fixed Diffie-Hellman: The client's public Diffie-Hellman parameters were sent in a certificate message, so the content of this message is null.  Fortezza: The client's Fortezza parameters are sent.

41. Phase 4  Finally, in this phase, the client may send a certificate_verify message to provide explicit verification of a client certificate.

42. Phase 4  This phase completes the setting up of a secure connection. The client sends a change_cipher_spec message and copies the pending  CipherSpec into the current CipherSpec  The client then immediately sends the finished message under the new algorithms, keys, and secrets.  The finished message verifies that the key exchange and authentication processes were successful. The content of the finished message is the concatenation of two hash values:

43. Finish

44. Master Secret  The shared master secret is a one-time 48-byte value (384 bits) generated for this session by means of secure key exchange.  The creation is in two stages. First, a pre_master_secret is exchanged. Second, the master_secret is calculated by both parties. For pre_master_secret exchange, there are two possibilities:  RSA: A 48-byte pre_master_secret is generated by the client, encrypted with the server's public RSA key, and sent to the server. The server decrypts the ciphertext using its private key to recover the pre_master_secret.  Diffie-Hellman: Both client and server generate a Diffie-Hellman public key. After these are exchanged, each side performs the Diffie-Hellman calculation to create the shared pre_master_secret.

46.  CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a  server write IV, which are generated from the master sercret in that order  The generation of the key material from the master secret uses the same format for generation of the master secret from the pre- master secret:

48. TLS (Transport Layer Security)  IETF standard RFC 2246 similar to SSLv3  with minor differences in record format version number in record format version number uses HMAC for MAC uses HMAC for MAC a pseudo-random function expands secrets a pseudo-random function expands secrets has additional alert codes has additional alert codes some changes in supported ciphers some changes in supported ciphers changes in certificate types & negotiations changes in certificate types & negotiations changes in crypto computations & padding changes in crypto computations & padding

49.  There are two differences between the SSLv3 and TLS MAC schemes: the actual algorithm and the scope of the MAC calculation  TLS makes use of the HMAC algorithm, HMAC is defined as  HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]] where  H = embedded hash function (for TLS, either MD5 or SHA-1)  M = message input to HMAC  K+ = secret key padded with zeros on the left so that the result is equal to the block length of the hash code(for MD5 and SHA-1, block length = 512 bits)  ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)  opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)  SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret key rather than being XORed with the secret key padded to the block length. The level of security should be about the same in both cases.

51.  TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for purposes of key generation or validation.  The objective is to make use of a relatively small shared secret value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on hash functions and MACs.  The PRF is based on the following data expansion function

53.  where A() is defined as  A(0) = seed  A(i) = HMAC_hash (secret, A(i - 1))  The data expansion function makes use of the HMAC algorithm, with either MD5 or SHA-1 as the underlying hash function.  As can be seen, P_hash can be iterated as many times as necessary to produce the required quantity of data. For example, if P_SHA-1 was used to generate 64 bytes of data, it would have to be iterated four times, producing 80 bytes of data, of which the last 16 would be discarded.  In this case, P_MD5 would also have to be iterated four times, producing exactly 64 bytes of data. Note that each iteration involves two executions of HMAC, each of which in turn involves two executions of the underlying hash algorithm

54.  To make PRF as secure as possible, it uses two hash algorithms in a way that should guarantee its security if either algorithm remains  secure. PRF is defined as

57.  PRF takes as input a secret value, an identifying label, and a seed value and produces an output of arbitrary length.  The output is created by splitting the secret value into two halves (S1 and S2) and performing P_hash on each half, using MD5 on one half and SHA-1 on the other half.  The two results are exclusive-ORed to produce the output; for this purpose, P_MD5 will generally have to be iterated more times than P_SHA-1 to produce an equal amount of data for input to the exclusive-OR function.

58.  Alert Codes  TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate. A number of additional codes are defined in TLS;  of these, the following are always fatal:  decryption_failed: A ciphertext decrypted in an invalid way; either it was not an even multiple of the block length or its padding  values, when checked, were incorrect.  record_overflow: A TLS record was received with a payload (ciphertext) whose length exceeds 214 + 2048 bytes, or the  ciphertext decrypted to a length of greater than 214 + 1024 bytes.  unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA  certificate could not be located or could not be matched with a known, trusted CA.  access_denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed with  the negotiation.

59.  decode_error: A message could not be decoded because a field was out of its specified range or the length of the message  was incorrect.  export_restriction: A negotiation not in compliance with export restrictions on key length was detected.  protocol_version: The protocol version the client attempted to negotiate is recognized but not supported.  insufficient_security: Returned instead of handshake_failure when a negotiation has failed specifically because the server  requires ciphers more secure than those supported by the client.  internal_error: An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue.  The remainder of the new alerts include the following:  decrypt_error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypt a key  exchange, or validate a finished message.

60.  user_canceled: This handshake is being canceled for some reason unrelated to a protocol failure.  no_renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial  handshaking. Either of these messages would normally result in renegotiation, but this alert indicates that the sender is not able  to renegotiate. This message is always a warning.

61.  Cipher Suites  There are several small differences between the cipher suites available under SSLv3 and under TLS:  Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of Fortezza.  Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found in SSLv3, with the  exception of Fortezza.

62.  Client Certificate Types  TLS defines the following certificate types to be requested in a certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, and  dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea.  Ephemeral Diffie-Hellman involves signing the Diffie- Hellman parameters with either RSA or DSS; for TLS, the rsa_sign and dss_sign  types are used for that function; a separate signing type is not needed to sign Diffie-Hellman parameters. TLS does not include the  Fortezza scheme.

63.  In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over handshake_messages. Recall that for SSLv3, the hash calculation also included the master secret and pads. These extra fields were felt to add no additional security.  As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared master_secret, the previous handshake messages, and a label that identifies client or server. The calculation is somewhat different. For TLS, we have

65. Cryptographic Computations  The pre_master_secret for TLS is calculated in the same way as in SSLv3. As in SSLv3, the master_secret in TLS is calculated as a hash function of the pre_master_secret and the two hello random numbers.  The form of the TLS calculation is different from that of SSLv3 and is defined as follows:

67.  The algorithm is performed until 48 bytes of pseudorandom output are produced. The calculation of the key block material (MAC secret keys, session encryption keys, and IVs) is defined as follows

69.  Padding  In SSL, the padding added prior to encryption of user data is the minimum amount required so that the total size of the data to be  encrypted is a multiple of the cipher's block length. In TLS, the padding can be any amount that results in a total that is a multiple of the  cipher's block length, up to a maximum of 255 bytes. For example, if the plaintext (or compressed text if compression is used) plus MAC  plus padding.length byte is 79 bytes long, then the padding length, in bytes, can be 1, 9, 17, and so on, up to 249. A variable padding  length may be used to frustrate attacks based on an analysis of the lengths of exchanged messages.

70. Secure Electronic Transaction (SET)

71. Secure Electronic Transaction (SET)  Developed by Visa and MasterCard  Designed to protect credit card transactions  Confidentiality: all messages encrypted  Trust: all parties must have digital certificates  Privacy: information made available only when and where necessary

72. Participants in the SET System

73. SET Business 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

74. SMUCSE 5349/7349 SET Business Requirements (cont ’ d)  Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction  Create a protocol that neither depends on transport security mechanisms nor prevents their use  Facilitate and encourage interoperability among software and network providers

75. SMUCSE 5349/7349 SET Transactions

76. SMUCSE 5349/7349 SET Transactions  The customer opens an account with a card issuer. MasterCard, Visa, etc. MasterCard, Visa, etc.  The customer receives a X.509 V3 certificate signed by a bank. X.509 V3 X.509 V3  A merchant who accepts a certain brand of card must possess two X.509 V3 certificates. One for signing & one for key exchange One for signing & one for key exchange  The customer places an order for a product or service with a merchant.  The merchant sends a copy of its certificate for verification.

77. SMUCSE 5349/7349 SET Transactions  The customer sends order and payment information to the merchant.  The merchant requests payment authorization from the payment gateway prior to shipment.  The merchant confirms order to the customer.  The merchant provides the goods or service to the customer.  The merchant requests payment from the payment gateway.

78. SMUCSE 5349/7349 Key Technologies of SET  Confidentiality of information: DES  Integrity of data: RSA digital signatures with SHA-1 hash codes  Cardholder account authentication: X.509v3 digital certificates with RSA signatures  Merchant authentication: X.509v3 digital certificates with RSA signatures  Privacy: separation of order and payment information using dual signatures

79. SMUCSE 5349/7349 Dual Signatures  Links two messages securely but allows only one party to read each. MESSAGE 1 DIGEST 1 NEW DIGEST HASH 1 & 2 WITH SHA MESSAGE 2 DIGEST 2 CONCATENATE DIGESTS TOGETHER HASH WITH SHA TO CREATE NEW DIGEST DUAL SIGNATURE PRIVATE KEY ENCRYPT NEW DIGEST WITH SIGNER’S PRIVATE KEY

80. SMUCSE 5349/7349 Dual Signature for SET  Concept: Link Two Messages Intended for Two Different Receivers: Order Information (OI): Customer to Merchant Order Information (OI): Customer to Merchant Payment Information (PI): Customer to Bank Payment Information (PI): Customer to Bank  Goal: Limit Information to A “Need-to-Know” Basis: Merchant does not need credit card number. Merchant does not need credit card number. Bank does not need details of customer order. Bank does not need details of customer order. Afford the customer extra protection in terms of privacy by keeping these items separate. Afford the customer extra protection in terms of privacy by keeping these items separate.  This link is needed to prove that payment is intended for this order and not some other one.

81. SMUCSE 5349/7349 Why Dual Signature?  Suppose that customers send the merchant two messages: The signed order information (OI).The signed order information (OI). The signed payment information (PI).The signed payment information (PI). In addition, the merchant passes the payment information (PI) to the bank.In addition, the merchant passes the payment information (PI) to the bank.  If the merchant can capture another order information (OI) from this customer, the merchant could claim this order goes with the payment information (PI) rather than the original.

82. SMUCSE 5349/7349 Dual Signature Operation  The operation for dual signature is as follows: Take the hash (SHA-1) of the payment and order information. These two hash values are concatenated [H(PI) || H(OI)] and then the result is hashed. C ustomer encrypts the final hash with a private key creating the dual signature. DS = E KRC [ H(H(PI) || H(OI)) ]

83. SMUCSE 5349/7349 DS Verification by Merchant  The merchant has the public key of the customer obtained from the customer’s certificate.  Now, the merchant can compute two values: H(PIMD || H(OI)) D KUC [DS]  Should be equal!

84. SMUCSE 5349/7349 DS Verification by Bank  The bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer’s public key, then the bank can compute the following: H(H(PI) || OIMD) D KUC [ DS ]

85. SMUCSE 5349/7349 What did we accomplish?  The merchant has received OI and verified the signature.  The bank has received PI and verified the signature.  The customer has linked the OI and PI and can prove the linkage.

86. SMUCSE 5349/7349 SET Supported Transactions  card holder registration  merchant registration  purchase request  payment authorization  payment capture  certificate query  purchase inquiry  purchase notification  sale transaction  authorization reversal  capture reversal  credit reversal

87. SMUCSE 5349/7349 Purchase Request  Browsing, Selecting, and Ordering is Done  Purchasing Involves 4 Messages: Initiate Request Initiate Request Initiate Response Initiate Response Purchase Request Purchase Request Purchase Response Purchase Response

88. SMUCSE 5349/7349 Purchase Request: Initiate Request  Basic Requirements: Cardholder Must Have Copy of Certificates for Merchant and Payment Gateway Cardholder Must Have Copy of Certificates for Merchant and Payment Gateway  Customer Requests the Certificates in the Initiate Request Message to Merchant Brand of Credit Card Brand of Credit Card ID Assigned to this Request/response pair by customer ID Assigned to this Request/response pair by customer Nonce Nonce

89. SMUCSE 5349/7349 Purchase Request: Initiate Response  Merchant Generates a Response Signs with Private Signature Key Signs with Private Signature Key Include Customer Nonce Include Customer Nonce Include Merchant Nonce (Returned in Next Message) Include Merchant Nonce (Returned in Next Message) Transaction ID for Purchase Transaction Transaction ID for Purchase Transaction  In Addition … Merchant’s Signature Certificate Merchant’s Signature Certificate Payment Gateway’s Key Exchange Certificate Payment Gateway’s Key Exchange Certificate

90. SMUCSE 5349/7349 Purchase Request: Purchase Request  Cardholder Verifies Two Certificates Using Their CAs and Creates the OI and PI.  Message Includes: Purchase-related Information Purchase-related Information Order-related Information Order-related Information Cardholder Certificate Cardholder Certificate

91. SMUCSE 5349/7349 Purchase Request  The cardholder generates a one-time symmetric encryption key, KS,

92. SMUCSE 5349/7349 Merchant Verifies Purchase Request  When the merchant receives the Purchase Request message, it performs the following actions: Verify the cardholder certificates by means of its CA signatures. Verify the cardholder certificates by means of its CA signatures. Verifies the dual signature using the customer’s public key signature. Verifies the dual signature using the customer’s public key signature.

93. SMUCSE 5349/7349 Merchant Verification (cont’d) Processes the order and forwards the payment information to the payment gateway for authorization. Processes the order and forwards the payment information to the payment gateway for authorization. Sends a purchase response to the cardholder. Sends a purchase response to the cardholder.

94. SMUCSE 5349/7349 Purchase Response Message  Message that Acknowledges the Order and References Corresponding Transaction Number  Block is Signed by Merchant Using its Private Key Signed by Merchant Using its Private Key Block and Signature Are Sent to Customer Along with Merchant’s Signature Certificate Block and Signature Are Sent to Customer Along with Merchant’s Signature Certificate  Upon Reception Verifies Merchant Certificate Verifies Merchant Certificate Verifies Signature on Response Block Verifies Signature on Response Block Takes the Appropriate Action Takes the Appropriate Action

95. SMUCSE 5349/7349 Payment Process  The payment process is broken down into two steps: Payment authorization Payment authorization Payment capture Payment capture

96. SMUCSE 5349/7349 Payment Authorization  The merchant sends an authorization request message to the payment gateway consisting of the following: Purchase-related information Purchase-related information PIPI Dual signature calculated over the PI & OI and signed with customer’s private key.Dual signature calculated over the PI & OI and signed with customer’s private key. The OI message digest (OIMD)The OI message digest (OIMD) The digital envelopThe digital envelop Authorization-related information Authorization-related information Certificates Certificates

97. SMUCSE 5349/7349 Payment Authorization (cont’d) Authorization-related information Authorization-related information An authorization block including:An authorization block including: A transaction ID A transaction ID Signed with merchant’s private key Signed with merchant’s private key Encrypted one-time session key Encrypted one-time session key Certificates Certificates Cardholder’s signature key certificateCardholder’s signature key certificate Merchant’s signature key certificateMerchant’s signature key certificate Merchant’s key exchange certificateMerchant’s key exchange certificate

98. SMUCSE 5349/7349 Payment: Payment Gateway  Verify All Certificates  Decrypt Authorization Block Digital Envelope to Obtain Symmetric Key and Decrypt Block  Verify Merchant Signature on Authorization Block  Decrypt Payment Block Digital Envelope to Obtain Symmetric Key and Decrypt Block  Verify Dual Signature on Payment Block  Verify Received Transaction ID Received from Merchant Matches PI Received from Customer  Request and Receive Issuer Authorization

99. SMUCSE 5349/7349 Authorization Response  Authorization Response Message Authorization-related Information Authorization-related Information Capture Token Information Capture Token Information Certificate Certificate

100. SMUCSE 5349/7349 SET Overhead Simple purchase transaction:  Four messages between merchant and customer  Two messages between merchant and payment gateway  6 digital signatures  9 RSA encryption/decryption cycles  4 DES encryption/decryption cycles  4 certificate verifications Scaling:  Multiple servers need copies of all certificates

101. Secure Electronic Transactions (SET)  open encryption & security specification  to protect Internet credit card transactions  developed in 1996 by Mastercard, Visa etc  not a payment system  rather a set of security protocols & formats secure communications amongst parties secure communications amongst parties trust from use of X.509v3 certificates trust from use of X.509v3 certificates privacy by restricted info to those who need it privacy by restricted info to those who need it

102. SET Components

103. SET Transaction 1. customer opens account 2. customer receives a certificate 3. merchants have their own certificates 4. customer places an order 5. merchant is verified 6. order and payment are sent 7. merchant requests payment authorization 8. merchant confirms order 9. merchant provides goods or service 10. merchant requests payment

104. Dual Signature  customer creates dual messages order information (OI) for merchant order information (OI) for merchant payment information (PI) for bank payment information (PI) for bank  neither party needs details of other  but must know they are linked  use a dual signature for this signed concatenated hashes of OI & PI signed concatenated hashes of OI & PI DS=E(PR c, [H(H(PI)||H(OI))])

105. SET Purchase Request  SET purchase request exchange consists of four messages 1. Initiate Request - get certificates 2. Initiate Response - signed response 3. Purchase Request - of OI & PI 4. Purchase Response - ack order

106. Purchase Request – Customer

107. Purchase Request – Merchant 1. verifies cardholder certificates using CA sigs 2. verifies dual signature using customer's public signature key to ensure order has not been tampered with in transit & that it was signed using cardholder's private signature key 3. processes order and forwards the payment information to the payment gateway for authorization (described later) 4. sends a purchase response to cardholder

108. Purchase Request – Merchant

109. Payment Gateway Authorization 1. verifies all certificates 2. decrypts digital envelope of authorization block to obtain symmetric key & then decrypts authorization block 3. verifies merchant's signature on authorization block 4. decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment block 5. verifies dual signature on payment block 6. verifies that transaction ID received from merchant matches that in PI received (indirectly) from customer 7. requests & receives an authorization from issuer 8. sends authorization response back to merchant

110. Payment Capture  merchant sends payment gateway a payment capture request  gateway checks request  then causes funds to be transferred to merchants account  notifies merchant using capture response

111. Summary  have considered: need for web security need for web security SSL/TLS transport layer security protocols SSL/TLS transport layer security protocols SET secure credit card payment protocols SET secure credit card payment protocols