Bruce Schneier

 
 

Schneier on Security

A blog covering security and security technology.

« Beyond Fear Review | Main | Interview with Marcus Ranum »

June 27, 2005

Seagate's Full Disk Encryption

Seagate has introduced a hard drive with full-disk encryption.

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.

Here's the press release, and here's the product spec sheet. Ignore the "TDEA 192" nonsense. It's a typo; the product uses triple-DES, and the follow-on product will use AES.

Posted on June 27, 2005 at 7:24 AM40 CommentsView Blog Reactions

To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.

Comments

Full disk encryption is not new IBM fielded one as a prototype some time ago (about 5 years I think).

Guess what one of the reasons quoted for using it was what we now call DRM...

Posted by: Clive Robinson at June 27, 2005 7:33 AM


There's a company here in the UK that have been doing this for a while, called Stonewood (http://www.stonewood.co.uk/electronics/products/flagstone/index.html)

For Government types they do a CAPS version.

Posted by: Nick Barron at June 27, 2005 7:44 AM


Had a look on the web and you might also want to read the artical that caused me to hunt the IBM disk proposal out originally,

http://www.theregister.co.uk/2000/12/20/stealth_plan_puts_copy_protection/

Posted by: Clive Robinson at June 27, 2005 7:46 AM


Here's another UK site, one that sells a full range of hardware-encrypted disks:

http://www.amacom-tech.com/encryp2disk.html

Posted by: Louis Dice at June 27, 2005 8:24 AM


Any chance they'll produce a version where (1) the decrypted data on the disk varies according to which key is used, and (2) there is no way of telling how many valid keys there are?

Posted by: Phil Hunt at June 27, 2005 8:36 AM


Two things interest me here... (1) The key is password protected and no one but the user can access it. I wonder... How robust is this mechanism? E.g. Is there a lost password recovery or reset procedure? (2) The potential marketing is intersting too, in the eWeek article an industry analyst said that public disclosure wouldn't be required if a drive were lost that contained personal information.

Posted by: Sue Donym at June 27, 2005 8:55 AM


"Any chance they'll produce a version where (1) the decrypted data on the disk varies according to which key is used, and (2) there is no way of telling how many valid keys there are?"

That's very hard to do securely. I call it "deniable encryption," and for many threat models it is impossible.

But no, I don't expect it in products any time soon.

Posted by: Bruce Schneier at June 27, 2005 9:10 AM


I remain extremely skeptical about products like this. I much prefer using filesystem encryption at the OS level where I feel I have much more control. Also, the text "a software key that resides on a portion of the disk nobody but the user can access" sets off alarms in my head.

Encryption should be transparent, but to a point. When it's at the point where I'm unsure it's even happening, that's much too transparent.

Posted by: Jay at June 27, 2005 9:57 AM


The unanswered question here, in terms of security, is how are the keys managed. Without proper key management (which is *hard*), the encryption just adds latency, not security.

Posted by: ronys at June 27, 2005 10:20 AM


Right, the major question is what does it mean "only user can access it". If that key on the disk is encrypted by the password which a user enters at boot time or anything that's not in the computer, then it's safe.
Otherwise, there's really no point in encrypting. I'd really like to see some detailed description what they do.

Posted by: AC at June 27, 2005 10:28 AM


I too wondered about the "only the user can access it". I mean, I may have bought the drive so I am the user of it, but how many other people are considered "users"? I know I'm splitting hairs, but I'd rather rely on my own encryption that's done by the OS. The first thing that makes me suspicious is the phrase "trust me".

Posted by: jammit at June 27, 2005 11:11 AM


Most of the people commenting seem to assume that it's the wetware at the keyboard that is "the user". It seems more likely that the system bios or the OS will be the actual "user" and this will be used to ensure you can't move a drive from one machine to another.

Posted by: jconde at June 27, 2005 11:12 AM


What if the block with the key in is damaged...?

Security vs Resilience. Hmm.

Are your backups encrypted?

Posted by: Senji at June 27, 2005 11:14 AM


What happen if I travel with a laptop with this kind of hard disk, for example, to France, where encryption is forbidden?

Posted by: Anonymous at June 27, 2005 11:26 AM


France = bad example, since use of strong encryption is now allowed there.

Posted by: Anonymous at June 27, 2005 11:36 AM


How will this work as a USB drive?

What if I take this drive an put it into an external enclosure with USB connector. The literature doesn't say you can't do this or that the drive must be connected through system BIOS. The drive details on this seem sketchy.

Posted by: Anonymous at June 27, 2005 11:38 AM


The spec looks much like marketing and keeping the key anywhere but internal RAM of the drive makes no sense at all from security perspective. I'd imagine a drive with builtin encryption would be practical only if the bios would ask the password on boot, send it to the drive and the drive would then signal if the password was accepted or not (the drive could perhaps do this by decrypting some ciphertext block stored on the disk with that key and then check if it results in some known plaintext pattern).

Obviously, at this point, it's more like a marketing trick than really wanting to put resources to it to absolutely make it right (I mean, why would they hire experts for big bucks if they can just buy a piece of AES code, put it as part of the drive's firmware and then slap AES sticker on the drive? They'd have to consider a lots of things like side channel attacks, etc. to make it really secure). Good idea overall, but I wouldn't keep anything worth more than a few thousands of $$ (or less) on it until manufacturers start giving out real specs.

Posted by: Ari Heikkinen at June 27, 2005 1:14 PM


Any one remember the Trusted Computing Group (https://www.trustedcomputinggroup.org/)? They are still alive and kicking - and we are starting to see products (http://www.tonymcfadden.net/tpmvendors.html) rolling out that comply with their specifications. Seagate is a member of the TCG .. any chance this hard drive complies with the TCG specifications for hard drives? I think such a drive would make much more sense for something like a TPM-enabled environment that simple user passwords.

Posted by: smithwd at June 27, 2005 1:45 PM


If it's not open source, it's CRAP. Not just crap, INSECURE crap. I want to see the firmware. I want to see it all. Show me, don't tell me. YOU ARE ALL SCREWED!

Posted by: OSIFreak at June 27, 2005 2:14 PM


TDEA (short for Triple Data Encryption Algorithm) is the term NIST uses to refer to 3DES in some of their literature (including FIPS 140-2 certification literature). This is most likely where the reference came from.

Posted by: cryptonym at June 27, 2005 2:56 PM


However, if the idea is to ensure that when the drive is NOT in the normal host computer(s), the drive is unreadable, then this gets interesting.

If they are only used data volumes (mounted after boot), this could be well integrated into a secure system. It's fairly easy to talk directly to the "hardware", especially on 'nix. There are commandline utilities for sending commands directly to the onboard controller for both IDE/SATA and SCSI devices.

Sequence is:

A) Boot the system
B) Write the encryption key to the drive after boot
C) Drive puts key into volatile memory
D) Read the partition table and mount the volumes, not that the drive can decrypt it's own data.
E) power down is easy, just unmount the volumes and power down the drive, and it forgets it's key.

From the spec, I see this is done in bios instead of OS, but no reason why for database systems where drives/tapes travel containing data, a similar system couldn't be used.

The disks are well encrypted for transportation, and function correctly when accessed by a host that knows the correct key.

Of course, once you have the drive (found/stolen), you can also easily script a brute-force attack unless the device is very "attack aware", and will limit the password set rate (ie, once per "boot" of the drive), etc, so as to slow down the attack rate.

They don't state if the drive allows access or not until it's unlocked, or if the drive simply improperly decrypts the data if not unlocked correctly. The former seems like it would be better, especially if you had to go through a lengthy handshake to get the drive to boot correctly unlocked (10 seconds to power up, try a key, find it failed, and power down the drive).

Posted by: Woody at June 27, 2005 3:07 PM


what we need is totally private, portable computing, and as osifreak observed above, the security mechanism must be totally transparent such that even the technologically slow-witted (like me) can understand and repose trust in it. the key should not be reverse-engineerable by anyone else who may possess the system, the world's most adept hacker or the world's most i.t. adept member of law enforcement, which raises the question of whether our government will permit us to own such machines without any backdoors. seagate's new unit is an advance, but not the final objective in our quest.

Posted by: another_bruce at June 27, 2005 4:47 PM


USB drives get connected via a "bridge" chip which is a controller that speaks USB on one side and IDE on the other.

Suitably configured, there shouldn't be much of a difference. The host computer needs to have some way to specify the key or authentication to the spindle, and then all should work as before.

But yes, all we have is a sales brochure, nothing like technical documentation.

Posted by: Anonymous at June 27, 2005 5:09 PM


"I remain extremely skeptical about products like this. I much prefer using filesystem encryption at the OS level where I feel I have much more control. Also, the text 'a software key that resides on a portion of the disk nobody but the user can access' sets off alarms in my head."

The entire spec sheet sets off all sorts of alarms. I talked a bit to an engineer from the company, which helped me feel a bit better. But honestly, regardless of whether the product is hardware or software you have to trust the developer.

Open source would help, as the person above said less delicately.

Posted by: Bruce Schneier at June 27, 2005 5:22 PM


"The unanswered question here, in terms of security, is how are the keys managed. Without proper key management (which is *hard*), the encryption just adds latency, not security."

Of course. I urged them to publish as much as they possibly could about the technology.

Posted by: Bruce Schneier at June 27, 2005 5:22 PM


"TDEA (short for Triple Data Encryption Algorithm) is the term NIST uses to refer to 3DES in some of their literature (including FIPS 140-2 certification literature). This is most likely where the reference came from."

Thank you.

The "192" came from 3*64, if you can believe that.

Posted by: Bruce Schneier at June 27, 2005 5:23 PM


I can't think of any way to make this supportable in an enterprise environment.

This technology seems to have a very small effective class of end users. If only one person has the decryption key (the user), how does the technical staff install and maintain an operating system? If the end user is savvy enough to install the OS on his/her own (and is allowed to do so by the technical staff), they probably can navigate PGP or CFS or whatever encryption is appropriate at the file/filesystem level.

The premise is that you're decreasing the "load" on the end user by making functionality transparent, but doing so usually requires an enormous re-tasking of effort on the back end to support and maintain the systems.

In this particular incidence, in an enterprise sense, you're giving too much power to the end-user -> the technical support staff can't even boot the box without the user's presence!

So what's the advantage of deploying these to your employee's laptops?

From the e-week article, it seems like one of their selling points is, "You don't have to disclose that the laptop was lost"... ie, "You don't have to comply with the California law that has been cropping up in the news so much lately". It's a liability dodge. So now you can let your employees have local copies of sensitive data, and you have plausible deniablity if the laptop is lost.

Without knowing what sort of password the user has set, this is absurd. If the passphrase is "kittens", the crypto is meaningless. What's more, the class of users you're deploying these devices to are precisely the class that choose ineffective passwords.

Posted by: Pat Cahalan at June 27, 2005 5:48 PM


It is right there in the spec sheet:

"Supports and enhances Trusted Platform Modules (TPM)"

This is part of the Trusted Computing Group - of which Seagate is a member - see this site for details:

https://www.trustedcomputinggroup.org/

The security specifications, white papers, etc. are available for download from the site here:

https://www.trustedcomputinggroup.org/downloads

Current products are more geared toward corporate laptops where theft of a laptop could result in a loss of business critical information.

I expect we will be seeing a lot more of this technology in multimedia PCs with DRM support in hardware.

People may not like the closed source nature of the implementation, but at least the implementation specs are there for all to read.

Posted by: smithwd at June 27, 2005 7:12 PM


I see comments that this has been out before - but what if? It becomes a commercial success? What if, that stimulates others to compete? What if, somebody makes firmware open source, and *still* a commercial success? What if this evolves as a Good Thing? I have no particular affinity for the vendor (Seagate) but wish them well ... and hope they succeed tremendously, thereby prompting others to follow suit. What if it became a 'cool' thing to have your own encrypted drive, sort of like an iPod 'must have' bit - and then security became a forefront thing, more talked about in the general public than last weeks' football game? It could have potential! Just my .02 -

Posted by: Brad Mills at June 28, 2005 7:09 AM


OK, somebody correct me if I'm wrong, but it looks like if you buy this drive today and put it in a current-model laptop, you don't see any benefit. The spec sheet leads me to believe that the only way you can activate the encryption is to use a TPM-enabled (trusted computing) system that knows how to feed the encryption key to the drive on boot.

Posted by: Phil at June 28, 2005 8:36 AM


“…[A] suite of security features inside the drive that enables robust system-level security such as key management and recovery.”

What, exactly, do they mean by key “recovery”?

Posted by: Henry Dorsett Case at June 28, 2005 11:06 AM


Folks, there are three points,

1, Is it DRM in disguise (probably)
2, Is it secure (probably not)
3, Are corperates going to buy it (probably).

The reason I say probably not on 2 is can you see the US or any other government allowing it out and about without some kind of law enforcment back door?

Untill I see proof otherwise I'm going to stay well away from this one and use structured encryption in the Open Source OS and Apps.

Posted by: Clive Robinson at June 28, 2005 11:56 AM


"Any chance they'll produce a version where (1) the decrypted data on the disk varies according to which key is used, and (2) there is no way of telling how many valid keys there are?"

Bruce's "deniable encryption" or forms of "plausable deniability" have been present in at least 3 of leading software encryption products for quite a while:

TrueCrypt (sf.net) - supports "hidden volumes";
BestCrypt (Jetico.com) - supports "hidden containers";
DriveCrypt (Securestar.com) - supports "invisible containers".

TrueCrypt and BestCrypt publish their source for at least one platform. DriveCrypt has explicit support for enterprise management and with a separate extension can even hide entire operating systems accessed by different keys on startup!

Posted by: Tasuki Yamamoto at July 4, 2005 5:47 AM


Take a look at the SecureD product line from High Density Devices, a Norwegian company (http://www.hdd.no). This is a chip (instantiated in various packages) that resides in the IDE data path and encrypts ALL data on the drive, from spindle to rim. No encryption material ever resides in the system CPU, system memory, drive electronics, or storage media. Keying material is introduced at system boot through a smart card and evaporates at power-off. Uses TDEA and AES for keying material and data stream, respectively. Has FIPS certs for TDEA and AES, FIPS 140-2 cert at SL3, and CC cert at EAL4 for self protection and data protection.

These sorts of devices (see also ASUS Pundit-R barebones case) are used for protecting data-at-rest. When the system is up and running, the hard drive is totally visible, subject to all of the viscitudes of any unencrypted system. But when the system is powered off, or powered on with no keying material available, the contents of the drive are digital kibble. Great tool for road warriors (whose laptops sometimes go adrift) or data centers who need to "destroy" large amounts of data very quickly.

Key management is external to the devices, except for the ability to make the keys go away at power-off or dissipate after some other trigger event.

Do you trust FIPS and CC? TDEA and AES? The grand conspiracy of NSA and the NWO? You pays your money and you makes your choice.

Sp00ky
"No matter how paranoid you are, it isn't paranoid enough."

Posted by: Spiritus ex Machina at March 1, 2006 1:46 PM


Secure Systems Limited (www.securesystems.com.au) from Australia has a hardware solution that solves many of the problems noted above. It is available as a an internal drive, USB drive, or removable drive. Early boot user authentication. It can be centrally administered. You do not need TPM. OS agnostic. Just plug it in and you are in business.

animaus88-gen yahoo.com

Posted by: Red Dog at August 18, 2006 12:51 PM


Some of the information I received when I queried Segate shortly after they announced these:

"These drives will need the newest motherboard, BIOS, and the Vista
Operating system from Microsoft. The FDE drives are bleeding edge and will
need all three of these components"

"The Seagate FDE drives require "TRUSTED DRIVE " which Vista is one avenue,"

"The encrypt and decrypt key is accessible without booting.The hardware is
on the drive, it is a chip. It is essentially a traditional drive with a
3DES Crypto Chip and DriveTrust firmware. You will become familiar with
this "Trusted Drive" as it will become a laptop manufacturing standard."

Also a bunch of stuff from the Trusted COmputing Group website.

This looks like under the right circumstances and by the right people the encryption could be compromised.

Additionally, as noted earlier, if you laptop/system doesn't have a TPM module they are useless.

Posted by: WD Milner at September 29, 2006 9:28 PM


according tot he data sheet:

"Independent of OS to avoid OS vulnerabilities
and overhead "


Posted by: Allan Marcus at October 30, 2006 2:57 PM


So it can't be used to secure data on far servers, because you have to drive/fly to the server to write the password.
Is there no way to secure data on a far server?

Posted by: Dr. Freitag at August 6, 2007 7:04 AM


Re:'So it can't be used to secure data on far servers, because you have to drive/fly to the server to write the password.
Is there no way to secure data on a far server?'

The Trusted Computer Group - (url posted earlier in the post) has another specification called "TNC Network Connectivity Architecture" .
I believe the "Owner" of the network -remote or not - retains the rights to configure / reconfigure any node on that network.

Posted by: Golf Studio at August 9, 2007 1:51 PM


Post a comment



Real names aren't required, but please give us something to call you. Conversations among several people called "Anonymous" get too confusing.



E-mail is optional and will not be displayed on the site.


Remember Me?


Powered by Movable Type 3.36. Photo at top by Steve Woit.

Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.

 
Bruce Schneier