[unisog] OT: Putting Encyption Functions in the HDDs
cstejerean at gmail.com
Thu Apr 27 23:46:30 GMT 2006
My problem with crypto magic dust relies on the fact that cryptography
only works when applied properly to the correct problem. If you need
more examples of crypto magic dust take a look at WEP and CSS for
DVDs. Both of these technologies were supposed to solve problems by
using crypto (secure wireless networks and protect dvd content) and
failed miserably. As I mentioned earlier take a look at work by Ross
Anderson to see other wonderful crypto devices that can be attacked in
- Cosmin Stejerean
On 4/27/06, Alan Amesbury <amesbury at oitsec.umn.edu> wrote:
> Saqib Ali wrote:
> > See the following for an links to articles that talk about this:
> > http://www.xml-dev.com/lurker/message/20060425.042414.0b74d6fb.en.html#fde
> >>From eWeek article:
> > -------------------------
> > The 2.5-inch drive offers full encryption of all data directly on the
> > drive through a software key that resides on a portion of the disk
> > nobody but the user can access. Every piece of data that crosses the
> > interface encrypted without any intervention by the user, said Brian
> > Dexheimer, executive vice president for global sales and marketing at
> > the Scotts Valley, Calif.-based company.
> Show me a section of a hard drive to which "nobody but the user" has
> access, and I'll show you a pretty useless section of a hard drive.
> That has to be inaccurate or incorrect reporting by eWeek.
> > "The user has to activate a password to access any data. In fact, the
> > operating system won't even boot up until the password is entered," he
> > said. "So if the computer is lost or stolen, even if they take the
> > drive out of the system, it won't do them any good because all of the
> > data on the drive is encrypted."
> This makes a bit more sense. I could very easily see something like a
> bootstrap program that has just enough logic to ask for a passphrase for
> a key that's been stored XOR'ed (or similarly obfuscated using the
> passphrase) on disk, then using the recovered key to decrypt the next
> boot phase, etc. I *think* products like PointSec work this way.
I believe the misunderstanding here is where the key is actually
stored. By stored on a section of the disk not accessible to anyone
but the user it means it is not stored on the magnetic plates that
make up the physical storage layer of the drive. Rather the key is
stored in some component of the board which controls the hard drive.
This is why you cannot access this from the OS (that's what they meant
by not accessible to anyone else). Before the board will allow you to
access the drive it will prompt you for the password, decrypt the key
and only then allow reads and writes to be performed on the drive.
This is very similar to the way hard drive passwords work today (most
recent notebooks have the ability to password protect a hard drive so
that you cannot use the drive if the password is not entered. This has
a failure mode however because you can swap out the plates in the disk
into another board and read the data that way. Encryption is meant to
deal with this failure mode).
> It still sounds a lot like the "magic crypto dust" Cosmin mentioned
> earlier in the thread.
I would like to see more public discussion and involvement of security
researchers before another other solutions claim to solve problems
using cryptography. Cryptography and related issues are pretty hard to
get right the first couple of times (MD*5*, SSL*2*, Kerberos *5*, NTLM
*2*, WPA*2* and the list goes on).
I think I wrote too much on this thread already so I think this would
be a good time for me to stop writing until someone finds a way to
break the encryption on this drive at which point we can resume the
discussion (or monolog).
> Alan Amesbury
> University of Minnesota
> unisog mailing list
> unisog at lists.sans.org
- Cosmin Stejerean
More information about the unisog