# NTAG 424 - how to diversify the key?

I am currently working with the NXP NTAG 424 chips, which feature AES-128 encryption.

In the end, one will be able to read an NDEF message; for example, with a smartphone, the backend server will then verify whether the message was delivered.

However, NXP often implies that the UID should not be communicated in the clear. They even have a setting that disables the communication of the UID in the clear (it is then replaced with a fake UID). NXP also states the following in their application note: " Therefore verification side does not have immediate info on UID, which is usually used as input for key derivation function. In this case, KSDMMetaRead key shall not be UID diversified and high attention on secure storage on the system level of this key is required. "

Why is the open communication of the UID such a problem? Can the UID be used to crack the key? How should one diversify the key instead?

Why is the clear communication of the UID such a problem?

Problem is that most RFID tags can be read at a distance, without the holder knowing. Since the UID is readable, and if it is fixed, that can help track the holder. That's why there is a trend¹ in modern RFID tags towards random UIDs (RID), and making it necessary for the tag reader to hold a key in order to be able to read any tag-identifying information. As explained in the question's quote, that key must be non-diversified, except when there is another tag identifier available thru a different channel².

Can the UID be used to crack the key?

No. The tag's UID is an arbitrary public number: fixed at manufacturing (often sequential or random), or drawn randomly³ at each power-up or reset of the tag (see NFC's AN10927). In a system with non-diversified key³, the UID has no relation to the key. In a system with diversified tag key $$K_D$$ derived from a master key $$K$$ (not in the tag), the UID has no relation with $$K$$. If the tag key is diversified per the UID, it holds the relation $$K_D=\operatorname{KDF}(K,\text{UID})$$. However, not knowing $$K$$, knowing the UID does not allow finding the tag key $$K_D$$, for proper $$\operatorname{KDF}$$. And even if $$K_D$$ is somehow extracted from some tag(s), then for proper $$\operatorname{KDF}$$ that does not allow finding the master key $$K$$ (which would allow to find $$K_D$$ for other tags).

How should one diversify the key instead?

In some tags, when the tag-identifying information (other than UID) has been read using the first non-diversified key, it can then be used to diversify another key, bringing back the security of diversified tag keys. I have no idea about if this is possible on this particular tag.

As already explained, in some application it could be possible to diversify the key using a different information read thru an other mean, e.g. optical.

¹ That's currently marginal. In France, practice is that legitimate readers are required not to keep identifying information beyond the requirement of the application, and identifying information kept by unrelated applications should be protected against reconciliation (for example, a serial number read from an RFID tag could be be encrypted by an application-unique key before being entered in a database).

² In many modern passports/MRTDs that can be read per ISO/IEC 14443, the design is such that there is no identifying information (personal or not) readable directly by that channel, including a mere serial number/(U)UID/PUPI. Reading such information only becomes possible after reading data on the optically readable strip inside the passport, which (after a public transformation) acts as a key to unlock reading more thru the RF channel. I heard that one of the design rationale was to defeat a device that performs a nefarious action (explosion, toxic spray…) when a specific person approaches. If someone has a reference for the true design rationale, please leave comment.

³ In this case, the (U)UID has no cryptographic role and is only used for addressing purposes when there are several tags in the operating field of a reader.

• @kelalaka: added a link. Be sure to re-read the first paragraph, it changed significantly. – fgrieu Mar 14 at 19:25
• Thanks ${}{}{}$ – kelalaka Mar 14 at 19:27