Seagate Encrypted Drive

Seagate has announced a product called DriveTrust, which provides hardware-based encryption on the drive itself. The technology is proprietary, but they use standard algorithms: AES and triple-DES, RSA, and SHA-1. Details on the key management are sketchy, but the system requires a pre-boot password and/or combination of biometrics to access the disk. And Seagate is working on some sort of enterprise-wide key management system to make it easier to deploy the technology company-wide.

The first target market is laptop computers. No computer manufacturer has announced support for DriveTrust yet.

More details in these articles.

Tags: , , , , , , , , ,

Posted on November 7, 2006 at 7:04 AM • 40 Comments

Comments

John Ridley • November 7, 2006 7:45 AM

Prediction:
Casual users will lose the password and get really steamed that there’s no backdoor.
Serious users will assume there’s a backdoor and won’t use it.
For my uses, truecrypt works fine. I’m not too worried about my boot area, but I want the data locked down. Truecrypt handles that just fine.

Alicia Keys • November 7, 2006 8:29 AM

As alluded to, key management is the usual issue. All large-sized, and most medium-sized, companies I know insist on an easy way to recover if the end-user loses/forgets the key(s).

denis bider • November 7, 2006 8:33 AM

There should be a seriously supported drive encryption product for Windows providing deniable encryption – the ability to boot into a different environment (aspect) depending on the decryption password, and preventing detection of other aspects unless you know those aspects’ passwords. Something like Rubberhose for Linux, which unfortunately is not maintained. 🙁

Alexandre Carmel-Veilleux • November 7, 2006 8:34 AM

This would be right up the ThinkPad’s alley. Their boot-up security is already above average, it would make sense if they rolled this in too. They already have fingerprint readers on many laptops, too.

slick • November 7, 2006 8:38 AM

This would be great for enterprise IT. Joe User can’t be expected to put his sensitive files in the right place every time, so encrypting the whole HDD makes sense. And since HDD crypto software tends to be pricey, this could be a nice cost savings.

Chris • November 7, 2006 8:48 AM

This is to be a product targeted at a single problem: laptop and/or hard drive theft. Sure, an encrypted drive is nice if you remember to shut your system down but it has no support for access control at the file or volume level.

And what will this technology do to people who travel to places that inspect your drive when you enter their country? Or countries that strictly control encryption technology?

jaq • November 7, 2006 8:53 AM

@Alexandre
I had a ThinkPad with a fingerprint reader for a while. Sometimes the reader would work fine, while other times I could scan my finger many times without it recognising it, and I would have to remember the password that I didn’t usually use. I would like something more reliable.

Andy • November 7, 2006 8:57 AM

An important phrase to note is the “full drive performance”. Software solutions like BitLocker will chew up CPU time otherwise spent on application work. I didn’t plan to throw that second CPU core at housekeeping problems. DriveTrust is really clever – it soaks up spare computation resources on the drive itself with little or no hardware cost.

Key management is certainly an issue, but no one can seriously suggest it is unique to this product. It’s rather an industry problem, so I would look to security software vendors for a corporate solution. For a personal use, it doesn’t seem to me to be out of place to add this to, say, an antivirus package. The AV program already reads every file I’ve ever created, so it’s not much of a stretch to let them manage my key(s). Or send the key out to a USB thumb-drive if you want to keep tighter control than a central authority would provide.

Nicholas Weaver • November 7, 2006 8:59 AM

Its hooked up into the TPM style platforms, so you can bind things to both user and system.

What I worry about is that all the key management issues and different authentication modes may create weak failures, where an attacker who can physically capture the drive can extract the key by taking it apart.

(TPM tamper resistence is designed for casual adversaries, not a $10k-100k adversary who wants to do a single key extraction)

jmc • November 7, 2006 9:33 AM

@jaq
I think the technology becomes more reliable in time. I have a somewhat new ThinkPad (T60) and its reader works just fine. (One, two exceptions, of course, but I don’t need nor know my pw.)
It’s the same with all such biometric devices: They need to grow up until you can use them and the TP readers has IMHO.

greetings, jmc

BLP • November 7, 2006 10:12 AM

@jmc
Out of curiosity, if you don’t know your password… what happens if you lose your finger (or fingertip) in a tragic accident?

nerdbert • November 7, 2006 10:28 AM

“DriveTrust is really clever – it soaks up spare computation resources on the drive itself with little or no hardware cost.”

Ah, no. They’ve built in the appropriate hardware for the decoding, not put it in software. The microcontrollers on drives are pretty pathetic and don’t have the spare bandwidth to do this kind of stuff. Frankly, the controllers barely have the bandwidth to keep the drives happy much less add all this overhead.

Now when it’s put onto the SoC in the next generation then it really will become cheap since most of those SoCs are pin limited these days.

Tim • November 7, 2006 10:38 AM

The questions are:
a) how does it work with auto- or remote-reboot when your finger isn’t on the reader to allow it?, and
b) it’s all very well saying it uses some standard algorithms, but if the protocol surrounding their use is proprietary, we still don’t know two things:
1) whether there’s a backdoor;
2) whether there’s scope for callusion with m$loth and others to enforce DRM on us all the hard way.

How do you know the disk doesn’t actually have twice the capacity it presents to you in “encrypted” mode?

derf • November 7, 2006 10:59 AM

1) Hard drives fail.
2) Operating systems fail.
3) Users ignore rule #1 and #2.
4) Users demand data be recoverable from failed systems despite rule #1 and #2.

Most encryption solutions make the data unrecoverable by alternate means if the drive or the OS fails. Seagate’s system would be unique if it were to get around the recoverability and enterprise keying issues without compromising the security.

pluto • November 7, 2006 11:00 AM

probably of most use in devices such as PVR/Set top boxes that will contain protected content that the owners do not wish to see copied to other devices. It will give the cable co and the content owner a nice warm feeling that their content is secure from users copying it (by putting the drive into a PC), but as we all know, wont matter at all to anyone determined enough (or able to use google).

Ignatius • November 7, 2006 11:09 AM

IMHO, the correct place for harddrive encryption is the controller, not the disk itself. When both, data and encryption, are in the same sealed black-box, you have no way of knowing what’s really written onto the disk and the system is practically impossible to audit for back-doors.

Ulrich • November 7, 2006 11:13 AM

Some questions on first reading the announcement:
– what are they using the RSA for? Key recovery?
– What mode of operation for AES? AES with ECB conforms to the standard, but is not secure. If not, which one do they use? How do they handle the IV? Maybe we can learn something for our OS-based disk encryption stuff…

BetaTester • November 7, 2006 11:31 AM

If this product is similar to the earlier efforts over the past two years, it looks like smart-cards-on-a-disk, so judgement-by-analogy about the security and backdoors should apply.
If Seagate really wants everyone to buy in, they should open-source the portions of the firmware that handle this interface. Since this is a recent add-on, it’s likely that they could release this without giving away deep disk firmware secrets … unless there really is some backdoor.

Jim • November 7, 2006 11:31 AM

Hmmm, what happens if you lose your finger (or fingertip) in a tragic accident?

Not sure. I guess folks need to backup their fingerprints on a thumb drive.

Chris Granade • November 7, 2006 11:38 AM

Why SHA-1? I thought it was being phased out in favor of the SHA-2 family… Seems odd to pair AES with a hash algorithm known to have problems. Also, does anyone know what they’re doing to prevent side channel attacks of the AES based on power consumption?

Jim • November 7, 2006 11:47 AM

They say, “DriveTrust Technology works by encasing the security operations in the hard drive, making the technology as easy and cost-effective to deploy as the drive itself.”

They make it sound all so simple. It sounds plug and playish. They should stick with building more dependable drives. A good security engineer can secure a standard old drive.

Pede • November 7, 2006 12:06 PM

What happens in case of an HD crash?
How can you recover files from your notebook? Ok, there is a backup copy, but
you cannot make a backup of your files every hour, specially on notebook.
Now with normal disks the hope to recover data from a broken HD is poor, but when all is encrypted?

David • November 7, 2006 12:48 PM

If you are logged in and you make a backup to anything but another encrypted disk, all your “safe” data is now in the clear again.

I’d like to see the database performance numbers for a disk that uses this since they rely on heavy I/O to indexes and such to perform SQL queries and everything must be decrypted “just in time” and repeatedly as data goes in and out.

Rob Mayfield • November 7, 2006 2:24 PM

@John Ridley

me too – truecrypt is fine – I’m sure there are other similar products that are fine also.

Do you want to have to give your password to the service tech ? or to the network admin ? or share it with the company ? I can see applications where drive encryption would be handy, and done properly in hardware makes for good performance, but for average Joe and average Corp its potentially more trouble than its worth …

Bob Stratton • November 7, 2006 4:03 PM

I think an interesting question will be: What happens when these are in large-scale adoption and people begin to travel to France and find their laptops confiscated?

Last I checked, volume encryption wasn’t kosher for visitors to a number of countries.When it’s in software, that’s one thing, but when it’s a standard hardware feature, I’m betting that some won’t take kindly to it.

Fenris Fox • November 7, 2006 4:22 PM

@BLP

“@jmc
Out of curiosity, if you don’t know your password… what happens if you lose your finger (or fingertip) in a tragic accident?”

You can always lift your print from the glass… =;o)

And as far as having boot/system file encryption, Security Now! mentioned a cool trick you can do. While you can’t use TrueCrypt to protect a host OS.. you can put an entire VM into an encrypted container/partition. If you do so, then all the data for that guest OS – boot and data – is protected, cutting leaks down to just about zero.

(One possible problem with this is virtual memory in the host OS.. if you have lots of RAM, you could turn it off; an alternative would be to use something like cryptsetup in Linux to encrypt the swap with random keys during each session. It’s not as secure as TrueCrypt.. but for many applications, it should be acceptable.

AFAIK, TrueCrypt itself can’t be used to encrypt host OS swap… if there is a way, please correct me, since it’d beat the hell out of cryptsetup.)

Fenris Fox • November 7, 2006 4:27 PM

@Bob Stratton:

“I think an interesting question will be: What happens when these are in large-scale adoption and people begin to travel to France and find their laptops confiscated?”

That’s simple to answer – when they confiscate enough big-business laptops, the corporate world will sit its wookus down on France and those other national governments. =;o)

“Remember the Golden Rule: He who has the gold, makes the rules.” –Disney’s Aladdin. It might have been a kids’ movie.. but by George, it’s the truth!

solinym • November 7, 2006 5:40 PM

The proper place to put encryption is on a general-purpose CPU. The economies of scale there are tremendous and can’t be beat, dollar for dollar. Peter Gutmann has a paper on his web page about an open-source crypto co-processor. I’m interested in designing and building one.

The problem with custom ASICs is that they’re expensive to design and don’t have economies of scale. Within a few years the crypto accelerator ends up being a decellerator.

Plus, it’s hard to update the algorithms to account for successful analyses.

Stefan Wagner • November 7, 2006 8:36 PM

@Jim: “…what happens if you lose your finger…?”

Well – you’ll find your fingerprint on the 78zuhjn and m-key (where every thief will find it too).

Wylie • November 7, 2006 10:59 PM

Being an Aussie, im not too familiar with US law etc, but how will the US government (in particular) react when Joe User can encrypt their hard drive? (Ok, perhaps not Joe User, but Joe Geek).

Im thinking of cases like the recent boarding pass guy, who apparently had a visit from the FBI .

They’re not gonna be happy, and he is going to be in more trouble than he might have otherwise been.

Having said that, I cant wait to get my hands on one.

Its not the data related to the prank thats the problem – its all the other stuff you forgot was there…. its difficult to buy a drive under 100Gb these days, so thats an awful lot of other stuff.

COMINT • November 8, 2006 1:31 AM

I spoke to a colleague in Seagate prior to the press release launch of the FDE(1) product last year who informed me it was all good to go for release in the 3rd quarter 2006.

Just after the press release, he became very tightlipped about the push back on the release date and I managed to gleam that there were some objections to the release from “concerned” visitors.

Low and behold, the project is “redesigned” and released as FDE.2(yet to see them on the market mind you) after some careful re-engineering.

The sooner the “interested” parties realise that there is no point trying to stiffle hardware crypto the better it will be for the general security of our data.

Some things never change.

Nik • November 8, 2006 2:52 AM

There’s been a similar product available in the UK from Stonewood called Flagstone. It’s a 1″/1.8″ disk in a 2.5″ sized chassis with the relevant crypto hardware and thermal management embedded.

It also has the CESG rubber stamp, which depending on your perspective either means it’s pretty secure or alternatively has a secret squirrel backdoor added 🙂

cmills • November 8, 2006 11:38 AM

The main point is that this is only a single layer of security for a specific attack. There are many possible ways to subvert this measure, so you must maintain security practices in other areas.

The questions are:
Does this device provide a high level of security against the specific attack which it was designed to protect against?
and
Does it provide reliable access to those authorized to access the data on the device?

Dan • November 9, 2006 11:48 PM

What about performance? Bitlocker, and other software-only solutions will have an impact both on transfer speed, and CPU usage.

If this is done completely in hardware, will the drive offload everything from the CPU? Will it have enough cache/buffer space to minimize the delta in drive access and transfer speed?

Mr. P • January 31, 2007 2:41 PM

DriveTrust encrypts and decrypts on the fly – on the hardware, without any of the software hassles. The only software that you will need is the centralized key management software to recover the hard disk. Such software is VERY light and simple. Look at the alternatives: Software for Disk Encrpytion. These all require enormous hassles in the management of the users systems. We have all been around long enough to know that if the device does not come encrypted, then the extra (expensive) software, Installation and Management effort are simply too much hassle – and the acceptance for users / corporations will be close to zero. Bring on the easiest form of encrpytion possible.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.