"Web Security Secure Electronic Transaction"
Web Security: Secure Electronic Transaction Cunsheng Ding HKUST, Hong Kong, CHINA Secure Electronic Transactions • An application-layer security mechanism, consisting of a set of protcols. • Protect credit card transaction on the Internet. • Companies involved: – MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign • Not a payment system. • Official documentation with 971 pages – SSLv3 specification with 63 pages only – TLS specification with 80 pages C. Ding CSIT571 L25 2 SET Services • Provides a secure communication channel in a transaction. • Provides tust by the use of X.509v3 digital certificates. • Ensures privacy. C. Ding CSIT571 L25 3 SET Overview • Key Features of SET: – Confidentiality of information – Integrity of data – Cardholder account authentication – Merchant authentication C. Ding CSIT571 L25 4 SET Participants • Cardholder, Merchant • Issuer: cardholder‛s bank • Acquirer: Merchant‛s bank • Payment Gateway: Operated by the Acquirer for payment processing. • Certificate Authority (CA): A trusted authority that issues X.509v3 public-key certificates for cardholders, merchants, and payment gateways. C. Ding CSIT571 L25 5 SET Participants C. Ding CSIT571 L25 6 Steps for transactions (1) • Customer opens a credit card account and receives a digital certificate signed by the bank. It also establishes a relationship, guaranteed by the bank, between the customer‛s key pair and his/her credit card. • Merchant has his own two certificates for two public keys: one for signing messages, one for key exchange. C. Ding CSIT571 L25 7 Steps for transactions (2) • Customer places an order • Merchant is verified by Customer • Order and payment are sent to the merchant • Merchant requests payment authorization • Merchant confirms order and provides goods or service • Merchant requests payment C. Ding CSIT571 L25 8 Dual Signature • Purpose is to link two messages that are intended for two different recipients • Merchant does not need to know customer‛s credit card number • Bank does not need to know customer‛s order details • But both items must be linked to resolve any disputes if required C. Ding CSIT571 L25 9 Construction of Dual Signature PIMD PI H (c) Kd Dual POMD Signature || H D OIMD OI H PIMD = PI message digest PI = Payment Information OIMD = OI message digest OI = Order Information POMD = Payment order message digest H = Hash function(SHA1) D = Decryption (c) || = Concatenation Kd = Customer’s private signature key C. Ding CSIT571 L25 10 Phase 1 1.1 Initial request (ID, nonce) 1.3 Merchant Certificate, initial response 1.2 Verify merchant 1.5 Verify Customer Order & Payment Inform. 1.4 C. Ding CSIT571 L25 11 Initial Request and Response Initial Request Initial Response • A signed response: • The brand (kind, grade) – The nonce from the of the credit card the customer, another nonce for the customer to customer is using. return in the next • An ID assigned to this message. request/response pair. – A transaction ID. • A nonce used to ensure • Merchant‛s signature timeliness. certificate. • Payment gateway‛s key exchange certificate. C. Ding CSIT571 L25 12 Customer Verifies Merchant • The Customer then uses the Merchant‛s public signature key to verify the signature of the merchant. Remark: The detailed verification depends on the underlying (signing, verification) algorithms C. Ding CSIT571 L25 13 Purchase request Request message PI Passed on by + merchant to payment Digital Envelope E gateway + + PIMD Dual Signature Ks + OI Received by + merchant OIMD E + Dual Signature (b) + Cardholder certificate K e Ks = Temporary symmetric key (b) Ke = Merchant Bank’s public keyexchange key E = Encryption (RSA for asymmetric; DES for symmetric) C. Ding CSIT571 L25 14 Payment/Order Related Information • Payment-related • Order-related • The PI: payment Inf • The OI • The dual signature • The dual signature • The OIMD • The PIMD – OI message digest – PI message digest • The digital envelope – it contains secret key C. Ding CSIT571 L25 15 Verification of Purchase Request and Customer by Merchant: Pictorial Request message E = Encryption (RSA) (c) Passed on by Ke = Customer’s public key + merchant to payment Digital Envelope gateway + POMD PIMD || H + OI Compare H + OIMD Dual Signature E + POMD Cardholder certificate (c) Ke C. Ding CSIT571 L25 16 Phase 2 Authorization Request C. Ding CSIT571 L25 17 Authorization Request: Merchant ==> Payment Gateway • Payment-related • Authorization-related • The PI: payment Inf • An authorization block: • The dual signature – transaction ID, signed with merchant‛s private • The OIMD key, and encrypted with a – OI message digest session key generated by • The digital envelope the merchant. • A digital envelope: – session key encrypted Cardholder‛s certificate with the gateway‛s public key. C. Ding CSIT571 L25 18 The follow-up by the Gateway • Verify all certificates. • Decrypts the digital envelop of the authorization block to obtain the session key and then decrypts the authorization block. • Verifies the merchant‛s signature on the authorization block. • Decrypts the digital envelope of the payment block to obtain the symmetric key and then decrypt the payment block. • Verifies that the transaction ID received from the merchant matches that in the PI received (indirectly) from the customer. C. Ding CSIT571 L25 19 Phase 3 Requests and receives an authorization from the issuer C. Ding CSIT571 L25 20 Phase 4 Authorization Response C. Ding CSIT571 L25 21 Authorization Response • Authorization-Related Information: – authorization block, signed with gateway‛s private key and encrypted with a session key generated by the Gateway. – An envelope, the session key encrypted with the merchant‛s public key. • Capture token information: – This information will be used to effect payment later. – It has the same form as the authorization-related information above. • Certificate: The gateway‛s signature key certificate. C. Ding CSIT571 L25 22 Phases 5 and 6 • Phase 5: • Phase 6: Payment – Merchant delivers capture goods after getting – involves all parties. the authorization – Details omitted. response from the payment gateway. C. Ding CSIT571 L25 23 Security • SET has been developed to make trading via the Internet secure. • It ensures: – That both parties are "genuine". – That the customer is protected against bogus companies and misuse of payment cards. – That companies are protected against bogus customers. – That alterations cannot be made to orders without being discovered. – That orders can only be read by the customer and the company concerned. – That payment information can only be read by the acquirer and the customer. C. Ding CSIT571 L25 24 References • W. Stallings, Cryptography and Network Security 2/e. • S. Macgregor, Web Security & Commerce. Cambridge, MA: O‛Reilly and Associates, 1997. C. Ding CSIT571 L25 25