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
Random Oracle 
Hey man, great write up. You really nail a lot of key points. One thing I think is worth mentioning is that as you adopt different crypto methods you adopt companies building ICs that aren’t possible to read.. Compatability issues if you will..
For example Samsung phones have a Broadcom chipset, these can’t read the NDEF of some Mifare Crypto enabled ICs.
It’s another trade off to be mindful of, NFC Type 1 and 2 are set in stone but as you deviate away from NTAG and move towards application specific and crypto enabled ICs you can get burned badly.
Imagine if the NFC Ring shipped and didn’t work with all Samsung phones for example?
Amal Graafstra is my go-to guy for stuff like this and could probably explain this a lot better than me 🙂 I will drop him through a copy of your article. Cheers for the write up and Cheers for the link to NFCRing.com, it’s appreciated 🙂
johnyma22: I think Ultralight C is Type 2 and so there shouldn’t be compatibility problems.
Thank you for the comments.
Yes, the compatibility problem between Broadcom NFC controller and NXP proprietary Mifare Classic tags are well understood. This was discussed at length in a blog post earlier here: https://randomoracle.wordpress.com/2013/09/13/samsung-tectiles-nfc-standards-and-compatibility/
That still leaves two options featuring both strong cryptography and widespread compatibility:
1. DESFire standards mode. These have been around for almost 10 years and support 3DES/AES. They can be addressed using standard ISO-7816 commands, which every NFC controller is capable of supporting. (Not to be confused with the proprietary DESFire protocol, which would have required licensing from NXP.) As proof that this works, note that even Broadcom-equipped Nexus 5 can read the San Francisco public-transit “Clipper” cards which are based on DESFire.
2. Ultralight C, as the commenter below pointed out. This one has been around for 5 years. It is a cheaper, lightweight alternative. Because it requires less power than DESFire, it plays better with small form-factors and constrained antenna designs.
Any comment on the NTAG216 password feature and “originality” signature?
I’m curious as to how good the originality signature really is. If it’s as good as a PUF (physical version of a hash function) it would be enough to prevent skimming the password from the phone. However, PUFs rely more on the fidelity of the scanner, it’s hard to imagine consumer devices having scanners sensitive and robust enough to verify a complex PUF in a short amount of time.
However, even without the originality signature, the password feature would force an attacker to first skim the phone before reading the NFC chip or eves-drop on an exchange. However, at 888 bytes, one could store a size-able encrypted private key (or some other secret) which would be decrypted once it landed on the phone (hopefully in an SE) and destroyed once the phone goes into sleep mode. I think this is an option for the FIDO protocol.
Physically unclonable functions (PUFs) rely on unique hardware characteristics that are a function of the physical manufacturing process.
NTAG 216 originality signatures appear to be a much higher-level concept implemented in software.
According to section 8.9 in the NTAG216 document from NXP:
Click to access NTAG213_215_216.pdf
This is a signature over the UID itself, which can be retrieved from the chip.
The only thing this prevents is creating a bogus tag with UID X unless you have also seen that particular tag before eg it is useful to prevent large scale counter-feiting where some company produces millions of fake tags for commercial purpose.
It doesn’t stop the targeted attack where adversary gets to scan your tag in order to create an identical clone.
Some interesting stuff here on your blog. I recently got a NTAG216 xNT implant (from Dangerous Things). I’m currently only using it with a Samsung Ezon door lock and to unlock my Nexus 5, but keen to see what else I can do with it.