Since its inception almost five years ago, the Linux microPlatform™ has been leveraging secure boot and the PKCS#11 API for securely storing and managing IoT Keys and Certificates. On ARM/RISC-V, OP-TEE became our preferred implementation to access Secure Storage, Secure Elements, Enclaves and Cryptographic Cores. On other platforms, we recently up-streamed support for TPM2 devices and it is now our choice as a secure back-end to the API when OP-TEE is not available.
Linux microPlatform: why PKCS#11?
The Public Key Cryptography Standard #11 defines a secure API which allows clients to access cryptographic devices for key generation, encryption, decryption, digital signatures and storage in a future-proof vendor-neutral way.
As security researchers continue to push the technology forward, the specification evolves with support for new algorithms added to the different implementations of the standard while maintaining backwards compatibility.
This allows our cryptographic software to persist unmodified across releases for any new cryptographic device that our customers may chose to use—e.g., at the time of this writing, that would be the i.MX93 with the Secure Enclave core. This approach also simplifies the auditing of our software for those customers where compliance to strict security standards need to be met. Our software becomes open for extension and closed for modifications.
Our commitment to this long-term architectural decision can be validated in our open contributions to firmware and security projects such as U-Boot, OP-TEE, OpenSSL, tpm2_pkcs11, and libp11—among others. These contributions, in the form of fixes, extensions, new features, and various hardware support, can be seen as an indication of how Foundries.io is helping to shape the industry in the field of device security.
The Linux microPlatform™ includes support for secure boot in SoCs from many vendors and partners—NXP, Texas Instruments, AMD/Xilinx, STMicro, Arduino, NVIDIA to name a few—each with their own cryptographic IPs and intricacies.
Our secure boot architecture relies on a combination of persistent fused keys—to start the hardware root of trust—and transient keys. And while persistent keys can be revoked just a limited number of times depending on the SoC, transient keys could and should be rotated regularly during OTA updates.
We invested in streamlining this often complicated programming sequence as part of our board provisioning process—on all SoCs that include hardware support for it—because the Linux microPlatform OTA allows clients to update each and every firmware in the boot chain: not having a properly configured root of trust would not only expose a critical vulnerability during updates, but would prevent systems in the field from fixing any that might be discovered during their operational life-time.
And that will no longer be just an inconvenience for product manufacturers: they will be liable by law. In the case of the E.U, the Cyber Resilience Act will impose essential security requirements for digital products and connected devices.
So at an architecture level, it is rewarding to see how our total commitment to device security is being backed up by legislative changes.
By using PKCS#11 coupled with secure boot authentication on a hardware root-of-trust, we have extended our reach to the majority of the cryptographic hardware in the market—making our platform and OTA process one of the most secure in the world.
To know more about how these changes in legislation will impact the way software products are built and what can you do to comply with the new security requirements please download our Embedded Linux: Licensing and CyperSecurity whitepaper.
The OP-TEE PKCS#11 Implementation
The implementation of the standard can be summarized in an user-space library and a Trusted Application executing in the Secure World running OP-TEE. I am swiftly skipping complexity details about the communication mechanism between both via the kernel which is beyond the scope of this blog entry.
The Trusted Application uses OP-TEE services to implement its functionality: cryptographic operations are delivered by the OP-TEE cryptographic driver which routes the requests to the corresponding hardware device driver.
When a client is using the OP-TEE PKCS#11 implementation, OP-TEE will also provide the secure storage for keys and certificates required by the PKCS#11 standard.
When a client is using a TPM however, secure storage is delivered by the TPM software stack. Additionally we integrated support for disk encryption - with LUKS and dm-crypt - to have an extra layer of protection during boot on the PKCS#11 database.
OP-TEE follows the Global Platform specification for secure storage. The specification dictates that secure storage must:
- be bound to a device, shared or not with the normal world.
- implement rollback protection.
- guarantee confidentiality and integrity of the data.
OP-TEE provides two implementations that comply with those requirements. Both can execute concurrently:
- A Rich Execution Environment File System (REE-FS), shared with the Normal World.
- A Replay Protected Memory Block File System (RPMB-FS), under OP-TEE's access control since OP-TEE calculates and programs the RPMB key. The key is derived from OP-TEE's internal secrets.
And as to supporting various types of cryptographic devices, OP-TEE can implement different types of access for different types of hardware: serial, memory map or inter processor based protocols.
Conceptually it is all that simple.
OP-TEE Access to Secure Elements
Secure Elements are typically connected to the processor via serial interfaces such as SPI or I2C. OP-TEE implements the necessary drivers to communicate with these cryptographic devices early during boot. However once the system is up, the Normal World operation might power off the bus controller (run-time power-management configurations) or cause bus collisions when accessing other devices sharing the same bus—it is rare to have an I2C bus with a single device.
To avoid this situation, OP-TEE can call back to the REE via RPC to let the Normal World handle the bus transfer to access the cryptographic device. Such a mechanism was up-streamed by Foundries.io as part of the NXP SE05X driver contribution we did. There are other considerations to have in mind—like encrypting and authenticating the data that will be put on the insecure bus—but OP-TEE can also be configured to take care of that internally.
Another important detail is that Secure Elements never expose the private keys outside the device: OP-TEE must be able to work with either key handles (for Secure Elements or Enclaves) or actual keys.
OP-TEE Access to Secure Enclaves
Secure Enclaves run on separate processor cores. OP-TEE communicates with the enclaves via inter-processor mechanisms such as mailbox; this was the design chosen to interface with the PLM firmware executing on the PMC processor on the AMD/Xilinx Versal ACAP platform when we up-streamed its OP-TEE cryptographic support.
More simple mechanisms—such as the Message Unit driver—are used in newer (at the time of this writing) i.MX platforms (i.MX93 or i.MX8ulp) to access the Secure Enclave (ELE) executing on a RISC-V core.
OP-TEE Access to Cryptographic Cores.
Cryptographic cores are typically controlled via memory mapped interfaces and as such they don't require of any additional IPC mechanisms. But since they can be shared with the normal world, sections or capabilities of the cores are usually configured and reserved using the device tree passed by a previous boot-loader to OP-TEE for modification.
OP-TEE and Software Cryptographic: LibMbedTLS and LibTomCrypt
In platforms where there is no cryptographic hardware available, OP-TEE implements its cryptographic driver using primitives provided by ports from LibMbedTLS or LibTomCrypt.
OP-TEE also offers a compile time option that allows unsupported hardware operations to fallback to their software implementations instead of allowing them to fail.
The TPM2 PKCS#11 Implementation
Unfortunately OP-TEE does not provide the stack required to support TPM devices behind its PKCS#11 implementation.
Because of this, the Linux microPlatform uses the PKCSC#11 implementation provided by the tpm2_pkcs11 project.
Foundries.io recently up-streamed support for Elliptic Curve Diffie Hellman in order to be able to derive a shared secret over an insecure channel. This shared secret is then used to help register devices with Foundries.io factories. The change extended to OpenSSL and was merged earlier this year.
Linux microPlatform PKCS#11 Architecture
The following diagram depicts the PKCS#11 architecture supporting our secure utilities as well as how the different cryptographic devices are being accessed.
Notice how OpenSSL can be configured to route cryptographic operations to a specific PKCS#11 implementation by providing the path to the corresponding library.
For more detailed information, please browse our publicly accessible documents or simply try it today on any of our many supported platforms: because as always the proof is in the pudding.