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
