Category: wolfTPM

TPM vs HSM, what’s the difference? Check out this blog post for more detailed.

In a nutshell, TPMs are typically a dedicated chip included along side a main (host) processor and used for securing a single consumer electronics device. HSMs are external devices that can be used across multiple devices and systems, offering advanced cryptographic operations and key management. For both of them, their main objective is to protect and store private key material. A TPM typically presents itself via the standardized TPM 2.0 API while an HSM presents itself via the standardized PKCS11 API.

If you think about it really, really carefully, the difference is just a matter of form factor, interfaces, and regulatory technicalities. So is it possible for a TPM to present itself as an HSM? The answer is most definitely YES! But how?

Here at wolfSSL we have our own PKCS11 provider library, wolfPKCS11, to leverage cryptographic hardware and keystores on various systems. A while ago, we added support for using TPM 2.0 modules via wolfTPM into wolfPKCS11. We believe that this functionality is particularly useful for users that have coded to the PKCS11 standard, but need to switch to a TPM or fTPM; there are many technical and business reasons to do so.

With that in mind, if you have been using an HSM and want to simplify to simply using a TPM with little to no code changes in your application, let us help you with that. Reach out to us to find out how your specific situation would work!

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

We’re excited to share a new feature added to wolfTPM: a lightweight example for verifying TPM Endorsement Key (EK) Certificates without wolfCrypt.

The new example, `verify_ek_cert`, retrieves and verifies the EK certificate stored in the TPM’s non-volatile memory. This supports TPMs like the Infineon SLB9672/SLB9673, STMicro ST33 series, and validates their RSA-signed EK certs using the manufacturer’s public CA certificate. This is essential for secure boot, remote attestation, and provisioning in trusted systems.

Highlights:

• Reads EK cert from NV memory (Index: 0x1C00002)
• Parses and validates the X.509 certificate
• Verifies hash and signature using CA public key
• Confirms TPM identity and trustworthiness

This example uses minimal ASN.1 parsing to reduce code size and avoid dependencies on wolfCrypt. This approach is especially valuable for DO-178C certification efforts, where reducing complexity and traceability is critical. wolfTPM remains the only TPM 2.0 stack specifically designed for bare-metal environments with a minimal code footprint—ideal for embedded, safety-critical systems.

To try it:

$ git clone https://github.com/wolfSSL/wolfTPM.git
$ cd wolfTPM
$ ./configure --disable-wolfcrypt && make
$ ./examples/endorsement/verify_ek_cert

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

wolfTPM now includes support for Das U-Boot, extending TPM 2.0 access to early boot stages in secure embedded systems. This port enables direct TPM communication in U-Boot environments using software SPI and provides both native and high-level APIs for flexibility.

Key Features

• SOFT SPI Driver
• Full TPM 2.0 command set
• Both native API and wrapper APIs for complex TPM operations
• Two integration paths:
  • __linux__: Uses tpm2_linux.c to communicate via standard Linux TPM interfaces
  • __UBOOT__: Direct SPI communication via tpm_io_uboot.c

U-Boot TPM Commands

The wolftpm command interface in U-Boot offers a rich set of TPM 2.0 operations. including:

• Basic TPM control: init, startup, self_test, info
• PCR management: pcr_extend, pcr_read, pcr_allocate, pcr_print
• Security features: clear, change_auth, dam_reset, dam_parameters
• Firmware management: firmware_update, firmware_cancel
• Capability reporting: caps, get_capability

These commands allow developers to initialize, configure, and query TPM state from within U-Boot, enabling security features even before the OS loads.

Extended Functionality

While U-Boot includes basic TPM 2.0 command support through its native library, wolfTPM extends this functionality with the ability to manage firmware updates.

Firmware Management Support

wolfTPM includes dedicated commands for managing TPM firmware, allowing users to directly perform updates and control firmware behavior from the U-Boot shell:

• firmware_update <manifest_addr> <manifest_sz> <firmware_addr> <firmware_sz>
  Performs a full firmware update on the TPM by providing a signed manifest and firmware image.</styel=”font-family:courier>
• firmware_cancel
  Allows users to cancel or abandon an ongoing firmware update process. 

These capabilities are not present in U-Boot’s built-in TPM stack, which lacks any mechanism for managing TPM firmware or triggering a reboot of the TPM device. With wolfTPM, developers gain direct control over the TPM lifecycle, supporting scenarios like:

• Field upgrades of TPM firmware
• Factory provisioning with verified firmware images
• TPM resets and recovery via startup/shutdown sequences

By leveraging wolfTPM in U-Boot, embedded developers and security teams can take full advantage of the TPM 2.0 specification—including lifecycle and provisioning flows that go beyond what standard U-Boot TPM implementations provide.

Getting Started

For detailed build instructions, configuration options, and sample usage:

• Pull Request with full details: PR#398
• Documentation and examples: examples/u-boot/README.md

Conclusion

wolfTPM’s U-Boot support is ideal for securing early boot environments with TPM 2.0 features. With a rich command-line interface, flexible APIs, and tested support for QEMU and swtpm, it’s a robust solution for TPM integration in embedded platforms.

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

wolfSSL now has support for Zephyr RTOS through a newly added wolfTPM Zephyr port. This enables easy integration of TPM 2.0 functionality in embedded projects using Zephyr, expanding the flexibility and portability of secure applications.

Below is a summary of the key features introduced in the PR#395:

Key Changes and Features

Zephyr Module Integration

wolfTPM has been added as a Zephyr module, complete with CMake and Kconfig support. This makes it simple to include TPM functionality in any Zephyr-based project using standard module inclusion through west.

Sample Applications

Two test/sample applications are included in the port:

• wolftpm_wrap_test – tests core TPM wrapper functionality
• wolftpm_wrap_caps – displays TPM capabilities

Both examples build and run successfully on qemu_x86, providing developers with a solid foundation to build on.

Custom Configuration Support

The module uses a user_settings.h configuration file, which can be customized or replaced as needed by developers to match project-specific requirements.

CI Integration

A new zephyr.yml GitHub CI workflow has been added to automatically build and verify the wolfTPM Zephyr samples, ensuring continued build stability and integration with upstream Zephyr changes.

Device Tree Integration

Communicating with your TPM in zephyr is as simple as setting WOLFTPM_ZEPHYR_I2C_BUS in user_settings.h to the node describing the i2c bus on your device. You can also set the speed of the i2c line with WOLFTPM_ZEPHYR_I2C_SPEED.

Getting Started

To learn more about using wolfTPM with Zephyr and how to set it up in your project, see:

• Pull Request with full details: PR#395
• Getting Started Documentation: zephyr/README.md

Conclusion

wolfTPM now supports Zephyr RTOS, enabling robust TPM 2.0 integration in lightweight embedded systems. With CI coverage, modular design, and working samples, developers can confidently build secure applications using wolfTPM on Zephyr.

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

The latest update to meta-wolfssl introduces support for the wolfTPM wrap_test example, enhancing TPM functionality within the Yocto Project. PR #92, includes new recipes, such as wolftpm-wrap-test.bb and wolftpm_%.bbappend, allowing seamless integration and testing of wolfTPM in Yocto Linux environments.

With this update, users can now easily validate TPM-based security features using QEMU and the TPM 2.0 simulator within a Yocto Linux environment. For a full setup guide on configuring and running QEMU and the TPM 2.0 simulator, refer to the README. These instructions outline how to build and run wolfTPM within a simulated Yocto Linux environment. This update simplifies and provides a structured approach for testing TPM features within embedded Linux systems.

The latest meta-wolfssl update streamlines TPM-based security feature validation in embedded Linux systems. This improvement is achieved through enhanced support for the wolfTPM wrap_test, new recipes for seamless Yocto Linux integration, and a structured guide for using QEMU and the TPM 2.0 simulator.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfTPM is a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM has been supporting NSING Technologies Z32H330TC and recently added support for NS350 starting from wolfTPM 3.6.0.

The NS350 series are NSING’s new generation of high-security, high-performance, and cost-effective TPM 2.0 security chips that offer significant improvements in both technical performance and security. The NS350 devices are all Common Criteria (EAL4+) certified.

The users of NS350 can take advantage of wolfTPM’s API wrappers to help with complex TPM operations like attestation and cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM. We have a multitude of examples to help accelerate your integration.

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

We are pleased to announce the release of wolfTPM 3.8.0, our latest version with several important enhancements.

What’s New

This release includes a range of fixes and improvements that enhance the overall quality and reliability of wolfTPM. These changes are designed to support the delivery of high-quality production-grade products that meet the needs of our customers.

Key Changes

• Session Auth Improvements: We’ve fixed an issue with bound session authentication, ensuring that TPM 2.0 authenticated sessions with binding work correctly. Additionally, we’ve added comprehensive test cases to verify the functionality.
• Bus Protection: Our implementation of the TCG “bus protection guidance” now includes a comprehensive example, making it easier for developers to ensure their applications meet these critical security standards. For more information on our bus protection guidance, please refer to the TCG’s bus protection guidance document.
• Build Support: We’ve improved support for building wolfTPM against older wolfCrypt versions, including updated CI tests.
• HAL IO Improvements: We’ve added HAL IO support for Microchip I2C bit-bang driver

TPM 2.0 Use Cases

wolfTPM is designed to provide a robust and secure foundation for a wide range of applications, from IoT devices to high-end servers. Here are some examples of how wolfTPM 3.8.0 can help:

• Secure Boot: wolfTPM provides a robust secure boot mechanism, ensuring that only authorized firmware can be loaded on the platform.
• Platform Firmware Updates: Our implementation of bus protection guidance includes support for secure firmware updates, making it easier to keep platforms up-to-date and secure.
• Key Management: wolfTPM can be used to manage cryptographic keys securely, providing a reliable and efficient way to handle sensitive data.
• Hardware-Level Isolation: wolfTPM’s hardware-level isolation features provide a robust security foundation for applications that require high levels of isolation.
• Trusted Execution Environments (TEEs): wolfTPM is designed to work seamlessly with TEEs, providing a secure environment for executing critical functions.

Getting Started

Download the latest version of wolfTPM 3.8.0 today! Check out the complete ChangeLog for full details.

As always, we appreciate your contributions and feedback. If you have any questions or suggestions, please email facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL is pleased to announce its upcoming wolfTPM support with Zephyr RTOS. Zephyr is an open-source, real-time operating system targeted for resource-constrained devices, which makes it a perfect match for wolfTPM’s lightweight and efficient TPM 2.0 library.

This will introduce hardware-based cryptographic security to IoT and embedded systems. Extending wolfSSL’s existing support for Zephyr supported applications like wolfSSL and wolfSSH.

Stay tuned for future updates about wolfTPM Zephyr support. If you have any further questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

In a well-designed modular system there is a dedicated component that performs cryptographic operations. It can be a discrete physical chip, a software library or a mix. Whenever a system component needs a cryptographic operation like hashing, signature verification, encryption, key creation, etc. it delegates the operation to the “cryptographic provider”.

But how to interact with the cryptographic provider?

Ideally, with a (good) standardized application programming interface (API). Having a common interface for cryptographic providers has several advantages: the provider becomes interchangeable, the software is more maintainable and easier to audit, and as a consequence, it’s safer. Unfortunately, designing a good API is an overwhelming task: the abstraction has to be clean and easy to use and read, but at the same time flexible and secure.

Public Key Cryptographic Standard 11 (PKCS#11) and Platform Security Architecture (PSA) Crypto API specifications try to accomplish this daunting task: defining a common API for cryptographic providers.

What about Trusted Platform Module (TPM) 2.0?

The TPM2.0 is aimed at a specific category of cryptographic devices, quoting from the TPM 2.0 specification:
“…a device that enables trust in computing platforms in general”. A TPM is a device that, besides normal cryptographic functions, provides the necessary foundation to enable device identification and overall system integrity reporting. Very early stages of software typically use it in a platform to establish a Root of Trust and allow secure boot and remote attestation features. So while PSA and PKCS#11 both define only an API to access cryptographic providers, TPM2.0 has a much larger scope, as it defines the system architecture to achieve the “trust” of the platform alongside the interface with the TPM device. Moreover, the interface to the TPM is described in terms of commands and responses that a compliant TPM device will understand, unlike PKCS#11 and PSA where the interface is described using C function prototypes and data structure.

But even if PKCS#11 and PSA are both C-based, they show several differences in how they model the cryptographic operations and the terminology used. As an example, PKCS#11 uses a hierarchical sophisticated object model to represent keys, algorithms (called mechanisms), devices (called tokens), etc, while PSA Crypto aims for a more flat and simpler model, where algorithms and keys are just a typedef of an integer type.

wolfSSL support for TPM2.0, PKCS#11 and PSA

Regarding TPM 2.0, wolfTPM library abstracts away the details of the communication with the device and exposes a 1:1 mapping of the TPM commands defined in the specification, plus wrappers that hide away the complexity of using the commands directly.

For PKCS#11 and PSA Crypto API wolfSSL can both expose its functionality using the defined interface and consume cryptographic functions from a provider of the interface.

This not only means that wolfSSL can use cryptographic providers that expose one of the three interfaces, not only that wolfSSL can be used by any software that uses one of the three interfaces, but that wolfSSL can also act as a sort of polyglot translator between software components!

You can refer to here as an example of this, where an application can use wolfPKCS11 to talk with a TPM, thanks to wolfCrypt using wolfTPM to talk with the latter. I report here a diagram of the article as a reference:

So no matter what interfaces you need, wolfSSL has you covered! Do you need more info about a specific use-case? Do you have any suggestions? or if you have questions about any of the above, feel free to drop a line at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now