Why “Encryption at Rest” Can Still Leave a Disk Key in Server Memory

Encryption at rest protects data stored on a disk, volume, database file, backup medium, or other persistent storage. It prevents a person who obtains the powered-off storage device from reading its contents without the correct key. It does not prevent a running server from reading its own encrypted data after the volume has been unlocked.

A server must use a data-encryption key to read from and write to an encrypted volume. The storage device contains ciphertext. The operating system presents a usable filesystem by decrypting blocks as they are read and encrypting blocks as they are written. The data-encryption key, or a usable representation of it, must remain available to the component performing those cryptographic operations while the volume is active.

In a conventional Linux software-encryption deployment, dm-crypt provides transparent block-device encryption through the kernel’s device-mapper framework and cryptographic API. The active mapping requires an encryption key. The Linux kernel documentation describes the key as an input to the dm-crypt target, either supplied directly or retrieved through the kernel keyring. The kernel uses the key to process block I/O for the mapped device.

A typical volume-encryption design uses more than one key. A user password, recovery credential, TPM-protected secret, network-unlock credential, or key-management service may unlock a key-encryption key. That key-encryption key unwraps the volume’s data-encryption key. The data-encryption key then encrypts and decrypts the volume itself. Changing a user password usually changes the protection around the data-encryption key, not the key that encrypts every storage block.

The disk remains encrypted on physical storage while the volume is mounted. An attacker who removes the disk and does not possess the decryption key sees ciphertext. The security boundary changes after the server unlocks the volume. The host must be able to access the data-encryption key in order to perform normal reads and writes. If an attacker gains sufficiently privileged control of that host, the attacker may be able to obtain the active key or alter the encryption path that uses it.

A compromised host can create several key-exposure paths. An attacker with kernel-level access may inspect kernel memory, modify a device driver, intercept cryptographic operations, alter the storage stack, access key-management interfaces, or capture plaintext before it is encrypted and after it is decrypted. Administrative access alone does not always provide every one of these capabilities, but kernel compromise generally places the software encryption path within the attacker’s trust boundary.

The Linux cryptsetup documentation states that suspending an active LUKS mapping wipes its encryption key from kernel memory. The mapping must then be resumed with the key before I/O can continue. This behavior shows that the active key exists in kernel-accessible memory during normal operation and can be removed when the encrypted device is no longer active.

A TPM can strengthen the unlock process without necessarily removing the active volume key from host memory. A TPM can seal an unlock secret to measured boot conditions, device identity, firmware state, or Secure Boot policy. If those expected measurements change, the TPM can refuse to release the secret. Once a conventional software encryption stack unlocks and mounts the volume, the host still needs a usable data-encryption key for ongoing disk operations.

A hardware-backed key store can protect the stored form of a volume key and prevent offline recovery of the key from a disk. This is valuable protection against device theft, unauthorized boot changes, and some physical-access attacks. It is different from keeping the active data-encryption key outside the host operating system during normal use.

Encryption at rest protects against unauthorized access to stored ciphertext. It does not independently protect against an attacker who controls a server after the encrypted volume has been unlocked. NIST distinguishes between protection of stored information and broader data security controls, noting that storage encryption must be supported by key management, authentication, system security, and other controls.