TLV data objects use the following primitive data types:

• A = Alphabetic (string, no numbers).

• AN = Alphanumeric (string).

• B = Binary value, which includes bit combinations (“OR” types).

• CN = Compressed numeric.

• N = Numeric.

• T = TLV Constructed data object (TLV Value contains additional layers of TLV-encoded data the parser should continue to process).

NFC UID Type

These file types conform to the Common File Structure format. The File Payload of these files contain a certificate in PEM format.

Certificates must be loaded into the device in the order of trust starting with the root CA, next intermediate CA(s) and ending with the leaf (server or client for example) so that the device can verify the signature of each certificate. If the certificates are not loaded in order, they will be rejected.

When loading a server cert, the associated key pair must already exist in the device as the CSR keys or as the existing server or client cert and will be used to verify that the public key contained in the certificate is correct. If the keys don’t match the certificate will be rejected. If the certificate is associated with the CSR keys, the CSR keys will be associated with the certificate and will no longer be available for other certificates until re-generated.

Initial server or client certificates can not be loaded until the respective CSR keys and CSR is generated. To generate a CSR see Generate CSR (WLAN Only) - Command 0xEF03.

Some files types conform to the common file structure format that follows. The following is a list of file types that conform to this format.

1. EMV file types

2. Certificate File Types

3. Certificate Signing Request (CSR) File Types

Common File Structure

This section defines the primitive and composed data types, TLV (Tag-Length-Value) data objects, file structures, and cryptographic key formats used throughout the device command set, including track data, display strings, EMV configuration file types (ARQC, ARPC, Batch, CA Public Keys), security parameters, TR‑31 key blocks, certificate and CSR file structures, and card emulation.

The Encryption Type provides the key type, variant, and other information the host can use to decrypt encrypted data included in various payloads. The possible values are an ORed bitmask using the following elements:

• 0xxx xxxx = Fixed Key (Not used)

• 1xxx xxxx = DUKPT Key

Terms and Definitions

• DUKPT – Derived Unique Key Per Transaction

• OID – Object Identifier

• SRED - Secure Reading and Exchange of Data

There are 7 OIDs defined for these 7 SRED Data IDs.

Each OID value contains a two-byte DUKPT slot ID and a one-byte transformation ID.

DUKPT Slot IDs

The existing TR31 Module supports 32 MagTek DUKPT Slot IDs, from 0x2000 to 0x201F.

The Key Injection Software Tool shall inject DUKPT keys through these DUKPT Slot IDs.

Transformation IDs

This is the list of DUKPT transformations defined in both the Legacy and AES specifications.

During TR31 Key Injection, each DUKPT Slot ID contains a parameter indicates the purpose of a Key Set.

• Example 1: The restriction value is 0x3F

  • This Key Set can be used for all purposes.

• Example 2: The restriction value is 0x3E

SRED Data ID map configuration values (Slot ID and Transformation ID) must be checked and rejected if they don’t meet the following conditions.

• The DUKPT Slot ID must be loaded. (Table - Settings of Injected DUKPT Slot IDs)

• The loaded DUKPT Slot ID must allows this type of SRED Data ID. (Table - The Definition of Restriction Bitmap).

• The transformation must be allowed by Table - Allowed Key Mapping Table.

Here is the list of parameters of 4 DUKPT Slot IDs based on the existing Key Injection Tool.

If the Transformation ID of the latest key mapping request is different, then the original OID setting of the other SRED Data ID will be forced to match the latest OID setting. For example, SRED Data ID 2 has been mapped to 0x2007 0x04, user wants to map SRED Data ID 4 to 0x2007 0x05, then the OID setting of SRED Data ID 2 will be forced to 0x2007 0x05.

The following OID Values indicate that:

• 200701: Map PIN-TDES to DKPTM7-2007 PIN Encryption Variant.

• 20020B: Map Account Data to DKPTM2-2002 Data Encryption Usage.

• 200702: Map MAC to DKPTM7-2007 MAC Generate/Verify Variant.

Figure 1 - Configuration Usage Values

A TR-31(X9.143) key block consists of three parts:

The Key Block Header(KBH) which contains attribute information about the key and the key block and is not encrypted. It is always treated as ASCII.

• The first section is 16 bytes with a fixed format defined below.

• The second section is optional within the standard, but required for current products.

The Confidential Data, which is encrypted and always binary.

• Two bytes indicating the key length (in bits, AES-128 is 128 bits, so length will be 0080).

• The secret key and/or sensitive data.

• Padding as required (random bytes 0x00 to 0xFF).

The MAC, which is of varying length as follows:

• 64 bits if the TDEA key derivation method is used (typically not used for this device).

• 128 bits if the AES key derivation method is used.

Symmetric keys are padded with Block Padding to the maximum length for the algorithm, 192 bits for TDEA or 256 bits for AES, to hide the true length of short keys.

The data to be encrypted and the MAC are always binary for calculation purposes. The encrypted data and the MAC are converted to ASCII hex as the last step.

Date and time strings specified within the TR-31 block are represented according to the rules described in ISO 8601 and TR-31. Year is 4 digits. Time uses UTC 24 hour clock. Some functions like ‘toISOString()’ will produce a string of format yyyy-mm-ddThh:mm:ss.fffZwhere fff is a decimal fraction of a second, Z is UTC time zone. The device ignores ‘Z’ and ‘.fff’ if they are present. Seconds ‘:ss’ are optional. Date, hours, and minutes are required. For example, March 23, 2020 4:19PM is encoded as 2020-03-23T16:19at minimum, but could also be 2020-03-23T16:19:00.000Z.

DUKPT – Derived Unique Key Per Transaction OID– Object Identifier

SRED- Secure Reading and Exchange of Data

There are 7 new OIDs defined for these 7 SRED Data IDs.

Each OID value contains a two-byte DUKPT slot ID and a one-byte transformation ID.

The existing TR31 Module supports 32 MagTek DUKPT Slot IDs, from 0x2000 to 0x201F. The Key Injection Software Tool shall inject DUKPT keys through these DUKPT Slot IDs.

This is the list of DUKPT transformations defined in both the Legacy and AES specifications.

During TR31 Key Injection, each DUKPT Slot ID contains a parameter indicates the purpose of a Key Set.

Example 1: The restriction value is 0x3F

This Key Set can be used for all purposes.

Example 2: The restriction value is 0x3E

This Key Set can be used for all purposes, except PIN Encryption.

Example 3: The restriction value is 0x01

This Key Set can be used for PIN Encryption only.

SRED Data ID map configuration values (Slot ID and Transformation ID) must be checked and rejected if they don’t meet the following conditions.

1. The DUKPT Slot ID must be loaded.

2. The loaded DUKPT Slot ID must allows this type of SRED Data ID.

3. The transformation must be allowed by .

Here is the list of parameters of 4 DUKPT Slot IDs based on the existing Key Injection Tool.

Note: If SRED Data ID 2 and 4 are mapped to the same Key Set, then they must have the same Transformation ID. If the Transformation ID of the latest key mapping request is different, then the original OID setting of the other SRED Data ID will be forced to match the latest OID setting. For example, SRED Data ID 2 has been mapped to 0x2007 0x04, user wants to map SRED Data ID 4 to 0x2007 0x05, then the OID setting of SRED Data ID 2 will be forced to 0x2007 0x05.

The following OID Values indicate that:

1. 200701: Map PIN-TDES to DKPTM7-2007 PIN Encryption Variant.

2. 20020B: Map Account Data to DKPTM2-2002 Data Encryption Usage.

3. 200702: Map MAC to DKPTM7-2007 MAC Generate/Verify Variant.

Figure 1 - Configuration Usage Values

The device formats ARQC messages as shown in the EMV ARQC (DynaPro Format) Type table below. The default is an EMV standard list of ARQC message tags. The host may also customize the contents of ARQC messages by setting 1.1.1.1.1.2 - EMV ARQC Message Tag List.

EMV ARQC (DynaPro Format) Type - A

The device encrypts the value inside the Encrypted Data Primitive container using the Encrypted Transaction Data Encryption Type parameter and working key associated with the keyset number currently active in the device’s configuration. As a requirement for using DUKPT encryption algorithms, the device pads it so the length of its value is a multiple of 8 bytes for TDES, or 16 bytes for AES. The device uses container DFDF58 to report how many bytes of data object DFDF59 are padding. Data object DFDF59 itself is formatted like the table below after the host decrypts it.