RECENT BLOG NEWS

Hardware Security Module (HSM)

A hardware security module (HSM) is a physical computing device that protects digital key management and key exchange, and performs encryption operations for digital signatures, authentication and other cryptographic functions. It can be thought of as a “trusted” network computer for performing cryptographic operations. A 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.

HSMs may have tamper evidence features such as visible signs of tampering, tamper resistance where tampering makes the HSM inoperable, or tamper responsiveness such as deleting keys upon tamper detection. Many HSM systems have secure backup systems, which allows keys to be backed up and stored on a computer disk or externally using a secure portable device. HSMs are usually certified to internationally recognized standards, such as FIPS 140, to provide independent assurance of sound design and implementation.

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.

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.

wolfSSL also supports PKCS#11, a HSM standard that defines an API for using cryptographic tokens. 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. TPM can also refer to a chip conforming to the standard. The standard was designed by the Trusted Computing Group, and TPM 2.0 is the most recent edition of the standard. 

TPM is used to:

• Securely create, store, and limit the use of cryptographic keys.
• Authenticate platform devices and encrypt data using the TPM’s unique RSA 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.

TPM technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element, 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. 

Secure Element/Hardware Root of Trust

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 without the standard TPM interface. Secure elements are unique in terms of interface.

A secure element is a tamper-resistant hardware platform, capable of securely hosting applications and storing confidential and cryptographic data. It provides a highly-secure environment that protects user credentials. Secure element features include:

• 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

The wolfTPM library provides APIs to access TPM 2.0 compatible secure elements. 

Conclusion

HSM, TPM, Secure Enclave, and Secure Element/Hardware Root of Trust all have the same function, which is to securely store keys, and securely execute cryptographic operations. The difference is that they’re all uniquely named. wolfSSL provides products that support all different schemes to best fit your cryptographic needs!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Love it? Star us on GitHub!

The latest release of wolfMQTT, v1.12.0, is now available! This release has several bug fixes and optimizations including:

• Allow MqttClient_WaitType to return MQTT_CODE_CONTINUE with MT (PR #283)
• Fix decoding user property and add example (PR #282)
• Fix issue with MqttClient_Publish_WriteOnly not waiting properly for ACK
  (PR #281)
• Fix MQTTv5 disconnect with props (PR #279)
• Add new publish write only API for multi-threading (PR #277)
• Fix for multithreaded cancel (PR #276)
• MQTT-SN Add disconnect_cb when disconnect recv from broker; Fix PUB ACK
  return status handling (PR #274)
• Enable TLS1.3 in examples (PR #273)
• Adding windows github actions build test (PR #272)

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

wolfSSL is holding an upcoming webinar on February 24th, 2022!  Join us for a comprehensive presentation on how to leverage wolfSSL for all of your automotive security needs. Our expert engineers will go through a variety of different use cases, stories, and examples, each with specific engineering details. Bring your questions for the Q&A session to follow!

Topic: Looking Under the Hood – Everything you need to know about automotive security that you’re too afraid to ask: wolfSSL Automotive Stories and Examples!

Watch the webinar here: Looking Under The Hood-wolfSSL Automotive Security

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

One of the reasons for wolfSSL ubiquity is its easiness to support a wide range of platforms, interfaces and hardware accelerations. Now wolfSSL makes another step in this direction supporting an additional cryptographic interface, the Platform Security Architecture (PSA) crypto API. This means that everything wolfSSL supports (DTLS 1.2, TLS 1.3, etc.) can now leverage the API exposed by a PSA capable system. To start experimenting take a look at https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/psa.

For a more hands-on approach feel free to check our examples, where you can find how to establish a TLS 1.3 connection on Trusted Firmware-M (https://github.com/wolfSSL/wolfssl-examples/tree/master/psa), the reference implementation for the PSA ecosystem. The example uses an STM32L5 NUCLEO-L552Ze-Q board.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We have been expanding wolfSSL’s use of NXPs CAAM (Cryptographic Acceleration and Assurance Module) on i.MX8 devices. Now it is able to use black keys with RSA operations on one of NXP’s Linux setups. To achieve this we expanded the current CAAM driver some and will post links and benchmarks shortly. Using black key’s with the CAAM are useful because they encrypt the private key and do not expose it to potentially malicious users. We are also one of the first to expand the CAAM driver for use with the new Curve25519 support. Curious how fast these operations run on the device?

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL has added support for nginx 1.21.4. nginx is a high-performance and high-concurrency web server capable of powering your website and more! wolfSSL is a SSL/TLS library that implements the TLS stack up to TLS 1.3 and DTLS 1.2.

Under the hood, we use the wolfCrypt library to provide FIPS 140-2 (soon to be 140-3) cryptography. Using wolfSSL/wolfCrypt, your web servers can become FIPS compliant! You also gain hardware support for many platforms and architectures.

Patches and instructions for using wolfSSL with nginx are publically available at https://github.com/wolfSSL/wolfssl-nginx. We currently have support for the following versions of nginx:

• Nginx 1.21.4
• Nginx 1.19.6
• Nginx 1.17.5
• Nginx 1.16.1
• Nginx 1.15.0
• Nginx 1.14.0
• Nginx 1.13.12
• Nginx 1.13.8
• Nginx 1.13.2
• Nginx 1.13.0
• Nginx 1.12.2
• Nginx 1.12.1
• Nginx 1.12.0
• Nginx 1.11.13
• Nginx 1.11.10
• Nginx 1.11.7
• Nginx 1.10.3
• Nginx 1.7.7

wolfSSL has updated support for the Apache HTTP Server. We have updated support for Apache httpd to version 2.4.51 in pull request #4658. wolfSSL is a SSL/TLS library that implements support for the latest TLS standards (TLS 1.3 and DTLS 1.2).

Apache is the most popular web server on the Internet since April 1996 that provides a secure, efficient and extensible web server. By building wolfSSL, you can leverage the full power of wolfCrypt. This includes hardware support for multiple platforms and architectures, FIPS 140-2 (soon 140-3) compliance for your FIPS needs, and the best tested cryptography on the market.

To build wolfSSL for Apache httpd, please configure wolfSSL with –enable-apachehttpd –enable-postauth. The patch and instructions for using Apache 2.4.51 with wolfSSL 5.1.0 can be found at https://github.com/wolfSSL/osp/tree/master/apache-httpd.

Vulnerabilities Fixed

• [High] A TLS v1.3 server who requires mutual authentication can be bypassed. If a malicious client does not send the certificate_verify message a client can connect without presenting a certificate even if the server requires one. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. CVE-2022-25640
•  [High] A TLS v1.3 client attempting to authenticate a TLS v1.3 server can have its certificate check bypassed. If the sig_algo in the certificate_verify message is different than the certificate message checking may be bypassed. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. CVE-2022-25638

New Feature Additions

• Example applications for Renesas RX72N with FreeRTOS+IoT
• Renesas FSP 3.5.0 support for RA6M3
• For TLS 1.3, improved checks on order of received messages.
• Support for use of SHA-3 cryptography instructions available in ARMv8.2-A architecture extensions. (For Apple M1)
• Support for use of SHA-512 cryptography instructions available in ARMv8.2-A architecture extensions.  (For Apple M1)
• Fixes for clang -Os on clang >= 12.0.0
• Expose Sequence Numbers so that Linux TLS (kTLS) can be configured
• Fix bug in TLSX_ALPN_ParseAndSet when using ALPN select callback.
• Allow DES3 with FIPS v5-dev.
• Include HMAC for deterministic ECC sign build
• Add –enable-chrony configure option. This sets build options needed to build the Chrony NTP (Network Time Protocol) service.
• Add support for STM32U575xx boards.
• Fixes for NXP’s SE050 Ed25519/Curve25519.
• TLS: Secure renegotiation info on by default for compatibility.
• Inline C code version of ARM32 assembly for cryptographic algorithms available and compiling for improved performance on ARM platforms
• Configure HMAC: define NO_HMAC to disable HMAC (default: enabled)
• ISO-TP transport layer support added to wolfio for TLS over CAN Bus
• Fix initialization bug in SiLabs AES support
• Domain and IP check is only performed on leaf certificates

ARM PSA Support (Platform Security Architecture) API

• Initial support added for ARM’s Platform Security Architecture (PSA) API in wolfCrypt which allows support of ARM PSA enabled devices by wolfSSL, wolfSSH, and wolfBoot and wolfCrypt FIPS.
• Included algorithms: ECDSA, ECDH, HKDF, AES, SHA1, SHA256, SHA224, RNG

ECICE Updates

• Support for more encryption algorithms: AES-256-CBC, AES-128-CTR, AES-256-CTR
• Support for compressed public keys in messages.

Math Improvements

• Improved performance of X448 and Ed448 through inlining Karatsuba in square and multiplication operations for 128-bit implementation (64-bit platforms with 128-bit type support).
• SP Math C implementation: fix for corner case in curve specific implementations of Montgomery Reduction (P-256, P-384).
• SP math all: assembly snippets added for ARM Thumb. Performance improvement on platform.
• SP math all: ARM64/32 sp_div_word assembly snippets added to remove dependency on __udiv3.
• SP C implementation: multiplication of two signed types with overflow is undefined in C. Now cast to unsigned type before multiplication is performed.
• SP C implementation correctly builds when using CFLAG: -m32

OpenSSL Compatibility Layer

• Added DH_get_2048_256 to compatibility layer.
• wolfSSLeay_version now returns the version of wolfSSL
• Added C++ exports for API’s in wolfssl/openssl/crypto.h. This allows better compatibility when building with a C++ compiler.
• Fix for OpenSSL x509_NAME_hash mismatch
• Implement FIPS_mode and FIPS_mode_set in the compat layer.
• Fix for certreq and certgen options with openssl compatibility
• wolfSSL_BIO_dump() and wolfSSL_OBJ_obj2txt() rework
• Fix IV length bug in EVP AES-GCM code.
• Add new ASN1_INTEGER compatibility functions.
• Fix wolfSSL_PEM_X509_INFO_read with NO_FILESYSTEM

CMake Updates

• Check for valid override values.
• Add `KEYGEN` option.
• Cleanup help messages.
• Add options to support wolfTPM.

VisualStudio Updates

• Remove deprecated VS solution
• Fix VS unreachable code warning

New Algorithms and Protocols

• AES-SIV (RFC 5297)
• DTLS SRTP (RFC 5764), used with WebRTC to agree on profile for new real-time session keys
• SipHash MAC/PRF for hash tables. Includes inline assembly for x86_64 and Aarch64.

Remove Obsolete Algorithms

• IDEA
• Rabbit
• HC-128

Here at wolfSSL, we love doing integrations. 

What you might not know about Mozilla’s Firefox and NSS is that all of the cryptography happens underneath their PKCS#11 layer which is a software component called the “NSS Internal PKCS #11 Module”. It has a “Software Security Device.” As you can see in the user interface screenshot above, “wolfPKCS11” has “wolfSSL HSM slot ID 01” and has been loaded in Mozilla Firefox’s Security Device Manager. You can find wolfPKCS11 at https://github.com/wolfSSL/wolfPKCS11/ . It primarily replaces the underlying authentication implementations with those found in wolfCrypt.

What does this mean in terms of FIPS 140-2/3? It means that if you are running Firefox in an environment that requires FIPS assurances, you can swap in wolfSSL and meet the requirement!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Join us to hear from cURL founder and lead developer Daniel Stenberg,  and learn about the cURL roadmap for 2022. Tune in to learn about the topics that he and wolfSSL plan to work on over the year and potential ideas that they are considering. As always, bring your questions for the Q&A session at the end!

Topic: cURL 2022 Roadmap

Watch the webinar here: cURL 2022 Roadmap

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.