I've been burying my nose in the AN12196.pdf for a few days now and slowly getting a hang of it.
What I cannot clearly understand is the idea behind the SDMENCFileData.
In section 4.4.3 SDMENCFileData mirror, if I understand it correctly, it's saying that you can take any 32-character plaintext part of your URL, and it gets encrypted when tapping, am I right?
What would be the use-case of this? If I had some secret thing, that's shorter than 32-chars, I have to pad it before encrypting, and if I had something longer I wouldn't be able to use it. I wanted to know what other's use this for.
The Secure Dynamic Messaging (SDM) or Secure Unique NFC feature is an amazing one available on NTAG 424 DNA and Mifare DESFire EV3 tags.
If enabled it allows to work with NFC card readers that can read a standardized NDEF message without any dedicated app. The card reader should forward the "Link/URI" NDEF message to a browser that connects to a backend server. This backend server gets the data transferred within the link.
For an example I'm storing this link on a NTAG 424 DNA NDEF file (that is a Standard file):
https://sdm.nfcdeveloper.com/tag?picc_data=00000000000000000000000000000000&enc=0102030405060708A1A2A3A4A5A6A7A8&cmac=00000000000000
Without enabled SDM/SUN feature this link is calling the backend server in Plain communication (without any encryption).
Please note: the data you are asking for is the one after the "&enc=" trailer:
0102030405060708A1A2A3A4A5A6A7A8
where only the first half of them will be encrypted later, the second half is a placeholder for the complete encrypted data as they are encoded in hex encoding.
What does happen when the SDM/SUN feature gets enabled ? This is same data but in encrypted form:
https://sdm.nfcdeveloper.com/tag?picc_data=B825283ABE4DDCE04C86DC9D078F927D&enc=AD5B1FE8F6CBA426B3CF522CAC77A695&cmac=5F5FB0752DD549F4
The data behind the "&enc=" trailer is now:
AD5B1FE8F6CBA426B3CF522CAC77A695
This is the encrypted first half of the plaintext shown before.
Now run a live test with a sample backend server. Below you find the same url as clickable link that will bring you to a backend server that is. been able to decrypt the data:
The result is as follows:
Secure Dynamic Messaging Backend Server Demo
Cryptographic signature validated.
Encryption mode: AES
PICC Data Tag: c7
NFC TAG UID: 04514032501490
Read counter: 4
File data (hex): 30313032303330343035303630373038
File data (UTF-8): 0102030405060708
The use case is simple - maybe you like to transport additional data beneath the UID a Read Counter to the backend server (e.g. a birth date for age verification, a promotion code or "vip status").
If your data is shorter than 16 byte just a (random ?) padding, if it is longer you need an additional 32 bytes long spaceholder (in total multiples of 32).