Month: July 2021

True Random vs. Pseudorandom Number Generation

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:

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.

For more information on wolfRand or general inquiries about wolfSSL, contact us at facts@wolfssl.com! 

wolfTPM first to support Nuvoton NPCT75x extra GPIO for safety-critical applications

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 :

Manufacturer Model Extra GPIO availability GPIO modes
Nuvoton NPCT75x 2 GPIO for SPI & I2C 3 output modes
STMicroelectronics ST33 2 GPIO for SPI
4 GPIO for I2C		 6 modes in total

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 want to use TPM 2.0 and secure GPIO signaling in your next project please contact us at facts@wolfssl.com

wolfMQTT Client Supports HiveMQ Cloud

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!  Contact us at facts@wolfssl.com with any questions or for help using wolfMQTT in your project!

Embedded SSH client with TPM protected keys

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? Please email us at facts@wolfssl.com. 

Integration update: wolfSSL is the Secure Socket Solution for Qt

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:

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. 

Questions? Reach out to our support team at support@wolfssl.com!

cURL Security Advisories

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

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.

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.

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.

Posts navigation

1 2