HSMs, TPMs, Secure Enclaves, and Secure Elements are all dedicated security components that exist to service other devices. While at a high level they have similar security goals and intentions (e.g. private key isolation), they are not the same things, and they do have important differences. This blog post will guide the reader through what those key differences are.
Download wolfSSL →
Hardware Security Module (HSM)
Hardware security modules (HSMs) are standalone security devices that traditionally range from small USB plug-ins to larger rack-mounted servers. In contrast to other security components, HSMs have a clear client-server separation, with client cryptographic API exposed over a network interface (usually PKCS#11). This enables key operations to be isolated to the HSM server side, while the client interacts only with opaque key handles or tokens through an API. HSMs are typically used for key lifecycle management, digital signatures, high-throughput cryptographic operations, etc. It can be thought of as a “trusted” network computer for offloading cryptography and managing keys. An HSM is secure because it:
- Is built on top of well-tested, lab certified hardware.
- Has a security-focused OS.
- Has limited access via a network interface controlled by internal rules.
- Actively hides and protects cryptographic material.
- Securely create, store, and isolate the use of cryptographic keys.
- Authenticate platform devices and encrypt data using the TPM’s unique bind key.
- Ensure platform integrity by storing security and system integrity measurements.
- Create a nearly unforgeable hash key summary of the hardware and software configuration, which allows a third party to verify that the software has not been changed, called remote attestation.
- Generate random numbers from hardware.
- Detection of hacking and modification attempts.
- Creation of a Root of Trust (RoT) platform for encryption systems.
- Secure memory for storing private encryption keys and other sensitive information.
- Secure random number generation.
- Generation of encryption keys.
HSMs are usually designed with tamper-resistance, and furthermore to be tamper-evident (meaning they self-document attempted tampering through physical evidence or event logging), and tamper-responsive (they respond to breaches by deleting sensitive material or shutting down). Additionally, HSMs can be certified to internationally recognized standards, such as FIPS 140, to provide independent assurance of sound design and implementation.
wolfSSL ties into HSMs through several mechanisms. wolfHSM provides a portable abstraction layer to facilitate working with HSMs on both client and server sides. wolfBoot can provide secure boot on the HSM server core. Finally, the wolfSSL library itself supports PKCS#11. Using wolfSSL on your application or your device will now allow you to utilize PKCS#11 for access to hardware security modules, smart cards, and other cryptographic tokens.
Trusted Platform Module (TPM)
Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor – a special microcontroller designed to secure hardware through integrated cryptographic keys. This microcontroller interfaces with a standard hardware/software platform to be secured to serve the interests of the system designer alone. In contrast to HSMs, TPMs are not standalone devices, and instead are physically integrated with a host system, where they provide specialized cryptographic support and platform attestation. Virtually all modern TPMs adhere to the TPM 2.0 standard, from the Trusted Computing Group.
TPMs are used to:
TPM technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure elements, and the only TPM 2.0 library designed for bare metal and embedded systems. It also has native Windows and Linux support, alongside a TPM simulator for rapid development and testing. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670. Due to wolfTPM’s portability, it is generally very easy to compile on new platforms. For more information, visit the wolfTPM product page!
Secure Enclave
Secure enclaves are becoming a popular way to separate and protect sensitive code and data from other processes running on a system. Two popular secure enclaves are SGX and TrustZone, both of which can be used in securing trusted execution environments.
A trusted execution environment (TEE) is a secure area of a main processor which guarantees confidentiality and integrity of code and data loaded inside. A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets.
Intel Software Guard Extensions (SGX) are a set of security-related instruction codes that are built into some modern Intel CPUs. SGX allows user-level and operating system code to define enclaves – private regions of memory whose contents are protected and unable to be either read or saved by any outside process. SGX involves encryption by the CPU of a portion of memory and protects data via application isolation technology. In cryptography, SGX can be used to conceal proprietary algorithms and encryption keys.
SGXs can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint, this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor would not be able to access data inside of this “black-box”. An Intel enclave is a form of user-level TEE which can provide both storage and execution – users can store sensitive information, as well as move sensitive portions of a program or an entire application inside.
The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been set up for both Linux and Windows environments. For more information, visit our blog post on wolfSSL and Intel SGX.
Arm TrustZone technology offers an efficient, system-wide approach to security with hardware-enforced isolation built into the CPU. It provides the perfect starting point for establishing a device root of trust based on Platform Security Architecture (PSA) guidelines. TrustZone is used on billions of application processors to protect high-value code and data for diverse use cases including authentication, payment, content protection and enterprise. On application processors, TrustZone is frequently used to provide a security boundary for a GlobalPlatform Trusted Execution Environment.
wolfBoot provides support for secure boot on systems with a TEE. wolfBoot provides embedded developers with a code base that complies with the specification for the separation between secure and non-secure world, on those CPUs and microcontrollers that support it. On ARMv8 Cortex-A CPU and Cortex-M microcontrollers it is now possible to create a hardware-enforced separation between the two worlds, using the ARM TrustZone technology. For more information, read our blog post on wolfBoot support for ARM TrustZone.
wolfCrypt, our crypto engine that powers wolfBoot, supports all possible schemes from a wide range of manufacturer-specific API to access this functionality, such as Microchip ATECC608, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, and many others.
The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security modules (HSM, TPM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. wolfSSL supports the NXP CAAM hardware, which offers the same functions as HSM, but built into i.MX silicon. For more information, visit our blog about NXP CAAM.
Secure Element, Hardware Root of Trust, SoC HSMs
Hardware root of trust prevents simulation of hardware with user-controlled software, using a set of private keys used for cryptographic functions that are embedded directly into the chip during manufacturing. These keys cannot be changed, even after device resets, and have public counterparts kept in a manufacturer database. The public key is used to verify a digital signature of trusted vendor-controlled firmware (such as secure enclaves in SGX), which is then used in remote attestation.
Hardware root of trust also enables a secure boot process, using hardware that makes it immune from malware attacks. It can be used on its own or implemented as a security module within a processor or a system on chip (SoC).
Secure Element refers to secure solutions like STSAFE, ATECC608, and hardware roots of trust that function in a TPM-like role but without the standard TPM interface. Secure elements are unique in terms of interface. Similarly, system on a chip (SoC) HSMs function in an HSM-like role but in a smaller profile embedded space. Taken together, Secure Elements and SoC HSMs are an emerging category of security products that combine aspects of both TPMs and HSMs while remaining distinct. Their features include:
The wolfTPM library provides APIs to access TPM 2.0 compatible secure elements, and similarly wolfHSM can be integrated with SoC HSMs.
Conclusion
HSMs, TPMs, Secure Enclaves, and Secure Elements all have similar underlying goals, which is to securely execute cryptographic operations, provide cryptographic offloading for a host system or client, and in general to provide isolation mechanisms for cryptographic keys and sensitive data. The differences are mainly in their scale (e.g. a rack mounted cloud HSM, vs a secure cryptocoprocessor), the standards they adhere to (PKCS#11, vs TPM 2.0), architecture (external vs integrated component), and whether a client-server abstraction is present. wolfSSL provides products that support all different schemes to best fit your cryptographic needs!
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now