December 1, 1995
Copyright© 1995 Visa International Service Association and Microsoft Corporation. All rights reserved. Permission to copy the material contained herein is granted subject to the conditions that (i) any copy or re-publication must bear this legend in full, and (ii) that none of the copyright holders shall have any responsibility or liability whatsoever to any party arising from the publication of the material contained herein.
Visa and Microsoft hereby grant to any party a royalty-free, worldwide, perpetual license to use the material contained herein to make, use, and sell products and services that conform to the Secure Transaction Technology Specifications contained herein. The authors of this documentation make no representation or warranty regarding whether any particular physical implementation of any part of these Specifications does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or intellectual property of third parties, and thus any person who implements any part of these Specifications should consult an intellectual property attorney before any such implementation. The following Specifications include public key encryption technology, which is the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether their activities require a license to any patents, including, but not limited to, patents on public key encryption technology. Visa International Service Association and Microsoft Corporation shall not be liable for any party's infringement of any intellectual property right.
STT is designed to handle secure payment with bank cards over insecure data transports like the Internet. The protocol requires only reliable message transport, such as TCP. It features strong, export-approved DES encryption of financial information, direct RSA (TM) encryption of bank card account numbers, and mandatory authentication of all participants, including clients, for reduced financial risk. [1]
STT is independent of other authentication and privacy protocols. An implementation of STT is being developed by Microsoft, and an authentication trust hierarchy will be operated by VISA. Implementation plans and schedules are not covered in this document. This document is a terse technical companion to a much more thorough exposition of STT for general audiences.
This document presents protocols and message formats for version 1.0 of STT. Protocols are the conditions under which messages are sent. Message formats are presented as they appear "on the wire". The purpose of this document is to facilitate implementation of interoperable STT applications. The target audience is software developers. Section 9 presents the protocols and earlier sections cover formats. All formats are little- endian, favoring performance on Intel® x86 and compatible platforms, which make up the majority of the installed base of personal computers. All objects are byte-packed: pad bytes are explicitly denoted.
Encrypted messages are shown in their plaintext forms. A separate section explains STT's use of bulk data symmetric-key cryptography. STT uses RSA public-key cryptography (PKC) to protect bank card numbers and bulk data encryption keys and for digital signatures. Message-creating software should construct plaintext messages, then sign and encrypt them, in that order, as described in detail below. Message-reading software should decrypt, verify signatures, then parse plaintext.
STT Version 1 character string data is ANSI. STT may support Unicode™ or other multibyte character sets in future versions.
All such data should be melded through a mixing and compression function, such as MD5 or SHA, so that correlations from run to run or boot to boot will be destroyed. XOR is an inadequate mixing function, since it allows cancellations if correlations in pseudo- random noise are present. STT-compliant software shall seed pseudorandom number generators with physically random information and shall frequently update the seed with physically random information. STT-compliant software shall also use seeds of at least 160 bits. See Internet RFC 1750 for general information on randomness.
The remainder of this section gives an informal description of STT's CPN transfer syntax. The formal description is in the appendix.
Objects are written in with the type first, followed by an optional literal value and an optional symbolic name that might be used in expository text or later definitions to refer to the object. So, for example, a BYTE called bFoo is written as follows:
(BYTE bFoo)A BYTE object not needing a name would be written
(BYTE)or, where unambiguous, as:
BYTE
The syntax also supports specification of ordered collections or sequences of objects. On the wire, these objects appear in time order; in memory, they appear as byte-packed concatenations. So, for example, A BYTE called bFoo followed by a CString called customerName and DWORD called dwCount is written as follows:
((BYTE bFoo)
(CString customerName)
(DWORD dwCount))
If these objects did not need names, the same sequence would be
written:
((BYTE) (CString) (DWORD))Note that:
(BYTE CString (DWORD))would be ambiguous, since it could mean a BYTE named CString rather than an anonymous BYTE followed by an anonymous CString. The ambiguity could be resolved by checking names against the dictionary of known types, but a syntactic solution is preferable.
A fixed-length array or stream of N objects of type X has type X[N], a pseudo-C notation. So, for example, the type of an array of BYTEs of length cb is written:
BYTE[cb]The optional value field is written as a numeric or string constant, as in:
(WORD 0x1234)or:
(BYTE[4] "RSA1")denoting a BYTE array holding a character string, or in:
(BYTE[4] 0x23 rgbFoo)denoting a BYTE array named rgbFoo and filled with repetitions of 0x23.
Complexity is built by defining new types. So, for example, the expression:
(define-type BOGEY
((BYTE bFoo)
(CString customerName)
(DWORD dwCount)))
gives the name BOGEY to the sequence shown. In later expressions,
BOGEY may be used as a stand-in expression for the sequence,
shortening the notation and removing redundancy with its
concomitant possibility for error. Define-type also admits some
automated consistency checks on the notation.
Comments inline to the Cambridge Notation are preceded by semicolons.
BYTE: 8-bit unsigned integer.
WORD: 16-bit unsigned integer, low-order byte first on the wire (or, in memory, at lower byte address). STT writes the number of bytes in a WORD as the symbolic constant cbW, which equals 2.
DWORD: 32-bit unsigned integer, low-order WORD first. STT writes the number of bytes in a DWORD as the symbolic constant cbDW, which equals 4.
QWORD: 64-bit unsigned integer, low DWORD followed by high DWORD.
DECFLOAT: Decimal floating point. This atom type is reserved for future versions of STT.
RSA1KE: RSA encryption of a 128-byte quantity under a 1024-bit modulus.
RSA.75KE: RSA encryption of a 96-byte quantity under a 768-bit modulus.
RSA.5KE: RSA encryption of a 64-byte quantity under a 512-bit modulus.
CString: character count followed by string data (ANSI chars). Character count is contained in either a byte, 3 bytes, or 7 bytes, as follows:
1. If the first byte is between 0 and 0xFE, inclusive, this is
the character count.
2. If the first byte is 0xFF and the next word is between 0 and
0xFFFD, inclusive, then the WORD contains the character
count.
3. Finally, if the first byte is 0xFF and the next word is
0xFFFF, then the following DWORD contains the character
count.
4. RESERVATION: In the future, STT may support Unicode CStrings.
These are denoted by (BYTE 0xFF), followed by (WORD 0xFFFE),
followed by a Unicode character count -- not a byte count --
as encoded in 1, 2, and 3 above.
The following is a brief synopsis of one GUID-generating algorithm. More details may be found in the citations below.
If your machine contains a network card with a 48-bit IEEE network card hardware address, this globally unique address will be incorporated into the GUID. Otherwise a random pseudo-address is created from machine state information that is extremely likely to have been affected by truly random events, especially human interaction with devices and the file system. See the Note on Randomness in the Introduction for more.
The following excerpts on net hardware addresses are taken from
Project 802: Local and Metropolitan Area Network Standard
Draft Standard P802.1A/D10, 1 April 1990,
prepared by the IEEE 802.1.
--- begin quote -----------------------------------------------
Page 18: "5. Universal Addresses and Protocol Identifiers
The IEEE makes it possible for organizations to employ unique
individual LAN MAC addresses, group addresses, and protocol
identifiers. It does so by assigning organizationally unique
identifiers, which are 24 bits in length. [...] Though the
organizationally unique identifiers are 24 bits in length, their
true address space is 22 bits. The first bit can be set to 1 or 0
depending on the application. The second bit for all assignments
is zero. The remaining 22 bits [...] result in 2**22
(approximately 4 million identifiers).
[...] The multicast bit is the least significant bit of the
first octet, A.
[...] 5.1 Organizationally Unique Identifier
[...] The organizationally unique identifier is 24 bits in length
and its bit pattern is shown below. Organizationally unique
identifiers are assigned as 24 bit values with both values (0,1)
being assigned to the first bit and the second bit being set to 0
indicates that the assignment is universal. Organizationally unique
identifiers with the second bit set to 1 are locally assigned and
have no relationship to the IEEE-assigned values (as described
herein).
The organizationally unique identifier is defined to be:
1st bit 24th bit
| |
a b c d e ....... x y
| |
| Always set to zero
Bit can be set to 0 or 1 depending on application
[...] 5.2 48-Bit Universal LAN Mac Addresses
[...] A 48 bit universal address consists of two parts. The
first 24 bits correspond to the organizationally unique
identifier as assigned by the IEEE except that the assignee may
set the first bit to 1 for group addresses or set it to 0 for
individual addresses. The second part, comprising the remaining
24 bits, is administered locally by the assignee.
[...]
octet:
0 1 2 3 4 5
0011 0101 0111 1011 0001 0010 0000 0000 0000 0000 0000 0001
|
First bit transmitted on the LAN medium. (Also the
Individual/Group Address Bit.) The hexadecimal representation is:
AC-DE-48-00-00-80
The Individual/Group (I/G) Address Bit (1st bit of octet 0) is
used to identify the destination address either as an individual
or as a group address. If the Individual/Group Address Bit is 0,
it indicates that the address field contains an individual
address. If this bit is 1, the address field contains a group
address that identifies one or more (or all) stations connected
to the LAN. The all-stations broadcast address is a special, pre-
defined group address of all 1's.
The Universally or Locally Administered Address Bit (2nd bit of
octet 0) is the bit directly following the I/G bit. This bit
indicates whether the address has been assigned by a local or
universal administrator. Universally administered addresses have
this bit set to 0. If this bit is set to 1, the entire address
(i.e.: 48 bits) has been locally administered."
--- end quote ------------------------------------------------
Also, see the following:
DEC / HP, Network Computing Architecture Remote Procedure Call Run Time Extensions Specification, Version OSF TX1.0.11, Steven Miller, July 23, 1992. (Chapter 10 describes UUID allocation.)
A GUID has the following wire format:
(define-type GUID
((DWORD data1)
(WORD data2)
(WORD data3)
(BYTE[8] data4)))
Transaction-initiating messages sent by an entity are stamped with its current GUID preceded by a QWORD containing a non- decreasing serial number. The composite of a GUID and a qwSerial is called an XID, for transaction ID. Responses to the transaction-initiating message contain the XID of the corresponding initiating message.
STT-compliant applications must guarantee that the serial number never decrease for a given GUID, and that the GUID is generated by validated software when STT software is installed on a machine. Implementations must guarantee that the serial number is non- decreasing for each GUID, and, thus, that no two transactions have the same XID.
STT-compliant applications shall guarantee idempotency of the protocol by examining XIDs. For example, a payment server will reject attempts to replay payment requests from merchants. It will detect these attempts by examining the XID of the payment request and XID of the embedded payment instruction, separately signed and encrypted by the cardholder.
An XID has the following wire format:
(define-type XID
((QWORD SerialNumber) ;Per-Guid, non-decreasing
(GUID InstallationGuid)))
(define-type CMoney
((WORD CountryCode) ;ISO 4217 Country Code.
(QWORD Amount))) ;fixed-point with four decimals
(define-type DATE
(QWORD))
Messages are composed of TLVs to support forward and backward compatibility. Old software will be able to read new messages because it will tags it does not recognize. New software will continue to read old messages since tags are never removed from the TLV tag space documented below.
The full notation for a TLV is:
(<Tag> <Length> <Value>)
where <Tag> is replaced with a member of the Tag Space
documented below, <Length> is a byte count for the
<Value>, and <Value> is replaced with actual notations of
the kind shown so far and to follow. This denotes a TLV with the
indicated Tag, Length, and Value. There are many cases where the
Length equals the sum of the lengths of a set of nested data
objects, and the Value equals a concatenation of the nested objects.
The shorthand:
(<Tag> <Value>)
denotes this case. Since TLV notations tend to become deeply
nested, it is sometimes convenient to give the value field a
symbolic name for documentation purposes. The name is written
in a comment on the same line as the tag:
(<Tag> ;My Value's name is "Foo"
<Value>) ;This is the definition of "Foo"
Note that this differs from the notation for Atoms and Composites,
where a symbolic name is enclosed with the type in parentheses.
In all these cases, a description of the Value contents is
carried out in embedded Cambridge Notation.
In some cases, the Value is an undifferentiated byte stream. The notation may be further streamlined in these cases by omitting the Value altogether, resulting in merely
(<Tag>)
On the wire, all TLVs appear as follows:
((DWORD dwTag)
(DWORD dwLength)
(BYTE[dwLength] rgbValue))
The notation:
(<Tag> <Value>)
suffices for TVs, with a possible name as a comment.
On the wire, TVs appear as follows:
((DWORD dwTag)
(BYTE[knownLength] rgbValue))
* Root signature key: 2048 bits (256 bytes)
* All other signature keys: 1024 bits (128 bytes)
* Cardholder Credential Server,
Merchant Credential Server,
Payment Server key-exchange keys: 1024 bits (128 bytes)
* Merchant key-exchange key: 768 bits ( 96 bytes)
* Client key-exchange key: 512 bits ( 64 bytes)
Thus, there are four key formats, distinguished by key size. On
the wire, RSA keys appear as follows:
((BYTE[4] "RSA1")
(DWORD cbitsMod) ;bit length of modulus
(DWORD publicexp) ;public exponent
(BYTE[cbitsMod/8] modulus)) ;modulus data, little-endian.
The complete RSA Key block typess have the following symbolic
names (which are used frequently in the rest of this document)
and sizes, including the 12 bytes of overhead documented above:
* RSA2K: 268 B (cbitsMod = 2048)
* RSA1K: 140 B (cbitsMod = 1024)
* RSA.75K: 108 B (cbitsMod = 768)
* RSA.5K: 76 B (cbitsMod = 512)
It is therefore useful to add the following composites to the type
system:
(define-type RSA-common
((BYTE[4] "RSA1")
(DWORD cbitsMod)
(DWORD publicExp)))
(define-type RSA2K
(RSA-common (BYTE[256] modulus)))
(define-type RSA1K
(RSA-common (BYTE[128] modulus)))
(define-type RSA.75K
(RSA-common (BYTE [96] modulus)))
(define-type RSA.5K
(RSA-common (BYTE [64] modulus)))
There is some similarity to RC4Keys, documented further below. It would be possible to document a common abstraction, but it was deemed less confusing to document DESKeys and RC4Keys separately, despite the common elements.
The first 12 bytes are header data in the clear. Following the header data is a 128-byte, RSA-encrypted DEKB, and then an 8 byte initialization vector. A DEKB is a DESK diffused with Optimal Asymmetric Encryption Padding (OAEP), a method first described by Bellare and Rogaway [2] for diffusing the contents of RSA envelopes to forestall information-theoretic attacks.
All DESKeys are the same length since they are all encrypted with RSA1K keys. All DESKeys are 12+128+8=148 bytes long, with 12 bytes of fixed overhead, 128 bytes of RSA-encrypted DEKB, and 8 bytes containing an initialization vector.
First, we describe DESK, then DEKB, and finally DESKey
(define-type DESK ;total length = 119
((DWORD 8 cbKeyProper)
(BYTE[8] rgbKey) ;the DES key proper
(DWORD 32 cbBankCardNumber) ;actually, up to 32 bytes
(BYTE[32] BCN) ;bank card number
(BYTE[71] 0 padding)))
Every DESK is 119 bytes long because the RSA modulus for
encrypting DES keys in STT is always 128 bytes = 1024 bits and
nine bytes are needed for OAEP and overflow protection.
Each byte of rgbKey contains 7 bits of key data + 1 check bit in position 0, as specified in FIPS 81.
The byte length of the bank card number data must be less than or equal to 32. The data format is application-dependent.
(define-type DEKB
((BYTE[119] DiffusedDESK)
(BYTE[8] rgbHx)
(BYTE 0 padding))) ;prevents overflow when
;exponentiating
To reverse the process, recovering a DESK from a DEKB, do the
following:
Finally, the entire DESKey format can be described:
(define-type DESKey
((BYTE 1 keyBlockType)
(BYTE 2 keyVersion)
(WORD 334 reservedWord)
(DWORD 0x0000CC01 algorithmIdentifier)
(DWORD 0x00014800 keyExchAlgIdOfRSA)
(RSA1KE DEKB) ;RSA-encrypted DEKB
(BYTE[8] InitVector))) ;DES IV, as in FIPS 81
The notation (RSA1KE DEKB) refers to the RSA encryption of a
DEKB. That is, a DEKB raised to the power of the public key
modulo the RSA modulus found in an instance of RSA1K (all DESKeys
are encrypted with RSA1Ks). To recover DEKB, one must know the
modulus and the secret, RSA private key. Given DEKB, one must
further undo OAEP as described to recover a DESK.
There is some similarity to the RSA Envelope format for DES keys and bank card account numbers, documented above. The first 12 bytes of an RC4Key are header data in the clear. Following the header data is an RSA-encrypted REKB and three bytes of salt. A REKB, in the RC4 context, contains a diffused RC4K, via OAEP, exactly as with DESKeys. An RC4K is an RC4 Plaintext Key Block. REKBs come in three lengths: 128, 96, and 64 bytes, equaling the size of the corresponding RSA modulus. Since nine bytes of the REKB are needed for OAEP and overflow protection, just as with DESKeys, RC4Ks come in the following sizes: 119, 87, and 55. Including the 12 bytes of overhead preceding and the three bytes of salt following the REKB, the total lengths of RC4 Keys are 143, 111, or 79 bytes. The size of an RC4Key is known implicitly, by the context of the allowed RSA key length used for its final encryption. First, types for the three kinds of RC4Ks and REKBs are defined, then the types of the three lengths of RC4Keys are defined.
(define-type LengthAndKey
((DWORD 5) ;STT RC4 keys are always 5 bytes long
(BYTE[5] rgbKeyProper)))
(define-type RC4K1K (LengthAndKey (BYTE[110] 0 padding)))
(define-type RC4K.75K (LengthAndKey (BYTE[78] 0 padding)))
(define-type RC4K.5K (LengthAndKey (BYTE[46] 0 padding)))
(define-type OAEPkeyPad
((BYTE[8] rgbHx) ;obscured OAEP key
(BYTE 0 padding))) ;RSA overflow protection
(define-type REKB1K ((BYTE[119] DiffusedRC4K) (OAEPkeyPad)))
(define-type REKB.75K ((BYTE[87] DiffusedRC4K) (OAEPkeyPad)))
(define-type REKB.5K ((BYTE[55] DiffusedRC4K) (OAEPkeyPad)))
Each of these REKBs contains an rgbEKey and an OAEPkeyPad.
The process for creating a REKB from a RC4K is analogous to the
process for creating a DEKB from a DESK. The process is:
Finally, there are three kinds of RC4Key:
(define-type RC4KeyCommon
((BYTE 1 keyBlockType)
(BYTE 2 keyVersion)
(WORD 16718 reservedWord)
(DWORD 0x0000D001 algorithmIdentifier)
(DWORD 0x00014800 keyExchAlgIdOfRSA)))
(define-type RC4Key1K ;total length = 143
((RC4KeyCommon com)
(RSA1KE REKB1K) ;RSA-encrypted REKB
(BYTE[3] rgbSalt))) ;Key salt
(define-type RC4Key.75K ;total length = 111
((RC4KeyCommon com)
(RSA.75KE REKB.75K) ;RSA-encrypted REKB
(BYTE[3] rgbSalt))) ;Key salt
(define-type RC4Key.5K ;total length = 79
((RC4KeyCommon com)
(RSA.5KE REKB.5K) ;RSA-encrypted REKB
(BYTE[3] rgbSalt))) ;Key salt
The notation (RSA... REKB) refers to the RSA encryption of a
REKB. That is, a REKB raised to the power of the public key
modulo the RSA modulus found in an RSA1K, RSA.75K, or RSA.5K.
To recover REKB, one must know the modulus and the secret, RSA
private key. Given REKB, one must further undo OAEP as
described.
The final three bytes of any RC4Key are key salt used to complete an 8-byte RC4 key. The salt is in the clear. Its purpose is to foil quick table lookup attacks that may be feasible with a 40-bit key.
TLVs and TVs are easily differentiated and parsed (without lookup tables) simply by checking the 31st bit in a tag: If on, then the least significant WORD of the tag includes the encoded length of the entity. This saves considerable message overhead for commonly used, fixed-length values. If the encoded length is -1, then the entity is a CString and obeys the explicit CString coding convention defined earlier in this document.
The Version tag is a special case for backwards compatibility: it doesn't look like a TV (e.g., 31st bit isn't set), but is a TV with an implicit length of 4.
(TLV_NULL 0x00000000)
(TV_DUALHASH 0x40210028) // for dual signature
(TV_HASH 0x40220014) // hash value
(TV_ROOTSIGNATURE 0x40230100) // root signature
(TV_SIGNATURE 0x40240080) // signature on Cred
(TLV_SIGNED_DATA 0x00000021) // signed data
(TLV_DATA 0x00000022) // binary data
(TLV_ENCRYPTED_DATA 0x00000023) // encrypted data
(TLV_DUALSIGNED_DATA 0x00000024) // dual-signed data
(TLV_KEYBLOCK 0x00000025) // key exchange block
(TLV_AUTHINFO 0x00000026) // authorization information
(TLV_CARDINFO 0x00000027) // bank card info
(TLV_CARD_NONCE 0x00000028) // for card no.
(TLV_HASHED_DATA 0x00000029) // hashed, unsigned data
(TV_SUMMARY 0x4025FFFF) // cardholder memo to his issuing bank
(TV_VERSION 0x0000014C) // version information
(TV_DATA_FLAG 0x40270002) // message format flag
(TV_CDH_XID 0x41010018) // transaction ID
(TV_MER_NAME 0x4102FFFF) // merchant name
(TV_CDH_AMT 0x4103000A) // amount req. by cardholder
(TLV_SHIP_INFO 0x00000101) // shipping information
(TV_CHARGE_SLIP 0x4104FFFF) // charge slip
(TLV_DETAILS 0x00000102) // details
(TV_CARD_NAME 0x4105FFFF) // name as on card
(TV_EXP_DATE 0x4106FFFF) // card expiration date
(TLV_BILLING_INFO 0x00000103) // billing information
(TV_XID 0x41070018) // transaction ID
(TV_CDHCRDSVR_NAME 0x4108FFFF) // cdh crd svr name
(TV_RCPT_FLAG 0x41090002) // fail flag in receipt
(TV_RCPT_MSG 0x4110FFFF) // message in receipt
(TV_HASH_NONCE 0x41110010) // foils known-plaintext
(TV_CRDRSP_CODE 0x41120002) // cred response fail code
(TV_ATHRSP_CODE 0x41130002) // auth response fail code
(TV_MER_AMT 0x4114000A) // amount req. by merchant
(TV_RCPT_AMT 0x4115000A) // amount chgd by merchant
// Tags for credentials (all have the 13th bit set)
(TLV_CRDINFO 0x00001001) // cred common info
(TV_CRDSERIALNUM 0x50010010) // cred serial number
(TV_CRDOWNER 0x5002FFFF) // cred owner name
(TV_CRDROOTNAME 0x5003FFFF) // name of the cred root
(TV_CRDLEVEL 0x50040002) // level in trust hierarchy
(TV_CRDVALIDITY 0x50050010) // dates of validity
(TV_CRDACCTHASH 0x50060014) // hash of acct # etc
(TLV_CRDKEY 0x00001002) // public key value
(TLV_CRDKEYEX 0x00001003) // extra public key
(TLV_SIGNERCRD 0x00001004) // cred of signer
(TV_CARDTYPE 0x50070004) // card type field
(TLV_MERACCTNUM 0x00001005) // mer acct # with payment server
(TV_CREATOR 0x50080006) // vendor identifier
(TV_ALTERNATE_NAME 0x5009FFFF) // alternate name
(TV_KEY_ID 0x50100004) // public key ID
(TV_KEY_IDEX 0x50110004) // extra public key ID
(TLV_INSTITUTION_ID 0x00001006) // institution identifier
(TLV_CRD_CARDHOLDERSIG 0x00001801) // cardholder sig cred
(TLV_CRD_CARDHOLDEREXCH 0x00001802) // cardholder key exch cred
(TLV_CRD_MERCHANTSIG 0x00001803) // merchant sig cred
(TLV_CRD_MERCHANTEXCH 0x00001804) // merchant key exch cred
(TLV_CRD_PAYSVRSIG 0x00001806) // payment server sig cred
(TLV_CRD_PAYSVREXCH 0x00001807) // payment server key exch Cred
(TLV_CRD_MERCRDSVRSIG 0x00001808) // merchant credential server sig cred
(TLV_CRD_MERCRDSVREXCH 0x00001809) // merchant credential server key exch cred
(TLV_CRD_CAEXCH 0x0000180A) // root key exch cred
(TLV_CRD_CDHCRDSVRSIG 0x0000180B) // cardholder cred svr sig Cred
(TLV_CRD_CDHCRDSVREXCH 0x0000180C) // cardholder cred svr key exch Cred
(TLV_CRD_CRDSVRSIG 0x0000180D) // credsvr sig cred
(TLV_CRD_CRDSVREXCH 0x0000180E) // credsvr key exch cred
// Tags for credential requests
(TLV_SIGKEY 0x00002001) // sig key in cred req
(TLV_EXCHKEY 0x00002002) // key-exch key in cred req
(TLV_EXCHKEYEX 0x00002004) // extra key exch key
// Tags for message components
(TLV_GSO 0x00004001)
(TLV_PI 0x00004002)
(TLV_MERCHANT_REQUEST 0x00004004)
(TLV_CRD_RESPONSE 0x00004080)
(TLV_EMERGENCY 0x00004100)
// Tags for message types
(TLV_PURORD 0x00008009)
(TLV_ATHREQ 0x0000800A)
(TLV_ATHRSP 0x0000800B)
(TLV_RCEIPT 0x0000800C)
(TLV_CDHCRDREQ 0x0000800F)
(TLV_MERCRDREQ 0x00008010)
(TLV_CDHCRDRSP 0x00008011)
(TLV_MERCRDRSP 0x00008012)
// Reserved Range; width = 4096
(MSAPP_RESERVED_FIRST 0x0000A000)
(MSAPP_RESERVED_LAST 0x0000AFFF)
// Tag range reserved for VISA
(TLV_VISA_FIRST 0x00020000)
(TLV_VISA_LAST 0x0002FFFF)
// User-Defined Tag range -- not used by STT
(TLV_USER_FIRST 0x00800000)
(TLV_USER_LAST 0x008FFFFF)
// mask for defining TAG lengths
(TLV_EXTENDED 0x80000000) ; To be defined later
Authentication policy is out-of-band for STT. In other words, it is completely up to banks and higher authorities in the trust tree to decide whether to issue credentials. When a merchant credential server receives a credential request from a merchant, the entity must satisfy itself that the merchant is in good standing before issuing an STT credential. Options for so doing include visiting the merchant face-to-face, checking credential request fields via telephone, fax, or e-mail, and so on. Similarly, cardholder credential servers (issuers) must satisfy themselves that cardholder credential requests are valid. Options include a phone call and "mother's maiden name" questions, a separate paper mailer to an address on file containing the credential on diskette, or simply checking that the card is not reported lost or stolen. Since STT is transport-independent, it is important for applications to ensure that the credential is delivered to the party who requests it. STT addresses this requirement by packaging new credentials in credential response messages encrypted under the key-exchange key of the requestor. However, this alone does not prevent the requestor from being an impostor.
To reduce sizes of messages that do not need both kinds, key- exchange credentials and signature credentials are separate. A signature credential binds a signature key with an account number and places the pair in the trust hierarchy for an explicit time. A key-exchange credential binds a key-exchange key to an account number and allows others to encrypt data to the owner of the account with some assurance that the owner can be trusted with encrypted data. There are several different kinds of credentials. The Common Fields appear in all credentials. Other fields only appear in certain kinds of credentials. A credential is a TLV. Its detailed format follows:
(define-type CRD-COMMON
((TLV_DATA ;just a container
((TV_CRDLEVEL WORD) ;see explanation below
(TV_VERSION (DWORD 0x00000110))
(TV_CREATOR
((WORD wReserved) ;vendor # assigned by card brand, MS is 1
(DWORD dwAbilities))) ;reserved for vendor
(TV_CRDSERIALNUM BYTE[16]) ;assigned by cred creator
(TV_CRDOWNER Cstring) ;"subject name"
(TV_ALTERNATE_NAME CString)
(TV_CRDVALIDITY
((DATE GoodFrom)
(DATE GoodThru)))))))
TLV_CRDTAG refers to one of the following:
TLV_CRD_CARDHOLDERSIG TLV_CRD_CARDHOLDEREXCH TLV_CRD_MERCHANTSIG TLV_CRD_MERCHANTEXCH TLV_CRD_PAYSVRSIG TLV_CRD_PAYSVREXCH TLV_CRD_MERCRDSVRSIG TLV_CRD_MERCRDSVREXCH TLV_CRD_CAEXCH TLV_CRD_CDHCRDSVRSIG TLV_CRD_CDHCRDSVREXCH TLV_CRD_CRDSVRSIG TLV_CRD_CRDSVREXCHThe TV_CRDLEVEL is a WORD containing the height of the credential in the trust tree. The height is 0 for leaf credentials, i.e., cardholders and merchants. Cardholder Credential Servers and Merchant Credential Servers have height 1, meaning they can sign the credentials of leaf entities. Credential Servers have height 2, meaning they can sign level-1 credentials, i.e., Merchant Credential Servers, Payment Servers, and Cardholder Credential Servers.
There are different Credential Type-Dependent Fields for each type of credential. The following streams are mutually exclusive: any credential may have only one of them.
((TV_CARDTYPE DWORD) ;VISA is 2, all others are reserved
(TV_CRDACCTHASH BYTE[20]) ;see explanation below
(TV_KEY_ID DWORD) ;assigned by key generator / owner
(TLV_CRDKEY 76 RSA.5K))
The TV_CRDACCTHASH contains the SHA hash of the concatenated card
nonce, card account number, and expiration date string - in this
specific order.
Cardholder Signature Creds have the following CDF:
((TV_CARDTYPE DWORD) ;VISA is 2, all others are reserved
(TV_CRDACCTHASH BYTE[20]) ;as with cardholder key-exchange creds
(TV_KEY_ID DWORD) ;assigned by key generator / owner
(TLV_CRDKEY 140 RSA1K))
Merchant Signature Creds have the following CDF:
((TV_CARDTYPE DWORD)
(TLV_MERACCTNUM) ;identifies merchant to payment server
(TV_KEY_ID DWORD) ;assigned by key generator / owner
(TLV_CRDKEY 140 RSA1K))
Merchant Credential Servers, Payment Servers, and Cardholder
Credential Server creds share the same CDF formats:
((TV_CARDTYPE DWORD)
(TLV_INSTITUTION_ID) ;assigned by cred signer
(TV_KEY_ID DWORD) ;assigned by key generator / owner
(TLV_CRDKEY 140 RSA1K))
Credential Server creds need an additional field for the name of the
root of the trust tree in which the cred is signed:
((TV_CARDTYPE DWORD)
(TLV_INSTITUTION_ID) ;assigned by cred signer
(TV_CRDROOTNAME CString) ;name of root of trust tree
(TV_KEY_ID DWORD) ;assigned by key generator / owner
(TLV_CRDKEY 140 RSA1K))
The root credential authority key-exchange cred has the following CDF:
((TV_CRDROOTNAME CString) ;name of root of trust tree
(TV_KEY_ID DWORD)
(TLV_CRDKEY 140 RSA1K))
Merchant key-exchange creds contain the following CDF fields:
((TV_CARDTYPE DWORD)
(TLV_MERACCTNUM) ;identifies merchant to payment server
(TV_KEY_ID DWORD) ;assigned by merchant
(TLV_CRDKEY 108 RSA.75K))
(TV_KEY_IDEX DWORD) ;assigned by payment server
(TLV_CRDKEYEX 140 RSA1K))
Merchant key-exchange creds include the public key-exchange key of
the merchant's payment server in the TLV_CRDKEYEX. This enables
cardholder software to encrypt the PI to the payment server and the
GSO to the merchant. The merchant credential server signs this cred,
vouching for both keys.
((TLV_SIGNERCRD) ;recursively contains signer creds
(TV_ROOTSIGNATURE BYTE[256])) ;PKCS #1 sig
Or, in the case of creds signed directly by the Root Credential
Authority (normally, these are just sub-authority creds):
(TV_ROOTSIGNATURE BYTE[256]) ;PKCS #1 sig
A message may be either signed, dual-signed, or hashed, and finally, may be encrypted. Any signing or hashing is always done before encryption. Every message component includes a TV_DATA_FLAG, which precedes the message content with a WORD specifying extra processing, as follows:
Bit# Mask Data Form ------------------------------ 1 0x0002 SIGNED 2 0x0004 ENCRYPTED 4 0x0010 DUALSIGNED 5 0x0020 HASHEDBits 1 and 2 are mutually exclusive. That is, a message may be either signed, dual-signed, or hashed. All other bit mask positions are reserved for enhancements and future versions of STT.
Messages may carry a TV_CARDTYPE to indicate card brand. This WORD value is to be interpreted as follows:
// Values for card types in TV_CARDTYPE
(VISA 0x2)
(RESERVED 0x3)
(RESERVED 0x4)
(RESERVED 0x5)
(RESERVED 0x6)
Other message details are documented in the following sections. The following types are recognized:
PURORD
MERCRDREQ
CDHCRDREQ
ATHREQ
RCEIPT
ATHRSP
MERCRDRSP
CDHCRDRSP
Sent by cardholder to merchant, this is an aggregate message containing a hashed GSO followed by a dual-signed PI. The hashed GSO contains a dual-signed GSO core and an unsigned Details field. The Details field is unsigned because secure signature software, without being excessively generic, cannot guarantee display of all formats that might be of interest to merchants and cardholders. Whereas an adversary could tamper with the unsigned Details field through its veil of RC4 encryption, he would not be able to construct a valid hash through that veil without knowing the complete plaintext of the signed GSO core and the Details field.
Typical software scenarios involve a client shopping application interacting with a compatible merchant server application. A shopping protocol must be defined between these applications. For example, the client application must supply a shipping address in a form that the merchant application can interpret. Shopping protocols are out of the scope of STT, but STT provides the Details field for application designers to put higher-level protocol information.
A dual signature is an RSA encryption of the hash of the concatenation of two hashes. A dual signature must be generated for the combined GSO and PI, and affixed to each. The same dual signature is affixed to the GSO and to the PI. The procedure is as follows:
1. Hash the GSO, producing H(GSO).
2. Hash the PI, producing H(PI).
3. Concatenate the two, in that order, producing
H2 = H(GSO) | H(PI).
4. Hash H2, producing H(H2).
5. Sign H(H2), i.e., RSA-encrypt it with the private signature
key, producing S(H(H2)).
6. Affix the concatenation of H2 | S(H(H2)) to each of the
GSO and the PI.
To check the dual signature, if you are a merchant and you have
the supposed GSO plaintext, call it GSO':
1. Hash GSO', producing H(GSO').
2. Overwrite the first twenty bytes in the H2 received from
the sender with your own H(GSO'), producing H2'.
3. Hash H2', producing H(H2').
4. RSA-decrypt the S(H(H2)) received from the message sender,
recovering H(H2)).
5. Compare, bitwise, H(H2') with H(H2); if they match, the
signature is verified.
6. Include H(GSO') in the Merchant Authorization Request.
If you have the ansatz PI' plaintext (you are a payment server),
do the following:
1. Verify H(GSO') against the FIRST twenty bytes in the H2
received from the sender.
2. Hash PI', producing H(PI').
3. Overwrite the LAST twenty bytes in the H2 received from
the sender with your own H(PI'), producing H2''.
4. Hash H2'', producing H(H2'').
5. RSA-decrypt the S(H(H2)) received from the message sender,
recovering H(H2)).
6. Compare, bitwise, H(H2'') with H(H2); if they match, the
signature is verified.
The dual signature is an optimization: It reduces the number of
time-consuming signatures the cardholder must compute. The second-
tier receipient (payment server) can verify the GSO/PI are a pair
since replacing the PI in transit would require creating a collision
in H(H2''), which is computationally infeasible.
A successful purchasing transaction comprises four messages: a GSO/PI, an AuthRequest, an AuthResponse, and a Receipt. The XID for the transaction is generated by the cardholder when he or she initiates the transaction with the GSO/PI. As an optimization, the AuthResponse does not require the XID of the GSO/PI since it bears the additional XID generated by the merchant for the nested AuthRequest transaction. The outer transaction may be terminated by the merchant, in which case there will be no nested AuthRequest transaction and the merchant will send a negative receipt to the cardholder.
STT's strongest encryption secures the bank card number in the RSA envelope, which is packaged in the DESKey.
(TLV_PURORD
(TV_VERSION (DWORD 0x00000110))
(TLV_GSO
(TV_KEY_ID DWORD) ;from merchant's cred
(TV_DATA_FLAG (WORD 0x0014)) ;dualhashed and encrypted
(TLV_KEYBLOCK 111 RC4Key)
(TLV_ENCRYPTED_DATA ;RC4-encrypted data
;------- The data below is in plaintext form ------
(TLV_HASHED_DATA
(TV_HASH_NONCE BYTE[16]) ;foils known plaintext attack
(TLV_DATA ;"XDataToHash"
(TLV_DUALSIGNED_DATA
(TLV_DATA
(TV_CDH_XID XID);of this GSO/PI
(TV_MER_NAME CString)
(TV_CRDSERIALNUM BYTE[16]);from merchant's cred
(TV_CDH_AMT CMoney) ;authorized by Cdh
(TLV_CRD_CARDHOLDEREXCH)
(TV_CHARGE_SLIP CString)) ;end of TLV_DATA
(TLV_CRD_CARDHOLDERSIG)
(TV_DUALHASH BYTE[40]) ;2 SHA hashes
(TV_SIGNATURE BYTE[128])) ;sig of DUALHASH
(TLV_DETAILS)) ;unsigned supporting data
(TV_HASH BYTE[20])))) ;hash of "XDataToHash"
(TLV_PI
(TV_KEY_ID DWORD) ;of Payment Server from MerCrd
(TV_DATA_FLAG (WORD 0x0014))
(TLV_KEYBLOCK 148 DESKey)
(TLV_ENCRYPTED_DATA ;DES-encrypted data
;------- The data below is in plaintext form ------
(TLV_DUALSIGNED_DATA
(TLV_DATA
(TV_CDH_XID XID) ;of this GSO/PI
(TV_MER_NAME CString) ;merchant name
(TV_CRDSERIALNUM BYTE[16]) ;from merchant's cred
(TV_CDH_AMT CMoney) ;authorized by Cdh
(TLV_BILLING_INFO) ;application-defined
(TV_CARD_NAME CString) ;name as on card
(TV_EXP_DATE CString) ;from card, for hash check
(TV_SUMMARY CString) ;cardholder memo back to their issuing bank
(TLV_CARD_NONCE)) ;end of data;for hash check
(TLV_CRD_CARDHOLDERSIG)
(TV_DUALHASH BYTE[40]) ;2 SHA hashes
(TV_SIGNATURE BYTE[128]))))) ;sig of DUALHASH
(TLV_MERCRDREQ
(TV_VERSION (DWORD 0x00000110))
(TV_KEY_ID (DWORD MerCrdSvrKeyId))
(TV_DATA_FLAG (WORD 0x0024))
(TLV_KEYBLOCK 148 DESKey)
(TLV_ENCRYPTED_DATA ;DES-encrypted data
;------- The data below is in plaintext form ------
(TLV_HASHED_DATA
(TV_HASH_NONCE BYTE[16]) ;foils known plaintext attack
(TLV_DATA
(TV_XID)
(TV_CREATOR
((WORD wReserved) ;vendor #, MS is 1
(DWORD dwAbilities))) ;reserved for vendor
(TV_CARDTYPE (DWORD dwBrand))
(TV_ALTERNATE_NAME CString)
(TV_CRDOWNER (CString MerchantName))
(TLV_DATA) ;Application-defined
(TV_KEY_ID requestedKeyId)
(TLV_SIGKEY RSA1K)
(TLV_EXCHKEY RSA.75K)) ;end of TLV_DATA
(TV_HASH (BYTE[20] HashOfData)))))
(TLV_CDHCRDREQ
(TV_VERSION (DWORD 0x00000110))
(TV_KEY_ID (DWORD CdhCrdSvrKeyId))
(TLV_DATA_FLAG (WORD 0x0024))
(TLV_KEYBLOCK 148 DESKey)
(TLV_ENCRYPTED_DATA ;DES-encrypted data
;------- The data below is in plaintext form ------
(TLV_HASHED_DATA
(TV_HASH_NONCE BYTE[16]) ;foils known plaintext attack
(TLV_DATA
(TV_XID)
(TV_CREATOR
((WORD wReserved) ;vendor #, MS is 1
(DWORD dwAbilities))) ;reserved for vendor
(TV_CARDTYPE (DWORD dwBrand))
(TV_ALTERNATE_NAME CString)
(TLV_CARDINFO
(TLV_BILLING_INFO) ;Application-defined
(TV_CARD_NAME (CString NameAsOnCard))
(TV_EXP_DATE (CString ExpirationDate))
(TV_CDHCRDSVR_NAME (CString CdhCrdSvrName)))
(TLV_DATA) ;CdhCrdSvr-specified policy field
(TV_KEY_ID requestedKeyId)
(TLV_SIGKEY RSA1K)
(TLV_EXCHKEY RSA.5K)) ;end of TLV_DATA
(TV_HASH (BYTE[20] HashOfData)))))
(TLV_ATHREQ
(TV_VERSION (DWORD 0x00000110))
(TLV_MERCHANT_REQUEST
(TV_KEY_ID (DWORD PaymentSvrKeyId))
(TV_DATA_FLAG (WORD 0x0006))
(TLV_KEYBLOCK 148 DESKey)
(TLV_ENCRYPTED_DATA ;DES-encrypted data
;------- The data below is in plaintext form ------
(TLV_SIGNED_DATA ;auth request prefix
(TLV_DATA
(TV_XID) ;generated by merchant for nested transaction
(TV_MER_AMT (CMoney MerchantRequestedAmount))
(TLV_CRD_MERCHANTEXCH))
(TV_HASH (BYTE[20] HashOfGSO))
(TLV_CRD_MERCHANTSIG)
(TV_SIGNATURE (BYTE[128] MerchantSig)))))
(TLV_PI)) ;See PURORD section
0 - Approved / Card OK
1 - Declined
2 - No Reply
3 - Call Issuing Bank
4 - Amount Error
5 - Expired Card
6 - Invalid Transaction
7 - System Error
(TLV_RCEIPT
(TV_VERSION (DWORD 0x00000110))
(TV_KEY_ID (DWORD CardholderKeyId))
(TV_DATA_FLAG (WORD 0x0006))
(TLV_KEYBLOCK 76 RC4Key)
(TLV_ENCRYPTED_DATA ;RC4-encrypted data
;------- The data below is in plaintext form ------
(TLV_SIGNED_DATA
(TLV_DATA
(TV_XID (XID OfOriginalGSO))
(TV_RCPT_AMT (CMoney))
(TV_RCPT_FLAG (WORD ReceiptFlags))
(TV_RCPT_MSG (CString MessageFromMerchant)))
(TLV_CRD_MERCHANTSIG)
(TV_SIGNATURE (BYTE[128] MerchantSig)))))
0 - Approved / Card OK
1 - Declined
2 - No Reply
3 - Call Cardholder's issuing bank
4 - Amount Error
5 - Cardholder's card has expired
6 - Invalid Transaction
7 - System Error
(TLV_ATHRSP
(TV_VERSION (DWORD x00000110))
(TV_KEY_ID (DWORD MerchantKeyId))
(TV_DATA_FLAG (WORD 0x0006))
(TLV_KEYBLOCK 111 RC4Key)
(TLV_ENCRYPTED_DATA ;RC4-encrypted data
;------- The data below is in plaintext form ------
(TLV_SIGNED_DATA
(TLV_DATA
(TV_XID (XID OfOriginalAuthRequest))
(TV_ATHRSP_CODE WORD)
(TLV_DATA)) ;application-defined
(TLV_CRD_PAYSVRSIG)
(TV_SIGNATURE (BYTE[128] PaySvrSig)))))
0 - Credential issued; no error
1 - Contact credentialing authority (one level up the tree)
2 - Try again or contact credentialing authority
3 - Expired Card (cardholder credential)
4 - System Error; contact credentialing authority
(TLV_MERCRDRSP
(TV_VERSION (DWORD 0x00000110))
(TV_KEY_ID (DWORD 0))
(TV_DATA_FLAG (WORD 0x0004))
(TLV_KEYBLOCK 111 RC4Key)
(TLV_ENCRYPTED_DATA ;RC4-encrypted data
;------- The data below is in plaintext form ------
(TV_CRDRSP_CODE WORD)
(TV_XID (XID OfCorrespondingCrdRequest))
(TLV_CRD_MERCHANTSIG)
(TLV_CRD_MERCHANTEXCH)))
0 - Credential issued; no error
1 - Contact credentialing authority (one level up the tree)
2 - Try again or contact credentialing authority
3 - Expired Card (cardholder credential)
4 - System Error; contact credentialing authority
(TLV_CDHCRDRSP
(TV_VERSION (DWORD 0x00000110))
(TV_KEY_ID (DWORD 0))
(TV_DATA_FLAG (WORD 0x0004))
(TLV_KEYBLOCK 79 RC4Key)
(TLV_ENCRYPTED_DATA ;RC4-encrypted data
;------- The data below is in plaintext form ------
(TV_CRDRSP_CODE WORD)
(TV_XID (XID OfCorrespondingCrdRequest))
(TLV_CARD_NONCE (BYTE[16] Nonce))
(TLV_CRD_CARDHOLDERSIG)
(TLV_CRD_CARDHOLDEREXCH)))
1. STT uses RC4 encryption with 8-byte keys, of which 3 bytes are salt, in the clear. See the RC4Key entry under the Low- Level Composites section of this document. RC4 is a stream cipher; there are no pad bytes and the encrypted data is the same size as the plaintext data.
2. STT uses the Cipher Block Chaining (CBC) mode of DES, as defined in Federal Information Processing Standard FIPS 81. The key is 8 bytes long, with each byte having a parity bit in position 0. Thus there are 56 bits of random key. STT uses an all-zero byte Initialization Vector (IV). A maximum of 8 bytes of padding is applied to every plaintext message encrypted with DES to pad the message to a length that is a multiple of 8 bytes. Pad bytes have a value of:
x = 8 - ((length of the plaintext) mod 8)
and the number of pad bytes is also x. For example, if the
plaintext message was 17 bytes long, then each of the 7 bytes of
padding contains the value 0x07. If x is 0, then there are 8
bytes, each containing 0x08. Padding is appended to the end of
the plaintext before encryption and is stripped off after
decryption.
(TV_SIGNATURE
(BYTE[20] HashOfData) ;hash of the data being signed
(BYTE 0) ;parser initializer
(BYTE[105] 0xff) ;padding
(BYTE 0x01) ;recom. for private key encryptions
(BYTE 0)) ;overflow protection for RSA
(TV_ROOTSIGNATURE
(BYTE[20] HashOfData) ;hash of the data being signed
(BYTE 0) ;parser initializer
(BYTE[233] 0xff) ;padding
(BYTE 0x01) ;recom. for private key encryptions
(BYTE 0)) ;overflow protection for RSA
1. Cdh - Cardholder
2. Mer - Merchant
3. CdhCrdSvr - Cdh Credential Server, (Issuing Bank) signs Cdh Creds
4. PaySvr - Payment Server, Acquiring (Mer) bank
5. MerCrdSvr - Merchant Credential Server, signs Mer Creds
6. CrdSvr - Credential Server, signs CdhCrdSvr, PaySvr, and MerCrdSvr Creds
7. Root - Signs Credential Server Creds
1. TLV_PURORD
2. TLV_MERCRDREQ
3. TLV_CDHCRDREQ
4. TLV_ATHREQ
5. TLV_RCEIPT
6. TLV_ATHRSP
7. TLV_MERCRDRSP
8. TLV_CDHCRDRSP
1. Card Registration. Sequentially,
a) Cdh sends CDHCRDREQ to CdhCrdSvr
b) CdhCrdSvr sends CDHCRDRSP to Cdh
2. Merchant Registration. Sequentially,
a) Mer sends MERCRDREQ to MerCrdSvr
b) MerCrdSvr sends MERCRDRSP to Mer
3. Purchasing, Sequentially,
a) Cdh sends PURORD to Mer
b) Either
(1) Mer sends ATHREQ to PaySvr
(2) PaySvr sends ATHRSP to Mer
(3) Mer sends RCEIPT to Cdh
c) or
(1) Mer sends RCEIPT to Cdh
Merchant registers with the Merchant Credential Server
Merchants (or their processing agents) must register through their Merchant Credential Server, which have been previously registered with their Credential Server, to be able to accept transactions on a particular brand's cards and pass them on their (the Merchant's) Payment Server.
Message Types:
TLV_MERCRDREQ - The credential request message sent by the
merchant to the merchant credential server.
TLV_MERCRDRSP - The credential request response message sent by
the merchant credential server back to merchant.
Cardholder registers with Cardholder Credential Server
Cardholders must register their cards. They do this by registering directly with Cardholder Credential Server (issuer). This bindery is operated by their bank or its agent (which could be the brand itself, for example Visa, MasterCard, American Express)
Message Types:
TLV_CDHCRDREQ - The credential request message sent by the
cardholder to the Cardholder Credential Server that
issues the cardholder's credential.
TLV_CDHCRDRSP - The credential request response message sent by
the Cardholder Credential Server back to the cardholder
for the registered card.
Once all parties to a transaction are registered, initial distribution of credentials may occur. Distribution of credentials is NOT defined as part of the STT protocol because it is part of the basic (and variable) business relationships between participants (see Initial Credential Distribution, below).
Given that registration and credential distribution have taken place, a purchase transaction may occur. In STT, this is a three-way communication between a cardholder, a merchant, and a payment server. The back-end communication between the payment server and the banking system is neither defined nor affected by STT. It fully exists today.
The flow begins with a cardholder sending a request to a merchant to purchase goods or services. This includes the "Goods and Services Order" (GSO) and "Payment Instruction" (PI). The GSO is processed locally by the merchant, while the PI is passed on to the payment server for authorization of the means of payment. STT does not specify the "back end" of the payment server, that is, the mechanism by which the server processes the authorization request. Presumably, existing banking systems networks and protocols will be used. The response from the payment server to the merchant is back in-band for STT, as is the final leg of the transaction, consisting of a receipt from merchant to cardholder.
Message Types
TLV_PURORD - The purchase request sent by the cardholder to the
merchant. This includes both the GSO and the PI. See the
section on encryption for details on encryption and signing.
TLV_ATHREQ - The PI, along with additional merchant information
is sent from the merchant to the payment server.
TLV_ATHRSP - The result of processing the PI (accomplished
synchronously, but out of the STT protocol specification) is
sent from the payment server to the merchant.
TLV_RCEIPT - The receipt (as specified by the merchant) is sent
back to the cardholder.
Not currently defined in the STT protocol.
Credential format is defined by STT, but the means of distribution, i.e., the transport, is not specified. Web-based scenarios are most likely and will be supported directly by Microsoft's implementations.
Merchant Registration with Merchant Credential Server:
MERCHANT MER CRD SERVER
| |
| TLV_CRD_MERCRDSVREXCH |
| <---------------------------- |
| |
| TLV_MERCRDREQ |
| ----------------------------> |
| |
| <---------------------------- |
| TLV_MERCRDRSP |
Cardholder Registration with Cardholder Credential Server:
CARDHOLDER CDH CRD SERVER
| |
| TLV_CRD_CDHCRDSVREXCH |
| <---------------------------- |
| |
| TLV_CDHCRDREQ |
| ----------------------------> |
| |
| <---------------------------- |
| TLV_CDHCRDRSP |
Purchase:
CARDHOLDER MERCHANT PAY SVR
| | |
| TLV_CRD_MERCHANTEXCH | |
| <------------------- | |
| | |
| TLV_PURORD | |
| -------------------> | |
| | TLV_ATHREQ |
| | ----------------> |
| | |
| | TLV_ATHRSP |
| | <---------------- |
| TLV_RCEIPT | |
| <------------------- | |
[2] "Optimal Asymmetric Encryption," M. Bellare and P. Rogaway, Eurocrypt '94.
36 Australian Dollar; 2; Australia, Christmas Is.,
Cocos Is., Keeling Is., Heard Is., McDonald Is.,
Kiribati, Nauru, Norfolk Is., Tuvalu
40 Austrian Schilling; 2; Austria
56 Belgian Franc; 0; Belgium
124 Canadian Dollar; 2; Canada
156 Yuan Renminbi; 2; China
280 Deutsche Mark; 2; Germany
300 Drachma; 0; Greece
344 Hong Kong Dollar; 2; Hong Kong
348 Forint; 2; Hungary
360 Rupiah; 2; Indonesia
372 Irish Pound; 2; Ireland
376 Shekel; 2; Israel
380 Italian Lira; 0; Italy, San Marino, Vatican City
392 Yen; 0; Japan
410 Won; 0; Korea, Rep. of Korea, South Korea
442 Luxembourg Franc; 0; Luxembourg
484 Mexican Nuevo Peso; 2; Mexico
528 Netherlands Guilder; 2; Netherlands
620 Portuguese Escudo; 0; Portugal
724 Spanish Peseta; 0; Spain, Andorra
752 Swedish Krona; 2; Sweden
756 Swiss Franc; 2; Switzerland, Liechtenstein
818 Egyptian Pound; 2; Egypt 826; Pound Sterling; 2;
United Kingdom
840 U.S. Dollar; 2; United States, US, USA, U.S.,
U.S.A., Guam, American Samoa, Wake Is., U.S. Misc.
Pac. Is., Panama Canal Zone, British Virgin Is.,
Johnston Is., Marianas Is., Saipan, Midway Is.
type ::= atom ; alternatives are on separate lines
atom-array
composite
tagged-type
atom ::= <atom-type> ; primitive symbols are in brokets
"(" <atom-type> ")"
"(" <atom-type> <SymName> ")"
"(" <atom-type> <NumValue> ")"
"(" <atom-type> <StrValue> ")"
"(" <atom-type> <NumValue> <SymName> ")"
"(" <atom-type> <StrValue> <SymName> ")"
<atom-type> ::= member of the list named "*atoms-alist*"
array ::= array-prim
"(" array-prim ")"
"(" array-prim <SymName> ")"
"(" array-prim <NumValue> ")"
"(" array-prim <StrValue> ")"
"(" array-prim <NumValue> <SymName> ")"
"(" array-prim <StrValue> <SymName> ")"
array-prim ::= atom "[" <NumCount> "]"
<NumCount> ::= numeric literal, hex or decimmal, C-style
<NumValue> ::= numeric literal
<StrValue> ::= character string literal
<SymName> ::= symbolic literal, all sym names are global
composite ::= member of the list named "*composites-alist*"
composite-def ::= "(define-type" <SymName> sequence ")"
tag_id ::= <tlv_identifier>
<tv_identifier>
<tlv_identifier> ::= symbolic literal whose first four characters are "TLV_"
<tv_identifier> ::= symbolic literal whose first three characters are "TV_"
<tag_value> ::= numeric literal unique in the space
tagged-type ::= TLV
TV
TLV ::= "(" <tlv_identifier> <size_literal> sequence ")"
"(" <tlv_identifier> sequence ")"
<size_literal> ::= numeric literal
TV ::= "(" <tv_identifier> sequence ")"
sequence ::= "(" type-list ")"
type-list ::= <nothing>
type type-list