Just a quick notice for those interested in using a Yubikey outside an OS, more precisely in Lenovo BIOS. With help from Yubico's customer service I learned that I should try to decrease the character output rate. I now did try full disk/ hardware encryption on a SSD again using a slot on a Yubikey to speeding things up and still having a strong password (32 characters). I can confirm that it is working fine. I decreased the output rate by 60ms. When decreasing the output rate on a Yubikey that is being used inside an OS (e.g. logon) one has to be a little more patient for all the characters to be transferred. I mention this because I had been used to the factory setting and at first confirmed the password too soon (wondering why it hadn't been accepted). Often there are only few characters displayed while in the background the rest of the 32 characters are being transferred. Be patient and observant. Things I learned the hard way: 1. Always type in your passwords manually, especially in "sensitive" environments like BIOS 2. if it works manually I can try password devices like a Yubikey (3. Get rid of the written password or store it in a safe place) Fortunately Samsung is making my SSD usable again, all data will be wiped in the process.
Yes, the implementation MSED uses relies on the 128MB "shadow MBR table" but that table can only be changed by someone with the drive password, if your attacker has the drive password they wouldn't need to inject a keylogger, your already compromised. I haven't tested every scenario with every drive but when the drive powers up the BIOS/whatever is presented with a pristine copy of the shadow MBR table. There MAY (untested, by me at least) be an attack vector if the attacker modifies the shadow MBR and then puts the computer to sleep instead of hibernating/powering off the computer. OPAL also allows you to define multiple locking ranges with different attributes, I use this feature to protect the "real" MBR and partition table from modification by defining it as write locked (read only) by default so this area can also only be modified by someone with the drive pass-phrase. Some vendors have also implemented what I would call "disconnect security" where if the SATA cable is disconnected the drive is immediately locked stopping hotplug attacks.
FYI: Some Samsung 800 series drives fail queued trim in Linux https://news.ycombinator.com/item?id=9723066 Also, the linked article is instructive.
Which article is that (sorry, so many links)? I do not use the trim command on my encrypted SSDs. Does that mean I don't have to worry? I use SSDs exclusively for Linux. I also applied the first 840 Evo patch for Linux. It went well.
I meant the OP article: https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ Yes, you're fine. Even using trim is fine. It's queued trim that fails. Windows can't do queued trim, so there are no issues there. But Linux can do queued trim, and it can zero out blocks that are still being used
Crucial also has FDE with Opal 2.0 and IEEE-1667 on it's SSDs since the m500.(Though note that their budget model BX100 is the exception.) Here's an article about Opal encryption drives that is being kept up-to-date: http://blog.michael.kuron-germany.de/2013/11/ssds-with-tcg-opal-or-ieee-1667-support/
Can't your write protection be circumvented by booting live with the drive attached? Why would the live OS respect those permissions? Firmware stored in a flash ROM is designed specifically in hardware to prevent writes without the key, while this MBR resides on an SSD which has no write protections of this sort (short of the traditional encryption I recommend).
MSED has been replaced by sedutil from the Drive Trust Alliance. https://github.com/Drive-Trust-Alliance/sedutil (sources: http://www.r0m30.com/msed , https://github.com/r0m30/msed)
