Month: November 2023

The wolfSSL implementation of DTLS 1.3 supports Early Data or 0-RTT Data. Early Data is application data that can be sent by the client with the very first ClientHello message. It is also called 0-RTT Data because it requires 0 Round Trip Time before application data can be sent. To utilize Early Data in DTLS 1.3, the server needs to omit the cookie exchange when using a PSK connection. The handshake using Early Data is presented in the following figure.

	Client                                      	Server
    	ClientHello
    	+ early_data
    	+ key_share
    	+ psk_key_exchange_modes
    	+ pre_shared_key
    	Early Data       	      -------->
                                                    	ServerHello
                                               	      + pre_shared_key
                                                   	+ key_share
                                                      EncryptedExtensions
                                                  	+ early_data
                                                     	Finished
                            	<--------   	      Application Data
    	EndOfEarlyData
    	Finished          	-------->
    	Application Data  	<------->    	      Application Data

To use DTLS 1.3 Early Data in wolfSSL without the cookie exchange, the server needs to be modified:

• Compile wolfSSL with WOLFSSL_DTLS13_NO_HRR_ON_RESUME defined
  • When compiling with configure add CPPFLAGS=-DWOLFSSL_DTLS13_NO_HRR_ON_RESUME
  • When compiling with user settings add #define WOLFSSL_DTLS13_NO_HRR_ON_RESUME
• Call wolfSSL_dtls13_no_hrr_on_resume(ssl, 1) on the WOLFSSL object to disable the cookie exchange on resumption
• Continue like with a normal connection

Early Data is protected by using the cipher material associated with the PSK (pre-shared key). This can either be the cipher material of the previous connection when using a ticket or out-of-band cipher material when using a real PSK. As a result of using previous cipher material, Early Data can compromise PFS (Perfect Forward Secrecy).

For any questions about DTLS 1.3 and Early Data in wolfSSL, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

We at wolfSSL are continuously improving performance of the wolfCrypt code. Recently we took a look at our AES-GCM on Aarch64 and thought: we can do better.

By using the cryptographic instructions built into Aarch64 chips we had already gotten a significant boost over straight C but we saw that we could do more. By unrolling loops, interleaving the GCM calculation with AES encryption and using NEON as well as the base instructions at the same time, we were able to see a significant improvement!

How significant? Up to 9.5 times faster! The wolfSSL 5.6.4 numbers on an Apple M1 were:

------------------------------------------------------------------------------
 wolfSSL version 5.6.4
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-GCM-enc           1845 MB took 1.000 seconds, 1845.382 MB/s
AES-128-GCM-dec            907 MB took 1.005 seconds,  902.210 MB/s
AES-192-GCM-enc           1845 MB took 1.002 seconds, 1842.527 MB/s
AES-192-GCM-dec            902 MB took 1.002 seconds,  900.038 MB/s
AES-256-GCM-enc           1845 MB took 1.000 seconds, 1844.793 MB/s
AES-256-GCM-dec            897 MB took 1.001 seconds,  895.873 MB/s
Benchmark complete

And now with the new assembly code:

------------------------------------------------------------------------------
 wolfSSL version master
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-GCM-enc           8583 MB took 1.000 seconds, 8580.862 MB/s
AES-128-GCM-dec           8583 MB took 1.000 seconds, 8580.389 MB/s
AES-192-GCM-enc           7875 MB took 1.001 seconds, 7870.179 MB/s
AES-192-GCM-dec           7922 MB took 1.000 seconds, 7921.097 MB/s
AES-256-GCM-enc           7067 MB took 1.000 seconds, 7064.394 MB/s
AES-256-GCM-dec           7230 MB took 1.001 seconds, 7225.034 MB/s
Benchmark complete

Try it out and you will see that the encryption and decryption of TLS packets will appear insignificant.

Are there other algorithms on Aarch64 whose performance you would like to see us improve? Let us know!

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

wolfEntropy, a software-based entropy source developed by the wolfSSL team, leverages timing jitter variations in memory accesses across various cache levels to generate entropy. It has been available since wolfSSL v5.5.4, and support for Windows has been introduced. This eliminates the need for hardware redesign to incorporate a hardware-based entropy source.
The first general purpose high performance software entropy source is available now!

It is designed to fully conform with SP800-90B. The SP800-90B is a publication by the National Institute of Standards and Technology (NIST) that specifies the requirements for entropy sources used in cryptographic applications.

The wolfEntropy library source is undergoing testing to meet the criteria of a certified entropy source as outlined in the publication. It will soon proceed through the FIPS Entropy Source Validation (ESV) process.

The design of wolfEntropy is depicted in this figure:

When dealing with Unix-style systems that employ autoconf/autotools for configuring the wolfCrypt cryptographic module and integrating wolfEntropy as a component, you need to adhere to these basic configuration prerequisites:

Using Auto-tools:

./configure –enable-entropy-memuse=nofallback

Enabling the nofallback feature is crucial in this context. It restricts the system from using any other entropy source apart from wolfEntropy, even if wolfEntropy experiences a failure in any of its health tests. This strict condition ensures SP800-90B compliance.

For Windows and systems using user_settings.h to fine-tune the wolfCrypt cryptographic module along with wolfEntropy as a component, you can configure your CFLAGS with the following options:

CFLAGS=”-DHAVE_ENTROPY_MEMUSE -DWOLFSSL_SHA3 -DENTROPY_MEMUSE_FORCE_FAILURE”

Much like the Unix-style systems, the ENTROPY_MEMUSE_FORCE_FAILURE option is pivotal. It disables the use of any other entropy source, allowing only wolfEntropy to be utilized. This adherence to ENTROPY_MEMUSE_FORCE_FAILURE ensures SP800-90B compliance.

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

Join us on an informative webinar about wolfSSL and Automotive Hardware Security Modules (HSMs) presented by wolfSSL Software Engineer, Bill, on November 30th at 10 am PT. In today’s automotive landscape, vehicles have transformed into sophisticated digital systems, making automotive cybersecurity a paramount concern.

During this webinar, Bill will delve into the world of HSMs and explore how wolfSSL is dedicated to safeguarding data in connected vehicles.

Watch the webinar here: wolfSSL and Automotive Hardware Security Modules (HSMs)

Sneak peek of the webinar

• Automotive HSM Features and benefits
• Exploring wolfHSM Functional Design
• wolfHSM Applicability to Standards
• wolfHSM Hardware Ports and Plans
• wolfHSM Demo on Infineon Aurix Tricore TC3xx
• Future Targets of wolfHSM technology
• And much more

Don’t miss this opportunity to expand your knowledge and technical skills in Automotive HSMs. Discover the full potential that wolfSSL products can offer and how wolfSSL products enhance automotive security. Bring all your questions related to Automotive HSMs and get ready to learn insights on automotive HSMS from Bill.

Watch it now!

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

As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.

Today we are about to release our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future.

This is really great news for our customers selling into Chinese markets!

For those readers considering using wolfSSL products, here’s some additional notes:

• The SM Ciphers will be fully supported in wolfSSL’s TLS 1.3 implementation.
• wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
• ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance.
• We will continue to support bare metal for ZUC, SM2, SM3, and SM4.
• True to form, we have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
• Our GPLv2 licensed versions of the SM ciphers will be made available on GitHub and for download.

Commercially licensed versions are available.

If you have questions about our support for the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com, or call us at +1 425 245 8247.

Download wolfSSL Now

In WolfSSL release v5.6.4 we have added support for Silicon Labs’ Simplicity Studio. In addition we have tested with the ERF32xG21 series of chips and have created an example setup. More information can be found in the WolfSSL repo.

Using our benchmarking tool, we have the following results from a Cortex M33 at 80MHz:

wolfCrypt Benchmark	(block bytes 1024, min 1.0 sec each)
RNG	200 KiB took 1.057 seconds	189.215 KiB/s
AES-128-CBC-enc	6 MiB took 1.000 seconds	5.542 MiB/s
AES-128-CBC-dec	6 MiB took 1.000 seconds	5.518 MiB/s
AES-192-CBC-enc	5 MiB took 1.001 seconds	5.415 MiB/s
AES-192-CBC-dec	5 MiB took 1.001 seconds	5.390 MiB/s
AES-256-CBC-enc	5 MiB took 1.004 seconds	5.301 MiB/s
AES-256-CBC-dec	5 MiB took 1.001 seconds	5.268 MiB/s
AES-128-GCM-enc	5 MiB took 1.003 seconds	4.844 MiB/s
AES-128-GCM-dec	5 MiB took 1.003 seconds	4.625 MiB/s
AES-192-GCM-enc	5 MiB took 1.002 seconds	4.751 MiB/s
AES-192-GCM-dec	5 MiB took 1.002 seconds	4.532 MiB/s
AES-256-GCM-enc	5 MiB took 1.002 seconds	4.654 MiB/s
AES-256-GCM-dec	4 MiB took 1.000 seconds	4.443 MiB/s
AES-128-GCM-enc-no_AAD	5 MiB took 1.004 seconds	4.888 MiB/s
AES-128-GCM-dec-no_AAD	5 MiB took 1.001 seconds	4.658 MiB/s
AES-192-GCM-enc-no_AAD	5 MiB took 1.000 seconds	4.785 MiB/s
AES-192-GCM-dec-no_AAD	5 MiB took 1.000 seconds	4.565 MiB/s
AES-256-GCM-enc-no_AAD	5 MiB took 1.004 seconds	4.693 MiB/s
AES-256-GCM-dec-no_AAD	4 MiB took 1.003 seconds	4.479 MiB/s
GMAC Small	5 MiB took 1.000 seconds	4.653 MiB/s
CHACHA	2 MiB took 1.012 seconds	1.809 MiB/s
CHA-POLY	1 MiB took 1.006 seconds	1.189 MiB/s
POLY1305	5 MiB took 1.004 seconds	5.082 MiB/s
SHA	8 MiB took 1.000 seconds	7.812 MiB/s
SHA-256	8 MiB took 1.000 seconds	8.032 MiB/s
HMAC-SHA	7 MiB took 1.000 seconds	7.056 MiB/s
HMAC-SHA256	7 MiB took 1.002 seconds	7.237 MiB/s
RSA 2048 public	30 ops took 1.022 sec	avg 34.067 ms	29.354 ops/sec
RSA 2048 private	2 ops took 2.398 sec	avg 1199.000 ms	0.834 ops/sec
ECC [SECP256R1] 256 key gen	172 ops took 1.004 sec	avg 5.837 ms	171.315 ops/sec
ECDHE [SECP256R1] 256 agree	186 ops took 1.005 sec	avg 5.403 ms	185.075 ops/sec
ECDSA [SECP256R1] 256 sign	174 ops took 1.007 sec	avg 5.787 ms	172.790 ops/sec
ECDSA [SECP256R1] 256 verify	160 ops took 1.003 sec	avg 6.269 ms	159.521 ops/sec

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

Download wolfSSL Now

Designed by Freepik: www.freepik.com

Here at wolfSSL, we pride ourselves on the portability of our products. An essential part of the real-world applicability of our projects is that they can run in various environments in support of various use cases. We recently published an incomplete list of parts that our SSL/TLS library wolfSSL has been run on. Since our secure bootloader wolfBoot shares the same flexibility, we wanted to share a similar list of supported targets and architectures.

Here’s a list of supported CPU architectures:

CPU Architectures

ARMv6-M Cortex-M0

ARMv7-A Cortex-A9

ARMv7-M Cortex-M3

ARMv7-M Cortex-M4

ARMv7-M Cortex-M7

ARMv7-R Cortex-R5

ARMv8-A Cortex-A53

ARMv8-A Cortex-A57

ARMv8-M Cortex-M33

PowerPC 32-Bit

PowerPC 64-Bit

RV32 32-Bit RISC-V

Intel x86 32-Bit

Intel x86 64-Bit

RXv3 core

Here’s a list of supported hardware parts and their manufacturers:

Part	Manufacturer
Xilinx UltraScale+ ZCU102	AMD
PSoC 62S2	Infineon/Cypress
i.MX-RT1050	NXP/Freescale
i.MX-RT1060	NXP/Freescale
i.MX-RT1064	NXP/Freescale
Kinetis K64	NXP/Freescale
Kinetis K82	NXP/Freescale
QorIQ P1021	NXP/Freescale
QorIQ T1024	NXP/Freescale
QorIQ T2080	NXP/Freescale
QorIQ LS1028A	NXP/Freescale
LPC54xxxx	NXP/Freescale
nRF5280	Nordic
11th Gen Core i7 (Tiger Lake)	Intel
PI3	RaspberryPi
RX72N	Renesas
RA6M4	Renesas
STM32C0xx	ST Microelectronics
STM32F4xx	ST Microelectronics
STM32F7xx	ST Microelectronics
STM32G0xx	ST Microelectronics
STM32H7xx	ST Microelectronics
STM32L0xx	ST Microelectronics
STM32L4xx	ST Microelectronics
STM32L5xx	ST Microelectronics
STM32U5xx	ST Microelectronics
STM32WBxx	ST Microelectronics
HiFive1	SiFive (RISC-V)
ATSAMR21	Microchip (Atmel)
TM4C1294xx	Texas Instruments
TMS570lc4xx	Texas Instruments
CC26x2	Texas Instruments

For info on the wolfBoot configuration details of the targets listed above, visit https://github.com/wolfSSL/wolfBoot/blob/master/docs/Targets.md. For wolfBoot usage examples, visit https://github.com/wolfSSL/wolfBoot-examples.

Don’t see your part/architecture on this list? Not to worry! The minimalistic design and tiny HAL API of wolfBoot make it portable to the highest degree. Reach out to us letting us know the details of your system and we can get you in touch with our porting experts.

If you have questions, comments, and suggestions about any of the above, contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Designed by Freepik: www.freepik.com

Have you seen the recently released wolfBoot v2.0.0? It is full of a lot of interesting new features and optimizations. You can see full detail in the changelog.

What about the CNSA 2.0 Guidance? We’ve mentioned it many times in our blog posts. You can find it here.

You might be wondering, what do these have to do with each other? The NSA’s CNSA 2.0 guidance specifically states that LMS/HSS and XMSS/XMSS^MT are appropriate for firmware signing. These algorithms are now supported in the 2.0.0 release of wolfBoot. They depend on our LMS and XMSS integrations in wolfCrypt which are part of the recently released 5.6.4 version of wolfSSL! So, you can start working with these algorithms and signing and verifying your firmware images TODAY.

Being able to do that today is really important because the CNSA 2.0 says that LMS/HSS and XMSS/XMSS^MT are to be added as an option and tested in your systems and products today. By 2025, only a year from now, these algorithms are to be the default and preferred algorithms. By 2030, all other algorithms are to be phased out.

Are you ready to meet these expectations? You are if you use wolfBoot!

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

When looking to store your cryptographic secrets, it is important to have a good platform to store them on. Even more important is the ease of accessing and using those secrets. With wolfTPM, we have already added support for the following platforms:

• Raspberry Pi (Linux)
• MMIO (Memory mapped IO)
• STM32 with CubeMX
• Atmel ASF
• Xilinx (Ultrascale+ / Microblaze)
• QNX
• Infineon TriCore (TC2xx/TC3xx)
• Barebox

These TPM (Trusted Platform Module) 2.0 modules are tested and running in the field:

• STM ST33TP* SPI/I2C
• Infineon OPTIGA SLB9670/SLB9672
• Microchip ATTPM20
• Nations Tech Z32H330TC
• Nuvoton NPCT650/NPCT750

For direct Secure Element access, we have ports in wolfSSL for:

• ST-SAFE
• Microchip ATECC508/608
• Microchip TA100
• NXP SE050

Wolfcrypt has support for the following:

• NXP CAAM (Cryptographic Acceleration and Assurance Module) on i.MX6 (QNX), i.MX8 (QNX/Linux), RT1170 FreeRTOS
• Intel SGX
• ARM TrustZone CryptoCell 310

For more detailed information on our supported hardware take a look at our Hardware Support list.

We also offer support for PKCS11 to interface to various HSMs like:

• Infineon TriCore Aurix
• Renesas RH850
• ST SPC58

Wolfcrypt also gives support for PSA (Platform Security Architecture). This includes the following algorithms:

• hashes: SHA-1, SHA-224, SHA-256
• AES: AES-ECB, AES-CBC, AES-CTR, AES-GCM, AES-CCM
• ECDH PK callbacks (P-256)
• ECDSA PK callbacks (P-256)
• RNG

Another product of interest could be wolfBoot, which – as the name suggests – is a bootloader that can use an HSM (Hardware Security Module) for validation and verification. It supports use of the ARM TrustZone technology. WolfBoot also supports all of the TPMs and secure elements listed above, as it inherits all of wolfCrypt’s capabilities. WolfBoot can also be used in an fTPM (Firmware TPM) environment where the bootloader code is running on the same device as the one providing TPM functionality.

Check out the latest updates on the keystores and secure elements supported by wolfSSL.

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

Download wolfSSL Now

wolfSSL is proud to partner with Weston Embedded Solutions, developers of the Cesium RTOS line of real time kernels and protocol stacks for embedded systems. Weston Embedded Solutions and their products trace their roots back to Micrium and the popular uC/OS software that pioneered the use of real time kernels more than 30 years ago. Cesium RTOS is popular among customers demanding real time performance and proven reliability in the most critical embedded applications. This partnership allows wolfSSL to broaden its portfolio of supported real time operating systems giving customers integrated access to the most reliable and trusted embedded kernels and middleware components.

The combination of wolfSSL’s state-of-the-art SSL/TLS library and Weston Embedded Solutions’ highly reliable Cesium RTOS provide a level of protection that is simply unmatched in the industry. Customers can now enjoy enhanced security and performance, reduced development time, and increased flexibility in their embedded systems.

The ultra configurability of wolfSSL will let you make the optimizations and trade offs that make the most sense for you. Whether your application requires a small code size, no stack usage, no heap usage, minimal memory usage or blazing performance, wolfSSL and Weston Embedded Solutions will get you where you need to be.

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