EdgeLock™ SE05x: Plug & Trust Secure Element¶
There is extensive documentation online about the EdgeLock™ SE05x Secure Element so we won’t duplicate it here; however for reference we recommend the following reads:
Data Sheet: SE05x Plug & Trust Secure Element
Application Notes: User Guidelines, SE05x APDU Specification, Ease ISA/IEC 62443 compliance with EdgeLock
User Manuals: NXP SE05x T=1 Over I2C Specification
The EdgeLock™ SE05x follows the Global Platform Card Specification. So on top of the previously suggested product documentation we also advise to get some awareness of the specification by reading the following documents:
Global Platform Specifications: Card Specification 2.3.1, Secure Channel Protocol 03
NXP SE05x Plug & Trust MW¶
NXP provides a software stack, the SE05x Plug&Trust Middleware, to support this device in a number of environments.
There is also extensive documentation in the form of PDF and HTML browsable documents within the freely downloadable NXP SE05x Plug & Trust MW software package. We recommend users to download and succinctly read them to better understand what the product has to offer.
A reduced open source version of this middleware is the Plug-and-Trust mini package used in our OP-TEE integration. We forked the repository and maintain it on our public github server. Since support for the SE05x exists in OP-TEE upstream, OP-TEE references this project in order to run its Azure CI pipeline and avoid build regressions.
Note
The support for the SE05x in OP-TEE is generic and not platform dependent: it only requires an OP-TEE native I2C driver to enable SCP03 early during boot.
NXP SE05x Plug & Trust TEE Integration¶
At Foundries.io we believe in securing systems by extending the perimeter of the hardware root of trust to as many operational phases as possible: secure monitoring, secure authentication, storage protection, secure communication and key management.
Because a number of our customers have been targeting the NXP SE05x in their designs, we chose to integrate the NXP middleware with our ROT (root of trust) by bringing it under the umbrella of our Trusted Execution Environment: OP-TEE.
The SE05x middleware is a behemoth of a software stack: highly configurable, highly flexible and therefore sometimes difficult to navigate. And derived from its flexibility comes its complexity and size - well over half a million lines of code.
Fortunately, most of the functionality provided by the TEE overlaps with that provided by the SE05x; in particular all cryptographic operations have a software mirror implementation in OP-TEE: ECC, RSA, MAC, HASH, AES, 3DES and so forth.
This meant that we could validate our integration using the OP-TEE crypto regression test suite from the OP-TEE tests
The main advantage of using the SE05x in a product design which already runs a TEE is that all private keys programmed in the device’s non volatile memory will never be leaked to the outside world.
The SE05x also provides a real random number generator which can be exported to the REE (normal world) to improve its entropy requirements.
Because the TEE is its only client, the TEE SE05x stack only requires a single global session and key store. Policies are configured so only the SCP03 enabled session can access its objects for creation or deletion.
OP-TEE Integration¶
The SE05x standard physical interface is I2C typically configured as a target running in high speed mode (3.4Mbps). Since the SE05x could replace the OP-TEE default crypto operations (software), we chose to implement a native I2C driver so the SE05x could be accessed as early as possible.
OP-TEE’s cryptographic providers are not runtime configurable meaning that the user must choose at compile time where to execute its cryptographic functions: whether in libmbedtls, libtomcrypt or now in the SE05x. But this is not an all or nothing configuration and operations can be routed to one service or another; for instance on an iMX platform the Hardware Unique Key could be retrieved from the CAAM, AES ECB and HASH operations implemented in libtomcrypt, and RNG, ECC and RSA in the SE05x.
Note
As a typical scenario, choosing to run AES ECB and HASH on the SE05x might be a bad idea due to its performance implications as those operations are heavily used to verify the trusted filesystem in OP-TEE and would dramatically slow down the opening of trusted applications.
Serial Communications to the SE05x¶
The first step taken during the integration work was to develop and upstream a native I2C driver (imx_i2c). But since this driver could not be used once the REE started executing - as it would not protect against I2C bus collisions or power management implementations controlled from the REE - we needed a second driver: a sort of i2c trampoline service capable to routing I2C read and write operations from OP-TEE to the REE driver (Linux in particular).
Note
These drivers are configurable using the following build options:
CFG_CORE_SE05X_I2C_BUS= : the I2C bus where the SE05x sits
CFG_CORE_SE05X_BAUDRATE= : the SE05x baud-rate in mbps
Secure Communication Protocol 03¶
The SE05x has native support for Global Platform Secure Communication Protocol 03 which allows us to protect the integrity of end to end communications between the processor and the SE05x. All data sent to the SE05x is software encrypted and all data received decrypted in the TEE using a set of predefined keys shipped with the devices.
These keys can be securely rotated. Once rotated, they are stored in the TEE secure file system.
Note
We can choose whether to enable SCP03 right after boot with its default set of keys or at a later time once the RPMB-FS (or REE-FS) are available so the keys can be read from secure storage:
CFG_CORE_SE05X_SCP03_EARLY=y : enables SCP03 with its default keys.
CFG_CORE_SE05X_SCP03_PROVISION=y : allows SCP03 rotation.
To trigger SCP03 key rotation, execute the following Pseudo Trusted Application from the REE: the scp03 PTA. This is generally accessible via libseteec and from the u-boot scp03 command.
Warning
If the secure database storing the SCP03 keys gets corrupted, the processor will no longer be able to access the SE05x over an encrypted connection. Moreover, there is no protocol defined to recover from this situation. This is why we chose to derive the SCP03 static keys from the platform’s Hardware Unique Key so that they can be recreated in the Trust Zone on every boot.
SE05x Non Volatile Memory¶
The current implementation of the SE05x TEE driver only allows for permanent storage of the ECC and RSA keys. These keys can be managed using the cryptoki API implementing the pkcs#11 standard. External keys used by the SE05x to perform other cryptographic operations are not stored in the SE05x NVM.
Note
The SE05x NVM can be cleared by setting the following configuration option:
CFG_CORE_SE05X_INIT_NVM=yAlternatively, the SE05x NVM can also be cleared by issuing the following command on the target:
$ ssscli se05x reset
The ssscli tool will be discussed in the next section.
Be aware that initializing the NVM would cause all keys and objects to be deleted from permanent storage, but would not affect any handles that the PKCS#11 TA might have stored in its database which would now point nowhere. This configuration option however has no impact on the SCP03 set of static keys which will remain unchanged.
Importing Secure Objects to PKCS#11 tokens¶
After manufacturing, the NXP SE05x will contain pre-provisioned keys and certificates. These secure objects will be known to the user through their product specific internal documentation and will be accessible from the TEE by their 32 bit identifiers.
To import those objects into PKCS#11 tokens, we have extended the TEE pkcs#11 implementation. This allows the user to call standard tools like pkcs11-tool to import keys into the database; as we said earlier, private keys can’t be exposed outside the secure element and therefore these calls shall only import the handles to access those keys. The SE05x OP-TEE driver is prepared to work with either keys or key handles. Storing handles in the pkcs#11 database does not impose restrictions to the user.
Note
The private key will be a handle to the actual key in the element NVM: private keys are never exposed outside the NXP SE05x. For example, to import the data-sheet documented 32 bit 0xF7000001 RSA 4096 bit key into the pkcs#11 database, issue the following command:
$ pkcs11-tool --module /usr/lib/libckteec.so.0.1 --keypairgen --key-type RSA:4096 --id 01 --token-label fio --pin 87654321 --label SE_7F000001
We developed a very simple PTA SE05x Object Import Application to interface to the TEE and gain access to the SE05x to obtain certificates. This application also includes a wrapper to import the keys using the mechanism described earlier.
The certificates are retrieved in DER format using the import PTA and then written to the pkcs#11 token.
$ pkcs11-se05x-import --cert 0xf0000123 --id 45 --pin 87654321
The following diagram succintly details the overall design:
To offer universal access to Secure Element we also developed and up-streamed an apdu based interface accessible via libseteec. This interface allows the normal world to send APDU frames to the SE05x using OP-TEE’s SCP03 secure session.
A python application that uses this interface is ssscli, a tool developed by NXP to provide direct access to its secure element:
fio@imx8mm-lpddr4-evk:~/$ ssscli
Usage: ssscli [OPTIONS] COMMAND [ARGS]...
Command line interface for SE05x
Options:
-v, --verbose Enables verbose mode.
--version Show the version and exit.
--help Show this message and exit.
Commands:
a71ch A71CH specific commands
cloud (Not Implemented) Cloud Specific utilities.
connect Open Session.
decrypt Decrypt Operation
disconnect Close session.
encrypt Encrypt Operation
erase Erase ECC/RSA/AES Keys or Certificate (contents)
generate Generate ECC/RSA Key pair
get Get ECC/RSA/AES Keys or certificates
policy Create/Dump Object Policy
refpem Create Reference PEM/DER files (For OpenSSL Engine).
se05x SE05X specific commands
set Set ECC/RSA/AES Keys or certificates
sign Sign Operation
verify verify Operation
This diagram summarizes the options discussed:
