Secure Electronic Payment Protocols

1. The Problem

E-payments travel over an open, insecure network between buyer, merchant, gateway and bank. Requirements:

Requirement	Meaning
Confidentiality	card/data unreadable to eavesdroppers
Integrity	payment data not altered in transit
Authentication	parties are who they claim to be
Non-repudiation	a party cannot deny the transaction
Card-number shielding	merchant should not necessarily see the full card number

Four classic protocol families: SHTTP, SSL/TLS, SET, and 3-D Secure (plus digital envelope/digital signature primitives).

2. SHTTP (Secure HTTP)

An early IETF extension of HTTP (RFC 2660) that adds message-level security inside the application protocol: encryption, digital signatures and MACs applied per HTTP message.
Operates at the application layer, above HTTP; mutually negotiated modes per message header.
Historically competed with SSL; lost — SSL/TLS (transport layer) won because it is protocol-agnostic. Largely obsolete.

3. SSL / TLS (the universal layer — HTTP + SSL = HTTPS)

  TCP/IP
    ^
    |  +--------------------------+
    |  |  Application (HTTP, FTP) |
    |  +--------------------------+
    |  | SSL / TLS record layer   |  <- encryption + MAC per record
    |  |  Handshake: negotiate    |
    |  |  cipher suite, exchange  |
    |  |  keys, verify certificate|
    |  +--------------------------+

Handshake outline

ClientHello — supported cipher suites, random number.
ServerHello + server certificate (X.509, signed by a CA); optional client certificate for mutual auth.
Key exchange (RSA or (EC)DHE) → pre-master secret → both sides derive session keys.
Finished messages verified with MACs → encrypted application data flows.

Provides: confidentiality (symmetric cipher, e.g. AES-GCM), server authentication (certificate chain to a trusted CA), integrity (HMAC/AEAD).
Limitation: does not guarantee non-repudiation of a payment, and the merchant sees the card number — hence SET/3DS were designed.

Digital envelope = the classic SHTTP/SSL idea:

\text{Envelope} = \{K_{session}\} \text{ encrypted with recipient's public key } + \{M\} \text{ encrypted with } K_{session}

i.e. public-key crypto protects a randomly generated symmetric key; the symmetric key encrypts the bulk data — fast and scalable.

4. SET — Secure Electronic Transaction (Visa/MasterCard, 1996-97)

A payment-specific protocol designed so the merchant never sees the credit-card number and the bank never sees the order contents — using dual signatures.

 BUYER                      MERCHANT                        PAYMENT GATEWAY / BANK
  | order info (OI)  ------->|                                |
  | payment info (PI) -------|  --(encapsulated, gateway     |
  | certificate-signed dual  |    public key encrypted)------>| authorises card
  | signature attached       |                                |   |  approve/decline
  |<-- authorisation --------+<-------------------------------+---+

Dual signature — buyer signs the hash of (hash(OI) + hash(PI)):

DS = E_{K_{buyer}^{-}}\big[\,H(\,H(OI)\,\|\,H(PI)\,)\,\big]

Merchant can verify that the PI belongs to this order without seeing PI (it gets only H(PI)).
Gateway verifies the payment without seeing OI.
Both get integrity + non-repudiation with privacy separation.

Components: certificates (X.509) issued by CAs to cardholder, merchant and gateway; cardholder's wallet software; purchase/authorisation/capture message flow.
Why SET failed commercially: heavy infrastructure (wallets, certificates for every consumer), complex, slow — superseded by SSL/TLS + 3-D Secure.

5. 3-D Secure (Verified by Visa / MasterCard SecureCode / RuPay Protect)

Modern, domain-based improvement over SET:

3 domains: Issuer domain (bank), Acquirer domain (merchant's bank + gateway), Interoperability domain (card network directory).
During checkout the merchant redirects the cardholder to the issuer's ACS (Access Control Server) page.
Cardholder authenticates (OTP, password, biometric) → issuer returns an auth result to the merchant.
Liability for fraud shifts to the issuer when authentication succeeds.

Advantages: merchant never sees/needs the OTP; issuer controls authentication; works with any bank app. Drawback: extra redirect, friction, phishing-style look-alike pages.

6. Comparison Table

Protocol	Layer	Card number to merchant	Non-repudiation	Status
SHTTP	Application (message)	visible	yes (signatures)	obsolete
SSL/TLS	Transport (between hops)	visible to merchant	weak	universal standard
SET	Application (payment-specific)	hidden (dual signature)	strong (certificates)	failed commercially
3-D Secure	Domain-based redirect	hidden from merchant's payment page	strong (issuer auth)	current standard

7. Supporting Cryptographic Primitives

Symmetric encryption (AES) — bulk data, fast.
Public-key / asymmetric (RSA, ECC) — key exchange, digital envelopes.
Hash + digital signature (SHA-256 + RSA/DSA/ECDSA) — integrity + non-repudiation.
Certificates (X.509) & PKI — bind public keys to identities via CAs; certificate chains, revocation (CRL/OCSP).
MAC/HMAC — integrity when only a shared key exists.

8. Exam Points

Explain SSL/TLS handshake with a diagram and list what it provides — 10 marks (very frequent).
Explain SET architecture and the dual signature with formula/diagram — 10 marks.
Compare SHTTP, SSL, SET and 3-D Secure — 5-7 marks.
Short notes: digital envelope, digital signature, certificates/PKI — 5 marks each.

Secure Electronic Payment Protocols