Slashdot Mirror
Universal Disk Encryption Spec Finalized
Lucas123 writes "Six of the largest disk manufacturers, along with encryption management software vendors, are backing three specifications finalized [Tuesday] that will eventually standardize the way encryption is used in firmware within hard disk drives and solid state disk drive controllers ensuring interoperability. Disk vendors are free to choose to use AES 128-bit or AES 256-bit keys depending on the level of security they want. 'This represents interoperability commitments from every disk drive maker on the planet,' said Robert Thibadeau, chief technologist at Seagate Technology."
Why should this be trustable?
You are being MICROattacked, from various angles, in a SOFT manner.
How can we trust their implementation?
... it's TPM glue for hard drives. The spec says almost nothing about encryption and authentication, it's just a bunch of TPM command and control mechanisms for hard drives. The IEEE P1696 working group is the one working on secure hard-drive encryption. Unfortunately the TPM people have better PR people than the CS and EE types doing the IEEE work do.
That information is not available. The PDF linked to as "the spec" is merely a press release, and the other linked documents aren't any better. It seems like they haven't really agreed.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
everytime you turn on your computer, you need to enter a password to access the hard drive. That's not going to work so well if your computer is sitting in a data center on the other side of the country.
Do you even lift?
These aren't the 'roids you're looking for.
brick your hardrive. Now it's secure.
When are drives conforming to this standard going to be available? Also, the article mentions using this type of encryption to, say, lock up a laptop and keep a kid from using it. That seems to imply that there will be some kind of user interface. Wouldn't the encryption keys be unwieldy and hard to remember? If it's baked into the hardware, what about swapping drives between machines? If users are able to create their own passwords, wouldn't these drives be just as crackable as any other?
here are "on the PLANET". Looks like they've got a bit more work to do before EVERYONE agrees to do this.
Can any storage gurus explain the real-world benefit to this? Is it currently impossible to encrypt a RAID volume built on two different manufacturers' disks?
Why not just use TrueCrypt pre-boot system partition encryption? The benefit of a hardware standard is not immediately clear to me.
but has it been pretty well established that there are no significant backdoors, or backdoor techniques, related to the existing AES algorithms? I.e., 128 and 256?
What good would hardware encryption be unless we were pretty well assured that even the NSA would be stymied?
It is not a matter of doing anything illegal, of course, but encryption is encryption. If there are reasonable methods available to break it, then it ain't.
I bet they'll ALL have major backdoors built in!
Question: what are the SPECIFICATIONS for this, anyway? I've heard enough about drive resident crypto to be worried about things like secret specifications / implementations geared toward industries like DRM providers to help them "hide" / access control content on your OWN hard drive at the hardware level, backdoors, et. al.
q.v.
http://www.theregister.co.uk/2001/01/10/everything_you_ever_wanted/
Presumably this AES implementation is different than the CPRM related link above, but it is moot if AES is considered secure / auditable of the details of how the drive itself stores / uses the secret key are not well assured. If the drive encrypts / decrypts the data onboard, it must have an API to receive and control the secret key and encryption parameters. Nothing at all would prevent a malicious implementation from keeping a copy of the secret key in FLASH or on a hidden spot on the disc surface or whatever. Full disclosure of the data encryption algorithms / keying scheme and an independent host software means to read the *encrypted* disc blocks and (in host software) duplicate the crypto algorithms would permit the host to be (somewhat) assured that the "on disc" data blocks were even being stored encrypted with the expected algorithms / formats. Although malicious firmware could simply read actually unencrypted data on the disc and encrypt it "as expected" for an auditing readback if it wanted to fool the reader. As long as the data surfaces are "black boxes" accessible only via this "black box" storage controller we really have no idea WHAT it is doing in a proper and trustworthy fashion.
Why would anyone really trust encryption done by a such "black box" piece of commodity hardware?
The temptation on the part of manufacturers is too great to have sloppy / weak / backdoored implementations due to pressures from sources like oppressive / intrusive governments, data recovery concerns / options for industry, et. al.
All the GSM phones have been intentionally weakened in their "security through obscurity" crypto algorithms to permit snooping. Even if there are "somewhat potentially secure" algorithms available for GSM, IIRC it has been established that they intentionally misuse them via keying / option choices to weaken the result and permit easy disclosure of the traffic if the operator / government desires. Intentionally or unintentionally the security of a lot of DECT telecom gear has basically been rendered moot due to bad design according to recent /. articles. Companies that get their security systems hacked (e.g. that recent mass transit / crypto card situation) would rather sue to quiet the news about the insecurity rather than be humbled / shamed and make a properly secure system.
Weren't several prominent secure USB / "secure disc drive" vendors exposed and found out to be using basically no actually useful security even the ones that claimed to be using AES actually WEREN'T in any useful manner encrypting anything?
Look at seagate in the news.. they practically have to be having millions of drives turning into dead bricks in a very public scandal before they'll even ADMIT they have a firmware problem and issue a firmware update to fix the problem. Is this the sort of company you want to TRUST to proactively audit / update crypto algorithms and systems whenever there's the slightest vulnerability found (I assume key disclosure / loss / data corruption vulnerabilities are most likely rather than failure to implement AES itself properly)?
What "consumer level" hardware actually DOES have effective security through cryptography using openly available / auditable algorithms and specifications? Next to nothing? GSM SIM cards -- intentionally weak, non-public algorithms / implementation parameters. "Smart cards" -- very often secret algorithms and / or critical implementation details are used to prevent p
This is useless and insecure.
Can I please get the sourceode to the firmware and verify it and then build a new set of firmware to use on the device?
I mean, I want to make sure there isnt any funny backdoors and stuff.
I cant? Well, No problem. Ill just continue to use the one I am already using then.
Security vithouth being able to verify it is useless. CryptoAG told us that.
I thought this kind of talk was over the top, then I read the article.
No reset so that you can repartion the thing? Users are supposed to trust the hardware won't betray them? No way. It's like they are trying to clog landfills with these things.
The whole article reeks of "trusted path" and other defective by design tech beyond the obvious "oops, I forgot the password" inevitability. To be trusted by sane users, the controller boards must come with easy to change free software doing the dirty work. If not, all sorts of malicious features can be hidden that negate all benefits of hardware encryption. These things could turn themselves if "premium" content is ever placed on the drive and then accessed with a "non trusted" OS, for example. Your data is never secure when you use non free software, it is always at the mercy of the software's owner. This kind of "firmware" is something that should be rejected.
Friends don't help friends install M$ junk.
Universal Disk Encryption Spec Cracked. Available on 0dayz haxx0r b0ardz!!!
These posts express my own personal views, not those of my employer
So, do[es any of] these standards make it easier for a gov't or other organization to notice that someone (eg, a journalist) has got his/her data (eg, article, photo's, interview audio, important video clips, etc.) encrypted on a device, ie, as they try to sneak from, say, within a war zone (closed to journalists) back to friendly soil?
If so, which encryption software (eg, Trucrypt, etc.) - that DOESN'T adhere to standards - will save this journo's life and/or media, in the above situation?
There was (still is) a possibility to set a password for hdds. It was in the news, because it was not possible to get to the data if you couldn't remember the pw. So it was advised to set it or disable it. Because if a malware got to it first they could set some random password and you would have no access anymore.
You're kind of missing the point. If our hypothetical journalist is caught crossing a border, the guards won't pull the hard drive and check the make, and then hook it up to their own gear to see if it's encrypted or not. They'll point their AKs at the journo and make him turn his laptop on. If he refuses, they shoot him. If it prompts for a password and he refuses to enter it, they shoot him. If he claims he forgot the password, they'll toss him and his laptop into the back of the truck to send him to the capital to receive 'enhanced interrogation'. No encryption software will save his life. The guards probably won't know or care about encryption.
If I were that journo, I'd encrypt the files themselves and rename them crash.dump and put them in the Windows directory so I can turn it on, let them scan for jpegs and avis and find nothing, and be sent on my way.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
If the password protection is only blocking the drive's firmware, but the data is not encrypted on disk, it's a very weak protection. Someone stealing your disk only has to find a disk of the same model, and exchange the platters.
If someone has Truecrypt on their hard drive and the police raid your house for some server and they take that encrypted drive, there is nothing stopping you from saying, "I forgot my password... oops." But if you trust the hardware, then what stops the police from going after that hard drive manufacturer and putting the legal pressure on them to provide a back entrance and/or technical help? The idea that the government won't put a legal squeeze on the hard drive manufacturer the second they think they've come upon a child pornography/warez/other horrible illegal things seems absurd to me. I understand that manufacturers of things like flash drives and such have had hardware encryption before, but it hasn't been widespread and mainstream. When you throw in the "average citizen" factor, I think we'll see all kinds of challenges and laws spring up.
-- And as always IANAL, but I do read Slashdot!!
"The best way to accelerate a Macintosh is at 9.8m/sec^2" -Marcus Dolengo
... can be used across all hard disk drives, solid state drives (SSD) and encryption key management applications ...
I'm supposed to trust my crypto keys to a third party? What particular dealer do they think is supposed to supply me with the kind of crack that would cause me to find this acceptable? I didn't write the code that runs their firmware, and I didn't compile anything from their shop either (reference On Trusting Trust by Ken Thompson, circa 1984, for background).
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It looks like they're using the "Opal" standard as a way of selling essentially the same hard drive slightly crippled since if you don't have the key for the thing you "can't even sell it on eBay", whereas admins can "cryptographically erase" their data with ease. Does this mean that the well priced one has a one-key no-reselling system, and the artificially inflated "server" class one can be rotated? I'm going to ere on the side of "companies get together in order to hurt us all" and fear the worst.
Nothing says you can't use Truecrypt or what have you on top of the hardware-based encryption built into the hard drive.
This way you'll have AT LEAST as much protection as you would've with just your software-based encryption.
- The race is not [always] to the swift, nor the battle to the strong. -
The idea isn't new. Hard drives already have the ability to lock users out if a code isn't entered correctly; the XBox used this. The paranoid seem to be coming at this from a "Oh no they're gonna lock me out of my own data" type of deal; but the benefits aren't intended to lock your upgrade hardware down to your brand, PC wise (Compaq tried that a long time ago, it didn't work.) An encryption standard could be good. There are plenty of perverts out there, afraid that their friends will discover all of their nasty bestiality fetishes, who would love to be able to encrypt their hard drives. If the standard is open, then it would be a lot easier for them to swap their drives filled with illegal horse and furry porn into a new computer.
This use-case is more or less dying out though. Because transporting bits across a border by having someone hand-carry them is just too large a risk, assuming it's the kind of bits the government of either country would rather not have crossing the border.
Much better to transmit the bits out, in encrypted form, over some kind of network. Even if there's no internet, you can always do it over satelite-phone or something. Yeah, I know that's like $3/minute, but how many minutes do you need to transmit the ascii-text of an interview or something ?
It's sligthly more of a problem if it's something largish, particularily if it's HD-video though, but even this problem is going away. Even if you're in Iran, it's not very hard to find an access-point with a megabit or more of capacity.
There's no question; the safest way to store "dangerous" bits on your laptop while crossing a border, is to NOT store them on there at all. They can't find what is genuinely not there.
They needed to own your hardware at the lowest level before they could implement a DRM based OS that completely controls access to every bit on the computer. And the DCMA guarantees jail time for breaking the encryption on your own hardware to get your own data out.
What' is this then ?
http://www.truecrypt.org/downloads2.php
Source Code ?
I have not compiled it, nor gone through it in detail, but it looks like source code to me.
D
http://davesboat.blogspot.com/
That will throw them... heck, do it once more to be doubly sure...
All this sounds like to me is that enough governments finally agreed on a standard that they want the HD manufacturers to use. I would say this is about the point where the tech industry is getting into bed with government like the telecom industry did back in it's day.
Trusted computing platform. Built in, black box hard drive encryption. And with the recent 'bogus Chinese Cisco routers that might have enemy sniffing capabilities' scare I'm sure routers and other core Internet architecture are in the process too.
In my mind this is the real reason to push open source. For protection from a police state as much as protection of free choice.
It gives good reason why things like Asterisk, Vayatta, Linux/BSD, etc. are important and why we need them to have significant market share in core communications areas to insure initiatives like those I mentioned don't become defacto standards.
IMO anyway....
Here are some comments that may not be obvious from the story.
(1) While all of the HDD vendors have been involved with the spec, not all HDD vendors have agreed to the TCG version yet. That is, the Opal spec was approved, but there is also an approved Enterprise spec that could be used (previously, Enterprise was targeted only at RAID servers, but the spec is applicable to laptops & desktops). In other words, there may still be some fracturing within the industry until the final standard is selected.
(2) Microsoft, who typically is very involved with drivers and application support for standardized HW, is notably absent from the article
(3) Microsoft is driving a related spec under the IEEE-1667 umbrella, which does not current include encryption, but does include the ability to handle access control (credentials).
(4) Pre-boot authentication is not currently supported by BIOSes or widely by ISVs (e.g. Wave). There's still a lot of work to do here.
(5) Compliance testing is still not completed by the TCG, and therefore, current implementations toward the existing spec likely vary.
Also, for those who are wondering if there are backdoors to these solutions. Note the following:
(a) The first HDD encryption solutions may or may not have back doors. It's obviously not in the TCG spec, but the TCG spec does not specifically prevent a HDD manufacturer from adding other firmware to create a backdoor for them or uncle sam (no such agencies).
(b) Once HDD encryption solutions hit the streets, hackers will likely attack the products and find weaknesses. The community will, in turn, reveal the relative strengths of these solutions.
(c) Mid to long term, the HDD encryption drives will likely be requested to be FIPS certified, which is under NIST. FIPS 140-2 or 140-3 requires a lab to review both the hardware and firmware designs in order to gain compliance (i.e. check for security holes and backdoors). FIPS testing will go a long way to confirm the quality of these FDE solutions.
Cheers
but in the end what it amounts to is trust. In general today, I would trust a private supplier of free software (that has been thoroughly examined in broad daylight by experts in the field), even if it is "proprietary", over something supplied by my government. Simply because in the case of the government, there is strong motivation to "fudge" things a little.
Obviously (though some companies still don't get this), "security through obscurity" is a waste of everybody's time. TrueCrypt, while not "open source", has still been willing to put up with open examination, and in fact has challenged people to break its security. I believe its credibility is pretty high. Which does not prove anything, of course.
You can't ever trust what you don't have access to. So you will need to do the encryption yourself, regardless of what else the device does. That's "user trusted encryption" which these devices simply cannot ever offer (unless you build it yourself).
Oh, and BTW, you can't really trust your CPU, either.
now we need to go OSS in diesel cars
In this case, you seem to be the one without any knowledge. Ask any security expert about something called "security by obscurity" and see if that's a good thing.
c++;
How long until the first trojan comes along that password-protects your drive for you with a random password, irrevocably locking you out? 'Universal' interfaces can have drawbacks as well.
This sounds like one of those things that have a few potential nice features, but can also turn into a big can of worms. Good luck explaining to grandma why there's no way she can get any of her files back, even though technically they're still there.
And the encryption key is standard also, it's:
f81ce859f77fa8a773d66d538ba7ad3daa1185d8
How short-sighted is it to tie into one encryption standard? Idiots.
You need to *at least* make various encryptions pluggable and software-upgradeable because I guarantee that Murphy's Law says that once EVERYONE has one of these hard drive, AES will be cracked sufficiently and we'll be back to square one but tied into millions of devices incorporating a useless and obsolete security "standard. It'll be WEP all over again, even down to 99% of people being "assured" that their hard drive is safe, and then finding out the reality.
Plus, the DRM potential is obvious. I thought the ATA standard had the facility to implement disk encryption anyway - isn't that one of the features used on the XBox or something to lock the hard drives to a particular machine? - you have to send a password across the bus as an ATA packet before the drive will permit any access at all.
You'd be better off using pagefile.sys than some name you made up. How many cursory glances will pick up you're running your pagefile on a different partition? Or which pagefile is in use?
Finally had enough. Come see us over at https://soylentnews.org/
Look.
STD's do a lot of things. Many of them are curable nowadays. But I'm fairly sure that letting you 'see' encrypted discs is not one of their symptoms. I am truly sorry.
...but you can never be to careful so: Remember to include the CIA backdoor guys! Thanks!
PS: Tinfoil won't protect you from it!
The subject of the above article has a valid point. His "expansive area" of expertise may not be directly applicable to the matter being discussed, but I believe that upon cursory glance it's no "stretch" of the imagination to apply the theory to data security, at least in a personal respect. However, upon further "anal"ysis, however, it seems that the "fissure" between the two ideas is too "vast" and would only cause a poorly formed analogy to be used.
Finally had enough. Come see us over at https://soylentnews.org/
Read about where the bottlenecks are before suggesting nonsense.
IANAL but write like a drunk one.
They can't find what is genuinely not there.
If they're properly motivated to find something on you, I'm sure they'll find something on you even if it's not there.
"If anything can go wrong, it will." - Murphy
Truecrypt is awesome for this. Full disk encryption plus a hidden encrypted partition.
You put in one password you get a dummy install you use to trick them. Just a bare bones windows xp with some files on it. You put in the second password and you get your real OS with all your important data.
Password. Never. Stored. In. Memory.
CPU cache turned off when entering password.
And, of course, you guys are aware that really random data is easy to detect in the middle of not-so-random data, so you need to have a LOT of crap with truly random data around, if you want to hide those core.dumps...
AND yes, there are programs to search for really random data in files and disk partitions. They're quite handy to locate encripted files and keys.
n/t
I have a older generation 3ware card here which is just thoroughly trounced by software raid to the point where it acts as a decelerator. It's simply much faster to use the card as a many port controller and Linux kernel software raid.
Modern general purpose CPUs are deeply memory bandwidth limited, raid5/raid6 computation is nearly free so long as the data is moving through the CPU anyways, likewise for the tiny amount of additional logic required to implement raid.
Now, that isn't true for another system with a new raid card that has a 1.2GHz(?) processor on it⦠there software raid and the controller tie with the raid controller slightly winning out on the CPU front.
The two primary ways that raid controllers improves things today is
(1) that it reduces the I/O bandwidth at the CPU: Raid-1 requires doubling (or more) every write, Raid-5/6 requires reading from every drive each time it writes an incomplete stripe.
and
(2) they can feature battery-backed-up write-back cache, so your OS can instantly return a 'write complete' to your application.
For raid-5/6 point (1) has been made obsolete by new file systems with integrated raid (ZFS and soon BTRFS) as they always perform full stripe writes.
And you can bet there will be hidden back doors in the hardware/firmware - in case law enforcement wants to get into your drive. But then, the military and gov't usually have technology that's at least 12 years or more ahead of what's in the public domain, and so. This may be chicken to them. Um, no thanks. I'd rather roll my own.
Not information. If they are trying to find out, for example, which government official revealed secrets to you, if the name isn't on your computer they won't find it. They can make up charges against you, sure, and even plant whatever they want on your hard drive. But it won't get them any closer to finding the leak. In that sense, they truly can't find what isn't there.
.sig withheld by request
Firmware stores three very long keys somewhere in the drive in a very strongly encrypted format. It doesn't matter where. Several thousand bits should be enough to protect against conventional attacks for the next 10 years.
Key #1 gives you read access and is the key used to encrypt the drive.
Key #2 gives you write access, it's just an access password and doesn't affect the data.
Key #3 gives you key-management access, , it's just an access password and doesn't affect the data.
Each key is accessible by a passphrase, with appropriate timeouts, session-negotiation protocols, etc. to prevent spoofing. The drive can also be "locked" to a particular device, subject to unlocking only by use of the key-management key or destroying the keys/resetting the drive. The session-negotiation and other protocols are probably the hard part and those would need to be an industry standard.
Under certain conditions, including a customer-requested drive reset, case tampering, etc. the drive will destroy all 3 keys, rendering the data irretrievable using conventional techniques.
By the way, "256 bits should be enough for anyone." Yeah, right.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm not as worried about that as some. Here's how I look at it - if there's a back door, it doesn't matter as long as it doesn't get used. If it gets used even a few times, word will get out. When some ring of baby-rapers gets caught and prosecuted with evidence that was obtained through said back door, word *will* get out.
So what happens then? A million drive purchasers demand their money back. A million businesses that bought the drives because they were guaranteed unbreakable encryption join in class-action lawsuits against the drive manufacturers and resellers, blasting them into legal oblivion.
If I were a drive manufacturer, I wouldn't risk it. The secret would eventually leak and my company would be toast, overnight.
"Disk vendors are free to choose to use AES 128-bit or AES 256-bit keys depending on the level of security they want"
More likely, they will choose based on the power of the controller. Nobody would want less security.
. . it also has some pitfalls as well.
My company laptop runs whole disk encryption on it.
It's software based so it decrypts the drive on a
successful login to the main OS.
Therein also lies the problem.
In the event the OS goes screwy and doesn't want
to boot for some reason, you have no way of fixing
the problem without doing a complete re-image.
You can't boot your favorite Linux ISO disc and
drop into the Windows partition and ' fix '
anything as the entire drive is encrypted. Linux
doesn't even see the drive as a valid partition.
You can't decrypt it until it boots, and if it
doesn't boot you're stuck. Same thing is going
to apply to the hardware versions. A simple
glitch will kill everything on your drive.
I find it more to my liking to encrypt certain
directories or files instead. This way a soft
ware glitch ( which is far more common than a
hardware one ) doesn't kill my entire drive
leaving me with few ( if any ) options to
recover it.
It would take a forensic examiner all of 4 seconds to see that it's not a valid pagefile. Then they would be up your ass, as they know you're trying to hide data.
If you're going to do file name obfuscation, make it look like a binary dump and name if convincingly.
Disk firmware is a lame place to put this functionality, compared to the OS. When a bunch of vendors are working on a solution to a problem that no user has, beware. They aren't offering a feature; they are offering us a trojan.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This use-case is more or less dying out though. Because transporting bits across a border by having someone hand-carry them is just too large a risk, assuming it's the kind of bits the government of either country would rather not have crossing the border.
Do you think so? It probably depends on how much data you have. I figure it's probably easier to put several gigabytes of data onto a MicroSD card and smuggle it out in the sole of your shoe or under your foreskin or something than upload it from an internet cafe...
Yes, you can do read only file systems with RAID 5. As long as a disk never fails, because if it does, your performance is gone again while the array rebuilds. All the information on all the disks needs to be read in order to fix the failed disk. RAID 1 needs rebuilding too of course, but if that's a problem, you just add an extra disk or two to the array. You only need to copy one disk, not all of them.
Finally! A year of moderation! Ready for 2019?
That is why TrueCrypt includes hidden partitions and the secure OS feature (second OS installed on the hidden partition). That way, when the border guards ask you to enter your password you enter the one for the public OS, the machine boots, and the adversary, the border guard(s) in this case, remain ignorant of the secure OS installed on the hidden partition because of plausible deniability. The TrueCrypt boot loader handles all of this for you automatically depending upon which key is entered (the one for the regular or hidden partition).
Another problem will be for the IT guys. I have users drives working, but their machines dying till I get a tech here to repair it. This will firmly stop swapping of drives to other machines, cloning their data using a USB/Firewire. I imagine were going to be needing a TCG external hard drive enclosure.
Yep, software encryption has it's own set of limitations and vulnerabilities. The methods that I have tried for encrypting swap are all too slow to be usable, especially on Windows. You also have to consider remapped sectors and other factors that make it difficult to delete sensitive data that was accidentally written as plaintext. Using in-drive encryption gives you better general protection for the random sensitive data that finds a way to get into the normally unencrypted portions of the disk, while still using software encryption for known sensitive files. And all without any significant performance loss.
It's easy to get bits across a border, just make sure you wipe the disk with a secure wiper (dumps randomness on the disk) and reimage it.
Or that's what you say, for all you know the sysadmin guy put five checksummed mirrors under the randomness, say four and a half left now that the machine has been imaged. Maybe that's the reason he gave you a nice 500Gb drive. He doesn't have to worry about you booting it or using it a bit, he just has to make sure it goes wrong when you get back home ...
Of course re-imaging is the most reasonable thing in the world to do if the border patrols are known to be ... erm ... aggressive.
encryption doesn't work that way.
Sure. They've got the power. They can pull their gun and shoot you dead for no reason whatsoever, should they be so inclined. Depending on the regime in power, they may or may not even be able to get away with that.
But nevertheless, if the information genuinely isn't on your laptop, there's nothing they can do to get their hands on that information. Besides, in many situations, transmitting the information rather than transporting it means that you have no need to cross the border at ALL. (well, obviously you will need to do that if you're going in to get it, but not if the information is for example from an informant on the inside)
I recommend this practice heartily for everyone visiting USA, for example. The border-people claim the right to search anyone, without probable cause, and to refuse entry if they find anything suspicious, it's anyones guess if an encrypted partition to which you refuse to tell the password counts as "suspicious". (my guess would be yes, certainly yes if you have a beard)
So, much better to go to USA with a naked laptop. You can keep your data online somewhere, you'll still have full access to the data once you're inside USA.
It does depend on the data. But I do think that the easily accessible bandwith is growing faster than the size of data that needs to be transported secretly across borders, so that it's more and more practical to make the transport by data-transfer rather than carrying physical media.
There's going to be exceptions for a while, where your data is, and must be, huge, and you're transporting them from a region with very poor bandwith. But I do think the *trend* points towards the extinction of physical-media as a means of data-transport.
If it's risky data to be carrying, there's still no reason to hand-carry it across the border. If I wanted to get 10GB of unpopular data out of Iran (not completely random example, I've got several close friends in Iran), I'd *never* risk asking any of them to carry it. Rather I'd ask them to encrypt it, store it on a flash-card or something, and mail that card out, putting no return-adress on it, and if extra paranoid, have the card mailed in a different city than the one they live in.
It's not idiot-proof, but it's hell of a lot better than showing up at the border and hoping for the best.
If it was only 1GB, yeah, I'd ask them to upload it. Sure, it'd take time, but even by modem, you can upload a gigabyte in about 30 hours. If there was no rush, I'd ask them to do it 50MB a day, spread over 3 weeks. Wouldn't be that suspicious, particularily not if the upload happened to https://www.flickr.com/ https://mail.google.com/ or a similar site where it's non-suspicious to upload 50MB worth of data every now and then.
"... the key is never visible to the CPU at any time..."
If the CPU is used to decrypt, the key must be available to the CPU. Anything that happens in the CPU must use the registers of the CPU.
It can be arranged that the password is never seen by the main CPU, but that requires another CPU, which may also have vulnerability.
At present, it looks as though TrueCrypt is very attractive. It's open source, a necessary quality for encryption methods. Hardware-assisted encryption would not be open source. TrueCrypt can and does use methods of preventing boot-time attacks.
From the TrueCrypt documentation: "Note that TrueCrypt can encrypt an existing unencrypted system partition/drive in-place while the operating system is running (while the system is being encrypted, you can use your computer as usual without any restrictions)."
That means that TrueCrypt system partition encryption is available to existing systems, a huge advantage, since any organization has existing systems.
Really short explanation of difference between TrueCrypt and native hard drive encryption: With TC, the laptop's cpu sees the key used for decryption; with native HD encryption, only the microcontroller on the hard drive sees the key - the laptop CPU never sees encrypted data, hence, it doesn't need the key.
If the hard drive microcontroller computes the key from, say, the hash of the password, then it can store the key in its internal registers, and the key itself never goes across the bus. When the drive is powered down, the key is lost. Hence, you have a securely encrypted drive which cannot be read without the password, and cannot reveal the password to a hacker.
The society for a thought-free internet welcomes you.
I don't see how this standard can receive wide acceptance. It seems to be designed only for very unusual requirements.
First, if the main CPU doesn't do the encryption, another CPU of equal speed must be provided. Otherwise the encryption and decryption will be very slow. That means double the power and heat dissipation requirement.
Second, read this from the ComputerWorld article: "When a USB drive is unplugged, or when a laptop is powered down, or when an administrator pulls a drive from a server, it can't be brought back up and read without first giving a cryptographically-strong password. If you don't have that, it's a brick. You can't even sell it on eBay."
Does that mean a lost password causes a complete loss of hardware?
TrueCrypt is FAST. It is FREE. It is OPEN SOURCE.
Would you trust a hidden encryption system? The U.S. government has established that it can act in secret, and put executives in prison if they don't cooperate. How would you establish that there is no hidden system to decrypt the data?
Third, read the specifications. They are poorly written.
First, if the main CPU doesn't do the encryption, another CPU of equal speed must be provided.
AES can be implemented in hardware for an almost trivial amount of gates these days. To encrypt/decrypt data at the rate a modern hard disk speeds is child's play for dedicated hardware. Typical performance is one AES block per clock cycle, meaning a 1 Mhz clock speed would give a 128 Mbs encode/decode.
Even lacking dedicated hardware, they're putting 100 Mhz processors in microcontrollers these days. Atmel advertises .5 mW (mA? - I forget) per Mhz microcontrollers these days, so a 100 Mhz crypto controller would consume the equivalent of five LEDs. The drive motor is going to be the largest power concern.
The society for a thought-free internet welcomes you.
I found this quote on the Atmel web site: "... the SAM7X offers 80 Mbps AES encryption throughput, which is 20x faster than a software implementation." I didn't know AES in specialized processor hardware was that advanced.
However, the other questions remain:
1) Does a lost password cause a complete loss of hardware? The article referenced by Slashdot implies that it does?
2) Would you trust a hidden encryption system? The U.S. government has established that it can act in secret, and put executives in prison if they don't cooperate. How would you establish that there is no hidden system to decrypt the data?
3) The specifications are poorly written. It would be scary to partner with such a disorganized organization. TrueCrypt is proven, and works very well.
4) Is a hardware implementation really more secure than TrueCrypt? TrueCrypt could, for example, overwrite memory 20 times before exiting. A shutdown command could overwrite all of system memory.