1

... preferably without having to remove the drive from the laptop?

I'd like to explicitly test that data is indeed encrypted at rest on my SSD but can't think of a way; eg: even if boot my laptop off a Linux USB key without entering the hard disk password, I just won't see the drive. Can someone recommend a fool-proof test?

Background: I have a new laptop (ThinkPad X1 Carbon gen 5), which is supposed to come with an Opal SSD. My understanding - based on some rather terse manufacturer documentation - is that an Opal SSD encrypts at all times (it's supposedly not possible to switch it off) and that to prevent unauthorized access, I should set a "Hard Disk1 Password".

One of the issues I have is that the SSD manufacturer (Samsung) doesn't even bother providing any information on the Opal capability of the drive so for all I know, it could perfectly well store everything in plaintext.

  • 1
    I don't have an answer for you, but I am personally somewhat skeptical of self-encrypting drives much for the reason you have run into: there is no way to independently verify that the crypto is done, let alone done right. Unless, of course, you can bypass the device's firmware and gain access directly to the stored data. SED might add some non-negligible degree of data confidentiality, particularly in the case of decomissioning a marginal drive, but there's simply no good way to know. With software-based FDE, at least you can boot a different OS and run forensics software on your drive. – a CVn May 13 '17 at 21:00
  • Why can't you just boot into a live GNU/Linux distro and see what you can do with the drive, i.e. what do you mean "I just won't see the drive"? – multithr3at3d May 14 '17 at 4:44
  • @MichaelKjörling: indeed I've been using LUKS s/w encryption for my valuable partitions but I'm somewhat annoyed at the double encryption going on (and in particular the performance and SSD-wear impact). – sxc731 May 15 '17 at 20:00
  • @korockinout13: if I don't enter the hard disk password at startup, the drive is not made available to the OS at all, meaning there is no way to glimpse its - presumably encrypted but perhaps not - content... – sxc731 May 15 '17 at 20:00
2

You cannot independently verify the encryption function of OPAL drives because

  • the encryption and password-derivation happens transparently : you either have a password-protected disk which doesn't allow read requests or you can R/W freely after unlocking with the right password. Everything happens inside the disk. Even the BIOS/SATA controller hasn't got access to the encrypted datastream , password hashes , master keys etc. etc.

  • the firmware which handles password storage , key derivation and cipher setup is top secret

  • the manufacturers do not publish technical details or whitepapers on their implementations for reasons unknown

Software full-disk encryption (VeraCrypt , BitLocker) is fast , proven and trusted and the only mitigation for the truly paranoid.

  • That's probably fair enough for VeryCrypt as it's open source; less so for BitLocker where we have to trust Microsoft, which isn't much different from trusting manufacturers of Opal drives... It's really a shame that the Opal standard doesn't seem to cover the basic requirement for verifiable encryption - and agreed, this would still leave the issue of the opaque implementations... – sxc731 Oct 13 '17 at 8:20
  • 1
    @sxc731 The BitLocker source code is closed, but that does not mean you can't independently verify the specification. – forest Dec 24 '17 at 4:26
0

Since both Opal and ATA Drive Password (via BIOS) methods work by taking advantage of the SSD's inherent ability to hardware encrypt, not only are those methods reliable (assuming no "master password override" exists at the SSD maker or BIOS maker level), but they are impossible to crack once the SSD is powered off. Not so secure if the SSD is in sleep mode, though.

SSDs like EVO, Intel and the like essentially are always 'encrypting' via their controller chips...essentially data comes in, the controller 'randomly' places data someplace on the drive. However, without adding a password, this encryption is open (it's in a safe, but the door is left open) and not secure. Sure, adding an ATA Drive Password in the BIOS will give you no performance hit on the drive and ridiculous security (to the point where you lose the password, you're screwed...unless the BIOS manufacturer has a master password somewhere). The problem with the ATA Drive PW approach: if your machine fries, you need to find another one with a compatible BIOS to enter the password. For fun, do a search for which Mobo's have BIOS's that support ATA Drive passwords. A few do, but no one bothers to mention whether they do or not. Weird. As for Opal, I use Symantec Desktop Encryption for a single Win7 x64 Ultimate (Sophos WinMagic failed, Bitlocker was far too fussy to ever work, the boards are filled with problems initiating it in Win7 ultimate, though it may be easier in Win7) machine- since it works in preboot, there's a 5 second slowdown loading windows, and that's the only performance hit, since it uses the hardware encryption on the SED Samsung 840 EVO.

Bottom line, the hardware security of SED are so solid that you can't confirm the encryption because they are too well encrypted. This is why Mobo makers are nervous about making ATA BIOS passwords available...if the password is lost, all data is gone forever.

  • 1
    You keep saying things like "reliable" and "solid" without clarifications. What about those drives which use CBC mode with no ESSIV, or god forbid, ECB? – forest Dec 24 '17 at 4:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.