In a previous article I presented an overview of the general security features of our lilitab swipe. I described the two main protection mechanisms: the high strength ABS enclosure with embedded swipe unit along with the integrated information encryption at the reader head.
In this article, I want to briefly cover another subtle, but no less important security feature, Device Unique Key Per Transaction, or DUKPT.
The Triple Data Encryption Standard (3DES) algorithm used by the MagTek MagneSafe reader inside the lilitab swipe encrypts customer data three times using a 64-bit key for each pass resulting in an overall key length of 192 bits. Simply put, the original data is encrypted with the first key, that encrypted data is encrypted with the second key, and so on.
However, if the keys are compromised, the overall security would be compromised. Though difficult and incredibly time consuming, a resilient hacker could get a unit and continually swipe a bunch of cards and try to derive the keys. With current computing technology, we’re probably talking about a decade or so of time for a “brute force” attack.
But what if the key used to encrypt the data were changed each time a swipe occurred? That would mean that two successive swipes, using the same card, would yield different encrypted data (cryptext). That’s how DUKPT works.
Inside the electronics embedded in the reader head—the part that handles the card swipe—resides an algorithm to generate a new encryption key for each swipe. So when the data is encrypted and sent to the back end for processing (the credit card gateway) only the encrypted data and a serial number, the number of the swipe, is included, plus a few pieces of supportive information.
In order to allow different gateways to operate with their own security schemes, a master key is used to generate the keys used to encrypt the individual transaction. This master key is termed “base derivation key” or BDK. Only the embedded swipe electronics and the gateway (and of course the secure facility that embedded the keys into the readers) know the BDK. In this manner, neither the lilitab electronics nor the app performing the point of sale function has any knowledge of the personal customer information, which reduces PCI scope for the app developer and thus, reduces development costs while increasing security for your customers.
So, a card is swiped. The number of the swipe at that unit is used along with the BDK to generate a “derived” key which is used to encrypt personal customer data, thus, the term “Derived Unique Key”—each swipe derives a new, unique encryption key, “Per Transaction”, or each time a card is swiped.
DUKPT and 3DES are not the only security mechanisms provided by a lilitab swipe unit. In a future article I will cover the concept and use of Tokenization to provide additional security for users of the lilitab swipe.
Ken Maskrey - Director of Systems Engineering
For more information, please contact us at info@lilitab.com.
