ST ST25DV-I2C User manual

Introduction
This user manual shows how to run the "ST25DV-I2C Crypto Demo", using the ST25DV-I2C fast transfer mode (FTM) to
establish a secure transfer channel (STC) over NFC between an STM32 microcontroller and an Android™ smartphone.
The ST25DV-I2C is a dynamic NFC tag IC able to communicate with NFC readers and smartphones, and also with a
microcontroller through an I2C interface. The FTM feature allows to speed up the communication between these two interfaces.
This demonstration establishes an STC by using cryptography to perform a mutual authentication, and to encrypt the
communications over NFC. This STC is used during the demonstration to securely:
• Send and retrieve data
• Set the device settings
• Upload new firmware
Only the granted user / smartphone is able to communicate with the STM32 device to perform these operations.
The STC over NFC has applications in different sectors (such as industrial, home appliance and consumer) where the control of
a device is restricted to authorized users, and when the personal data must be protected.
The following packages are available on www.st.com for this demonstration:
• STSW-ST25DV003 firmware
• STSW-ST25003 Android™ application
ST25DV-I2C crypto demonstration
UM2575
User manual
UM2575 - Rev 1 - May 2019
For further information contact your local STMicroelectronics sales office.
www.st.com

1General information
This document is applied to STM32L476 Arm®-based devices.
Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
1.1 Purpose and scope
The "ST25DV-I2C Crypto Demo" runs on the ST25DV-I2C-DISCO kit, featuring a ST25DV-I2C tag connected to a
STM32L476 device through the I2C bus. The ST25DV-I2C-DISCO kit represents an IOT sensor device, which is
controlled by an Android™ smartphone through the NFC.
Figure 1. Connection scheme with ST25DV-I2C-DISCO
NFC
Secure transfer
channel
ST25DV-I2C-DISCO
I2C
ST25DV-I2C STM32 device
When a communication between the device and a smartphone is started, a mutual authentication is done. It
ensures that:
• The user of the smartphone has a permission to communicate with this device
• The device is not counterfeited
Once the mutual authentication is done, all the communications between the microcontroller and the Android™
phone are encrypted, so the user can configure the product or retrieve data securely. Anyone who spies on the
data exchanged on the NFC is not able to interpret them. The key used to encrypt the communication changes
each time a mutual authentication is done, this action prevents someone from recording the encrypted content
and replaying it.
In this demonstration, the first user of the device becomes the administrator of the product so the device refuses
any request from other users.
More details on the cryptographic processing used in the demonstration are provided in Section 2 Security
processes.
Additional details on the implementation are provided in the AN5323 ST25DV-I2C crypto demonstration.
UM2575
General information
UM2575 - Rev 1 page 2/23

1.2 Acronyms
Table 1. Acronyms
Acronyms Meaning
NFC Near field communication
AES Advanced encryption standard
ECC Elliptic curve cryptography
FTM Fast transfer mode
STC Secure transfer channel
GCM Galois/counter mode
GMAC Galois message authentication code
1.3 Hardware equipment
The following hardware is needed for this demonstration:
• A ST25DV-I2C-DISCO kit
• An Android smartphone with at least the version 6.0 (Android Marshmallow)
1.4 Installation
This demonstration requires to download the firmware (STSW-ST25DV003 on www.st.com) for the ST25DV-I2C-
DISCO board and the Android executable (APK, STSW-ST25003 on www.st.com) to use on the Android phone.
1.4.1 ST25DV-I2C-DISCO kit setup
The "ST25DV-I2C Crypto Demo" application requires a ST25DV-I2C-DISCO kit composed of two boards:
• The ST25DV-I2C-DISCO motherboard
• The ST25DV-I2C antenna daughter board
Warning: the ST25 discovery motherboard must be based on a STM32L476 device, which is labelled MB1396
(and not MB1283 which is based on a STM32F4).
The ST25DV-I2C-DISCO motherboard is programmed with the regular ST25DV-I2C demonstration, thus the
board must be flashed with the "ST25DV-I2C Crypto Demo" binary (“ST25DV-I2C_CryptoDemo_MB1396.bin”,
available in STSW-ST25DV003 package).
To program the ST25DV-I2C-DISCO motherboard, perform following instructions:
1. Install the ST-LINK USB driver, available on www.st.com.
2. Connect the ST25DV-I2C-DISCO motherboard to a PC with the USB-mini port.
3. The ST25DV-I2C-DISCO motherboard icon must appear in the PC directory.
4. Drag-and-drop the "ST25DV-I2C Crypto Demo" binary to the ST25DV-I2C-DISCO motherboard icon.
5. Restart the ST25DV-I2C-DISCO motherboard by pressing the reset button (black).
1.4.2 Android APK installation
This application is not available on Google Play™ store so it must be installed manually. By default, Android
prevents the installation of programs not coming from Google Play™ so an action is needed to allow the
installation of this application:
• Navigate to setting → Security.
• Check the option "Unknown sources".
• Tap “OK” on the prompt message.
• Select "Trust".
Note: Depending of the Android version and the phone model, the wording may vary a little bit.
Then connect the Android phone to a PC with an USB cable and copy the APK to the phone’s internal memory.
UM2575
Acronyms
UM2575 - Rev 1 page 3/23

With a file explorer, browse the memory of the phone and go to the folder where the APK was copied. Click on the
file to install it.
Note: If there is no file explorer, the program "File commander" is available for free on Google Play™.
The STSW-ST25DV003 package contains a second firmware binary file (“ST25DV-
I2C_Demo_FwUpgrd_MB1396.bin”) intended to be used for the secure firmware upgrade demonstration. This file
has to be downloaded on the Android smartphone.
1.4.3 How to set the "Authorized User"
As described in Section 2.1 Public key exchange, the first Android smartphone establishing a secure session
with the ST25DV-I2C-DISCO board is considered being the owner of the device. This means that only this
smartphone is able to establish a secure session from now on, and any connection from other smartphone is
rejected.
When no "Authorized User" has been set yet, the “key exchange” box is unchecked and a “no user” message is
displayed on the ST25DV-I2C-DISCO screen.
Figure 2. ST25DV-I2C-DISCO screen - no user
Then by starting the demonstration and establishing a secure channel (as described in section Section
3.2.1 Secure transfer channel setup), the ST25DV-I2C-DISCO saves the connection data (smartphone "Login"
and "Public key") and only accepts the forecoming connections with same smartphone credentials.
Note: As these data are saved in the flash memory of the STM32, the ST25DV-I2C-DISCO firmware restore them after
a reset.
Once an "Authorized User" is set, the login (the name of the smartphone) is displayed, and the “key exchange”
box is now checked.
Figure 3. ST25DV-I2C-DISCO screen - registered user
Any other user / smartphone trying to connect to this ST25DV-I2C-DISCO board is rejected.
UM2575
Installation
UM2575 - Rev 1 page 4/23

Figure 4. ST25DV-I2C-DISCO screen - denied access
It is possible to set a new "Authorized User" by pushing the user button (blue) of the ST25DV-I2C-DISCO
motherboard (any previously stored "Authorized User" is erased by the firmware).
1.5 Disclaimer
The Android application and the associated firmware are provided under the SLA0052 license agreement,
available on www.st.com
UM2575
Disclaimer
UM2575 - Rev 1 page 5/23

2Security processes
This section describes the security processes used to perform a mutual authentication and establish a secure
transfer channel (SFC) where all the communications are encrypted.
2.1 Public key exchange
The public keys exchange is done in two steps:
• The Android phone sends its "Login" and ECC "Public key".
• The ST25DV-I2C-DISCO board sends its ECC "Public key".
If the ST25DV-I2C-DISCO kit has never been used before, it saves the "Login" and the "Public key" in static
memory and consider this user to be the administrator "Authorized User" of the product. It means that the
ST25DV-I2C-DISCO kit only accepts requests from this smartphone user.
When the Android phone receives the ST25DV-I2C-DISCO "Public key", it checks that this key is signed by a
manufacturer key. This verification ensures that the product (represented by the ST25DV-I2C-DISCO kit here) is
not counterfeited.
2.2 Definition of a "Shared Secret"
To establish an encrypted channel, the Android phone and the ST25DV-I2C-DISCO kit have to agree on a
symmetric key used to encrypt all the communications between the two devices. This key cannot be exchanged
over NFC because someone may spy all the data exchanged and get the key.
Elliptic curve Diffie–Hellman (aka “ECDH”) is a well known “key agreement protocol” used to establish a “Shared
Secret” over an insecure channel. Section 2.3 Derivation of a public key describes how this "Shared Secret" is
used to define a symmetric key used to encrypt all the communications of this session.
The two communicating devices must both have an ECC key pair. They exchange their public keys (the private
key remain secret and is not shared). Each device use ECDH scheme to combine its own private key with the
public key of the peer device. Thanks to ECC, these two operations leads to the exact same result, that is called
“Shared Secret” (see Figure 5).
Someone who has spied the communication has seen the public keys exchanged but this is not sufficient to find
the "Shared Secret".
Figure 5. Elliptic curve Diffie-Hellman over NFC
Discovery
public key
Pub
Android phone
Android
public key
Pub
ST25DV-I2C-DISCO
The two devices have been able to define a "Shared Secret" that nobody else can find. Only the ones knowing
the private keys can get the "Shared Secret".
2.3 Derivation of a public key
The "Shared Secret" can be used to encrypt the communications between the two devices but it has a weakness:
the ECC key pairs of the Android and ST25DV-I2C-DISCO devices do not change, so the "Shared Secret" is
always the same. Someone can record the data exchanged over NFC and re-execute them. This is called "replay
attack".
UM2575
Security processes
UM2575 - Rev 1 page 6/23

To avoid this problem, a key is derived from the "Shared Secret" plus a random number (changing every times).
The key obtained is called “AES Session key” and is used to encrypt all the exchanges between the two devices.
The random number changes every times so the session key is different every times.
By convention, the random number used for key derivation is chosen by the ST25DV-I2C-DISCO and shared not
encrypted with the Android phone.
In this demonstration, an AES-256-GCM encryption is used. GCM (Galois counter mode) allows 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 Android phone
When the communication between the Android phone and the ST25DV-I2C-DISCO starts, the Android phone
sends a “Login” to the ST25DV-I2C-DISCO. This "Login" corresponds to the "Login" received by the ST25DV-I2C-
DISCO during the keys exchange phase when the product has been used for the very first time. The ST25DV-
I2C-DISCO board has saved this "Login name" and the corresponding "Public key" in its static memory.
The ST25DV-I2C-DISCO sends a challenge to the Android phone to check if it really knows the "Private key"
corresponding to this "Public key":
1. The ST25DV-I2C-DISCO generates a random number, encrypts it with the AES session key and sends it to
the Android phone.
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 ST25DV-I2C-DISCO also computes the SHA256 hash and then knows if the answer is correct.
Figure 6. Android phone authentication over NFC
ST25DV-I2C-DISCOAndroid phone
EncryptDecrypt
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 Android phone performs an authentication of the ST25DV-I2C-DISCO. This is done to be sure that the board
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 Android phone generates a challenge, encrypts
it with the "AES Session key" and sends it to the ST25DV-I2C-DISCO.
UM2575
Authentication of the Android phone
UM2575 - Rev 1 page 7/23

The ST25DV-I2C-DISCO decrypts it and sends a SHA256 hash to prove that the decryption is correct.
Figure 7. ST25DV-I2C-DISCO authentication over NFC
ST25DV-I2C-DISCOAndroid phone
Encrypt Decrypt
This authentication protects from counterfeited products: a counterfeited product can contain a valid "Public key"
taken on a valid product. However it does not contain the "Secret Key" that is stored in the product and which is
not readable. So here also, the counterfeited products is not able to compute the "Shared Secret" nor the "AES
Session key". So it fails to pass this authentication phase.
2.6 Encrypted data transfer
Once the mutual authentication has been run, all the forecoming communications over NFC are encrypted using
the current AES session key, which means:
• Someone spying the NFC communication is not able to decrypt the transmitted data (because the current
"AES Session key" is unknown).
• A message not encrypted with the current "AES Session key" is rejected
• A valid message (encrypted with the current "AES Session key") maliciously modified is rejected too (thanks
to the message authentication).
The AES encryption is performed by using the GCM.
This encryption method requires to transmit additional metadata along with the encrypted data:
1. An initialization vector (12 bytes) required to initialize the decryption process. This initialisation vector
changes for every new encrypted message.
2. A GMAC of 16 bytes used to ensure the message integrity and source.
Note: No block-padding is required by this encryption method.
UM2575
Encrypted data transfer
UM2575 - Rev 1 page 8/23

3Android and ST25DV-I2C-DISCO screens
3.1 Home screen
Manually launch the application “ST25DV-I2C-Crypto Demo” or simply tap the ST25DV-I2C NFC tag, Android
automatically launches the “ST25DV-I2C-Crypto Demo” application, if it is installed.
Figure 8. "ST25DV-I2C Crypto Demo" - home screen
When the application starts, it initializes the Android KeyStore and some cryptography elements.
By default, the “User authentication” is disabled but this can be changed in the "Settings" menu. If enabled, the
user has to enter its pin-code or fingerprint every times this application is started.
UM2575
Android and ST25DV-I2C-DISCO screens
UM2575 - Rev 1 page 9/23

3.2 "ST25DV-I2C Crypto Demo" application screen
This section describes how the "ST25DV-I2C Crypto Demo" application works.
3.2.1 Secure transfer channel setup
When tapping the ST25DV-I2C tag, the "ST25DV-I2C Crypto Demo" application automatically executes all the
steps described from Section 2.1 Public key exchange to Section 2.5 Authentication of the connected device to
setup a secure transfer channel.
Figure 9. "ST25DV-I2C-Crypto Demo" - secure transfer channel setup
On the ST25DV-I2C-DISCO board, similar information is displayed to show what is the current security status,
and which user is logged.
Figure 10. ST25DV-I2C-DISCO screen when no user has been registered
UM2575
"ST25DV-I2C Crypto Demo" application screen
UM2575 - Rev 1 page 10/23