Category: wolfSSL/ wolfCrypt

We’re often asked if our cryptography library can be used in kernel, typically for use cases involving network or disk I/O. Indeed it can. Performing cryptographic operations inside the kernel has performance and security advantages, and is typically transparent to user mode applications and daemons. When is kernel mode cryptography the right solution, and what sorts of advantages can you expect?

Two common high level use cases for kernel mode crypto are network packet flow (VPNs, IPsec, MACsec, TLS offload, and packet authentication like TCP-AO) and disk encryption (for example, dm-crypt/LUKS and fscrypt). Much of the processing for network packets and block device I/O can be done entirely in kernel mode, but only if the required cryptographic operations are also performed in kernel mode. Performance will degrade significantly if that processing has to pass through a user mode process, as in a user mode VPNs such as StrongSwan with default configuration, or a FUSE-based cryptographic filesystem such as EncFS.

The common thread for all performance-motivated kernel crypto use cases is that the kernel is already in the critical path. Performing critical path operations in user mode introduces context switches and forces data copying, while kernel mode crypto leverages the existing data flow, with only the negligible overhead of function calls and pointer passing. If a design calls for leveraging a hardware crypto accelerator, kernel mode is a natural fit, due to the kernel’s direct access to memory-mapped physical resources.

Kernel mode crypto also allows a fundamentally higher level of security for specialized applications. Private keys and other highly sensitive data can be kept entirely in-kernel, safe from exposure. With trusted execution environments such as ARM TrustZone, Intel SGX, and AMD SEV-SNP, this data can be kept separate even from other kernel data, effectively defeating software-borne attacks even if the endpoint has been compromised.

wolfSSL has implemented Linux kernel cryptosystem plug-and-play functionality for all supported FIPS AES modes and key sizes, including XTS, CBC, CFB, GCM, OFB, CTR, and CCM, offering full turnkey (no code) support for dm-crypt/LUKS disk encryption and other kernel-mode applications. On amd64, our kernel AES implementations fully leverage AESNI and AVX, delivering state-of-the-art performance. We also support retargeting of the WireGuard kernel module to wolfCrypt, and can also retarget kernel mode WireGuard to use wolfCrypt FIPS cryptography directly. More kernel mode cryptographic algorithms are in process and available shortly, including registration of our AVX-accelerated post quantum implementations.

The full wolfCrypt native API is available in-kernel to other kernel modules, including full support for FIPS 140-3. We have also ported our full TLS stack to the kernel, allowing special use cases with TLS1.3 and DTLS1.3 endpoints resident in kernel space. TLS 1.3 in the kernel allows for encrypted communication links directly to kernel threads for maximum security.

How do you decide when Kernel Mode cryptography or TLS is appropriate for your use case? Typically you are looking for a security advantage or a performance advantage, or both. We can help! Contact us at facts@wolfSSL.com and we can support you through benchmarking and security concerns to guide your decisions.

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

Download wolfSSL Now

At wolfSSL, we are ensuring that embedded systems, IoT devices, and high-performance computing platforms benefit from the fastest and most secure cryptographic solutions available. Leveraging the available Xilinx hardware acceleration allows for high-speed encryption, decryption, and hashing with minimal CPU overhead, making it ideal for applications in aerospace, defense, automotive, networking, and industrial automation. wolfSSL’s integration with Xilinx hardware accelerators increases performance with AES-GCM, ECC, RSA and SHA3 operations. In addition there is also support for TRNG’s on Versal boards.

As we continue to enhance wolfSSL’s cryptographic performance on hardware accelerators, we’re excited about the next generation of Adaptive SoCs from AMD/Xilinx—specifically, the Versal Gen 2 Prime Series.

These next-gen platforms introduce a new Application Security Unit (ASU). Stay tuned for updates on wolfSSL leveraging the latest cryptographic hardware accelerators available on AMD/Xilinx devices!

Want to learn more about wolfSSL’s hardware acceleration roadmap or have any questions? Reach out to us today at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Expanding Cross-Compilation Capabilities in Visual Studio

With the recent release of wolfSSL, we have significantly improved the cross-compiling capabilities of wolfSSL in Visual Studio, particularly when targeting non-Windows operating systems from a Windows-based development environment. This improvement was introduced in PR #7884 and provides a new build option that makes cross-compilation smoother and more efficient.

Introducing WOLFSSL_NOT_WINDOWS_API

One of the key additions in this release is the new macro WOLFSSL_NOT_WINDOWS_API. This is specifically designed for scenarios where:

• The compilation is performed on Windows using Visual Studio.
• The target operating system is not Windows.
• The Windows API should not be used during compilation.

When WOLFSSL_NOT_WINDOWS_API is defined, the related macro USE_WINDOWS_API is not defined, ensuring that wolfSSL is built under the assumption that no Windows API functions are available. This allows developers to cross-compile for platforms such as Linux or embedded systems while using Visual Studio as their primary development environment.

Why is this Important?

In many embedded and IoT use cases, developers prefer to work within Visual Studio due to its powerful debugging and development tools. However, the final deployment target may be a non-Windows OS. Prior to this update, Visual Studio builds often assumed that Windows API functions were available, leading to compatibility issues when targeting platforms that do not support them.

With WOLFSSL_NOT_WINDOWS_API, these limitations are removed, making it much easier to:

• Compile wolfSSL for embedded Linux and other POSIX-based environments from Windows.
• Maintain a single development workflow without switching between build environments.
• Ensure consistent behavior across different platforms.

How to Use WOLFSSL_NOT_WINDOWS_API in Your Build

To leverage this new macro, follow these steps:

1. Modify Your Preprocessor Definitions:
   In your Visual Studio project settings, navigate to:
   • Configuration Properties → C/C++ → Preprocessor → Preprocessor Definitions
   • Add WOLFSSL_NOT_WINDOWS_API to the list.
2. Use CMake (if applicable):
   If you are using CMake for your build configuration, you can define this macro using:

   add_definitions(-DWOLFSSL_NOT_WINDOWS_API)

3. Manually Define in Your Code (not recommended):
   You can also define the macro at the beginning of your source files, though this is not the preferred method:

   #define WOLFSSL_NOT_WINDOWS_API
   #include 
   #include 
   

Example Use Case: Building wolfSSL for Linux from Visual Studio

Let’s say you want to compile wolfSSL in Visual Studio for a Linux-based target while avoiding Windows API dependencies. Here’s a step-by-step approach:

1. Set Up Your Toolchain
   Install a cross-compilation toolchain for Linux, such as MinGW-w64 or WSL with a Linux cross-compiler.
2. Update Your Visual Studio Project Settings
   • Define WOLFSSL_NOT_WINDOWS_API in preprocessor definitions.
   • Ensure that your include paths point to the correct non-Windows headers.
3. Compile and Verify
   • Build the project in Visual Studio.
   • Test the generated binary on the target Linux system to ensure it operates correctly.

Future Enhancements and Next Steps

This update is just the beginning of improving wolfSSL’s cross-compilation capabilities within Visual Studio. Some potential future enhancements include:

• Better integration with CMake toolchains for automated cross-platform builds.
• Expanded CI/CD support for Visual Studio-based cross-compilation.
• Additional optimizations to streamline the build process further.

Conclusion

With the introduction of WOLFSSL_NOT_WINDOWS_API, developers can now cross-compile wolfSSL in Visual Studio for non-Windows targets without encountering Windows API dependencies. This simplifies the workflow for embedded and Linux developers who prefer to work in Visual Studio but deploy on other platforms.

For more details on getting started with wolfSSL in Visual Studio, check out our previous blog: Getting Started with wolfSSL Using Visual Studio 2022

Or this awesome webinar recording on YouTube.

Have a specific request or questions? We’d love to hear from you. Please contact us at support@wolfSSL.com or open an issue on GitHub.

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

Download wolfSSL Now

Here at wolfSSL, we love making top notch examples for our customers to help them move faster. You can see a huge sample of them here.

That said, this one is a bit different. This is an example of how someone could integrate their new RNG into our wolfCrypt library. Here are some great reasons why you’d want to do that:

• You might have a NIST-certified entropy source which would be helpful for a customer that has FIPS 140-3 requirements. Since wolfSSL is FIPS 140-3 certified, combining it with a NIST-certified entropy source is a natural fit.
• Perhaps you have a special new RNG but do not have the man-power nor expertise to construct a cryptographic library to use it. (Rule #1: Never roll your own crypto!) In this case, integrating it with wolfSSL’s wolfCrypt library is a natural match to show real world use cases. Examples of this might be QRNGs (Quantum Random Number Generators) or any other new and interesting entropy generation methods.

Integrating your product into wolfCrypt might sound difficult, but it is NOT!

We show how easy it is by integrating a toy example of an RNG. Please see the patch that can be found as a github gist.

It is called the DEADBEEF RNG because when it is called to fill a buffer with randomness, it fills it with copies of 0xDEADBEEF. The diff is only 200 lines and is very simple to read and understand. Much of it is GPL boilerplate comments.

NOTE: Please do not use this patch. It is for illustrative purposes only! It provides zero randomness!

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

Download wolfSSL Now

The team at wolfSSL has taken the core functionality of the wolfSSL embedded SSL/TLS library to the next level and implemented changes to conform to the Required and Mandatory rules from the MISRA-C guidelines.

Currently a subset of the wolfCrypt modules are already covered for compliance, including detailed deviation documents (sha256.c, aes.c (CBC/GCM), rsa.c, random.c, sp_c64.c). Let us know if your project requires other files and we can target them while expanding coverage.

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 is continuously improving its support for DTLS (Datagram Transport Layer Security) to make it easier for developers to handle connection IDs and implement stateless DTLS services. In this blog post, we’ll explore the new APIs introduced in wolfSSL 5.7.6 that simplify these tasks.

DTLS is a variant of TLS designed for datagram-based transports like UDP. It’s widely used in IoT and real-time applications where packet loss and reordering are common. Connection IDs allow to tag each connection so that they can be maintained despite network changes, reducing rehandshake frequency and enhancing security with features like encrypted record types and padding for privacy. The wolfSSL stack allows the server to establish new connections in a stateless manner by not allocating any extra resources until the client can prove that they can reply to server packets. Managing CIDs and stateless operations can be challenging, but wolfSSL has introduced new features to streamline this process.

Demultiplexing DTLS messages for a server involves distinguishing between multiple client connections using a single socket. When data arrives on the socket, the server reads the packet and extracts the source IP address, port, and the connection ID. This information is then used to search through a list of active connections, matching the incoming packet’s source details with existing connections. The matching is done either based on the source address of the received datagram or on the CID found in the message itself. If a match is found, the data is processed by that connection. If no match is found, it attempts to establish a new connection. This method ensures each packet is correctly routed to its respective connection, allowing multiple clients to communicate over a single socket efficiently without dropping any packet.

wolfDTLS_accept_stateless

This function allows accepting DTLS connections in a stateless manner. It’s designed to use a single WOLFSSL object to listen to all new connections and indicate to the user when the WOLFSSL object has entered stateful handling and should no longer be used for new connections.

Example:

WOLFSSL* ssl;

do {
rc = wolfDTLS_accept_stateless(ssl);
if (rc == WOLFSSL_FATAL_ERROR) {
        	/* re-allocate the ssl object with wolfSSL_free() and wolfSSL_new() */
	}
} while (rc != WOLFSSL_SUCCESS);
rc = wolfSSL_accept(ssl);
if (rc != SSL_SUCCESS) {
	/* Handle error */
}

wolfSSL_inject

The `wolfSSL_inject` function allows you to inject application data directly into the WOLFSSL object, bypassing the usual IO calls. This is useful when data needs to be read from a single place and demultiplexed into multiple connections. The caller should then call wolfSSL_read() to extract the plaintext data from the WOLFSSL object.

Example:

int rc;
WOLFSSL* ssl;
byte data[2000];

sz = recv(fd, data, sizeof(data), 0);
if (sz <= 0) {
	/* Handle error */
}

/* Inject received data */
rc = wolfSSL_inject(ssl, data, sz);
if (rc != WOLFSSL_SUCCESS) {
	/* Handle error */
}

wolfSSL_dtls_set_pending_peer

This function is introduced to handle the peer address when using Connection IDs. It sets a pending peer that will be upgraded to a regular peer when the next record is successfully de-protected. This should be used with Connection ID's to allow seamless and safe transition to a new peer address. This function can be called for every incoming datagram or when an address change is detected.

Example:

WOLFSSL* ssl;
sockaddr_in addr;

rc = wolfSSL_dtls_set_pending_peer(ssl, &addr, sizeof(addr));
if (rc != WOLFSSL_SUCCESS) {
	/* Handle error */
}

wolfSSL_is_stateful

This function checks if the current SSL session is stateful. This can be useful for determining whether the listening WOLFSSL object is still waiting to be associated with a single peer or if it has already progressed to handling a single connection.

Example:

WOLFSSL* ssl;
byte isStateful;

rc = wolfSSL_accept(ssl);
/* rc might indicate failure when using non-blocking sockets */

if (wolfSSL_is_stateful(ssl)) {
	/* Session is stateful */
} else {
	/* Session is stateless */
}

wolfSSL_dtls_cid_parse

This function parses a CID from a DTLS message. This is useful for extracting and handling connection IDs in your application.

Example:

WOLFSSL* ssl;
/* DTLS 1.2 app data containing CID */
byte cid12[] =
"\x19\xfe\xfd\x00\x01\x00\x00\x00\x00\x00\x01\x77\xa3\x79\x34\xb3" \
"\xf1\x1f\x34\x00\x1f\xdb\x8c\x28\x25\x9f\xe1\x02\x26\x77\x1c\x3a" \
"\x50\x1b\x50\x99\xd0\xb5\x20\xd8\x2c\x2e\xaa\x36\x36\xe0\xb7\xb7" \
"\xf7\x7d\xff\xb0";
size_t cid_len = 8;

const unsigned char* cid = wolfSSL_dtls_cid_parse(cid12, sizeof(cid12), cid_len);
if (cid == NULL) {
	/* Handle missing CID */
}

wolfSSL_SSLDisableRead and wolfSSL_SSLEnableRead

These functions allow you to control the reading of data from the IO layer. `wolfSSL_SSLDisableRead` disables read operations, while `wolfSSL_SSLEnableRead` re-enables them.

Example:

WOLFSSL* ssl;

/* Disable reading */
wolfSSL_SSLDisableRead(ssl);

/* Perform some operations */

/* Re-enable reading */
wolfSSL_SSLEnableRead(ssl);

These new APIs in wolfSSL make handling DTLS connection IDs and implementing stateless services easier and more efficient. By providing direct data injection, pending peer management, state checks, and read control, wolfSSL continues to enhance its support for secure datagram-based communications. For more information about new and existing API visit our manual and take a look at our examples.

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

Download wolfSSL Now

The wolfSSL team is announcing the deprecation of the ARC4 cipher. This decision is part of our ongoing effort to simplify the wolfSSL codebase and focus on supporting the most secure and widely-used ciphers.

The ARC4 cipher has been shown to have significant weaknesses, including:

• Key biases and correlations
• Plaintext recovery attacks
• Increased risk of data breaches

Removing ARC4 will allow us to reduce the complexity of our codebase and devote more resources to maintaining and improving our supported ciphers.

Recommendations:

• Begin transitioning away from ARC4 and towards more secure ciphers, such as AES or ChaCha20.
• Consult the wolfSSL documentation and support resources for guidance on migrating away from ARC4.

We will provide additional information on the removal timeline in the future. If you have any questions or concerns about this deprecation, please don’t hesitate to reach out to the wolfSSL support team.

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

Download wolfSSL Now

In today’s digital landscape, the need for robust authentication mechanisms has never been more crucial. Among the various methods available, SPAKE (Simple Password-Authenticated Key Exchange) stands out as an enhanced security solution for authenticating users.

SPAKE represents a significant advancement over traditional password-based authentication, which often relies on static hashes. By leveraging a shared secret key, SPAKE ensures that passwords are never directly exposed during the authentication process, thereby mitigating risks associated with compromised credential storage.

The integration of wolfSSL into the Kerberos 5 implementation further elevates security by providing FIPS 140-3 certified cryptography. This compliance ensures that cryptographic modules meet stringent security standards, crucial for organizations prioritizing data protection and regulatory adherence.

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

Download wolfSSL Now

Ladies and gentlemen, it’s story time!!

Once upon a time, there was a network administrator that only wanted to use the strongest NIST-approved ECC encryption available within the TLS 1.3 protocol. They picked ECDHE over the secp521r1 curve. When they went to code their application, they wanted the best TLS library available so they naturally picked wolfssl.

In order to let their peers know that they wanted to use ECDHE over the secp521r1 curve with TLS 1.3, they used the wolfSSL_UseKeyShare() API during the setup of the connection. With this addition they thought they were done. Like any good software developer, they then tested their application against many servers and found that it worked as expected. Happy with the results, our security conscious network administrator began using their new application.

A little while later, during a network security audit, the consultant found that the application was on some occasions using ECDHE over the secp256r1 curve!! Flabbergasted, the network administrator demanded proof and the consultant showed him the wireshark transcripts. Low and behold, the transcripts showed that the server had sent a HelloRetryRequest handshake message requesting secp256r1. This was because the SupportedGroups extension in the ClientHello had advertised support for secp256r1 and that was the only curve that this particular server supported.

In the end, the solution was simple. Our network administrator called wolfSSL_set_groups() specifying only secp521r1. The next time he connected to the offending server, it simply refused the connection. Then our administrator upgraded that server to support secp521r1. Our hero and their application and servers lived happily ever after.

– The End –

Note this parable does not constitute a bug nor vulnerability in the wolfssl library. What happened was exactly how TLS 1.3 is supposed to work. This is a case of unintended consequences due to insufficient configuration.

Another possible more bullet proof solution is to compile out support for weaker ECC curves during the configuration of the wolfssl library.

This parable is especially relevant in the era of post-quantum cryptography. If you are trying to thwart the “harvest now, decrypt later” threat model and you are willing to sacrifice some interoperability, then you do not want to advertise support for conventional algorithms.

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

Download wolfSSL Now