Page 13 - Read Online

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

Figure 6. The complete communication trace concerning the GetCardUID and GetFileCounters commands

Figure 7. The complete communication trace concerning the Read_Sig command

Figure 8. NXP public key for the elliptic curve secp224r1

28 bytes long and refers to the r parameter, and the second part is 28 bytes long as well and refers to the s
parameter. The corresponding public key which should be used to verify the digital signature is provided by
[26]
NXP and includes the X and Y coordinates of a point on the curve, plus an additional control byte . The
public key is provided in Figure 8.

The verification procedure was written within the Android application relying on the Bouncy Castle
Cryptographic Library (https://www.bouncycastle.org).

To correctly test the digital signature, the raw bytes returned by the Read_Sig command need to be encoded
in DER; otherwise, they cannot be handled by the java library used to operate the verification.

The verification procedure may be summed up as follows:
1. add the Bouncy Castle security provider;
2. create an empty data structure based on the secp224r1 curve;
3. load the elliptic curve point from the raw bytes containing the NXP public key;
4. generate the elliptic curve public key accordingly;
5. prepare a Signature object with the aforementioned public key;
6. set the message to be verified as the tag UID;
7. encode the tag digital signature with DER encoding;
8. perform the digital signature verification on the DER-encoded signature.
The Android algorithm correctly verifies the digital signature. The originality check based on strong
asymmetric cryptography is thus passed.