Internet Development Technologies

Secure Transaction Technology (STT) Wire Formats and Protocols

Version 0.909

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.

1. Introduction

STT (Secure Transaction Technology) is a protocol provided by Microsoft and Visa International to the financial and technical communities for review and comment. Comments on this specification are welcome. Please e-mail comments to

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]


This document covers the international version of the STT protocol, which includes DES encryption of all financial data, direct RSA encryption of bank card account numbers, and 40-bit RC4 encryption of the purchasing order form contents and receipt. A U.S./Canada version of the protocol with triple-DES encryption of the order, receipt, and all financial data and direct RSA encryption of bank card account numbers will be documented and published in the near future.

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.

Note on Randomness

STT uses cryptographic algorithms that require a random source that is both unguessable and has high entropy. STT-compliant implementations shall take advantage of as much physically random information as is available on their platforms. Truly random information must be noise from the world external to the strictly deterministic parts of the machine. The best source of such noise is direct human interaction with the machine. Some information may be collected in real time by asking the user, for example, to type for a while or move the cursor around randomly. This is the preferred method for implementations of STT, though it is recognized that it trades off against user interface concerns. Other information may have accumulated over the lifetime of the machine as users create and delete files, processes, install and remove software, and so on. The following list is a small fraction of the amount of random information that systems programmers can access. The "true entropy" of these sources ranges from high, for those sources that change rapidly in time, to low, for those sources that do change or are not likely change from one machine to the next.

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.

2. Type Hierarchy and Notation

STT messages are made up of data objects, or just objects. Data objects are instances of data types. Data types include atoms, low- level composites, and subtypes of a meta-data type called a TLV. TLVs serve as grouping constructs and as explicit "transfer syntax" elements. So, the notation here is, in effect, an explicit transfer syntax. The transfer syntax is written in a variant of Cambridge Prefix Notation (CPN). The BNF for the transfer syntax appears in appendix IIB. A simple parser for this syntax, written in R4RS Scheme, will be published in an appendix of an upcoming version of this specification.

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
or, where unambiguous, as:

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:

The optional value field is written as a numeric or string constant, as in:
   (WORD 0x1234)
   (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.

3. Atoms

The following are the plaintext formats of STT's data atomic data types.

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.

4. Low-Level Composites


(OSF/DCE Globally Unique ID) GUIDs are also known as UUIDs in the network literature. There is an ISO standard for their format and generation. They must be guaranteed to be unique across space and time. They are a standard part of the Open Software Foundation's (OSF) Distributed Computing Environment (DCE). They are necessary for the correct operation of many network protocols, such as Kerberos. It is very unlikely that an STT developer will be working on a platform that does not support validated GUID-generating software.

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
        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.

          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:
      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)))


Each entity, e.g., cardholder, merchant, bank, in STT has a GUID.

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)))

4C. CMoney

All amounts in STT are contained in CMoneys, which appear as follows:
      (define-type CMoney
        ((WORD  CountryCode)        ;ISO 4217 Country Code.
         (QWORD Amount)))           ;fixed-point with four decimals


A QWORD representing the number of 100-nanosecond intervals since midnight UTC at the beginning of 1 Jan 1601.
        (define-type DATE


(Tag, Length, Value) A TLV is a metadata format for generic, self-describing, byte-packed, streamed, aggregate data objects. These TLV objects can be in any order within a level.

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

On the wire, all TLVs appear as follows:
      ((DWORD          dwTag)
       (DWORD          dwLength)
       (BYTE[dwLength] rgbValue))

4F. TV

(Tag, Value) A TV is an optimized metadata format similar to TLVs except that the length of a TV is either statically known or can be determined by another method, as with CStrings, and therefore the Length field of a TLV is unnecessary. TVs can be distinguished from TLVs by the status of the 31st bit in the Tag. If set, the object is a TV. See TLV/TV Tag Space for a more detailed description of how TVs are constructed.

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))

4G. RSAKey

This is the type of RSA Encryption and Signature Keys. STT RSA moduli have the following lengths:
      * 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)))

4H. DESKey

This is the RSA Envelope for DES keys and bank card account numbers. DESKeys are used to hide DES keys and account numbers from adversaries. The DES keys are generated randomly and used to encrypt bulk financial data.

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


A DESK is a plaintext DES key concatenated with a bank card account number of at most 32 bytes. Its format is:
      (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.


To diffuse a DESK and, thereby, to create a DEKB:
  1. Generate a fresh, 8-byte, random RC4 key -- the OAEP key.
  2. Generate 119 bytes from RC4 using the OAEP key.
  3. XOR these bytes into DESK, resulting in DiffusedDESK.
  4. Hash DiffusedDESK with SHA.
  5. Keep only the low-order (first) 8 bytes of the hash.
  6. XOR the OAEP key with the hash, resulting in rgbHx.
  7. Concatenate rgbHx and a byte of overflow space to DiffusedDESK, resulting in DEKB.
The plaintext of a DEKB, then, is the following:
      (define-type DEKB
        ((BYTE[119]     DiffusedDESK)
         (BYTE[8]       rgbHx)
         (BYTE        0 padding))) ;prevents overflow when
To reverse the process, recovering a DESK from a DEKB, do the following:
  1. Hash DiffusedDESK with SHA.
  2. Keep only the low-order (first) 8 bytes of the hash.
  3. XOR rgbHx with the hash, resulting in the OAEP key.
  4. Generate 119 bytes from RC4 using the OAEP key.
  5. XOR these bytes into DiffusedDESK, resulting in DESK.
The DESK, finally, may be used to decrypt other, DES-encrypted data outside the RSA envelope.

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.

4I. RC4Key

This is the RSA Envelope for protecting RC4 keys. These keys are used in the international version of STT for bulk encryption of receipts, the GSO, authorization responses, and credential responses.

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.


There are three different RC4Ks, corresponding to the three RSA modulus sizes for encrypting RC4 keys.
      (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)))


There are three REKBs corresponding to the three RSA modulus sizes:
      (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:
  1. Generate a fresh, 8-byte, random RC4 key -- the OAEP key.
  2. Generate 110, 78, or 46 bytes from RC4 using the OAEP key, for RC4K1K, RC4K.75K, or RC4K.5K, respectively.
  3. XOR these bytes into an RC4K, resulting in DiffusedRC4K.
  4. Hash DiffusedRC4K with SHA.
  5. Keep only the low-order (first) 8 bytes of the hash.
  6. XOR the OAEP key with the hash, resulting in rgbHx.
  7. Concatenate rgbHx and a byte of overflow space to DiffusedRC4K, resulting in a REKB.
To reverse the process, recovering a RC4K from a REKB, do the following:
  1. Hash DiffusedRC4K with SHA.
  2. Keep only the low-order (first) 8 bytes of the hash.
  3. XOR rgbHx with the hash, resulting in the OAEP key.
  4. Generate 110, 78, or 46 bytes from RC4 using the OAEP key, for RC4K1K, RC4K.75K, or RC4K.5K, respectively.
  5. XOR these bytes into DiffusedRC4K, resulting in an RC4K.
The RC4K, finally, may be used to decrypt other, RC4-encrypted data outside the RSA envelope.

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.

5. TLV/TV Tag Space

This section contains symbolic names and numerical values for TLV and TV tags. STT-compliant software should not use values that do not appear in this table. A range of keys is set aside for application-dependent use. No version of STT will ever use these tags.

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)

   // 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

6. Credentials

STT messages often contain credentials, also called just creds hereafter. An STT credential is a binding between a banking account number, such as a cardholder bank card number or a merchant BIN number, and an RSA key-exchange key or RSA signature key. There is an analogy to certificates in other public-key systems. However, credentials are specialized to STT, they do not affirm general identity, and must not be mistaken for certificates.

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:


The following type encapsulates the fields common to all credentials:
   (define-type CRD-COMMON
     ((TLV_DATA                            ;just a container
        ((TV_CRDLEVEL WORD)                ;see explanation below
         (TV_VERSION  (DWORD 0x00000110))
           ((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)
           ((DATE GoodFrom)
            (DATE GoodThru)))))))
TLV_CRDTAG refers to one of the following:
The 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.


For cardholder key-exchange credentials, CDF should be replaced by:
   ((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:
    (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:
    (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:
    (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:
    (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
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.

Signature Section

Following the Credential Type-Dependent fields, a cred includes the creds, recursively, of its signing authorities and the signatures created by the signers. Software will verify the signature on the cred, then the signature on the signer's cred, and so on, until a signature by a root key is reached. A failure at any level of this recursive check must result in a failure to verify the leaf signature. See the cryptography section for details on PKCS #1 signature format.
   ((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

7. Message Formats

An STT transaction consists of 2 or, in one case, 4 messages. Every STT message can be assigned unambiguously to its transaction via a globally unique XID. Every STT message has its XID explicitly in a field, but the location of the XID is different in each message type. There are two kinds of messages: upward and downward. Upward messages flow from entities lower in the trust hierarchy to higher entities. Downward messages flow from higher authorities to lower. Downward messages may include piggybacked Emergency messages. Emergency messages support global root key replacement in the (very unlikely) case of root key compromise. A proper implementation of STT will ONLY replace the root key if the Emergency message is signed by the old root and if the user successfully types in the hash of the message from an external, trusted source such as Microsoft's 800 support number or an ad in a prominent newspaper. The signature on the Emergency message prevents denial of service attacks, and the hash check ensures that users get crucial information from a trusted source. All message content fields are TLV/TVs.

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    HASHED
Bits 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:

Upward Messages


Downward Messages


Detailed Message Formats


(Goods & Services Order / Payment Instruction)

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.

       (TV_VERSION (DWORD 0x00000110))
         (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 ------
             (TV_HASH_NONCE BYTE[16])        ;foils known plaintext attack
             (TLV_DATA                       ;"XDataToHash"
                   (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 
                   (TV_CHARGE_SLIP CString)) ;end of TLV_DATA
                 (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"
         (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 ------
               (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
             (TV_DUALHASH BYTE[40])          ;2 SHA hashes
             (TV_SIGNATURE BYTE[128])))))    ;sig of DUALHASH

7B. Merchant Credential Request

       (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 ------
           (TV_HASH_NONCE BYTE[16])             ;foils known plaintext attack
               ((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)))))

7C. Cardholder Credential Request

The bank card number goes in the (TLV_KEYBLOCK DESKey), which is the RSA envelope, as with a PI.
       (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 ------
           (TV_HASH_NONCE BYTE[16])             ;foils known plaintext attack
               ((WORD  wReserved)               ;vendor #, MS is 1
                (DWORD dwAbilities)))           ;reserved for vendor
             (TV_CARDTYPE (DWORD dwBrand)) 
             (TV_ALTERNATE_NAME  CString)
               (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)))))

7D. Merchant Authorization Request (ATHREQ)

This is an aggregate message tied by XID to a GSO/PI and a Receipt. It contains a signed Authorization Request Prefix from the merchant to the payment server, as well as the forwarded PI encrypted by the cardholder to the payment server. The PI contains the XID of the original GSO/PI. The purpose of the authorization request prefix is to allow the merchant to tell the payment server the amount he thinks the cardholder has authorized from the GSO. This prevents cardholders and merchants from defrauding each other. Some payment servers allow a small percentage difference in the two amounts to account for fluctuations in freight charges and taxes. The existence or width of this slop is entirely a bank policy issue. The AthReq also contains the merchant-derived hash of the GSO, which the recipient can use to verify linkage between the GSO and the PI.
       (TV_VERSION (DWORD 0x00000110))
         (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
               (TV_XID)                     ;generated by merchant for nested transaction
               (TV_MER_AMT (CMoney MerchantRequestedAmount))
               (TV_HASH  (BYTE[20] HashOfGSO))
             (TV_SIGNATURE (BYTE[128] MerchantSig)))))
      (TLV_PI))                            ;See PURORD section

7E. Merchant Receipt (RCEIPT)

Signed receipt from the merchant to the cardholder. The TV_RCPT_FLAG WORD holds a code that indicates whether the transaction was successful. The following values are defined for the TV_RCPT_FLAG:
         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

       (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 ------
             (TV_XID       (XID OfOriginalGSO))
             (TV_RCPT_AMT  (CMoney))
             (TV_RCPT_FLAG (WORD ReceiptFlags))
             (TV_RCPT_MSG  (CString MessageFromMerchant)))
           (TV_SIGNATURE (BYTE[128] MerchantSig)))))

7F. Payment Server Authorization Response (ATHRSP)

Signed authorization response from the payment server to the merchant. This indicates to the merchant whether the cardholder's bank card is good. The XID of the original GSO is omitted, as an optimization, since the XID of the corresponding AuthRequest identifies the message uniquely. The following values are defined for the TV_ATHRSP_CODE:
         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

       (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 ------
             (TV_XID (XID OfOriginalAuthRequest))
             (TV_ATHRSP_CODE WORD)
             (TLV_DATA))                    ;application-defined
           (TV_SIGNATURE (BYTE[128] PaySvrSig)))))

7G. Merchant Credential Response

The TV_CRDRSP_CODE WORD holds a code indicating whether the credential was issued. If the WORD is non-zero, credentials are not present in the response. The following values are defined for the WORD:
         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
       (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_XID  (XID OfCorrespondingCrdRequest))

7H. Cardholder Credential Response

The TV_CRDRSP_CODE WORD holds a code indicating whether the credential was issued. If the WORD is non-zero, credentials are not present in the response. The following values are defined for the WORD:
         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
       (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_XID  (XID OfCorrespondingCrdRequest))
         (TLV_CARD_NONCE (BYTE[16] Nonce))

8. Cryptography

8A. Encryption for US/Canada only

This is work in progress. A high-level summary is that U.S./Canada versions of STT will use triple-DES (3DES) for all encrypted messages and will put Bank Card Account Numbers in the RSA envelope of one of the 3DES keys, as with the international version.

8B. Encryption for the International Version

Two bulk encryption algorithms are used in international STT: RC4 and DES.

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.

8C. Signatures

STT uses PKCS #1 encryption block formatting for RSA signatures. Total length is 128 bytes for the signature (1024-bit modulus), except for signatures by the root key, which are twice as long. The following are the plaintexts:
         (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

         (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

8D. Hashing

All hashes in STT are 20-byte SHA hashes. See Federal Information Processing Standard FIPS 181 for the specification of SHA hashes.

9. Protocols

9A. Entities

     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

9B. Messages

      1.  TLV_PURORD
      4.  TLV_ATHREQ
      5.  TLV_RCEIPT
      6.  TLV_ATHRSP

9C. Protocol Quick List

     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 

9D. Protocol Descriptions


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.

Purchase and Authorization

This is the only two-step or nested transaction in STT.

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 Distribution

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.

9E. Message Flows


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             |


   CARDHOLDER              MERCHANT              PAY SVR
       |                      |                     |
       | TLV_CRD_MERCHANTEXCH |                     |
       | <------------------- |                     |
       |                      |                     |
       |      TLV_PURORD      |                     |
       | -------------------> |                     |
       |                      |       TLV_ATHREQ    |
       |                      |   ----------------> |
       |                      |                     |
       |                      |       TLV_ATHRSP    |
       |                      |   <---------------- |
       |       TLV_RCEIPT     |                     |
       | <------------------- |                     |

10. References

[1] "A Method for Obtaining Digital Signatures and Public Key Cryptosystems," R.L. Rivest, A. Shamir, L. Adelman, MIT Laboratory for Computer Science and Department of Mathematics, S. L. Graham, R. L. Rivest, ed. Communications of the ACM, February 1978 (Vol. 21, No. 2), pages 120-126.

[2] "Optimal Asymmetric Encryption," M. Bellare and P. Rogaway, Eurocrypt '94.

11. Appendices

11A. ISO 4217 Currency Country Codes

This is not part of STT proper. Interpretation of these fields is an application issue. The following is a non-authoritative sample of popular currencies.
   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.

11B. BNF for STT's Transfer Syntax CPN

     type ::= atom                ; alternatives are on separate lines

     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>
                <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

     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

© 1995 Microsoft Corporation