ST ST25DV-I2C User manual

Introduction
This document 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 or iPhone (7 and
up, with iOS13 or later version).
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 speeds 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:
• STSW-ST25DV005 firmware
• STSW-ST25003 Android™ application
• STSW-ST25IOS003 iOS™ application
ST25DV-I2C cryptographic demonstration
UM2684
User manual
UM2684 - Rev 2 - November 2020
For further information contact your local STMicroelectronics sales office.
www.st.com

1General information
The application described in this document runs on the 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 NUCLEO-L476RG board plus a X-NUCLEO-NFC04A1 shield,
featuring a ST25DV-I2C tag connected to a STM32L476 device through the I2C bus. This kit represents an IOT
sensor device, which is controlled by an Android™ smartphone or by an iPhone (with iOS13 or later version)
through the NFC.
Figure 1. Connection scheme of the "ST25DV-I2C Crypto Demo"
MS53521V1
ST25DV-I2C STM32
I2C
X-NUCLEO-NFC04A1 NUCLEO-L476RG
Secure transfer
channel
NFC
When a communication between the device and a smartphone starts, a mutual authentication takes place. It
ensures that:
• The user of the smartphone has a permission to communicate with the device
• The device is not counterfeited
Once the mutual authentication has taken place, all the communications between the microcontroller and the
smartphone are encrypted, so the user can configure the product or retrieve data securely. Anyone who spies on
the data exchanged on the NFC is unable 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 so the device refuses requests 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 AN5453 "ST25DV-I2C crypto demonstration".
UM2684
General information
UM2684 - Rev 2 page 2/27

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:
• NUCLEO-L476RG board plus X-NUCLEO-NFC04A1 shield
• An iPhone (with iOS™ 13 or later) or an Android™ smartphone with at least the version 6.0 (Android™
Marshmallow)
1.4 Installation
This demonstration requires to download the firmware (STSW-ST25DV005) for the NUCLEO-L476RG board and
the Android™ executable (APK, STSW-ST25003) the iOS™ application (STSW-ST25IOS003) to be used on a
smartphone.
1.4.1 NUCLEO-L476RG and X-NUCLEO-NFC04A1 setup
The "ST25DV-I2C Crypto Demo" binary (“SBSFU_UserApp.bin”, available in STSW-ST25DV005 package) must
be uploaded on the NUCLEO-L476RG board.
To program the NUCLEO-L476RG board, go through the following steps:
1. Install the ST-LINK USB driver, available on www.st.com.
2. Connect the NUCLEO-L476RG board to a PC with the USB-mini port.
3. The NUCLEO-L476RG board icon must appear in the PC directory.
4. Drag-and-drop the "SBSFU_UserApp.bin" binary to the NUCLEO-L476RG board icon.
5. Restart the NUCLEO-L476RG board by pressing the reset (black button).
1.4.2 Android™ APK application installation
The "ST25DV-I2C Crypto Demo" Android application is available at Google Play™ store.
The STSW-ST25DV005 package contains two firmwares in the UserApp Binary directory (UserApp.sfb and
UserApp_NewPicture.sfb) to use for the secure firmware upgrade demonstration. These files have to be
downloaded on the Android™ smartphone.
1.4.3 iOS™ application installation
This application is not available on Apple® store so it must be installed manually.
The user can download the application by the OTA (over the air) programming, a method for wireless distribution
of an application and/or its updates to end-users.
On approval, application is automatically installed or it is updated if it is already installed.
Perform the following steps to install the application:
1. Use Safari® browser on your iPhone
2. Enter URL: http://myst25.com/iOSST25DVCryptoDemo/
3. Click on the blue icon on the right (see Figure 2)
4. Check iOS™ installation on your iPhone.
UM2684
Acronyms
UM2684 - Rev 2 page 3/27

Figure 2. Blue icon view
When user opens an enterprise application (OTA installed), user is identified by one 'Untrusted Enterprise
Developer' notification. In such case, user needs the 'Trust Developer' certificate allowing application to be
installed.
This can be done by tracing the menu as follows: Settings→General→Device Management→Enterprise
Apps→Trust Developer.
1.4.4 How to set the "Authorized User"
As described in Section 2.1 Public key exchange, the first smartphone establishing a secure session with the
firmware is considered as the owner of the device. This means that only this smartphone is able to establish a
secure session from now on, and all connections from other smartphone are rejected.
When no "Authorized User" has been set yet, the X-NUCLEO-NFC04A1 LED1 (green) is OFF.
After the start of the demonstration and set up of a secure channel (as described in section Section 3.2.1 Secure
transfer channel setup), the STM32L476RG microcontroller saves the connection data (smartphone "Login" and
"Public key") and only accepts connections with the same smartphone credentials.
Note: As these data are saved in the Flash memory of the STM32, the firmware restores them after a reset.
Once an "Authorized User" is set, the X-NUCLEO-NFC04A1 LED1 (green) is switched ON.
Any other user / smartphone trying to connect to this NUCLEO-L476RG board is rejected, and the X-NUCLEO-
NFC04A1 LED3 (yellow) is switched ON..
It is possible to set a new "Authorized User" by pushing the user button (blue) of the NUCLEO-L476RG board
(any previously stored "Authorized User" is erased by the firmware).
UM2684
Installation
UM2684 - Rev 2 page 4/27

1.5 License scheme
The Android™ and iOS™ application and the associated firmware are provided under the SLA0052 license
agreement, available on www.st.com.
The software components provided in this package come with different license schemes, as shown in Table 2.
Table 2. ST25DV-I2C cryptographic firmware - License scheme
Component Copyright License
Project application
STMicroelectronics
ST proprietary
LibNDEF ST proprietary
Menu demo ST proprietary
Board support package (BSP) ST proprietary
LibJPEG ST Liberty SW License Agreement V2
HAL STM32L4 Open source BSD
STM32_Cryptographic Image V2 (object release only)
STM32_Secure_Engine Ultimate Liberty (source and object
release)
Cortex®-M CMSIS Arm®Open source BSD
UM2684
License scheme
UM2684 - Rev 2 page 5/27

2Security processes
This section describes the security processes used to perform a mutual authentication and to 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 smartphone sends its "Login" and ECC "Public key".
• The firmware sends its ECC "Public key".
If the firmware has no registered "Login" yet, it saves the "Login" and the "Public key" in the static memory and
considers this user to be the "Authorized User" of the product. It means that the firmware only accepts requests
from this smartphone.
When the smartphone receives the firmware "Public key", it checks that this key is signed by a manufacturer key.
This verification ensures that the product (represented by the NUCLEO-L476RG and X-CUBE-NFC04A1 kit here)
is not counterfeited.
2.2 Definition of a "Shared Secret"
To establish an encrypted channel, the smartphone and the firmware 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 (ECDH) is a “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 to encrypt all the communications of this session.
Both two communicating devices must have an ECC key pair. They exchange their public keys (the private key
remains secret and is not shared). Each device uses ECDH scheme to combine its own private key with the
public key of the peer device. Thanks to ECC, these two operations bring to the exact same result, which is called
“Shared Secret” (see Figure 3).
Someone who has spied the communication has seen the public keys exchanged but this is not sufficient to find
the "Shared Secret".
Figure 3. Elliptic curve Diffie-Hellman over NFC
Discovery
public key
Pub
Smartphone
Smartphone
public key
Pub
Firmware
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 smartphone and firmware 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".
UM2684
Security processes
UM2684 - Rev 2 page 6/27

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.
Figure 4. Smartphone authentication over NFC
FirmwareSmartphone
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 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
Authentication of the smartphone
UM2684 - Rev 2 page 7/27

Figure 5. Firmware authentication over NFC
FirmwareSmartphone
Encrypt Decrypt
This authentication protects from counterfeited products containing a valid "Public key" taken on a valid product.
However it does not contain the "Secret Key" that is stored in the product and that is not readable. The
counterfeited product is not able to compute the "Shared Secret" nor the "AES Session key", so it fails this
authentication phase.
2.6 Encrypted data transfer
Once the mutual authentication has been run, all the imminent 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 (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.
UM2684
Encrypted data transfer
UM2684 - Rev 2 page 8/27

3"ST25DV-I2C Crypto Demo" application screens
3.1 Home screen
User manually launches the application “ST25DV-I2C-Crypto Demo” or simply taps the ST25DV-I2C NFC tag,
Android™ automatically launches the “ST25DV-I2C-Crypto Demo” application.
Figure 6. "ST25DV-I2C Crypto Demo" - Android™ 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 time this application starts.
On iOS™ application, user must launch the application manually since NFC is only enabled on demand by user
application.
When the iOS™ application starts, a home screen is displayed and a tab bar appears at the bottom of the
application screen (see Figure 7). It provides the ability to quickly switch between different sections of an
application.
Push on section "Crypto Demo" to start demonstration.
UM2684
"ST25DV-I2C Crypto Demo" application screens
UM2684 - Rev 2 page 9/27

Figure 7. "ST25DV-I2C Crypto Demo" - iOS™ home screen
UM2684
Home screen
UM2684 - Rev 2 page 10/27