PQC support for the Zephyr port

PQC support for the Zephyr port was introduced in the last wolfSSL release using liboqs. This involved adding necessary files to the CMakeLists.txt for the Zephyr module. Zephyr is an open-source real-time operating system (RTOS) designed for resource-constrained devices and embedded systems. It is maintained by the Linux Foundation and supported by a vibrant community of developers and contributors.

PR #7026 (https://github.com/wolfSSL/wolfssl/pull/7026) also addressed proper random number generation within liboqs by using the wolfSSL interface. Previously, liboqs random data acquisition relied on various sources, depending on the liboqs build configuration. With the changes, a custom RNG method is provided through the OQS_randombytes_custom_algorithm() interface, enabling liboqs to obtain RNG data from wolfSSL for all generic liboqs uses.

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

Download wolfSSL Now

wolfSSL on Microblaze

MicroBlaze, developed by Xilinx, is a soft processor core optimized for Xilinx FPGAs. It offers flexibility and scalability, making it suitable for a wide range of applications, including embedded systems and IoT devices. Integrating wolfSSL’s AES-GCM with MicroBlaze is possible and has been done running on a soft CPU on MicroBlaze. In the latest wolfSSL release this integration saw some additional enhancements. When used on a MicroBlaze, wolfSSL’s AES-GCM enhances the security capabilities of FPGA-based systems, enabling developers to implement secure communication protocols and data encryption mechanisms. There is also the option of setting up wolfSSL so that it makes use of Xilinx’s xilsecure while running on the Microblaze. Increasing the AES-GCM performance significantly.

For more information about using wolfSSL on a MicroBlaze or 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

RSA-PSS with CRL’s

Did you know wolfSSL has integration of RSA-PSS signatures with Certificate Revocation List (CRL) support?

RSA-PSS: Enhancing Security Layers

RSA-PSS, or Probabilistic Signature Scheme, represents a modern approach to digital signatures. Unlike traditional RSA signatures, RSA-PSS offers improved security properties, making it more resilient against various cryptographic attacks. By adopting RSA-PSS, wolfSSL users benefit from heightened security, enhancing the integrity of cryptographic operations.

Certificate Revocation List (CRL): Managing Certificate Integrity

In the realm of certificate management, CRL plays a pivotal role. It serves as a mechanism for indicating the revocation status of digital certificates. With CRL, systems can promptly identify and reject compromised or revoked certificates, bolstering the overall security posture. Integrating CRL support into wolfSSL empowers users with efficient certificate management capabilities, ensuring the authenticity and integrity of cryptographic transactions.

Empowering wolfSSL with RSA-PSS and CRL Integration

The fusion of RSA-PSS with CRL support within wolfSSL is a logical step when providing cutting-edge security solutions. Now, wolfSSL users can leverage the combined strength of RSA-PSS signatures and CRL management to fortify their cryptographic environments.

To delve deeper into the RSA-PSS with CRL integration in wolfSSL, visit our GitHub repository (https://github.com/wolfSSL/wolfssl/pull/7119) or reach out to facts@wolfSSL.com for assistance.

Thank you for entrusting wolfSSL as your ally in cybersecurity.

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

Removal of user RSA

In the last release of wolfSSL there was some house cleaning done on older RSA implementations. The user RSA layer was removed along with the hooks used for tying in IPP. When those were first introduced we had yet to implement SP (single precision) versions of RSA. Fast forward to today, and there is a faster implementation of RSA in wolfSSL itself. In IPP v0.9 it was able to do 990.09 RSA 2048 bit sign operations per second and in wolfSSL 5.7.0 it was able to run 1,015.23 operations per second. Verify operations took around the same time with both libraries now at 35,714 operations per second on average. These measurements were collected on an older Intel(R) Core(TM) i7-4870HQ CPU. Along with a performant implementation of RSA there are now the crypto callbacks if desiring to plug in custom RSA operations. This being the case the –enable-fastrsa, user RSA, and IPP hooks were dropped to lower maintenance and reduce bundle size.

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

How to unload intermediate certificates with wolfSSL?

Recently, a notable modification was introduced in wolfSSL, a prominent provider of security solutions. Pull request #7245 (https://github.com/wolfSSL/wolfssl/pull/7245) focuses on optimizing memory management by introducing a function to unload intermediate CA certificates and free up memory. Let’s explore the significance of this code change and its potential impact on enhancing efficiency and resource utilization within cryptographic applications.

Specifically, the code change addresses the need to efficiently handle intermediate Certificate Authority (CA) certificates. These certificates, while essential for establishing trust chains in cryptographic operations, can consume valuable memory resources, particularly in resource-constrained environments.

The essence of the code change lies in the introduction of a dedicated function (wolfSSL_CertManagerUnloadIntermediateCerts()) to unload intermediate CA certificates from memory when they are no longer needed. By using this function, developers can optimize resource utilization, thereby enhancing the overall efficiency and stability of cryptographic operations.

Key Benefits: The introduction of the function to unload intermediate CA certificates brings several notable benefits:

  1. Efficient Memory Management: By providing a mechanism to unload intermediate CA certificates from memory, the code change ensures efficient utilization of resources. This is particularly crucial in environments where memory constraints are a concern, such as embedded systems and IoT devices.
  2. Prevention of Memory Leaks: Memory leaks can pose significant security and reliability risks in software applications. The new function helps prevent memory leaks by explicitly releasing memory allocated for intermediate CA certificates when they are no longer required, thereby improving the robustness of cryptographic operations.
  3. Scalability and Performance: Optimal memory management contributes to improved scalability and performance of cryptographic applications. By freeing up memory resources, the code change enables applications to handle larger workloads more efficiently, leading to enhanced responsiveness and overall performance.

By incorporating the function to unload intermediate CA certificates, developers can optimize resource utilization and mitigate potential security risks associated with memory management issues. This not only enhances the reliability and stability of cryptographic applications but also contributes to the overall security resilience of the systems in which they are deployed.

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

wolfSSL LTS Announcement

wolfSSL is announcing a long term support (LTS) version of the wolfSSL library. The goal of this product will be to provide users with fully ABI compatible releases of wolfSSL that are secure against all known vulnerabilities. Patches for vulnerabilities will be backported to the LTS branch in an ABI compatible way to guarantee security and stability.

ABI (Application Binary Interface) is a low-level interface that defines how functions and data structures are accessed in machine code. ABI specifies how parameters are passed to functions, how return values are retrieved, and how data structures are arranged in memory. Guaranteeing ABI stability means that compiling a newer version of the library with the same configuration will work with programs linked against an older release.

wolfSSL LTS will provide users with a stable and reliable library that can be kept up to date with no additional headache. Your programs will always be compatible with the latest wolfSSL LTS release and will be safe from discovered vulnerabilities. Separating out a LTS branch will allow us to continue developing and improving wolfSSL without the strict restrictions of ABI backwards compatibility. Users will be able to choose the appropriate version for them based on their individual priorities.

wolfSSL LTS, like all of our libraries, will be offered under a dual-license model. GPL will be available for open source users and a commercial license will be available for customers integrating it in commercial products. Additional limited backporting services will also be available for customers.

If you’re interested in wolfSSL LTS or have questions about any of the above, please reach to us at facts@wolfSSL.com or call us at +1 425 245 8247!

Download wolfSSL Now

TLS on Embedded Systems: UART, I2C or SPI

Recently, we have seen an uptick in interest in securing communications between different embedded modules within a larger system. The academic community has seen great work in showing that these communications need to be secured; especially in the automotive space.

Are you looking to start securing your internal communications over UART, I2C or SPI? With wolfSSL, no matter how small and constrained your micro-controller, we can help!! You can make trade-offs and set build flags to suit your needs with regards to code size, memory usage and binary footprint size. For example, if you are running a TLS 1.3 client, we have flags to exclude all server-only code and exclude all earlier versions of TLS and SSL.

Some might find the idea of TLS over UART, I2C or SPI to be somewhat strange. Isn’t TLS supposed to be running over a network connection? Actually, with our IO callback system, there is no problem at all. For a great example of how to do it, you can have a look at our STM32 example code. There we show TLS 1.3 over UART both as server and client. Please have a look at https://github.com/wolfSSL/wolfssl/blob/master/IDE/STM32Cube/wolfssl_example.c. You can search there for the ENABLE_TLS_UART macro to better understand how it hooks into our IO callbacks.

Want more details? Want to discuss further how you can secure your data interfaces on your micro-controller? Reach out to facts@wolfssl.com.

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

wolfSSL 5.7.0 Now Available!

Version 5.7.0 of wolfSSL is now available! Many new and exciting features were added in this release. Near the top of that list is the addition of our Kyber implementation along with other post quantum algorithm support. This empowers you to future-proof your security measures, ensuring robust protection against evolving threats. In addition to introducing new features, we’ve addressed three vulnerabilities in this release. Two of these fixes target vulnerabilities related to row hammer attacks, while the other addresses a TLS 1.3 server-side issue. We take security seriously, and you can find more information about these fixes on our vulnerability page (https://www.wolfssl.com/docs/security-vulnerabilities/).

A full list of fixes, additions, and optimizations can be found in the ChangeLog, here are some of the highlights!

  • Experimental framework for using wolfSSL’s XMSS and LMS implementation. Explore and test advanced cryptographic techniques within the wolfSSL ecosystem. (PR 7161 & PR 7283)
  • Experimental wolfSSL Kyber implementation and assembly optimizations, enabled with –enable-experimental –enable-kyber. Proactively prepare for quantum computing threats with Kyber integration and assembly optimizations. (PR 7318)
  • The Linux kernel module now supports registration of AES-GCM, AES-XTS, AES-CBC, and AES-CFB with the kernel cryptosystem through the new –enable-linuxkm-lkcapi-register option, enabling automatic use of wolfCrypt implementations by the dm-crypt/luks and ESP subsystems. In particular, wolfCrypt AES-XTS with –enable-aesni is faster than the native kernel implementation.
  • BER content streaming support for PKCS7_VerifySignedData and sign/encrypt operations. Handles large data streams more effectively during PKCS7 operations. (PR 6961 & 7184)
  • Microchip PIC24 support and example project expands compatibility, facilitating integration with Microchip’s PIC24 microcontrollers. (PR 7151)
  • AutoSAR shim layer provides a standardized interface for RNG, SHA256, and AES (PR 7296)
  • wolfSSL_CertManagerUnloadIntermediateCerts API to clear intermediate certs added to certificate store (PR 7245)

This is a small subset of the optimizations and enhancements made in the last release are as follows:

  • Remove obsolete user-crypto functionality and Intel IPP support (PR 7097)
  • Support for RSA-PSS signatures with CRL use (PR 7119)
  • Enhancement for AES-GCM use with Xilsecure on Microblaze (PR 7051)
  • Improve liboqs integration adding locking and init/cleanup functions (PR 7026)
  • Update Arduino example TLS Client/Server and improve support for ESP32 (PR 7304 & 7177)
  • Improvements for Espressif use; SHA HW/SW selection and use on ESP32-C2/ESP8684, wolfSSL_NewThread() type, component cmake fix, and update TLS client example for ESP8266 (PR 7081, 7173, 7077, 7148, 7240)

Visit our download page to download the latest release, or clone it from wolfSSL GitHub. If you have questions about any of the above, feel free to email us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Getting Started with wolfSSL on Arduino

Getting started with wolfSSL has never been easier. We’ve recently updated our library as published on the Arduino libraries site, listed in the “Communications” section:

https://www.arduino.cc/reference/en/libraries/wolfssl/

To use wolfSSL in the Arduino IDE, download the latest IDE version from arduino.cc and follow the installation instructions.

Note that if you used any version of wolfSSL prior to v5.6.6.Arduino.1, those versions have been removed from the Arduino registry as they were not Official wolfSSL Arduino releases.

To install wolfSSL, click on Tools… Manage Libraries:

Type wolfssl in the search box, then press the Install button.

Additional details can be found in the Arduino documentation for installing libraries for V1 or using the Arduino IDE V2 installation method.

When the sketch is opened, click on the “Select Board” dropdown:

In the case of Windows, click on the COM port that has your device, here for COM36:

Enter part of name to more quickly find the desired board selection:

Click on the desired board and click the OK button.

For Arduino brand and compatible boards, the Arduino IDE will prompt if libraries are needed to be installed:

There are two main examples for wolfSSL: a TLS client and a TLS server. The most recent code can be found in the IDE/Arduino directory on GitHub.

To use the examples from the Arduino IDE Library, click on File… Examples. See the wolfSSL sample sketches in the “Examples from Custom Libraries” at the bottom of the list:

Note that both the Client and Server examples need a network connection. Most boards will need to have WiFi parameters set for this. See the beginning of the sketch for setting a file (typically outside the scope of any GitHub repository, to be kept private):

Otherwise if you are not using a private file, the values can be entered directly into the source code, shown here for your_SSID and your_PASSWORD:

Once the sketch is loaded and a board (and serial port) are selected, simply press the upload button as with any other Arduino sketch.

If using the Server example, make note of the IP address assigned. By default a DHCP address is requested, so the value will be specific to the SSID / Access Point.

If using the Arduino Client, not only do the WiFi settings need to be assigned, but also the Server address WOLFSSL_TLS_SERVER_HOST value to connect to, shown here for an example address of 192.168.1.39

Both the Arduino Client and Server sketches can of course be used to communicate with the wolfSSL executables, found in the examples/client and examples/server directories. These are built automatically when running make from the root of the wolfSSL clone:

./configure --enable-all
make clean
make && make test
./examples/client/client -h 192.168.1.39 -p 11111

Keep in mind that workstation examples may need firewall rules and/or anti-virus adjusted when communicating with external embedded devices such as the Arduino boards. The wolfSSL TLS examples typically use port 11111.

Want to customize the wolfSSL settings? See the user_settings.h file in

C:\Users\%USERNAME%\Documents\Arduino\libraries\wolfssl\src

It’s best to not directly include the wolfSSL user_settings.h file in your code. When including the library, there’s a settings.h file that will automatically include the user_settings.h file as appropriate, along with making some default environment settings.

See the documentation for more details on settings. For embedded targets such as Arduino, all of the settings are the #define values in the user_settings.h file.

Details on how we publish wolfSSL to Arduino can be found in our wolfSSL/IDE/ARDUINO GitHub directory. If you have a local clone of wolfSSL, you can use the wolfssl-arduino.sh script to install your own latest version of wolfSSL directly to your Arduino libraries directory like this:

./wolfssl-arduino.sh INSTALL

Note that there’s only a Linux bash command. Windows users are encouraged to use WSL. See the README file for more information.

If any problems are encountered with the sketch, sometimes it can be helpful to delete the build cache directories. For Windows users, this is in the AppData directory:

C:\Users\%USERNAME%\AppData\Local\Temp\arduino\sketches

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

wolfSSL SSL/TLS Support for NXP SE050

The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 module since November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. To help users get started with TLS usage, we also have two example client applications available for use and reference.

wolfSSL TLS users can use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050 module.

#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id,
    long sz, int devId);

For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:

cd wolfssl-X.X.X
./configure <options> CFLAGS=”-DWOLF_PRIVATE_KEY_ID”
make
sudo make install

TLS Client Demos Using SE050

wolfSSL has two example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi environment with attached NXP EdgeLock SE050 Development Kit.

Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:

  1. wolfSSL SSL/TLS Client Example

    This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example README.md, or wolfssl_client.c file.

  2. wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050

    This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example README.md or wolfssl_client_cert_key.c.

Resources

For more details on using wolfSSL or wolfCrypt with the NXP SE050, see one of the following links or email us at facts@wolfSSL.com. The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).

Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (README_SE050.md)
Examples: wolfSSL NXP SE050 Examples (README.md)
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family

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

Posts navigation

1 2 3 4 5 6 7 8