Authentication Of The Smartphone; Authentication Of The Connected Device; Figure 4. Smartphone Authentication Over Nfc - ST ST25DV-I2C User Manual

To avoid this problem, a key is derived from the "Shared Secret" plus a random number (changing every time).
The key obtained is called "AES Session key" and it is used to encrypt all the exchanges between the two
devices. The random number changes every time so the session key is different.
By convention, the random number used for key derivation is chosen by the firmware and shared (not encrypted
with the Android™ or iOS™ phone).
In this demonstration, an AES-256-GCM encryption is used. GCM (Galois counter mode) permits the
authentication of the encrypted messages received (GMAC). Each encrypted message is authenticated so the
receiver detects if the received encrypted message has been modified.
2.4

Authentication of the smartphone

When the communication between the smartphone and the firmware starts, the smartphone sends a "Login" to
the firmware. This "Login" corresponds to the "Login" received by the firmware during the keys exchange phase
when the product has been used for the very first time. The NUCLEO-L476RG board has saved this "Login name"
and the corresponding "Public key" in its static memory.
The firmware challenges the smartphone to check if it really knows the "Private key" corresponding to this "Public
key":
1. The firmware generates a random number, encrypts it with the AES session key and sends it to the
smartphone.
2. If the smartphone owns the "Private key" corresponding to the "Login name", it computes the "AES Session
key" and decrypts the message received.
3. The smartphone sends a SHA256 hash of the random number in order to prove that it has been able to
decrypt the challenge.
4. The firmware also computes the SHA256 hash and then knows if the answer is correct.
This authentication protects the device from someone trying to usurp the "Login" of a valid user. A hacker may
know the "Login" and the associated "Public key" (since they are exchanged not encrypted over NFC) but does
not know the "Private key" so the "Shared Secret" or the "AES Session key" cannot be computed.
2.5

Authentication of the connected device

The smartphone performs an authentication of the firmware. This is done to be sure that the product is genuine
and corresponds to the "Public key" that has been saved in the smartphone during the key exchange phase.
The procedure is the same but in the opposite direction: now the smartphone generates a challenge, encrypts it
with the "AES Session key" and sends it to the firmware.
The firmware decrypts it and sends a SHA256 hash to prove that the decryption is correct.
UM2684 - Rev 2
Figure 4. Smartphone authentication over NFC
Decrypt
Smartphone
Authentication of the smartphone
Encrypt
Firmware
UM2684
page 7/27