NXP Semiconductors EdgeLock A5000 Installation and operating instructions

AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-
counterfeit protection using device-to-device authentication
Rev. 1.0 — 28 March 2022 Application note
Document information
Information Content
Keywords A5000, mutual authentication, proof of possession
Abstract This document describes how to leverage A5000 for device-to-device
authentication

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Revision history
Revision
number
Date Description
1.0 2022-03-28 Initial version
Revision history
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
2 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
1 Device-to-device authentication
The IoT environment increases the exposure of high value components to new
security threats. OEM manufacturers need to protect themselves from non-authorized
components, discriminate original devices from fake copies, avoid device misuse and
over usage, and make sure customers purchase original equipment.
If we do not take security into account, attackers may try to compromise our devices by:
•Exploiting software bugs
•Extracting secret device keys
•Inserting counterfeit devices
•Abusing untrusted connections
•Disclosing confidential data, etc
These security threats are significantly serious for IoT systems dealing with real time
processes, even risking safety in case of medical devices, industrial processes, energy
grids or traffic lights automation, among others.
For illustrative purposes, let's assume an OEM which manufactures a certain type
of machinery controlled by a centralized control unit as shown in Figure 1. As these
machines perform some critical tasks in the manufacturing plant:
•The control unit authenticates the machine that is attempting to connect to it.
•The machines also authenticate the control unit that will manage it.
Therefore, only authenticated machines and control units will be used in the supply
chain. This mechanism ensures protection against rogue devices that might damage
production, degrading security levels or risking employee safety.
Figure 1. Device-to-device authentication scenario
The exchange of digital certificates is the basis of the authentication process. The two
parties each check that the certificate is valid and was issued by a trusted authority,
known as Certificate Authority. Section 2 describes how certificates are verified using a
certificate chain of trust.
Digital certificates, as public information, are susceptible to be intercepted and be
misused. For this reason, a proof of possession of the certificate private key is an
essential requirement to validate the certificate source. Section 3 describes how to
leverage A5000 to conduct the proof of possession.
The private key must be kept secret and protected. The leakage of any private key
compromises the identity verification and the overall system security. The A5000
provides a trust anchor at the silicon level, providing a tamper-resistant platform capable
of securely storing keys and credentials needed for offline authentication.
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
3 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
2 Certificate chain of trust
IoT requires each device to possess a unique identity. For certificate-based
authentication scheme, the identity is made of:
•Device certificate
•Device key pair
The digital certificate binds an identity with a public key. Digital certificates are verified
using a chain of trust. The certificate chain of trust is a structure of certificates that enable
the receiver to verity that the sender and all CA's are trustworthy. The trust anchor for the
digital certificate is the root CA.
Certificates are issued and signed by certificates that reside higher in the certificate
hierarchy, so the validity and trustworthiness of a given certificate is determined by the
corresponding validity of the certificate that signed it. The certificate chain of trust results
in a root CA signing an intermediate CA that in turn signs a leaf certificate as shown in
Figure 2
Verify Signature
Sign
Owner‘s name
Leaf
certificate
Owner‘s public key
Issuer‘s (CA) name
Issuer‘s (CA) signature
Owner‘s private key
Intermediate
certificate
Issuer‘s name
Issuer‘s public key
Root CA‘s name
Root CA signature
Issuer‘s private key
Root CA‘s name
Root
certificate
Root CA‘s public key
Root CA‘s signature
Root CA private key
Sign
Verify Signature
Reference
Reference
Self-Sign
Figure 2. Certificate chain of trust
IoT devices manufactured by the OEM should be equipped with a unique key pair and a
digital certificate signed by the OEM's CA certificate. The OEM's CA certificate is used to
sign all the certificates of the devices manufactured by the OEM. Precisely, this signature
provides the means to verify the validity of device certificates in the field (Figure 3).
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
4 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 3. Certificate hierarchy
Before a machine or control unit manufactured by the OEM goes to the operation phase,
they must possess the CA certificate, an individual certificate and a key pair securely
stored as shown in Figure 4.
Figure 4. Machine and control unit credentials
Secure silicon chips like A5000 are capable of internally protecting private keys in IoT
devices. The CA certificate could optionally be stored outside the A5000. Section 5
outlines the A5000 trust provisioning models available.
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
5 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
3 Mutual authentication flow
The authentication flow consists of a mutual authentication procedure. First, the machine
will authenticate the control unit that it will be connected to. After that, the control unit will
authenticate the machine that attempts to connect.
3.1 Control unit authentication
The authentication of the control unit consists of two steps: the certificate validation and
the private key proof of possession as shown in Figure 5.
Certificate validation:
The first step is the verification of the control unit digital certificate.
1. The control unit sends its device certificate together with its hierarchy of CA
certificates.
2. The machine validates that the provided certificate chain of trust is valid by verifying
the signatures of all the certificates in the chain up to the root CA
If the control unit certificate is valid, it means that the public key included in it can be
trusted.
Proof of possession:
The second step is the proof of possession. This procedure is needed to make sure that
the certificate we verified belongs to the control unit. This proof of possession mechanism
ensures that the uploader of the certificate also knows the associated private key. For
that,
1. The machine generates a random challenge
2. The control unit returns the random challenge signed, using its private key stored
inside A5000.
3. The machine validates the random number signature with the public key obtained
from the control unit certificate.
A successful response means that the control unit is authentic. Bear in mind that the trust
relies on protecting the private key. For this reason, the use of A5000 is fundamental to
make sure the private key is not compromised.
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
6 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 5. Control unit authentication flow
3.2 Machine authentication
The authentication of the machine also consists of two steps: the certificate validation
and the private key proof of possession as shown in Figure 6. These two steps are
equivalent to the ones performed for the control unit authentication.
Certificate validation:
The first step is the verification of the machine digital certificate.
1. The machine sends its device certificate together with its hierarchy of CA certificates.
2. The control unit validates that the provided certificate chain of trust is valid by verifying
the signatures of all the certificates in the chain up to the root CA
If the machine certificate is valid, it means that the public key included in it can be
trusted.
Proof of possesion:
The second step is the proof of possession. This procedure is needed to make sure that
the certificate we received belongs to the machine. This proof of possession mechanism
ensures that the uploader of the certificate also knows the associated private key. For
that,
1. The control unit generates a random challenge
2. The machine returns the random challenge signed, using its private key stored inside
A5000.
3. The control unit validates the random number signature with the public key obtained
from the machine certificate
A successful response means that the machine is authentic. Bear in mind that the trust
relies on protecting the private key. For this reason, the use of A5000 is fundamental to
make sure the private key is not compromised.
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
7 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 6. Machine authentication flow
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
8 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
4 Evaluating A5000 for anticounterfeit protection
This chapter describes how to evaluate the A5000 Secure Authenticator for
anticounterfeit protection using device-to-device authentication. The following description
is provided only for demonstration. Therefore, the subsequent procedure must be
adapted and adjusted accordingly for commercial deployment.
The Plug Trust Middleware offers out of the box several software libraries to implement
and verify a device-to-device authentication on devices running an embedded Linux
distribution.
•OpenSSL
•PKCS11
•Plug&Trust Middleware SSS API
The following chapters are demonstrating the principal of the machine and control unit
authentication flow based on the theoretical example described in Section 3“. To simplify
the hardware setup a single A5000 Secure Authenticator IC is used.
To keep the example as simple as possible only A5000 pre-provisioned credentials are
used to demonstrate the Mutual Authentication.
The examples are divided into the following steps to introduce the A5000 and the
Plug&Trust OpenSSL engine and the ssscli tools:
1. Section 4.1 Hard- and software setup
2. Section 4.2 OpenSLL engine overview
3. Section 4.3 Plug & Trust Middleware ssscli tool introduction
4. Section 4.4 Pre-provisioned A5000 device certificates used by the example
5. Section 4.5 Retrieve the pre-provisioned A5000 credentials
6. Section 4.6 Chain of trust of the pre-provisioned device certificates
7. Section 4.7 Mutual authentication flow
a. Section 4.7.1 Control unit authentication
b. Section 4.7.2 Machine authentication
The physical I2C connection between the Raspberry Pi and the A5000 Secure
Authenticator can be established either in plain or secured (authenticated and encrypted)
using the Global Platform Secure Channel Protocol 03 (SCP03). Section 4.8 gives a brief
overview about Global Platform Secure Channel Protocol 03 and explains how to run the
examples using Platform SCP.
How to manage access from multiple Linux processes to the A5000 authenticator
application is briefly discussed in Section 4.9 .
4.1 Hard- and software setup
The following hardware is used for this demo as a reference for any other embedded
Linux board like the NXP i.MX8:
•Raspberry Pi3 Model B+ or Pi4 Model B
•OM-A5000ARD development kit (NXP 12NC: 935424319598)
•Optional - OM-SE050RPI adapter board for Raspberry Pi (NXP 12NC: 935379833598)
The AN12570 "Quick start guide with Raspberry Pi" describes the hardware and software
for the NXP SE05x Secure Element. Chapter “3.3. Build EdgeLock SE Plug & Trust
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
9 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Middleware test examples” describes the CMake settings to build the middleware
accessing a SE05x Secure Element.
To build the Plug & Trust Middleware to support the A5000 Secure Authenticator
application the following CMake setting needs to be modified before building the
middlware:
•Select AUTH for the CMake option PTWM_Applet.
•Select None for the CMake option PTWM_FIPS.
•Select 07_02 for the CMake option PTWM_SE05X_Ver.
•Disable the CMake option SSSFTR_SE05X_RSA.
The project settings can be specified dynamically using the CMake GUI. Figure 7 shows
a CMake GUI screenshot with EdgeLock A5000 project settings.
•Run the following commands to update the CMake settings and rebuild the Plug &
Trust Middleware:
cd ~/se_mw/simw-top_build/raspbian_native_se050_t1oi2c
cmake-gui .
Update the CMake settings as explained above. Press first Configure and second
Generate and close the CMake GUI.
cmake --build .
sudo make install
sudo ldconfig /usr/local/lib/
AN13500 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Application note Rev. 1.0 — 28 March 2022
10 / 45