Well-publicized hacks illustrate why contactless credentials demand sophisticated security measures that can evolve as fast as the cracking techniques used by bad actors.
Kiran Vasishta • ELATEC, Inc.
In recent years, multinational corporations including Cathay Pacific, Facebook, and Uber have been heavily fined for security and data protection violations. This period has seen a rise in data protection laws as more and more information is gathered and shared online. As such, it becomes crucial to asses security capabilities when choosing an embedded device that touches potentially sensitive data.
One approach to passing encrypted data over the air employs Telaeris XPressEntry mobile access control hardware and software that integrates with existing security systems for mobile identity verification. XPressEntry access control software runs on any Windows Mobile or WinCE-compatible handheld device. A server synchronizes data to and from connected handhelds.
RFID readers can transmit personal or user identification data either to a host system such as a PC or to an endpoint such as a human machine interface (HMI). A passive RFID transponder, a mobile phone app using BLE/NFC, or smart cards and other contact-based credentials all can carry sensitive data or personal information. It’s more common for smart card or contact-based credentials to store personal information such as names, addresses or date-of-birth than in contactless credentials where an identification number may be used.
There are numerous security vulnerabilities related to low frequency (125 kHz) contactless transponders. One can find references to vulnerabilities online that discuss how to easily access unprotected static card information. Adversaries may then clone this credential that may be used for triggering action such as granting access to a facility or unlocking a computer.
Some references also highlight vulnerabilities in Wiegand type interface about intercepting the data signals to capture card value. The Wiegand protocol is among the most widespread protocols for proximity card reader systems. A Wiegand card contains two short wires which store data magnetically. When the card is pulled through the reader, the wires transmit the either high or low voltage signals to create binary data for authenticating the card credentials. (A third Wiegand wire provides a common ground). The problem is, inexpensive Wiegand hacks are easy to find. Consequently, some older RFID transponders and communication interfaces are now considered fundamentally compromised.
There are a series of questions designers should ask when developing RFID apps. The first is whether the situation requires encryption capabilities. If it does, can the reader involved execute cryptographic algorithms?
Where encryption is necessary, designers must determine the exact channel through which encryption must be enforced. It could be that the host interface requires the exchange of encrypted data, or protected data must pass over the air interface. Bear in mind that crypto facilities only work when they are configured correctly. There have been instances where key cards have only encrypted the UID but left other personal information unencrypted and vulnerable to interception.
Furthermore, many types of contactless transponders can store data and encrypt or lock these segments with cryptographic keys. A card reader must not only decrypt the memory and access the data but also provide an easy means for the end-user to carry out this operation.
In many instances, companies using the card reader have their own customized cryptographic keys for their credentials and are unwilling to share these keys with the maker of the card reader. To handle these situations, the card reader must have the capability to accept custom keys from someone other than its manufacturer. This can be facilitated in multiple ways, such as implementing high-level APIs, by allowing the user to write applications for the card reader, or by means of a GUI enabling the end user to enter keys.
Another question to ask is whether the reader and cards must exchange encrypted data. If so, of course, the card reader must be able to support the exchange. Some don’t.
In a typical scenario, the card reader behaves as a medium to facilitate data collection and transfer between the transponder and the host system. The host system can either be an endpoint that locally validates the presented credential, or it can be a microcontroller that sends data over the network to the cloud or to a database for validation and authentication.
If there’s a need for encryption between the RFID media and the reader, the appropriate credentials are required. There are use cases wherein smart cards or passports store personal information such as name, address, date-of-birth or biometric data. Here the card reader must host encryption algorithm engines such as AES, DES, 3DES, or the capability to implement custom algorithms.
In cases where smartcards or contact-based credentials are used, the host system typically drives the communication in its entirety. So the card reader must also have:
● Software capabilities such as Personal Computer Smart Card (PCSC) or Chip Card Interface Device (CCID) modes of communication. PCSC is the interoperability standard set for integrating smart cards and smart card readers into the mainstream computing environment. CCID is a USB protocol that allows a smartcard to connect to a computer via a card reader using a standard USB interface. Drivers to facilitate communication with the host also enable easy software integration.
Deconstruct a Secure Access module (SAM) on a smart card and this is what you’ll see. The SAM stores the cryptographic keys to access applications and data. Once on the SAM, the keys can never leave — an attacker would not be able to extract the raw key material from the chip.
● Hardware support for communication standards such as ISO7816 and the presence of Secure Access Modules (SAM) slots and other contact-based interfaces. ISO7816 deals only with contact smart cards and defines aspects of the card and its interfaces such as the card’s physical dimensions, the electrical interface, card logical structure, various commands used by the application programming interface, and so forth. The SAM can be used for cryptographic computation and secure authentication and physically can either be a SIM card and plugged into a SAM slot in a reader, or an IC in a housing on the smart card.
Some applications require a mutual authentication between SAMs and RFID media. Some readers support this kind of transaction, but others don’t. Typically, SAMs are used to generate application keys based on a specific master key or to generate session keys. They also enable secure messaging between the RFID media, the reader, and the host system.
Encrypted memory
Many contactless credentials hold memory segments that are encrypted with cryptographic keys. These keys are often stored in SAMs and supplied to card reader manufacturers. This practice not only ensures the security of the keys but adds a step in the authentication process. The card reader in this case should first perform authentication operations with the SAM and then carry out a series of cryptographic and bit-manipulations between the contactless card and the SAM. This operation can be further secured by adding a key diversification step. The card reader must be able to support such a scenario both in the hardware as well as in the software.
Many companies using card readers require that the card reader natively support such a scenario, and they have the ability to provide high-level APIs to help in their implementation. In addition, high-security applications demand the transfer of data in an encrypted format.
One can ensure end-to-end encryption/security with the help of SAMs. In such an architecture, the reader facilitates mutual authentication with the RFID media and the SAM, thus transferring protected data over a radio link and also ensuring the security of encryption keys. The reader can also transfer data encrypted by the SAM to the host system.
Note that the safety of distributing SAMs, as well as administering the installation process within the reader, should be treated as separate issues and tackled accordingly. There is also a possibility of the readers being stolen or the SAM modules being dismounted from the reader. If these scenarios are possible, they must be factored into the overall security procedures.
Note as well that the Wiegand card and the Wiegand interface for data transmission is 40-year old technology. While Wiegand cards are still in production, they have been largely replaced by newer and cheaper forms of access cards. However, these new cards are still based on the Wiegand data format. Though the cards are new, that format is susceptible to interception as the data are available in plain text.
There are other technologies that can offer higher security from interception and support encrypted data exchange. Various industrial products output a code in Wiegand format. Often this is an inconvenient form for reading to a PC or other device having only a RS232 serial port. So readers frequently employ Wiegand-to-RS232 converters that transform Wiegand 26-bit and 37-bit formats to a RS232 data stream.
Printer manufacturers often integrate RFID readers in their products to provide secure printing. In this context, the TWN4 product family is a frequent choice because of its easy upgrade and update in the field. TWN4 products, such as the TWN4 MultiTech 2 BLE PCB (below), support features such as remote firmware updates or authentication via smartphone instead of RFID card.
Additionally, developers must discern whether the reader can be tampered with, and if so, how much it matters. As an example, card readers attached to multi-function printers (MFPs) for releasing print jobs usually aren’t strategic. Tampering with the reader can put the printers offline but will not compromise the safety of the documents. Typically, if the card reader is sabotaged, the MFP software prevents the release of any information.
On the other hand, high-security environments such as data centers need greater protection. There are several technologies such as mechanical and optical tamper detectors that can be embedded directly on the card reader for protection against threats.
Tamper switches are built-in to many types of equipment, and external tamper switches can be used with equipment lacking a built-in switch. Mechanical micro switch or plunger-type tamper switches are the most common types. Tamper switches usually detect when the cover of the device is removed. Alternatively, they can also detect when an RFID reader is removed from the wall.
Downloads
At some point, card readers generally will require some kind of software or firmware update. The process is quite similar to that for phones and PCs except the software or configuration updates might require encryption. For example, suppose an application just reads static card numbers from an RFID media or isn’t using data protected by encryption keys. Neither the firmware nor the configuration need be encrypted simply because these files do not carry any sensitive information.
On the other hand, suppose data read by the reader contains personal information or proprietary corporate information. The data must be encrypted, and the readers must hold the cryptographic keys. In such a scenario the configuration software or firmware must be encrypted as well because it also holds sensitive information. Encrypted configuration software or firmware poses no security risk, so it can be shared with customers or with the card reader manufacturers for updates.
To navigate such issues, integrators must work with subject matter experts and establish requirements and objectives. Security planning generally takes place after the development of the concept, system architecture, and data flow. Both for security features and overall ease of implementation, it’s best to use readers flexible enough to accommodate likely future changes and adaptations. DW
You may also like:
Filed Under: Sensors (proximity), Wire & Cable Tips, Product design, MOTION CONTROL, ELECTRONICS • ELECTRICAL