Secure Transaction Technology
                                             
                                             
                                             
                         BFOX@MICROSOFT.COM
                       BRIANBEC@MICROSOFT.COM

========

Design Goals

 o  Transaction privacy, integrity.
     - End-to-End encryption, signed RSA key-exchange keys
     - signatures where appropriate, signed RSA signature keys
     - MACs where appropriate

 o  Authentication of ALL participants
     - Card Brands sign their member banks
          * Issuers sign cardholders
          * Acquirers sign merchants

 o  Credentials as proxies for bank relationships
     - STT Credentials are not X.509 certificates: Cannot be used for
       generic identity.

 o  Non-repudiation via consumer signatures
     - one signature on Goods and Services Order encrypted to merchant
     - another signature on Payment Instruction encrypted to merchant's
       acquirer bank

 o  Leverage existing payment infrastructure
     - reflect existing business models and relationships
     - exploit existing backends, e.g., settlement

 o  IDEMPOTENT protocol
     - the effect of any message is independent of the number of times 
       the message is sent
     - implement with globally unique Transaction IDs on every message.

 o  Replay protection via globally unique TransID=92s
     - applications may access TransID's and key a replay database with
       them

 o  Require only reliable message transport
     - STT messages could be sent in email, HTTP, FTP, on floppies, etc.
     - Do not require secure channels
     - encrypt all messages

 o  Self-contained
     - do not assume a Certification Authority
     - do not assume SSL, SHTTP, Secure Courier or other external
       products or vaporware
     - close all transaction loops

========

STT Message Circuits

 (1) Register request from consumer to issuing bank
     - consumer gets issuer credential via MIME
 (2) Register response (credential) from issuing bank to consumer
 (3) Order (GSO) and charge slip (PI) from consumer to merchant
     - GSO encrypted to merchant
     - PI encrypted to acquirer: merchant forwards
     - dual-signature and TransID linkage
 (4) Charge slip (PI) from merchant to acquiring bank/processor
     - merchant forwards PI in an AuthRequest
 (5) Authorization from acquiring bank/processor to merchant
 (6) Receipt from merchant to consumer
     - no channel from acquirer to consumer
 (7) and (8) Acquiring bank/processor and merchant settle
     - out of band

 Visa is connected through the back end of both the issuing bank and 
 the acquiring bank/processor (cloud)

========

Goods and Services Order (GSO)

 o  Details (arbitrary "Stationery Store" Order Form) [MAC only]

 The following are signed and encrypted to the Merchant:

 o  ChargSlip text
 o  TransID
 o  Shipping Address
 o  Merchant Contact Info.
 o  Authorized Amount (ISO 4217)
 o  Authorization Terms
 o  Cardholder Credentials

========

Payment Instruction (PI)

 The following are signed and encrypted to the Acquirer:

 o  Merchant ID
 o  TransID of the GSO
 o  Authorized Amount and Terms
 o  Charge Slip Text
 o  Shipping Address (optional)
 o  Cardholder Credentials

========

Cardholder Credential

 o  Serial #
 o  Brand ID
 o  Cardholder Name, Address, Email, etc.
 o  Hash (acct#)
 o  Cardholder GUID
    either / or
     - RSA Signature Key
     - RSA Key Exchange Key
          We use separate credentials for signature and key exchange 
          because Acquirer does not need client's key-exchange key.
 o  Expiration Date
 o  Per-Bank Policy Fields
 o  Bank or Visa Signature

========

Merchant Credential

 o  Serial #
 o  Name, Address, Email, etc.
 o  Brand Accepted ID
 o  Acquirer BIN
 o  Merchant Key Exchange Key (for encrypting GSO)
 o  Acquirer Key Exchange Key (for encrypting PI)
 o  Merchant Signature Key (for checking receipt)
 o  Per-Bank Policy Fields
 o  Bank or Visa Signature

========

STT Trust Forests

 Visa:
   issuers
     cardholders
   acquirers
     merchants

 (e.g.) MasterCard:
   issuers
     cardholders
   acquirers
     merchants

 Brand X:
   issuers
     cardholders
   acquirers
     merchants

 ...

========

Multisignatures

 Party 1 (merchant) sees doc G.  Party 2 (acquirer) sees doc P.  1 must 
 verify signature on P without seeing P and 2 must verify signature on 
 G without seeing G.

 Solution: Consumer signs H( H(G) | H(P) ), where
   HASH of G = H(G)
   HASH of P = H(P)
   CONCAT = |
   =

   S(G,P) = E_V_CMR [ H( H(G) | H(P) ) ]
   Encrypt w/ Private Sig. Key = E_V_CMR

 Party 1 receives: G|H(P)|S(G,P)|Signature credential
 Party 2 receives: P|H(G)|S(G,P)|Signature credential plus H(G) from 
   Party 1, preventing consumer's sending phonies:  P|H(G')|S(G',P) to 
   2 and G|H(P')|S(G,P') to 1.  As an extra check, 2 could send 1 an 
   independent hash of P.
 
 Each party can verify the signature on the group of documents, but only 
 sees the documents he needs to see.

 Obviously extensible to any number of documents.

========

RSA Envelope for the PI and Consumer Credential Request

 k = DES key for CMR ID req'd by issuing bank (per-bank policy)
 d = ID data
 c = Credit card data (160 bits)
 R = 808-bit random pad
 E_k_(d) =def= e = DES-encrypted data
 H(e|"1") =def= h_1 = HASH of e concat "1"
 H(e|"2") =def= h_2
 ...
 H(e|"7") =def= h_7
 z={h,|h_2|...|h_7]_1024 = low 1024 bits of CAT of HASHes = recoverable 
 noise vector for diffusing bits in the envelope

 Envelope contents  =  E_public_key(k|c|r) xor z
 
 Receiver recomputes z given DES-encrypted data following envelope, 
 xors with envelope, RSA-decrypts envelope.

 This is our variant of Bellare-Rogaway

 Card# in the envelope for (presumably) higher security due to greater 
 key length.