Public health concerns have put a new emphasis on contactless credentials. The blossoming variety of reader formats complicates the task of reading and verifying IDs.

Kiran Vasishta • ELATEC, Inc.

Contactless credentials can be divided into two categories: soft credentials that include mobile phone apps transmitting data via BLE (Bluetooth Low Energy) or NFC (Near Field Communication), and hard credentials that typically include low-frequency (125 kHz) and high-frequency (13.56 MHz) passive RFID transponders. Security concerns are fostering interest in these sorts of credentialing. Consequently, OEMs and system integrators increasingly must understand subtle aspects of how to choose an appropriate RFID reader.

One concern is that readers be “future proof” or built to sustain technical advances and shifts in market forces. Additionally, customers have varied needs and requirements, particularly those who use contactless credentials. For example, a university will have different security needs than a federal office. Not only do the credentials differ but so, too, does the level of security.

For these reasons, a lot of contactless credentialing installations demand some of level of customization. Such efforts often involve changing or adjusting the output format, adapting hardware to read multiple technologies, and providing a means to update the reading technology after installation. Another common area of customization involves ensuring the system can accommodate future upgrades in security algorithms and data integrity checks, necessary because cryptosecurity methods are rapidly evolving.

The reader

The reader itself is typically just a small piece of the puzzle. Usually, the embedded product connects to a host that runs its application which interacts with a back-end system or database. Some instances require a matching of credential IDs that are already part of the end-user database or active directory. In systems where the host application cannot manipulate the reader data, the reader must be able to format its output to help match the credential ID stored in a database.

There are numerous RF standards and technologies that apply to RFID. Examples include ISO14443A/B, which defines contactless 13.56-MHz cards used for identification and their transmission protocols; ISO 15693, which applies to vicinity cards, cards which can be read from a greater distance as compared with ISO 14443 standard-based cards, and low-frequency cards also widely referred to as “Proximity cards” or Prox cards that may use different modulation schemes such as FSK (Frequency Shift Keying) and ASK (Amplitude Shift Keying).

Here the reader typically provides power to the card via a wireless connection. Examples of RF technologies used in this area include NFC HCE (NFC Host Card Emulation, where an electronic appliance such as a smartphone behaves exactly as a contactless smart card), ordinary passive EM4x02 and Prox tags which operate at 125 kHz, and HITAG tags that also operate at 125 kHz but are memory based. The reader must be able to fully support all such transponders.

RFID readers must not only detect these varying card technologies but also read their data and interact with them. For example, a UID (unique identification number) may serve as a credential ID and in some instances. Memory-based transponders may store the credential ID in their memory. Here the reader must read not only the UID but also the memory segments of the transponder.

The flexibility to change the firmware or configuration is important when the reader is integrated as a subsystem. Firmware updates accommodate scenarios such as adding a new credential to the customer’s fleet or upgrading a credential with better security. Clearly, over-the-air or contactless RFID configuration capabilities save time by eliminating the need for making physical connections.

The host application, that is, the software component that directly interacts with the reader, can have subtleties that may not be apparent initially. Typically, the reader either communicates with the system either as a keyboard or as a serial device. There are instances wherein the host application expects the reader to work as a PC/SC (personal computer/smart card) device.

Thus the software specifications of the host application directly affects the functioning of the reader. Problems to look out for include whether appropriate drivers are available and whether the reader will be able to interact with the host via standard software communication protocols. These factors impact the software development necessary when setting up the reader.

Any embedded design project involves creating software for a specific purpose. In RFID readers, the end goal might be to complete a secure transaction or exchange information under time constraints. In some situations, the reader may simply send data over a serial line. In others, the task might be to perform operations based on inputs captured by the embedded host application or hardware.

An example of such a scenario would be when the host expects the reader to detect transponders only when they transmit a particular character. Another example might be having the reader execute a sequence of commands based on a GPIO signal (General Purpose Input/Output) that the host initiates. Such tasks can be easier to implement if the reader can run a custom protocol under the embedded host.

Encryption

Typically, it is desirable to have widely used encryption standards such as AES, DES, or 3DES be part of the reader firmware. Doing so helps embedded designers more readily implement encryption. But there are cases where the host system uses a HashMap based algorithm. (As a quick review, a HashMap or hash table is a special data structure that allows a fast retrieval of its individual elements. Elements get stored as a key-value pair; to look things up, you give the HashMap a key that lets it find the right value.) In such a scenario the reader should be able to implement the algorithm and produce the right output.

There are scenarios where the host system also expects CRCs (Cyclic Redundancy Checks) to be part of the data stream as a way of verifying the integrity of the data. It is extremely helpful for the reader to run applications and custom algorithms that let the host decrypt the data as well as verify data integrity.

Finally, it’s important that developers be able to modify the reader’s or physical behavior to handle customer needs. Some customers expect the reader to blink a green LED when an RFID card is presented. Others expect the reader to beep and transition its LED color from red to green. The control of such basic feedback mechanisms in response to user actions is frequently a key operating point. DW

---

Filed Under: Product Design & Development, TECHNOLOGIES + PRODUCTS, Design World articles, Wireless devices
Tagged With: elantec
 

---