Page 12 - Read Online

Calderoni et al. J Surveill Secur Saf 2020;1:106-18 I http://dx.doi.org/10.20517/jsss.2019.01 Page 113

Figure 5. The complete communication trace concerning the commands performed against the NDEF file. EF: elementary file; SDM:
secure dynamic messaging; UID: unique tag identifier

The next step consists of the inspection of the NDEF file. After the file selection, the application checks
the file settings through the GetFileSettings command and, subsequently, reads the full file content using
the standard ISOReadBinary command. The complete communication trace is provided in Figure 5. The
information returned by the GetFileSettings command shows that, differently from the CC file, SDM is
enabled for this file. Specifically, the file metadata shows that two attributes are supposed to be mirrored
inside the NDEF file: the tag UID, stored at offset 14:00:00 (i.e., 20 following the decimal notation) and the
SDM read counter, stored at offset 23:00:00 (i.e., 35 following the decimal notation). Both of them are stored
in ASCII encoding. SDM access rights are set to FF:EF; this means that the UID and the SDMReadCtr are
stored as plaintext within the NDEF file. Moreover, no run time encryption is applied to these data when
the NDEF file is read through the ISOReadBinary or ReadData commands. Again, the GetFileCounters
command is disabled. Moreover, metadata indicate that the overall dimension of the NDEF file is 256 bytes
(00:01:00), and the access conditions are set to E0:EE. This access policy reflects the one included in the CC
file for the NDEF file, as it states that the file may be updated and read with no restrictions (E). This setting
suggests that the default file access rights were not changed after chip personalization.

Concerning the file content, the file effectively occupies 39 bytes (00:27). The file stores a single NDEF
record having header D1. Hence, this record is a short record of a well-known type. The specific type is a
URI (55) and the payload length is 35 (23). The first byte of the URI is 02, which is an abbreviation for
“https://www.”. The remaining bytes contain the rest of the URI and the mirrored UID and SDMReadCtr,
stored in ASCII encoding, as depicted in Figure 5.

To check the correctness of the APDU implementation in relation to the tag access logic, we also tested
two more commands: GetCardUID and GetFileCounters. Both commands correctly return an error code.
In the first case, this is due to the fact that the command was executed when the tag and the reader were
not under authenticated mode. The error returned by the latter is instead related to the SDM access rights
reported in Figure 5: as the SDMCtrRet is set to F, the GetFileCounters command is disabled. The error
codes are provided in Figure 6.

Finally, we run the Read_Sig command to verify the digital signature and to prove the compliance of this
tag with respect to chip forging. The related communication trace is listed in Figure 7.

[25]
According to NXP, the digital signature relies on elliptic curve cryptography and was produced for the
tag UID using an ECDSA algorithm with the elliptic curve secp224r1. As the name suggests, this curve
implies keys of 224 bits (i.e., 28 bytes). Thus, the digital signature is composed of two parts: the first part is