{{Header}} {{title|title= Full Disk Encryption (FDE) }} {{#seo: |description=Full Disk Encryption, Additional Security Measures |image=Fulldeskencryption423423.jpg }} {{fde-mininav}} {{physical-mininav}} {{intro| 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. }} {{Contributor| |status=stable |about=About this {{Code2|{{PAGENAME}}}} Page |difficulty=easy |contributor=[https://forums.whonix.org/users/HulaHoop HulaHoop] |support=[[Support]] }} [[File:Fulldeskencryption423423.jpg|thumb]] = Introduction = == Essentials == {{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_Modeling|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 and Firmware Trojans|malware]]. == Encrypting {{project_name_long}} 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.
== Plausible Deniability - Deniable Encryption == {{fde}} software plausible deniability 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 negligible 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. https://defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm 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. https://embeddedsw.net/doc/physical_coercion.txt At time of writing (October 2024), there are no known ways to accomplish FDE with plausible deniability on any Linux distribution. This is because cryptsetup which is used for FDE on Linux doesn't support plausible deniability. Cryptsetup is an independent software project. Such a feature would need to be implemented in cryptsetup, which would be an extremely complicated development task. Cryptsetup, upstream feature request: [https://gitlab.com/cryptsetup/cryptsetup/-/issues/7 Plausible deniability support for LUKS] was rejected. For reasons, see [https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md?ref_type=heads#5-security-aspects cryptsetup FAQ] and search for {{CodeSelect|inline=true|code=Plausible Deniability}}. == 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 [https://www.eff.org/press/releases/digital-privacy-us-border-new-how-guide-eff EFF Guide] provides advice and outlines your rights at the border. Tips like storing key material in the cloud should be ignored. * A [https://www.cypherpunks.ca/~iang/pubs/shattersecrets-spw18.pdf 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. https://www.schneier.com/blog/archives/2009/07/laptop_security.html == Physical Access == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = 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. [[Full_Disk_Encryption#Plausible_Deniability_-_Deniable_Encryption|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|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. * https://security.stackexchange.com/questions/99906/can-ram-retain-data-after-removal * https://security.stackexchange.com/questions/99906/can-ram-retain-data-after-removal/100391#100391 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 [[Passwords#Generating_Unbreakable_Passwords|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. Debian's installer supports setting up FDE. = Kicksecure Hosts = The {{project_name_short}} [[ISO]] installer also supports setting up FDE. = 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, https://github.com/storaged-project/libblockdev/issues/416 https://github.com/vpodzime/libblockdev/commit/9dc4e2463860810cac5a1dbfb7064c47200260f6 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. {{CodeSelect|code= sudo ls /dev/ }} Create a LUKS container and change the device name as needed, then follow the prompts. {{CodeSelect|code= sudo cryptsetup --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat }} == 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. {{Box|text= '''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. {{CodeSelect|code= sudo ls /dev/ }} '''2.''' View the LUKS header data in order to make necessary adjustments. Run. {{CodeSelect|code= sudo cryptsetup luksDump --debug }} LUKS header data legend: * 'MK' means 'Master Key'. https://security.stackexchange.com/questions/109981/how-can-i-extract-the-encrypted-master-key-from-luks-header * 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. https://unix.stackexchange.com/questions/254017/how-to-interpret-cryptsetup-benchmark-results * 'Payload offset' is 4096 for 256-bit keys and 2048 for 128-bit keys. https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Re-encrypting_an_existing_LUKS_partition '''3.''' Re-encrypt the device with stronger keys. https://man.archlinux.org/man/cryptsetup-reencrypt.8 Fortunately, header resizing is usually unnecessary (otherwise it will abort the process). {{CodeSelect|code= sudo cryptsetup-reencrypt -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. https://asalor.blogspot.com/2012/08/re-encryption-of-luks-device-cryptsetup.html }} = 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 == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = As of the next point release in {{project_name_short}} 15, Zulucrypt is included by default. In the {{project_name_short}} 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 [https://www.dyne.org/software/tomb/ tomb files] and also capable of reading and creating Truecrypt / [https://www.veracrypt.fr/en/Home.html 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). https://github.com/mhogomchungu/zuluCrypt/issues/113 Until it is possible to use 20-word diceware passphrases to lock LUKS containers, it is recommended to use [[Passwords#Guidelines|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. https://crypto.stackexchange.com/questions/24022/luks-multiple-key-slots-whats-the-intuition For further usage instructions please consult the official [https://github.com/mhogomchungu/zuluCrypt/blob/master/docs/zuluCrypt.pdf 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. {{CodeSelect|code= sudo cryptsetup luksDump --debug /home/user/ }} 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 [[Full_Disk_Encryption#Plausible_Deniability_-_Deniable_Encryption|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 {{project_name_short}} developers. = Additional Measures = '''Table:''' ''Additional Protective Measures'' {| class="wikitable" |- ! scope="col"| '''Measure''' ! scope="col"| '''Description''' |- ! scope="row"| Anti Evil Maid | [[AEM|Evil Maid Attack]] |- ! scope="row"| Erase LUKS Header | This is a much quicker alternative to zeroing data on a HDD with [https://dban.org/ Darik's Boot and Nuke (DBAN)]. https://en.wikipedia.org/wiki/Darik's_Boot_and_Nuke DBAN also warns:
While DBAN is free to use, there’s no guarantee your data is completely sanitized across the entire drive. It cannot detect or erase SSDs and does not provide a certificate of data removal for auditing purposes or regulatory compliance. Hardware support (e.g. no RAID dismantling), customer support and software updates are not available using 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. https://superuser.com/questions/1168928/wipe-luks-partition-in-pre-boot/1177362 Replace /dev/sdXY with the encrypted partition. Reply YES to the prompt. {{CodeSelect|code= sudo cryptsetup luksErase /dev/sdXY }} Alternatively, to accomplish the same goal without being prompted, run. {{CodeSelect|code= 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 command. |- ! scope="row"| Killer | Killer https://github.com/Lvl4Sword/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. https://github.com/Lvl4Sword/Killer/issues/48 Once the program is packaged, it is intended to provide this software in the {{project_name_short}} repositories for Debian hosts. |- ! scope="row"| 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. https://github.com/vianney/arch-luks-suspend/issues/7 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. https://blog.freesources.org/posts/2018/06/debian_cryptsetup_sprint_report/ 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. https://blog.freesources.org//posts/2020/08/cryptsetup-suspend/ |- ! scope="row"| Magic Key Feature | In an emergency, [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]] 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. https://en.wikipedia.org/wiki/Magic_SysRq_key https://www.thegeekstuff.com/2008/12/safe-reboot-of-linux-using-magic-sysrq-key/ https://phabricator.whonix.org/T553 The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands. https://forums.whonix.org/t/full-disk-encryption-fde-emergency-shutdown-feature-testing-requested/2985 |- ! scope="row"| Nuke Patch for cryptsetup | * The Kali penetration testing distro team has written a [https://www.kali.org/blog/emergency-self-destruction-luks-kali/ nuke patch for cryptsetup], which adds the option to nuke all keyslots after a certain passphrase is entered; see footnotes. https://github.com/offensive-security/cryptsetup-nuke-keys In most emergency situations there will not be enough time to reboot the computer and enter the dead-man switch passphrase.
* 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. |- ! scope="row"| Encrypted /boot Partition | {{anchor|encrypted_boot}} 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 [https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/ Pwning Past Whole Disk Encryption]. Article [https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html 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. Considered not useful and [https://forums.whonix.org/t/fs-verity-in-linux-5-4/8911/30 measured boot] considered superior: * https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/2016912 Only GRUB supports encrypted /boot. Using GRUB to unlock /boot comes with several disadvantages. * No keyboard layout support: Only US keyboard layout is supported. Other local keyboard layouts are unsupported. If the user has chosen a full disk encryption password in calamares in their local keyword, chances are that this password will not work. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686817 * https://github.com/calamares/calamares/issues/1203 * https://savannah.gnu.org/bugs/index.php?65113 * No password feedback: No asterisk sign ("*") is shown during password entry. There is also no option to enable such a feature. The user must type the password "blind" without knowing how many characters have been typed already. * Slow decryption: Takes much longer to decrypt. * No retry: If the password has been entered wrong, GRUB drops to a recovery shell. The user might type (the first few) characters of its password again making it visible to anyone shoulder surfing. * Slow development: LUKS2 and Argon2 was unavailable in GRUB for a long time. * No dracut support: At time of writing (Debian 12), entering the password twice was required. Once for GRUB and once during initrd. |- ! scope="row"| 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. |- ! scope="row"| 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. |- ! scope="row"| TRESOR Kernel Patch | Another useful protection is the [https://en.wikipedia.org/wiki/TRESOR TRESOR] [https://www.cs1.tf.fau.de/research/system-security-group/tresor-trevisor-armored/ 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. https://security.stackexchange.com/questions/89301/was-tresor-integrated-in-the-linux-kernel/119835#119835 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. |- ! scope="row"| USBKill | * [https://en.wikipedia.org/wiki/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. For example, this can be done quickly if the flash drive is attached to your wrist via a lanyard. * https://github.com/hephaest0s/usbkill * https://en.wikipedia.org/wiki/USBKill * https://phabricator.whonix.org/T552 |- ! scope="row"| 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 PBKDF2See RFC 2898 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: {{CodeSelect|code= sudo cryptsetup luksChangeKey --iter-time 10000 }} * LUKS 2 (available with Debian Buster) added support for [https://www.cryptolux.org/index.php/Argon2 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 on LUKS can use up to four threads, but will lower the number and/or memory if the computer being used can't meet requirements. Argon2 iterations will vary depending on environment. {{CodeSelect|code= 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-memoryThe pbkdf-memory option is limited to 4194304 kilobytes. Memory is freed after the unlock operation. --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. |- |} = TPM = == Different Use Cases == === TPM Transparent Encryption === A common usability issue in systems without TPM transparent encryption is the need for multiple passwords: one for Full Disk Encryption (FDE) and another for [[login]]. In systems using TPM (Trusted Platform Module) for transparent encryption, the encryption key is securely stored within the TPM, and no pre-boot authentication is required. FDE is automatic, meaning the system can unlock the encrypted disk upon boot, using the TPM to manage the encryption key. The user only needs to enter a password at the login manager during the regular login process, rather than at boot. This enhances user convenience while ensuring the encryption key is protected by TPM's hardware security features. While TPM transparent encryption offers clear usability advantages, such as eliminating the need for pre-boot authentication, it also has potential vulnerabilities. * '''Advantages''': ** '''Improved Usability''': No more password input during pre-boot authentication, offering a seamless experience for the user. ** '''Disk Swap Security''': In the event of a hard drive failure or disposal, the data remains secure and cannot be recovered, provided the LUKS implementation follows best practices and the encryption algorithms used are not compromised. Since the encryption key is not stored on the disk itself (and is instead securely managed by the TPM or passphrase), even if someone obtains physical access to the discarded or damaged drive, they will not be able to decrypt or recover the data. ** '''Remote Password Entry''': It is possible to use FDE without needing pre-boot authentication where no networking is available. Useful for servers. * '''Disadvantage''': ** '''Cold Boot Attack Vulnerability''': TPM transparent encryption can be vulnerable to [[Cold Boot Attack Defense]], including both traditional "cold" boot attacks and "warm" cold boot attacks. *** '''Cold Boot Attack Overview''': A cold boot attack exploits the fact that encryption keys, including FDE keys, are stored in volatile memory (RAM) while the system is running. When the system is powered off or restarted, data in RAM does not immediately vanish but gradually fades. During this brief period, an attacker can quickly reboot the machine into a prepared environment or physically remove the RAM to read its contents using specialized tools. *** '''"Normal" vs "Warm" Cold Boot Attacks''': In systems without TPM transparent encryption, cold boot attacks can sometimes be mitigated by simply powering off the system. However, TPM transparent encryption introduces an additional risk: '''warm cold boot attacks'''. *** '''Attack Overview''': In this scenario, if an adversary gains physical access to a device using TPM transparent encryption, they can simply reboot the machine. Since there is no pre-boot authentication required, the system automatically boots, and the encryption key is loaded into RAM, making it susceptible to extraction. *** '''TPM Transparent Encryption & RAM''': In TPM transparent encryption, because no pre-boot authentication is involved, the system boots automatically, and the TPM releases the encryption key into RAM to decrypt the disk. Once the operating system is running, the key often remains in RAM to allow continuous access to the encrypted disk. *** '''Vulnerability''': Cold boot attacks exploit this by attempting to recover the FDE key from RAM after a sudden shutdown or reboot, bypassing the protection the TPM offers when the system is fully powered down. Since the encryption key remains in the system's memory during operation, an attacker can potentially extract it from RAM if they act quickly enough after the shutdown or reset. Where is the TPM? Either * soldered on the motherboard; or * inside the CPU; or * an external security key (FIDO2 security token). In case of a TPM stored inside the system (soldered or CPU): {{quotation |quote=Even though this sounds a lot weaker than the FIDO2/PKCS#11 model TPM2 still bring benefits for securing your systems: because the cryptographic key material stored in TPM2 devices cannot be extracted (at least that's the theory), if you bind your hard disk encryption to it, it means attackers cannot just copy your disk and analyze it offline — they always need access to the TPM2 chip too to have a chance to acquire the necessary cryptographic keys. Thus, they can still steal your whole PC and analyze it, but they cannot just copy the disk without you noticing and analyze the copy. |context=https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html }} External FIDO2 security token are more secure than built-in TPM because the user can more easily carry and/or hide them. === TPM as Additional Key === LUKS supports multiple keyslots. For instance, a keyslot 1 could be a password, keyslot 2 a keyfile and keyslot 3 a TPM. At each boot, the user could choose which authentication method to use. The use case might be to use TPM Transparent Encryption but have a backup password in case of TPM failure or hard disk migration to a different system. === TPM to Strengthen Weak Passwords === {{quotation |quote=TPM2 stuff to allow short (4 digits or so) "PINs" for unlocking the harddisk, i.e. kind of a low-entropy password you type in. The reason this is reasonably safe is that in this case the PIN is passed to the TPM2 which enforces that not more than some limited amount of unlock attempts may be made within some time frame, and that after too many attempts the PIN is invalidated altogether. Thus making dictionary attacks harder (which would normally be easier given the short length of the PINs). |context=https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html }} === TPM plus Password === https://x.com/mjg59/status/1420480679523930116 Unavailable in any Linux distribution. See comparison table below. == Complexity Risk == The integration of TPM introduces additional complexity to the system. While security is a crucial factor, it is not the only consideration. Usability and data safety are equally important, particularly in ensuring the user does not face complete data loss. The system's complexity should remain within the user's technical capabilities. If the setup or recovery process is too complex for the user, it could lead to unintended consequences, such as losing access to critical data. Therefore, the balance between security, usability, and data safety must be carefully managed. == Implementation Issues == {{quotation |quote=There's still plenty room for further improvement in all of this. In particular for the TPM2 case: what the text above doesn't really mention is that binding your encrypted volume unlocking to specific software versions (i.e. kernel + initrd + OS versions) actually sucks hard: if you naively update your system to newer versions you might lose access to your TPM2 enrolled keys (which isn't terrible, after all you did enroll a recovery key — right? — which you then can use to regain access. [...] Nothing updates the enrollment automatically after you initially enrolled it, hence after the first kernel/initrd update you have to manually re-enroll things again, and again, and again … after every update. |context=https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html }} == Security == Using full disk encryption with a strong password is more secure than using a TPM. {{quotation |quote=According to the researcher, targeted attacks can bypass BitLocker's encryption by directly accessing the hardware and extracting the encryption keys stored in the computer's Trusted Platform Module (TPM) via the LPC bus. |context=[https://www.techspot.com/news/101792-microsoft-bitlocker-encryption-can-cracked-43-seconds-4.html Microsoft BitLocker encryption cracked in just 43 seconds with a $4 Raspberry Pi Pico] }} {{VideoLink |videoid=wTl4vEednkQ |text=Breaking Bitlocker - Bypassing the Windows Disk Encryption }} * https://www.guru3d.com/story/researchers-expose-vulnerabilities-in-amds-firmware-based-tpms/ {{quotation |quote= '''Security implications''' As you establish an alternative unlock method using only the on-board hardware of your platform, you have to trust your platform manufacturer to do their job right. This is a delicate topic. There is trust in a secure hardware and firmware design. Then there is trust that the UEFI, bootloader, kernel, initramfs, etc. are all unmodified. Combined you expect a trustworthy environment where it is OK to automatically decrypt the disk. That being said you have to trust (or better, verify) that the manufacturer did not mess anything up in the overall platform design for this to be considered a fairly safe decryption alternative. There are a range of cases where things did not work out as planned. For example, when [https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network security researches showed that BitLocker on a Lenovo notebook would use unencrypted SPI communication] with the TPM2 leaking the LUKS passphrase in plain text without even altering the system, or that BitLocker used the native encryption features of SSD drives that you can [https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/ by-pass through factory reset]. These examples are all about BitLocker but it should make it clear that if the overall design is broken, then the secret is accessible and this alternative method less secure than a passphrase only present in your head (and somewhere safe like a password manager). On the other hand, keep in mind that in most cases elaborate research and attacks to access a drive’s data are not worth the effort for an opportunistic bad actor. Additionally, not having to enter a passphrase on every boot should help adoption of this technology as it is transparent but adds additional hurdles to unwanted access. |context=[https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/ Fedora Magazine: Automatically decrypt your disk using TPM2] }} * https://www.bleepingcomputer.com/news/security/new-tpm-20-flaws-could-let-hackers-steal-cryptographic-keys/ * https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/ == Resources == * https://github.com/QubesOS/qubes-issues/issues/9460 == TPM Full Disk Encryption Threat Modeling == To make good use of a TPM for full disk encryption, it is important define adversary goals and capabilities. Adversary goal: * Access contents circumventing the encryption. Adversary capabilities: * Can bruteforce weak user passwords? * Can steal the complete notebook? * Can steal any external USB drive? * Can steal an external mobile device (mobile phone) used for 2FA (two factor authentication)? * Can make a copy of the notebook hard drive without the user noticing? * Can make a copy of any external USB drive without user noticing? * Can perform a "warm" cold boot attack (as described above)? * Can sniff full disk encryption passwords using (hidden) cameras or laser microphones? * Can perform [https://xkcd.com/538/ 5$ wrench attack]? * Can break the TPM? * Can perform replay attacks as described [https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/ here]? * Can perform relay attacks as described [https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/ here]? It is tempting to answer all of these questions with "yes". But there is a catch. If "enough" ("the correct") questions are answered with "yes", then the adversary can accomplish its goal. Unfortunately, some answered must be answered with "no" for the user to remain secure. == TPM Encryption Comparison Table == {| class="wikitable" ! '''Security Feature''' ! '''FDE Password Only''' ! '''FDE Password + USB Keyfile''' ! '''FDE USB Keyfile Only''' ! '''FDE TPM Transparent Encryption''' ! '''FDE Password + TPM''' |- ! Cannot bruteforce weak user passwords? | {{No}}, susceptible to bruteforce if the password is weak. | {{Yes}}, keyfile adds significant entropy. | {{Yes}}, keyfile adds significant entropy. | {{Yes}} | {{Yes}} |- ! Secure if using a strong password? | {{Yes}} | {{Yes}} | {{Yes}} | {{No}}, due to "Warm" Cold Boot Attacks. | style="background-color: {{Yellow}}"| In theory, yes, but no such implementations exist in practice. There are currently no implementations that truly combine a strong user-provided password with the unsealed key from the TPM. This has significant disadvantages compared to FDE Password + USB Keyfile. Relying solely on TPM with a PIN or password is not the same as deriving a cryptographic key from both the password and the TPM. If the TPM is compromised - through physical tampering - the encryption is broken, even if the password is strong. This creates a single point of failure, allowing attackers to bypass password protections entirely once the TPM is compromised. Users of FDE Password + USB Keyfile benefit from enhanced security because the complete key is genuinely derived from both the user-provided password and the USB keyfile. This means that both components are required for decryption, adding significant entropy and making it much harder for an attacker to compromise the system. Unlike setups relying solely on TPM, this approach eliminates a single point of failure, requiring an attacker to break both the password and the physical key, which provides more robust protection. |- ! No TPM-Specific Risks or Vulnerabilities (Backdoors, Attack Surface, Data Loss)? | {{Yes}} | {{Yes}} | {{Yes}} | {{No}}, TPM introduces potential attack surface, is proprietary (non-freedom software), and is not as time-tested. | {{No}} (See left.) |- ! Not vulnerable to "Warm" Cold Boot Attacks (as defined above)? | {{Yes}} | {{Yes}} | {{Yes}} | {{No}} (Unless using [[Dev/confidential_computing|confidential computing]], which isn't really available with Freedom Software yet.) | {{Yes}} (Due to additional password required at pre-boot authentication.) |- ! Not vulnerable to "Normal" Cold Boot Attacks (as defined above)? | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} |- ! Not vulnerable to [https://xkcd.com/538/ 5$ wrench attack]? | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} |- ! Unattended server boot without needing to enter a pre-boot authentication password? | {{No}} | {{No}} | Where would the keyfile be stored? | {{Yes}} | {{No}}, requires user password for boot. |- ! Secure against sniffing of encryption passwords using (hidden) cameras or laser microphones? | {{No}} | {{Yes}} | {{Yes}} | Depends: * Server: Yes, because the user typically logs in over SSH. * Desktop: No, because the user must type the login manager password. | {{Yes}} |- ! Encryption Key Binding to Specific Hardware (TPM)? | {{No}} | {{No}} | {{No}} | {{Yes}}, key bound to device's hardware through TPM. | {{Yes}} (Same as left.) |- ! Protection Against Key File Being Moved to Another Device? | {{No}} | {{No}}, Keyfile can be copied | {{No}}, Keyfile can be copied | {{Yes}}, Keyfile tied to hardware. Discrete TPM (on motherboard) or External TPM Security Key both prevent simple copying, but discrete TPM is integrated while the external security key is removable. | {{Yes}} (Same as left.) |- ! Supports Multi-Factor Authentication (Password + External Device) | {{No}} (password only) | {{Yes}}, password plus USB key | {{No}} (USB key only) | {{No}}, then it no longer fulfills the definition of TPM transparent encryption. | style="background-color: {{Yellow}}"| In theory, yes. TPM can be combined with password and potentially other factors for multi-factor authentication - in theory - though support might require manual setup and maybe even development. At time of writing, no Linux distribution installer is known to support setting up true key derivation that combines both a password and TPM during installation. |- |} = Advice for Solid-state Drives and USB Storage = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = 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. https://web.archive.org/web/20201201150503/https://www.infosecisland.com/blogview/12153-Data-Remains-on-USB-and-SSDs-After-Secure-Erase.html https://www.theregister.com/2011/02/21/flash_drive_erasing_peril/ For instance, it is insecure to rely upon a fast erase mechanism by overwriting the header and key-slot area. [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ - Section: 5.19 What about SSDs, Flash and Hybrid Drives?] 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. See 'shred' manual page Wear-leveling mechanisms like TRIM also leak information about the filesystem that can aid forensics. https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29 https://wiki.archlinux.org/title/Solid_state_drive#dm-crypt https://web.archive.org/web/20160709174950/https://www.saout.de/pipermail/dm-crypt/2011-September/002019.html https://web.archive.org/web/20171122210051/https://www.saout.de/pipermail/dm-crypt/2012-April/002420.html https://web.archive.org/web/20150122113644/http://forensic.belkasoft.com/en/ssd-2014 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 tested by {{project_name_short}} developer HulaHoop. * Debian bug report: [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910249 Bumping up encryption to AES-256 by default] * Gnome disks utility upstream bug report: [https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/103 Bumping up encryption to AES-256 by default] (as of Debian stretch). However, this bug was fixed in Debian buster so it now provides adequate [[PQCrypto|post-quantum security]]. For encrypting removable media refer to this [[#Protection_Against_Powerful_Adversaries|guide]]. To install it, run. {{CodeSelect|code= sudo apt install gnome-disk-utility }} = See Also = {{physical-mininav}} todo 2fa = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]