Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section covers how DynaFamily readers protect cardholder data and manage keys: encrypting data at the point of read, the keys and key-serial numbers behind DUKPT, verifying message integrity with MACs, loading keys with TR-31, and the PCI requirements deployers must meet. These pages are the concepts and procedures; the security commands and data objects that implement them live in the API & Command Reference.
Applies to: DynaFamily (DynaFlex II PED, Go, SCR, DynaProx). The core concepts — DUKPT, KSN, MAC, TR-31 — apply to MagTek MMS SCRAs generally.
Reference Section
Information Available
The section (where you are now) contains articles on implementation. actual commands and objects live in the section:
Key Security Commands
Individual Security Data Objects can be found in the section.
Change the device's lock state or its lock passcode.
Retrieves information about a key slot and the key stored in it.
The operational requirements the device enforces for PCI compliance: the 24-hour automatic reset and the device lock feature.
The data object, its tags, and structure (in the command reference).
How DUKPT derives a unique key per transaction, and the path (and reasons) for moving from legacy 3DES/TDEA DUKPT to AES DUKPT on your devices and host.
What a KSN is, how it's structured, and how it identifies the unique key used to encrypt a given transaction under DUKPT.
How a MAC lets the host and device confirm a message hasn't been altered in transit, and when one is required.
How the reader encrypts data at the point of read (SRED), how to determine which key was used, and how to decrypt the output on your host.
The ANSI TR-31 key-block format used to transport and load keys securely into the device.
The operational requirements the device enforces for PCI compliance: the 24-hour automatic reset and the device lock feature.
Reference Section
Information Available
0xE001 - Get Challenge
Requests a random challenge from the device, used to build a secured command.
0xEEEE - Send Secured Command to Device
Transmits another command to the device securely.
0xEF01 - Load Key using TR-31
Loads a key into one of the device's secure key slots.
Reference Section
Information Available
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.
This structure contains an Encrypted Signature Capture FileType specifying the operation to be performed.
Identifies the key being used for operation.
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site:
💬 Developer Forum:
Documentation Feedback:
Help us improve this documentation!
The device can use two different types of keys: Triple Data Encryption Standard (TDES) DUKPT Keys and AES DUKPT Keys. The Key Serial Number (KSN) format is slightly different depending on which type of key is injected into the key slot that is being used by the operation being performed or the data being passed.
When the device and host are using TDES keys, the Key Serial Number (KSN) is an 80-bit value. The rightmost 21 bits are the current value of the encryption counter associated with that key. The leftmost 59 bits are the Initial KSN for that key, which is specified during key injection and is a combination of the Key Set ID that identifies the Base Derivation Key (BDK) injected into the device during manufacture, and the device’s serial number (DSN); how those two values are combined into the 59 bit Initial KSN is defined by a convention the customer defines when architecting the solution, with support from MagTek.For example, one common scheme is to concatenate:
a 7 hex digit (28 bit) Key Set ID,
a 7 hex digit (28 bit) Device Serial Number,
and a 3 bit Initial Key Load Counter the injecting host increments each time the same key is re-loaded into the device.
In these cases, the key can be referenced by an 8-digit MagTek part number (“key ID”) consisting of the 7 hex digit Key Set ID plus a trailing “0.”
“MAC” is an abbreviation of Message Authentication Code, which is a string of bytes included in a message that can be used to provide reasonable assurance that the message originated from a trusted source and has not been modified.
This section describes how to calculate MACs for EMV ARQC and EMV Batch Data.
The key and variant used to calculate the MAC is determined by how the DUKPT Key Mapping is mapped; this can be set up for TDES or AES mode.
The key used to calculate the MAC is normally the same key used to encrypt the encrypted data included as part of the same data structure. For TDES MAC, the key variant is always Message Authentication, Request or Both Ways. For AES MAC, this can be AES-128 or AES-256; the valid usages are: 0x08 = MAC Generate, 0x0A = MAC Generate/Verify.
For TDES MAC:
ANSI X9.24-3-2017
The MAC operations follow the CBC procedure described in ISO 16609 Section C.4 using padding method 1 defined in ISO 9797 section 6.1.1.
For AES CMAC:
NIST Special Publication 800-38B Section 6.2 MAC Generation
The data structure for both EMV ARQC and EMV Batch Data has the following format related to MACing:
AAAA /* 2-byte MSB message length excluding padding and CBC-MAC */
F9<len> /* container for MAC structure and generic data */ DFDF54(MAC KSN)<len><val>
DFDF55(MAC Encryption Type)<len><val> DFDF25(IFD Serial Number)<len><val>
<Nested TLV data objects specific to the message>
<Padding to force the 2-byte MSB message length plus F9 plus padding to be a multiple of 8 bytes>
<Four byte CBC-MAC of all data starting with the 2-byte MSB message length and ending with the last byte of padding (if any)>Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site:
💬 Developer Forum:
Documentation Feedback:
Help us improve this documentation!
When is the right time to transition to AES DUKPT and what needs to be considered?
Since the 1970s the electronic payments and secure banking communities have strived to provide their customers with greater convenience, faster speeds, and improved security for electronic transactions. Throughout this timeline, the Open Standards Community, comprised of the International Standards Organization (ISO) and the American National Standards Institute (ANSI-X9), have led the way with the development of numerous security standards that have provided an open platform for proper implementation of accepted encryption and authentication methods. This platform was further augmented in 2007 when the PCI Security Standards council adopted these standards and provided a superset of additional guidance and requirements for PCI DSS.
Collectively, the Open Standards and PCI Security Standards communities have provided a trusted foundation for guiding the global implementation of accepted security methods for Electronic Payments and Secure Banking.
Paramount amongst these security standards has been defining the use of encryption and authentication technologies for the protection of customer PINs and payment data.
TDEA ENCRYPTION WITH DUKPT KEY MANAGEMENT
For and , the device encrypts data using TDES in CBC-like chaining without an Initial Vector:
The device begins by TDES encrypting the first 8 bytes of clear text data. The 8-byte result is placed in an encrypted data buffer.
Continue using TDES CBC method with the encrypted 8 bytes XORed with the next 8 bytes of clear text; encrypt that result and place it into the encrypted data buffer.
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site: https://www.magtek.com
💬 Developer Forum: https://forum.magtek.com
Documentation Feedback:
Help us improve this documentation!
That said, numerous universities and security labs have conducted research and published data that suggests the security capabilities of TDEA DUKPT may soon be challenged (and surpassed) by security threats from advanced computing platforms that will brute-force calculations at ever faster speeds (e.g., quantum computers). These threats may soon provide a viable path for attackers to “crack” the TDEA DUKPT level of security. To mitigate these threats, stronger encryption and authentication methods are required.
In anticipation of increased security threats to the TDEA DUKPT platform, the Open Standards community released a new set of improved security standards in 2017 that support AES DUKPT. (Reference: ANSI X9.24-3) The AES DUKPT standards provide a pathway to improved security features that are significantly stronger and more resistant to brute-force attacks. Specifically, these standards use the AES algorithm (Advanced Encryption Standard) in conjunction with an updated DUKPT specification. AES-128 DUKPT and AES-256 DUKPT are the new standards.
AES-128 uses crypto keys that are 128-bits in length and AES-256 uses crypto keys that are 256-bits in length. Both are far more secure than the existing TDEA DUKPT implementation that uses crypto keys that provide only 112-bits of key strength.
In the world of cryptography, each additional bit represents an order-of-magnitude improvement in security. The larger AES key sizes represent a significant improvement in encryption protection from attackers. In addition, the AES algorithm itself provides numerous security improvements for faster calculation speeds and reduces the possibilities of crypto-analysis side-channel attacks.
In addition to stronger AES encryption, CMAC (cipher-based message authentication code) authentication enhances the security of sensitive data. In this context, CMAC authentication is the cryptographic process of validating that the encrypted sensitive data has not been manipulated or altered from its original form. The authentication process begins within the trusted hardware reader device, where prior to AES encryption, the sensitive clear-text data has a cryptographic CMAC calculation applied to it using a secret MAC key. This results in a unique 6-digit CMAC checksum that is unique to the sensitive data.
The sensitive data is then AES encrypted within the hardware reader device and the CMAC checksum is included with the encrypted data packet that is transferred to a trusted decryption host. Upon receipt at the trusted decryption host, the sensitive data is both decrypted and CMAC validated to confirm that clear-text sensitive data is still in its original form and without alteration or compromise.
Combined, the use of AES DUKPT encryption in combination with CMAC data authentication provides a powerful “one-two punch” that ensures sensitive data remains protected and intact.
Planning your Roadmap
TDEA DUKPT is in its twilight era and needs to be replaced by the more secure AES DUKPT platform. The benefits of doing so are improved security and higher confidence that financial transaction data will remain safe for now and into the future.
To stay ahead of potential threats, PCI has been encouraging the electronic payments community to begin the migration from TDEA DUKPT to AES DUKPT to protect both PIN and payment data. Although no mandates have been made, the threat landscape is expanding, and the urgency to migrate towards more secure encryption is accelerating.
WHAT DATA DO I NEED TO PROTECT? WHAT PROTECTION SHOULD I USE?
Ideally, to meet PCI DSS requirements, it is necessary to protect sensitive PAN (Personal Account Number) payment data and/or PIN (Personal Identification Number) data so that the clear-text sensitive data is never stored, transmitted, or available within the merchant’s payment systems. To do this, it is recommended to use AES DUKPT to protect this sensitive data.
IS THERE A REQUIREMENT TO AUTHENTICATE DATA?
No. PCI DSS only requires that sensitive data be protected/encrypted. However, this document recommends that CMAC authentication be used when available, as it provides an additional layer of security to ensure that sensitive data has not been altered from its original form. This will direct which decryption host services, card readers, and PIN entry devices are used to meet this extra level of security.
After determining the data that needs to be protected and the best protection method, the next step is to determine how to build out the complete ecosystem including the customer environment, hardware, and services.
WHAT HARDWARE DO I NEED?
To move to AES DUKPT encryption, you will need a card reader / PIN entry device (PED) that is specifically rated and approved to support AES DUKPT operations. Check the data sheet of your device or speak with the product support team from your vendor. Ideally, the device should be a “PCI Approved” device rated as “PCI 6.x” (or higher) and list AES support.
DO I NEED NEW KEYS?
Yes, you will minimally need to have a new AES BDK generated as your Data Protection Key. If the reader device also supports PIN entry, an additional AES BDK is required as your PIN Protection Key. Regarding AES Key Size, you will need to select between 128-bits or 256-bits. Typically, the card reader / PED vendor provides key-generation and key-injection services.
WHAT ABOUT DECRYPTION SERVICES?
You will need to check with your existing Payment Gateway / Decryption service and validate that they can support AES DUKPT decryption for your specific reader device. Ensure they can support both AES-128 and AES-256 key sizes. Additionally, you should check if they can provide CMAC data validation services.
AES-128 VS AES-256 KEY SIZE? WHICH ONE SHOULD I CHOOSE?
All things being equal, it is preferable to migrate to AES-256 DUKPT. Doing so ensures that you are using the maximum level of encryption protection available. However, in some cases you may discover that certain products / services only support AES-128 DUKPT. In that case, it is your preference. Although AES-256 DUKPT is strongest, AES-128 DUKPT still provides encryption that is substantially stronger than TDEA DUKPT and is fully supported by PCI.
HOW DO I INJECT THE NEW AES KEY(s)?
Typically, all newly ordered reader devices are injected with their AES key(s) from the factory during the initial order process. For devices already in the field, these devices can typically be updated via remote management services. Check with your reader vendor for details.
CAN I STILL USE MY TDEA DUKPT DEVICES DURING THE MIGRATION TO AES?
Yes. There should be no problems with operating a “mixed fleet” of both TD
Transitioning from TDEA DUKPT to AES DUKPT requires a plan and trusted partners. MagTek and Magensa have a complete solution of integrated hardware, services, and support to make this migration simple, fast, and painless. Partner with us today and let us show you how to migrate to a higher-security AES DUKPT platform that provides maximum data protection for your customers and your business.
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
If the final block of clear text contains fewer than 8 bytes, the device pads the end of the block to make 8 bytes.
After the final clear text block is XORed with the prior 8 bytes of encrypted data, the device encrypts it and places it in the encrypted data value.
No Initial Vector is used.
The host must decrypt the data in 8-byte blocks, ignoring any final unused bytes in the last block. When a value consists of more than one block, use the CBC method to decrypt the data by following these steps:
Do not XOR the first block with anything.
Concatenate all blocks.
Determine the expected length of the decrypted data (for EMV ARQC and EMV Batch Data this information is included as part of the unencrypted data structure) and truncate the end of the decrypted data block to the expected data length, which discards the padding at the end.
When the device and the host are using TDES DUKPT key and the device is encrypting data, the host software must generate a key (the “derived key”) to use for decryption.
The lookup methods the host software uses depend on the overall solution architecture and are outside the scope of this document. Most solutions do this in one of two ways, both of which use the Initial Key Serial Number that arrives with the encrypted data:
Look up the value of the Base Derivation Key using the Initial KSN portion of the current KSN as an index value, then use TDES DUKPT algorithms to calculate the value of the Initial Key; or
Look up the value of the Initial Key directly, using the Initial KSN portion of the current KSN as an index value.
Apply TDES DUKPT algorithms to the Initial Key value and the encryption counter portion of the KSN that arrives with the encrypted data.
Determine which variant of the current key the device used to encrypt. The variants are defined in ANS X9.24-1:2009 Annex A. Which variant the host should use depends on the type of data the host is decrypting. The encrypted portions of EMV ARQC and EMV Batch Data both use the Data Encryption, Request or Both Ways variant.
Use the variant algorithm with the current key to calculate that variant, then decrypt the data according to the steps in How to Decrypt Data.
For EMV ARQC and EMV Batch Data, the device encrypts data using TDES in CBC-like chaining without an Initial Vector:
The device begins by TDES encrypting the first 8 bytes of clear text data. The 8-byte result is placed in an encrypted data buffer.
Continue using TDES CBC method with the encrypted 8 bytes XORed with the next 8 bytes of clear text; encrypt that result and place it into the encrypted data buffer.
Repeat until all clear text bytes have been encrypted.
If the final block of clear text contains fewer than 8 bytes, the device pads the end of the block to make 8 bytes.
After the final clear text block is XORed with the prior 8 bytes of encrypted data, the device encrypts it and places it in the encrypted data value.
No Initial Vector is used.
The host must decrypt the data in 8-byte blocks, ignoring any final unused bytes in the last block. When a value consists of more than one block, use the CBC method to decrypt the data by following these steps:
Do not XOR the first block with anything.
Concatenate all blocks.
Determine the expected length of the decrypted data (for EMV ARQC and EMV Batch Data this information is included as part of the unencrypted data structure) and truncate the end of the decrypted data block to the expected data length, which discards the padding at the end.
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site: https://www.magtek.com
💬 Developer Forum: https://forum.magtek.com
Documentation Feedback:
Help us improve this documentation!
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site: https://www.magtek.com
💬 Developer Forum: https://forum.magtek.com
Documentation Feedback:
Help us improve this documentation!
TR-31 is an ANSI standard format for securely transporting a cryptographic key from one system to another. Instead of sending a key as raw bytes, the sender wraps it in a key block that binds the key to information about how it may be used — so a key can't be moved to a device and then used for a purpose it was never intended for. Dyna-family readers use TR-31 to load keys into their secure key slots.
Two pieces work together:
TR-31 Key Block (data object) — the format itself: a header describing the key's attributes (type, algorithm, allowed usage, mode) plus the encrypted key and a MAC that protects the whole block from tampering. This is what you build and hand to the device.
— the command that delivers a TR-31 key block to the reader and loads it into a key slot. The device validates the block, then stores the key for use.
Loading or rotating a key on the device — for example, provisioning an initial DUKPT key or updating a key later in the field. The TR-31 format is how the key gets there safely; how DUKPT then uses that key per transaction is covered in the security guides.
Reference Section
Information Available
The data object, its tags, and structure (in the command reference).
Loads a key into one of the device's secure key slots.
DUKPT, key serial numbers (KSN), and how keys are used once loaded.
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site:
💬 Developer Forum:
Documentation Feedback:
Help us improve this documentation!
Due to Payment Card Industry (PCI) certification requirements, the device must automatically reset at least once every 24 hours. This is required for security purposes, so that the device can reinitialize memory and perform a self-test. Host software developers and potentially end users should be aware of this.
By default, the device will automatically reset 23 hours after it boots up and it will attempt to send a warning notification message to the host 3 minutes before the reset occurs.
The default behavior is adjustable. See the following for more information:
Device Reset Will Occur Soon notification in
One way the host software could handle receiving a device reset-will-occur notification:
Cancel any operation that is in process (for example, a transaction) if it is unlikely to end before the reset.
Optionally send instead of waiting for the automatic reset to occur.
Re-connect with the device and re-start any operation that was in process.
The purpose of locking a device is to disable most of the device’s functionality for use cases that need this extra layer of security. When a device is locked, it will reject all commands except for a few. Use of the device lock feature is optional. It is not required by PCI.
The device lock state can be either unlocked or locked. The device lock state can be retrieved by getting a property.
The device lock state can be changed by setting a secure property or it can be changed with a command that requires knowledge of the device lock passcode.
The device can be configured to always have the device lock state set to locked after a reset or power cycle by setting a property.
Commands and properties to manage the device lock feature:
Only the following commands are allowed when the device lock state is set to locked:
The device lock passcode can be changed by setting a secure property or it can be changed with a command that requires knowledge of the current device lock passcode.
Need Help?
For additional support, please contact MagTek Support:
Technical Support:
📧 Email: support@magtek.com
📞 Phone: 1-800-788-6835 (US) | +1-562-546-6616 (International)
🕐 Hours: Monday-Friday, 6:00 AM - 5:00 PM PST
Online Resources:
🌐 Official Site:
💬 Developer Forum:
Documentation Feedback:
Help us improve this documentation!