2
Security 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.
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
Someone who has spied the communication has seen the public keys exchanged but this is not sufficient to find
the "Shared Secret".
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 - Rev 2
Section 2.3 Derivation of a public key
Figure
3).
Figure 3.
Elliptic curve Diffie-Hellman over NFC
Discovery
public key
Smartphone
Pub
describes how this "Shared Secret" is used to define a
Smartphone
public key
Firmware
Pub
UM2684
Security processes
page 6/27
Need help?
Do you have a question about the ST25DV-I2C and is the answer not in the manual?
Questions and answers