Introduction
This post has been sitting around in my drafts for about a year and a half. I have since abandoned this solution, preferring to encrypt my home partition only. But if someone finds it useful, I’ve published it here.
Background
Most solid state disks nowadays proudly claim that data is encrypted in the controller before being written to disk. But if no ATA password is set on the disk, then that encryption is not really of much use. All it does is prevent someone from disassembling your SSD and reading the data off the flash modules without the controller, and ensuring that a secure erase can be performed quickly. This is not much use for me, as I was trying to guard my data on my laptop against theft, while not compromising on performance.
One vital part of a proper security system is protecting “data at rest”, i.e. preventing data on your laptop from being accessed if it is lost or stolen while turned off. For this, Full Disk Encryption (FDE) is generally the best solution, but if your CPU does not support AES-NI, then implementing FDE on the operating system level can cause throughput to be painfully slow (around 40 MB/s through the encryption pipeline on my AMD E2-1800), and CPU intensive. Not ideal for a laptop, and having spent all that money on an SSD, very annoying to have to compromise between speed and security. Step forth the SSD controller, a small chip on your SSD that manages the interface between SATA and flash modules. Samsung’s newest SSDs use a triple-core ARM controller, so wouldn’t it be cool to offload responsibility for FDE to this controller, since it is already doing it?
Leaving aside issues of whether to trust your SSD vendor’s claims about a proper keychain of trust, I at least wanted to use the provided encryption of my solid state disk. The big problem I faced though was that my BIOS did not support setting an ATA password, nor did it support unlocking an already set ATA password (ATA passwords can be set and unlocked using hdparm on linux. But make sure you can boot a live USB disk to unlock it again if your BIOS turns out not to be able to unlock it, otherwise your system may be unbootable).
Solution
After a bit of thinking, my solution turned out to be:
-Ensuring my computer could boot a USB disk if the SSD was locked (check boot order in BIOS)
-Prepare a USB disk which would boot, run hdparm, ask for the password, unlock the SSD, and hand over to the linux installation on the SSD. Henceforth called the drive-unlock-stick (DUS).
-Set the ATA password on my SSD.
-Verify that the setup worked (it does)
-Test for additional problems caused (one big one: Suspend to RAM does not currently work properly, described below)
Preparing the “drive-unlock-stick” (DUS)
Firstly, consider that you will need this disk every time you boot your laptop. Either, you could use this opportunity to implement a form of two-factor authentication (to boot you need both the DUS and your password), or find a USB disk small enough that you don’t mind leaving it in your computer. I chose the latter, and for the added performance benefits of USB 3.0, bought a compact USB disk off amazon.
The DUS must be bootable, so set up syslinux. This involves making sure that the partition on the DUS has the bootable flag set (check with fdisk for example), copying the syslinux MBR onto the DUS, installing the syslinux bootloader, and writing the configuration file.
Next thing you need is a linux kernel and an initial ramdisk environment in which to run hdparm. I’m using Arch linux, so I scripted a hook that would load the drivers to interface with the disk (ahci in my case, but check using lsmod), load the drivers to eventually read the filesystems of my boot and root partitions on the SSD, ask for the password from the user, unlock the drive, do a bit of magic by unloading the driver again and reloading it, freeze the drive security, to prevent setting another password in the operating system, mount the boot and root partitions of the SSD, and hand over control to the original linux kernel on the SSD through a kexec call, from which point normal booting continues. This requires some work to get right, and my current solution still spews a lot of errors when the ahci module gets confused, and I think it has a 5 second timeout somewhere that slows it down quite a bit, but it works.
Since writing this post back in 2013, I seem to have lost the configuration files. But the above descriptions seem to sum the method up nicely.
jpamills 