Category: wolfSSL/ wolfCrypt

Summary

A critical security incident exposed KeyPlug malware infrastructure due to the improper use of wolfSSL test certificates in production. The 24-hour exposure revealed sophisticated attack tools linked to the RedGolf/APT41 threat group, demonstrating how poor certificate management can compromise even advanced threat actors’ operations.

The Certificate Failure

The compromised server was identified through its WolfSSL test certificate:

Subject Common Name: www[.]wolfssl[.]com
Subject Organizational Unit: Support_1024
Issuer Organizational Unit: Consulting_1024
SHA-256: 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF

Critical Issues

• Test Certificate Misuse
  • Production use of wolfssl.com test domain
  • Weak 1024-bit keys (indicated by “_1024” suffix)
  • Certificate sharing across multiple attack servers
• Security Impact
  • Exposed Fortinet exploitation tools and C2 infrastructure
  • Enabled infrastructure correlation through shared certificates
  • Compromised operational security of advanced threat actors

Best Practices for WolfSSL Implementation

To avoid security lapses like the one described, it’s critical to follow best practices when deploying wolfSSL in production environments. The following guidelines focus on certificate requirements, security controls, and monitoring techniques:

Production Deployments

• Certificate Requirements
  • Use only trusted CA-issued certificates
  • Implement minimum 2048-bit RSA keys
  • Maintain proper validation chains
• Security Controls
  • Never use test certificates in production
  • Implement certificate pinning
  • Regular certificate rotation

Monitoring and Detection

• Certificate Auditing
  • Regular infrastructure scans
  • Certificate inventory management
  • Automated validation checks
• Warning Signs
  • Domains containing “wolfssl.com”
  • Organizational units with test indicators
  • Key sizes below 2048 bits
  • Invalid trust chains

Recommendations

To mitigate risk and ensure strong certificate hygiene, both WolfSSL users and security teams should take immediate action. Below are tailored recommendations for each group:

Immediate Actions

1. For WolfSSL Users
   • Audit all certificates
   • Remove test certificates
   • Implement CA-issued certificates
   • Verify proper key lengths
2. For Security Teams
   • Monitor for test certificate usage
   • Implement certificate validation
   • Regular infrastructure scanning
   • Maintain certificate inventory

Conclusion

Organizations must maintain strict separation between development and production certificates and implement proper certificate management policies to prevent similar exposures.

Please do not use wolfSSL test certificates in production because the corresponding private keys are published as part of the wolfSSL source code package, so by design, these certificates are insecure. The test certificate private keys are public!

Source:

• KeyPlug-Linked Server Briefly Exposes Fortinet Exploits, Webshells, and Recon Activity Targeting a Major Japanese Company
• Exposed KeyPlug Malware Staging Server Contains Fortinet Firewall and VPN Exploitation Scripts

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

In the evolving landscape of cryptographic security, supporting multiple signature algorithms within a single certificate has become increasingly important. These certificates are known as Chimera certificates, a moniker coined by the X9.146 banking standards team. They provide enhanced security, flexibility, and agility, especially for the transition to post-quantum cryptography. As well, wolfSSL also understands the new TLS 1.3 CKS extension as defined by the X9.146 banking standard draft.

Chimera certificates are X.509 certificates that contain two public keys and signatures. These certificates are implemented through the use of three extensions:

• Subject Alternative Public Key Info (SAPKI): Contains an alternative public key
• Alternative Signature Algorithm: Specifies the algorithm used for the alternative signature
• Alternative Signature Value: Contains the actual bitstring of the alternative signature

In X.509 certificates, extensions can be marked as either “critical” or “non-critical.” Critical extensions MUST be understood and processed by the certificate validator. If a validator doesn’t recognize a critical extension, it MUST reject the certificate. Non-critical extensions can be safely ignored if not understood.

Before release 5.8.0, wolfSSL’s dual algorithm certificate implementation did not properly support the parsing of these extensions if they were marked as Critical. This was because the whole purpose of these extensions was to facilitate migration by allowing unmigrated systems to ignore the alternative public key and signatures. In that context, marking these extensions as critical made no sense.

That said, these extensions are standardized in the 2019 edition of the ITU-T X.509 standard. In that document, under recognition that there might be other future applications for these extensions, marking these extensions as critical is permitted.

The addition of critical extension support for Chimera certificates extensions represents an important compliance step. Without standards, interoperability would not be possible.

As the cryptographic landscape continues to evolve, especially with the ongoing transition to post-quantum algorithms, enhancements such as Chimera certificate support will become increasingly valuable. wolfSSL continues to demonstrate its commitment to providing a robust, standards-compliant, and forward-looking cryptographic library.

If you have question about any of the above, please contact us at >a href=”mailto”facts@wolfssl.com”>facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We are excited to announce that wolfSSL version 5.8.0 is now available. This release brings several important new features and improvements. Below are the key new additions:

New Features

• Implemented various fixes to support building for Open Watcom, including OS/2 support and Open Watcom 1.9 compatibility (PR 8505, 8484).
• Added support for STM32H7S (tested on NUCLEO-H7S3L8) (PR 8488).
• Added support for STM32WBA (PR 8550).
• Added Extended Master Secret Generation Callback to the –enable-pkcallbacks build (PR 8303).
• Implemented AES-CTS (–enable-aescts) in wolfCrypt (PR 8594).
• Added support for libimobiledevice commit 860ffb (PR 8373).
• Initial ASCON hash256 and AEAD128 support based on NIST SP 800-232 IPD (PR 8307).
• Added blinding option when using a Curve25519 private key by defining the macro WOLFSSL_CURVE25519_BLINDING (PR 8392).

ML-DSA and Post-Quantum Cryptography Enhancements

In line with NIST’s latest documentation, wolfSSL has updated its Dilithium implementation to ML-DSA (Module-Lattice Digital Signature Algorithm), which is fully supported in this release. Additionally, the release includes updates to further optimize ML-DSA and LMS (Leighton–Micali Signature) schemes, reducing memory usage and improving performance.

Linux Kernel Module (linuxkm) Updates

wolfSSL 5.8.0 expands support for the Linux Kernel Module (linuxkm), with several important enhancements to improve kernel-level cryptographic integration. This includes extended LKCAPI registration support for rfc4106(gcm(aes)), ctr(aes), ofb(aes), ecb(aes), and the legacy one-shot AES-GCM backend. Compatibility improvements have been added for newer kernels (?6.8), and calls to scatterwalk_map() and scatterwalk_unmap() have been updated for Linux 6.15. The release also registers ECDSA, ECDH, and RSA algorithms with the kernel crypto API and introduces safeguards for key handling, including forced zeroing of shared secrets. These changes make it possible to use more wolfSSL functionality in the kernel space.

For a full list of fixes and optimizations check out the ChangeLog.md bundled with wolfSSL. Download the latest release from the download page. 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

The NXP Application Code Hub, in collaboration with wolfSSL, now provides developers with a practical foundation for building secure IoT applications using NXP’s MCUXpresso VS Code extension.

This ecosystem combines NXP’s powerful microcontrollers with wolfSSL’s security libraries, all running on the Zephyr RTOS.

Available Initial Examples:

• wolfMQTT publisher client with zephyr
  • Implements a secure MQTT client for real-time data publishing.
• wolfSSH RGB server with zephyr
  • Features an SSH server with remote RGB LED control capabilities.
• wolfSSL tls hello server with zephyr
  • Shows basic TLS v1.3 server implementation with secure communication.

These examples are initially designed specifically for NXP’s FRDM-MCXN947 development board, but because they are using Zephyr they can easily be adapted to any board or chip supported by Zephyr and NXP!

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

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