wolfBoot on STM32H5: Enhancing secure boot with TrustZone-M

WolfSSL is excited to announce that WolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This new integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following the guidelines of RFC9019 for a safe and reliable secure boot solution.

wolfBoot already offers several unique features compared to the SBSFU expansion for STM32Cube, or other open-source secure bootloaders designed uniquely for microcontrollers, like mcuboot.

This includes:

  • A wider selection of cryptographic algorithms for signature verification to choose from
    (RSA, ECC, ed25519, ed448). including a few recently added post-quantum algorithms (LMS, XMSS)

  • FIPS 140-2 and FIPS 140-3 certified cryptographic engine

  • Support for bootloader’s self-updates

  • Customizable trust anchor storage, as the keystore containing the public keys can be placed virtually anywhere in the system

  • Support for a large number of secure elements including full support for TPM to implement measured boot

  • Multiple keys allowed to authenticate different components in multiple partitions through a partition access control bitmask

  • The possibility of receiving incremental binary patches to perform delta updates

  • A safety-oriented design, facilitating safety certifications such as ASIL or DO-178C

  • Independence from the update transport mechanism, allowing remote updates over any channel or protocol

  • Flexible and portable keytools command line applications, easy to integrate with any provisioning strategy including third party signing actors and continuous deployment

  • A solid and proven set of countermeasures against specific attacks targeting secure boot mechanisms, such as fault injections and glitch attacks inducing instruction skipping

The STM32H5 series stands out within the STM32 family for its advanced performance and security features. These microcontrollers are built around the Arm Cortex-M33 core, which offers a significant boost in computational power and efficiency compared to previous generations. The STM32H5 series integrates TrustZone-M technology, providing hardware-assisted isolation between secure and non-secure executing domains, which enhances security and simplifies the development of secure applications. The STM32H5 series also offer extensive memory options, with up to 2 MB of flash memory and 640 KB of SRAM, supporting complex and memory-intensive applications. The dual-bank flash memory architecture allows for instant firmware updates by swapping the logical mapping of the two banks. Its advanced cryptographic hardware accelerators, cryptographic grade TRNG complete the picture, making the STM32H5 series an excellent choice for high-performance and secure embedded applications.

wolfBoot extends its support within the STM32 family by including some target-specific security features offered by the STM32H5 series. Let’s explore these features and their role in a system secured using wolfBoot, wolfCrypt and wolfPKCS11.

Secure boot and public key storage in OTP FLASH

The main requirement to secure the boot process consists in a so-called “trust anchor”. RFC6024 specifies the requirements for the management and the storage of the anchor, which must be immutable and immune to tampering, suggesting the use of hardware assisted mechanisms to provide strong protection against tampering and unauthorized access.

STM32H5 provides 2KB of OTP FLASH memory that meets the requirements to properly store the trust anchor. Once the keys are provisioned, the OTP FLASH memory cannot be erased, and can also be explicitly protected against further write access. wolfBoot uses the OTP memory to store the “keystore” structure containing the trust anchors. During the boot process, wolfBoot verifies the firmware’s authenticity against the stored trust anchors. By storing these anchors in OTP memory, wolfBoot ensures that the verification process is based on a reliable and tamper-proof reference.
Once provisioned, the OTP FLASH memory is available for read-only access on STM32H5 at address 0x08FFF000 : 0x08FFF7FF. The memory can be accessed in read-only mode also from the application so the same trust anchors can be also reused for other purposes.

Firmware update via dual bank swapping

STM32H5 FLASH is organized in two banks of the same size, mapped at 0x08000000 and 0x08100000 in non-secure mode and at 0x0C000000 and 0x0C100000 in secure mode. The microcontroller exposes one bit in the configuration registers to swap the mapping of the two banks in the bootloader stage. This feature ensures that the updated firmware can be installed instantly to match its hardcoded boot address. In the example configuration provided in the repository, wolfBoot reserves 256KB of FLASH memory on both banks for the bootloader code and the secure supervisor, so the boot partition has a fixed address after 0x08040000.

Support for TrustZone-M: wolfCrypt in secure world

TrustZone creates a secure execution environment, separating secure and non-secure code. wolfBoot uses this technology to implement a hypervisor that supports the PKCS#11 standard interface. This allows applications in the non-secure world to perform cryptographic operations without direct access to the cryptographic keys.

In this setup, wolfCrypt and wolfPKCS11 run as the cryptographic engine within the secure domain. The PKCS#11 interface provides a standardized API for cryptographic operations, ensuring that sensitive keys remain protected within the secure world. Applications can thus perform necessary cryptographic tasks while keeping the keys and secrets hidden from non-secure code, enhancing overall security.

wolfBoot configures the Global TrustZone Controller (GTZC) and the Security Attribution Unit (SAU) to separate the FLASH and the RAM available on the system into the two TrustZone domains. The lower half of the total RAM available is reserved for the cryptographic engine to store secret keys and other sensitive data that must not be accessible from the applications, while the upper 320KB are available for the other tasks executing in the non-secure domain.

Each Bank on FLASH memory is divided into secure and non-secure areas. After verifying the integrity and the authenticity of the selected firmware image and swapping the banks accordingly, the selected application or RTOS is executed in the non-secure domain. This basically means that the executing software has limited access to the resources available on the system, including FLASH.

Software running in the non-secure domain cannot access secrets contained in the key vault, which are in the secure-domain portion of the FLASH. Instead, an application will unlock the vault then call TrustZone Non-Secure Callable (NSC) functions through its PKCS11 standard interface, which will then use those secret keys. Each key is referred to as a slot number in the vault. wolfBoot reserves the necessary space to contain the implementation of those PKCS11 API functions in a specific area, marked as NSC in the SAU.

Support for TrustZone-M: wolfCrypt in secure world

The integration of WolfBoot with STM32H5 significantly enhances the security and reliability of an embedded system based on this series. By leveraging TrustZone technology for secure cryptographic operations, utilizing OTP memory for tamper-resistant key storage, and implementing dual bank swapping for seamless firmware updates, wolfBoot provides a robust and efficient, ready to use secure boot solution.

In addition to these features, WolfBoot offers unique capabilities such as support for post-quantum cryptographic (PQC) authentication methods like LMS and XMSS, and protection against glitching attacks, further enhancing its security profile. These features make wolfBoot an ideal choice for developers seeking a secure and reliable bootloader solution for their STM32H5-based projects.

Do you want to know more about secure boot and embedded security? Let’s talk! Send us an email to facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Top 5 Build Options To Improve wolfCrypt/wolfSSL Performance

The wolfSSL embedded TLS library and its crypto engine wolfCrypt are both highly configurable to give users the best cryptographic performance. Our users appreciate that they’re able to customize their builds to suit their specific needs. If your needs are a crypto or SSL/TLS solution optimized for performance, we’ve compiled a list of the top 5 wolfSSL build options that you should consider.

Intel Assembly
For use with Intel/AMD processors, enabling the intelasm option for wolfSSL will utilize enhanced assembly instructions of the processor that can dramatically enhance cryptographic performance for most algorithms. The instruction sets leveraged when the configure option is enabled include AVX1, AVX2, BMI2, RDRAND, RDSEED, AESNI, and ADX. This option also automatically enables our Intel AES-NI support, which on its own can lead to direct AES encryption that’s over 3.3 times faster than using software-based AES. Performance increases in total can be as large as 5,800% when intelasm is used.
Enabled with: ./configure –enable-intelasm
Macro: WOLFSSL_ARMASM

ARM Assembly
Whether you’re doing cryptography on an ARMv8, ARMv7 or even an ARM64, armasm is the quickest way to speedup your cryptographic operations, and by doing so speedup your TLS that makes use of these algorithms. By using the cryptographic instructions built into the chips, we get a significant boost in performance over straight C. We recently did another round of tuning on our ARM64 code and got the crypto running up to 9.5 times faster than it already was.
Enabled with: ./configure –enable-armasm
Macro: WOLFSSL_ARMASM

RISC-V Assembly
The newest addition on this list, wolfSSL now has support for RISC-V hardware acceleration. The RISC-V assembly implementation of AES includes standard/scalar cryptography/vector cryptographic instructions for ECB/CBC/CTR/GCM/CCM and can be up to 50 times faster than the software implementation.
Enabled with: ./configure –enable-riscv-asm
Macro: WOLFSSL_RISCV_ASM

Single Precision Math Assembly
Unlike some of the other build options on this list, SP ASM is hardware agnostic. SP is Single Precision Math and it is a wolfSSL developed math library that is extremely well optimized for cryptographic math calculations. SP ASM is the assembly component of the SP math library. Enabling this option leads to faster RSA, ECC and DH operations.
Enabled with: ./configure –enable-sp –enable-sp-asm
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)

AES GCM (4-bit Table)
A hardware agnostic feature for AES GCM (authenticated cipher) to improve the symmetric performance of the GHASH authentication calculation. The performance gain is about a 3x speedup.
Enabled with: ./configure –enable-aesmgcm=4bit
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)

For more information on the wolfSSL library and its performance, please visit our benchmarks page or contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Partner Webinar: wolfBoot security on the STM32H5 with PQC

Learn about the advanced security features of the STM32H5 microcontroller and how wolfBoot enhances these capabilities, including support for Post Quantum Cryptography.

Check it out today for “wolfBoot security on the STM32H5 with PQC.”

wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following RFC9019 guidelines for a reliable secure boot solution.

The STM32H5 series excels within the STM32 family with superior performance and security. Built around the Arm Cortex-M33 core, it provides a notable boost in computational power and efficiency. Featuring TrustZone-M technology, it offers hardware-assisted isolation between secure and non-secure domains, enhancing security and simplifying secure application development. The series includes up to 2 MB of flash memory and 640 KB of SRAM, ideal for complex applications. Its dual-bank flash architecture enables quick firmware updates. Equipped with advanced cryptographic accelerators and a cryptographic-grade TRNG, the STM32H5 series is perfect for secure, high-performance embedded applications.

wolfBoot extends its support within the STM32 family by including target-specific security features offered by the STM32H5 series. Explore these features and their role in a system secured using wolfBoot, wolfCrypt, and wolfPKCS11.

During this webinar, attendees will learn about:

  • STM32H5 Security Features
  • wolfBoot Secure Boot Solution
  • TrustZone with PKCS11
  • Post Quantum Cryptography
  • Dual Bank Swap, OTP for RoT, HW TRNG
  • Live Demonstration

Watch it now!

As always, our webinar includes Q&A throughout. 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 on RISC-V Benchmarks (HiFive Unleashed)

We are excited to share the latest benchmark results of wolfSSL v5.7.0 running on the HiFive Unleashed at 1.4GHz. We implemented AES for ECB, CBC, CTR, GCM, and CCM using assembly for RISC-V. This benchmark demonstrates the performance capabilities of wolfSSL on RISC-V architecture, highlighting our commitment to providing high-performance, lightweight, and secure SSL/TLS solutions across diverse platforms.

The benchmark results prove that the new assembly optimizations are much faster.

With RISC-V assembly optimizations:

./configure --enable-riscv-asm && make

root@HiFiveU:~/wolfssl-riscv# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm------------------------------------------------------------------------------
 wolfSSL version 5.7.0
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=64 bits=3072 sp_int.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc             20 MiB took 1.076 seconds,   18.588 MiB/s
AES-128-CBC-dec             20 MiB took 1.083 seconds,   18.473 MiB/s
AES-192-CBC-enc             20 MiB took 1.245 seconds,   16.062 MiB/s
AES-192-CBC-dec             20 MiB took 1.246 seconds,   16.047 MiB/s
AES-256-CBC-enc             15 MiB took 1.057 seconds,   14.189 MiB/s
AES-256-CBC-dec             15 MiB took 1.055 seconds,   14.212 MiB/s
AES-128-GCM-enc             15 MiB took 1.300 seconds,   11.543 MiB/s
AES-128-GCM-dec             15 MiB took 1.300 seconds,   11.535 MiB/s
AES-192-GCM-enc             15 MiB took 1.425 seconds,   10.526 MiB/s
AES-192-GCM-dec             15 MiB took 1.425 seconds,   10.523 MiB/s
AES-256-GCM-enc             10 MiB took 1.032 seconds,    9.687 MiB/s
AES-256-GCM-dec             10 MiB took 1.032 seconds,    9.691 MiB/s
GMAC Table 4-bit            31 MiB took 1.025 seconds,   30.251 MiB/s
Benchmark complete

Without RISC-V assembly optimizations:

./configure —enable-all && make

root@HiFiveU:~/wolfssl# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm
------------------------------------------------------------------------------
 wolfSSL version 5.7.0
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc              5 MiB took 12.798 seconds,    0.391 MiB/s
AES-128-CBC-dec              5 MiB took 12.672 seconds,    0.395 MiB/s
AES-192-CBC-enc              5 MiB took 15.301 seconds,    0.327 MiB/s
AES-192-CBC-dec              5 MiB took 15.181 seconds,    0.329 MiB/s
AES-256-CBC-enc              5 MiB took 17.820 seconds,    0.281 MiB/s
AES-256-CBC-dec              5 MiB took 17.669 seconds,    0.283 MiB/s
AES-128-GCM-enc              5 MiB took 12.870 seconds,    0.388 MiB/s
AES-128-GCM-dec              5 MiB took 12.870 seconds,    0.388 MiB/s
AES-192-GCM-enc              5 MiB took 15.375 seconds,    0.325 MiB/s
AES-192-GCM-dec              5 MiB took 15.376 seconds,    0.325 MiB/s
AES-256-GCM-enc              5 MiB took 17.878 seconds,    0.280 MiB/s
AES-256-GCM-dec              5 MiB took 17.896 seconds,    0.279 MiB/s
AES-128-GCM-STREAM-enc       5 MiB took 12.878 seconds,    0.388 MiB/s
AES-128-GCM-STREAM-dec       5 MiB took 12.878 seconds,    0.388 MiB/s
AES-192-GCM-STREAM-enc       5 MiB took 15.379 seconds,    0.325 MiB/s
AES-192-GCM-STREAM-dec       5 MiB took 15.385 seconds,    0.325 MiB/s
AES-256-GCM-STREAM-enc       5 MiB took 17.881 seconds,    0.280 MiB/s
AES-256-GCM-STREAM-dec       5 MiB took 17.888 seconds,    0.280 MiB/s
GMAC Table 4-bit            30 MiB took 1.006 seconds,   29.831 MiB/s
Benchmark complete

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

Download wolfSSL Now

The Top 5 Build Options for Security in wolfSSL

Here at wolfSSL, we love giving the community and our customers lots of choices and options. That said, for the vast majority of our user base, all the options we are discussing in this post should be enabled to maximize your security and minimize your adversary’s opportunities.

#define WOLFSSL_HARDEN_TLS 112 or –enable-harden-tls=112

enables the following algorithms at the following key lengths
  DH: at least 2048 bit keys
  RSA: at least 2048 bit keys
  ECC: at least 224 bit keys

#define WOLFSSL_HARDEN_TLS 128 or –enable-harden-tls=128

  Disables 3DES ciphersuites
  DH: at least 3072 bit keys
  RSA: at least 3072 bit keys
  ECC: at least 256 bit keys

#define NO_OLD_TLS or –diable-oldtls

This disables older protocols that are inherently insecure. The only protocols that are built are (D)TLS 1.2 and 1.3.

#define HAVE_ALPN or –enable-alpn

This helps to ensure that the right application is processing the connection. Please see RFC document for more details about how to use this TLS extension.

#define WOLFSSL_CIPHER_TEXT_CHECK or –enable-maxstrength

Add in extra checks after the processing of ciphertext input in order to mitigate glitching attacks.

#define WC_RSA_BLINDING or –enable-harden

RSA blinding involves transforming the input just before the RSA private key operations using some random data. After the operation, the reverse of the transform is performed giving the desired output. This prevents an adversary from gaining knowledge about the private key as they don’t know the random data that was used to determine the transform and therefore do not know the true input into the RSA private key operation.

#define TFM_TIMING_RESISTANT #define ECC_TIMING_RESISTANT or –enable-harden

These allow for constant time implementations of the math used in private key operations to mitigate timing attacks.

Oops, looks like we went a bit over 5! Want even more? Thinking about turning some of these off to get performance gains or reduce memory usage? Send a message to support@wolfSSL.com to start a conversation about it!

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

Download wolfSSL Now

wolfSSL Supports Nucleus Legacy Customers

wolfSSL has partnered with Siemens to provide cyber-security solutions in the Nucleus RTOS stack for over a decade. Now that Nucleus ReadyStart has been discontinued, wolfSSL will continue to provide support and software updates for the wolfSSL, wolfCrypt, wolfMQTT, and wolfSSH components. This will help ensure that Nucleus customers’ applications are safe and secure.

wolfSSL supports the latest versions of TLS and DTLS for newer and older versions of Nucleus. wolfCrypt also supports the latest cryptography standards, including post quantum cryptography.

Direct support plans are available for our security tools, so please contact us with any questions about keeping your Nucleus project secure!
Check out our Support and Maintenance

Lastly, if you are considering migrating to another RTOS solution, wolfSSL can continue to provide the optimized security you have been accustomed to when using Nucleus. The wolfSSL projects are highly portable, and we would be happy to assist you with the migration process.

If you have any questions about keeping your Nucleus ReadyStart up to date with the latest wolfSSL code, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

TLS and Secure Boot in the EU Cyber Resilience Act

As of June 2024, the EU Cyber Resilience Act (CRA) is a pending piece of legislation that has been approved by the European Parliament and is waiting on adoption by the Council of the European Union. Once the act comes into force, manufacturers will have 36 months to apply the rules. It aims to tackle the challenges of cyber security in the EU and “safeguard consumers and businesses buying or using products or software with a digital component”. The act will require that any product sold in the EU with a digital component will adhere to stricter cyber security regulations. Products will have to be secure by default, have a way to apply security updates, have a clear vulnerability process, and define a product life cycle among other requirements.

The CRA requires that all communications are secure. We recommend using secure protocols such as SSL/TLS and SSH instead of trying to develop your own solution. These protocols provide privacy, integrity, and authentication across unsecure networks. They protect against unauthorized access and protect the confidentiality of the transmitted information.

To provide security updates to devices in the field, we recommend using wolfBoot’s Over-The-Air (OTA) update feature. This allows you to provide security updates in compliance with the CRA. wolfBoot provides a highly reliable, transport-agnostic firmware update mechanism.

Over at wolfSSL we take vulnerabilities very seriously. We investigate them immediately and fixes are always developed within days of an initial report. We implement rigorous security testing and code review to ensure the best quality releases possible.

With wolfSSL you can be sure that your products will meet the CRA requirements. For more questions about how to comply with the CRA, or if you have questions about any of the above, please write to us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Live Webinar: Post-Quantum Algorithms in cURL

Watch our webinar, “Post-Quantum Algorithms in cURL.” The session will be led by wolfSSL Senior Software Developer Anthony Hu.

In this session, Anthony will cover a wide range of topics, from the fundamental concepts of post-quantum algorithms, including the CNSA 2.0 timelines and the concept of “Harvest Now, Decrypt Later,” to a demonstration on how to make cURL transfers quantum-safe.

Check it out: Post-Quantum Algorithms in cURL

During this webinar, we will cover:

  • Motivation: CNSA 2.0
  • Demo Architecture
  • Getting and Building the Code
  • Demo Time!
  • Post-Quantum Connection Explained

Gain an understanding of the importance of investing in post-quantum algorithms and learn how to create a quantum-safe security environment for cURL transfers in the future.

Watch it now! Time is ticking until post-quantum algorithm requirements become mandatory, so start preparing to secure your data using cURL with quantum-safe methods.

As always, our webinars will include Q&A sessions throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

TLS Session ID vs Tickets

All versions of the Transport Layer Security (TLS) protocol support resuming previously established connections. The keying material previously negotiated is re-used in the new connection. The major benefits of resuming sessions are the much shorter handshake and not having to recompute session keys. In embedded systems, both of these advantages are critical to decrease the latency of a connection. TLS session resumption uses much less bandwidth and fewer clock cycles than a full handshake. There are two methods to resume a TLS session: using the session ID or a session ticket.

The TLS session ID can be used to resume TLS <= 1.2 sessions. It has been deprecated in TLS 1.3 in favor of only tickets. The session ID is sent to the client from the server in the ServerHello message when performing a full handshake. When a client wants to resume a session, it sends the session ID in the ClientHello. The server then needs to find the session matching the ID in its cache and restore the keying material. This requires both sides to store the keying material. This means that servers need to have a cache that grows linearly with the number of peers that it intends to resume with.

TLS session resumption tickets are available in all versions of TLS, although TLS version 1.3 has introduced a few changes. The general idea is that a server can issue an encrypted ticket to the client that contains all of the data necessary to resume a session. The client has to store the ticket and the keying material to be able to resume the session while the server does not have to store anything (apart from the encryption key used to encrypt the ticket). This removes the cache burden on the server entirely. In TLS <= 1.2 the session ticket is sent as part of the handshake while in 1.3 it is a post-handshake message. This means that the server can actually issue multiple tickets in one connection but the client needs to wait until after the handshake for the server to send the ticket before it can resume a session. TLS 1.3 servers usually send the ticket as the first message right after the handshake.

To perform session resumption in wolfSSL, please see the documentation about the wolfSSL_get1_session API.

For more information about session resumption in wolfSSL, or if you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Announcing wolfSSL TPM support for the Espressif ESP32

Infineon and wolfSSL recently announced their collaborative Commitment to Trusted Computing.

wolfTPM is designed for embedded use and leverages all features in the TPM 2.0 specification. wolfTPM is ideal for resource constrained devices and runs on Windows, Linux, RTOS, and bare metal environments.
The Infineon OPTIGA TPM SLB 9672 supports Microsoft Windows and Linux environments. Infineon also offers software and tools to facilitate firmware updates for the TPM.

Today we add the Espressif ESP32 to the long list of devices with wolfTPM support. With the merge of the open source PR #351, our TPM library can now be used in the ESP-IDF for the Infineon 9673 I²C TPM 2.0 module, taking up only about 5×5 mm footprint for a PG-UQFN-32-1,-2 package.

In recent years, TPM gained more attention due to the requirement of Windows 11 machines to have a TPM module present to meet Microsoft’s Security Recommendations. In fact, many other[*1] devices have long taken advantage[*2] of the security features available in a TPM module.

Key features[*3] include :

  • Optimized TPM device for IoT and ICT applications
  • PQC-protected firmware update mechanism
  • Compliant to TPM Main Specification, Family “2.0”, Level 00, Revision 01.59
  • Certifications:
    • CC, Version 3.1 Rev.5, level EAL4+, AVA_VAN.4 (moderate) according to TCG PC Client TPM Protection Profile (targeted)
    • FIPS 140-2 level 2 (physical security level 3) (targeted)
  • I2C interface
  • Random Number Generator (RNG) implemented according to NIST SP800-90A using entropy source according to NIST SP800-90B
  • Full personalization with 4 Endorsement Keys (EK) and 4 EK certificates (RSA 2048, RSA3072, ECC NIST P256, ECC NIST P384)
  • Standard temperature range (-40°C .. +85°C) or enhanced temperature range (-40°C .. +105°C)
  • PG-UQFN-32-1,-2 package
  • Optimized for battery operated devices: low standby power consumption (typ. 120 µA)
  • 24 PCRs (SHA-1, SHA-256 or SHA384)
  • 51 kByte NV memory [*4]
  • Unlimited amount of NV counters (only depending on NV memory utilization)
  • Up to 3 loaded sessions (TPM_PT_HR_LOADED_MIN)
  • Up to 64 active sessions (TPM_PT_ACTIVE_SESSIONS_MAX)
  • Up to 3 loaded transient Objects (TPM_PT_HR_TRANSIENT_MIN)
  • Up to 7 loaded persistent Objects (TPM_PT_HR_PERSISTENT_MIN)
  • Pre-generation of up to 7 RSA key pairs
  • RSA (1024, 2048, 3072 and 4096 bit)
  • ECC (NIST P256, BN P256, NIST P384)
  • SHA-1, SHA-256, SHA-384
  • AES-128, AES-192, AES-256

Why use wolfTPM?

The perfect companion to the Infineon Hardware is the wolfTPM software library, making it easier than ever to easily use the hardware features in your project. Of particular interest is our ability to update the SLB9672 and SLB9673 firmware! See the related blog: Infineon wolfSSL Modus Toolbox Support and wolfTPM Firmware upgrade support,

Security Enhancement: Adding wolfTPM to your Espressif ESP32 projects brings a crucial layer of hardware-based security. By using a Trusted Platform Module (TPM), wolfTPM ensures that all cryptographic operations are handled within a secure chip away from the prying eyes of software attackers. This setup is ideal for maintaining the confidentiality and integrity of your data.

Open Source and Community-Driven: As with all other open-source wolfSSL libraries, wolfTPM thrives on community input and collaboration. This transparency not only helps in enhancing its security capabilities but also keeps it at the forefront of technological and security advancements.

Broad Platform Support: The new support for Espressif ESP32 is another example of wolfTPM’s commitment to versatility across different platforms. This is especially valuable for those working on IoT devices or embedded systems that demand secure, flexible hardware integration options.

Ease of Integration: wolfTPM is designed with developers in mind, offering an intuitive API that makes it easy to add security features into your applications. Whether you’re highly experienced or just getting started in the world of hardware security, wolfTPM comes with all the documentation and support you’ll need to get up and running quickly.

Performance and Efficiency: wolfTPM is both economical and powerful in terms of resource use, making it ideal for the resource-limited environments that are typical of devices such as the ESP32. The library ensures your cryptographic operations are efficient and fast.

Real-World Use Cases: wolfTPM is built to secure a wide variety of applications – from smart home devices ensuring your privacy, to industrial machines that need to operate under stringent security and safety measures. The introduction of wolfTPM to the ESP32 allows for even more applications to benefit from trusted computing technologies.

Compliance and Certification: Using TPM technology with wolfTPM can ease the path to meeting rigorous security standards and compliance demands, critical for many businesses and industries.

Learn more about wolfTPM

Stay tuned for more announcements, as we’ll be also supplying wolfTPM support for the ESP32 as an Espressif Registry Managed Component, along with our existing wolfSSL, wolfSSH, and wolfMQTT components.

Do you want to take security to the next level on your ESP32 project? Let us help you take advantage of all the capabilities of TPM.

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us at facts@wolfSSL.com, +1 425 245 8247, or open an issue on GitHub.

[*1] – See https://github.com/wolfSSL/wolfTPM?tab=readme-ov-file#hardware
[*2] – Governments recognize the importance of TPM 2.0 through ISO adoption (June 29. 2015)
[*3] – Copied from the Infineon OPTIGA™ TPM SLB 9673 TPM2.0 Data Sheet
[*4] – Actual usable NV memory slightly less.

Download wolfSSL Now

Posts navigation

1 2 3 20 21 22 23 24 25 26 198 199 200