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