Page 14 - Read Online

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

4 DISCUSSION
In this section, we discuss some notable security and privacy patterns that may be addressed using the
NT4H2421Gx tag.

4.1 Communication channel security
The most commonly known security functionalities are based on three-pass mutual authentication and rely
on AES symmetric cryptography. The authentication procedure is initiated by the AuthenticateEV2First or
AuthenticateLRPFirst command.

When the reader and the tag are in the authenticated state, they are able to communicate using each
command included in the command set. Performing a successful authentication proves that the reader
possesses one of the cryptographic keys listed in Table 1. In authenticated mode, each APDU command
is protected by secure messaging. Thus, message payloads are encrypted using the adopted AES key, and a
message authentication code is attached as well. It follows that the communication channel is secured with
respect to sniffing/eavesdropping attacks. Three-pass mutual authentication and secure messaging ensure
confidentiality, integrity and trust. Of course, as they rely on symmetric AES cryptography, they suffer the
[27]
key distribution problem, which is notably relevant within this field . Some strategies should be adopted
to provide the readers with one or more AES keys.

Finally, the SetConfiguration command may be used to enable the leakage-resilient primitive (LRP)
mode (note that it is not possible to revert the tag to simple AES mode). Under LRP mode, three-pass
authentication is started by the AuthenticateLRPFirst command and may rely on originality keys as well.
LRP mode relies on a slightly different AES algorithm which is designed to resist side-channel attacks. An
in-depth discussion on this subject falls out of the scope of this work.

4.2 Privacy implications
The GDPR specifically includes the term online identifiers within the definition of what constitutes personal
data. These objects may include information relating to the device that an individual is using, such as
applications, tools or protocols. To this end, the GDPR Recital 30 shows a shortlist as an example and
explicitly includes RFID tags. To comply with the latest privacy requirements, a good tag should thus be
allowed to hide its UID under specific circumstances, since this UID may be sniffed out by unauthorized
readers, threatening the user’s privacy.

The random ID feature provided by NT4H2421Gx implements this requirement. This setting may be
triggered through the SetConfiguration command, and prevent the UID to be unveiled through the
GetVersion command. Specifically, when the tag is in random ID mode, a 4-byte random ID substitutes the
7-byte UID within the GetVersion response. There are two more options to learn the tag UID: using the
GetCardUID command or reading it out from the NDEF file when UID mirroring is active. The first option
does not represent a privacy breach, as the GetCardUID command is not allowed when the reader is not
authenticated (see Figure 6 for reference). Concerning the latter option, it should be pointed out that UID
mirroring is not mandatory, and moreover, the mirrored UID may be stored as ciphertext within the NDEF
file. While the examined tag mirrors the UID as plaintext (see Figure 5 for reference), a proper change in
the NDEF file settings (through the ChangeFileSettings) would encrypt the UID.

4.3 Chip cloning
The ability of a malicious stakeholder to clone the tag is probably the most dangerous event concerning
NT4H2421Gx. The only countermeasure provided by the tag is represented by the inability of the attacker
to copy the four originality keys which are stored in the ROM. These keys may be used accessing the MF
level to perform a successful authentication, proving the tag originality. Unfortunately, it is evident from