What is the Purpose of NFC NDEF Signature Records?
The NFC Forum Signature RTD 1.0 specification was first released as a specification in 2010. Michael Roland later identified ways to improve the specification and assisted the NFC Forum in updating it. Now a candidate specification, the final NFC Forum Signature RTD 2.0 is scheduled to be released in the not too distant future. So I wanted to revisit some of the important observations made by Eric and Michael in that blog post.
Imagine walking into your favorite coffee shop, and while you wait in line, you tap an NFC smart poster. It connects you to free WiFi, offers you the promotion of the day, and allows you to place an order without having to configure anything. It’s a great user experience — but how do you trust the NFC tag? That’s where the Signature RTD comes in.
The Signature Record applied to an NDEF record adds integrity protection to the contents of the tag. When a user taps a signed tag, the signature is verified through a certificate chain from a trusted third party Certificate Authority (CA).
Technically, the Signature RTD idea borrows heavily from Code Signing, where apps are digitally signed so that they can’t be modified. Without this, the whole application ecosystems for mobile phones (and PCs, for that matter) would really not work. Apple’s and Google’s third party apps are digitally signed before they can be offered on their respective app stores. While not perfect, it does helps prevent malicious use.
The ecosystem for NFC Signatures would work as follows: Certificate Authorities (using the NFC Forum Signature RTD Certificate Policy) would issue signing certificates to organizations and individuals so that they can sign their tags (NDEF messages). Let’s call them tag authors. These signing certificates chain back to a root certificate stored on NFC enabled devices so that they can be verified, and in turn, allows the NFC enabled device to verify the signature on the NDEF message.
How does the user experience on mobile devices differ between signed tags and unsigned tags? That’s really up to the OS vendors and app developers. At a high level, it improves the user experience. All the user has to do is tap the tag. If the signature verifies, then the action is performed. If there is no signature, the user may be asked if it is okay to proceed. The user should be able to get additional information, such as the name of the tag author. While hackers could get signing certificates, they probably won’t because they could then be tracked and easily revoked.
Back to the questions posed in the blog:
- Cloning. Is it true that signatures don’t prevent copying or cloning? Yes and no. I could copy that signed tag and deploy it on another tag elsewhere, however, a hacker can’t tamper with the content and one can identify the author through the certificate. One could leverage a web service to check the tag’s UID with that signed tag. This can be cloned, but it requires a significant effort (finding UID programmable tags) and more importantly, it can be detected through analytics.
- Tag replacement. Could a tag be replaced? Sure, but in most cases, tags will be mounted in a poster or behind a barrier – glass or plastic. I believe there are simple countermeasures to prevent tag replacement.
Michael Roland also raised very important points:
- Signature RTD 1.0 only signed the payload and not the header. This was addressed in Signature RTD 2.0, thanks to Michael.
- There is no definition as to how signed and unsigned records will be handled on NFC enabled devices. That’s true. The user experience example above is by no means a standard. A good example is how browsers handle https. You will notice a solid green lock to indicate that a secure TLS connection was made. This has received a lot of criticism in the industry because users mostly ignore the lock and the warnings when certificates expire. We can learn from this in NFC and create a more seamless user experience when tags are signed versus unsigned.
- The certificate infrastructure makes no assumption about the certification infrastructure. The NFC Forum Security Working Group has developed a certificate policy for Certificate Authorities to address this issue.
- Storage. Michael pointed out that the Certificate chain can be stored on the tag or as a URL reference. Certificates are rather large if we use the traditional X.509 format. They are 1 Kbyte or larger, which means they will not fit on low cost Type 1 and 2 tags. To address this, the NFC Forum Security Working Group defined a machine-to-machine (M2M) certificate format that reduces the size down to around 300Kbytes. Michael points out the security issue of obtaining the certificate chain from a URI reference. The signature RTD 2.0 now has a recommended practices section indicating that the user should approve the URI reference or that the app maintain a list of trusted URI references for this purpose.
The NFC Forum Signature RTD 2.0 and associated Certificate Policy address all of these concerns.
A final thought on who will be signing tags. I believe that in the early days this will be limited to larger organizations who want to deploy high volume tags while protecting their brands and offering a seamless user experience. Certificate Authorities already work with organizations and perform a vetting service before issuing signing certificates. At the moment, it’s difficult to imagine use cases for individuals signing tags. Perhaps people more creative than I will come up with them.