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
mount /dev/mapper/aClearFileSystemName /mnt/myMountPoint
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 . 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  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 !
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).
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 :
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).
 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)
 TRIM is used for SSD to free ASAP unused blocks and increase the disk lifespan.
– blog_tech/benefits_of_hardware-based_full_disk_encryption_and_sedutil.txt · Last modified: 2018/05/31 14:19 by bflorat