Privacy in person
Information security on computers systems is a defensive battle on multiple fronts, with an emphasis on attacks against running systems. Surely this is where most of computer security is focused: networking, software (applications & services), and user accounts.
You find articles on our site about encryption for systems using:
This guide presents reasons why you should implement full disk encryption and considers the finer aspects. FDE allows you to fully protect information on your servers and desktops from prying eyes with physical access. Sometimes, even a rat deserves peace of mind
Get your hands off my data
Any good security professional knows the given physical access (possession) of something and enough time, any security can be broken. This is nothing new. Old school theft involving safes and such is much more successful when the safe can be removed offsite for performing lengthy, and relatively safe, extensive physical break-in techniques. The enhanced security of a bank vault compared to a home safe is the bank vault cannot be carried offsite!
Well, that has been simulated
Regarding our computer systems, physical access enables all kinds of useful and normal IT administrative functionality. We can root a mobile phone, reset an admin password, and repair an unbootable operating system. However, physical access to a computer can lead to serious compromises if the wrong persons get possession of our machine.
This will likely happen if you:
- Lose a laptop or other mobile device
- Sell or give a computer away and forget to secure-erase it
- Are targeted by an errant coworker, roommate, parent, or significant other
- Have someone that breaks into your house or office and steals your stuff
- Encounter an authority figure like law enforcement or government representative who confiscates your system
While the righteousness of the last one is well beyond the scope of this article and certainly CoolGeeks is not offering any legal advice, what follows in this guide can possibly allow you a sense of plausible deniability
Know it All: For a more serious and in-depth discussion of Deniable Files Systems, the academic article “Defeating Encrypted and Deniable File Systems: TrueCrypt v5.1a and the Case of the Tattling OS and Applications” (pdf) has further insight about the topic, especially the section 2 titled “Threat Model”
Something to hide, nothing to fear
The solution that allows us to protect our systems and data from inspection or compromise when physically accessed is Full Disk Encryption (FDE). This technology has been around for some time in various configurations. The basic idea is that all your data, and the operating system itself, are encrypted with some kind of password. The password is entered on the physical console during boot.
There are several ways in which this password encryption function can be implemented, with most techniques being some kind of trade-off between convenience and security. Is not that always the case? In a highly secure environment, the entire disk is encrypted and a password has to be entered during BIOS boot. Considerably less secure, a key is embedded in the motherboard BIOS and automatically invoked when the computer is booted –> note: that only protects if the hard drive is removed and installed in another computer for inspection, or if the operating system is compromised in a low-level manner from something like a rootkit.
For most styles of full disk encryption, some portion of the boot or BIOS process must be unencrypted in order to activate the decryption system for the main storage area. In the Linux world, this involves the bootloader, usually Grub, the kernel and initramfs from the
/boot directory or partition.
How many tweaks and enhancements we turn on or add to our FDE deployment just depends on our appetite for inconvenience
Worth Mentioning: There have been proven attempts to discern the encryption key of a running system by removing the RAM chip, freezing it to slow bit decay, and then dumping its raw data to search for the in-memory encryption key. This and similar techniques are called cold boot attacks
Let us get something straight
Before thinking of how to best implement any encryption on any kind of media, it is important to start with completely blank and sterilized media, even if it was just purchased. Primary storage areas are user-accessible such as a C: drive or
/ root partition, but there are also possible hidden areas on storage media used by the drive manufacturers to improve efficiency and reliability. If we do not ensure each and every single bit is erased to a known blank condition, we risk possible forensic recovery of a portion of our drive that was left unencrypted or yet to be overwritten with new encrypted data.
In the old-skool world of metal hard drives, this erasure can be reasonably accomplished with good old
shred in a command like this
shred -v -n 4 -z /dev/sda
Worst Case Scenario: By including the
-z flag to zero out all bits after randomly erasing them, there is no evidence of the secure erase. Without doing this, it would be possible for some person to mistake evidence of secure erase as evidence of encrypted data. A typical example would be a government security inspector say at customs or a happenstance police interaction. Some countries do not allow citizens to possess encrypted data. By securely erasing your data without the last step to zero all the bits, you could unintentionally draw a lot of un-resolvable attention; they think you have encrypted data and demand the password, but you know it is just data noise from secure erasing and there is no password, but you cannot prove that because forensically, random securely erased data looks just like encrypted data…
Solid results when erasing an SSD
When it comes to Sold State Drives, normal erase procedures are inadequate. Due to all kinds of intricate designs and exotic techniques to achieve their exceptional performance while maintaining high reliability and long life, an SSD tends to hide a lot of its internal functions from the end user. In most cases, the actual internal capacity of the SSD is significantly higher than advertised and accessible by the end user. Extra space is used for benefits like high-speed cache, wear leveling, garbage collection, error recovery, and device-specific encryption.
The problem in any attempt to securely erase an SSD is that if we use something like
shred in the same manner as with metal drives, we cannot be certain these internal SSD storage locations have been wiped and therefore some data may be left intact for possible forensic recovery. Best case, this is old encrypted data that would be inherently undecipherable. Worst case, an unmasked master encryption key used somewhere else remains on the drive.
Big Brain: A very nicely written and comprehensive treatise on the topic of securely erasing SSD drives and a scientific approach to assessing the quality of various techniques is the article titled Reliably Erasing Data from Flash-Based Solid State Drives (pdf)
So how to address the unique aspects of securely erasing an SSD?
Three suggested big-picture strategies:
- Always purchase an SSD as new and implement user-side encryption from the start. In the Linux world, this means formatting the SSD with LUKS using a strong passphrase or keyfile. If re-purposed later, the SSD can be reformatted with a reasonable expectation that any prior encrypted data yet to be overwritten is intrinsically unrecoverable and safe to ignore
- Never re-use an SSD that had valuable data stored unencrypted. Destruction with fire and/or physical shredding is the best method to dispose of them, being mindful of toxic materials. Note that degaussing does not work on an SSD!
- Utilize some kind of software secure erase operation. The remainder of this section discusses possible techniques
Flash Drives: All of this information applies to USB flash drives as well as ATA, PCI, or M.2 -connected Solid State Drives. However, with USB flash drives, many of the low-level techniques to ensure a quality secure erase are not available. The USB interface prevents direct access to the flash controller. With USB flash drives, our best strategies are #1 & #2 above. In general, USB flash drives should never have unencrypted data stored on them. If they have contained important unencrypted data, they must be physically destroyed because unlike an SSD, you cannot be reasonably confident a secure erase process has eliminated all important data on the flash drive – do not attempt to re-use them!
One idea is to overload the drive by writing a giant file to the SSD that is beyond its capacity, thereby forcing the SSD controller logic to overwrite any internal storage areas. Similar to
shred, another way is to write all binary 1’s to the drive in a command such as
tr '\0' '\377' < /dev/zero | dd status=progress bs=16M of=/dev/sda
Even so, we cannot be absolutely sure all internal areas of the SSD have been overwritten.
Another idea is to trigger the ATA command instructing the device to initiate an internal process securely erasing itself. Fundamentally this entails running these 2 commands below on your SSD. What actually occurs depends on how the individual SSD manufacturer chooses to implement the process. It appears very common that all the
--security-erase command does is erase and regenerate an internal encryption key (not exposed to the end user) used by the SSD controller for overall access to individual memory cells. By recreating a new internal key, the SSD controller cannot access any prior data still present in the memory cells.
hdparm --user-master u --security-set-pass PasSWorD /dev/sda
hdparm --user-master u --security-erase PasSWorD /dev/sda
Wishful Parameter: There is an additional command described by the ATA specification, called
--security-erase-enhanced, but it does not seem to be widely implemented among SSD manufacturers. In principle, this enhanced command is supposed to wipe all individual memory cells before wiping the internal access key
A nice article at Arch Linux details this process and some of the preliminaries involved to get an SSD into the “not frozen” state required for initiating a device-specific erase process. Apparently UEFI BIOS will “freeze” the drive. The easiest way to “unfreeze” the drive is to place the computer into suspend mode and then un-suspend without rebooting. This causes the SSD to change to the “not frozen” status
How much is enough?
Full disk encryption in Linux can be implemented in varying levels of increasing security:
- Only encrypt a
/datauser partition or drive. The decryption key can be a user-entered password or a keyfile stored in an unencrypted filesystem area, probably
/root, but using a keyfile this way only protects if the data drive is removed offsite without the encryption key.
- Encrypt the
/root partition or drive. The decryption key can be a user-entered password or keyfile stored in an unencrypted filesystem area such as
/boot. Again with the same caveat as above.
- Encrypt the
/bootpartition or drive. The decryption key is a password entered into Grub along with possibly additional keyfiles for other partitions or drives. Here we begin to obtain an end-to-end method for securing our systems
- Place some portion of the encryption details related to booting on an external storage drive. Most likely a USB flash drive. This would enable the highest tiers of secure FDE implementations. Effectively, we have a real physical “key” that must be inserted into our system to boot. In this case, we have a few options, again with increasing levels of security:
- Put only the encryption keyfile on the USB drive. For a LUKS implementation scheme, we can also put the LUKS header there; this is called a “detached header.”
- The USB drive is the
/bootpartition and contains Grub. The system could be compromised if the flash drive is found by a malicious 3rd party because it is unencrypted.
- The USB drive itself is encrypted and unlocked by password entered into Grub. No malicious person can compromise the system because the encryption keyfiles are stored on encrypted media
With a USB flash drive key containing the bootloader (grub), /boot partition, and keyfiles, AND using LUKS with detached headers, our main permanent physical drives with / root and /data can be raw disks without any partitions or even a partition table. To the unassuming, these physical drives are unused. Under a binary inspection, there will be no structure at all and they will appear only securely erased. In the operating specific full disk encryption guides presented on this site, we describe how to achieve this effect with Ubuntu/ext4/USB, Ubuntu/ZFS-root, and Mint/ZFS-root.
Absolutely, you must be aware that any physical or logical damage to the encrypted disk can permanently prevent access to your data. When using full disk encryption, many of our regular go-to tools for data recovery on damaged media are completely ineffective. Stuff like
fsck will not work.
Definitely any damage to your keyfile or forgetting the user-entered password will prevent ANY access to your encrypted data. All of these modern encryption schemes, when properly implemented, are perfect. As long as you choose a sufficiently complex passphrase and/or keyfile and keep them private, you are protected. There are no backdoors to an FDE drive!
You have been warned
MAKE BACKUPS: As with all things IT, backups (frequent, air-gapped, and offsite) are your only real protection. Backup completely, often, and make certain to backup your keyfiles and headers. Best to encrypt and physically lock up your backups too!!! Keep at least some of your backups air-gap’d offline. Think ransomware
If you question the need for full disk encryption given the complexity required to competently implement it…
Think about how you will feel when your computer is stolen or realize you forgot a laptop on the train