lecture: security hutter/ stephan secure electronic transactions (set) developed 1996 by mastercard...

Lecture: Security Hutter/ Stephan

Secure Electronic Transactions (SET)

• Developed 1996 by Mastercard and VISA• Originally:

– Secure Electronic Payment Protocol (SEPP) (MasterCard, Netscape, IBM)

– Secure Transaction Technology (STT)(VISA, Microsoft)

• Only a payment protocol (no online shopping, price negotiation, payment-method-selection, etc.)

• Specification consists of 3 parts– Business Descripion (80 pages)– Programmers Guide (629 pages)– Formal Protocol Description (262 pages)


Buisiness Requirements

• Confidentiality of payment information and of order information

• Integrity of all transmitted data• Authentication of cardholder as a legitimate user of a

branded payment card• Authentication that a merchant can accept branded payment

cards• Best security practices to protect legitimate parties• Protocol independent of transport security mechanisms• Interoperability among software and network providers


Payment System Participants

• Cardholder:customer uses payment cards• Issuer: financial institution establishing an

(bank) account with the cardholder• Merchant: offers goods via the net• Acquirer: financial institution establishing an

account with the merchant.• Payment gateway: device operated by the aquirer

processing merchant payment messages

• Brand: payment card brands


Encryption used in SET


Dual Signatures

To 1st receiver:Message 1 + Hash value 2+ Dual signature

To 2nd. receiver:Message 2 + Hash value 1+ Dual signature

Message 1

Dies ist ein voellig bloedsinniger Textden man nicht lesen sollte, weil erkeinen Sinn ergibt und nur hier steht,damit was darin steht....................

Message 1

Dies ist ein voellig bloedsinniger Textden man nicht lesen sollte, weil erkeinen Sinn ergibt und nur hier steht,damit was darin steht....................

Hash value 10F363B..

Hash value 10F363B..

Dualsignature

Dualsignature

privat key

Message 2

Noch ein voellig bloedsinniger Textden man nicht lesen sollte, weil erkeinen Sinn ergibt und nur hier steht,damit was darin steht....................

Message 2

Noch ein voellig bloedsinniger Textden man nicht lesen sollte, weil erkeinen Sinn ergibt und nur hier steht,damit was darin steht....................

Hash value 2726AE8FB..

Hash value 2726AE8FB..

Common hash value83AE7F55E...

Common hash value83AE7F55E...


Certificate Issuance

• Participants authenticate themselves using private keys.

• Public keys are certified by trusted third parties.(X.509 version 3)


Phases of Credit Card Payment

CardHolder

Financial NetworkFinancial Network

Card IssuerPaymentGateway

Merchant

Non-SET Non-SET

SET

SET3. Purchase Request

4. Purchase Response

1. Init Request

2. Init Response

7. Inquiry Request

8. Inquiry Response

6. Auth. Response5. Auth. Request 10. Payment Capture Response

9. Payment Capture Request


Purchase Request (Overview)


Some Notions Used in SET Protocol (I)

Cryptographic keys:

teeth indicate owner PB : public keys, PV: private keys

Digital signature (Letter indicates owner)

Dual Signature (Letter indicates owner)

Certificates: M indicates merchant certificates CA indicates creation by Certification Authority Diamond/Key denote signature and key-exchange certificates


Some Notions Used in SET Protocol (II)

Symmetric key

Payment card denoting account information

Protected data, e.g. account information in digital envelope

Digiatal envelope containing a symmetric keyand account information encrypted with the public key of the gateway

Message PI and cardholders signature certificateDual signed by the cardholder and encrypted with the symmetric key (2) mentioned above


Initialization of Request

Cardholder is „ready to pay“:

{IDBrand, IDC,Trans, ChallC}

Merchant is ready:

{ { IDTrans, Date, ChallC, ChallM } Sig(M), CAM, CAPG }


Purchase Order – Payment Instructions (PI)

Intended for the payment gateway (bank)

CardData

CC#ExpiryPANnoncePINnonce

HashOrder

DescriptionAmountODSalt

PIData

IDTrans

AmountCardDataHash(Order)

Extra StrongEncryption

OIData

...

PI

PIDataDual SigDual Sig.

Encrypt PK(PG)


Purchase Order - Order Information

OIData

IDTransIDBrandDateChallCChallMODsalt

PIData

...

OI

OIDataDualSig

{Hash H2}Sig( C)

Hash(PIData)

Hash(OIData)

Intended for the merchant


Processing Purchase Request

Verification of:

Certificate and

Dual Signature


Purchase Response

Merchant answers: {IDTrans, Compl.code, [Results], ChallC}SIG(M)

Compl.code: authorization or capturing completed?

Result: authorization and capturing codes


Purchase Response – Final Step


Payment Authorization

Verification that cardholder has credit for purchase


Authentication Request

Order

DescriptionAmountODSalt

AuthReq

IDTrans

DateAuthReqAmtHash(Order)Hash(OIData)SalesIndMerchants DetailsCardholder billing addrss

PI

PIDataDual Sig

Hash

From Purchase Request


Authentication – Payment Gateway

Issues:

Decrypt and Authenticatevarious parts of message

Check consistency ofmessage parts usingthe dual signatures

Contact issuer of cardholder for clearance


Authentication – Response from Payment Gateway

Create capturetoken only readableby the gateway

Link the token to the cardholder


Authentication – Final Step

Verify message ofthe payment gateway

Store encrypted capture tokenfor later user


Payment Capture

Request payment to be transfered to merchant‘s account


Payment Capture


Formal Analysis of SET ?

• Only parts of SET have been formally analysed(e.g. by L. Paulson, D. Bolignano, ...)

lecture: security hutter/ stephan secure electronic transactions (set) developed 1996 by mastercard...

Documents

merchant slide

payment capture request

set slide

pages slide

payment card brands

payment capture response

dual signature message

pkpg slide