Q&A: What do NFC NDEF Signature records bring?

Here is another question related to NFC, this time about what I understand of NDEF signatures (could be incomplete).

The NFC Forum has recently added the possibility to include a signature record in tags. Adding such a signature can be used to ensure that the content of the tag (say, a URL) has been written by the person who sign it, and not modified afterwards. OK, so what does such a signature really bring in terms of security?

Well, I must admit that I am not really sure. Of course, one of the reasons is that I am yet to see a phone that verifies these signatures; I may also not have all the information. So far, I have read the NDEF spec, and the thesis by Markus Kilås on this topic. So, let’s say that this entry will get modified at some point.

Let’s continue with the URL example, on a very simple, innocuous example: a tag in Nice that contains a URL pointing to explanations about the Ste-Reparate Cathedral. If this tag is signed, then we can expect that a mobile phone would verify the signature before to forward the URL to the browser. However, the mobile phone would also be able to read unsigned tags.

Let’s now consider the two main attacks on this kind of tags:

  • Cloning. The entire record can be read freely, so a signature doesn’t protect at all against cloning. A Nice supporter may be able to put a Ste-Reparate tag on a Notre-Dame de Paris poster.
  • Tag replacement. The signature does not protect against this. If a Paris supporter comes to Nice, removes the Ste-Reparate tag and replaces it with a Notre-Dame de Paris tag, this will work with a browser. Of course, the phone may display a small “Trusted” icon for a recognized signature, but unless all tags rapidly become signed, I doubt that users will notice this icon any time soon.

So, my conclusion is that signatures are likely to be useless for this URL use case, at least before the industry reaches a global agreement on a way to define how signatures should be handled on phones.

Of course, signatures may still be very useful in proprietary applications, which may be used in the industry. In such cases, the signatures will be verified by a specific application. In that case, it would solve part of the tag replacement attacks, since it would mean that a tag from a given company could only be replaced by another tag from the same company (or a clone of it). This means that a good level of tamper-evidence will also be required.

Not really good looking so far, but if I have missed something, I would be really glad to update this to something more positive.

2 Comments

  • Hallo Eric,

    taking a closer look at the NDEF Signature RTD it even gets worse.

    But first the good news ;-) Assuming a phone only trusts signed records, the scenario you mentioned will likely only work with something like a plain URI record (as a standalone record). As soon as you try cloning/tag replacement with a Smart Poster record, you will also clone the textual description associated with the URI. Therefore, the user will immediately see that something is wrong. I.e. if the text mentions some sight in Paris, while the user and the touched tag are in Nice.

    Still, there is several severe problems with the Signature RTD. We have published two papers on this (“Digital Signature Records for the NFC Data Exchange Format”, M. Roland, J. Langer; “Security Vulnerabilities of the NDEF Signature Record Type”, M. Roland, J. Langer, J. Scharinger). Essentially, the weaknesses we identified can be summarized to this:

    For one, the signature record brings a false sense of integrity and authenticity to signed NDEF data. As the signature is only applied to the payload and to certain parts of an NDEF record’s header fields, the signed NDEF messages are prone to data modification. Specifically the “Type Name Field” is not signed and, therefore, the semantics of a record can be changed without voiding the signature. Specific attack scenarios would be record hiding (where you hide a certain record by setting the Type Name Field to “Unknown”) and record composition (where multiple signed NDEF messages are combined to a new NDEF message with new semantics).

    Secondly, the Signature RTD only defines the record and not the environment for signing. There is still no definition on how signed and unsigned records should be handled on devices. As soon as signatures for NDEF are useable, it is certainly necessary to drastically reduce the user experience with unsigned content (e.g. warning screens, etc.) Actually, to protect the user, this should happen even now!

    Moreover, the Signature RTD makes no assumptions on the certification infrastructure. As a result, before the signature record can be used for generic structures like the Smart Poster, it is necessary to define who we trust (i.e. it is necessary to define global certificate authorities) and what a certificate guarantees (i.e. the binding between a certificate and certain record types, certain URIs, …)

    A third problem is storage. We have two possibilites to store signatures and certificates with a signature record. One is refering these fields through URIs/URLs. The other is direct inclusion into the signature record.

    The first method (reference by URL) leads to a severe privacy issue and also opens up for further weaknesses. This is due to the fact that even though we verify a signature, prior to verification we have to download data from an unprotected(!) URL.

    The second method has a disadvantage which was presented by Tony Rosati (RIM) at the NFC Congress this week (“Elliptic Curve Certificates and Signatures for NFC Digital Signature Records”): The signature algorithms specified by the Signature RTD cause both the signatures and the certificate chains to be quite extensive in terms of data. Therefore, signed NDEF data will not fit onto cheap NFC tags (i.e. type 1 & 2 tags).

    So, to summarize this, there is still a lot of work to be done before useful signatures can be implemented.

    Best regards,
    Michael

  • […] was posted a few years ago by Eric Vétillard in this blog […]

Leave a Reply

Your email is never shared.Required fields are marked *