Other Data Types
Signature Capture File Type (Touch Only)
The signature capture file type produced when the host invokes Command 0x1801 - Request Cardholder Signature (Touch Only) is a TLV data object in the format below. If the encryption is enabled in Command 0x1801, please refer to Encrypted Signature Capture File Type below.
Table - Signature Capture File Type
81
08
Signature Window Width and Height Bytes 0..1 = Left edge (minimum value of all X coordinates) Bytes 2..3 = Right edge (maximum value of all X coordinates) Bytes 4..5 = Top edge (minimum value of all Y coordinates) Bytes 6..7 = Bottom edge (maximum value of all Y coordinates)
B
R
0000 00FD 0000 0078 (landscape) 0000 00C8 0000 00B9 (portrait)
82
var
Signature Coordinate Values List This is a blob that consists of a raw list of point coordinates representing the signature. Each coordinate is 4 bytes long, where the first 2 bytes are the X coordinate of that point and the second 2 bytes are the Y coordinate of that point.
B
O
Table - Encrypted Signature Capture File Type
F9
var
Container for MAC structure and generic data, length excludes MAC padding and MAC checksum
T
R
/DFDF54
var
MAC KSN
B
R
/DFDF55
var
MAC Encryption Type
B
R
/F8
var
Container for Encrypted Data
T
R
//DFDF59
var
Encrypted Data Primitive ( length includes padding) Decrypt the value of this TLV data object using the algorithm and variant specified in the Encrypted Data KSN parameter and the Encryption Type parameter below to read its contents.
B
R
//DFDF56
var
Encrypted Data KSN
B
R
//DFDF57
01
Encrypted Data Encryption Type See section 4.4 Encryption Type for a list of valid values.
B
R
PKCS7 padding for MAC calculation, maximum 16 bytes, minimum 1 byte
Four-byte MAC checksum. The host should calculate the MAC and verify that it matches.
Table - Encrypted Signature Capture File Type (after decryption)
F9
var
Container for MAC structure and generic data, length excludes MAC padding and MAC checksum
T
R
/DFDF55
var
MAC Encryption Type
B
R
/F8
var
Container for Encrypted Data
T
R
//DFDF59
var
Encrypted Data Primitive, length includes padding
T
R
///FC
var
Decrypted Data Container, length excludes padding
T
R
////A1
var
Signature file container, maximum 4,000 bytes
T
R
/////81
08
Signature Window Width and Height, refer to Table 45 - Signature Capture File Type.
B
R
/////82
var
Signature Coordinate Values List, refer to Table 45 - Signature Capture File Type.
B
R
////81
04
Real Time Clock, Epoch Time in seconds, unsigned 32 bits. The date and time shall be Universal Time Coordinated (UTC).
B
R
////82
04
Device Serial Number
B
R
////A3
var
User data parameters for item #0 to item #3. The maximum total size of 0xA3 TLV is 4,000 bytes.
T
O
/////81
var
User data item #0, optional
B
O
/////82
var
User data item #1, optional
B
O
/////83
var
User data item #2, optional
B
O
/////84
var
User data item #3, optional
B
O
PKCS7 padding for encryption, maximum 16 bytes, minimum 1 byte
//DFDF56
var
Encrypted Data KSN
B
R
//DFDF57
01
Encrypted Data Encryption Type See section 4.4 Encryption Type for a list of valid values.
B
R
PKCS7 padding for MAC calculation, maximum 16 bytes, minimum 1 byte
Four-byte MAC checksum. The host should calculate the MAC and verify that it matches.
Security Operation Type
This non-TLV data structure consists of four or five bytes that describes a security operation, including the algorithms and methods to be used in that operation.
Table - Security Operation Type
0
Operation Type
0x01 = Key Agreement
0x02 = Command Authorization Using Signature
0x03 = Command Authorization Using MAC
0x05 = Data Authentication Using MAC
0x07 = Data Encryption
0x10 = Data Signature
B
R
1
Operation Algorithm If Operation Type is Key Agreement type:
0x01 = ECDHE
If Operation Type is a Signature type:
0x01 = ECDSA (indeterministic)
If Operation Type is a MAC type:
0x01 = HMAC
0x02 = CBC-MAC
0x03 = CMAC
If Operation Type is an Encryption type:
0x01 = DEA
0x02 = 2TDEA
0x03 = 3TDEA
0x04 = AES-128
0x05 = AES-192
0x06 = AES-256
B
R
2
Operation Curve/Mode/Hash/Cipher If Operation Type is a Key Agreement type, this specifies the Curve:
0x01 = P192
0x02 = P224
0x03 = P256
0x04 = P384
0x05 = P521
If Operation Type is a Signature type, this specifies the Hash:
0x01 = MD5
0x02 = SHA-1
0x03 = SHA-224
0x04 = SHA-256
0x05 = SHA-384
0x06 = SHA-512
0x07 = SHA-512/224
0x08 = SHA-512/256
0x09 = SHA3-224
0x0A = SHA3-256
0x0B = SHA3-384
0x0C = SHA3-512
If Operation Type is a MAC type, this specifies the Encryption Algorithm:
0x01 = DEA
0x02 = 2TDEA
0x03 = 3TDEA
0x04 = AES-128
0x05 = AES-192
0x06 = AES-256
If Operation Type is an Encryption type, this specifies the Mode:
0x01 = ECB (Block)
0x02 = CBC (Block)
0x03 = CFB (Stream)
0x04 = OFB (Stream)
0x05 = CTR (Stream)
B
R
3
KDF/Curve/Padding If Operation Type is a Key Agreement type, this specifies the KDF:
0x01 = SP800-56A / X9.63
If Operation Type is a Signature type, this specifies the Curve:
0x01 = P192
0x02 = P224
0x03 = P256
0x04 = P384
0x05 = P521
If Operation Type is a MAC type, this specifies the Padding:
0x00 = None (for streaming modes)
0x01 = Zeros (ISO 9797 Padding Method 1)
0x02 = One and zeros (ISO 9797 Method 2)
0x03 = Length + zeros (ISO 9797 Method 3)
0x10 = PKCS7 (pad # = pad length)
0x11 = X9.23 (random + pad length)
0x20 = Random (when length is known)
If Operation Type is an Encryption type, this specifies the Padding:
0x00 = None (for streaming modes)
0x01 = Zeros (ISO 9797 Padding Method 1)
0x02 = One and zeros (ISO 9797 Method 2)
0x03 = Length + zeros (ISO 9797 Method 3)
0x10 = PKCS7 (pad # = pad length)
0x11 = X9.23 (random + pad length)
0x20 = Random (when length is known)
B
R
4
MAC Block Size If Operation Type is a MAC type, this specifies the data to be MACed must be padded to a multiple of this many bytes. For all other Operation Types, do not include this byte.
B
O
Security Parameters Type
Table - Security Parameters Type
81
var
Operation This contains an instance of a - Encrypted Signature Capture FileType structure specifying the operation to be performed.
B
R
84
var
Data Reserved for future use. Do not include this parameter. It is reserved for Initialization Vector or nonce, if needed.
B
O
85
var
Extra Data Item Reserved for future use. Do not include.
B
O
A8
var
Key Information This specifies the key used in the operation. Populate with a Key Information Type TLV data object. For ECDSA operations, do not include this parameter.
T
O
A9
var
Second Key Information (Reserved, do not include) This specifies a second key used in the operation. If needed, populate with a Key Information Type TLV data object.
T
O
Key Information Type
Table - Key Information Type
81
02
Key Slot ID Identifies the key being used for operation. See Table 59 -Key Slot IDs.
B
R
82
var
Key Label The label that indicates the key type. For example, DEVTK.
AN
O
86
var
Key Derivation Details Use Key Serial Number (KSN) in requests, Key Derivation Information in responses.
B
O
88
var
Additional Information Reserved for future use. Do not include.
B
O
NFC UID Type (EMV Contactless Only)
Table – NFC UID Type
DF79
var
NFC UID
B
R
GPO Response Type (EMV Contactless Only)
Table – NFC UID Type
81
var
GPO Response
B
R
TR-31 Key Block Type
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.
<-----------
Encrypted
--------------
------------>
<--------
------------
MAC
--------------
--------------
------------>
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.
Table - TR-31 Block Fixed Header
0
Key Block V ID
‘D’
1..4
Key Block Length
Calculated (in decimal, e.g. 138 bytes shown as ‘0138’
5..6
Usage
Look up the desired Key Type in Table 55 below and select this value from the Usage column.
7
Algorithm
Look up the desired Key Type in Table 55 below and select this value from the Algorithm column.
8
Mode of Use
Look up the desired Key Typein Table 55 below and select this value from the Mode of Usecolumn.
9..10
Key Version #
‘00’
Always ‘00’
11
Exportability
‘N’
Always no export allowed
12..13
# option blocks
Calculated
14..15
Reserved
‘00’
Table - TR-31 Key Type Table - Usage/Algorithm/Mode
Transport (KBPK)
‘K1’
‘A’ / ‘T’
‘D’
Initial DUKPT Key
‘B1’
‘A’ / ‘T’
‘X’
Fixed MAC (CMAC)
‘M6’
‘A’ / ‘T’
(‘C’, ’G’, ’V’)
Fixed Encrypt
‘D0’
‘A’ / ‘T’
(‘B’, ‘E’, ‘D’)
Table - TR-31 Optional Blocks
‘IK’
DUKPT KSID
‘KS’
Key Set Identifier (e.g. data used by host to find and/or derive this key).
‘KC’
Key Check Value (KCV) (Legacy or CMAC)
‘PB’
Padding Field
‘TS’
Current Time Stamp (optional) see description in previous section.
‘KP’
KCV of KBPK that created this Key Block (optional-preferred)
‘21’
MagTek Additional Key Info From Table - MagTek Custom TR-31 Small Optional Block
Table - MagTek Custom TR-31 Small Optional Block
0.1
Block ID
'21'
MagTek Added Key Info Block
2..3
Block Length
var
ASCII Hex (Length 01-FF from offset 0)
4..7
Owner Tag
‘MGTK’
Avoid collision with others using Block ID ‘21’
8..9
Data Tag
‘10’
Field ID
10..11
Data Len
‘01’
Field Length (ASCII Hex 00-FF)
12
Data
‘T’,’P’, or ‘0’
Field Data for Key Environment
T = Test
P = Production
0 = Erase Key
13…
Added elements
More Fields (Tags, Lengths, and Data)
Table - MagTek Custom Key Data Fields
‘10’
‘01’
Key Environment
T = Test
P = Production
0 = Erase Key
‘11’
‘04’
Key Slot ID See Table 59 - Key Slot ID.
‘12’
‘04’
Key Slot ID of Transport Key
‘20’
--
Reserved
‘21’
‘04’
DUKPT Data Type Restriction Bitmask This is for Transport Keys and DUKPT keys. Default to 0.
‘31’
‘07’
Device Serial Number
‘32’
‘10’
Challenge Token 10h = 16 characters
‘33’
‘10’ ..‘18’
Expiration Date/Time This is in UTC format, use short form if possible. Reserved.
Table - Key Slot IDs
10xx
Transport Keys (KBPK)
1000
TMPTK
Temporary KBPK
Key agreement process from Command 0xF017 - Establish Ephemeral KBPK
N/A
1001
MTK
Master Transport Key
TMPTK
K1AD
1002
DEVTK
Device Master Transport Key
MTK
K1AD
1003
FINTK
Financial Master Transport Key
MTK
K1AD
Table - Key Slot IDs
1021
PRODTK
(MAGTEK INTERNAL ONLY) Production Transport Key
DEVTK
K1AD
1022
MFGTK
(MAGTEK INTERNAL ONLY) Manufacturing Transport Key
DEVTK
K1AD
1081
MKIFTK
MagTek KIF Financial Transport Keys
FINTK
K1AD
1101
FREQMK
Factory Request MAC Key
PRODTK
M6AV
1102
MREQMK
Manufacturer Device Request MAC Key
MFGTK
M6AV
1111
MFRQMK
Manufacturer Financial Request MAC (Configuration) Key
MKIFTK
M6AV
0x2000 to 0x201F
DKPTM0 to DKPTM1F
DUKPT Initial Keys,
MKIFTK
B1TX
DUKPT Key Mapping
Terms and Definitions
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.
Table - SRED Data IDs and OIDs
SRED Data ID
OID
OID Size
0: Not assigned
N/A
N/A
1: PIN-TDES (supported on PED devices Only)
0x010102040101
3
2: Account Data
0x010102040102
3
3: MAC
0x010102040103
3
4: Magneprint (supported on devices with MSR Only)
0x010102040104
3
5: MagTek Token
0x010102040105
3
6: User Data 1
0x010102040106
3
7: PIN-AES (supported on PED devices Only)
0x010102040107
3
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.
Restrictions of a DUKPT Slot ID
Table - Transformation IDs for DUKPT Legacy and AES
Transformation ID #
Usage Name
Type
Data for calculation
0
Reserved
1
PIN Encryption
Legacy
00 00 00 00 00 00 00 FF
2
MAC Generate/Verify
Legacy
00 00 00 00 00 00 FF 00
3
MAC Verify
Legacy
00 00 00 00 FF 00 00 00
4
Data Enc/Decryption
Legacy
00 00 00 00 00 FF 00 00
5
Data Encryption
Legacy
00 00 00 FF 00 00 00 00
6
Reserved
7
PIN Encryption
AES
0x1000
8
MAC Generate
AES
0x2000
9
MAC Verify
AES
0x2001
A
MAC Generate/Verify
AES
0x2002
B
Data Encryption
AES
0x3000
C
Data Decryption
AES
0x3001
D
Data Enc/Decryption
AES
0x3002
Table - The definition of Restriction bit map
Bit #
5
4
3
2
1
0
Data Type
User Data (RFU)
Token (RFU)
Magneprint
MAC
Account Data
PIN
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.
The Rules of Key Mapping
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 63)
The loaded DUKPT Slot ID must allows this type of SRED Data ID. (Table 62)
The transformation must be allowed by (Table 64).
The settings of DUKPT Slot IDs injected through TR31
Here is the list of parameters of 4 DUKPT Slot IDs based on the existing Key Injection Tool.
Table - Settings of Injected DUKPT Slot IDs
DKPTM0-2000
TDES
0x3E
DKPTM2-2002
AES-128
0x3F
DKPTM3-2003
AES-256
0x3F
DKPTM7-2007
TDES
0x3F
The Allowed Key Mapping Table
Table - Allowed Key Mapping Table
0
Not assigned
-
-
1
PIN-TDES (supported on PED devices Only)
01
Not allowed
2
Account Data
01, 04, 05
0B, 0D
3
Transaction MAC
02
08, 0A
4
MagnePrint (supported on devices with MSR Only)
01, 04, 05
0B, 0D
5
MagTek Token (RFU)
RFU
RFU
6
User Data #1 (RFU)
RFU
RFU
7
PIN-AES (supported on PED devices Only)
Not allowed
07
…
RFU
-
-
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.
Examples of Key Mapping
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.
20030B: Map MangePrint to DKPTM3-2003 Data Encryption Usage.
000004: MagTek Token is RFU, 0000 ID does not exist (this is default value).
000004: User Data is RFU, 0000 ID does not exist (this is default value).
200207: Map PIN-AES to DKPTM2-2002 PIN Encryption Usage.
Figure 4.20-1 - Configuration Usage Values
Common File Structure
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.
EMV file types
Certificate File Types
Certificate Signing Request (CSR) File Types
Table - Common File Structure
MGTKAP10= Start Of File Marker
C1
4
File Type See Table 206
B
R
N/A
CE
var
File Payload See the “File Type” subsections of section - Data Types andShared TLV Data Objects.
B
R
N/A
Certificate File Types
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 Command 0xEF03 – Generate CSR (WLAN Only).
Certificate Signing Request (CSR) File Types
These file types conform to the Common File Structure format.
The File Payload of these files contain a certificate signing request in PEM format. To generate a CSR see Command 0xEF03 – Generate CSR (WLAN Only).
The device will erase the CSR file from volatile memory after the host fetches it with Command 0xD821.
- Start Get File from Device. After fetching the CSR, the keys used to generate the CSR will still exist in non-volatile memory associated with a CSR and can be used to generate a new CSR if needed.
Card Emulation
Card Emulation Overview
Card emulation enables a DynaFlex/DynaProx device to simulate a Type 4 smart card. The emulated card has the following characteristics:
Compliance: Card emulation conforms to ISO/IEC 14443 Type-A and NFC Forum Type 4 standards.
Passive Operation: The emulated card functions in passive mode. The phone is responsible for generating the magnetic field required to activate the simulated card.
Read-Only: The emulated card is read-only and does not support writing.
Supported Data Type: Supports the URI (URL) data type.
Device Compatibility
iPhone Support: NFC card reading was introduced on Apple iPhones starting with the iPhone 7.
Android Support: Android added NFC support in 2012; however, compatibility depends on the specific phone model and hardware capabilities. Most Android phones released since 2016 support NFC. Verify with the phone’s manufacturer to confirm compatibility.
Google Pay Indicator: If a phone supports Google Pay, it is likely capable of reading NFC tags.
Last updated