12 — Protocol

SPS — Secure Payment System Protocol

A three-party protocol for online payment that separates order info from card info — protecting each party from the other.

Actors

Notation legend
{X}_PubY = X encrypted with Y's public key (only Y reads) Sig_privX(H(X)) = X's signature over hash of X (proves origin + integrity) ‖ = concatenation

Sequence at a glance

C ── order ──▶ M ── invoice ──▶ C ── dual envelope ──▶ PG ── auth ──▶ M ── goods ──▶ C ① ② ③ ④ ⑤

Algorithm — 5 steps

C → M : Order Request. Encrypts order with M's public key and signs it.
C → M : { order_info }_PubM , Sig_privC( H(order_info) )
M → C : Payment Request. Verifies C's signature, returns merchant ID, transaction ID, amount — signed by M.
C → PG : Dual Envelope. Card info for PG only, order info for M only. M cannot read the card; PG cannot read the order.
C → PG : { card_info }_PubPG , { order_info }_PubM , Sig_privC( H(card_info ‖ order_info) )
The joint hash binds card+order so neither can be swapped or replayed separately.
PG → M : Authorisation. Decrypts card info with private key, checks funds with issuer, returns signed token (plus capture receipt to C).
M → C : Confirmation + Delivery. Verifies PG's signature, then ships goods.

Property table

PropertyProvided By
Card secrecy from MerchantCard encrypted with Pub_PG only
Order secrecy from PGOrder encrypted with Pub_M only
Customer authenticitySignature with privC
Merchant authenticityPayment request signed by M; auth token signed by PG
Non-repudiationSignatures on every step
Integrity + anti-replaySigned hashes; transaction ID must be fresh/unique
Lineage
Dual-envelope = the SET (Secure Electronic Transaction) pattern, ancestor of 3-D Secure / gateway flows. Core idea: separate the data each party is allowed to see.
Exam one-liner: Card→PG only, order→M only, joint signed hash binds them, PG's signed token releases goods.
← Prev
11 · MITM
Next →
13 · Access Control Models