I want to get a SSD to replace the HDD in an old Acer Travelmate 5720 laptop with a Core 2 Duo T7300 2Ghz. The BIOS has an option to set a HDD password, which I believe means I should be able to use hardware encryption with a suitable SSD. I could either get the Samsung 850 Evo 128GB for £50 or the Sandisk X110 Enterprise 256GB for £65. Obviously the 256GB SSD is better value for money but I'd like to encrypt the drive and I'm not sure if it supports hardware encryption. I found a couple of press releases from last May which seem to suggest the X300 range was Sandisk's first to support hardware encryption. I don't want to use software encryption like Truecrypt as the CPU is relatively weak and I understand it can increase wear on the SSD. Does anyone know for sure whether the X110 supports hardware encryption? Otherwise I guess I'll just get the 850 Evo 128GB.
I could not find any info that the x110 supports hardware encryption. The EVO 850 supports hardware encryption. Panagiotis
Thanks for confirming. I'll get the EVO 850 then. Even if the BIOS doesn't properly support hardware encryption, it looks like msed will do the trick http://www.r0m30.com/msed
In order to enable hardware encryption, you need a TPM Security Chip, often not present in cheap consumer grade laptops as well as old ones. Your laptop was released before SSD's became prevalent, so I'm positive that the BIOS won't encrypt the drive. You'll need a laptop made from ~2011-present, with TPM, in order to trust the strength of the encryption. The tool you linked to mentions TPM 2.0 which is only a year old.
The author of msed has advised that it doesn't need a TPM chip, just Opal support, so I've ordered a 120GB Samsung 850 Evo as that does support Opal.
I just read http://vxlabs.com/2015/02/11/use-th...-disk-encryption-your-tcg-opal-ssd-with-msed/ and it does seem that msed does implement Opal properly in Linux! That is very cool I have an 840 Evo laying around, so I'll give it a go.
From my understanding of the article, this method relies on the presence of a 128mb unencrypted MBR on the SSD, which could potentially be altered to include a keylogger by somebody with physical access to the drive. This is my biggest gripe with the standard LUKS/dm-crypt with Grub, a keylogger need only be ~20kb in size and so will probably go undetected on the boot partition. The advantage of the traditional TPM setup is that the only unencrypted bootloader resides within the SSD/TPM firmware, which can only be written to with the OEM's private key. If I'm mistaken, please correct me...
OK, now I get that. Thanks. So what about a Linux implementation for SSD with TPM? Is it the lack of a trusted OEM that's problematic? And why do we trust OEMs, anyway?
The encryption is handled between the SSD controller and the TPM chip, it's completely independent of the contents of the SSD. So it can be used with Windows, Linux, Solaris, fat32 with a bunch of movies and no OS, etc. At least with my gear. Yes, ideally there would be an open firmware for both TPM and SSD firmware, but I doubt you'll ever see that. Even if an OEM is trustworthy, they can get pwned by the NSA just like Airbus did and that's how the private key could be compromised. In the real world, an encrypted SSD running Linux with LUKS is probably your safest bet, even if it's not completely perfect. If you're genuinely trying to keep something from the NSA that they really want to know, you might as well give up anyways
Thanks Do you know a list of relatively inexpensive hardware with TPM chips? Or a few examples? A how-to for TPM-SSD setup would also be great.
I recommend Samsung Pro 850 SSD's (2.5"). They're the best hardware encrypted SSD's out there right now IMO. If we're talking mSATA then Samsung 850 EVO. Samsung is making the best SSD's these days.
Any standard corporate laptop made since the first-gen of i5/i7 was released should have the feature, typically it's called "Secure Chip" in specs. Specifically, Dell Latitudes/Precisions, Thinkpads, and HP Elitebooks. New gear is pricy but staying a generation or two behind is fine, there's little or no performance improvement nowadays. I've read about some privacy concerns with the new TPM 2.0 so you might prefer the second-latest generation. As for brand of SSD, my thoughts are to stick with Intel. Most of the parts of these higher end laptops are going to be Intel anyways, and I figure consistency is a good thing. It's a pretty short how-to, all you need to do is set a hard disk password in BIOS, and then scroll over to check that "Secure Chip" shows as "Active."
OK, thanks So this is just the simple BIOS password thing, with TPM to secure it? And then, what's the vulnerability? Could adversaries get it with information from the OEM? Or the motherboard manufacturer? Or either? And of course, one could layer this with software FDE, as backup.
Pretty much, this is how hardware encryption is normally implemented, I don't understand your skeptical tone. What I can tell you is that enterprise gear definitely supports hardware encryption, big businesses with stringent security standards (banks, police forces, etc) use this setup with the same hardware. I don't think that most consumer laptop mobos fully support self-encrypting drives, you'd need to research more. My understanding is that the hashed passwords/keys are stored in both the TPM and the SSD controller, and the physical presence of both is required to unlock the drive. If Intel put some backdoor in their standard, we wouldn't know about it and it would probably only get used in very serious cases (read: ISIS, Al-Qaeda, Ed Snowden...) since if it were used for a regular prosecution, all evidence and how it was gathered is revealed and this would undermine the entire scheme. And of course, use LUKS as a secondary measure as I do agree that it's a bit more trusted. I view SSD encryption primarily as a method to protect my bootloader from being tampered with.
It's just that I've read so much about how weak BIOS passwords are. And I'm not technical enough to assess the security of the SSD-BIOS-TPM setup. Well, low-end enterprise Thinkpads with TPM are reasonably affordable. They ought to support it, right?
Yes to both. Not that long ago I bought an "old" Thinkpad for the latest Qubes OS. It had the Security Chip in active state by default. I read somewhere in the Lenovo forums that you do not need to set a password in order to "activate" the hardware encryption of a Samsung SSD but rather that it should work if supported. To be honest, I wasn't sure what to make of it. I didn't mind that much because I use the LUKS disk encryption. Reading about the hardware encryption in this thread awakened my interest again. So, the questions remain. My BIOS shows that the secure chip is active (no passwords set). If hardware FDE was not enabled would it make sense despite LUKS? Edit: Okay, the part about "activating" is very stupid. Of course, you'd need to set a password in order to make use of it. And yes, you can set a hdd password in the BIOS.
@mirimir Thinkpads are solid. Yes BIOS passwords like the supervisor or power-on can easily be removed by shorting the BIOS chip upon bootup, but according to https://support.lenovo.com/us/en/documents/ht002240 the SSD password is stored within the drive (hashed, in the firmware I believe), so it's not open to a simple reset. Read through what Lenovo says on that link, they don't go into too much detail but the OEM should know what they're talking about. Apparently they say that TPM does not prevent the drive from put in a different computer, this goes against what I've read elsewhere so I'll need to test this out myself.
Be very careful...I think I just bricked a hdd! I set a hdd password in BIOS with a Yubikey (static password). I did not set a masterpassword. Of course, I have to type in the password 2 times, so it must have been the same output. I saved and exited the BIOS. At the next startup I had to type in my password. So I plugged in the Yubikey and touched the button. Unfortunately it looked wrong from the start. The password seemed to be transferred „bumpy“ and it looked short. I counted the digits and sometimes there were 18, 19 or 20 digits. I know, there were 21 digits in the BIOS. Well, I wasn't pleased but I thought I could easily solve this by typing in the 21 digits manually. I couldn't. I don't know what was saved in BIOS but it doesn't seem like the password stored on my Yubikey. I tried several things that seemed logically to me (passwords from 15 to 21 digits) but who knows what happened. There might be something different completely. I have several Yubikeys for encryption and they never failed me (I have backups as well) but this is beyond me. I don't lose any data because I have backups but it looks like I am losing a hdd worth almost a 100 bucks. Damn it, why do I have to be so curious when it comes to stuff like this. :-(
I'm happy to confirm that I've been able to encrypt my 850 Evo on my Acer Travelmate 5720 using msed. I don't actually understand when the data on the SSD gets converted from unencrypted to encrypted, must be during one of the steps listed here I guess http://www.r0m30.com/msed/documentation/managing but it must be so quick that it's not noticeable. I did think it must be doing it when I did the --loadPBAimage step as that took about 30mins and I couldn't see how it could take that long just to write a small img to the shadow MBR but that's explained in the FAQ here http://www.r0m30.com/msed/documentation/faq#TOC-Why-does-it-take-so-long-to-load-the-PBA-
It's always encrypted. You're just changing the encryption credentials, something like a passphrase for a key.
That's true. I am still mad at myself but I guess it won't happen again in the future. I am trying to unlock the drive but I think it's not going to work. I should have entered the passphrase manually and then check if it's working from the Yubikey. Instead I did it the other way round. Turns out that the output rate that's originally programmed on a Yubikey is too fast for Lenovo BIOS. It's not working properly. I did notice the same behaviour with other Yubikeys. Slowing down the output rate via the personalization tool seems to be the solution of the problem. At least the exact amount of characters is transferred. Thus, and based on experience, the password should be transferred correctly. Fortunately I already learned to backup regularly, so no data has been lost. It still would be nice to at least be able to reset/wipe the SSD. But what I read, that is impossible. That's what does hurt. Nonetheless I think I am going to use this feature in the future but hopefully this time without botching things up.
Ah I see, so I guess it previously decrypted itself automatically using a key stored in the firmware and now I've changed it to a passphrase that I have to provide.
I guess it could be improved by having the unlocking program run from a USB stick, which can be kept on the person leaving less opportunity for it to be tampered with. If the bulk of the program has to run from the SSD's MBR but it can be started from a USB stick, a user set display phrase along with a hash of the SSD MBR, both encrypted with the SSD decryption passphrase, could also be stored on the USB key. Then the part of the program run from the USB stick could, after the passphrase is entered, decrypt the stored hash and verify it against the SSD MBR and if it checks out show the display phrase to confirm to the user that the MBR is untampered with.
