Page tree
Skip to end of metadata
Go to start of metadata



This page was imported from 80000502-001 ID TECH Encrypted Data Output Formats.pdf It's not perfect click this link to view the original pdf.




    1. 80000502-001*

      ID TECH
      Encrypted Data Output
      Rev. G Revised 11/20/2017

      International Technologies & Systems Corporation
      10721 Walker Street, Cypress, CA 90630-4720; Tel: (714) 761-6368; Fax (714) 761-8880
      www.idtechproducts.com
      Copyright 2016 by ID TECH. All rights reserved.


      Table of Contents

      SCOPE5
      ENCRYPTION STANDARDS 5
      KEY MANAGEMENT 6
      DECRYPTION 6
      TERMINOLOGY: MSR VS. EMV6
      GLOSSARY7
      OUTPUT FORMAT OVERVIEW8
      HIGH LEVEL OVERVIEW 8
      NOTATIONAL CONVENTIONS 8
      ID TECH ENHANCED ENCRYPTED MSR DATA OUTPUT FORMAT9
      FIELD DESCRIPTIONS 11
      Field 1: STX11
      Field 2: Data Length11
      Field 3: Card Encode Type11
      Field 4: Track Status12
      Field 5: Track1 data length12
      Field 6: Track2 data length12
      Field 7: Track3 data length12
      Field 8: Clear/mask data sent status byte13
      Field 9: Encrypted data sent status13
      Field 10: Optional-bytes length13
      Field 11: Optional status byte 114
      Field 12: Track1 clear/masked data14
      Field 13: Track2 clear/masked data14
      Field 14: Track3 clear/masked data14
      Field 15: Track1 encrypted data15
      Field 16: Track2 encrypted data15
      Field 17: Track3 encrypted data15
      Field 18: Session ID (Security level 4 only)16
      Field 19: Track1 hash (if encrypted and hash track1 allowed)16
      Field 20: Track2 hash (if encrypted and hash track2 allowed)16
      Field 21: Track3 hash (if encrypted and hash track3 allowed)16
      Field 22: Reader Serial Number (optional)16
      Field 23: KSN (DUKPT only) or Key ID (TransArmor).16
      Field 24: MAC Value Length17
      Field 25: MAC Value17
      Field 26: 10 bytes KSN for MAC DUKPT Key.18
      Field 27: CheckLRC18
      Field 28: CheckSum18
      Field 29: ETX18
      SAMSUNG PAY/MST SUPPORT 19
      CARD TYPE 19
      ISO/ABA CARD 20
      JIS CARD OUTPUT 21
      MSR DATA EXAMPLES21
      Example: MSR Output from a USB-HID/RS-232/UART Interface22
      Example: MSR Output from USB KB and PS/2 Interface, Format 124
      Example: MSR Output USB HID/RS232/UART Interface, Format 226
      Example: Enhanced Manual Entry Output Format28
      Example: Enhanced Manual Entry with ADR and ZIP Output29
      Example: MSR Output Format with TransArmor TDES-DUKPT30
      ENCRYPTED EMV DATA32
      Encrypted TLV Packaging: Method One32
      Encrypted TLV Packaging: Method Two33
      TAG ENCODING 34
      LENGTH BYTE SEMANTICS 34
      TLV ENCRYPTED RESPONSE FORMAT EXAMPLES 38
      Configuration Note39
      Tag5A Value Mask Configuration Note39
      MAC Verification Data / KSN TLV Format46
      DFEF48 (Insufficient RAM) Examples48
      APPENDIX A: TAGS DFEF4B, DFEF4C, & DFEF4D50
      TAG DFEF4B50
      DATA SEARCH ORDER 51
      COMPRESSED NUMERIC ELEMENTS 52
      TAG DFEF4C52
      TAG DFEF4D52h1. SCOPE
      The intent of this document is to explain encoding rules as they apply to transaction data produced by ID TECH payment peripherals that perform encryption.
      Data encodings, in ID TECH products, take two major forms, depending on whether the transaction stems from a magstripe read (MSR) or a chip-card (ICC/EMV) interaction. The two major formats are described in detail here. Data from magstripe transactions will be in the Enhanced Encrypted MSR format. Data from ICC (chip card) transactions will be in a TLV-based format as described in the section on Encrypted EMV Data. Magstripe data (MSD) constructed from contactless interactions are treated as EMV data.
      Once a device has been key-injected and encryption-enabled, no sensitive transaction data will ever be sent in the clear. Non-sensitive data (such as the KSN) continues to be sent in the clear. The purpose of this document is to allow you to know which segments of data are encrypted, and which segments are not encrypted.
      ID TECH offers a Universal SDK that greatly facilitates data parsing. If you can do so, we strongly recommend you use the Universal SDK to obtain and manipulate data objects programmatically (in Java or C#).

      Encryption Standards

      The two industry-standard encryption methods supported by ID TECH products are Triple DES (TDES) and AES. (Depending on customer choice, a given product will support one or the other of these two algorithms, but not both at once.) Triple DES assumes a block size of 8 bytes; therefore, any data that will be TDES-encrypted will be zero-padded to a length that is a multiple of 8 before encryption. AES assumes a block size of 16 bytes. Data will be padded to a multiple of 16 bytes before AES encryption. For both encryption algorithms, cipher block chaining (CBC) is the default mode used in ID TECH products. The initial vector (where applicable) is all nulls.
      No attempt is made here to document TDES or AES encryption methods, since they are industry standards not maintained by ID TECH.
      For information on TDES, see NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, available at the following URL: {+}http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf+
      For information on AES, see FIPS-197, available at: {+}http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf+
      Some ID TECH products support the First Data TransArmor encryption methodology, which uses RSA-based public/private key technology. For information on the TransArmor methodology, see {+}https://www.firstdata.com/downloads/marketing-merchant/TransArmor-+ FAQs.pdf and/or contact First Data Corp. ({+}https://www.firstdata.com+).


      Key Management

      The key management methodology used in ID TECH products that support encryption is predominantly DUKPT (Derived Unique Key Per Transaction). DUKPT results in a unique 16-byte key for every transaction. The same 16-byte key may be used to encrypt or decrypt data using either TDES or AES. (In other words, the choice of key management technology has nothing to do with the choice of encryption technology.) The 10-byte Key Serial Number (KSN), unique for every transaction, is essential for deriving DUKPT keys.
      A full discussion of DUKPT key management methodology is beyond the scope of this document. For details, refer to ANSI X9.24 Part 1, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques: .

      Decryption

      ID TECH card readers do not provide decryption capability in firmware. Decryption of transaction data is usually done on the back end (by the party that will approve and/or clear a transaction). It can also be done in a test environment. But is not typically done in an application, at transaction time, in a live production environment, because the storage or transmission of sensitive customer data in cleartext form runs counter to PCI DSS requirements (and constitutes a "worst practice," in security terms).
      Still, you'll probably want to decrypt data for test/validation purposes. Decryption involves deriving the "working key" (or session key) associated with the data, and then submitting the key and data to the appropriate decryption algorithm. Deriving a one-time key using DUKPT is a somewhat intricate process. ID TECH makes available a decryption tool (at {+}http://www.idtechproducts.com/tooling/file+) that can derive keys using DUKPT, and decrypt data via TDES or AES. The tool is written in HTML and JavaScript, and uses open-source TDES and AES implementations. You may wish to look at the source code in that tool, if you want to see how DUKPT key derivation and decryption can be done.

      Terminology: MSR vs. EMV

      Throughout this document, the terms "magnetic stripe data," "magstripe data," and "MSR data" are considered synonymous.
      ICC transactions are generally either "contact" ("insert") transactions, or "contactless" ("tap") transactions. Throughout this document, we will refer to both contact and contactless as "EMV transactions." Likewise, we will sometimes refer to "EMV data" in the context of transaction data stemming from ICC or NFC interactions.
      Magstripe data (MSD) constructed from contactless interactions are treated as EMV data.
      Manually entered transactions (where the card number, expiration date, etc., are typed into a keypad) are treated as MSR data.


      GLOSSARY

      AESAdvanced Encryption Standard, FIPS-197
      CheckLRCSee LRC below
      CheckSumArithmetic sum of data bytes, ignoring overflow CVVCard Verification Value
      DESData Encryption Standard
      DUKPTDerived Unique Key Per Transaction EMVEuropay, MasterCard, Visa standards
      ETXEnd of Text, 0x03
      EXPExpiration Date
      ICCIntegrated Circuit Card (chip card)
      KSNKey Serial Number
      LRCLongitudinal redundancy check (XOR of data bytes)
      MSD Magnetic Stripe Data (may come from contactless interaction)
      MSRMagnetic Stripe Read (comes from physical read of magnetic stripe) NFCNear Field Communication
      PANPrimary Account Number
      RFUReserved for Future Use
      SHASecure Hash Algorithm
      STX Start of Text, 0x02
      TDESTriple DES (Triple Data Encryption Standard) TLVTag/length/value
      XORExclusive-OR


      OUTPUT FORMAT OVERVIEW


      High Level Overview


      The transaction data produced by ID TECH products will differ in format depending on the device, the mode of the device, and the type of transaction (e.g., magstripe versus ICC contact, versus ICC contactless). This document assumes that the device in question is operating in an encryption-enabled mode. The determining factor in how encrypted data payloads are constructed is whether data originated from a magnetic stripe read, or not.
      Magstripe transactions produce data encoded according to ID TECH's Enhanced Encrypted MSR Format (see below), which is a 29-field format (with some fixed-length fields and some variable-length fields) that can't be fully described without also describing field semantics.
      By contrast, chip-card transactions on EMV-capable ID TECH devices produce "EMV data" payloads that are predominantly constructed as unordered sets of TLV triplets, or so-called "tag/length/value" data. Because of the way TLV payloads are constructed, it's possible to talk about data structure without having to know about data semantics. In this document, we will focus on data structure whenever possible. ASN.1-BER encoding rules for tags are briefly discussed, but actual tag semantics are not. For information about EMV tag semantics, consult the EMV documentation at https://www.emvco.com.
      This document purposely avoids discussion of protocols in order to concentrate on formats. Nevertheless, it should be mentioned that depending on the protocol used, data may come back "wrapped" in various kinds of wrappers. For example, ViVOPay devices will prepend encrypted data payloads with a 14-byte header or preamble consisting of the 10-byte string "ViVOtech2\0" followed by a command byte, status code, and two length bytes (MSB, LSB). Most other devices adhere to a simple protocol that encloses data in a wrapper that begins with STX (0x02) and length bytes, and ends with LRC (longitudinal redundancy check bytes: XOR of the payload), 8-bit checksum, and ETX (0x03). Please consult the appropriate ID TECH Interface Developer's Guide (IDG) or the appropriate product User's Manual for more information on protocol-specific data packagings.

      Notational Conventions

      When bytes are described in terms of bits, we use zero-based numbering of bits: B0 is the least significant bit and B7 is the most significant bit.
      MB LB

      B7

      B6

      B5

      B4

      B3

      B2

      B1

      B0


      Hex values are denoted in various ways: 02h, 'H'02, 0x02 (all equivalent).

      ID TECH ENHANCED ENCRYPTED MSR DATA OUTPUT FORMAT

      For ID TECH products that can read magnetic stripe data, "encrypted output" conforms to a 29-field data format as described below, known as the ID TECH Enhanced Encrypted MSR Data Output Format.
      Payloads of the "Enhanced Encrypted MSR" type are constructed as shown in the following two tables. The first table is for conventional card-swipe data; the second table is for manual- entry data that occurs when a card number is typed into a keypad (during a Card Not Present transaction).
      Take care to note that some data fields are variable-length, and some may not occur at all. For example, Fields 10 and 11 are optional. To determine whether they exist, you will need to examine bit 6 of Field 4 (as discussed further below).

      MSR DATA OUTPUT FORMAT

      Field #

      Length in Bytes

      Optional

      Field Name

      1

      1

       

      STX

      2

      2

       

      Data Length

      3

      1

       

      Card Encode Type

      4

      1

       

      Track Status

      5

      1

       

      Track1 data length

      6

      1

       

      Track2 data length

      7

      1

       

      Track3 data length

      8

      1

       

      Clear/mask data sent status

      9

      1

       

      Encrypted/Hash data sent status

      10

      1

      Y

      Optional bytes length

      11

      Variable

      Y

      Optional bytes

      12

      Variable

      Y

      Track1 clear/mask data

      13

      Variable

      Y

      Track2 clear/mask data

      14

      Variable

      Y

      Track3 clear/mask data

      15

      Variable

      Y

      Track1 encrypted data

      16

      Variable

      Y

      Track2 encrypted data

      17

      Variable

      Y

      Track3 encrypted data

      18

      8

      Y

      TransactionID (Session ID for Security level 4,
      Terminal/Merchant ID for TransArmor)

      19

      20

      Y

      Track1 hashed

      20

      20

      Y

      Track2 hashed

      21

      20

      Y

      Track3 hashed

      22

      10

      Y

      Reader Serial Number

      23

      Variable

      Y

      KSN or Key ID (10 bytes KSN for DUKPT, 10 bytes Key
      ID for fixed key, 11 bytes Key ID for TransArmor)

      24

      2

      Y

      MAC Value length

      25

      Variable

      Y

      MAC Value

      26

      10

      Y

      KSN for MAC DUKPT

      27

      1

       

      LRC

      28

      1

       

      CheckSum

      29

      1

       

      ETX (0x03)



      MANUAL ENTRY DATA OUTPUT FORMAT

      Field #

      Length in Bytes

      Optional

      Field Name

      1

      1

       

      STX (0x02)

      2

      2

       

      Data Length

      3

      1

       

      Card Encode Type (0xC0)

      4

      1

       

      Track Status (0x17 or 0x37)

      5

      1

       

      Track1 data length (0x00)

      <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3b51b57a-7644-435a-b2fe-373494652e62"><ac:plain-text-body><![CDATA[

      6

      1

       

      Length of unencrypted ;PAN= EXP [:CVV]?LRC

      ]]></ac:plain-text-body></ac:structured-macro>

      7

      1

       

      Length unencrypted additional data ZIP and/or ADR

      8

      1

       

      Clear/mask data sent status

      9

      1

       

      Encrypted/Hash data sent status

      10

      1

      Y

      Optional bytes length

      11

      Variable

      Y

      Optional bytes

      12

      0

       

      Empty

      13

      Variable

      Y

      Keyed-in data presented as track 2
      <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6edd1b28-19db-478c-9dda-1a2763dfeb71"><ac:plain-text-body><![CDATA[;PAN=EXP[:CVV]?LRC

      ]]></ac:plain-text-body></ac:structured-macro>

      14

      Variable

      Y

      Additional keyed-in data in ASCII presented as track 3
      <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="099863e1-a966-468d-8054-6c0db8c83933"><ac:plain-text-body><![CDATA[[1ADR=][0ZIP=]

      ]]></ac:plain-text-body></ac:structured-macro>

      15

      0

       

      Empty

      16

      Variable

       

      Encrypted data

      17

      0

       

      Empty

      18

      8

      Y

      TransactionID (Session ID for Security level 4,
      Terminal/Merchant ID for TransArmor)

      19

      0

       

      Empty

      20

      20

      Y

      Hashed (present by default)

      21

      0

       

      Empty

      22

      10

      Y

      Device Serial Number (not present by default)

      23

      Variable

      Y

      Key ID (10 bytes KSN for DUKPT, 10 bytes Key ID for
      fixed key, 11 bytes Key ID for TransArmor)

      24

      2

      Y

      MAC Value Length

      25

      Variable

      Y

      MAC Value

      26

      10

      Y

      KSN for MAC DUKPT

      27

      1

       

      LRC

      28

      1

       

      CheckSum

      29

      1

       

      ETX (0x03)

      Field Descriptions


      Field 1: STX


      Start of Text. 0x02 for most products (0x60 for Spectrum Air and SecureMOIR).

      Field 2: Data Length


      Two bytes, little-endian, representing the length of the data payload (which does not include the LRC, checksum, nor ETX, nor the leading STX, nor the length bytes themselves). In other words, the layout is:
      STX LenL LenH Payload LRC SUM ETX
      The length bytes specify the length of the Payload portion only.

      Field 3: Card Encode Type


      Value Encode Type Description
  1. ISO 7813/ISO 4909/ABA format
  2. AAMVA format
  3. Other
  4. Raw; un-decoded format. All tracks are encrypted and no masked data are sent. No track indicator '01', '02' or '03' in front of each track.
  5. JIS II Only supported in some products.
  6. JIS IOnly supported in some products.
  7. JIS II SecureKey and Secure MIR.
  8. Contactless Visa (Kernel 1)
  9. Contactless MasterCard
  10. Contactless Visa (Kernel 3)
  11. Contactless American Express
  1. Contactless JCB
  2. Contactless Discover
  3. Contactless UnionPay

90 Contactless Others
C0Manual entry enhanced mode (similar to ABA track 2). Values without the high bit set are reserved.

Field 4: Track Status


MSR sampling and decode status flags:
MB LB

0

0

B5

B4

B3

B2

B1

B0


B0 1: Track 1 decode success (0: Track 1 decode fail)
B11: Track 2 decode success (0: Track 2 decode fail)
B21: Track 3 decode success (0: Track 3 decode fail)
B3 1: Track 1 sampling data exists (0: Track 1 sampling data does not exist) B4 1: Track 2 sampling data exists (0: Track 2 sampling data does not exist) B5 1: Track 3 sampling data exists (0: Track 3 sampling data does not exist) B6 1: Field 10 "optional bytes length" exists (0: No Field 10)
B70—reserved for future use

Field 5: Track1 data length Field 6: Track2 data length Field 7: Track3 data length


These one-byte values are the lengths of the actual (raw, unencrypted) Track data. It indicates the number of bytes in the Track masked data fields (Fields 12, 13, 14). It should be used to separate Track 1, Track 2 and Track 3 data after decrypting Track encrypted data field.
For ISO 7813 and ISO 4909 compliant Financial Transaction Cards: Track 1 maximum length is 79 alphanumeric characters.
Track 2 maximum length is 40 numeric digits.
Track 3 maximum length is 107 numeric digits.

Field 8: Clear/mask data sent status byte


Bit 0: 1— if Track1 clear/mask data present Bit 1: 1— if Track2 clear/mask data present Bit 2: 1— if Track3 clear/mask data present
Bit 3: 1— if fixed key; 0 DUKPT Key Management Bit 4: 0 — TDES; 1 — AES
Bit 5: 1— Chip present on card. (First byte of service code was '2' or '6'.) Use EMV transaction if possible.
Bit 6: 1— PIN Encryption Key; 0—Data Encryption Key Refer to ANSI X9.24 2009 Page 56 for details.
Bit 7: 1 — Serial Number present; 0—not present

Field 9: Encrypted data sent status


Bit 0: if 1—track1 encrypted data present Bit 1: if 1—track2 encrypted data present Bit 2: if 1—track3 encrypted data present
Bit 3: if 1—track1 hash data (SHA digest) present Bit 4: if 1—track2 hash data (SHA digest) present Bit 5: if 1—track3 hash data (SHA digest) present Bit 6: if 1—session ID present
Bit 7: if 1—KSN present

Field 10: Optional-bytes length


Number of optional bytes in Field 11. This field exists if and only if bit 6 of Field 4 is turned on.
Rationale: This field (Field 10) is present if, and only if, Bit 6 of Field 4 is turned on. The need for this scheme arises because originally, ID TECH products used a 160-bit SHA-1 digest in "hashed track data" of fields 19, 20, and 21. Later products were required to support a 32-byte (256-bit) SHA-2 digest. The purpose of the bit-6 flag in Field 4 is to signal whether the hashed track data fields use the original SHA-1 encryption (flag is zero) or the longer SHA-2 digest (flag is set). If the flag is set, Field 10 contains the length of Field 11, and Field 11 contains data specifying the type of hash. (Fields 10 and 11 provide an extensibility mechanism in case other SHA digest sizes need to be supported in the future.)

Field 11: Optional status byte 1


Bit 0: If 1—SHA-256. If 0—SHA-1 (Note: SHA-1 is the default if no Field 11.)
Bit 1: If 1—Encryption type follows Field 11 bit 2 &3 &4. If 0—Encryption type follows Field 8 bit 4.
Bit 4, 3, 2: 000—TransArmor. 001—Voltage. 010—Visa FPE. 011—Verifone FPE.
100—TransArmor TDES.
Bit 5: If 1— MAC Value Length, MAC Value, and MAC Key KSN will exist in Fields 24, 25 and 26.
If 0— No MAC Value Length, MAC Value and MAC Key KSN in Field 24, 25
and 26.
Bit 6: RFU
Bit 7: RFU

Field 12: Track1 clear/masked data Field 13: Track2 clear/masked data Field 14: Track3 clear/masked data

For MSR: Track data masked with the MaskCharID (default is '*'). The first PrePANID (up to 6 for BIN, default is 4) and last PostPANID (up to 4, default is 4) characters can be in the clear (unencrypted).

For Manual Input:

Field 12 is always empty.
Field 13 includes PAN, EXP ( in YYMM format) and (CVV) always masked.
The format should be:

  1. ;PAN=YYMM[:CVV]?LRC ';'—start sentinel

'='—field separator between PAN and EXP
':'—field separator between EXP and CVV if there is a CVV '?'—end sentinel
By default, the least significant digit of PAN is checked against the PAN with the MOD 10 algorithm.
LRC—calculated track 2 longitudinal redundancy check from ';' to '?'
This LRC is calculated on the raw data before conversion to ASCII as it would be encoded on a card, so that the keyed-in data can be checked identically to the card data.
The PAN is 12 to 19 digits; the EXP is 4 digits; and the CVV is 3 or 4 digits.

  • For Field 14: The format of the fields ADR and ZIP is:

    1 byte field identifier
    '1'—ADR; '0'—ZIP

    ASCII Data

    field terminator '='

    The maximum number of ADR digits is 20. The maximum number of ZIP digits is 10.
    Example: if address is 5555 and ZIP is 99999 15555=099999=

    Field 15: Track1 encrypted data Field 16: Track2 encrypted data Field 17: Track3 encrypted data


    These fields are the encrypted Track data, using either TDES-CBC or AES-CBC with initial vector of 0. If the original data length is not a multiple of 8 bytes for TDES or a multiple of 16 bytes for AES, the reader right pads the data with 0 before encryption.
    The key management scheme is DUKPT. For DUKPT, the key used for encrypting data is called the Data Key. The Data Key is generated by taking the DUKPT Derived Key exclusive OR'd (XOR'd) with 0000000000FF00000000000000FF0000 to get the resulting intermediate variant key. The left side of the intermediate variant key is then TDES encrypted with the entire 16-byte variant as the key. After the same steps are performed for the right side of the key, combine the two 8-byte key parts to create the 16- byte Data Key.
    Tracks 1, 2 and 3 data are encrypted separately. In order to get the number of bytes for each track's encrypted data field, the field length is always a multiple of 8 bytes for TDES or multiple of 16 bytes for AES, rounding up as necessary. This length value will be zero if there was no data on a track. Once the encrypted data are decrypted, all padding bytes need to be removed. The number of bytes of decoded (native) track data is indicated by the track's unencrypted length field as given in Fields 5, 6, and 7.
    NOTE: For TransArmor encryption, the field length of each encrypted track is 344 bytes.

    Field 18: Session ID (Security level 4 only)


    At the time of this writing, no ID TECH product implements Security Level 4. Hence, Session ID is not used, but this field will contain Terminal/Merchant ID if TransArmor crypto is enabled.

    Field 19: Track1 hash (if encrypted and hash track1 allowed) Field 20: Track2 hash (if encrypted and hash track2 allowed)

    Field 21: Track3 hash (if encrypted and hash track3 allowed)


    The hash is used for non-SRED products; for SRED products, either all zeroes are used (20 bytes of 00), or the hash is 32 bytes of SHA-256. Refer to product manual for details. The hash may be 20 bytes (SHA-1) or 32 bytes (SHA-256) in length. To determine which kind of hash is present, see the discussion of bit 6, Field 4, and also the discussion under Field 10 & 11, above.
    SHA-1 (160-bit digest) is used by default to create a 20-byte hash of the data for track 1 to track 3 raw data. The hash is exactly 20 bytes long for each track. This is provided with two purposes in mind: One is for the host to ensure data integrity by comparing this field with a SHA-1 hash of the decrypted Track data, allowing the detection of corruption in data transmission. The other purpose is to enable the host to store a tokenized version of card data for future use without keeping the sensitive cardholder data in plaintext form. The token may be used for comparison with the stored hash data to determine if they are from the same card.
    SHA-256 is another option for the hash; this type of hash is 32 bytes long for each track.

    Field 22: Reader Serial Number (optional)


    Always 10 bytes (pad with leading 0x30 if <10 digits).

    Field 23: KSN (DUKPT only) or Key ID (TransArmor).


    Key ID (10 bytes KSN for DUKPT, 10 bytes Key ID for fixed key, 11 bytes Key ID for TransArmor).

    Field 24: MAC Value Length


    Data Length (two bytes: low byte comes first, aka "little endian"). This field will not exist unless Field 11 exists and Bit 5 is set in that field.
    This value is commonly 10 00.

    Field 25: MAC Value


    If it exists, this field is used to verify the integrity and authority of the MSR data message; authenticated message is from Field 3 to 24. (The length of MAC Value is defined in Field 24.) This field will not exist unless Field 11 exists and Bit 5 is set in that field.
    This field contains the HMAC result (the 16-byte digest) used to authenticate messages sent from Device to Host. The hash algorithm used here is SHA-256, but only the first 16 bytes of the result are kept.
    MAC-Device = HMAC (MAC_KEY, msgX) Following this field is the MAC_DUKPT_KEY_KSN.
    The MAC-Device will be the last field in a MAC-authenticated message, and msgX (the payload that is hashed) will contain everything from the firstt byte of message being built (Response Data
    + MAC Value Length) up to, but not including, the MAC-Device first byte. NOTE: Advancing the KSN is controlled by the device.
    The hash algorithm is known as HMAC (RFC 2104) and is given by:
    HMAC(K', msgX) = H ((K' ⊕ opad) | H((K' ⊕ ipad) | msgX))
    Use HMAC-SHA256 (Refer to RFC 2104); but retain only the first 16 bytes of the calculation for MAC Authentication.
    In the above formula:
    H is a cryptographic hash function,
    K' is the current MAC Key padded to the right with extra zeros to the input block size of the hash function, or the hash of the original key if it's longer than that block size,
    m is the message to be authenticated,
    | denotes concatenation,
    denotes XOR,
    opad is the outer padding (0x5c5c5c…5c5c, one-block-long hexadecimal constant),
    ipad is the inner padding (0x363636…3636, one-block-long hexadecimal constant).

    Field 26: 10 bytes KSN for MAC DUKPT Key.


    This field will not exist unless Field 11 exists and Bit 5 is set in that field.

    Field 27: CheckLRC


    XOR of all data from Card Encode Type (Field 3) to end of KSN for most ID TECH products; XOR of all data before CheckLRC for SecureMOIR and Spectrum Air.

    Field 28: CheckSum


    Sum of all data from Card Encode Type (Field 3) to end of KSN. Use the bottom 8 bits only. Disregard overflow.

    Field 29: ETX


    End of Text: 0x03.

    Notes


    Force Encryption
    Force Encryption is a device setting. When Force Encrypt is set, the track will always be encrypted, regardless of card type. No clear/mask data (Field 10, 11 and 12) will be sent. When Force Encrypt is not set, only ABA bank cards (ISO 7813 and 4909 card) or Raw card data will be encrypted.

    Handling of Purposely Reading Cards Incorrectly

    In order to prevent bank card data from being transmitted if the card is not swiped firmly bottomed in the slot, a card that meets the above requirements, but has the track data shifted up one or two tracks, can also be rejected. That is, if Track 1 data appears as Track 3 data or Track 1 data appears as Track 2 data or Track 1 data appears as Track 2 data and Track 2 data appears as Track 3 data, the card may be rejected rather than being sent unencrypted. This support is only necessary and available on swipe readers.

    Ignoring tracks

    The reader can be set to ignore one or more tracks. That is, the track is not analyzed (nor sent) so that for purposes of encryption determination it can be ignored.

    Samsung Pay/MST Support

    Samsung Pay/MST (LoopPay) is designed to broadcast a magnetic signal to magnetic head. But because this happens contactlessly (devices separated by a centimeter or two), there is no physical mechanism by which to detect the origin of track data with respect to physical Track 1, physical Track 2, etc. So microcontrollers will receive magnetic signals on all tracks.
    If a device receives identical MSR data on multiple tracks, it will ignore Track 2 and Track 3 data if card data is ISO 7-bit-encoded (treating such data as Track 1 data only) and ignore Track 1 and Track 3 data if card data is ISO 5-bit-encoded encoding (treating it as Track 2 data only).
    ID TECH stripe readers will follow the ISO/ABA financial card checking algorithm below to decide card type, encryption, and data masking.

    Card Type

    Card Type 80 Cards meeting the conditions below are always encrypted following an ISO/ABA (American Banking Association) Card Encoding method.
    Card Type 81 (Not encrypted unless a track is forced to be encrypted.) AAMVA (American Association of Motor Vehicle Administration) Card Encoding method.
    Track1 is 7-bit encoded. Track2 is 5-bit encoded. Track3 is 7-bit.
    Card Type 83 (Not encrypted unless a track is forced to be encrypted.) Card has a nonstandard format, e.g. 7-bit character data on track 2.
    Card Type 84 card where the reader is in raw mode: always encrypted
    Any card in raw format (that is, where the reader does not decode the track data but rather sends the track data to the host without interpretation) is never sent masked and is always encrypted, because the reader never did any track data interpretation.
    Card Type 85 (Not encrypted unless a track is forced to be encrypted.) JIS II 8 8 0 (wide track, send Track 2 only, 080).
    Card Type 86 (Not encrypted unless a track is forced to be encrypted.) JIS I bits per track on Track 1 or Track 3: 858 855 850 758
    Card Type 87 (Not encrypted unless a track is forced to be encrypted.) JIS II 8 8 0 (wide track, send track 2 only, 080).
    It has been used for SecureKey and Secure MIR. A compatible setting is available to use Card Type 85 for JIS II.
    New Products will use Card Type 85 for JIS II.
    Card Type C0
    Manual Key-in card data.

    ISO/ABA Card

    Only cards encrypted by default are Card Type 0 (bank card format cards). If the reader is so configured, the unusual card type 4 raw format may exist (where the reader is set to not decode and interpret the cards but leave them in the same format as written to the card). Only bank cards send out masked data.
    Below is the algorithm used to check bank cards.
    • ISO/ABA (American Banking Association) Card Type 0 (bank cards):

The first character, the start sentinel, is a ';' on 5-bit/character tracks, and a '%' on 7-bit/character tracks. To be a valid track, the track must have a valid start sentinel, end sentinel, and longitudinal redundancy check character; and the parity on each character must be valid. Any track with 16 or fewer bits of data is invalid, the data are treated as noise.
Encoding method:
Track1 is 7-bit encoding and it was the only track decoded.
Track1 is 7-bit encoding. Track2 is 5-bit encoding and Track 3 was not decoded.
Track1 is 7-bit encoding, Track2 is 5-bit encoding, and Track3 is 5-bit encoding.
Track1 is 7-bit encoding, Track3 is 5-bit encoding, and Track 2 was not decoded.
Track2 is 5-bit encoding and neither track1 nor track3 was decoded. Track2 is 5-bit encoding, track3 is 5-bit encoding, and track 1 was not decoded.
Track3 is 5-bit encoding and neither track 1 nor 3 was decoded.
The reasons a track could be not decoded are it was not a valid 5-bit per character track, 7-bit per character track; 8-bit per character track; or the reader was told to ignore that track, or the track had insufficient bits to be a valid track.
Additional ABA Card Checks
On a track, the first field separator is used to indicate the end of the PAN (Primary Account Number). The field separator on a 5-bit/character track is '=' and on a 7-bit/character track is caret: '^'.
Track1 second byte is 'B'.
There is a '=' in track 2 so the account number length is 12-19 digits.
There is a '^' on track 1 so the account number length is 12-19 digits (excluding spaces).
Total length of track 1 is above 21 characters.
Expiration date can be missing if there is a separator '^' or '=' replacing the first digit of the expiration date.
Track3 ISO-4909 (with PAN) checking

    1. Track1 and Track2 should be in bank card format (Card Type 0, as checked above) or absent.
    2. Track3 second and third characters are "01","02" or "90" – "99"
    3. Track3 PAN is 12 to 19 digits. The field separator is '=' 4.Track3 total length is from 67 to 107 characters inclusive.

Note: Expiration date starts 36 characters (or optionally 34 characters) downstream of the first '='.

JIS Card Output

Below is ID TECH's standard output for JIS clear and encrypted output format.

USB KB or PS/2 Interface

SS, ES and LRC default for JIS track data L1, L3 mask and L3: encryption is none (0x00), i.e. not sending out SS, ES and LRC.
JIS is not recognized as ISO financial card; it will not be encrypted unless Force Encryption is on (no masked data).

Other Interfaces

For other interface (RS232, CDC, HID, SPI), SS, ES and LRC will be sent as is. LRC default is off on L1.
LRC in L3 masked data is on. LRC in L3 encrypted data is on.

MSR DATA EXAMPLES

Data formats vary by device model. Most USB-HID and RS-232/UART card readers follow the Enhanced Encrypted MSR format as described above. Those devices output binary data (represented as hex). Some USB-KB and PS2 insert readers output a format that mixes ASCII data (for Tracks 1, 2, and 3) with binary data. See examples to follow.
All the data will be in hex format for RS-232, USB CDC, and USB-HID interface: e.g. ETX will be output as H'03'.
All the data except Track1/2/3 clear/mask data will be in hexadecimal format for keyboard interface; e.g STX will be in two hexadecimal byte '0' (H'30') and '2' (H'32'). TrackX clear/mask data is in ASCII format. e.g. '%' will be output as H'25'.
For PS2 and USB-KB interface readers, up to 15 bytes prefix and postfix can be added to the output. This is a settable feature. By default, prefix and postfix are set to none.
For PS2 and USBKB interface readers, the Data Length, CheckLrc and CheckSum calculations are based on final output bytes, excluding prefix and postfix.

Example: MSR Output from a USB-HID/RS-232/UART Interface


The data in this example are encrypted using the Enhanced Encryption MSR Format. This can be recognized because the high bit of the fourth byte underlined (80) is 1.
USB-HID / RS-232 / UART output format:
029801803F48236B03BF252A343236362A2A2A2A2A2A2A2A393939395E425553
48204A522F47454F52474520572E4D525E2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A
2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A3F2A3B343236362A2A2A2A2A2A2A2A39
3939393D2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A3F2ADA7F2A52BD3F6DD8B96C50 FC39C7E6AF22F06ED1F033BE0FB23D6BD33DC5A1F808512F7AE18D47A60CC3F4 559B1B093563BE7E07459072ABF8FAAB5338C6CC8815FF87797AE3A7BEAB3B10 A3FBC230FBFB941FAC9E82649981AE79F2632156E775A06AEDAFAF6F0A184318 C5209E55AD44A9CCF6A78AC240F791B63284E15B4019102BA6C505814B585816 CA3C2D2F42A99B1B9773EF1B116E005B7CD8681860D174E6AD316A0ECDBC6871 15FC89360AEE7E430140A7B791589CCAADB6D6872B78433C3A25DA9DDAE83F12 FEFAB530CE405B701131D2FBAAD970248A456000933418AC88F65E1DB7ED4D10 973F99DFC8463FF6DF113B6226C4898A9D355057ECAF11A5598F02CA31688861 C157C1CE2E0F72CE0F3BB598A614EAABB16299490119000000000206E203
STX, Length(LSB, MSB), captured data type, track status, length track 1, length track 2, length track 3, Clear/mask data sent status, Encrypted/Hash data sent status
02 9801 80 3F 48-23-6B 03BF
The above broken down and interpreted: 02—STX character
98—low byte of total length 01—high byte of total length
80—captured data type byte (interpretation: new format ABA card) 3F—3 tracks of data all good
48—length of track 1 23—length of track 2 6B—length of track 3
03—tracks 1 and 2 have masked/clear data BF—bit 7=1—KSN included
Bit 6=0—no Session ID included so not level 4 encryption Bit 5=1—track 3 hash data present
Bit 4=1—track 2 hash data present Bit 3-1—track 1 hash data present
Bit 2=1—track 3 encrypted data present Bit 1=1—track 2 encrypted data present Bit 0=1—track 1 encrypted data present
Track 1 data masked (length 0x48) 252A343236362A2A2A2A2A2A2A2A393939395E42555348204A522F47454F52474520572E
4D525E2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A
2A2A3F2A
Track 1 masked data in ASCII
%4266******9999^BUSH JR/GEORGE W.MR^*****************************?
Track 2 data in hex masked (length 0x23) 3B343236362A2A2A2A2A2A2A2A393939393D2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A3 F2A
Track2 masked data in ASCII
;4266*******9999=*************?
In this example there is no Track 3 data, whether clear or masked (encrypted and hashed data are shown below).
Track 1 encrypted length 0x48 rounded up to 8 bytes = 0x48 (72 decimal) DA7F2A52BD3F6DD8B96C50FC39C7E6AF22F06ED1F033BE0FB23D6BD33DC5A1F80851 2F7AE18D47A60CC3F4559B1B093563BE7E07459072ABF8FAAB5338C6CC8815FF87797A E3A7BE
Track 2 encrypted length 0x23 rounded up to 8 bytes =0x28 (40 decimal) AB3B10A3FBC230FBFB941FAC9E82649981AE79F2632156E775A06AEDAFAF6F0A18431 8C5209E55AD
Track 3 encrypted length 0x6B rounded up to 8 bytes =0x70 (112 decimal) 44A9CCF6A78AC240F791B63284E15B4019102BA6C505814B585816CA3C2D2F42 A99B1B9773EF1B116E005B7CD8681860D174E6AD316A0ECDBC687115FC89360A EE7E430140A7B791589CCAADB6D6872B78433C3A25DA9DDAE83F12FEFAB530CE405 B701131D2FBAAD970248A45600093
Track 1 data hashed length 20 bytes 3418AC88F65E1DB7ED4D10973F99DFC8463FF6DF
Track 2 data hashed length 20 bytes 113B6226C4898A9D355057ECAF11A5598F02CA31
Track 3 data hashed length 20 bytes
688861C157C1CE2E0F72CE0F3BB598A614EAABB1
KSN length 10 bytes 62994901190000000002
LRC, CheckSum and ETX 06E203
Clear/Masked Data in ASCII:
Track 1: %4266******9999^BUSH JR/GEORGE W.MR^*****************************? Track 2: ;4266*******9999=*************?
Key Value: 1A 99 4C 3E 09 D9 AC EF 3E A9 BD 43 81 EF A3 34 KSN: 62 99 49 01 19 00 00 00 00 02
Decrypted Data:
Track 1 decrypted
%B4266841088889999^BUSH JR/GEORGE W.MR^0809101100001100000000046000000?!
Track 2 decrypted
;4266841088889999=080910110000046?0
Track 3 decrypted
;33333333337676760707077676763333333333767676070707767676333333333376767607070
776767633333333337676760707?2
Track 1 decrypted data in hex including padding zeros (but there are no pad bytes here) 2542343236363834313038383838393939395E42555348204A522F47454F52474520572E4D52
5E303830393130313130303030313130303030303030303034363030303030303F21
Track 2 decrypted data in hex including padding zeros 3B343236363834313038383838393939393D3038303931303131303030303034363F300000000
000
Track 3 decrypted data in hex including padding zeros 3B333333333333333333333736373637363037303730373736373637363333333333333333333
337363736373630373037303737363736373633333333333333333333373637363736303730373
03737363736373633333333333333333333373637363736303730373F320000000000

Example: MSR Output from USB KB and PS/2 Interface, Format 1


02E102803F4F286F03BF%4266*******9999^BUSH JR/GEORGE
W.MR^*************************************?;4266*******9999=
*******************?*38E2F7E63C3CB4114881A50CAE7A0FBCD391AEE2551 7A8D98FB6A12B58B4F494C7849E9635DC9C22204884735B2624F4CCF2B7334EA
8C746E4E32EE462836445DA36611816B73C141F1F754B2D839A04B83FD38F070 EEC9BB401ED5A4079DB7A2928B92A4D16D8C3007B60D88F9C0C5E352719FD285
69447F20FC37CC789AED41A2FEAEBE48D5A48A1B456C15FC3271A0A8D5BE324A
4878BB3E7A61B1AF45E1E3A509329ED59D8C9A647676B725264864946E226B9C
970AED70C492313BCE0A4893014EDE3A7F4D0ECA8AFF50350CD9EE257F96B1D0
00AAB259D75D807B76A04AF0897E0A292B7C44D56DBB2AA6E57EFEDD08FF7123
426037AA6B19D4955D22FB7BA325CFA81ABAFB8F7ED9387C29B2D7BD32BDC792
7845B1E819C3DCB8623870619381862994901510000C00004439F03
STX, Length(LSB, MSB), captured data type, track status, length track 1, length track 2, length track 3, Clear/mask data sent status, Encrypted/Hash data sent status
02 E102 80 3F 4F-28-6F 03BF
The above broken down and interpreted 02—STX character
E1—low byte of total length 02—high byte of total length
80—captured data type (interpretation: new format ABA card) 3F—3 tracks of data all good
4F—length of track 1 28—length of track 2 6F—length of track 3
03—tracks 1 and 2 have masked/clear data BF— Bit 7=1—KSN included
Bit 6=0—no Session ID included so not level 4 encryption Bit 5=1—track 3 hash data present
Bit 4=1—track 2 hash data present Bit 3-1—track 1 hash data present
Bit 2=1—track 3 encrypted data present Bit 1=1—track 2 encrypted data present Bit 0=1—track 1 encrypted data present
Track 1 data masked (length 0x4F)
%4266******9999^BUSH JR/GEORGE W.MR^************************************? Track 2 data in hex masked (length 0x28)
;4266*******9999=******************?
In this example there is no Track 3 data whether clear or masked. (Encrypted and hashed data are shown below.)
Track 1 encrypted length 0x4F rounded up to 8 bytes = 0x50 (80 decimal) 38E2F7E63C3CB4114881A50CAE7A0FBCD391AEE25517A8D98FB6A12B58B4F494C7849 E9635DC9C22204884735B2624F4CCF2B7334EA8C746E4E32EE462836445DA36611816B7 3C141F1F754B2D839A04
Track 2 encrypted length 0x28 rounded up to 8 bytes =0x28 (40 decimal) B83FD38F070EEC9BB401ED5A4079DB7A2928B92A4D16D8C3007B60D88F9C0C5E35271 9FD28569447
Track 3 encrypted length 0x6F rounded up to 8 bytes =0x70 (112 decimal)
F20FC37CC789AED41A2FEAEBE48D5A48A1B456C15FC3271A0A8D5BE324A4878BB3E 7A61B1AF45E1E3A509329ED59D8C9A647676B725264864946E226B9C970AED70C492313 BCE0A4893014EDE3A7F4D0ECA8AFF50350CD9EE257F96B1D000AAB259D75D807B76A 04AF0897E0A292B7C4
Track 1 data hashed length 20 bytes 4D56DBB2AA6E57EFEDD08FF7123426037AA6B19D
Track 2 data hashed length 20 bytes 4955D22FB7BA325CFA81ABAFB8F7ED9387C29B2D
Track 3 data hashed length 20 bytes 7BD32BDC7927845B1E819C3DCB86238706193818
KSN length 10 bytes 62994901510000C00004
LCR, CheckSum and ETX 439F03
Decrypted Data:
Track 1 decrypted
%B4266841088889999^BUSH JR/GEORGE W.MR^08091011000011000000000460000000000000?1
Track 2 decrypted
;4266841088889999=08091011000004600000?0
Track 3 decrypted
;33333333337676760707077676763333333333767676070707767676333333333376767607070
7767676333333333376767607070707?2
Track 1 decrypted data in hex including padding zeros (but there are no pad bytes here) 2542343236363834313038383838393939395E42555348204A522F47454F52474520572E4D52
5E303830393130313130303030313130303030303030303034363030303030303030303030303
03F3100
Track 2 decrypted data in hex including padding zeros 3B343236363834313038383838393939393D30383039313031313030303030343630303030303 F30
Track 3 decrypted data in hex including padding zeros 3B333333333333333333333736373637363037303730373736373637363333333333333333333
337363736373630373037303737363736373633333333333333333333373637363736303730373
0373736373637363333333333333333333337363736373630373037303730373F3200

Example: MSR Output USB HID/RS232/UART Interface, Format 2


600198803F48236B03BF252A343236362A2A2A2A2A2A2A2A393939395E42555348204A52
2F47454F52474520572E4D525E2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2 A2A2A2A2A2A2A2A2A2A2A3F2A3B343236362A2A2A2A2A2A2A2A393939393D2A2A2 A2A2A2A2A2A2A2A2A2A2A2A2A3F2A26B03F2BD327CA087C159DEA3E77974A36B6E
89CB5BC85EF92D08FB01152089099FE2A348DF2BA8D7AFEF16A1F5F2CEA46946A92CD C2AB3B750D1AEF8127995EE6A944E12F9DF40E46607F06C68E057DA05CC3BBB2BD68E CE1D7D89A4671423C4F649082106A785A62D9382968BCF4CFD0ECE3CF33449F265542C B4AE6240F99CDACD08E92744FFC04C683834EB4D04C9CB9D2A4B4A4FFE15F7C70169 C89288097C4B8BB42C67D33073CFEE68B95D0F88C6CF82F86BF8E7FE5909D1537103999 40C9DAD8BD26E929EE98BEBFA9D3C19AAC047B61E8ED56BE52D4A7F8B5FFFA01341
8AC88F65E1DB7ED4D10973F99DFC8463FF6DF113B6226C4898A9D355057ECAF11A5598 F02CA31688861C157C1CE2E0F72CE0F3BB598A614EAABB1629949011A000BE00003D70 3

60, length(MSB, LSB), card type, track status, length track 1-length track 2- length track 3, mask clear status, crypt hash status
60 0198 80 3F 48-23-6B 03BF
0198 Total message length in hexadecimal 3F Tracks 1-3 found and properly decoded
48 Length of track 1 data is 48h (72 decimal) bytes 23 Length of track 2 data is 23h (35 decimal) bytes 6B Length of track 3 data is 6Bh (107 decimal) bytes 03 indicates tracks 1 and 2 as masked
BF Tracks 1-3 are encrypted, Tracks 1-3 are hashed, the KSN is included
Track one masked track data displayed in hexadecimal 252A343236362A2A2A2A2A2A2A2A393939395E42555348204A522F47454F52474520572E
4D525E2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A
2A2A3F2A
Track two masked track data displayed in hexadecimal 3B343236362A2A2A2A2A2A2A2A393939393D2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A3 F2A
Track one encrypted track data displayed in hexadecimal 26B03F2BD327CA087C159DEA3E77974A36B6E89CB5BC85EF92D08FB01152089099FE2 A348DF2BA8D7AFEF16A1F5F2CEA46946A92CDC2AB3B750D1AEF8127995EE6A944E12 F9DF40E
Track two encrypted track data displayed in hexadecimal 46607F06C68E057DA05CC3BBB2BD68ECE1D7D89A4671423C4F649082106A785A62D938
2968BCF4CF
Track three encrypted track data displayed in hexadecimal D0ECE3CF33449F265542CB4AE6240F99CDACD08E92744FFC04C683834EB4D04C9CB9D 2A4B4A4FFE15F7C70169C89288097C4B8BB42C67D33073CFEE68B95D0F88C6CF82F86B F8E7FE5909D153710399940C9DAD8BD26E929EE98BEBFA9D3C19AAC047B61E8ED56B E52D4A7F8B5FFFA01
First 20-bytes of track one data hashed 3418AC88F65E1DB7ED4D10973F99DFC8463FF6DF
First 20-bytes of track two data hashed 113B6226C4898A9D355057ECAF11A5598F02CA31
First 20-bytes of track three data hashed
688861C157C1CE2E0F72CE0F3BB598A614EAABB1 KSN
629949011A000BE00003
LRC and ETX D7 03
Key Value: 14 81 3F 2E DA E0 EF C0 46 0B 08 AB FA D7 95 87
KSN: 62 99 49 01 1A 00 0B E0 00 01
Decrypted Data:
%B4266841088889999^BUSH JR/GEORGE W.MR^0809101100001100000000046000000?!
;4266841088889999=080910110000046?0
;33333333337676760707077676763333333333767676070707767676333333333376767607070
776767633333333337676760707?2
Clear/Masked Data displayed in ASCII:
Track 1: %4266******9999^BUSH JR/GEORGE W.MR^*****************************? Track 2: ;4266*******9999=*************?
Key Value: 1A 99 4C 3E 09 D9 AC EF 3E A9 BD 43 81 EF A3 34 KSN: 62 99 49 01 19 00 00 00 00 02
Decrypted Data displayed in ASCII:
%B4266841088889999^BUSH JR/GEORGE W.MR^0809101100001100000000046000000?!
;4266841088889999=080910110000046?0
;33333333337676760707077676763333333333767676070707767676333333333376767607070
776767633333333337676760707?2
Track 1 decrypted data in hex including padding zeros (but there are no pad bytes here) 2542343236363834313038383838393939395E42555348204A522F47454F52474520572E4D52
5E303830393130313130303030313130303030303030303034363030303030303F21
Track 2 decrypted data in hex including padding zeros 3B343236363834313038383838393939393D3038303931303131303030303034363F300000000
000
Track 3 decrypted data in hex including padding zeros 3B333333333333333333333736373637363037303730373736373637363333333333333333333
337363736373630373037303737363736373633333333333333333333373637363736303730373
0373736373637363333333333333333333337363

Example: Enhanced Manual Entry Output Format


Keyed in PAN5150710200107903
Keyed in Expiration0909
Reader Output: (SecureKey Enhanced Key-In Format, USB-KB or PS2)
029200C0170018000292;515071******7903=0909?*FBCE9EFFF7500011FA44
7DC93C11F3816BC7A37EED3CBD0464AB280F610A7035448E0888CDF683D6C5C3
2DBE629949003700006000161DB103
Masked manually entered data: ;515071*****7903=0909?
Key Value: D1 3F 0B D8 47 AA 1D 27 C1 1C F8 4C D8 66 6A 2E KSN: 62 99 49 00 37 00 00 60 00 16
Decrypted Data:
Data in ASCII Format
;5150710200107903=0909?0
Data in HEX Format 3B353135303731303230303130373930333D303930393F30

Example: Enhanced Manual Entry with ADR and ZIP Output


Keyed in Admin #

5

Keyed in PAN

45678901234567890123

Keyed in Expiration

1234

Keyed in CVV

9999

Keyed in Address

88888888888888888888

Keyed in ZIP

7777777777


Reader Output: (SecureKey Enhanced Key-In Format, USB-HID)
028700C03700202206923B343536372A2A2A2A2A2A2A2A2A2A2A393031323D33
3431323A2A2A2A2A3F2A3138383838383838383838383838383838383838383D
30373737373737373737373DEABBF052D8FBB29F2814B4AFEAE0DF6882ED8CF5 F8AEB2A92B7A956FC51802E2CB35058DBE3FB4C0DD85F200A4929722E815E743 6299490101000020000FA92703
028700C0370020220692
0087 Total message length in hexadecimal C0 Enhanced manual entry
37 Tracks 2-3 found and properly decoded
00 Length of track 1 data is 00h (0 decimal) bytes 20 Length of track 2 data is 20h (32 decimal) bytes 22 Length of track 3 data is 22h (34 decimal) bytes 06 indicates tracks 2 and 3 as masked
92 Tracks 2 is encrypted, Track 2 is hashed, the KSN is included
Masked Keyed In Data:;4567**********9012=3412:**? Additional Data Fields:188888888888888888888=07777777777= Key Value: EB 8B 4A 63 7E 9E A4 BB 5C 75 E7 99 8F FC 7A 8F KSN: 62 99 49 01 01 00 00 20 00 0F
Decrypted Data in ASCII Format;4567890123456789012=3412:9999?4 Data in HEX Format 3B343536373839303132333435363738393031323D333431323A393939393F34

Example: MSR Output Format with TransArmor TDES-DUKPT


  • If track 1 and 2 are present, provide tracks 1+2 concatenated, with all sentinels, and encrypt that whole payload together, needs to be hex.
  • If only track 1 is present, provide track 1 with sentinels. Encrypted output must be in HEX.
  • If only track 2 is present, provide track 2 with sentinels. Encrypted output must be in HEX.



020A01804F6B000081890112252A343236362A2A2A2A2A2A2A2A393939395E4255534820
4A522F47454F52474520572E4D525E303830392A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2 A2A2A2A2A2A2A2A2A2A2A2A3F3B343236362A2A2A2A2A2A2A2A393939393D3038303 92A2A2A2A2A2A2A2A2A2A2A3F8E3849FC2888238C069A2EEB7C3B61B9A60825BCA99
263F2C4030CB696867AC76A648C24080248BB59E3241984CC9C66F90AE28020EADED4C
3F6D6A7A84D560D5EA51FD3773086C0D9B0B0FFB09CC8B070B5316F66E5AA88A5F71 B061BD3616C549A38A14BD25259DC88BA9A0ED5E528E74BDBCE885CCB87AE9F1ECE FA419792D226E7C100000000000000000000629949012C0004600001F50D03
[Get:TDES] INITKEY:Key:
0123456789ABCDEFFEDCBA9876543210
[Data Format:Enhanced] [Card Type:ISO/ABA Card] [Encrypted Type:TDES] [TotalLength:266 [0A01]] Track Length:
Track 1 Length:107
Track 2 Length:0
Track 3 Length:0 Track 1-3 Status: 4F
track1 decode success, track2 decode success, track3 decode success, track1 sampling success, track2 sampling fail, track3 sampling fail,
Field 10 ("optional byte length") exists Byte8:81
Status byte 1:
Track1 Clear/Mask data present, Track2 Clear/Mask data not present, Track3 Clear/Mask data not present, Encrypted Type :UN-AES
Encrypted Type : TDES Key Type : DATA Key
Out Put Serial Number Enable Byte9:89
Encrypted data sent status byte: Track1 encrypted data present,
Track2 encrypted data not present, Track3 encrypted data not present, Track1 hash data present,
Track2 hash data not present, Track3 hash data not present, Session ID not Present(level 3), KSN Present(encrypted),
Byte 10: 01
Optional byte length: 1 Byte 11: 12
SHA-1
Encryption type follows Field 11 bit 2 & 3 & 4 TransArmor TDES-DKUPT
No MAC Value Length
Track1 Mask (Hex): 252A343236362A2A2A2A2A2A2A2A393939395E42555348204A522F47454F52474520572E
4D525E303830392A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2 A2A3F3B343236362A2A2A2A2A2A2A2A393939393D303830392A2A2A2A2A2A2A2A2A2 A2A3F
Track2 Mask (Hex): Track3 Mask (Hex):
Track1 Mask :
%4266******9999^BUSH JR/GEORGE W.MR^0809*************************?;4266******9999=0809**********? Track2 Mask :
Track3 Mask :
Track1 Encrypted Data Length:112 Track2 Encrypted Data Length:0 Track3 Encrypted Data Length:0 Track1 Encrypted
Data:8E3849FC2888238C069A2EEB7C3B61B9A60825BCA99263F2C4030CB696867AC76A 648C24080248BB59E3241984CC9C66F90AE28020EADED4C3F6D6A7A84D560D5EA51FD
3773086C0D9B0B0FFB09CC8B070B5316F66E5AA88A5F71B061BD3616C549A38A14BD2
5259DC88BA9A0ED5E528
Track2 Encrypted Data:
Track3 Encrypted Data:
Track1 Hash:
E74BDBCE885CCB87AE9F1ECEFA419792D226E7C1
Track2 Hash: 0000000000000000000000000000000000000000
Track3 Hash: 0000000000000000000000000000000000000000
Serial Number: 00000000000000000000



ENCRYPTED EMV DATA

Transaction data from chip-card interactions (here loosely described as "EMV data") will consist primarily of TLV (tag-length-value) triplets.
Tags may be one or more bytes in length and are constructed according to standard ASN.1 Basic Encoding Rules, otherwise known as BER-TLV. (See discussion below.) Length is specified in one or more bytes using the rules described further below.
"Tag data" can consist of embedded TLV blocks that embed more TLV blocks, etc. The ordering of TLV blocks, at a given level, is not significant. The actual number of TLV blocks returned can vary, based on card brand, transaction type, and potentially many other considerations.
Not all TLV data will be encrypted. When TLVs are encrypted, packaging of contents will occur according to one of two schemes (Method One or Method Two), depending on whether or not you've specified the use of custom tag DFEF4B in your terminal settings. In Method One, track data and/or PAN data are encrypted in accordance with preferences specified in tag DFEF4B and the result placed in tag DFEF4D. (The data will not contain embedded tags; see further discussion under Method One below.) In Method Two, which is the default method if tag DFEF4B is not present in terminal settings, data for sensitive tags (such as tag 5A, 56, or 57, etc.) is padded, then the entire TLV is encrypted and embedded in a new TLV with the same tag name, as described under Method Two below.

Encrypted TLV Packaging: Method One


If the party that will be decrypting your data wants track data only, without any enclosing tags, select this method. The track data provided will be similar to the data provided in a traditional MSR transaction.
To utilize this method, you must set your preferences in tag DFEF4B and supply that tag, as a terminal configuration setting, to the ID TECH reader. (See Appendix A for more information
about tags DFEF4A, DFEF4C, and DFEF4D.) Once supplied, this tag does not need to be supplied again, unless your preferences change. (This is a one-time-only setting, in other words, unless you want or need to adjust it more dynamically.)
Use tag DFEF4B to specify which track or tracks (1, 2, or 3) you want to receive data for; whether or not to enable sentinels for those tracks; whether or not you wish to (also) receive PAN data; and to control whether the default behavior is to return all requested tracks, or just the first track found. (Again, see Appendix A for more information on these configuration options.) Once DFEF4B has been configured, the reader will place the requested data (padded and encrypted) in tag DFEF4D. If you have chosen to retrieve multiple tracks of data, the tracks will be concatenated. To know their lengths, you will need to retrieve tag DFEF4C, which will contain the explicit lengths of any returned data blocks.
Before encryption, the data payload in DFEF4D is zero-padded padded, as necessary, to a final length that's a multiple of 8 bytes (for TDES encryption) or a multiple of 16 bytes (for AES encryption).

Encrypted TLV Packaging: Method Two


Method Two is the default packaging for encrypted TLVs if tag DFEF4B has not been specified in terminal settings.
Under this packaging methodology, when a TLV has been identified as requiring encryption, the entire TLV, including the tag and length, is first padded (as necessary), then encrypted, before being wrapped in a new instance of the (same) tag:

After it has been padded and encrypted, the old TLV becomes the 'V' of a new instance of the tag, with a new length. The length is encoded according to special rules (as discussed below under Length Byte Semantics).

Tag Encoding

ID TECH transaction data will generally contain a mix of industry-standard EMV tags and proprietary ID TECH tags. ASN.1 Basic Encoding Rules apply in either case. (For information about EMV tags and their meanings, consult the EMV documentation at https://www.emvco.com.)
Tags are constructed as follows:
Byte 1: This is the first (and possibly only) value for the Tag.
If the bottom 5 bits are ON, then next byte is also part of the tag. In other words:
(firstByte & 0x1F == 0x1F) // TRUE means more tag bytes
follow
Byte 2 . . n (if necessary):
If the most significant bit (B7) is ON, then the next byte is also part of the tag:
(Byte & 0x80 == 0x80) // TRUE means more tag bytes follow

Examples:

8F 02 03 04: Tag = 8F, Length = 2, Data = 03 04
9F 02 03 04: Tag = 9F02 (and Length = 3, Data = 04) BF A2 92 82: Tag = BFA292

Length Byte Semantics

The top bits of the first length byte have special significance.
If the most significant bit (B7) of the first length byte is OFF, then that entire byte is the data length of the data to follow. (In this case, there is one and only one "length byte" to consider.)
If the most significant bit (B7) is ON, then the lower nibble specifies the number of following bytes that encode the length of the data to follow. In other words, the lower nibble is the "length of the length." (E.g.: the lower nibble of 84 is 4, therefore the number of length bytes is 4.)

Examples:


6F 12 13 14 15 […] Tag is 6F, Length is 12, Data starts at 13.
9F 20 81 82 83 84 […]: Tag is 9F20, the lower nibble of 81 is 1 (therefore there is one length byte, with value 82), so data starts at 83.
DF 81 01 82 01 02 03 […]: Tag is DF8101, Length is the 2 bytes after 82, which is 0x0102, so 258 bytes of data can be found starting at 03.




Using Length Byte to Denote Mask and/or Encryption:


Bits 5, 6, and/or 7 of the first length byte are used in a special way when data are masked or encrypted:

    • Bit 7 will be set to 1.
    • Bit 6 will be set to 1 if there is encryption.
    • Bit 5 will be set to 1 if there is a mask (e.g., for track data).
    • Bits 0-4 signify the number of "length bytes" that follow. The actual length must be retrieved from the length bytes.


Examples:

6F 12 13 14 15 . . .: Tag is 6F, Length is 12, Data starts at 13, no mask/encryption.
9F 20 C1 82 83 84 . . .: Tag is 9F20, Length is the 1 byte after C1, which is 0x82, data is encrypted, data starts at 83.
DF 81 01 A2 01 02 03 . . .: Tag is DF8101, Length is the 2 bytes after A2, which is 0x0102, data is masked, data starts at 03.
The following are tags that will contain encrypted and/or masked data:

Tags subject to encryption using Method Two

Tag

Data Object

Note

Plaintext

Mask and
format

Encryption and
format

5A

Application PAN

 

None

Mask

Encryption

 

 

 

 

5A A1 Len

5A C1 Len

 

 

 

 

<value>

<value>

 

 

 

 

This Value will

 

 

 

 

 

be masked

 

 

 

 

 

according to

 

 

 

 

 

PreCtlNum and

 

 

 

 

 

PostCtlNum,

 

 

 

 

 

then output.

 

56

Track 1 Data

1. MasterCard-

None

Mask1

Encryption

 

 

Paypass

 

56 A1 Len

56 Cx Len

 

 

(MagStripe)

 

<value>

<value>

 

 

defines it.

 

(Optional for

 

 

 

2. DiscoverZip

 

Contact EMV)

 

 

 

defines it.

 

 

 

 

 

3. Visa MSD –

 

 

 

 

 

not defined.

 

 

 

 

 

  1. Amex not defined.
  2. PBOC– not defined.

 

 

 

57

Track 2

 

None

Mask1

Encryption

 

Equivalent Data

 

 

57 A1 Len

57 Cx Len

 

 

 

 

<value>

<value>

 

 

 

 

(Optional for

 

 

 

 

 

Contact EMV)

 

5F20

Cardholder
Name

 

Full Plaintext

None

None

5F24

Expire Date

 

Full Plaintext

None

None

5F30

Service Code

 

Full Plaintext

None

None

9F1F

Track 1
Discretionary Data

 

None

None

Encryption 9F 1F Cx Len
<value>

9F20

Track 2
Discretionary Data

 

None

None

Encryption 9F 20 Cx Len
<value>

9F6B

Track 2 Data

1. MasterCard-

None

Mask1

Encryption

 

 

Paypass

 

9F6B A1 Len

9F 6B Cx Len

 

 

(MagStripe)

 

<value>

<value>

 

 

defines it

 

(Contactless

 

 

 

2. DiscoverZip –

 

MSD/EMV

 

 

 

Do not Define.

 

Only)

 

 

 

3. Visa MSD –

 

 

 

 

 

Define it for

 

 

 

 

 

'Card CVM

 

 

 

 

 

Limit'. Now Do

 

 

 

 

 

Not Encrypt it in

 

 

 

 

 

Visa MSD.

 

 

 

 

 

4. Amex – Do

 

 

 

 

 

not Define.

 

 

 

 

 

5. PBOC–Define

 

 

 

 

 

it for 'Card

 

 

 

 

 

CVM Limit'.

 

 

 

 

 

Now Do Not

 

 

 

 

 

Encrypt it in

 

 

 

 

 

PBOC.

 

 

 

 

 

If it is used for

 

 

 

 

 

Track2 Data.

 

 

 

 

 

The value need

 

 

 

 

 

be encrypted,

 

 

 

 

 

then Output.

 

 

 

FFEE13

Track 1 Data

  1. DiscoverZip Need Use it.
  2. Visa MSD Need Use it.
  3. Amex Need Use it.
  4. PBOC Need Use it.

None

Mask1
FF EE 13 A1
Len <value> (Contactless MSD Only)

Encryption FF EE 13 Cx
Len <value>

FFEE14

Track 2 Data

  1. DiscoverZip Need Use it.
  2. Visa MSD Need Use it.
  3. Amex Need Use it.
  4. PBOC Need Use it.

None

Mask1
FF EE 14 A1
Len <value> (Contactless MSD Only)

Encryption FF EE 14 Cx
Len <value>


1Mask Data Note:
Data for 9F6B, FFEE13, and FFEE14 are masked for Contactless MSD only.
Values will be masked according to PreCtlNum and PostCtlNum settings in EMV, then output.

Discretionary Data

Tag

Data Object

Note

Plaintext

Mask and format

Encryption and format


DF812A


DD Card Track 1

 

None

None

Encryption
DF 81 2A Cx Len
<value>


DF812B


DD Card Track 2

 

None

None

Encryption
DF 81 2B Cx Len
<value>

DF31

DD Card Track 1

 

None

None

Encryption
DF 31 Cx Len <value>

DF32

DD Card Track 2

 

None

None

Encryption
DF 32 Cx Len <value>




Additional Encryption Information Tags (for applicable ViVOpay products)

Tag

Data Object

Note

Format



DFEE26


Encryption Status Information ("Attribution bytes")

 

Byte 1:
Bit 4/3/0: Captured Data Type 0 0 0 = Contact Card

  1. 0 1 = Contactless Card / EMV
  2. 0 1 = Contactless Card / MSD

    0 1 x = MSR Card
    Bit 2/1: Encryption Mode

0 0 = TDES

  1. 1 = AES
  2. x = Refer to "Extended Encryption Mode" Bit 5: Reserved for Attribution Byte Extension. Bit 6/7: Encryption Status (For ViVOpay IDG) 0 0 = MSR/MSD off, EMV off
  3. 1 = MSR/MSD off, EMV on
  4. 0 = MSR/MSD on, EMV off

1 1 = MSR/MSD on, EMV on
Byte 2: (Optional)
Bit 3/2/1/0: Extended Encryption Mode 0 0 0 0 = TDES
0 0 0 1 = AES
0 0 1 0 = TransArmor Algorithm
0 0 1 1 = Voltage Algorithm
0 1 0 0 = Visa FPE
0 1 0 1 = Verifone FPE Bit 6~4: Reserved
Bit 7:
0 = No MAC Verification Data 1 = Has MAC Verification Data

Note:1. DiscoverZip has 56 Tag (Track 1 Data) and Formal Track1 & 2 Data (No Tags). So DiscoverZip will have 56, FF EE 13, FF EE 14 (3 Tags) later.
2. Visa MSD, Amex, PBOC can have FF EE 13, FF EE 14 (2 Tags for Formal Track 1 & 2 Data).

TLV Encrypted Response Format Examples


Note on Masking


Masked tags include:
57: Optionally masked for Contact EMV 56: Optionally masked for Contact EMV 9F6B: Contactless MSD/EMV Only FFEE13: Contactless MSD Only FFEE14: Contactless MSD Only
5A

Configuration Note


  1. Set PrePANClrData (N)

1 byte parameter, range is 0~6, default value 4

  1. Set PostPANClrData (M)

1 byte parameter, range is 0~4, default value 4

  1. Set ExpireDateOutputOpt

1 byte parameter, value is 0x30 (Mask) / 0x31 (Not Mask), default value 0x31

  1. Set MaskCharID (Mask Character) for Ascii Code Track Data 1 byte parameter, range is 0x20~0x7E, default value 0x2A (star)


  1. Set MaskCharID (Mask Character) for Hex Code Track Data

1 nibble parameter sent as byte value, range is 0x0A~0x0F, default value 0x0C

  1. In 57 Tag Value, the data before 0xDx is PAN data, to be Masked as Tag 5A Value.


  1. In 57 Tag Value, in the data 0xDy ym ms xz, yy mm is expiry date, and sxz is service code; they need not be Masked.


  1. In 57 Tag Value, the data after 0xDy ym ms xz are Other data, they need be Masked.


Example:


ASCII Pan clear data: "012345678912" Pre-PAN clear data characters: 5
Post-PAN clear data characters: 3 Mask Character = "*"
Masked Value = "01234****912"
Hex value clear data: 0x012345678912 Pre-PAN clear data characters: 5 Post-PAN clear data characters: 3 Mask Character = 0x0C
Masked Value = 0x01234CCCC912

Tag5A Value Mask Configuration Note


  1. Set PrePANClrData (N)

1 byte parameter, range is 0~6, default value 4

  1. Set PostPANClrData (M)

1 byte parameter, range is 0~4, default value 4

  1. Set MaskCharID (Mask Character) for Ascii Code Value

1 byte parameter, range is 0x20~0x7E, default value 0x2A (star)

  1. Set MaskCharID (Mask Character) for Hex Code Value 1 byte parameter, range is 0x0A~0x0F, default value 0x0C


Example 1 – TDES / AES mode for Tag5A


1. Plaintext 5A TLV data (5A 08 47 61 73 90 01 01 00 10)

  1. Encrypt this TLV data (5A 08 47 61 73 90 01 01 00 10) to be 16 bytes Encrypted Data (XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX):
    • For TDES mode: The Length should be multiple of 8. If it was not multiple of 8, unit should zero padded y bytes data follow automatically (the length +y should be multiple of 8).
    • For AES mode: The Length should be multiple of 16. If it was not multiple of 16, unit should zero padded y bytes data follow automatically (the length +y should be multiple of 16).


  1. Re-Create New TLV data for Mask:
  • TAG is 5A
  • Length is A1 08:
    • A1 – Bit 7 is 1 note followed data length bytes. Bit 5 is 1 note data is Masked. Bit 0~4 (1) data note followed n bytes (1 byte) data length.
    • 08 – followed 8 bytes data
  • Data is 47 61 CC CC CC CC 00 10 (0x0C is Mask Data)


  1. Re-Create New TLV data for Encryption:
  • TAG is 5A
  • Length is C1 10 (TDES/AES mode):
    • C1 – Bit 7 is 1 note followed data length bytes. Bit 6 is 1 note data is Encrypted. Bit 0~4
  1. data note followed n bytes (1 byte) data length.
    • 10 – followed 16 bytes data

Data is XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX



Example 2 – TransArmor mode for Tag5A
1. Plaintext 5A TLV data (5A 08 47 61 73 90 01 01 00 10)
2. Change Hex Value (47 61 73 90 01 01 00 10) to be Ascii Value (34 37 36 31 37 33 39 30 30
31 30 31 30 30 31 30). We encrypt this ASCII Value data (34 37 36 31 37 33 39 30 30 31 30 31
30 30 31 30) to be 344 bytes Encrypted Data (XX XX XX XX XX XX XX XXXX

XX XX XX XX XX XX XX)


  1. Re-Create New TLV data for Mask:
  • TAG is 5A
  • Length is A1 08:
    • A1 – Bit 7 is 1 note followed data length bytes. Bit 5 is 1 note data is Masked. Bit 0~4 (1) data note followed n bytes (1 byte) data length.
    • 08 – followed 8 bytes data
  • Data is 47 61 CC CC CC CC 00 10 (0x0C is Mask Data)


  1. Re-Create New TLV data for Encryption:
  • TAG is 5A
  • Length is C2 01 58 (344- TransArmor mode):
    • C2 - Bit 7 is 1 note followed data length bytes. Bit 6 is 1 note data is Encrypted. Bit 0~4
  1. data note followed n bytes (2 byte) data length.
    • 01 58 – followed 344 bytes data

Data is XX XX XX XX XX XX XX XXXX XX XX XX XX XX XX XX



Example 3 – TDES / AES for Tag57
1. Plaintext 57 TLV data (57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17 58 98 93 89)
2. Encrypt this TLV data (57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17 58 98 93 89) to be 24
(TDES mode) or 32 bytes (AES mode) Encrypted Data:

    • For TDES mode: The Length should be multiple of 8. If it was not multiple of 8, unit should zero padded y bytes data follow automatically (the length +y should be multiple of 8).
    • For AES mode: The Length should be multiple of 16. If it was not multiple of 16, unit should zero padded y bytes data follow automatically (the length +y should be multiple of 16).


  1. Re-Create New TLV data for Mask:
  • TAG is 57
  • Length is A1 11:
    • A1 – Bit 7 is 1 note followed data length bytes. Bit 5 is 1 note data is Masked. Bit 0~4 (1) data note followed n bytes (1 byte) data length.
    • 11 – followed 17 bytes data
  • If ExpireDataOutputOpt was set "Output Plaintext", expiry date and service code all Need Not be Masked. Data is 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC (0x0C is Mask Data):
    • 47 61 73 90 01 01 00 10 is PAN, it Need be Masked same as 5A Tag Value
    • In D1 51 22 01, 1 51 2 is expiry date (2015year, December), 2 01 is service code, they all

Need Not be Masked.

    • Followed them all Need be Masked.
  • If ExpireDataOutputOpt was set "Output Mask", expiry date Need be masked, service code Need Not be Masked. Data is 47 61 CC CC CC CC 00 10 DC CC C2 01 CC CC CC CC CC (0x0C is Mask Data):
    • 47 61 73 90 01 01 00 10 is PAN, it Need be Masked same as 5A Tag Value
    • In D1 51 22 01, 1 51 2 is expiry date (2015year, December) and Need be Masked, 2 01 is service code and it Need Not be Masked.
    • Following them, all bytes Need be Masked.


  1. Re-Create New TLV data for Encryption (TDES mode):
  • TAG is 57
  • Length is C1 18:
    • C1 – Bit 7 is 1 note followed data length bytes. Bit 6 is 1 note data is Encrypted. Bit 0~4
    1. data note followed n bytes (1 byte) data length.
    • 18 – followed 24 bytes data

Data is XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX



Example 4 - TransArmor mode for Tag57
1. Plaintext 57 TLV data (57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17 58 98 93 89)
2. Change Hex Value (47 61 73 90 01 01 00 10 D1 51 22 01 17 58 98 93 89) to be Ascii Value
and Red item 'D' to be '=' (0x3D) (34 37 36 31 37 33 39 30 30 31 30 31 30 30 31 30 3D 31 35
31 32 32 30 31 31 37 35 38 39 38 39 33 38 39). Encrypt this Ascii Value data (34 37 36 31 37 33

39 30 30 31 30 31 30 30 31 30 3D 31 35 31 32 32 30 31 31 37 35 38 39 38 39 33 38 39) to be

344 bytes Encrypted Data (XX XX XX XX XX XX XX XXXX XX XX XX XX XX
XX XX).

  1. Re-Create New TLV data for Mask:
  • TAG is 57
  • Length is A1 11:
    • A1 – Bit 7 is 1 note followed data length bytes. Bit 5 is 1 note data is Masked. Bit 0~4 (1) data note followed n bytes (1 byte) data length.
    • 11 – followed 17 bytes data
  • If ExpireDataOutputOpt was set "Output Plaintext", expiry date and service code all Need Not be Masked. Data is 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC (0x0C is Mask Data):
    • 47 61 73 90 01 01 00 10 is PAN, it Need be Masked same as 5A Tag Value
    • In D1 51 22 01, 1 51 2 is expiry date (2015year, December), 2 01 is service code, they all Need Not be Masked.
    • Followed them all Need be Masked.
  • If ExpireDataOutputOpt was set "Output Mask", expiry date Need be masked, service code Need Not be Masked. Data is 47 61 CC CC CC CC 00 10 DC CC C2 01 CC CC CC CC

CC (0x0C is Mask Data):

    • 47 61 73 90 01 01 00 10 is PAN, it Need be Masked same as 5A Tag Value
    • In D1 51 22 01, 1 51 2 is expiry date (2015year, December) and Need be Masked, 2 01 is service code and it Need Not be Masked.
    • Followed them all Need be Masked.


  1. Re-Create New TLV data for Encryption (TDES mode):
  • TAG is 57
  • Length is C2 01 58 (344- TransArmor mode):
    • C2 - Bit 7 is 1 note followed data length bytes. Bit 6 is 1 note data is Encrypted. Bit 0~4
    1. data note followed n bytes (2 byte) data length.
    • 01 58 – followed 344 bytes data

Data is XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX, or XX XX XX XX XX XX XX XX XX XX XX XXXX XXXX

XX XX XX XX XX XX XX XX XX

Example 5 – TDES / AES mode

  • If all TLVs are same level.

Raw data: 57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17 58 98 93 89 5A 08 47 61 73 90 01 01

00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01 94 60 02 7F
New data: 57 A1 11 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 84 07 A0 00 00 00 03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX

  • If all TLVs are not same level (e.g., Paypass application list Record). Raw Data:

<FF 81 06 (Tag00)> <82 01 70 (Len00)> <TLV10> <TLV11>
<FF 81 01 (Tag12)> <7F (Len12)> <TLV20> <TLV21> 57 11 47 61 73 90 01 01 00 10 D1 51

22 01 17 58 98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01

94 60 02 7F < TLV23 > … <TLV2n>
<FF 81 01 (Tag13)> <7F (Len13)> <TLV20> <TLV21> 57 11 47 61 73 90 01 01 00 10 D1 51

22 01 17 58 98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01

94 60 02 7F < TLV23 > … <TLV2n>
<TLV14> … <TLV1n>
<FF 81 05 (Tag01)> <60 (Len01)> <TLV10> <TLV11> 57 11 47 61 73 90 01 01 00 10 D1 51

22 01 17 58 98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01

94 60 02 7F <TLV13> <TLV14> …
New data:
<FF 81 06 (Tag00)> <82 01 D5 (Len00)> <TLV10> <TLV11>
<FF 81 01 (Tag12)> <81 B0 (Len12)> <TLV20> <TLV21> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX

XX XX XX XX XX XX XX XX XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 84 07 A0 00 00 00

03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX < TLV23 > … <TLV2n>

<FF 81 01 (Tag13)> <81 B0 (Len13)> <TLV20> <TLV21> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 84 07 A0 00 00 00

03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX <TLV24> … <TLV2n>
<TLV14> … <TLV1n>

<FF 81 05 (Tag01)> <91 (Len01)> <TLV10> <TLV11> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51 22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 84 07 A0 00 00 00 03 10

10 9F 20 C1 08 XX XX XX XX XX XX XX XX <TLV14> <TLV15> …

KSN in TLV format


  1. It only exists in TDES or AES mode.
  2. 3 bytes KSN Tag – DF EE 12.
  3. 1 byte Len – 0A
  4. 10 bytes KSN


KID in TLV format


KeyID (KID) exists in TransArmor mode (TransArmor - KID). Otherwise, for AES or TDES encryption, KSN will be supplied. (See above.)
3 bytes KID Tag – DF EE 12.
1 byte Len – 0B (TransArmor-KID-Length) Value - 11 bytes (TransArmor-KID-Value)

Contact L2 Response Format



06 + <Transaction Result > <Attribution> [<TLV>] >] [<DFEF48> <IndicatorLen>
<IndicatorValue>] [<MAC Verification Data TLV > <MAC Verification KSN TLV>] Or


In response to Retrieve Transaction Result Command:


06 + [<TLV>] [<DFEF48> <IndicatorLen> <IndicatorValue>] [<MAC Verification Data TLV >
<MAC Verification KSN TLV>]
Where:


  1. Transaction Result: 2 bytes (Approve, Decline, Other)
  2. Attribution: 1 Byte

Bit 4/3/0: Captured Data Type 0 0 0 = Contact Card

  1. 0 1 = Contactless Card / EMV
  2. 0 1 = Contactless Card / MSD

0 1 x = MSR Card (For ViVOpay IDG)
Bit 2/1: Encryption Mode 0 0 = TDES

  1. 1 = AES
  2. x = Refer to Tag DFEE26 Byte 2 field "Extended Encryption Mode."


Bit 5: Attribution Byte Extension in Encryption Information Tag DFEE26. 0 = Tag DFEE26 with 1 byte, same as the "Attribution Byte."
1 = Tag DFEE26 with 2 or more bytes, extension of the "Attribution Byte."
Bit 6/7: Encryption Status (For ViVOpay IDG) 0 0 = MSR/MSD off, EMV off

    1. 1 = MSR/MSD off, EMV on
    2. 0 = MSR/MSD on, EMV off

1 1 = MSR/MSD on, EMV on

  1. <TLV> is optional only if transaction was Approved or Declined

<TLV> will include KSN as first tag (DFEE12) while Encryption mode is TDES/AES. Encryption (bit 6) and Masking (bit5) flags will be utilized as appropriate in the Length component of the TLV element

  1. [<DFEF48> <IndicatorLen> <IndicatorValue>]:

<DFEF48> is Indicator Tag
<IndicatorLen> is Indicator Length, variable.
<IndicatorValue> are Tags which were not output due to insufficient RAM. Note: Please refer to Section "Buffer not enough examples for EMV L2."

  1. [<MAC Verification Data TLV > <MAC Verification KSN TLV>] is only valid for SRED & Output MAC Verification Data Option is On; please refer to Section " MAC Verification Data Format" below.


Contactless L2 Response Format



06 + <Status Code > <Error Code >< Attribution > [<TLV>] [<MAC Verification Data TLV>
<MAC Verification KSN TLV>]


Where:

  1. Status Code: 1 Byte. The usage is the same as in KioskII/KioskIII project and are used to specify if transaction was approved or declined.
  2. Error Code: 1 Byte. The usage is the same as in KioskII/KioskIII project and are used to specify if transaction was approved or declined.
  3. Attribution: 1 Byte
    • Bit 4/3/0: Captured Data Type 0 0 0 = Contact Card
  4. 0 1 = Contactless Card / EMV
  5. 0 1 = Contactless Card / MSD

0 1 x = MSR Card (For ViVOpay IDG)

    • Bit 2/1: Encryption Mode 0 0 = TDES
  1. 1 = AES
  2. x = Refer Tag DFEE26 Byte 2 field "Extended Encryption Mode".
    • Bit 5: Attribution Byte Extension in Encryption Information Tag DFEE26 0 = Tag DFEE26 with 1 byte, same as the "Attribution Byte".

1 = Tag DFEE26 with 2 or more bytes, extension of the "Attribution Byte".

    • Bit 6/7: Encryption Status (For ViVOpay IDG) 0 0 = MSR/MSD off, EMV off
  1. 1 = MSR/MSD off, EMV on
  2. 0 = MSR/MSD on, EMV off

1 1 = MSR/MSD on, EMV on

  1. <TLV> is optional only if transaction was Approved or Declined

<TLV> will include KSN as first tag (DFEE12) if encryption mode is TDES/AES. Encryption (bit 6) and Masking (bit5) flags will be utilized as appropriate in the Length component of the TLV element
6. <MAC Verification Data TLV > <MAC Verification KSN TLV> please refer to Section "MAC Verification Data" below.

MAC Verification Data / KSN TLV Format


<DFEFF41> <10> <MAC Value> <DFEFF42> <0A> <MAC Key KSN>
Where:

  • <DFEFF41> is the Tag for MAC Verification Data
  • <10> is length of <MAC Value>
  • <MAC Value> is 16 bytes – MAC value is MAC-Device (Please refer next Section). The msgX is:
    • For Contact L2: "06 + <Transaction Result > <Attribution> [<TLV>] <DFEFF41> <10> "

    • For Contactless L2: "06 + <Status Code > <Error Code > < Attribution > [<TLV>]

<DFEFF41> <10>"

  • <DFEFF42> is the Tag for MAC Verification KSN
  • <0A> is length of <MAC Key KSN>
  • <MAC Key KSN> is 10 bytes – MAC DUKPT Key KSN


MAC-Device

The HMAC result (16 bytes) is used to authenticate messages sent from Device to Host. MAC-Device = HMAC (MAC_KEY, msgX)
Following is MAC_DUKPT_KEY_KSN
The MAC-Device will be the last field in a message and msgX will include data starting from the first byte of message being built (Response Data + <DFEFF41> <10>) up to (but not including) the MAC-Device first byte.
Advancing the KSN is controlled by Device.
HMAC(MAC_KEY, msgX) = H ((MAC_KEY ⊕ opad) | H((MAC_KEY ⊕ ipad) | msgX))
Use HMAC-SHA256 (Refer to RFC2104); retain the left 16 bytes of the calculation to for MAC Authentication.
Where
H is a cryptographic hash function (in this case, SHA-256),
K is a Current MAC Key padded to the right with extra zeros to the input block size of the hash function (64 bytes, in this case), or the hash of the original key if it's longer than that block size, msgX is the message to be authenticated,
| denotes concatenation,
denotes XOR,
opad is the outer padding (0x5c5c5c…5c5c, one-block-long hexadecimal constant),
ipad is the inner padding (0x363636…3636, one-block-long hexadecimal constant).

Example of HMAC


Suppose the data to be hashed with HMAC is 0123456789012345, and the key is
0123456789ABCDEFFEDCBA9876543210. The calculation of HMAC proceeds as follows.
H( (K' ⊕ opad) ‖ H( (K' ⊕ ipad) ‖ m) )
K' is 0123456789ABCDEFFEDCBA9876543210000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
ipad is
363636363636363636363636363636363636363636363636363636363636363636363636363636
36363636363636363636363636363636363636363636363636
K' ⊕ ipad is 37157351BF9DFBD9C8EA8CAE40620426363636363636363636363636363636363636363636
363636363636363636363636363636363636363636363636363636
m is 0123456789012345
K' ⊕ ipad ‖ m is 37157351BF9DFBD9C8EA8CAE40620426363636363636363636363636363636363636363636
3636363636363636363636363636363636363636363636363636360123456789012345
H(K' ⊕ ipad ‖ m) is c6f3b8a5fcbf7c77b44b73a87f81a02cfd6b8be138efcdf184427b8880abb691
opad is 5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C
5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C
K' ⊕ opad is 5D7F193BD5F791B3A280E6C42A086E4C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C
5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C
(K' ⊕ opad) ‖ H( (K' ⊕ ipad) ‖ m) is 5D7F193BD5F791B3A280E6C42A086E4C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C
5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5Cc6f3b8a5
fcbf7c77b44b73a87f81a02cfd6b8be138efcdf184427b8880abb691
H( (K' ⊕ opad) ‖ H( (K' ⊕ ipad) ‖ m) ) is b8682749f16accceedf9c859869f6d7c305d8e8df3820ab063b61b229d4cefa8
For ID TECH products, retain only the first 16 bytes (32 hex nibbles) of the final result.

DFEF48 (Insufficient RAM) Examples


Example 1 – EMV L2 Transaction Result


The response body of EMV L2 Transaction Result:
06 + <Transaction Result > <Attribution> <5A C2 01 58 xx xx xx
…… xx xx xx> <9F 1F C2 01 58 xx xx xx …… xx xx xx> <TLV1> <TLV2>
… <TLVn> <DF EF 48 06 9F 20 57 56 9F 6B>
Means – There are not enough RAM resources to output 4 Tags (9F20, 57, 56 and 9F6B). Please send "Retrieve Transaction Result" command (72 46 07 01 <2 Byte Length> <Tags>) with 4 tags to retrieve them.

Example 2 – Retrieve Transaction Result for EMV L2


Terminal sends "Retrieve Transaction Result" command (72 46 07 01 <2 Byte Length> <Tags>)
with 4 tags (9F20, 57, 56 and 9F6B).
The response body is:
06 + <9F 20 C2 01 58 xx xx xx …… xx xx xx> <57 C2 01 58 xx xx xx
…… xx xx xx> <DF EF 48 03 56 9F 6B>
Means – There are not enough RAM resources to output 2 Tags Value (56 and 9F6B). Please send "Retrieve Transaction Result" command (72 46 07 01 <2 Byte Length> <Tags>) with 2 tags to retrieve them.

Example 3 – Retrieve Transaction Result again for EMV L2


Terminal sends "Retrieve Transaction Result" command (72 46 07 01 <2 Byte Length> <Tags>) with with 2 tags (56 and 9F6B).

The response body is:
06 + <56 C2 01 58 xx xx xx …… xx xx xx> <9F 6B C2 01 58 xx xx xx
…… xx xx xx>
Means – There are enough RAM resources to output all values.

Appendix A: Tags DFEF4B, DFEF4C, & DFEF4D

ID TECH proprietary tags DFEF4B, DFEF4C, and DFEF4D provide a way for track data (and optionally, PAN data) to be supplied in conjunction with an EMV transaction, with or without sentinels, in a form similar to the form track data would take in a conventional MSR transaction.

Tag DFEF4B

Tag DFEF4B is a configuration tag. Use it to tell your ID TECH reader which tracks you want to receive in tag DFEF4D, whether or not to use sentinels, and whether or not to include the PAN as a separate string.
Byte 1:

8

7

6

5

4

3

2

1

NOTES

-

-

-

-

-

-

-

X

  1. – Disable Track 3 Sentinels
  2. – Enable Track 3 Sentinels

-

-

-

-

-

-

X

-

  1. – Disable Track 2 Sentinels
  2. – Enable Track 2 Sentinels

-

-

-

-

-

X

-

-

  1. – Disable Track 1 Sentinels
  2. – Enable Track 1 Sentinels

-

-

-

-

X

-

-

-

  1. – Disable Track 3
  2. – Enable Track 3

-

-

-

X

-

-

-

-

  1. – Disable Track 2
  2. – Enable Track 2

-

-

X

-

-

-

-

-

  1. – Disable Track 1
  2. – Enable Track 1

-

X

-

-

-

-

-

-

  1. – Disable PAN
  2. – Enable PAN

X

-

-

-

-

-

-

-

  1. – All Data Elements Found
  2. – Only First Element Found

Byte 2: RFU
Byte 3: RFU

You can use the top bit of the first byte of DFEF4B to control search behavior: If the bit is OFF, all data elements requested will be provided (if they exist). If the bit is ON, only the first element found will be retrieved and placed in DFEF4D.
If you request multiple data items, they will be concatenated. To know the original lengths of the items, you must retrieve and inspect Tag DFEF4C (see below).
To use tag DFEF4B, add it (as a TLV) to your terminal configuration settings. Send the settings to your device as you normally would. (For example, in ID TECH's Augusta, use command 72 46 02 03 to Set Terminal Settings.)
NOTE: If this tag does not exist in Terminal Settings, tags DFEF4C and DFEF4D will not be generated.
The default value of this tag is 0x12 (Track 2 enabled, with Sentinels).

Data Search Order

When "Only First Element Found" (bit 8 = 1) is set in DFEF4B, Tag DFEF4D will be populated with a single data element according to the following search order
Track 2, Tag 57 (converted to alpha numeric format) Track 2, Tag 9F6B
Track 2, Tag 5F22 Track 1, Tag 56 Track 1, Tag 5F21
PAN, Tag 5A (converted to alpha numeric format) Track 3, Tag 58
Track 3, Tag 5F23
Regardless of the original format, the data will be placed in the DFEF4D tag in alpha numeric format, such that after decryption (and with padding removed) the data will look similar to:
3b343736313733393030313031303031303d31353132323031313134333837383038393f
Which means that after rendering it as ASCII, it would look like:
;4761739001010010=15122011143878089?
When "All Data Elements Found" (BIT 8), is specified in DFEF4B, Tag DFEF4D will be populated with a single instance of each requested data element, according to the following order:
Track 1 requested (bit 6 = 1). Includes first instance of:
Tag 56 = Track 1 Equivalent
Tag 5F21 = Track 1, identical to the data coded
Track 2 requested (bit 5 = 1). Includes first instance of:
Tag 57 = Track 2 Equivalent (converted to alpha numeric format) Tag 9F6B = Track 2 Data
Tag 5F22 = Track 2, identical to the data coded
Track 3 requested (bit 4 = 1). Includes first instance of:
Tag 58 = Track 3 Equivalent
Tag 5F23 = Track 3, identical to the data coded
PAN requested (bit 7 = 1). Includes:
Tag 5A = PAN (converted to alpha numeric format)

Sentinels


For any found data element of Track1, Track2 or Track3, sentinels will be included or not included according to the preferences set in bits 1, 2 and 3.
Compressed Numeric Elements
For any data element captured as compressed numeric, the following rules shall apply:
Padding (0xf) shall not be included
Center separators: 0xd shall be converted to 0x3d ("=")
Data shall be encoded as ASCII representation of binary data example 0x123f = 0x313233 = "123" (ignore padding) example 0x1234 = 0x31323334 = "1234"
example 0x123d456f = 0x3132333d343536 = "123=456"

Tag DFEF4C

This tag's 6-byte value provides the native lengths of tracks 1, 2, and 3, and the PAN (if applicable). Two bytes are reserved for future use.
<Track 1 Length><Track 2 Length><Track 3 length><PAN length><RFU><RFU>
A length of 0 indicates track disabled in DFEF4B or data not available. This tag also serves as an indicator of which data element was found first, when "Only First Element Found" is enabled in DFEF4B.

Tag DFEF4D

This variable-length tag contains track and/or PAN data, encrypted. The exact contents will vary depending on values supplied previously in DFEF4B (see above).
When TDES or AES encryption have been used in conjunction with traditional DUKPT, decrypt the data normally, using the 10-byte KSN found in tag DFEE12.
When TransArmor PKI (RSA) data are present, decrypt with the KeyID value in DFEE12 and Terminal ID found in 9F1C.
(Note: Each track encoded with TransArmor RSA will be encrypted to 344 bytes.)

Revision History


Revision

Description and Reason for Change

Date

By

Rev 50/A

Initial Draft

1-26-2016

KT

B

Edit to Section 5 to remove reference to IDG. Also, fix "Field 11 is always empty" to say Field 12 is always empty. Increment the two following references to match earlier table.

2-19-2016

KT

C

Revised tables to show that tag 56 and 57 data are masked, and also FFEE13, FFEE14, 9F6B are masked.

Substitute "captured data type" for "card type" where appropriate.

Updated references to Attribution Byte (and/or DFEE26) to reflect the latest bit-4 semantics.

"Magstripe data (MSD) constructed from contactless interactions are treated as MSR data" changed to say "Magstripe data (MSD) constructed from contactless interactions are treated as EMV data."

5/27/2016 Added changes for tags 56, 57, 9F

6/21/2016 Clarified treatment of bit 5, field 8, of MSR data.

 

KT

D

Added updates related to TransArmor crypto support. Added updates for MAC support.
P/N of this document updated to 80000502-001

8/5/2016
8/16/2016
9/6/2016

KT KT

E

Added DFEF48 tag (insufficient RAM) with examples. Added detailed example of HMAC calculation.
Document now aligns with 66A of ICC and 67 of EEMSR.

9/23/2016

KT

F

Add tags DFEF4B, DFEF4C, DFEF4D (new encryption tags).

10/03/2016

KT

G

Add support for TransArmor TDES (symmetric key) encryption.

11/20/2017

KT