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

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 7. A5000 CMake options
4.2 OpenSSL engine overview
OpenSSL is a free software library contains an open-source implementation of the TLS
protocols. OpenSSL is available for most Unix-like operating systems (including Linux,
macOS, and BSD) and Microsoft Windows.
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
11 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
The OpenSSL software library, written in C, includes a command-line interface for
general-purpose cryptography and managing certificates. For simplification the demos
below are using the OpenSSL CLI.
Starting with OpenSSL version 0.9.6, a new component called ENGINE, was added to
support alternative cryptography implementations. This Engine interface is used by the
Plug & Trust Middleware to interface with the A5000. The OpenSSL engine provides the
glue between applications using standard OpenSSL APIs and the Secure Authenticator
API.
Host MCU / MPU
OpenSSL
EdgeLock Plug&Trust
middleware stack
e4sss OpenSSL engine
Host Application
EdgeLock A5000
OpenSSL API
Figure 8. Principle of the OpenSSL engine
The Plug&Trust middleware OpenSSL engine allows to use the A5000 Secure
Authenticator for the following operations:
•EC crypto: EC sign/verify and ECDH compute key
•Fetching random data
The A5000 secure key and object management is not covered by the engine interface
but supported by the Plug & Trust Middleware ssscli tool as demonstrated in the
next chapters.
OpenSSL requires a key pair, consisting of a private and a public key, to be generated or
loaded into the A5000 before the cryptographic operations can be executed.
• Private Key: The Private key is securely stored inside the A5000 Secure Authenticator
and cannot be retrieved by the OpenSSL engine.
• Reference Key: Standard OpenSSL API needs to be called with a key. Instead of a
real private key the OpenSSL key data structure gets used with a reference to the
private key inside the Secure Authenticator. The reference key looks for OpenSSL like
a real key, but it does not contain secret data.
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
12 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
• Certificate/Public Key: The Certificate/Public Key as read from the Secure Element
can still be inserted into the OpenSSL key structure.
The A5000 Secure Authenticator can be easily integrated by applications which are
already using the OpensSSL API or the command-line tools. Instead of using a private
key, the application needs to use a reference key.
For more details, please see the Plug & Trust Middleware documentation:
• 8.1. Introduction on OpenSSL engine
• 5.3.2. AWS Demo for iMX Linux / RaspberryPi
• 5.4.2. OpenSSL Engine: TLS Client example for iMX/Rpi3
Run the following command to check weather OpenSSL is installed or not:
openssl version
Figure 9. Check the installed OpenSSL version
If OpenSSL is not already installed, you can run the following commands to install it:
apt-get install openssl libssl-dev
4.3 Plug & Trust Middleware ssscli tool introduction
The ssscli is a command line tool that can be used to send commands to A5000
interactively through the command line. For example, you can use the ssscli to create
keys and credentials in the A5000 security IC during evaluation, development and testing
phases. The ssscli tool is written in Python and supports complex provisioning scripts
that can be run in Windows, Linux, OS X and other embedded devices. It can be used to:
•Insert keys and certificates in DER or PEM format into the A5000
•Retrieve the public keys and certificates form A5000 and store the key into a DER
(Distinguished Encoding Rules) or PEM (Privacy Enhanced Mail) formatted file
•Create reference-keys and store the key into a DER or PEM formatted file
•Delete A5000 (erase) keys and certificates inside
•Generate keys inside the EdgeLock A5000
•Attach policies to objects
•List all A5000 secure objects
•Retrieve the A5000 device unique ID
Run some A5000 basic operations like sign/verify and encrypt/decrypt operations. Please
refer to the Plug & Trust Middleware documentation chapter "9. CLI Tool" for detailed
description how to use ssscli tool. Alternative use the following command to display the
ssscli built in help:
ssscli --help
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
13 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 10. ssscli help
The help includes a parameter description for all supported commands. To list all options
for the connect command use:
ssscli connect --help
Figure 11. ssscli connect help
Note: The subsystem option auth shall be used to define a session with the A5000
authenticator. For the Raspberry Pi the connection method none can be used.
The A5000 Secure Authenticator supports also the se05x commands certuid,
readidlist, reset and uid.
ssscli se05x --help
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
14 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 12. ssscli se05x help
The following commands will list all A5000 secure objects:
ssscli connect auth t1oi2c none
ssscli se05x readidlist
Figure 13. ssscli readidlist
Note: If you are not able to connect to the A5000 with an error saying that there is a
session already open, run ssscli se05x disconnect first.
To close a session use:
ssscli disconnect
4.4 Pre-provisioned A5000 device certificates used by the example
Examples described in this document are using the following pre-provisioned credentials
listed in the table below.
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
15 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
To be able to demonstrate the principle of machine and control unit authentication flow
with a single Raspberry Pi and OM-A5000ARD board the ECC256 key pair 0 (object ID
0xF0000000) and the corresponding certificate 0 (object ID 0xF0000001) are used as
“machine” credentials.
As “control unit” credentials the ECC256 key pair 1 (object ID 0xF0000002) and the
corresponding certificate 1 (object ID 0xF0000003) are used.
Credentials
are assigned
to
Key name and type Certificate Identifier
Machine Originality Key 0, ECC256, Die
Individual
Certificate 0 0xF0000000 (key)
0xF0000001 (cert)
Control Unit Originality Key 1, ECC256, Die
Individual
Certificate 1 0xF0000002 (key)
0xF0000003 (cert)
Table 1. Pre-provisioned certificates and keys used by the example
Note: The complete list of pre-provisioned device credentials is provided in the A5000
EdgeLock Secure Authenticator Product data sheet.
4.5 Retrieve the pre-provisioned A5000 credentials
The ECC private keys are securely stored inside the A5000 secure authenticator and
cannot be read out. Standard OpenSSL API and the OpenSSL command-line tools
needs to be called with a private key to perform private key operations.
The Plug & Trust Middleware provides an OpenSSL engine which allows to use so called
reference keys instead of private keys. A reference key contains only a reference, the
object ID, to the private key inside the A5000. The reference key looks for OpenSSL
like a real key, but it does not contain secret data. All private ECC operations using a
reference key, e.g. ECC signing, are performed securely inside the A5000 without the
need to know the private key value.
This chapter demonstrates how to use the ssscli and openssl command-line tools to
perform the following operations:
•Reading of the pre-provisioned A5000 device certificates and save them into a PEM
formatted file.
•Reading of the pre-provisioned A5000 device certificates public keys and save them
into a PEM formatted file.
•Creation of the corresponding reference keys and storage in a PEM-formatted file.
4.5.1 Retrieve the pre-provisioned A5000 device certificates
Create a folder inside your home directory for the example certificates and keys using the
following commands:
mkdir ~/auth_demo
cd ~/auth_demo
Run the following ssscli commands to read the device certificates and store them into
a file. By default a filename with extension .pem and .cer will store the certificate in
PEM format. Other extensions will store the certificate in DER format. In the following
examples we use machine.pem and control_unit.pem as the certificate file names.
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
16 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
ssscli get cert F0000001 machine.pem
ssscli get cert F0000003 control_unit.pem
Figure 14. Retrieve the pre-provisioned A5000 device certificats
Both certificates are stored in PEM format. These are text files containing base64
encoded data. The Linux command cat can be used to output the contents of a text file:
cat machine.pem
cat control_unit.pem
Figure 15. Device certificats in PEM format
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
17 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
The x509 Openssl command can be used to display the contents of a certificate in
human readable form (-text switch). The -noout switch reduces the output by not
printing the base64 encoded certificate itself.
openssl x509 -noout -text -in machine.pem
Figure 16. Content of the machine certificate
openssl x509 -noout -text -in control_unit.pem
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
18 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 17. Content of the control unit certificate
4.5.2 Retrieve the pre-provisioned A5000 device certificates public keys
The ECC public keys are required for the ECC verify operation. The ECC public keys can
be extracted from the corresponding certificate using the OpenSSL command-line tool or
with the help of the ssscli tool. In this chapter the ssscli tool is used.
ssscli get ecc pub --format PEM 0xF0000000 machine_pub_key.pem
ssscli get ecc pub --format PEM 0xF0000002
control_unit_pub_key.pem
Figure 18. Retrieve the pre-provisioned A5000 device certificate's public keys
We use again the Linux command cat to display the both PEM formatted public keys:
cat machine_pub_key.pem
cat control_unit_pub_key.pem
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
19 / 45

NXP Semiconductors AN13500
EdgeLock A5000 Secure Authenticator for electronic anti-counterfeit protection using device-to-device
authentication
Figure 19. Device public keys in PEM format
The x509 OpenSSL command also supports to display the public keys contents:
openssl ec -pubin -in machine_pub_key.pem -text
openssl ec -pubin -in control_unit_pub_key.pem -text
Figure 20. Content of the device public keys
4.5.3 Create the reference key files for the OpenSSL engine
As already described above, the ECC private keys are securely stored inside the A5000
and cannot be read out like the public certificate or public key. To be able to delegate
a private crypto operation like an ECC signature generation to the A5000 we need to
generate a reference key. Later we use the reference key instead of the private key for
OpenSSL operations.
The following two commands are generating a "machine" and "control unit" reference
key.
ssscli refpem ecc pair 0xF0000000 machine_ref_key.pem
ssscli refpem ecc pair 0xF0000002 control_unit_ref_key.pem
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
20 / 45