The previous post sketched the risks involved in using NFC-enabled objects for access control and how the NFC Ring fares against common attacks. The final part in the series examines trade-offs involved in improving security with different tag choices.

Cryptography and NFC tags

As part II pointed out, more advanced NFC tags support access control using cryptographic means, including the original Mifare Classic. The quality of that cryptographic protocol is a different story. Classic tags used a proprietary cipher dubbed Crypto-1 which has been successfully reverse engineered and broken.

Since then NXP has introduced improved models using established cryptographic algorithms. For example DESfire uses triple-DES with two independent keys as the name suggests. Interestingly enough, DESfire chips were vulnerable to a side-channel attack based on measuring power consumption. In terms of the threat model, this falls under the “physical access” category; the attack requires carefully instrumenting the chip and observing its behavior in a controlled environment. Bumping someone in the subway with a stealth reader is unlikely to yield those conditions.

Further up the security chain there is DESfire EV1, which replaces two-key triple DES with AES. As of this writing there are no published attacks in the literature against EV1 model.

The final point along the spectrum is a programmable smart card. For example SmartMX is a family of embedded secure-execution environments from NXP, programmed using Javacard. This allows complete freedom to choose the cryptographic protocol, unlike the situation with picking an existing tag type such as DESfire where the protocol is fixed but users control the key material. For example a custom public-key authentication scheme can be defined or an existing profile such as NIST 800-73 PIV can be reused.

Trade-offs

Improved security  has associated costs, in both the monetary sense and engineering one. A tag must perform expensive cryptographic operations in order to authenticate the reader. That may take time, which is bad enough when dealing with the severely constrained hardware present on those tags. But more importantly it requires power. Since tags do not have batteries or any other internal source of energy, that power must originate with the induction field of the NFC reader, generating a current in the tag antenna. That coupling defines the main constraint on physical dimensions of NFC tags. Smaller antenna could translate into longer delays when scanning, incompatibility with certain readers that emit insufficient power or finicky behavior for positioning the tag in relationship to reader.

A ring form factor is hampered not only by the dimensions of what users are willing to wear but also the curvature of the antenna surface away from the plane of the reader. That argues against some heavyweight options such as EV1 but Ultralight C could have been a viable option. Starting with the original Ultralight (48 bytes and no access control) this variant triples the available space and adds 3DES authentication.

Opening more than one door

There is another complication to using these tags: the reader must have access to the same keys. This is relatively easy when the object is used for a single scenario. Typically tags start out with each sector configured to use default transport keys.  If that NFC ring is only used to unlock one Android device, that device can take over key-management and rotate keys to new, randomly generated ones stored on the phone. That approach gets tricky when the tag is used for multiple access-control scenarios, such as gating entry into several rooms with their own badge reader. In that case some type of cooperative scheme is required for each reader to reserve one or more free sectors for its own use. (Public-key based credentials do not have this problem, since a single public-key can be used with any number of access control implementations.)

CP