What is the purpose of NFC NDEF Signature Records?
The NFC Forum Signature RTD 1.0 was first released as a specification in 2010. Michael Roland pointed to weaknesses and assisted the NFC Forum in fixing them. The NFC Forum Signature RTD 2.0 is now candidate specification and the final specification should 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 the 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. 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). The goal is to try and prevent malicious use of the tag. For example, lets say a coffee shop wants to deploy tags in store for advertising and promotion. There is nothing to prevent a hacker from deploying tags to launch a phishing attack, asking the user to log in. Now the hacker has your credentials. That could seriously degrade the usability of NFC tags.
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. Apples's and Google's third party apps are digitally signed before they can be offered on their respective app stores. It is not perfect but it does helps prevent malicious use.
The ecosystem for NFC Signatures would 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). Lets call them tag authors. These signing certificates chain back to a root certificate that is 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.
What is the user experience on a mobile device for signed tags vs unsigned tags? This is really up to the OS vendors and app developers. At a high level I would improve the user experience: Tap the tag. If the signature verifies then simply perform the action. If there is no signature then ask the user if its ok to proceed. The user should be able to get a little more information such as who is the tag author but most people won't care about that. This assume that tag authors are vetted by issuing CAs. Can hackers get a signing certificate? Yes they can but they probably won't because they could then be tracked and easily revoked. A hacker would almost certainly try to be malicious without signatures and hope that the user would accept the URL, for example.
Back to the questions posed in the blog:
- Cloning. Signatures don't prevent copy or cloning. True I could copy that signed tag and deploy it elsewhere. The question is can a hacker gain from this or do a lot of damage? Aside from inconveniencing the user, probably not.
- Tag replacement. True a tag could be replaced. Practically the tag 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 work group 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 Kbytes or more which means they will not fit on low cost Type 1 an 2 tags. To address this NFC Forum security work group defined a machine to machine (M2M) certificate format that leads to much smaller size 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 does address the shortcomings pointed out in the blog post.
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 and want to protect their brands and offer a seamless user experience. Certificate Authorities already work with organizations and perform a vetting service before issuing signing certificates. At the moment its difficult to see use cases for individuals signing tags. Perhaps people more creative than I will come up with them.