RECENT BLOG NEWS

We are excited to announce the release of v2.2.0 for wolfTPM. This release adds several new examples such as remote attestation, seal/unseal and GPIO control. There are minor fixes for authenticated sessions. A few coding refactors to improve readability and reliability. We also added endorsement hierarchy support to several examples. If you are using QNX then you will appreciate the built-in HAL SPI driver support.

• Fix for using multiple authenticated sessions.
• Added QNX support.
• Added new examples for remote attestation (make / activate credential).
• Added GPIO support and examples for ST33 and Nuvoton NPCT75x modules.
• Added new example for sealing a secret using TPM key.
• Added Endorsement Hierarchy support to many examples.
• Added missing TPM2_CreateLoaded and wrapper.
• Refactored the reference HAL IO code into separate files.
• Refactor of the TPM IO code to separate files.
• Refactor the assignment of structs to use memcpy to avoid alignment issues.
• Documentation improvements for API’s with Doxygen, QEMU and Windows TBS.

For a detailed list of changes see our ChangeLog.md here:
https://github.com/wolfSSL/wolfTPM/blob/master/ChangeLog.md#wolftpm-release-22-07132021

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

Pseudo Random Number Generator (PRNG)

Software-generated random numbers only are pseudorandom. They are not truly random because the computer uses an algorithm based on a distribution, and are not secure because they rely on deterministic, predictable algorithms. Since a seed number can be set to replicate the “random” numbers generated, it is possible to predict the numbers if the seed is known. Pseudorandom number generation in everyday tools such as Python and Excel are based on the Mersenne Twister algorithm. 

An example use of PRNGs is in key stream generation. Stream ciphers, such as Chacha, encrypt plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Keystreams of some block cipher modes, such as AES CTR (counter) mode, act as a stream cipher and can also be regarded as pseudorandom number generation.

True Random Number Generator (TRNG)

For truly random numbers, the computer must use some external physical variable that is unpredictable, such as radioactive decay of isotopes or airwave static, rather than by an algorithm. At the quantum level, subatomic particles have completely random behavior, making them ideal variables of an unpredictable system. Most higher end microcontrollers have TRNG sources, which wolfSSL can use as a direct random source or as a seed for our PRNG. Intel RDRAND, a silicon-based TRNG, is supported by wolfSSL.

Additionally, wolfSSL supports the following hardware systems involving TRNGs:

• Espressif ESP32-WROOM-32
• Intel SGX
• Microchip ATECC608
• Microchip PIC32MZ
• Nordic nRF5x
• NXP i.MX6 CAAM
• NXP i.MX RT1060
• NXP Kinetis and KSDK
• Renesas TSIP
• Silicon Labs SE
• STM32
• Telit M2MB
• Whitewood Quantum RNG
• Windows CryptGenRandom

You can find the full list of all hardware acceleration/cryptography platforms currently supported by wolfSSL here: Hardware Cryptography Support

RNGs in cryptography

However, true RNGs on their own are often not cost efficient, and can be subject to gradual decline. Thus, there is still some reliance on post-processing algorithms (that are deterministic and vulnerable) to further improve randomness, as the quality of their entropy source is not consistent. The combination of a TRNG and a PRNG can limit the negative effects of this decline. For example, in NXP i.MX RT1060, the TRNG present in the core can be used as an entropy source to determine the seed of a Deterministic Random Bit Generator (DRBG), which on its own is a PRNG, but in combination with the TRNG results in a good approximation of randomness, without weakness over time. 

wolfSSL uses the SHA2-256 (Secure Hash Algorithm) Hash_DRBG described in NIST’s SP 800-90A (the specification for three allegedly cryptographically secure pseudorandom number generators for use in cryptography). Additionally, wolfRand, wolfSSL’s FIPS module which includes a hardware entropy source, is conformant to NIST’s SP 800-90B (the design principles and requirements for the entropy sources used by random-bit generators, and the tests for the validation of entropy sources).

For cryptographic purposes, a more secure approximation of a true random number can be achieved with a combination of algorithms, rather than just relying on one. In the update from TLS 1.1 to TLS 1.2, the MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs, which continue to be used in TLS 1.3 with SHA2-256 and SHA2-384. 

MD5/SHA-1 (Message Digest/Secure Hash Algorithm) combined two Message Authentication Code (MAC) algorithms to provide a balance between speed and security. Meanwhile, a cipher suite is a set of cryptographic instructions or algorithms that helps secure network connections through Transport Layer Security(TLS)/Secure Socket Layer (SSL). During the SSL handshake between the web server and the client, the two parties agree on a cipher suite, which is then used to secure the HTTPS connection. A typical cipher suite contains 1 key exchange, 1 bulk encryption, 1 authentication, and 1 MAC algorithm. 

For more information on cipher suites and their uses, visit “What is a Cipher Suite?”

Conclusion

Truly random numbers are difficult to generate because they are not cost-efficient and subject to decline over time. However, random number generation can be made more effective by using multiple random processes in combination, either with a TRNG/PRNG combination, or an ensemble of algorithms in a cipher suite.

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

wolfTPM is the leading TPM library for embedded and baremetal applications. It is widely used in aerospace, military, and medical systems because the wolfSSL TPM 2.0 library is designed specifically for embedded systems. wolfTPM offers a low memory footprint and supports all of the TPM 2.0 commands and operations; as well as provids examples of: attestation, NVRAM usage, secure storage, and sealing.

Today, we have expanded on the new  TPM 2.0 feature called Extra GPIO, by adding support for the newest variant of NPCT75x modules by Nuvoton.

It is now possible to protect and control GPIO by using TPM 2.0 authorization. This way, extra GPIO on the TPM chip becomes a great tool for signaling of critical events across subsystems.

Since, wolfTPM already offers support for extra GPIO for ST33 modules from STMicroelectronics. Here is a brief comparison of the GPIO capabilities between ST33 and NPCT75x :

In safety-critical systems, extra GPIO control through the TPM 2.0 module provides signaling for security events and important changes of the system state. Such use cases are observed in the rising railway IoT automation and in modern automotive systems.

We want to thank the team at Nuvoton led by Mr. Oren and the amazing field application engineer Ms. Dana for collaborating on this project.

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

The wolfMQTT client library “mqttclient” example demonstrates securely connecting over TLS provided by wolfSSL.

We set up a HiveMQ Cloud cluster that can be used for testing. The HiveMQ Cloud broker uses the Server Name Indicator (SNI) extension for TLS client authentication, which is specified using the `-S ` option. The example is located in `/examples/mqttclient/`. You can test with our HiveMQ Cloud cluster using:

./examples/mqttclient/mqttclient -h 833f87e253304692bd2b911f0c18dba1.s1.eu.hivemq.cloud -t -S -u wolf1 -w NEZjcm7i8eRjFKF -p 8883

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that! Secure-IoT-Love from the wolfSSL team!

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

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

Don’t forget to add a star while you’re there!

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 are adding hardware security to wolfSSH to meet the rising security requirements for connected systems.

Thanks to the widely available Trusted Platform Module (TPM) and our portable wolfTPM library, wolfSSH can have the user’s private SSH key stored and used directly from a hardware security module. This way the private key material is never exposed in raw form and the system has physical tamper-proof protection of its important secrets.

wolfSSH is a portable SSH v2.0 client and server. It also supports the SCP and SFTP protocols. This makes wolfSSH a preferred choice for embedded systems and applications. 

wolfTPM is a portable TPM 2.0 library, designed for baremetal and embedded systems. wolfTPM has its own TPM Interface Layer (TIS) developed in accordance with the Trusted Computing Group Group (TCG). This allows wolfTPM to operate in every operating environment, because it does not require a TPM driver.

For information on our wolfSSH capabilities see https://www.wolfssl.com/products/wolfssh/.

Do you want to use SSH with hardware protected keys?

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

The QSslSocket class in Qt makes it easy to add encryption to your application. wolfSSL makes it secure!

The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set.  It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross-platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2 levels, is up to 20 times smaller than OpenSSL, supports FIPS, and has critical interfaces like TPM 2.0 and  PKCS#11.

Qt has traditionally used OpenSSL as the provider for SSL/TLS in Qt Network for secure network communications. wolfSSL 4.4.0 adds support for building Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend! The wolfSSL integration with Qt provides a performance-minded alternative, ideal for Qt developers who are looking for a lightweight, progressive, and well-tested SSL/TLS implementation.  

Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry.  Some of these may include:

• Progressive SSL/TLS protocol support (up to TLS 1.3)
• Smaller footprint size (up to 20 times smaller than OpenSSL)
• Extensive testing to reduce bugs and vulnerabilities (currently the best-tested SSL/TLS implementation available)
• Certifications (FIPS 140-2, DO-178C)
• Portability (supports over 30 operating systems)
• Hardware cryptography support
• Commercial support
• Consulting services and training available

To learn more about the advantages of using wolfSSL, visit our page on “wolfSSL vs. OpenSSL”. For more insight into building Qt with wolfSSL, the advantages it brings to Qt developers when used in place of OpenSSL, and the current state of SSL/TLS and the cryptography algorithms used, watch this recorded talk by our Engineering Manager, Chris Conlon. 

For instructions on how to compile Qt with the wolfSSL patch, please visit Building Qt with wolfSSL. 

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

The 200th curl release found 3 major security advisories from the curl bug-bounty program. These are the advisories:

• CVE-2021-22901: TLS session caching disaster

This is a Use-After-Free in the OpenSSL backend code that in the absolutely worst case can lead to an RCE, a Remote Code Execution. The flaw is reasonably recently added and it’s very hard to exploit but you should upgrade or patch immediately.

The issue occurs when TLS session related info is sent from the TLS server when the transfer that previously used it is already done and gone.

• CVE-2021-22898: TELNET stack contents disclosure

When libcurl accepts custom TELNET options to send to the server, it the input parser was flawed which could be exploited to have libcurl instead send contents from the stack.

• CVE-2021-22897: schannel cipher selection surprise

In the Schannel backend code, the selected cipher for a transfer done with was stored in a static variable. This caused one transfer’s choice to weaken the choice for a single set transfer could unknowingly affect other connections to a lower security grade than intended.

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 are integrating wolfTPM into U-Boot. This will extend the TPM 2.0 capabilities in U-Boot to include signature verification and measured boot.

For many platforms we can replace U-Boot such as on the Xilinx UltraScale+ MPSoC.

Our wolfBoot allows many features including:
* Partition signature verification using ED25519, RSA and ECC
* Encryption of partitions
* Updating of partitions in the boot loader
* Measured boot with TPM 2.0 PCR registers
* Offloading to crypto coprocessors like the TPM 2.0 modules
* Version checking for updates
* Rollback on failed updates

For information on our wolfBoot TPM integration see https://www.wolfssl.com/products/wolfboot/.

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

Connect with wolfSSL:
Twitter
LinkedIn
Facebook

Our first preview release of wolfSentry, the IDPS (Intrusion Detection and Prevention System) for embedded and IoT systems, has platform support for Raspberry Pi, STM32 with CubeMX, Atmel ASF and Barebox. As well as native support for Microsoft Windows and Linux.

Here at wolfSSL we are always striving to be better so we would love to hear which operating environments and platforms you would like to see supported by wolfSentry.

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 fans! Do you like FIPS? Do you like virtual machines? Guess what. wolfSSL`s crypto library, wolfCrypt, is validated for FIPS 140-2 and in the process of being one of the first cryptography libraries to be validated for FIPS 140-3. 

As wolfCrypt is commonly used in standard operating environments because of its royalty-free pricing and excellent cross platform support, wolfCrypt FIPS has been validated on a number of Operating Environments (OEs). The current validated OE list for both wolfCrypt FIPS certificates (#2425 and #3389) are listed here for reference.  

Certificate #2425 Current OE List:

Certificate #3389 Current OE List:

wolfSSL can easily add additional OEs to existing wolfCrypt FIPS certificates.

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