Disk Encryption
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
Disk Encryption
Disk Encryption is a security mechanism used to protect the data stored on a disk or partition. It uses cryptographic keys to ensure that encrypted data can only be decrypted and accessed when the required key is available. If the correct key cannot be obtained, the encrypted data remains inaccessible. When the root file system is encrypted, failure to obtain the required key may prevent the system from completing the boot process.
Several Disk Encryption implementations are available. One example is the Linux Unified Key Setup (LUKS), which is used on Linux-based systems, including embedded platforms such as NVIDIA Jetson. LUKS provides encryption at the block-device level, allowing the encrypted device to contain different types of file systems.
Disk Encryption can be implemented at different levels, including Full Disk Encryption (FDE) and filesystem-level encryption. Full Disk Encryption protects an entire disk or partition at the block-device level. Once the encrypted storage is unlocked, the operating system can access the data stored within it according to the normal file-system permissions and access controls.
In contrast, filesystem-level encryption can protect specific directories or files rather than an entire block device. Different encrypted areas can also be protected using different keys, allowing more granular control over access to sensitive data.
Depending on the system's security requirements, block-device encryption and filesystem-level encryption can be used independently or together. Combining multiple encryption mechanisms can provide additional separation for particularly sensitive data, but the appropriate approach depends on the system architecture, threat model, and key-management requirements.
On systems that include a Trusted Platform Module (TPM), the TPM can be used as part of the key-management process. For example, a key used to unlock encrypted storage can be protected, or sealed, by the TPM and made available only when specific platform conditions are met.
This can bind access to encrypted storage to a particular device or system state. As a result, removing the encrypted storage device and connecting it to another system would not, by itself, provide access to the protected key or encrypted data.
NVIDIA Jetson Implementation
In the case of NVIDIA Jetson platforms, disk encryption involves a Disk Encryption Key (DEK) and a passphrase or key-encryption mechanism:
- Disk Encryption Key (DEK): Also referred to as the master key, this key is used by the disk encryption mechanism to encrypt and decrypt data as it is written to or read from the encrypted block device. In a LUKS implementation, the master key is protected by key material derived from a passphrase or another key source rather than being stored directly in plaintext.
- Passphrase: An input used to derive key material that protects the disk encryption key. During the unlock process, the same passphrase is used to derive the required key material, allowing the disk encryption key to be recovered and the encrypted storage to be unlocked.
On NVIDIA Jetson platforms, disk encryption can use AES-XTS, a block-cipher mode designed for storage encryption. The cryptographic configuration, including key size, depends on the Jetson platform and disk encryption configuration.
Jetson platforms can also use hardware-backed security mechanisms to derive and protect key material used during the disk unlock process. This helps prevent sensitive key material from being directly exposed to the Normal World.
The disk encryption process used in this implementation is illustrated in the following figure:
This implementation uses a Trusted Application (TA) and Client Application (CA) pair to derive the passphrase used to unlock the encrypted storage. The passphrase is derived in the Secure World by the TA and then returned to the CA, which uses it during the disk unlock process.
On NVIDIA Jetson platforms, this disk encryption mechanism relies on OP-TEE to perform the secure key derivation process. Specifically, the TA used for this purpose is luks-srv, while the corresponding CA is nvluks-srv-app. Both components are part of NVIDIA's OP-TEE-based disk encryption implementation.
The Disk Encryption process is as follows:
- The nvluks-srv-app CA queries the per-device unique passphrase.
- When the luks-srv TA receives the command, it sends a request to jetson_user_key_pta to generate a unique LUKS key per device. The new key is derived from the EKB disk encryption key.
- The TA uses the LUKS key to generate a passphrase.
- The TA returns the output passphrase to the CA.
- The service is shut down, ensuring passphrase generation is done only once.
NXP i.MX95 Implementation
On NXP i.MX95 platforms running Linux, Disk Encryption can be implemented using the Linux device-mapper (dm-crypt) together with LUKS (Linux Unified Key Setup). The dm-crypt subsystem provides block-level encryption in the Linux kernel, while cryptsetup is used from user space to create and manage LUKS encrypted volumes. Pasted text Disk Encryption can be applied to a separate data partition or to the root filesystem. When a data partition is encrypted, Linux can boot normally and unlock the encrypted partition afterward. When the root filesystem is encrypted, an initramfs is required to unlock the LUKS volume before the actual root filesystem can be mounted. Pasted text A typical encrypted root filesystem boot process is as follows:
- The bootloader loads the kernel, Device Tree, and initramfs.
- Secure Boot authenticates the required boot artifacts, including the initramfs.
- The kernel starts the initramfs.
- The initramfs loads the required device-mapper and cryptographic support.
- The initramfs obtains the secret required to unlock the encrypted storage.
- cryptsetup opens the LUKS-encrypted root filesystem through dm-crypt.
- The decrypted mapping is mounted as the root filesystem, and the normal boot process continues. Pasted text
During development, the LUKS volume can be unlocked using a manually entered passphrase. However, an unattended embedded product requires a protected key-release mechanism. On an i.MX95-based system, OP-TEE or another hardware-backed security service can be used as part of such a design to prevent raw disk-encryption keys from being directly exposed to Normal World user space. The exact key-management mechanism depends on the BSP and product security architecture.
Disk Encryption limitations
The purpose of disk encryption is to prevent an attack from stealing or tampering with data on the disk. Even if the disk is physically unmounted (or, in the case of an internal device, such as an eMMC, is removed from the device), the data cannot be exposed or retrieved.
Due to the way it works, disk encryption cannot protect against the following types of threats:
- A background process or daemon that has a security hole. An attacker may use the hole to gain control of the process and access the disk.
- Theft or leakage of the login ID and password. An attacker can use these credentials to log in to the device and access the disk.