Category: Uncategorized

Benchmark values of the wolfSSL embedded SSL/TLS library running on Xilinx boards, including the ZCU102, have been collected and are up for viewing. Our friends over at Xilinx have a white paper posted that goes into detail about the benchmark values here: https://www.xilinx.com/support/documentation/white_papers/wp512-accel-crypto.pdf. This shows how much faster applications can perform secure operations when incorporating the hardware acceleration available on Xilinx devices. It also gives a demonstration of the performance trade-offs when choosing FreeRTOS versus an embedded Linux OS.

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

Most bootloaders do not use hardware acceleration and cryptography.

wolfSSL’s wolfBoot is an exception.

wolfBoot can use Secure Elements, such as ATECC508A. Thanks to integration with wolfTPM, wolfBoot can also leverage TPM 2.0, such as STMicroelectronics ST33, Infineon SLB9670, Nuvoton NPC750 and other TPM modules.

Thanks to wolfSSL’s cryptographic engine, wolfBoot can take advantage of the hardware acceleration for cryptography operations of many embedded and server platforms. Here are highlights of our platforms support list:

Manufacture Vendor	Platform
STMicroelectronics	STM32F1 / F2 / F4 / L1 / WB / F7 / H7 STM32L5 (with Trustzone support)
NXP	Kinetis K50 / K60 / K70 / K80
NXP	RT 1060 with DCP support, and LPC54xxx
NXP	iMX6 iMX7 iMX8 with CCAM support
Microchip	PIC32, MX and MZ series
Microchip (Atmel)	SAM R21
Cypress	PSoC6
Texas Instruments	TM4C1294 (ARM Cortex-M4F)
SiFive (RISC-V)	FE310 / HiFive1
Marvell (CAVIUM)	NITROX V, NITROX III
XILINX	Zynq UltraScale+
Intel and AMD x86	AES-NI, AVX1 / AVX2, RDRAND / RDSEED

wolfBoot is a solution for firmware update and authentication that can take advantage of your platform’s hardware acceleration and cryptography. This way we achieve a small memory footprint and high performance during secure updates over the air(OTA).

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

Hi! We continue to make progress on our upcoming FIPS 140-3 certification. We have now completed code review, and are working with our lab on operational testing. The process will be in NIST’s hands after that. Our goal is to be the first software cryptographic library with a FIPS 140-3 certification, and that looks like it is on track!

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

For more information on wolfCrypt’s previous 140-2 certificates, visit our FIPS page here.

In wolfSSL release 4.7, the Linux kernel module implementation has been enhanced to use kvmalloc() and kvfree() for heap-based storage. The typical approach using kmalloc() allocates physically contiguous memory, with meaningful limitations on the maximum size of allocation and the impact of those allocations on other system components. kvmalloc(), by contrast, uses vmalloc() internally to make non-contiguous use of memory for large allocations, which is more efficient and less contentious. The wolfSSL kernel module now leverages this capability when targeted to Linux kernel 4.12 or newer, relaxing potential resource constraints and minimizing the likelihood of interference in the kernel.

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 release 4.7 includes --enable-reproducible-build, a new configuration option that suppresses the binary jitter (timestamps and other non-functional metadata) that is otherwise common in various build processes. With --enable-reproducible-build, test and release engineers can carefully align build environments, then generate bitwise-identical binary packages with identical hashes. Using --enable-reproducible-build, FOSS binary distributors can publish their build environment attributes and parameters, then third parties can verify binary distributions by replicating the build process and comparing hashes. Similar processes can be used internal to an organization to confirm the integrity of build environments and source archives.

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

Since version 1.7.1, wolfBoot provides support for secure boot on systems with a Trusted Execution Environment (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.

Our first reference implementation has been made in collaboration with ST using STM32L5 target. This device can be configured to keep the running application or operating system from accessing the Secure world resources, including the partition containing the bootloader itself on the FLASH memory, and other hardware resources that may be configured as secure at boot time.

For more information, check out the wolfBoot product page.

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 wolfSSL OpenSSL compatibility layer is a means to switch applications designed for OpenSSL over to use wolfSSL. In addition to this, it is constantly expanded and currently has more than 500 commonly used OpenSSL functions. wolfSSL also provides Crypto API support to enable easier migration of projects.

We recently added some more in our wolfSSL 4.7.0 release!

• SSL_get_verify_mode
• X509_VERIFY_PARAM API
• X509_STORE_CTX API

… to name a few.

Why might one want to make the migration from OpenSSL and turn on this compatibility in the first place? To start, wolfSSL has numerous benefits over its counterpart, OpenSSL. Some of these include hardware acceleration implementations, progressive adoptions of TLS 1.3 as well as a reduced footprint size. In addition to this, there is the potential to use wolfCrypt FIPS. wolfSSL maintains current FIPS 140-2 (and soon to be 140-3) support which is used in numerous applications. We also provide FIPS Ready builds to help get projects ready for FIPS verification. All of this is supported by a team of trained wolfSSL engineers.

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 is happy to announce support for user_settings.h in CMake builds in wolfSSL 4.7.0. To enable this feature, add -DWOLFSSL_USER_SETTINGS=yes to your cmake command and proceed to use user_settings.h as you normally would. For more about user_settings.h, continue reading below.

When building for embedded devices the best way to configure the wolfSSL library is to create a header named “user_settings.h”. Then, at the global level in your application define WOLFSSL_USER_SETTINGS so that when <wolfssl/wolfcrypt/settings.h> is included throughout the library the user_settings.h header is also pulled in. The application should include <wolfssl/wolfcrypt/settings.h>, BEFORE all other wolfSSL headers. A good example user_settings.h for getting started on an embedded project can be found at wolfssl-4.7.0/IDE/GCC-ARM/Header/user_settings.h. That example is well commented and provides a good starting point for any embedded project, even non-ARM based ones!

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

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

$ git clone https://github.com/wolfSSL/wolfssl.git

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

1. wolfSSL was configured and installed with these settings:

./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install

2. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
3. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git”
4. StongSwan was configured and installed with these settings:

./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check

5. In the make check stage of the test, it was observed that 1 test was failing.

 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================

6. Reviewing the logs it was apparent one of the RSA tests was failing.
7. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.

Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

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

Three of our biggest engineering investments at wolfSSL are testing, testing, and testing. We invest heavily in testing, so that you don’t have to. We develop and test with 30+ operating systems, 10+ compilers, 50+ chipsets, 20+ hardware encryption IP schemes, and 15+ secure enclaves. We add more of the above to our Jenkins based CI/CD package every day. We do unit tests on everything, we run 5 static analyzers, and we run 7 internal fuzz testers. We employ sophisticated outside consultants to run additional fuzz testing.

Oh, yeah, we’ve had our code audited by every major vendor in computing, because they are all our customers, and need to review our code to ensure their own security and branding.

We’ve also been audited by over 20 security research teams in academia.

Finally, we’ve been through industry specific testing like DO-178 in aviation, MISRA and ASPICE in automotive, and FIPS 140 in government.

Contrast all of that with the testing and assurance you get from our competitors on your particular platform. It won’t compare.

Want to hear more about why we have the best tested cryptography and TLS 1.3? Email us at facts at wolfSSL dot com!

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