23

I'm in search of a free/libre software that is able to handle OPAL (2.0)-compliant SEDs (i.e. manage the setting of Pre-Boot Authentification (PBA) environment, encryption keys...).

It could be a utility that runs as a live image (thus OS-independant), or a client software that would work on GNU/Linux distributions. It would allow one end-user (not looking for fancy enterprise stuff) to manage the lock key (set, modify and delete the password used to encrypt the encryption key) and create the PBA.

hdparm is nearly what I'm looking for, but only works with ATA security features (no OPAL consideration, no PBA...), which can be troublesome with loosy BIOS (cf this blog post to understand how BIOS can screw up ATA password feature on SEDs).

The Trusted Computing Group (which edicts the OPAL standard) mentions a couple of "Independent Software Vendors" that handle OPAL SEDs, but most if not all of them require a Windows copy to be set up, or are aimed at large companies. I've been referred to SecureDoc's WinMagic Enterprise edition for its GNU/Linux compatibility and OPAL compliance, but I couldn't get in touch with their sales department because I don't have a "non-free"/corporate address (sure, why not).

More importantly, I don't trust closed ("proprietary") software for anything related to security. In those times of PRISM scandal and other large-scale impingements on privacy, it would be completely absurd to rely on opaque encryption technology proposed by a US-based company. Hence the search for a libre software which acts "in the clear" and whose source code can be reviewed and compiled for oneself.

If you do not know of such a software, any hints on how one could be produced? Start a crowdfunding campaign, make a request during a DefCon...? I'm just a normal end-user with no development skills, but I wouldn't mind participating in the funding of such a project.

Other interesting resource: SSDs with usable built-in hardware-based full disk encryption, a blog post with the most comprehensive info I could find on the topic of SEDs and FDE ;

ﾤ ﾡ
  • 148
  • 9
neitsab
  • 343
  • 1
  • 2
  • 7
  • 3
    "opaque encryption technology"...like the kind implemented in hardware? – Cory J Nov 15 '13 at 22:52
  • @CoryJ: Hum, you're probably right. My hope was that hardware following public specifications, like TCG's OPAL, would provide some sort of guarantee. But then one has to trust the certification process... Which is done by hardware manufacturers (see [link](http://www.trustedcomputinggroup.org/about_tcg/tcg_members) for TCG members). Ongoing news about Cisco backdoors etc. convinced me that hardware was fundamentally a layer one couldn't trust. Blackbox they say... It sure seems like so. I'll leave my question open though, as it first concerns an OPAL compliant libre software :) – neitsab Dec 10 '13 at 17:29

3 Answers3

7

A developer has started work on a GPL'd command line tool for supporting TCG Opal 1.0/Opal 2.0/Enterprise drives under linux and windows. It's in very early development (v0.02alpha), but I like what I see so far and I have done some testing for the developer.

Source: https://github.com/r0m30/msed

Binaries: http://www.r0m30.com/msed/files

Ali Ahmad
  • 4,784
  • 8
  • 35
  • 61
bhoar
  • 86
  • 1
  • 2
  • 2
    That project has partnered with the Drive Trust Alliance, moved repository location, and is now at v1.10, so sounds more stable. https://github.com/Drive-Trust-Alliance/sedutil – Chris Denning Dec 06 '15 at 14:23
5

The latest version of msed had been pushed to github with executables at www.r0m30.com/msed. The 0.20beta release has a PBA for bios machines and the ability to load it after activating the locking SP. I'm still developing some real documentation but the announcement contains some quick and dirty instructions for activating OPAL 2.0 hardware FDE using either Windows or Linux.

Michael Romeo
  • 51
  • 1
  • 1
  • Thanks for the update, it seems like I can finally accept the previous answer! It is really great of you to develop this needed software, hopefully accepting the answer will lead many people to try it out and help reporting bugs :) – neitsab Jan 30 '15 at 19:18
  • Mike has partnered with the Drive Trust Alliance (DTA) and future development of msed is moving forward with sedutil here: https://github.com/Drive-Trust-Alliance/sedutil – bhoar Nov 23 '15 at 15:35
1

You're smart to not trust black box security, but then that leaves software security. LUKS works, is well-regarded, and supports TRIM on SSD's.

Yes, you have to enter your password when you boot the machine (when it boots your /boot, actually). Having your BIOS know your password is closer to the 'convenient' side of the spectrum than the 'secure' one. Depends what your end goals are.

Bill McGonigle
  • 509
  • 3
  • 8
  • 1
    I realize I left that part out from my above comment: of course I didn't give up on encryption, I just went the software way ;-) dm-crypt/LUKS is doing marvels on this machine, thanks to AES-NI compatible processor. And if entering a password during boot is too painful, one can always use an external drive to store a keyfile... See [the Arch wiki](https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_Entire_System) for detailed instructions. However, that still leaves us with [Evil Maid attack](https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html) risks... – neitsab Mar 31 '14 at 11:09