Slashdot Mirror
EFF Position on Trusted Computing
Seth Schoen writes "EFF has just released our
analysis
of Trusted Computing. We find that the technology could benefit
computer security, but must be fixed to ensure that the computer owner
is always in control. We also propose a specific way of fixing it.
There's coverage
of our position at news.com. More articles should be up in
the near future at
the new EFF
Trusted Computing page. Thanks to all the people who helped us
understand this technology!"
Microsoft's chief security strategist made the surprising statement that the company is about one-third of the way to its goals for Trustworthy Computing. I guess there's a lot more going on internally than we're aware of.
The article also says, "Microsoft's short-term strategy will shift from patch management to what the company calls 'securing the perimeter.'" What this means is that they're working more closely with firewall companies.
Even the proposed "Owner Override" seems to me a "how are you going to do that" issue. How are you going to assure that a change was made by you and not by some software pretending to be you?
The idea would be to use the secure I/O capabilities to make sure the user approves the change/override at the keyboard, which can't be spoofed by software in a TC system.
"Identity" of software is determined by submitting a hash value, but how can you be sure someone's not sending a canned hash value?
The hash value is cryptographically signed by a key generated in the Trusted Platform Module. The key never leaves the chip and only the chip can issue such signatures. This is what makes sure that the hash values are correct.
The EFF's proposal actually amounts to letting you submit a spoofed or canned hash value, which makes the whole attestation feature useless.
"Secure output can prevent information displayed on the screen from being recorded" -- until someone invents a screen-scraping monitor. If information exists, there's a way to copy it. That's just what information is.
The (claimed) purpose of the secure I/O is to prevent software in the computer from being able to see certain parts of the screen. Obviously the user can see it, photograph it, etc.
The most serious point of all -- that the EFF is lending credibility to this blatant grab for dictator-like powers by suggesting that it can be "fixed" and the problems "addressed", at which point we should all happily adopt it.
This is just inflammatory rhetoric, something the EFF analysis was refreshingly free of. There are no dictator-like powers being grabbed here. At most, TC lets you prove your software configuration to third parties, allowing them to refuse to perform services for you unless you use certain software. That's hardly dictatorial.
There are some other problems with Trusted Computing that the EFF article fails to address.
One is the difficulty of dealing with upgrades, failures and replacement of computers, if your data is locked to the old machine. TCPA had a hugely complicated process you would have to go through to migrate any of your "secure" data to the new machine. It involved going back to the manufacturer, getting a special transfer key, moving the data over and having it get re-encrypted. Microsoft hasn't said what they're going to do, but it's an extremely difficult technical problem to solve while retaining the security.
Another problem is the PKI (public key infrastructure) issue. For remote attestation to work, it's necessary that the TC chips have some kind of crypto certificate that says that they are legitimate. Microsoft has said nothing about who will issue these certificates and who will revoke them if a machine gets broken into. Setting up a successful, global PKI is a prerequisite for DRM type applications and will be an enormous job.
The article also overlooks that the sealed storage feature, which the EFF mostly views favorably, can also be used to achieve lock-in and secure closed formats. Microsoft Word could store data encrypted using the TC hardware, such that only Microsoft-signed applications can access the data. This kind of lock-in does not depend on the remote attestation features that the EFF is so concerned about, and would not be addressed by their Owner Overrides.
I agree. The EFF has to understand that their box at the end of the article COMPLETELY ignores the part of the point of TC. Part of the point is to reduce software piracy. Like it or not, every time you copy windows/office/whatever and give it to your buddy, you are committing software piracy. Part of the point of TC is to prevent this - mainly by preventing the user from circumventing product activation. This is a worthwhile goal. The A+OE position has all the cons of the current status quo! How is this an improvement?
How are you going to assure that a change was made by you and not by some software pretending to be you?
Actually that is pretty easy, you press a special button/switch. Malicious software is incapable of faking actual physical control. I proposed exactly such a modification to TCPA months ago.
I e-mailed this one of the main TCPA proponents about this back in January. It was David Safford, author of Why_TCPA and TCPA_Rebuttal. I explained this system and pointed out that there every single claimed benefit of Why_TCPA works just as well with actual and full owner control like my (and the EFF's) proposed modification grants. He did not dispute this.
His only reply was to suggest this change would no longer keep laptops secure against a thief. This suggestion fails on two grounds. First of all it directly contradicts TCPA_Rebuttal where he claims TCPA is not designed to be secure against physical access and that this supposedly 'proves' that TCPA is not designed for DRM. If TCPA is not supposed to be secure against physical access then it is disingenuous to claim it is supposed to protect a laptop against theft. The second reason his 'theft' argument fails is that it is simple to combine a physical button-press with an owner ID code or password before full control is given. A theif cannot get this owner password, and software can neither get the password nor press the button.
Granting the owner of the machine to his own keys (passwords) that are locked in the TCPA chip gives the owner full control over the system. There is absolutely no justification for denying the owner access to his own keys. The only purpose for this design requirement is to use it as a weapon against the owner and for various varients of DRM.
Of course Microsoft and the TCPA proponents will never accept my proposal (and the EFF's proposal) because the only real motivation for this hardware change is for DRM-type purposes. If owners maintain actual control over their machines and it can't be used for DRM systems then the entire project is a waste of time. Everything else is just a smoke-screen. TCPA will not prevent your computer from being infected with a virus, and it will not prevent that virus from slagging your entire hard drive and everything on it. The only thing it will do is prevent the virus from distributing copies of your 'secure' music files.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.