whats the state of support for self-encrypting drives in CentOS 6 ? these are becoming increasingly common on both laptops and for enterprise storage (particularlly nearline), with features like instant-erase via key destruction.
Hello John,
On Tue, 2012-09-18 at 18:12 -0700, John R Pierce wrote:
whats the state of support for self-encrypting drives in CentOS 6 ? these are becoming increasingly common on both laptops and for enterprise storage (particularlly nearline),
From what I read on
http://www.trustedcomputinggroup.org/resources/commonly_asked_questions_and_... the key is randomly generated on board and gets encrypted with the "authorization key" when it's set, which I suppose is either or both of the master and user ATA drive passwords. On normal drives (non SEDs) these are used to lock and unlock the drive.
Since the key is stored (and generated) on the drive I/O should be transparent. I assume you just need to prime the SED by setting an "authorization key" with hdparm and unlock the drive on use. Although I've implemented most of the ATA security commands in hdparm I've never attempted to boot from a locked drive. You'd have to do a hdparm call in rc.sysinit and get the drive password before / is mounted.
with features like instant-erase via key destruction.
Would that be done using the security erase ATA command? Does it regenerate the key? Smart reuse of a command :) .
An ATA option to set the drive key - not just reset and regenerate it - would be desirable. (Master and user key commands could be repurposed to implement this. When implemented as a new ATA command there's an issue with syncing the master and user key x drive key crypts when updating the drive key.)
Please share any experiences and rc.sysinit patches when implementing this.
Regards, Leonard.
On Tue, 18 Sep 2012, John R Pierce wrote:
whats the state of support for self-encrypting drives in CentOS 6 ? these are becoming increasingly common on both laptops and for enterprise storage (particularlly nearline), with features like instant-erase via key destruction.
Management of Full Disk Encryption (FDE) drives is usually handled in BIOS or via central Windows application.
I've never installed FDE drives in servers, but they work well in laptops running Linux. We use BIOS-level passphrases (centrally escrowed, just in case), but we're a small shop. Performance seems within the realm of acceptable.
The encryption is always-on. That is, data is always encrypted when written to disk. Whether that data is readily readable depends on whether the drive's encryption key has been encrypted. Once the key is encrypted, a passphase must be presented to unlock it.
Once the key has been encrypted, the drive cannot be accessed unless connected directly to, say, the system's SATA bus. I haven't seen any mechanisms by which the key can be unlocked via things like external USB adapters.
Hello Paul,
On Wed, 2012-09-19 at 09:37 -0700, Paul Heinlein wrote:
Management of Full Disk Encryption (FDE) drives is usually handled in BIOS or via central Windows application.
Indeed. The scenario I mentioned of course does not work when one boots from the encrypted drive, only if one attaches it after the system has booted from another drive.
Once the key has been encrypted, the drive cannot be accessed unless connected directly to, say, the system's SATA bus. I haven't seen any mechanisms by which the key can be unlocked via things like external USB adapters.
As the interface for encrypting and locking an SED appears to be the same as for locking a normal drive using the security commands from hdparm should in theory work. This is assuming the BIOS pads passwords that are smaller than 32 bytes the same way as hdparm does, which is with NUL bytes.
Hdparm currently only accepts passwords as strings, so if the BIOS uses binary/hex strings for the password it could be problematic to unlock the same drive with hdparm. It should be quite simple to patch hdparm to accept hex strings as passwords though.
I have used drive (un)locking with hdparm on USB drives so (un)locking an external SED should be possible.
Regards, Leonard.
On Sun, 23 Sep 2012, Leonard den Ottolander wrote:
As the interface for encrypting and locking an SED appears to be the same as for locking a normal drive using the security commands from hdparm should in theory work. This is assuming the BIOS pads passwords that are smaller than 32 bytes the same way as hdparm does, which is with NUL bytes.
Hdparm currently only accepts passwords as strings, so if the BIOS uses binary/hex strings for the password it could be problematic to unlock the same drive with hdparm. It should be quite simple to patch hdparm to accept hex strings as passwords though.
I have used drive (un)locking with hdparm on USB drives so (un)locking an external SED should be possible.
Interesting. I'd never investigated hdparm as a drive-password interface. I'll certainly keep that in mind.
On Sun, 23 Sep 2012, Paul Heinlein wrote:
To: CentOS mailing list centos@centos.org From: Paul Heinlein heinlein@madboa.com Subject: Re: [CentOS] self-encrypting drives
On Sun, 23 Sep 2012, Leonard den Ottolander wrote:
As the interface for encrypting and locking an SED appears to be the same as for locking a normal drive using the security commands from hdparm should in theory work. This is assuming the BIOS pads passwords that are smaller than 32 bytes the same way as hdparm does, which is with NUL bytes.
Hdparm currently only accepts passwords as strings, so if the BIOS uses binary/hex strings for the password it could be problematic to unlock the same drive with hdparm. It should be quite simple to patch hdparm to accept hex strings as passwords though.
I have used drive (un)locking with hdparm on USB drives so (un)locking an external SED should be possible.
Interesting. I'd never investigated hdparm as a drive-password interface. I'll certainly keep that in mind.
IIRC there might also be a drive unlocking utility on the Ultimate Boot CD collection?
Kind Regards,
Keith
----------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------
Hello Paul,
On Wed, 2012-09-19 at 09:37 -0700, Paul Heinlein wrote:
Management of Full Disk Encryption (FDE) drives is usually handled in BIOS or via central Windows application.
I also expected unlocking at boot to be handled by the BIOS/UEFI, but according to http://www.trustedcomputinggroup.org/resources/commonly_asked_questions_and_... it is actually the drive that boots a mini OS/pre boot loader that asks the user for the password and passes the actual MBR back to the BIOS after the drive gets unlocked. Nifty.
Regards, Leonard.
-
John R Pierce -
Keith Roberts -
Leonard den Ottolander -
Paul Heinlein