Visa/MasterCard Secure Electronic Transactions (SET) Specification of the Official method of achieving network payment via Credit Cards Announced in February 1996 Supported by Visa, MasterCard, GTE, IBM, Microsoft, Netscape, SAIC, Terisa, Verisign and American Express Autumn 2004 Trinity College, Dublin 1 Scope of SET Protocols Motivated by the large amount of unsecured credit-card based transactions on the Internet Network payments treated in a similar way to Mail Order/Telephone Order (MOTO) transactions SET applies only to the front end of payment - no need to change the back end SET only addresses Payment - other protocols for shopping, payment method selection etc. will be developed by others Autumn 2004 Trinity College, Dublin 2 Page 1
SET Applicability Non-SET Financial Network Non-SET Card Issuer Payment Gateway Card Holder SET SET Autumn 2004 Trinity College, Dublin 3 SET Identities All parties to a SET transaction have Names (X.500 Distinguished Names) and zero or more public/private key pairs Certificate ::= SIGNED { SEQUENCE { version [0]Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL } Identities are linked to keys using X.509v3 certificates Autumn 2004 Trinity College, Dublin 4 Page 2
SET Certification Hierarchy Root Certification Authority Brand Certification Authority Geo-Political Authority (optional) Cardholder CA CA Payment CA Cardholder Payment Gateway Autumn 2004 Trinity College, Dublin 5 Example of SET Named Entities c=us o= SET Root cn= CA Identifier 0000 Card Holder Root of SET CA Hierarchy c=ie o= European Express Card ou= Bank of Ireland ou= Fun Card cn= 7891275648394585746576 Payment Gateway c=us o= European Express Card ou= Wells Fargo Bank cn= 432157.5 c=us o= European Express Card ou= Wells Fargo Bank ou= Wolf a Pizza cn= 25:426:7256 Autumn 2004 Trinity College, Dublin 6 Page 3
SET Payment Environment Autumn 2004 Trinity College, Dublin 7 SET Message Flow CardHolder Payment Gateway InitReq InitRes PReq PRes InqReq InqRes Anytime after PReq AuthReq AuthRes CapReq CapRes Autumn 2004 Trinity College, Dublin 8 Page 4
Financial Data Card data: number, expiry date Extra strong encryption (Direct RSA) Protects card from DES cracking machines Non-financial data Normal Encryption DES Encrypt (56 bit) Card Data DES Key Extra Strong Encryption RSA Encrypt (1024 bit) Autumn 2004 Trinity College, Dublin 9 Payment Initialization InitReq/InitRes NO Encryption used Cardholder browses, selects goods, approves order form, chooses bankcard Initialization achieves: Obtains merchant and acquirer certificates Indicate bankcard to be used Associate transaction ID with purchase Autumn 2004 Trinity College, Dublin 10 Page 5
InitReq/InitRes InitReq: {BrandID,[Thumbs],LID_C,Chall_C} Cardholder InitRes: {TransID,Date,Chall_C,Chall_M}Sig M,C A,C M replies (InitRes): - + Acquirer certificates - Globally unique transaction ID - Challenge variable and date proves freshness of response Autumn 2004 Trinity College, Dublin 11 Cardholder Payment (PReq) Purchase Order: PReq/PRes PReq is a two part message: OrderInfo (OI) : links to order description Payment Instructions (PI): amount, card data, IDs Dual signature links the order with the payment PReq: OI PI Cardholder Note: Only financial data encrypted! Autumn 2004 Trinity College, Dublin 12 Page 6
OrderInfo (OI) OI Data OI TransID BrandID Date Chall_C Chall_M ODsalt (nonce)......... PI Data H(OIData) H(PIData) Hash OIData DualSig H2 Sign {H2}Sig C Dual Signature process Note: Autumn No Encryption 2004 Trinity College, Dublin 13 Payment Instructions (PI) CardData CC# Expiry PANNonce PINonce Order Description Amount ODsalt (nonce) Extra Strong Encryption (RSA) Hash PI Data TransID Amount CardData H(Order) OI Data... Dual Sig. process Autumn 2004... Trinity College, Dublin 14 PI PI Data Dual Sig Encrypt: PK A Page 7
Receives PReq Store PI to forward to acquirer Verify cardholder certificate by traversing the trust chain to the root key Verify dual signature Obtain authorization from acquirer Send purchase response to cardholder to confirm order If authorization is delayed, PRes gives cardholder please inquire later message Autumn 2004 Trinity College, Dublin 15 Purchase Response (PRes) CompletionCode: Status of transaction e.g., authorization complete Results: Authorization/capture codes for transaction Cardholder PRes TransID CompletionCode [Results] Chall_C No Encryption Sig M Autumn 2004 Trinity College, Dublin 16 Page 8
Authorization AuthReq/AuthRes Verify cardholder has credit for purchase Contains PI from PReq Contains H(Order) showing agreement with cardholder (in PI) on purchase amount. Order details not given to acquirer Signed and encrypted by merchant Combined Auth and Capture = Sales Transaction (SalesInd) Ship goods on good AuthRes Autumn 2004 Trinity College, Dublin 17 AuthReq From PReq Order Description Amount ODSalt Hash AuthReq TransID Date AuthReqAmt H(Order) H(OIData) [Thumbs] SalesInd details Cardholder billing address To Acquirer PI Signed: Sig M Encrypt: PK A Autumn 2004 Trinity College, Dublin 18 Page 9
Acquirer receives AuthReq Decrypts AuthReq Verify merchant signature Decrypt PI from cardholder Verify dual signature in PI Extract card data from PI Ensure consistency between PI and AuthReq Verify cardholder and merchant agree on purchase: H(Order) equal in PI and AuthReq Autumn 2004 Trinity College, Dublin 19 Acquirer receives AuthReq Obtain authorization through financial network Create AuthRes with Capture Token {{AuthReq}Sig M }PK A {{AuthRes}Sig A }PK M Acquirer Existing Financial Network Issuer Issuer Autumn 2004 Trinity College, Dublin 20 Page 10
AuthRes To AuthRes TransID Date AuthAmt AuthCode Capture Token CapAmt CapCode Signed: Sig A Encrypt: PK M Auth + Capture together Capture Token AuthAmt Capture Data (IDs) Token Nonce Sig A E: PK A (acquirer s eyes only) Autumn 2004 Trinity College, Dublin 21 Capture Complete payment of authorized transactions Performed later, with several capture tokens Tokens from several AuthResponses Capture Token = proof of amount owed CapReq CapToken CapToken... Signed: Sig M Encrypted: PK A Acquirer 2. Clearing Existing 3. {{Cap Res}Sig A } PK M Financial Network Autumn 2004 Trinity College, Dublin 22 Issuer Issuer Page 11
SET Message Flow CardHolder Payment Gateway InitReq InitRes PReq PRes InqReq InqRes Anytime after PReq AuthReq AuthRes CapReq CapRes Autumn 2004 Trinity College, Dublin 23 Helper Applications (Temporary) 3. OD, Amount, Cards accepted, URLs Existing Web Web Browser 1. Submit order 2. MIME_Version:1.0 Content-type: application/set Content-transfer-encoding: binary Web Web Server Server SET SET SET 5. SET Payment Protocol SET Cardholder Application Application 4. Order OK? Autumn 2004 Trinity College, Dublin 24 Page 12
Integrating SET Web Browser Internal SET support Browsing Shopping protocol SET Payment Web Server Internal SET support SET API Autumn 2004 Trinity College, Dublin 25 Autumn 2004 Trinity College, Dublin 26 Page 13
SET Specification SET Version 1.0, 31st May 97 Book 1: Business Description Book 2: Programmer s Guide Book 3: Protocol Description Available from: Visa, http://www.visa.com Mastercard, http://www.mastercard.com SetCo, http://www.setco.org» compliance testing/approval process Autumn 2004 Trinity College, Dublin 27 SET Software Products by a number of vendors IBM, VeriSign, Hitachi, Baltimore, Trintech, etc. Covered by the US Unrestricted Export License Exemption Except to Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria Real-value transactions First transaction carried out Dec 31st 1996 by IBM, Danish Payment Systems (PBS) and Europay, in Denmark Many pilot projects in progress around the world Autumn 2004 Trinity College, Dublin 28 Page 14