Full Disk Encryption (FDE)

Download Docs News Forums

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Your support makes all the difference!

We believe security software like Kicksecure needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 10 year success story and maybe DONATE!

• Full Disk Encryption
• Cold Boot Attack Defense
• ram-wipe
• Encrypted VM Images

Full disk encryption (FDE) is a way to protect the contents of an entire hard drive from unauthorized access. It works by encrypting all the data stored on the disk, including the operating system and applications. This means that if someone gains physical access to the computer or removes the hard drive, they won't be able to read the data without the correct password or encryption key. FDE can help protect sensitive information such as financial data, personal information, and trade secrets.

About this Full Disk Encryption Page This wiki page is maintained by a contributor.
Support Status	stable
Difficulty	easy
Contributor	HulaHoop
Support	Support

Introduction

Essentials

Full Disk Encryption (FDE) can protect data at rest from physical access such as a stolen hard drive in case a computer or notebook gets stolen. Data at rest means, that a full disk encrypted computer is powered off.

To provide sufficient security from password cracking brute force attempts, it is required to use strong passwords. See Passwords.

In an advanced threat model it is also required that the FDE key has also been already decayed from the computer's volatile memory (RAM) so it cannot be extracted from there either. See also Cold Boot Attack Defense.

Full Disk Encryption versus Malware

Full disk encryption is generally not designed to defeat malware.

Encrypting Kicksecure ™ VMs

This is currently unsupported and does not provide any additional protection. The Encrypted Images wiki page provides a detailed explanation, with the conclusion noting:

The host of security considerations suggest that an unrealistic set of operational rules are required to defend the integrity of a purely encrypted guest image. Use of Full Disk Encryption (FDE) is recommended instead.

Deniable Encryption

Such software is only effective in jurisdictions that have human rights and follow the rule of law. In scenarios where one might face indefinite detention or worse, it is actually better to avoid using plausibly deniable encryption feature. According to game theory, the adversary incurs a neglible cost by prolonging torture or incarceration for the captive while the reward of finally breaking the victim is much greater, in case there was actually anything to be found. In group scenarios, using deniable encryption is a strong disincentive against the captured member "defecting" to save themselves since they cannot prove to the captor their loyalty.

Measures Against Non-violent Coercion

Even in relatively civilized states, the laws have been misconstrued to make civil liberties protections at the border weaker. In the case of the US, the Fourth Amendment can be violated at will by customs officers. This section assumes a scenario where one is compelled to divulge passwords without measures involving physical harm or indefinite imprisonment. In such situations it is always recommended to exercise your right to remain silent and to request a lawyer. Your devices will most likely be impounded and therefore backups of important data should be made beforehand.

• This EFF Guide provides advice and outlines your rights at the border. Tips like storing key material in the cloud should be ignored.
• A clever technique (page 3) proposed by OTR's designer, Ian Goldberg, uses Shamir's Secret Splitting Scheme to split a key-file and distribute it among trusted friends to make producing the key a physical impossibility.
• Cryptographer Bruce Schneier outlines a simpler variant of the above technique. A new random string is added as a password and then passed along to a trusted person, with the usual password being removed before crossing the border. After arriving, the key to access the drive can be retrieved and the original one re-added.

Physical Access

It is safest to assume that a machine has been compromised after any unauthorized physical access.

If unauthorized access is strongly suspected or confirmed, the hardware should not be trusted or used after it is back in your possession. This scenario is only relevant to a small minority who are already targeted for physical surveillance. A sufficiently skilled adversary can infect it with spyware or sabotage it in a number of ways that are virtually undetectable. For example, malicious firmware could be installed to record all activities, or the machine rendered inoperable by bricking the hardware. In that eventuality, none of the measures outlined in this chapter will help.

Protection Against Powerful Adversaries

As noted above, advanced attackers have virtually limitless possibilities to infect a computer under their physical control, such as flashing low-level firmware or adding physical implants.

Plausible deniability and Full Disk Encryption (FDE) are also useless if subjected to physical abuse by a captor.

A safer option is to have not left any discoverable data traces on a personal machine in the first place. See Live Mode and Anti-Forensics Precautions.

To protect against theft of personal information or data, FDE should be applied on the host, and the computer turned off when exposed to higher-risk situations like traveling. In the case of laptops, the battery should be temporarily removed after powering off. This ensures that the RAM chips are completely powered down and that any encryption key(s) in memory are erased. See also Cold Boot Attack Defense.

Sleep mode:

• Hibernation is also a safe alternative because the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), so long as no changes were made.
• Suspend to RAM is insecure.

Be sure to follow the standard advice for picking strong and unique passphrases, so they cannot be feasibly brute-forced. Also, computers should never be left unattended in untrusted venues.

Debian Hosts

Configuring FDE during system install is straightforward. The default cipher is AES-256 in XTS mode.

Removable Media

New Removable Media

Gnome Disks Utility creates LUKS partitions with AES-128 by default which is insufficient in event of quantum computers materializing. This has been successfully reported and fixed upstream as of February 2019, but until it lands in Debian, an appropriately secure container must be manually created. Afterwards, unlock the device and format the internal filesystem as EXT4 in Gnome Disks.

First enumerate the device. They will usually be called 'sdb1', as sdaX is reserved for the system on default installs. To avoid confusion, only connect one removable device at a time. # ls /dev/

Create a LUKS container and change the device name as needed, then follow the prompts. # cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat <device>

Legacy Device Encryption Upgrade

It is safer to re-encrypt the device with a stronger key rather than performing a quick format that will otherwise leave the old/weaker header intact.

1. First enumerate the device.

They will usually be called 'sdb1', as sdaX is reserved for the system on default installs. To avoid confusion, only connect one removable device at a time.

# ls /dev/

2. View the LUKS header data in order to make necessary adjustments.

Run.

# cryptsetup luksDump --debug <device>

LUKS header data legend:

• 'MK' means 'Master Key'.
• AES in XTS mode uses a key size double its bit size (512 in this case) since in XTS the key is split in 2, resulting in AES with 256-bit keys.
• 'Payload offset' is 4096 for 256-bit keys and 2048 for 128-bit keys.

3. Re-encrypt the device with stronger keys.

Fortunately, header resizing is usually unnecessary (otherwise it will abort the process).

# cryptsetup-reencrypt <device> -c aes-xts-plain64 -s 512 --use-directio

Abruptly disconnecting power can cause data loss. To safely pause the process (in case of system sleep/shutdown), cryptsetup can be suspended (e.g. by Ctrl+C) and it will automatically restart from where it left off if temporary header files are present in the home directory.

Encrypted Containers

Encrypted containers have the twin advantages of flexibility and mobility of folders, allowing more files to be added on the fly without needing re-compression and re-encryption (as in the case of using GPG).

Zulucrypt

As of the next point release in Kicksecure ™ 15, Zulucrypt is included by default. In the Kicksecure ™ command line version, containers can be managed from the terminal with zulucrypt-cli.

Zulucrypt is the Linux answer to encrypted containers, making use of the reliable LUKS disk encryption specification. It is compatible with encrypted tomb files and also capable of reading and creating Truecrypt / VeraCrypt containers. Note that Veracrypt containers only support a maximum password length of 64 characters, but LUKS has a maximum value of 32,767 (although a recently fixed bug had limited it to only 100 characters). Until it is possible to use 20-word diceware passphrases to lock LUKS containers, it is recommended to use makepasswd to generate 43 character strings. These can then be pasted into a text file that is encrypted with GPG -- which does not have low character limits -- essentially creating a makeshift key file.

Containers grow dynamically as more data is added. Opened containers are mounted under /run/media/private/user. More than one password may be added for access, making use of LUKS' key slots feature behind the scenes.

For further usage instructions please consult the official manual.

Recommended Security Settings

Important Note: In order to have post-quantum resistance, the aes.xts-plain64.512.sha512 option is recommended for 256-bit encryption (the encryption key-size is split in two with XTS mode).

To view the container header, run. sudo cryptsetup luksDump --debug /home/user/<file_name>

With LUKS it is possible to nest containers of different encryption ciphers; for example, by placing a Serpent and Twofish container inside each other, wrapped in an outer AES one. Be sure to select the .xts-plain64.512.sha512 variants in all cases. Each inner layer should be 1 MB less than the outer layer to allow space for each container's respective encryption header.

The plausible deniability feature is available with volume types Normal+Hidden Truecrypt/Veracrypt. Veracrypt volumes support crypto-cascades as a feature, so manual nesting is unnecessary. However, be warned that Truecrypt/Veracrypt volume types only support AES-128. Plain dm-crypt containers with a non-zero offset can be used to provide hidden volumes according to Zulucrypt's manual. This is yet to be tested by Kicksecure ™ developers.

Additional Measures

Table: Additional Protective Measures

Measure	Description
Anti Evil Maid	Evil Maid Attack
Erase LUKS Header	This is a much quicker alternative to zeroing data on a HDD with Darik's Boot and Nuke (DBAN). This is an effective measure on spinning HDDs where wiped data is confirmed to be destroyed. The OS only needs to read the LUKS header off disk once – not every single second. Wiping the header makes the disk impossible to unlock in the future. Replace /dev/sdXY with the encrypted partition. Reply YES to the prompt. sudo cryptsetup luksErase /dev/sdXY Alternatively, to accomplish the same goal without being prompted, run. sudo dd if=/dev/zero of=/dev/sdXY bs=1M count=2 This will overwrite the first two megabytes of the partition /dev/sdXY, which should cover the entire LUKS encryption header for version 1. If you are using LUKS2 with cryptsetup version 2.1.0 (Debian Buster default) the default header size is now 16MiB. Previous cryptsetup versions used a 4MiB LUKS2 header. In that case, simply adjust the dd command: dd if=/dev/zero of=/dev/sdXY bs=1M count=16 (or count=4). Determine your header size with the cryptsetup luksDump --debug <device> command.
Killer	Killer is a newer project that supports a range of trigger actions to shutdown a system in the case of tampering (disallowed changes) with USB, Bluetooth, AC, Battery, Disk Tray, and Ethernet. In the future, custom commands will be supported besides shutdown. Once the program is packaged, it is intended to provide this software in the Kicksecure ™ repositories for Debian hosts.
LUKS Suspend Scripts	On Linux hosts, there is one interesting solution for the risks posed by a computer in a suspended state; luks-suspend scripts. This approach has some limitations because it is not yet packaged for Debian, and it has only been tested in the Ubuntu and Arch distributions. As of 2018, luks-suspend and keyslot nuking (mentioned below) is being merged upstream. As of 2020 cryptsetup-suspend is now available in Debian Bullseye and Buster Backports, requiring Linux 5.6+. Keep in mind that while it protects LUKS keys by removing them from memory, other sensitive keys (GPG and SSH) and documents opened since last boot will still be present and extractable from RAM. Other daemons need to independently support key sanitization on suspend for enhanced protection.
Magic Key Feature	In an emergency, Kicksecure ™ is capable of powering-off the computer immediately via the Magic SysRq key feature. This is invoked by pressing the key combination: Alt + PrintScreen + o (lower-case letter). On bare-metal linux systems, the FDE passphrase is prompted after rebooting. The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands.
Nuke Patch for cryptsetup	The Kali penetration testing distro team has written a nuke patch for cryptsetup, which adds the option to nuke all keyslots after a certain passphrase is entered; see footnotes. Supplying the dead-man switch as the "real passphrase" to the interceptors of the machine is unlikely to be an effective strategy. It is standard forensics procedure to create multiple images of the drive beforehand.
Encrypted /boot Partition	An encrypted /boot partition has some advantages but it's imperfect because the bootloader is still necessarily unencrypted. To read more on this subject, see Pwning Past Whole Disk Encryption. Article Full disk encryption, including /boot: Unlocking LUKS devices from GRUB might be helpful. https://stackoverflow.com/questions/3655516/does-encryption-guarantee-integrity https://github.com/QubesOS/qubes-issues/issues/2442 https://github.com/QubesOS/qubes-issues/issues/6151 A signed /boot partition (next point) however is more important than a encrypted boot partition.
Signed /boot Partition and Bootloader (Verified Boot)	Verified Boot in theory but not yet available for (security-focused) Linux distributions such as Debian, Kicksecure ™ and Qubes OS.
Separate /boot Partition	When FDE is used on the host, it is inadvisable to keep any (unencrypted) partitions such as the /boot partition and bootloader on that same physical media which resides in a notebook which is sometimes left unattended. High risk users should move the /boot partition to a separate USB (or other external) media and the bootloader (Grub) should also be installed on the separate USB.
TRESOR Kernel Patch	Another useful protection is the TRESOR kernel patch, which keeps the disk encryption key outside of RAM by storing it inside the CPU. TRESOR does have several limitations. It is only available for the x86 architecture, and it complicates software debugging by disabling DR registers for security reasons. Moreover, a specialized attacker who can reverse engineer hardware designs is also capable of extracting secrets held in processor caches or specialized chips like TPMs.
USBKill	USBKill is an anti-forensics script written in the aftermath of the SilkRoad trial. Its purpose is to trigger protection events that prevent adversaries from siphoning files, installing malware, or running a mouse jiggler. The script creates a white-list of allowable USB devices. If anything else is plugged into the machine, the RAM is erased and the computer is immediately shutdown. USBKill can also be configured to exclude all devices from being attached. In another high-security configuration, a white-listed flash drive serves as a key, and must be in the USB port at all times. If the flash drive is forcibly removed, the program will initiate the desired routines.
Increase Costs of Brute-Force Attacks	Encryption software uses Password-Based Key Derivation Functions (PBKDF) to slow down access attempts and provide some protection against low-entropy passphrases. Higher wait times, or iterations, can often be used. Iteration values are low by default for impatient users and weak processors, also making systematic attempts to access such protected data much easier for unauthorized users. Choosing how long wait times should be should depend on how long you are willing to wait to access your own data and how long someone else should wait if they try. Computing power gets cheaper with time, so what works today might be weak in the future. LUKS version 1 uses PBKDF2 and allows the option --iter-time (or -i) for the LuksFormat, LuksAddKey, and LuksChangeKey commands. Iter-time is measured in milliseconds, so ten seconds would look like: $ sudo cryptsetup luksChangeKey --iter-time 10000 <device> LUKS 2 (available with Debian Buster) added support for Argon2i/Argon2id. In addition to processor time, Argon2 iterations use RAM and can be multi-threaded, making it difficult for hash bruteforcing using graphics cards. Argon2 iterations will vary depending on environment. $ sudo cryptsetup benchmark will show you how many iterations could be made in a requested 2000 ms. To customize wait times, specify (with values) --pbkdf --pbkdf-force-iterations --pbkdf-memory --pbkdf-parallel (number of threads) when using the LuksFormat command. Be aware that incorrect values can make wait times extremely long. Veracrypt improved upon TrueCrypt's iterations when performing operations on volumes.

Advice for Solid-state Drives and USB Storage

In the case of flash-based storage like solid-state drives (SSDs) and USBs, the only way to protect data is to never store it unencrypted in the first place!

Unlike hard-disk drives (HDDs), overwriting data on SSDs is no longer effective in wiping the disk. For instance, it is insecure to rely upon a fast erase mechanism by overwriting the header and key-slot area.

The most dire potential consequence would that old passwords are not erased, and for a significant period. Consider the following concrete example: someone changes their computer password because they noticed it was exposed to shoulder-surfing or CCTV. On a SSD, the old password may still be retrievable. If so, it could be used to decrypt the master key and all data. Secure overwriting is only guaranteed with magnetic disks that use non-journaling filesystems.

Wear-leveling mechanisms like TRIM also leak information about the filesystem that can aid forensics. It is strongly recommended to keep TRIM disabled (the default) during Linux LUKS-encrypted installations.

Gnome Disks Utility

Gnome Disks utility provides a convenient way to manipulate LUKS container passphrases (including the host's) and the overlying filesystems. Previously, it could not be relied upon for encryption because it used AES-128 as a hardcoded default (as of Debian stretch). However, this bug was fixed in Debian buster so it now provides adequate post-quantum security. For encrypting removable media refer to this guide.

To install it, run.

sudo apt install gnome-disk-utility

See Also

• System Configuration and Access
• Protection Against Physical Attacks
• Hardware Threat Minimization
• Full Disk Encryption
• Virtualization Platform Security

Footnotes

---

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

Kicksecure ™ A secure by default operating system with the latest security research in place.

Donate

Follow us on social media

FREE  ·  PLUS  ·  PREMIUM Support

Dark mode

At Kicksecure we believe in freedom and trust. That's why we fully support Open Source and Freedom Software.

Kicksecure ™ is supported by Evolution Host DDoS Protected VPS.

The personal opinions of moderators or contributors to the Kicksecure ™ project do not represent the project as a whole. By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service , Privacy Policy , Cookie Policy , E-Sign Consent , DMCA , Imprint Kicksecure ENCRYPTED SUPPORT LP, 2023

Donate

Kicksecure is free from corporate interest by being user funded. Thank you so much!

Scan the QR code or use the wallet address below.