Benefits of Hardware-based Full Disk Encryption and sedutil
We need to protect our personal or professional data, especially when located on laptops that can easily be stolen. Even if it is not yet fully widespread, many companies or personal users encrypt their disks to prevent such issues.
They are three major technologies to encrypt the data (most of the time, the same symmetric cipher is used:AES 128 or 256 bits) :
- Files-level encryption tools (7zip, GnuPG, openSSL...) where we encrypt one or more files (but not a full file system)
- Software FDE = Full Disk Encryption (dm-crypt, encfs, TrueCrypt under Linux ; BitLocker, SafeGuard under MS Windows among many others) where a full file system is encrypted. Most of these softwares map a real encrypted file system to a in-memory clear filesystem. For instance, you open an encrypted /dev/sda2 filesystem with dm-crypt/Luks this way :
sudo cryptsetup luksOpen /dev/sda2 aClearFileSystemName
<enter password>
mount /dev/mapper/aClearFileSystemName /mnt/myMountPoint
- Hardware-based Full Disk Encryption (also named SED = Self-Encrypting Disk) where hard disk encrypt themselves in their own build-in disk controller. We'll focus here on this technology.
To make it work, you need :
- a SED-capable hard disk or SSD (I for one own a Samsung 840 PRO and a 850 EVO that support it, most professional disks do).
- a compatible BIOS that support SED. You can then set a disk-level user password in the BIOS (and optionally an administrator password to unlock the user password). When the computer boots, the BIOS asks interactively for a disk password [1]. Note that many BIOS (especially on desktops or on non-professional laptops) doesn't support this feature because the constructor has not enable it (maybe to avoid customer complaints about password loss ?).
Once the correct BIOS disk password entered, the disk becomes totally 'open' (we say 'unlocked'), exactly like it has never been encrypted. None software is involved afterward. It is important to understand than a SED always encrypts the data. There is no way to disable this behavior (however, it doesn't cause any significant effect on the IO performance however because the IO volume is unchanged and because the disk controller comes with a build-in AES chipset). The real encryption key (MEK = Media Encryption Key) is located inside the disk itself (but cannot be accessed). The user password (named KEK = Key Encryption Key) is used to encrypt / decrypt the MEK. Keeping the disk password unset is like keeping a safe open : the data is still encrypted but decrypted when accessing the disk exactly as if none security system ever existed. When you set the user password, you close the safe door using your key. Note that there is no (known) way to recover a disk if you loose your password : you not only loose your data but you also loose your disk : it becomes a piece of junk from where none data can be read or written to.
I used dm-crypt (the default FDE software under Linux) for my own laptop until soon as I bought a SED-enabled Samsung SSD but I never managed to use them on my own computer because my AMI BIOS doesn't support this feature. The only option then was to use a software file system encryption. This works but comes with several complications or drawbacks :
- you need a /boot partition in clear to bootstrap the process. An attacker can easily alter this partition and add keyloggers for instance ;
- you have to change some kernel options and make sure to set the right modules loading order at startup or resume (ans keep them when updating the kernel) ;
- the TRIM SSD feature [2] is now supported by dm-crypt but it comes with security concerns ;
- you need dm-crypt commands on liveCD distros when performing system backups.
The only benefit of using software FDE I can think of is the possibility to check the cipher code source (when using an open source solution like dm-crypt of course). This is not the case of hardware encryption even if none severe issue has been reported so far AFAIK.
SED hardware-based disks are much simpler to use in comparison :
- you only have to set a BIOS password and it's done !
- you save a significant amount of CPU usage ;
- it is possible to destroy definitively a drive by changing its password once for all when decommissioning a laptop for instance (but it is also a drawback when the password is lost unintentionally).
But :
- once unlocked, the disk remains in this state while the computer is powered (this include while suspended on RAM). Login window doesn't change anything : an attacker can read the drive by plugging directly to the SATA port (DMA attack) and even worse ; [a warm reboot (a restart) keeps the drive open !]{.ul} It means that one can access the unlocked disk simply by inserting a Live CD/USB and rebooting the computer. The Live CD/USB is booted and all the drive data is available when mounted ! ; This is why, when using SED, [you should always hibernate]{.ul} (suspend-on disk) instead of suspending on RAM : when hibernating, the drive actually loses power and is locked again. Of course, you'll get the same effect when turning off your computer.
- you need a SED-capable BIOS. Note that you can also use the hdparm command to unlock a SED drive but it requires to boot a Live CD/USB. Then launch something like the command bellow and then restart your computer. However, it is not actually practicable ;
sudo hdparm --user-master u --security-set-pass 'pass' /dev/sdb
- if you loose the disk password, the disk is simply dead (but is may be a benefit as stated before) ;
- you may depend of a special BIOS manufacturer because it trims or hash the disk password (KEK). Another BIOS may use another algorithm. It means that moving a drive from a computer to another may lead to be unable to unlock the drive, even with the same password.
- because the operating system and its settings is not yet booted, only the QUERTY keyboard layout is available, you have to keep this in mind when choosing and typing it ;
- you have to trust the hardware security chipsets.
The OPAL specification published by the Trusted Computing Group (AMD, IBM, Intel, HP...) fixes some of these issues :
- you can always save the disk when loosing the disk password (of course, data is still lost, fortunately) thanks the PSID Revert function (the PSID is a number printed on the disk proving than you can physically access the drive) ;
- the KEK hashing and triming is now standard : the same drive could be moved from a computer to another :
- you can use SED even without BIOS support because OPAL comes with a mechanism called 'shadow MBR'. Basically, you flash a mini-OS (the PBA = Pre-Boot Authorization) up to 128MB to a dedicated area of the disk. This OS is provided to the BIOS when booting. A password window is then displayed. If the password is correct, the real MBR of the drive (the Master Boot Record = boot code) is then decrypted and executed. No more need for BIOS SED support and even better : a new open source OPAL implementation (sedutil) is available and its code source can be reviewed much more easilly than the BIOS binary firmware.
The new sedutil project comes with :
- some PBA images ready to flash to the drive
- the sedutil-cli command to administer the OPAL disk (setting up a drive in OPAL configuration, changing the password, PSID revert...) . Note that these commands requires to set libata.allow_tpm=1 to the kernel flags if run from an installed Linux. You can also, like me, use sedutil-cli from a rescue image booted from USB. See the list of commands. See also how to Setup a drive.
This worked perfectly for me and I now use my Samsung 850 EVO drive in SED OPAL mode. Note that sedutil doesn't support suspend on RAM (when resuming, the drive is as if it was dead, you'll get IO errors all over the place). Always use hibernation instead (as I already stated, it's the only safe way to use SED drives anyway).
[1] Note that it has nothing to do with the main BIOS user password that "protect" your machine (then your disk data is still in clear and can be read simply by moving it to another computer or by removing the BIOS battery)
[2] TRIM is used for SSD to free ASAP unused blocks and increase the disk lifespan.