Enhancing Realm Database Security with wolfSSL

Are you looking to add FIPS 140-3 certified cryptography to your Realm database? wolfSSL has you covered!

We’ve successfully integrated wolfSSL into Realm, providing you with robust TLS and cryptographic functionality. A version tested on Linux is available, and we can also help you enable support for platforms like Android and iOS upon request.

Getting Started with Realm and wolfSSL

To start using wolfSSL with Realm, follow these steps:

Configure wolfSSL:

./configure --enable-static --enable-opensslall --enable-enckeys --enable-certgen --enable-context-extra-user-data
sudo make install

Optionally, specify the installation directory with --prefix=/path/to/install.

Download and patch Realm Core:

git clone https://github.com/realm/realm-core.git
cd realm-core
git checkout a5e87a39
git submodule update --init --recursive

Applying the Patch to support wolfSSL:

git apply ../realm-v13.26.0.patch

You can obtain the patch from wolfSSL/osp/realm directory

Build Realm Core with wolfSSL:

mkdir build
cmake -B build -DREALM_ENABLE_ENCRYPTION=1 -DREALM_USE_WOLFSSL=1 -DREALM_WOLFSSL_ROOT_DIR=/usr/local/lib
cmake --build build
./build/test/realm-tests

If you’d like to secure your Realm app with wolfSSL or need support for other platforms, reach out to us at facts@wolfSSL.com or call us at +1 425 245 8247.

Stay secure with wolfSSL and Realm!

Download wolfSSL Now

Getting Started with wolfSSL using Visual Studio 2022

It’s never been easier to get started with wolfSSL on Microsoft Windows using Visual Studio 2022!

New VS2022-specific project and solutions files have been created for both the wolfssl/wolfcrypt core library, as well as the test and benchmark examples. These files are available immediately on GitHub and are included in the recent release.

For long term customers and backward-compatibility, we’ve had older versions of Visual Studio that generally would update to whatever latest version might be installed. See our blog post here.

Now with the new VS 2022 files, no more manual adjustments are needed. The project files work immediately out of the box. Just open the project file and click the run button.

Let’s say you’ve just cloned the latest version of wolfSSL from GitHub in your C:\workspace directory:

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

The test and benchmark examples also include a vcxproj.user file that aids in pointing the working directory of the project to the root-level wolfSSL to easily find the compiled binary.

To get started with the examples, simply navigate to the wolfCrypt benchmark directory:

C:\workspace\wolfssl\wolfcrypt\benchmark

and open either the benchmark-VS2022.vcxproj project or benchmark-VS2022.sln solution files in Visual Studio 2022.

If you happen to be one of the Windows developers that also uses WSL, you may occasionally see an oddity in Visual Studio’s equivalent of git status as compared to the result from the WSL prompt. The issue is the way Windows might handle file permissions that differ between Windows and Linux when the same file system is shared (e.g. C:\workspace vs /mnt/c/workspace), causing Visual Studio to detect modified files even though there’s no apparent text change. One way to fix this is with this git command:

git config core.fileMode false

Visual Studio may need to be re-launched if it was already already running when the command was entered in a WSL prompt.

When using wolfSSL on Windows, it is a common practice to use a user_settings.h file. There’s an example in the wolfssl/IDE/WIN directory:

https://github.com/wolfSSL/wolfssl/blob/master/IDE/WIN/user_settings.h

The wolfCrypt Benchmark and wolfCrypt Test applications can also be used as reference examples.

Note the beginning of the benchmark.c file. It uses a common pattern of including the wolfssl library:

#ifdef HAVE_CONFIG_H
    #include 
#endif

#ifndef WOLFSSL_USER_SETTINGS
    #include 
#endif
#include  /* also picks up user_settings.h */

It is important to define the c-compiler preprocessor definition: WOLFSSL_USER_SETTINGS

The #include <wolfssl/wolfcrypt/settings.h> should be listed before any other wolfSSL headers are included. The user_settings.h is included in the settings.h file. The user_settings.h should never be explicitly included in any other source code header.

Beyond the Benchmark and Test Examples

Do you have a project and you’d like to add the wolfssl library? Right-click on the solution file and select “Add – Existing Project…”:

Navigate to the root directory of your wolfSSL source code and add the wolfssl-VS2022.vcxproj file to your solution.

Be sure to also add a reference to each project that will use the wolfssl library. Right click on “references” and add check the “wolfssl” project:

Depending on the directory structure and relative location of the project, the path to the wolfssl source code headers will likely need to be added to the Additional Include Directories. The typical example will be at least for the root directory:

C:/workspace/wolfssl

And oftentimes the user_settings.h as well, shown here in the example IDE/Win directory:

C:/workspace/wolfssl/IDE/Win

The example property page would look like this:

That’s it! Simply build and run the project.

Reorganization Coming Soon

Visual Studio project and solution files will soon be moved to the .\IDE\VS2010.\IDE\VS2022 directories.

The FIPS-related builds currently interspersed in other directories will soon be consolidated and moved to a new .\IDE-FIPS directory. See PR #8126.

For more information:

Post Quantum

Do you have code that can be upgraded to Post Quantum? See our recent blog.

FIPS Certified!

When you are ready to move on to the next step, wolfSSL will be there for you! Need to have your project NIST Certified? Recently we announced that wolfSSL is the First in the World to offer FIPS 140–3 Automated Submission with our NIST Certificate #4718.

For more details, see our blog What is FIPS (long version).

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

Versal Support

Did you know that wolfSSL has been ported to and tested on Xilinx Versal hardware? There is support also in wolfSSL to make use of the Xilinx hardened crypto, enhancing both security and performance. Xilinx hardened crypto has accelerated crypto operations (SHA3-384 / AES-GCM / RSA / ECDSA) available on Ultrascale+ devices and is available for use with the latest and greatest Versal boards. wolfSSL makes these calls using the API from Xilinx’s XilSecure library (https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_services/xilsecure) and with the addition of Versal there was minor changes to the existing calls to make use of the new features available (ECC / RNG / AES-GCM with AAD). When benchmarking we saw well over a Gigabyte per second with AES-GCM operations in our demo and improvements in performance of RSA, ECDSA, and SHA3-384 over software only implementations.

A previous white paper going into the setup and use of wolfSSL on older Ultrascale+ devices with Xilinx hardened crypto can be found here (https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto). The support for Versal along with a README can be found in the wolfSSL bundle located in IDE/XilinxSDK/.

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

Download wolfSSL Now

Changes In wolfSSL for ARM Thumb-2 Builds

With wolfSSL release 5.7.4 we added the macro WOLFSSL_ARMASM_THUMB2. This macro can be defined to enable Thumb-2 ARM instruction optimizations and replaces the previous attempted autodetect on the macros __arm__ and __thumb__. Giving users complete control over which ARM assembly optimizations are compiled and used.

When building for Thumb-2 the source files beginning with thumb2-* should additionally be compiled in. If WOLFSSL_ARMASM_THUMB2 is not used then the armv8-32-* files will be used. These files are located in wolfcrypt/src/port/arm/.

The benefit of now having WOLFSSL_ARMASM_THUMB2 is that users can place all files in wolfcrypt/src/port/arm/ to be compiled and use the macro gate for selecting if the Thumb-2 section is optionally compiled or ARM32 implementation is. The armv8-32- code is very similar to the thumb2- code, but Thumb-2 is smaller in size.

For assistance with ARM optimization builds contact us at support@wolfSSL.com.

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

Download wolfSSL Now

Switching to wolfCrypt’s Implementations of Post-Quantum Algorithms

Have you been trying out post-quantum algorithms in wolfSSL’s products? As you probably know, here at wolfSSL we have a step-wise approach to post-quantum algorithm integration:

  1. Define an API in wolfCrypt.
  2. Do an integration with an existing reference implementation (ie.: liboqs, PQM4, hash-sigs liblms, xmss-reference).
  3. Use these APIs in higher level libraries and products (ie.: wolfssl, wolfssh, wolfmqtt, wolfboot) to implement features.
  4. Invest the time and effort to write and optimize our own production grade implementation of the algorithm.

For LMS, XMSS, ML-KEM and ML-DSA the time has finally come to switch to using wolfSSL’s implementations of these algorithms. It’s very simple to do so. If you are using any of the following configure-time flags simply remove them from your configure command-line:

--with-liblms
--with-libxmms
--with-liboqs

Then ensure you are enabling the relevant algorithm that you are interested in. Relevant flags are:

--enable-xmss
--enable-lms
--enable-dilithium
--enable-kyber

Once this is done, you will be using our professionally optimized and tested implementations of post-quantum algorithms.

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

Download wolfSSL Now

Do you need post quantum versions of Apache, NGINX, Lighttpd, cURL, or stunnel?

Our wolfSSL library has several post-quantum algorithms built in, but on their own, they aren’t always useful. How else can the PQC algorithms be used in production? Well, one of our areas of expertise is getting other open-source projects working with wolfSSL and then getting those integrations using post-quantum algorithms. We have post-quantum integrations with multiple web servers, a web client, and a secure tunneling solution. Read on to learn more!

For a more heavy-duty and reliable web server with professional production-ready code, we have a post-quantum integration with Apache.

For a lighter-weight yet fully featured and dependable alternative, you can turn to our post-quantum enabled Nginx integration.

Our wolfSSL library excels in constrained environments as does Lighttpd. For the most bare bones environments, our lighttpd post-quantum integration is likely the right choice.

And for the client side, we have also made the cURL web client quantum-safe! See this video for instructions on how to build.

If you’ve got an application where making changes is difficult due to legacy software, we’ve got our post-quantum integration with stunnel to make your migration a breeze.

Go ahead and try out these open source integrations! We are eager for your feedback, and happy to support your efforts Whether it be as part of a hackathon or as an experiment to understand feasibility or to gather benchmarking data, trying out these integrations is a great step in your plan for migration to post-quantum algorithms.

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

Download wolfSSL Now

MAX32666 and MAX32665 Hardware Acceleration added to wolfSSL

wolfSSL now supports using the Trust Protection Unit (TPU), Modular Arithmetic Accelerator (MAA), and TRNG provided by Analog Devices MAX32666 and MAX32665 microcontrollers.

The implementation can be seen in PR #7777 to wolfSSL, and is in wolfSSL starting at 5.7.4!

The port offers various usage options: fully leveraging all hardware features, selectively enabling specific hardware acceleration like SHA acceleration, or utilizing Crypto Callbacks for mixed usage between hardware and software. For a guide on setting up the port please refer to the README.

Currently wolfSSL supports offloading the following algorithms and operations to the respective hardware:

TRNG:

  • RNG

TPU:

  • AES-CBC – 128/192/256
  • AES-GCM – 128/192/256
  • AES-ECB – 128/192/256
  • SHA-1
  • SHA-2 – 224/256/384/512

MAA (HW Accelerated Math Operations up to 2048 bits):

  • Modulate (mod)
  • Modular Addition (addmod)
  • Modular Subtraction (submod)
  • Modular Multiplication (mulmod)
  • Modular Exponentiation (expmod)
  • Modular Squaring (sqrmod)

Benchmarks:

These benchmarks were collected using a Cortex-M4 clocked at 96 Mhz included on the MAX32666 FTHR dev kit, and a bare metal implementation of our benchmark. The timer used for these benchmarks can be enabled with the addition of MAX3266X_RTC to user_settings.h for reproduction.

AES ECB/CBC/GCM:

AES-CBC and AES-ECB Hardware Acceleration provides a hefty 2x uplift in performance when compared to our Arm assembly acceleration and normal software implementations.
AES-GCM does not provide the same uplift due to the hardware not supporting GCM explicitly, but we take advantage of the ECB support of the hardware to still provide a speedup when compared to our standard software implementation.
You can enable this kind of speed up for other AES modes by adding HAVE_AES_ECB to user_settings.h.



All algorithms of SHA provide a consistent boost to performance. With our benchmark tool we see up to a 7x performance for SHA-384/512 when compared to our software implementations. As the algorithm gets simpler we see less of a performance increase, however the consistent throughput is still impressive.

Math Acceleration (RSA 2048 and ECDSA p256):

Using the Math Acceleration hardware we do see a decrease in performance for RSA 2048 and ECDSA p256 when compared to our software implementations. This is likely due to the setup and preprocessing that needs to happen before sending the operands down to the hardware.

 
 

Download:

For our official release please checkout our download page!

Questions?

For information about using MAX32666 or MAX32665 hardware acceleration in your project, or any general inquiries about supporting your project’s hardware, reach out to our support team at support@wolfSSL.com

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

Download wolfSSL Now

X509 Attribute Certificate support

wolfSSL is adding support for X509 Attribute Certificates (ACERTs, for short), enabled with --enable-acert. This initial support includes reading, printing, and verifying. Furthermore, it uses our new ASN.1 template implementation, and supports RSA-PSS as well.

But what is an X509 Attribute Certificate, and how does it differ from the more commonly encountered X509 Public Key Certificate? Defined in RFC 5755, an Attribute Certificate is a digitally signed binding between an identity and authorization attributes. In contrast to X509 Public Key Certs, an X509 Attribute Cert does not contain a public key. However, the public key used to verify an Attribute Cert could be found in an X509 Pub Key Cert.

If you’re curious and want to learn more, check out the X509 ACERT pull request and our recently added ACERT example. The latter shows an example of using ACERT support with our openssl compatibility layer.

If you are interested in X509 Attribute Certificates support or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

LMS in PKCS11

Most people know that wolfSSL supports being a PKCS11 consumer. It is easy to enable this with the --enable-pkcs11 configure time flag and then trying out the examples. Now, what most people don’t realize is that we also have the ability to be a PKCS11 provider!! This is via our library called wolfPKCS11. Check out the source repo on github.

The most interesting thing about PKCS11 is that the post-quantum stateful hash-based signature scheme LMS/HSS has already been added to the PKCS11 standard. If you look at the latest specification, you can already find an example template definition for a private key:

CK_OBJECT_CLASS keyClass = CKO_PRIVATE_KEY;
CK_KEY_TYPE keyType = CKK_HSS;
CK_UTF8CHAR label[] = “An HSS private key object”;
CK_ULONG hssLevels = 123;
CK_ULONG lmsTypes[] = {123,...};
CK_ULONG lmotsTypes[] = {123,...};
CK_BYTE value[] = {...};
CK_BBOOL true = CK_TRUE;
CK_BBOOL false = CK_FALSE;
CK_ATTRIBUTE template[] = {
    {CKA_CLASS, &keyClass, sizeof(keyClass)},
    {CKA_KEY_TYPE, &keyType, sizeof(keyType)},
    {CKA_TOKEN, &true, sizeof(true)},
    {CKA_LABEL, label, sizeof(label)-1},
    {CKA_SENSITIVE, &true, sizeof(true)},
    {CKA_EXTRACTABLE, &false, sizeof(true)},
    {CKA_HSS_LEVELS, &hssLevels, sizeof(hssLevels)},
    {CKA_HSS_LMS_TYPES, lmsTypes, sizeof(lmsTypes)},
    {CKA_HSS_LMOTS_TYPES, lmotsTypes, sizeof(lmotsTypes)},
    {CKA_VALUE, value, sizeof(value)},
    {CKA_SIGN, &true, sizeof(true)}
}; 

Are you looking to use wolfSSL to consume LMS/HSS? Our wolfCrypt library already has support for LMS/HSS; want to consume it via a PKCS11 interface? Want to get ahead of the curve and start prototyping ML-KEM (FIPS 203) or ML-DSA (FIPS 204) in PKCS11? Send a message to facts@wolfSSL.com to let us know which of these you want accelerated.

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

Download wolfSSL Now

wolfSSL 5.7.4 Release

wolfSSL release 5.7.4 is now available, with exciting optimizations for ARM devices and enhancements to post-quantum cryptography algorithms. If you’re using wolfSSL on RISC-V, we’ve also included new performance enhancements specifically for RISC-V devices. Alongside these optimizations and new features, several important fixes were made. One notable fix involves the behavior of X509_STORE_add_cert() and X509_STORE_load_locations() functions to better align with OpenSSL when the compatibility layer is enabled.

Below are some of the key changes in this release. For a more comprehensive list, refer to the ChangeLog.

New Features and Additions

  • RISC-V 64: Added new assembly optimizations for SHA-256, SHA-512, ChaCha20, Poly1305, and SHA-3 (PRs 7758, 7833, 7818, 7873, 7916).
  • DTLS 1.2 Connection ID: Implemented support for Connection ID (CID) (PR 7995).
  • DevkitPro Support: Added support for (DevkitPro)libnds (PR 7990).
  • Mosquitto: Added a port for Mosquitto OSP (Open Source Project) (PR 6460).
  • sssd: Added a port for init sssd (PR 7781).
  • eXosip2: Added support for eXosip2 (PR 7648).
  • STM32G4: Added support for STM32G4 (PR 7997).
  • MAX32665 and MAX32666: Added support for TPU hardware and ARM ASM crypto callback (PR 7777).
  • libspdm: Added support for building wolfSSL to be used in libspdm (PR 7869).
  • Nucleus Plus: Added support for use with Nucleus Plus 2.3 (PR 7732).
  • RFC5755 Attribute Certificates: Initial support for x509 attribute certificates (acerts) with --enable-acert (PR 7926).
  • PKCS#11 RSA Padding Offload: Allows tokens to perform CKM_RSA_PKCS (sign/encrypt), CKM_RSA_PKCS_PSS (sign), and CKM_RSA_PKCS_OAEP (encrypt) (PR 7750).
  • Heap/Pool Allocation: Added “new” and “delete” style functions for heap/pool allocation and freeing of low-level crypto structures (PRs 3166, 8089).

Espressif / Arduino Updates

  • Updated wolfcrypt settings.h
  • Updated Espressif SHA, utility, memory, and time helpers (PR 7955).
  • Fixed _thread_local_start and _thread_local_end for Espressif (PR 8030).
  • Enhanced benchmarking for Espressif devices (PR 8037).
  • Introduced Espressif common CONFIG_WOLFSSL_EXAMPLE_NAME in Kconfig (PR 7866).
  • Added wolfSSL esp-tls
  • Updated wolfSSL release for Arduino (PR 7775).

Post-Quantum Crypto Updates

  • Dilithium: Support for fixed-size arrays in dilithium_key (PR 7727).
  • Dilithium Precalc: Added option to use precalc with small sign (PR 7744).
  • Kyber FIPS: Allowed Kyber to be built with FIPS (PR 7788).
  • Kyber in Linux Kernel: Enabled Kyber ASM usage in Linux kernel module (PR 7872).
  • Dilithium, Kyber: Updated to final specifications (PR 7877).
  • Dilithium FIPS: Supported FIPS 204 Draft and Final Draft (PRs 7909, 8016).

ARM Assembly Optimizations

  • ARM32: Added assembly optimizations for ChaCha20 and Poly1305 (PR 8020).
  • Poly1305 Aarch64: Improved Poly1305 assembly optimizations for Aarch64 (PR 7859).
  • Poly1305 Thumb-2: Added Poly1305 optimizations for Thumb-2 (PR 7939).
  • STM32CubePack: Added ARM ASM build option to STM32CubePack (PR 7747).
  • Visual Studio: Added ARM64 support to the Visual Studio project (PR 8010).
  • Kyber ARM Optimizations: Added assembly optimizations for ARM32, Aarch64, ARMv7E-M, and ARMv7-M (PRs 8040, 7998, 7706).

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

Download wolfSSL Now

Posts navigation

1 2 3 4 5 6