FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-19-2012, 01:12 AM
John R Pierce
 
Default self-encrypting drives

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.


--
john r pierce N 37, W 122
santa cruz ca mid-left coast

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-19-2012, 02:56 AM
Leonard den Ottolander
 
Default self-encrypting drives

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_answers_on_selfencryp ting_drives 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.

--
mount -t life -o ro /dev/dna /genetic/research


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-19-2012, 04:37 PM
Paul Heinlein
 
Default self-encrypting drives

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.


--
Paul Heinlein
heinlein@madboa.com
4538' N, 1226' W_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-23-2012, 01:29 PM
Leonard den Ottolander
 
Default self-encrypting drives

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.

--
mount -t life -o ro /dev/dna /genetic/research


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-23-2012, 03:12 PM
Paul Heinlein
 
Default 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.

--
Paul Heinlein <> heinlein@madboa.com <> http://www.madboa.com/
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-23-2012, 05:44 PM
Keith Roberts
 
Default self-encrypting drives

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]
-----------------------------------------------------------
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-23-2012, 05:54 PM
Leonard den Ottolander
 
Default self-encrypting drives

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_answers_on_selfencryp ting_drives 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.

--
mount -t life -o ro /dev/dna /genetic/research


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org