Full-disk encryption for all computer drives, coming soon
computerworld.com
computerworld.com
Equivalent software encryption has existed for a while (it's built into Vista for example). But when you read about these Government or Financial laptops getting stolen with people's private information on them they're never encrypted. Why?
Because any info that's valuable is too valuable to risk losing just because someone lost the password. I mean, he says it himself...
"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."
So when you deploy this kind of thing you have to ask yourself if there's any circumstance under which that password could get lost. I'm not against the technology I just don't know a lot of people who will be brave enough to use it.
In many F-500 companies, disk encryption is already a corporate standard on all laptops; the organizations that are worried about losing passwords keep escrow keys. The problem people are trying to solve is, if you leave your car unlocked and lose your laptop, you don't have to cut a press release about how many SSNs you just lost.
People are used to security that can be circumvented if need be (through an administrators password or at worst a disk recovery service). When you're talking about hardware based encryption that option is no longer on the table and I think that rightfully makes a lot of people uncomfortable. In that way it's a huge risk.
Which is why things like bitblocker (again, built into Vista) don't get used.
This sort of "encryption in the sky" approach is available to consumers too. There are products by most of the big encryption vendors (like http://voltage.com/vsn/) that make it easy for a user to encrypt their data without putting themselves at risk for data loss.
You're assuming that they didn't lose the key as well.
You remember the key; it's the sequence of digits and letters on the post-it just beside the track pad.
When I go so far as to encrypt my drive then I'd rather use an open source product that I can download and compile myself. Not that I'd ever actually audit the source code myself - but at least I can be reasonably sure that multiple independent third parties have done it for me.
I don't understand what you mean by "Proprietary hardware encryption schemes are assessed by third parties all the time". Sounds like corporate speak to me. First, any "proprietary encryption scheme" is rubbish, and second, I should be the one to assess it.
My point with the drive encryption solution was that you are told that your data is encrypted, but you have no way of checking it yourself. What if encryption is disabled in your drive? Can you tell?
The final output of any encryption solution needs to be independently accessible, so that you can verify if it resembles white noise (which it should, ideally).
By "proprietary encryption scheme", I'm just referring to crytosystems for which you don't have the source code. You will have trouble finding any mainstream full-disk encryption vendor that isn't using something like AES, LRW-AES, or XTS-AES.
Nobody you care about is ever going to ship a product based on Super-Mega-40960-Bit-Matrix encryption. It's not 1994 anymore. There is absolutely no business case to be made for using nonstandard encryption: if you do it, you can't sell to the government, you can't sell it to any Fortune 500 company, and you get made fun of in magazine reviews.
I don't understand your "what if encryption is disabled in your drive" comment. What makes you think that's hard to check? Also, what makes you think that "secretly not encrypting an encrypted drive" would be a sane business decision for any vendor? They'd be open to spectacular liability. The first credit card processor that lost a secretly unencrypted disk drive would end up owning Seagate.
I'm sorry, I am not convinced. I would much rather run software than I can a) audit and b) check the output of.
(2) If you think that hardware-level analysis is out of scope for assessing a corporate full disk encryption system, you're out of step with the security industry; hobbyists do hardware analysis in their spare time. There are obviously likely to be much simpler way to verify encrypted storage than "looking at the platters".
(3) Like I said originally, if you're religious about open source, more power to you. It's obvious that there's little I can say to make you happy with the TCG. But, and I mean no offense, from what little I know of you it seems like they know much more about this topic than you do.
As to (3), I am not "religious about open source". My point was that at the very least I would like to be able to verify what the output is, which I can't.
Your arguments about companies' reputations being on the line are something I don't buy. This is hacker news, I buy technical arguments. And if you believe "reputable companies" don't do strange things with your keys or our data, may I kindly remind you of http://en.wikipedia.org/wiki/NSAKEY
Regarding (1), thanks for the reference, I will certainly learn more about the technology involved.
http://www.schneier.com/blog/archives/2009/02/the_doghouse_r...
(yes, I know this is about a hardware enclosure, not about a drive, that's actually lucky because someone could _check_ if the bytes are actually encrypted)
Now let's hear you mock Bruce :-)
Your problem is with Microsoft, not with hardware security. If you don't like Microsoft, don't run Windows.
The same eviction of malware can be achieved through a documented hardware interface to the lowest levels of microcode (say, JTAG). The current problem is not due to openness, but closed CPU microcode.
Would you please elaborate?
The simple solution is to allow easy updating of that base firmware through a dedicated hardware interface. A socketed DIP isn't hip anymore (eww through-hole), but a USB device header on the motherboard would certainly work.
I'd feel better about trusted computing technology if one of their design goals wasn't preventing physical "tampering" but instead they provided unfettered access through a debug port. However, it seems like they're aiming for the exact opposite in order to facilitate naive software, theft deterrence, and business model preservation.
I don't currently use remote attestation for anything, but it's a matter of time until some bozo decides that remote attestation is the way to solve online banking security ("if only we could be sure they weren't running malware!"), and brings the technology stack mainstream.
When that happens, the non-techies (seeing no distinction) will enforce their business rules on end user's computers (they occasionally try to do this now, but run up against reality). Client-side-only verification of form fields may be laughable now, but won't be so funny with no incentive to fix it because common people cannot exploit it.
Does that answer the threat model you're thinking of?
A lot of the stuff under the "Trusted Computing" rubric goes a lot further than what you're describing. Some of it is designed to allow third parties (other than the OS and the machine's owner) to establish a secure channel to the chipset and the hardware over the network. That is almost certainly a bad idea.
Obviously, if you give Microsoft permission to own your machine, it can go talk to Microsoft.com anytime it wants. But it already could without the TPM.
Is it the same threat model you were talking about? You didn't answer that question.
And while it's perhaps necessary and desirable that our machines contain tamper-resistant chips with public-key pairs in them, it's neither necessary nor desirable that the private key be secret from the machine's legitimate owner, which is part of the TCG scheme.
Do you spend a lot of time working with TPM/TCG technology? I don't want to sound patronizing; maybe it's me that's missing something.
Please explain how remote attestation can work if the machine's owner has access to the signing key.
(edit: having just read up on the newer Direct "Anonymous" Attestation scheme, I see that the signing key is no longer a permanent part of the TPM chip, but is generated with an issuer. Still, this generated key is kept secret in the "trusted" module, and my question remains)
I know the article is talking about secure storage and I'm picking on remote attestation, but they're both part of a technology suite which treats the end-user as an attacker.
A simple rule of thumb - if the capabilities of the hardware cannot be emulated by a VM, it's not in the owner's best interest.
But regardless, the EK and attestation schemes are just capabilities of the TPM chip. You can use them or not use them. The problem isn't the TPM --- which we need. The problem is what Microsoft wants to do with the TPM.
To answer your earlier question, I don't do any work with TCG standards, in part because I don't want to make the situation any worse and in part because I find modern computer security in general extremely depressing.
If, like most of us, you don't believe it's possible to have bulletproof software, then at some point you need something like the TPM to bind a known-good running kernel to your hardware securely. Without it, any bug in your kernel leaves you with no way to trust your system from that point on.
I think the TPM solves way more problems than it creates; for instance, TPM-related techniques will allow us to get rid of clunky hardware crypto tokens, and instead bake them into our machines securely; it will also potentially allow us to have public kiosk computers that are safe to use.
My only objection to TPM discussions is that EFF-types engage in a lot of hyperbole about them. It's true that the TPM makes it easier for Microsoft to enforce DRM and copy protection. But that's just a property of having better system security. Most of what the TPM does, you want.
I don't know what happened, but there must be a glitch somewhere in the software. I doubt someone has bothered to crack my account, Most likely there is a bug that attributes other posts to my user.
This is the second post that is not written by me. Does HN have a place to post bugs?