2. If the f ir·r:t byte is Oxrt-.md the next �1or·d is between o and
`OxFFFD, inclur;ive, then the \·iOHD
`conte�ins the char·acter
`count.
`
`3. Finally, if the t irst byte is OxFF and the next word lr;
`OxFFFF, then the ColloHing D''iCJRD contains the chc�racter
`count.
`
`4. RESERVATION: in the future, S'TT m.:�y !!Upport UNICODE
`Cstrings. These are denoted by (BYTE OxFF}, fol101�cd by
`(I·!Of<D
`OxfTFE), follOvled by a UNICODE ch.Hdcter count -- not
`a byLe count-- d�: encoded in 1, 2, and 3. above.
`
`
`
`4. Low-level Composites
`
`4A. GUID
`
`OSF/DCE Globally Unique ID. GUlDs 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 arc necessary for the con-ect operation of many network protocols, such as Kcrberos. It is very
`
`
`
`
`unlikely that an SIT developer will be working on a platform that does not support validated
`
`GUID-gcnerating software.
`
`
`
`The following is a brief synopsis of one QUID-generating algorithm. More details may be found in the
`
`
`
`
`
`
`citations bdow.
`
`with a 48-bit IEEE network card hardware address, this globally
`
`If your machine contains a network card
`
`
`unique address will be incorporated into the GUID. Otherwise a random pseudo-address is created from
`
`machine state infom1ation 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 t'ollowing excerpts on net hardware addresses are taken from
`
`
`
`Project 802: Local and Metropoli t.�n Ar·ea Network Standard
`Draft Standard P802.1A/Dl0 1 April 1990
`Pr·epared by the IEEE 802 .1
`
`--- begin quote -----------------------
`
`------------------------
`
`Page 18: "5. Universal Addresses and Protocol Identi!iers
`
`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
`identt(iers, 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
`. 2u22 (approximately 4 mill ion identifiers}.
`
`[ ... ] The multicast bit is the least significant bit of the
`first octet, A.
`
`[ . .. ] 5.1 Organizationally Unique Identifier
`
`s o: 28
`
`Page 301 of 544
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1008
`
`

`
`[ ... 1 The o1ganizationally unique identifier is 24 bitc in
`lenglh and its bit pattern ir.: shown belm·l. Organizationally
`unique identifiers are �s�igned ac 24 bit values with both
`values (0,1) being assigned to the first bit and the second biL
`being :;et tO 0 indicates that the c1r,:dgnment )!: UnivetS<:<l.
`OlganL!ation.llly unique identitiers with the :;econd bit r:cL Lo 1
`are loc�lly c1BLigned and h�ve no rclationLhip to the
`IEEE-assigned values (as described herein).
`
`The otgctnizationally unique identifier is defined to be:
`
`1st bit
`I
`a b c d e
`I I
`I Always �;et to zero
`Bit can be set to 0 or 1 depending on application
`
`24th bit
`I
`x y
`
`I .. . ) 5.2 4!3-Bit Univer·sal LAN l4ac Addresr;es
`
`[ . . • 1 A 48 bit universal address consir;ts of two parts. 'rhe
`(irst 24 bits correspond to the organizationally unique
`identifier as ar;signed by the IEEC except that the ascignec may
`set the first bit to 1 for group addre�ses or set it to 0 fot
`individual .:•ddtesses. 1"hc second part, comprising the tem<!lining
`24 bits, 1S <:�dministered locally by the c�r;r.ignee.
`I . .. I
`
`5
`1
`4
`3
`2
`0111 1011
`0000 0000 oooo 0001
`0001 0010 0000 0000
`
`octet:
`0
`0011 0101
`I
`Fin:t bit transmitted on the LAN medium. (Alco the
`Individual/Group Address Bit.) The hex�decimal repr·esentation
`is: AC-DE-48-00-00-80
`
`The Individual/Group (1/G) Address B1t (lr..;t bit of octet 0) is
`used to identify the destination addresR either as an individual
`or as a group address. If the Individual/Group Address Bit is
`
`o, it indicates that the address field contain$ an individual
`address. If this bit h: 1. the address field contains a group
`<lddr·ess that identifies one or more (or all) stations connected
`to the LAN. The all-stations broadcast address is a specldl,
`pre-defined group address of all 1 · s.
`
`The universally or Locally Administered Address Bit (2nd bit of
`octet 0) is the bit directly follo1�ing 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 I HP, Network Computing Architecture Remote Procedure Call Run Time Extensions
`
`
`
`Specification Version OSF TXI.O.ll Steven Miller July 23, 1992 (Chapter
`
`10 describes UUID
`allocation)
`
`
`
`A GUID has the following wire fonnat:
`
`Page 302 of 544
`
`

`
`
`
`i'iicrosoft Corpor.;�lo.' ':. :Jto:"c�re 'rror�nil:ctio:l ';"ec:.: o�o�:y
`
`
`
`(define-type GUID
`( {DWORD ddtal)
`('tiORD ddta2)
`{':lORD data3)
`{BYTEIBJ dctta4)))
`
`4B.XID
`
`Each �ntity, �.g., cardholder, merchant, bank, in STI has a GUID. In the Microsoft implementation, the
`
`
`
`
`
`
`
`
`of this GUID is the lifetime of the installation of the STI software. It is possible for the same entity
`lifetime
`
`
`to have many GUIDs: typically one for every time SIT soflware has been installed.
`
`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.
`
`SIT-compliant applications must guarantee that the serial number never decrease for a given GUID, and
`
`
`
`
`
`
`
`
`
`U1at the GUID is generated by validated software when SIT 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.
`
`SIT-compliant
`applications shall guarantee idempotency of the protocol by examining X IDs. 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
`( (Q'..VORD Set·ialNumber) ;Per·-Guid, non-decreasing
`{GUID InstallationGuid)lJ
`
`4C. CMoney
`
`
`
`All amounts in SIT are contained in CMoneys, which appear as follows:
`
`(define-type CMoney
`((WORD CountryCode) ;ISO 4217 Country Code.
`{QWORD Amount))) ; fixed-point vii th four decimals
`
`40. DATE
`
`A QWORD representing the number of 100-nanosecond intervals since midnight
`UTC at the beginning
`of 1
`
`
`
`
`
`Jan 1601.
`
`(define-type DATE
`(QWORDJ)
`
`4E. TLV
`
`
`
`
`
`
`
`
`
`(Tag. Length, Value) A TL V is a metadata format for generic, self-describing. byte-packed, streamed.
`
`Page 303 of 544
`
`

`
`
`
`aggregate data objects.
`
`to support
`forward and backward compatibility. Old software will be able
`Messages arc composed ofTLVs
`
`
`
`to read new messages because it will tags it does not recognize. New software will continue to read old
`
`messages since tags arc never removed from the TLV tag space documented below.
`
`The full notation
`for a TL V is
`
`(<Tag> <Length> <Value>}
`
`where <Tag> is replaced with a member of the Tag Space documented below,
`<Length> is a byte count for
`
`of the kind shown so far and to follow. This denotes the <Value>, <Value> is replaced with actual notations
`
`
`a TLV with the indicated Tag, Length, and Value. There arc 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>)
`
`to give the
`denotes this case. Since TLV notations tend to becoml� deeply nested, it is sometimes convenient
`
`The name is written
`value 11cld a symbolic name for documentation purposes.
`
`in a comment on the same line
`as the tag:
`
`(<Tag>
`<Value>}
`
`;My Value's name ls •roo·
`;This is the definition of "Foo•
`
`Note 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 canicd out in embedded
`Cambtidge Notation.
`
`
`
`In some cases, the Value is an undifferentiated byte stream. The notation may be further streamlined in these
`
`
`
`
`
`
`cases by omilling the Value altogether, resulting in merely
`
`(<·rag>)
`
`On the wire, all TLVs appear as follows:
`
`((DWORD
`dwTag}
`(DWORD
`dwLength}
`(BYTE[dwLengthl rgbValue)J
`
`4F.TV
`
`(Tag, Value) A TV is an optimized metadata format similar to TL Vs except that the length of a TV is either
`
`
`the Length field and therefore by another method, as with CStrings, Statically known or can be detem1ined
`
`
`
`of a TLV is unecessary.
`
`The notation
`
`(<Tag> <Value>}
`
`sumces for TVs, with a possible
`name as a comment.
`
`On the wire, TVs appear as follows:
`
`8 of 28
`
`Page 304 of 544
`
`

`
`( (D\�ORD
`d�r�'fag)
`(BY'T'Eikno'tlnLength) rgbValue))
`
`4G. RSAKey
`
`This is the type of RSA Encryption and
`Keys. SIT RSA moduli have the followinglengths:
`Signature
`
`• r<oot signature key:
`20tJ8 bits {256 byte!'.)
`* All other signature keys:
`1024 bits {128 bytes)
`* Issuer 4 Acquirer key-exchange key$:: 1024 bits {128 bytes)
`768 bits { 96 bytes)
`* Merchant key-exchange kay:
`* Client key-exchange key:
`512 bits { 64 bytes)
`
`Thus. there ar�! four key formats,
`by key size. On the wire, RSA keys appear as follows:
`distinguished
`
`((BYTE(41
`"RSAl")
`(D:-JORD
`;bit length of modulus
`cbitsMod)
`(D'i'iORD
`;public exponent
`publicexp)
`modulus))
`(BYTE(cbitsMod/8]
`;modulus data, little-endian.
`
`symbolic names (which are used frequently in
`the
`The complete RSA Key block typess have the following
`rest of this document)
`the 12 bytes of overhead documented
`above:
`and sizes, including
`
`* RSA2K: 268 B (cbitsMod
`204/;l)
`* RSAlK: 140 B (cbitsMod
`1024)
`* RSA.75K: lOU 8 (cbitsMod
`76!l)
`� RSA.SK: 76 8 (cbitsMod
`512)
`
`to the type system:
`composites
`useful to add the following
`It is therefore
`
`(define-type RSA-common
`((BYTE( 4) "RSAl")
`(D\·10RD cbi ts�1od)
`(DWHW publicExp)))
`
`(define-type RSA2K
`<BYT£12561 modulus))}
`(RSA-common
`{define-type RSAlK
`(BY'I'E(l281 modulus)))
`(RSA-common
`(BYTE [96] modulus)))
`{define-type RSA.75K
`(RSA-common
`(BYTE [641 moduluc)JJ
`(de(inc-type RSA.SK
`(RSA-common
`
`4H. DESKey
`
`This is the RSA Envelope for DES keys and bank card Account Numbers. DESKeys are used to hide DES
`randomly and used to encrypt
`The DES keys are generated
`keys and account numbers from adversaries.
`bulk financial data.
`
`to document a
`below. It would be possible
`to RC4Keys, documented further
`There is some similarity
`to document DESKeys and RC4Keys separately,
`but it was deemed less confusing
`common abstraction,
`despite the common elements.
`
`RSA-encrypted
`The first 12 bytes are header data in the clear. Following the header data is a 128-byte,
`with Optimal Asymmetric
`vector. A DEKB is a DESK diffused
`DEKB. and then an 8 byte initialization
`by Bellare and Rogaway ill for diffusing
`Encryption
`the contents
`Padding (OAEP), a method first described
`infonnation-theoretic
`attacks.
`to forestall
`of RSA envelopes
`
`9 of 28
`
`Page 305 of 544
`
`

`
`All DESKt!ys arc the same length since they arc all encrypted with RSAI K keys. All DESKeys arc
`
`12+ 128+8= 148 bytes long, with 12 bytes or fixed overhead, 128 bytes of RSA-cncryptcd
`DEKB. and 8
`
`
`byt.:s containing an initialization vector.
`
`
`
`First. we describe DESK. then DEKB, and finally DES Key
`
`
`
`DESK
`
`A DESK is a plaintext DES key concatenated with a Bank Card Account Number of at most 32 bytes. Its
`
`
`
`format is:
`
`(def�ne-type DESK
`( (OWORD
`8 cbKcyPropet·)
`(BYTE ( 8)
`rgbKey)
`;the DES key proper
`;actually, up to 32 bytes
`(DWORO 32 cbBankCardNumber)
`;bank card number
`BCN)
`(BYTE[32)
`(BYTE[71] 0 padding)))
`
`;total length = 119
`
`keys in SIT is always 128
`Every DESK is 119 bytes long because the RSA modulus for encrypting DES
`bytes = I 024 bits and nine bytes arc needed for OAEP and overflow protection.
`
`in FIPS 81.
`Each byte or rgbKey contains 7 bits of key data+ I check bit in position
`0, as specified
`
`
`
`The byte length of the bank card number data must be less than or equal to 32. The data fomlat is
`application-dependent.
`
`DEKB
`
`
`
`To diffuse a DESK and. thereby, to create a DEKB:
`
`I. Generate a fresh, 8-byte, random RC4 key --the OAEP key
`
`2. Gcnaatc 119 bytes from RC4 using the OAEP key
`3. X Of\ these bytes into DESK, resulting
`in DiffusedDESK
`
`4. Hash DiffusedDESK with SHA
`5. XOR the OAEP key with the hash, resulting in rgbHx
`
`resulting 6. Concatenate rgbHx and a byte of overt1ow space 10 DiffusedDESK,
`
`
`
`in DEKB
`
`
`
`The plaintext of a DEKB, then, is the following:
`
`(define-type DEKB
`( (BYTE(119] DiffusedOESK)
`rgbHx)
`(BYTE\81
`(BYTE
`0 padding))) ;prevents overOow 1�hen
`;exponentiating
`
`To reverse the process,
`a DESK from a DEKB, do the following:
`recovering
`
`I. Hash DiffusedDESK with SHA
`
`2. XOR rgbHx with the hash, resulting
`in the OAEP key
`3. Generate 119 bytes from RC4 using the OAEP key
`4. XOR these bytes into DiffusedDESK,
`
`resulting in DESK
`
`
`
`
`
`
`
`
`The DESK. finally, may be used to decrypt other, DES-encrypted data outside
`the RSA envelope.
`
`10 of 28
`
`Page 306 of 544
`
`

`
`the entire DES Key fom1at can be desribcd:
`Finally,
`
`(de[lne-type
`DES Key
`1
`( (BYTE
`l<eyBlockType)
`2
`(BYTE
`l<eyVersion)
`(WORD
`re�:ervedWord)
`334
`(DWORD
`Ox0000CC01
`a) godthmldent i r ier)
`(0\-IORD
`Ox00014800
`l<eyExchAlgldO!RSA)
`(RSAlKE
`DEKB)
`DEKB
`;RSA-encrypted
`(8YTE(8)
`InitVector)) ) ; DES IV, a!> in
`FIPS 81
`
`The notation (RSAIKE 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 RSA I K (all DES Keys arc
`
`with RSA !Ks). To recover DEKB, one must know the modulus and the secret.
`encrypted
`RSA private key.
`
`to recover a DESK. Given DEKB, one must further undo OAEP as described
`
`
`41. RC4Key
`
`This is thl! RSA Envelope for protecting RC4 keys. These keys arc used in the International version of STT
`
`
`
`
`
`
`responses, and credential responses. for bulk encryption of receipts, the GSO. authorization
`
`There is some similarity to the RSA Envelope fonnat for DES keys and hank card account numbers,
`the header data
`12 bytes of an RC4Key arc header data in the clear. Following
`
`documented above. The first
`
`
`
`a diffused contains is an RSA-encrypted REKB and three bytes of salt. A REKB, in the RC4 context,
`
`as with DESKeys. An RC4K is an RC4 Plaintext Key Block. REKBs come in
`RC4K. via OAEP, exactly
`
`the size of the corresponding RSA modulus. Since nine bytes
`
`lhree lengths: 128, 96, and 64 bytes, equaling
`
`
`of the REKB are needed for OAEP and overl1ow 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
`
`
`First. types for known implicilly, by the context of the allowed RSA key length used for its final encryption.
`
`
`lhen the types of the three lengths of RC4Keys are
`the three kinds of RC4Ks and REKBs are defined,
`defined.
`
`RC4K
`
`
`
`RC4 keys. Then.� are three different RC4Ks, con·esponding to the three RSA modulus sizes for encrypting
`
`
`
`
`
`
`
`(def.ine-type LengthAndKey
`( (DWORD
`5) ;STT RC4 keys are always S bytes long
`(BYTE(SJ rgbKeyProper)))
`
`(define-type RC4KlK (LengthAndKey (BYTE[llO] 0 padding))}
`
`(define-type RC4K.75K (LengthAndKey (BYTE(78) 0 padding)))
`(define-type RC4K.SK (LengthAndKey (BYTE[46J 0 padding)))
`
`REKB
`
`
`
`There are three REKB's corresponding to the three RSA modulus sizes:
`
`(define-type OAEPkeyPad
`( (Bl'TE(8) rgbHx)
`(BYTE 0 padding)) )
`
`;obscured OAEP key
`;RSA overflow pr·otection
`
`(define-type REKBlK ( (BYTE(ll9] DiffusedRC4K) (OAEPkeyPad)))
`
`11 of .28
`
`Page 307 of 544
`
`

`
`(define-type REKI3.75K ( (BYTE[87) Diffusedf<C4K} (OAEPkeyPad)) l
`(define-type REKB.SK ((BY'IE(SS] DiffusedRC4K) (OAEPkeyPad)} )
`
`rgbEKey ami an OAEPkeyPad.
`Each of these REKBs contains an
`The process for creating a REKB from a
`
`
`RC4K is analogous to the process for creating a DEKB from a DESK. The process i s
`
`I. 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 an RC4K, resulting in DiffuscdRC4K
`
`4. Hash DiffusedRC4K with SHA
`5. XOR the OAEP key with the hash, resulting
`in rgbHx
`
`
`
`
`6. Concatenate rgbHx and a byte of overtlow space to DiffusedRC4K, resulting in a REKB
`
`
`
`To reverse the process, recovering a RC4K from a REKB, do the following:
`
`
`
`I. Hash DiffusedRC4K with SHA
`
`2. XOR rgbHx with the hash, resulting in the OAEP key
`
`3. Generate 119 bytes from RC4 using the OAEP key
`4. XOR these bytes into DiffusedRC4K, resulling in an RC4K
`
`
`
`
`The RC4K. finally, may be used to decrypt other, RC4-cncryptcd data outside the RSA envelope.
`
`
`
`
`
`Finally. there are lhree kinds of RC4Kcy:
`
`RC4KcyCommon
`(define-type
`1 keyBlockType)
`((BYTE
`2 keyVers ion)
`(BYTE
`16718 reser·vedvlord)
`{WORD
`OxOOOODOOl algorithmJdentifierl
`(IYtiORD
`(DviORD
`
`Ox00014800 keyExchAlgidOfRSA)) )
`
`{deCine-type RC4KeylK ;tOtdl length = 143
`
`((RC4Keycommon com)
`(RSAlKE REKBlK} ;RSA-cncrypted RBKB
`{BY'l'E[3J rgbSalt) ll ;Key salt
`
`(define-type RC4Key.75K ;totdl length; 111
`({RC4Keycommon com}
`(RSA. 75KE REKB. 75K} ; RSA-enc rypted REKB
`(BYTE(3) rgbSalt)}) ;Key salt
`
`(define-type RC4Key.SK ;total length = 79
`( (RC4Keycommon com}
`(RSA.SKE REKB.SK) ;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 RSA 1 K, RSA.75K, or RSA.SK. To recover
`
`
`
`REKB, one must know the modulus and the secret, RSA private key. Given REKB, one must funher undo
`OAEP as described.
`
`The tina! 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. TL V ffV Tag Space
`
`12 of 2 8
`
`Page 308 of 544
`
`

`
`software This section contains symbolic names and numerical values for TLV and TV tags. STT-compliant
`
`
`
`should not usc values that do not appear in this table. A range of keys is set aside for application-dependent
`usc. No version of STT will ever use these tags.
`
`(TI.V_NULL
`OxOOOOOOOOl
`(l'V_DUALHASH
`Ox00000021l
`II fot dual BignHLure
`(TV_HASII
`Ox00000022)
`II hM:h v.:�lue
`('rV _ROOTS I GNA TURF.
`II root cigndture
`Ox0000003F)
`.11 signature on cred
`rrv_SlGNATURE
`Ox00000040)
`11 signed datd
`('fLV _s lGNED_DATA
`Ox00000041l
`II bi nmy duL"
`(TLV_DATA
`Ox00000042l
`(TLV_ENCRYPTED_OATA
`II encrypted duta
`Ox000000'13)
`(rLV_DUALSIGNED_DATA
`Ox00000045)
`II dual-signed data
`(TLV_KEYBLOCK
`Ox00000046)
`II key exchange block
`('fLV _AUTH INFO
`Ox00000047l
`II authorization in!ormc�tion
`(TLV_CARDINFO
`Ox00000048}
`II bank cDrd inro
`(TLV_CARD_NONCE
`I I tor c,,rd no.
`Ox0000004A)
`(TLV_HASHED_DATA
`Ox0000004B)
`II hashed. unsigned data
`(TV_VERSION
`11 ver�ion Information
`Ox0000014C)
`('TLV_OATA_FLAG
`Ox0000004D)
`II message Cormat info
`(TV_DA'TA_FLAC
`Ox00000102)
`II messc�ge format fldg
`
`(TV_Ct�I'U<ID
`II tran�action id
`Ox00000103)
`(TV_�IEk_NAI'IE
`Ox00000104l
`II merchant name
`(TV_ C�lR_AMT
`II amount req. by cardholder
`OxOOOOOlOS)
`(TLV_SHIP_INFO
`II chipping information
`Ox00000106)
`(TV_CH/\RUE_SLIP
`Ox00000107)
`I I charge t.li p
`(TLV_DE'I'AILS
`Ox00000108)
`I I details
`(TV_C.I\RD_NAME
`Ox00000109)
`I I name d!·. on cc1rd
`(TV_EXP _rlATE
`Ox0000010A)
`II card expiration date
`(T!,V_BILLINC_INFO
`OxOOOOOlOB)
`II billing information
`II transacLlon ld
`{TV_XID
`Ox0000010D)
`(TV _ISSUER
`/1 issuer name
`Ox0000010E}
`('!V_RCPT_F'LAG
`Ox0000010F)
`II tail flag in receipt
`('l'V_RCP'l'_MSG
`II message in receipL
`OxOOOOOllO)
`(TLV_HASH_NONCE
`11 for gso hashing
`OxOOOOOlll)
`(TV _CRDRSP _CODE
`11 cred response fail code
`Ox00000112)
`(TV_ATHRSP _CODE
`II auth tesponse fail code
`Ox00000113)
`(TV .YIER_AMT
`Ox00000114)
`II amount req. by merchant
`(TV_RCPT_AMT
`OxOOOOOlJS)
`I I amounL chgd by merch.�nt
`
`II Tags for credentials (all have the 13th bit set)
`
`(TLV_CRDINFO
`Ox000010011
`II Cred common in(o
`(TV_CROSERIALNUM
`Ox00001002)
`II Cred serial number
`(TV_CRDOWNER
`Ox00001004)
`II Cred owner name
`(TV_CRDROOTNAME
`Ox00001008)
`II name of the Cred root
`(TV_CRDLEVEL
`Ox00001011)
`II level in trust hierarchy
`(TV_CROVALIDITY
`Ox00001012)
`II dates of validity
`(TV_CRDACCTHASH
`11 hash or acct i etc
`Ox00001014)
`(TLV_CRDI<EY
`Ox00001018)
`11 public key value
`(TLV_CRDKEYEX
`Ox00001020)
`II extra public key
`(TLV_SICNERCRD
`Ox0000102ll
`11 credo! signer
`(TV_CARDTYPE
`II card type field
`Ox00001022)
`(TLV_MERACCTNUM
`II mer acct I with acquirer
`Ox00001023)
`(TV_CREATOR
`Ox00001024)
`II vendor identifier
`(TV_ALTERNATE_NAME
`II alternate name
`Ox00001025)
`(TV_KEY_ID
`Ox00001026}
`II public key id
`(TV_KEY_IDEX
`1/ extra public key id
`Ox00001027)
`(TLV_INSTITUTION_ID
`Ox00001028}
`II institution identifier
`(TLV_CRD_CARDHOLDERSIG
`II cardholder sig Cred
`Ox00001802)
`(TLV_CRD_CARDHOLDEREXCH
`Ox00001803)
`11 cardholder key exch Cred
`
`Page 309 of 544
`
`

`
`:�o:.c� osoft Corporation'
`&r.!;dCtlO!'"i 'f&chnology
`:;i Gecu: t Tr
`
`I I merchant r.;ig creo
`(TLV_CRD_NERCIIAN'l'SIG
`Ox00001804)
`II merchant key exch Cred
`(TLV_CRD_I•IERCHANTEXCH
`OxOOOOJ805)
`II acquirer r;ig Crcd
`(TLV_CRD_ACQUIRERSIG Ox00001808)
`(TLV_CRD_ACQUIREHEXCH Ox00001809)
`II acqu i r·er key exch Cred
`(TLV_CRD_CAEXCH Ox00001813)
`II bindery key exch Cred
`('TIN _CRD_ CAROl SSS IG
`II ir>sucr sig crcd
`Ox00001814)
`II ir.,cucr key exch Cred
`(TLV_CRD_CARDISSEXCH Ox00001815)
`II brand !; ig Cr·ed
`(TLV_CRD_BR.;NDCASIG Ox00001818)
`(TLV_CRO_BRANDCAEXCH Ox00001819)
`II brand key exch Cred
`
`I I values for card type£: in 'l'V_CARDTYPE
`
`(VISA
`(RESERVED
`(RESERVED
`(RESERVED
`(RESERVCD
`
`Ox2)
`Ox3)
`Ox4)
`Ox5)
`Ox6)
`
`11 Tags for credential requests
`
`(TLV_SIGKEY
`(TLV_EXCHKEY
`(TLV_SIGKEYEX
`( TLV _EXCHKEYEX
`
`Ox00002001)
`I I sig key in Cred r·eq
`II key-exch key in Cred req
`Ox00002002}
`II extr.:� slg key in Cred req
`Ox00002004)
`II extra key exch key
`Ox00002008)
`
`II
`Tags tor message component f.>
`
`(TLV_GSO
`Ox00004001)
`(TLV_PI
`Ox00004002)
`(I' LV _HERCHANT _REQUEST Ox00004004J
`(TLV_CRD_RESPONSE Ox00004080)
`('TLV_E�IERGENCY llx00004100)
`
`Tags tor message types
`II
`
`!TLV_Ct�RCRDREQ
`(TLV_MERCRDREQ
`(TLV_CMRCRDRSP
`· {TLV_MERCRDRSP
`(TLV_PURORD
`<TLV_ATHREQ
`(TLV_ATHRSP
`(TLV_RCEIPT
`
`Ox00008002)
`ox00008003)
`Ox00008006)
`Ox00008007)
`Ox00008009)
`Ox0000800A)
`OxOOOOBOOB)
`OxOOOOSOOC)
`
`II
`Reserved Range; width 4096
`
`(t·ISAPP _RESERVED_FIRST OxOOOOAOOO)
`(HSAPP_RESERVED_LAST OxOOOOAFFF}
`
`II
`Tag range reserved for VISA
`
`(TLV_VISA_FIRST Ox00020000)
`(TLV_VISA_l.AST Ox0002FFFF)
`
`II
`User-Defined Tag range -- not used by
`STT
`
`(TLV_USER_FIRST OxOOBOOOOO)
`(TLV_USER_LAST
`OxOOBFFFFF)
`
`II
`mask for extended TAGS for the future
`
`(TLV_EXTENDED
`
`Ox80000000)
`
`14 ()f 28
`
`Page 310 of 544
`
`

`
`6. Credentials
`
`SIT messages often contain credentials, also called just creds hereafter. An SIT 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. Then: is an analogy to certificates in other public-key
`systems.
`
`
`
`However, credentials arc SJ)I!Cializcd to STT. they do not aflinn general identity, and must not be
`
`mistaken for certificates.
`
`policy is om-of-band for SIT. In other words. it is completely up to banks and higher
`
`
`
`Authentication
`
`
`
`
`
`
`authorities in the trust tree to decide whether to issue credentials. When an acquiring bank receives a
`
`
`request from a merchant, the bank must satisfy itself
`credential
`that the merchant is in good standing
`before
`
`
`
`an STT credential. Options for so doing include visiting the merchant face-to-face, checking
`issuing
`
`
`credential request fields via telephone,
`
`
`fax, or email, and so on. Similarly, issuers must satisfy themselves
`
`
`that cardholder credential requests
`are valid. Options include a phone call and "mother's maiden name"
`or simply
`
`
`
`on diskette, the credential questions, a separate paper mailer to an address on file containing
`
`
`
`
`
`
`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. SIT addresses this
`
`
`
`
`
`
`requirement by packaging new credentials in crcdcnrial response messages encrypted under the
`
`
`
`key-exchange key of the requestor. However. this alone docs not prevent the requestor from being an
`impostor.
`
`To reduce sizes of messages that do not need both kinds. key-exchange
`credentials
`credentials and signature
`
`
`
`
`
`arc 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
`
`account with some assurance that the owner
`number and allows others to encrypt data to the owner of the
`
`
`
`of credentials. The Common Fields can be trusted with encrypted data. There are several different kinds
`
`
`
`
`
`appear in all credentials. Other fields only appear in certain kinds of credentials. A credential is a 11... V. Its
`
`detailed fom1at follows:
`
`CRD
`
`;see explanation below
`(TLV_CRDTAG•
`;juKt a container
`(1'LV_OATJI
`;see explanation below
`(TV_CRDLEVEL WORD)
`(TV_VERSION (OWORD Ox00000110))
`(TV_CREATOR
`assigned by card brand, MS is 1
`((WORD wReserved) ;vendor �
`;reserved for vendor
`(OWORD dwAbilities)))
`;assigned by cred creator
`(TV_CRDSERIALNU�1 BYTE[16))
`Cstring)
`;•subject name•
`(TV_CRDOWNER
`(TV_ALTERNATE_NAME CString)
`(TV_CRDVALIDITY
`((DATE GoodFrom)
`(DATE GoodThru))))
`
`CDF
`SignatureSection)
`
`;CredType-dependent Fields
`;sec explanations below
`
`
`
`In this (somewhat abstracted, and therefore impure) notation, TLV _CRDTAG* refers to one of the
`
`
`
`
`following:
`
`TLV_CRD_CAROHOLDERSIG Ox00001802
`slg cred for cardholder
`TLV_CRD_CAROHOLDEREXCH Ox00001803
`key exch Cred for cardholder
`TLV_CRO_MERCHANTS!G Ox00001804
`sig Cred for merchant
`
`Page 311 of 544
`
`

`
`:�:cro�oft Co1poro.t ion·:; :>ac�r &- Trd.nso.ccio�. Tr�crtno:c..�.:y
`
`Tl.V _CRD_�IERCIIANTEXCH Ox00001805 key exch Cred for merchant
`TLV _CRD_ACQUl REf<S IG oxo0001808 cig cr·cd for acguirer
`TLV_CfW_ACQUIREREXCH Ox00001809 key cxch Cred for acquirer
`TLV_CHD_CACXCH
`Ox00001Sl3 key exch Cred for bindery
`T LV _CF<D_CAHDI SSS J G Ox00001814 r-:ig cred for cdrd is..; suer·
`
`TLV_CRO_C.!;I<DI SSEXnl Ox00001815 key exch erect fo1· card ir.;r.;ue:t
`TLV _CRD_BH/\NDCASIG Ox00001818 r,ig Crcd for brand bj nder·y
`TLV_CRD_BHMIDC/·.CXCfl Ox00001819 key cxch Crcd for brand bindery
`
`The TV _CRDLEVEL is a WORD containing the height of the credential
`
`in the tmst tree. The height is n
`
`
`
`
`
`for leaf credentials. i.e., cardholders and merchants. Issuers and Acquircrs have height I, meaning they can
`
`
`
`
`have height2, meaning they can sign Authorities Brand Credential sign the credentials of leaf entities.
`
`Ievel-l credentials,
`
`i.e., Acquirers and Issuers.
`
`There arc different
`
`Credential Type-Dependent
`
`
`
`mutually exclusive: any credt.!ntial may have only ont.! of them.
`
`
`
`Fields for each type of credential. The following streams are
`
`CDF
`
`
`For cardholder key-exchange credentials.
`
`
`
`
`CDF should be replaced by
`
`( (TV_CARDTYPE
`loiOHD)
`(TV_CRDACCTHASH
`BYTE[20))
`(TV_KEY_tn
`D�:ORD)
`(TLV_Cf<DKEY 76
`RSA. SK))
`
`;VISA is 2, all otherc are reserved
`;see explc�ndtlon below
`;assigned by key generator I o•.-mer
`
`card nonce. card account number, The TV _CRDACCTHASH contains the SHA hash of the concatenated
`
`
`
`
`
`and expiration date stting -in this specific order
`
`
`
`Cardholder Signature Crds have the following
`CDF:
`
`
`
`( {'f'V_CARDTYPE \-lORD)
`; VISA is 2, <tll others <tre reserved
`{']'V_CRDACCTHASH BYTE(20))
`;as \vi th cardholder Key-exchange
`Creds
`(TV_KEY_Hl DWORD)
`;assigned by key generator I o•,;ner
`(TLV_CRDKEY 140 RSAlK))
`
`
`
`
`
`Merchant signature. Creds have the following CDF:
`
`((TV_CARDTYPE WORD!
`(TLV_MERACCTNUM)
`(TV_KEY_ID
`DWORD)
`(TlN_CRDKEY 110 RS/\lK))
`
`;identifies merchant to acquirer
`;assigned by key generator I owner
`
`
`
`
`
`
`
`Acquirer, Issuer, and Brand Bindery erects all share the same CDF formats:
`
`( {TV_CARDTYPE DWORO)
`(TLV_INSTITUTION_ID)
`;assigned by cred signer
`(TV_KEY_ID DI�ORD)
`;assigned by key generator I owner
`(TV_CRDROOTNAME CString)
`;name ot root of trust tree
`(TLV_CRDKEY 140 RSAlK))
`
`
`
`The root credential authority key-exchange Cred has the following CDF:
`
`
`
`
`
`
`
`( (T!..V_INSTITUTION_ID)
`lTLV_CRDKEY 140 RSAlK))
`
`
`
`Merchant key-exchange erects contain the following CDF fields:
`
`
`
`
`
`Page 312 of 544
`
`

`
`( ('TV_CARDTYPE
`D't!ORDl
`;identific� merchant to acquirer
`('TLV _t�ERACCTNUM)
`(T·V_KEY_IO
`0!\'0RD)
`;assigned by merchant
`RSA. 75K))
`(TLV_CRDKEY 108
`0\>IORD}
`
`(TV_KEY_lDEX
`("rLV_CROKEYBX 140
`RSAlK))
`
`;a:.r.igncd by acquir·cr·
`
`Merchant key-exchange crcds include the public key-exchange key of the merchant's acquirer in the
`
`
`
`
`
`TLV _CRDKEYEX. This enables cardholder software to encrypt the PI to the a�.:quircr and thl! GSO to the
`
`
`
`
`merchant. The acquirer nonnally signs this crcd, vouching for both keys.
`
`SignatureSectlon
`
`Following the Credential Type-Dependent 1iclds, a cred includes the creds, recursively. of its signing
`
`
`
`
`
`
`
`
`
`created by the signers. Software will verify the signature on the crcd. then the
`
`authorities and the signatures
`
`by a rom key is reached. A failure at any level of
`signature
`on the signer's cred, and so on, until a signature
`Sec the cryptogrnphy section for
`
`
`this recursive check must result in a failure to verify the leaf signature.
`
`
`details on PKCS # 1 signature fonnat.
`
`contains signer cred£
`;recurslvely
`((TLV_SIGNERcr<P)
`BY'fE I 256 I)) ; PKCS 11 sig
`(TV_f<OOTSlGNATURE
`
`
`
`or, in the case of creds signed dirt:clly by the Root Credential Authority (normally, these arc just
`
`
`
`
`
`
`sub-authority creds)
`
`(TV_ROOTSICNATURE BYTEI256)) ;PKCS n sig
`
`7. Message Formats
`
`An SIT Transaction
`of 2 or, in one case, 4 messages.
`Every SIT message can be assigned
`consists
`unique XID. Every SIT message has its XID explicitly
`unambiguously to its transaction via
`a globally
`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 tlow from entities lower in the trust hierarchy to higher entities.
`to lower. Downward messages may include piggybacked
`Downward messages flow from higher authorities
`
`
`Emergency messages support global root key replacement in the (very unlikely) case
`Emergency messages.
`
`of SIT will ONLY replace the root key if the
`
`of root key compromise. A proper implementation
`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 support 800 number or an ad in a prominent
`
`on the Emergency message prevents denial of service attacks, and the hash check
`newspaper. The signature
`source. All Message content fields are TL V rrv s.
`ensures that users get crucial infonnation
`from a trusted
`
`A message may be either signed, dual-signed, or hashed, and finally, it may be encrypted. Any signing or
`
`
`
`a TV _DATA_FLAG. which
`
`
`
`hashing is always done before encryption. Every message component includes
`the message content with a WORD specifying
`precedes
`as follows:
`extra processing,
`
`Bit# Mask
`
`Data Form
`
`1
`2
`4
`5
`
`Ox0002
`Ox0004
`OxOOlO
`