You are so right. FDE vendors - H/W or S/W should be more transparent.
The truth of this whole matter is that - regardless of hardware or software -
the implementation of the cryptography is the single most important factor. The
other side of this argument (bias stated that I AM a software encryption
vendor) is that customer should demand standards based cryptography,
cryptographic hygiene, and reviewed implementations.
It seems to me that solely 'trusting' either hardware or software for any
reason is what has generated this problem. I still routinely run into people
that think Microsoft Windows passwords are secure, That DES is more than
enough, and that TPM chips wholly manufactured in China are 'OK' to protect
your credentials when the attackers come from the same fabrication factory that
made the chips.
Point is, the customer is to blame in all this. Companies are not
committed to protecting their data beyond the 'checkbox' . Bitlocker and EFS
are great examples, how many exploits can you count against the platform before
you question the implementation?
So, Keep asking questions and demand answers, then - perhaps - secure
implementation will win over lowest cost or best marketing.
Regarding you question of how to protect the password, You can find the
answer in the common criteria review of any of the 'good' FDE implementations.
Answer is, they use the same mechanism that Windows or Linux uses, they use
username and password, HASH them with something like MD5 or (better) SHA256 and
then either store the value or encrypt another secret with it.
Regards;
Bryan
------------------------------------
Mobile Armor
Bryan E. Glancey
Senior Vice President & Chief Technology Officer
400 South Woods Mill Rd.
Suite 300
Chesterfield, MO 63017
http://www.mobilearmor.com/
------------------------------------
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Garrett M. Groff
Sent: Monday, May 18, 2009 9:05 AM
To: [email protected]; [email protected]
Subject: Re: [FDE] re how FDE is implemented at system layer
<snip #1>
Please don't tell me this is true. Seagate's own commissioned
study concluded that the standard ATA hard disk password was
not secure.
</snip>
I think the idea is that you can use ATAPI (via the BIOS) to lock either an FDE
drive or a
non-FDE drive. In the case of the non-FDE drive, you'll be using standard ATA
locking
(which can be bypassed with relative ease, apparently); in the case of an FDE
drive,
you'll be leveraging the more effective full disk encryption implemented on the
cryptographic ASIC within the drive enclosure. Doing a "reset" on that would
cause the
attacker to lose any chance of recovering the data on the disk. (Someone please
correct me
if I'm wrong.)
<snip #2>
Which begs the question, how do these software products protect
the password? I had thought they were doing it using the TPM
but now I don't think so.
</snip>
The TPM is used by software-based FDE products, like PGP and BitLocker (the
TPM, in
essence, acts as a "smart card" in the context of FDE). In contrast, I haven't
heard of an
FDE disk (such as Seagate's Momentus) that rely on anything outside the disk
enclosure
(wrt encryption or key storage). Instead, my understanding (again, someone
please
interject if I'm wrong) is that software that is "FDE harddrive-aware" can be
used for key
management purposes. This would be unnecessary for single users, but essential
for
enterprise deployment of FDE harddrives.
---
I think the bottom line is that FDE providers--s/w or h/w--should be more
transparent
about how their encryption is implemented. As potential buyers, people on this
list often
make decisions on what to purchase (or recommend for acquisition) based on
public
information about the product.
G
Scott S scott at u.washington.edu wrote in part:
(http://www.xml-dev.com/pipermail/fde/2009-April/001075.html)
<snip>
> And it is only when you set the password on the drive that you
> are taking advange of encryption security. And you don't need
> anything to do that either (more on this later).
<snip>
> Third, when you set the password and authenticate to the drive
> at the start of the computer, in essence, what you are doing is
> providing permission to the drive to use its secret encryption
> key to read and write the data.
<snip>
> Four, so how do you set the password on the FDE drive? There are
> two ways. The simple, cheap, and quick way is via the drive lock
> in the BIOS (not to be confused with the system BIOS password).
> For this you don't need anything else, just go into the BIOS and
> look for it under the hard drive or SATA section to set it. Once
> set, the password gets save on the drive so that if you were to
> connect the drive to a diffent computer, it will still ask for
> the password. The drive lock password is ideal for single users
> and don't need anything fancy.
Please don't tell me this is true. Seagate's own commissioned
study concluded that the standard ATA hard disk password was
not secure.
"Hard Drive Password(using ATA)
Minimal protection
Available on most notebooks and some desktops. Prevents the drive
from retrieving data unless the correct password is provided. Does
not encrypt any data. Easily defeated but requires specific skills
or hiring someone with those skills. Stronger than BIOS or OS
passwords but still weak protection and not suitable for data
worth more than US$100."
http://www.wwpi.com/summer-2007/2669-hard-drive-passwords-easily-defeated-the-truth-about-data-protection
http://seagate.com/docs/pdf/whitepaper/HDpasswrd_TP580-1-0710US.pdf.
All the fancy encryption on the disk isn't going to do any good
if the password unlocking it is easily recovered.
> The second way is via a 3rd party client software that you will
> have to purchase. Besides being more user friendly, the client
> software provide enhance features like password synchronization
> with OS, remote password reset, and multiple account access.
> For a company these features are must.
Which begs the question, how do these software products protect
the password? I had thought they were doing it using the TPM
but now I don't think so.
--
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security
_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde
_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde
