Considering Custom Keys for Contactless Cards

by:
David Stallsmith
Director of Strategic Initiatives at ColorID

Since improved security is one of the main reasons for migrating to contactless cards, and that security is based on encryption, owning your encryption key should allow us to make all our card-based systems inter-operable, right?
​
Well, not exactly.  Let’s break it down. 

ENCRYPTION
Encryption keys are long numbers that act like passwords to lock and unlock contactless smart card data, such as the ID number used to allow door access.  Typically a manufacturer will program their cards and readers with data secured by their own secret key.  If the manufacturer’s key were to be publicly known, all their cards and readers would be subject to compromise.  Sometimes manufacturers use their own proprietary encryption algorithms, but these have not resisted hacking well, especially in the case of MIFARE Classic and HID iCLASS (legacy version).  

MIFARE DESFire EV1
DESFire EV1 by NXP uses AES 128, a standard encryption algorithm that is considered to be unbreakable for long term data storage.  HID, Schlage, Blackboard, Identiv and many other card and reader manufacturers provide EV1 solutions, some with an option for custom, user-owned keys.  Theoretically, an institution could share the custom key used to program its cards with any reader manufacturer of its choice.  However, there are a few more hurdles to clear on the path to interoperability. ​

Document for AES Background by NIST

MIFARE DESFire EV1 cards and readers share many parameters that require decisions and/or data, in addition to the encryption key.  In some cases, there could be additional keys, up to 14 per application.  Readers are secure, but not too intelligent.  NXP created a protocol called PACSA which can be used as a guide for EV1 programming, for access control.  Nonetheless, a card programmed for one reader won’t work on another reader that is configured to expect different parameter values.  Key diversification is a common example of one of these parameters.  The reader has to know if the key used to encrypt the data was diversified by scrambling with each chip’s Card Serial Number (or UID), or not.  Without alignment on the parameter, the reader cannot read the secret data from the card.

HID
HID Seos and iCLASS SE cards also use AES 128 and are available with custom keys through the Elite Key program.  This enhances card security for any institution; however, these cards can only be read by readers with HID technology, such as iCLASS SE and Omnikey readers, and ASSA ABLOY electronic locks.  Regarding interoperability, HID readers read many more card types than other readers and work with almost all access control and other card systems. 
 
ENCODING
Many ID issuance software products support custom key encoding of NXP chips, both inline and at the desktop.  MIFARE encoding configuration is fairly straightforward, but EV1 setup can require professional services.  Check for which printers are supported.  HID offers software for encoding NXP, iCLASS, Seos and other chips in HID printers and at a desktop encoder. 
 
THIRD PARTY
Encoding for third party applications can require the system provider to share their encoding parameters and encryption keys.  In some cases, such as biometrics, a system may provide its own encoding application. 

CONCLUSION
Custom encryption keys offer the promise of interoperability for all card systems.  However, there are many complications involved, some technical and some business, and not all can be resolved for every system.  ColorID has the experience to be able to help an institution find inter-operable card system solutions, both existing and planned.  ​

​WANT TO LEARN MORE?
Contact ColorID using the form below and we will be happy to discuss custom encryption key options available for your contactless credentials.