Linux Kernel Crypto Framework: Architecture, Data Structures, and Application in File System Encryption
The Linux kernel’s generic crypto framework, introduced in version 2.5.45, defines core structures such as crypto_template, crypto_alg, crypto_instance and crypto_tfm to dynamically register and combine algorithms (e.g., ecb(aes)), providing a uniform API for symmetric, asymmetric, hash and other primitives, supporting user‑space access via AF_ALG and practical use cases like Android file‑based encryption with built‑in self‑tests for correctness.
With the growth of the digital era, massive amounts of data are generated daily and users increasingly value the security of their personal data, making personal data more valuable than the devices themselves. The foundation of data security protection lies in the combination of a key and an encryption algorithm. The Linux kernel introduced a generic cryptographic algorithm framework (crypto) as early as version 2.5.45, providing a unified interface for various cryptographic operations.
The kernel crypto subsystem resides in the kernel/crypto directory and implements symmetric encryption/decryption, asymmetric encryption/decryption, authenticated encryption, hash, HMAC, DRBG pseudo‑random number generation, and compression algorithms. It offers a uniform data‑processing interface to other subsystems and can be accessed from user space via the AF_ALG socket mechanism introduced in Linux 2.6.38.
The framework is built around several core data structures: crypto_template (algorithm template registered at module init), crypto_alg (base class for algorithms, containing function pointers and attributes such as block size, context size, priority, and the cra_u union that abstracts four common algorithm types), crypto_instance (dynamic algorithm instance created from a template), crypto_spawn (part of a dynamically generated algorithm instance linking to crypto_alg ’s user list), crypto_type (used to override members of crypto_alg ’s cra_u for TFM initialization and information display), and crypto_tfm (transformation‑context instance holding key, IV, etc.).
When an algorithm such as “ecb(aes)” is requested, the kernel performs dynamic registration: if no matching crypto_alg exists, it locates the “ecb” template and the “aes” algorithm, combines them into a new crypto_alg instance, and registers it. The naming convention follows template(single block cipher) , e.g., cbc(aes) or ecb(des) .
A practical example is file‑based encryption (FBE) in Android 7.0+, where each file is encrypted with a unique key derived via the ecb(aes) algorithm using a master key and the file’s inode nonce. The process involves allocating a TFM for “ecb(aes)”, initializing it, setting the key, preparing a request with the plaintext, and invoking the asynchronous crypto_skcipher_encrypt operation.
To ensure correctness, the kernel performs static self‑tests for every algorithm at registration time (see testmgr.c ). Given known input and expected output, a mismatch results in test failure and aborts system boot if required by standards such as FIPS.
In summary, the Linux kernel crypto framework employs heavy abstraction and object‑oriented principles to provide a flexible, extensible, and maintainable cryptographic service layer, enabling both in‑kernel and user‑space consumers to leverage a wide range of algorithms through a consistent API.
OPPO Kernel Craftsman
Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.