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 AM48 Comments


Clive Robinson June 27, 2005 7:33 AM

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…

Phil Hunt June 27, 2005 8:36 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?

Sue Donym June 27, 2005 8:55 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.

Bruce Schneier June 27, 2005 9:10 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.

Jay June 27, 2005 9:57 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.

ronys June 27, 2005 10:20 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.

AC June 27, 2005 10:28 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.

jammit June 27, 2005 11:11 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”.

jconde June 27, 2005 11:12 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.

Senji June 27, 2005 11:14 AM

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

Security vs Resilience. Hmm.

Are your backups encrypted?

Anonymous June 27, 2005 11:26 AM

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

Anonymous June 27, 2005 11:38 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.

Ari Heikkinen June 27, 2005 1:14 PM

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.

smithwd June 27, 2005 1:45 PM

Any one remember the Trusted Computing Group ( They are still alive and kicking – and we are starting to see products ( 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.

OSIFreak June 27, 2005 2:14 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!

cryptonym June 27, 2005 2:56 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.

Woody June 27, 2005 3:07 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).

another_bruce June 27, 2005 4:47 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.

Anonymous June 27, 2005 5:09 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.

Bruce Schneier June 27, 2005 5:22 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.

Bruce Schneier 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.

Bruce Schneier June 27, 2005 5:23 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.

Pat Cahalan June 27, 2005 5:48 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.

smithwd June 27, 2005 7:12 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:

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

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.

Brad Mills June 28, 2005 7:09 AM

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 –

Phil June 28, 2005 8:36 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.

Henry Dorsett Case June 28, 2005 11:06 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”?

Clive Robinson June 28, 2005 11:56 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.

Tasuki Yamamoto July 4, 2005 5:47 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 ( – supports “hidden volumes”;
BestCrypt ( – supports “hidden containers”;
DriveCrypt ( – 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!

Spiritus ex Machina March 1, 2006 1:46 PM

Take a look at the SecureD product line from High Density Devices, a Norwegian company ( 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.

“No matter how paranoid you are, it isn’t paranoid enough.”

Red Dog August 18, 2006 12:51 PM

Secure Systems Limited ( 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 <|at|>

WD Milner September 29, 2006 9:28 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.

Allan Marcus October 30, 2006 2:57 PM

according tot he data sheet:

“Independent of OS to avoid OS vulnerabilities
and overhead “

Dr. Freitag August 6, 2007 7:04 AM

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?

Golf Studio August 9, 2007 1:51 PM

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.

Fake McCoy January 10, 2009 11:26 AM

Segate is far superior to anything else on market.
I know the engineer that developed the line and its impossable to crack

Cymage March 24, 2009 5:43 PM

Fake McCoy, you lost all of your credibility when you said “its impossable to crack”. Nothing is impossible to crack if someone wants to put the time and resources into it.

Anonymous April 11, 2009 10:27 PM

NetBSD cgd might be helpful. Waiting for NetBSD 5 to be out, although cgd been out for a while.

Interview on NetBSD cgd is a decent read, easy find on yahoo.

Would be nice to have a little work done to cgd, different ciphers, hashes.

Joshua May 13, 2010 9:35 PM

I have my hands on a friends Seagate Black Armor drive. Anyone interested in helping me crack it? He thinks its impossible and I want to prove him wrong, without destroying it. He cant remember his password, so it sounds like its time to experiment! Any interested email me @

Garrett June 12, 2010 12:39 PM

I’m amazed this thread has lasted so long (~5 years, as of today!). I did some research on Seagate’s Momentus FDE drive; it was difficult to get all the answers I was looking for, and one of the answers I got led me to go with a s/w based solution (using TPM).

To allay concerns above, I believe the Momentus drive is secure, even with a relatively weak password (it must impose a delay of sorts on password-guessing). Further, I believe there are other vendors who specialize in s/w-based FDE who are now providing management consoles so that the power isn’t in the hands of the end-user at all, but instead w/ IT management.

The characteristic of the Seagate Momentus FDE drive that bothered me though was that, once the drive was unlocked, only a power cycle would cause it to re-lock (which does not happen when doing a warm reboot). Of course, w/ any FDE solution, there are always risks if one doesn’t shut down the machine completely (cold boot attack, OS-specific attack, etc), but the idea that a simple boot disk could subvert the security of a system that wasn’t shut down or hibernated was a bit disconcerting.

My guess (or hope) is that future versions of h/w-based FDE will be smart enough to lock if there is a warm reboot (after all, all s/w-based FDE solutions do this). In the meantime, I’m intrigued at the idea of using self-encrypting external drives – anyone had experience w/ such drives, such as Maxtor (now Seagate’s) BlackArmor drive?

Garrett June 12, 2010 12:56 PM

@Fake McCoy – I agree w/ Cymage on this one. You’ve been duped, or perhaps you’re doing the duping on us. Anyway, nothing is impossible to crack, but some well-designed solutions might be prohibitively expensive to crack.

Eg – Infinion’s TPM chip. It can be utilized by multiple s/w-based FDE solutions (bitlocker, PGP, et al), but can also be cracked, if this article is accurate:

However, considering the costs involved in doing so and the specialized equipment involved in cracking a TPM (equipment not required in a s/w-only attack), I actually took comfort in the level of difficulty that was required to break the TPM. Further, newer TPMs will likely be a bit more secure, making these sorts of attacks more difficult (but even if they don’t, the costs of the attack remain high indefinitely).

Nghia Nguyen April 9, 2012 4:16 AM

Now, I have a Seagate Momentus ST9250412AS drive (Self-Encypting Drive). But I don’t know how to lock/unlock this drive. I issued TRUSTED RECEIVE command (security protocol=00h, sp_specific=0000h) and it returned the following data:
00 00 00 00 00 00 00 02 00 F0 00 00 00 00 00 …
The returned value is F0. From ATA8 specification, I see it is not support TCG but supports a vendor specific. So, what security protocol is supported on this drive? If it is not support TCG, please give me some documents about the protocol supported on this drive.

Thank you in advance,
Nghia Nguyen

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.