Neat, if you disregard the (justified? unjustified?) widespread suspicion of TPMs.
However, this only prevents an attacker copying the key to another machine. If the attacker has access to that key, then they have access to your machine. Not much stops them from installing malware and using your machine as a proxy for the session they want to establish to the endpoint (with the additional benefit of appearing to connect to that endpoint from your machine in any connection logs).
It should be noted that ssh, gpg-agent, and OpenPGP smart cards already provide the capability to store an SSH key on a removable smart card. Storing your key on a smart card provides the additional barriers that such a proxying setup would only work 1) while you have the card inserted, and 2) if you authorize that access by entering the PIN (optionally through an un-observable channel if you have a Class II or III reader). Of course such hypothetical malware would still be able to inject commands into a session once you log on to the endpoint, but it would be much harder to avoid your detection.
Of course, most modern machines come with a TPM (right? correct me if I'm wrong), while very few people have an OpenPGP smart card.
Suspicion of TPMs has, so far, been just wrong. Most machines don't have TPMs; they're usually a feature on "business" laptops. Lenovo's ThinkPads have them, IdeaPads don't.
But now Windows 8.1 apparently makes OEMs ship a TPM to provide transparent device encryption for tablets - so it should become more commonplace. (It might only be for ARM devices though.) I'd assume those TPMs provide the full APIs and capabilities others do.
Intel has a habit of trickling down features of "business chips" to the consumer chips. If I'm not mistaken, they may even be the same chips, Intel just disables those features for lower-end chips. So it's just a matter of time.
I think it's right to be very suspicious of these chips, especially since Intel has been awfully quiet despite all the accusations, and we do know that NSA has been trying to get "encryption hardware vendors" to subvert the encryption for them.
> Neat, if you disregard the (justified? unjustified?) widespread suspicion of TPMs.
Most of the TPM fears are about its secure booting features, about locking in a machine to a certain OS or DRM code. This isn't using those features.
> If the attacker has access to that key, then they have access to your machine.
Not necessarily true. First of all they won't have access to you machine all the time. When you turn it off they won't have access to the key. Same when you improve your firewall rules (maybe).
I get a warm feeling from knowing that when someone logged in using a specific key, then a certain piece of hardware was involved in the handshake. Not "someone logged in", but "someone logged in using this exact laptop".
> It should be noted that ssh, gpg-agent, and OpenPGP smart cards already provide the capability to store an SSH key on a removable smart card.
Initial models did ship with a TPM, but current ones do not. Install Windows Vista or later via Bootcamp and it'll gladly tell you about the lack of any such chip.
If you want a solution for secure ssh key storage that is based in hardware, I would look at using a GPG Card or other smart card solution. Smart cards are more portable, more standardized, and you're not dependent on physical possession of a particular hardware component.
The big caveat being that if you need FIPS 140-2 validation, you'd need a commercial smart card solution.
Note that the Trusted Computing Group has seen the controversy over Snowden's leaks as useful tool for spreading propaganda about the TPM and their goal of establishing a root of trust.
They acknowledge that almost nobody actually wants a TPM ("There has been no market driver to incorporate TPMs"), and observe that post-Snowden there are more people looking to improve their internet security.
Therefor, the plan is to repudiate the NSA, ("The manufacturers of TPMs must demonstrate that there are no back doors in their products." - at least not an NSA back-door...) and push their usual word-games about the TPM such as "secure end-to-end communication [...] made possible [...] with TPMS.
So it may be prudent to question the motives behind any of these new attempts at justify the TPM.
What is the general consensus on TPM? Is it trustable? Bitlocker is the only encryption I know that makes use of it. Weirdly, Truecrypt is stern about never ever using it.
Assuming no foul play, I think a combination of TPM (Hardware based Keys), Secure boot and Open source encryption should be enough to keep your data safe from any prying eyes.
Are there any TPM implementations where the user doesn't control the TPM? And by user, I mean the owner of the physical device (so a company over its laptops, a person over their laptops).
I've not heard of any TPM that has some other owner, like the claims against TPMs have said. TPMs aren't needed to provide a DRM scenario - UEFI Secure Boot can do that by itself, right?
> Are there any TPM implementations where the user doesn't control the TPM?
The design of the TPM prevents the user from ever fully controlling it, so complete revocation of access is unnecessary. Anything in the system/bootup can update a PCR, revoking some or all access to essential keys.
Take the chromebook I am using right now. The user can disable secureboot (which isn't actually implemented with the TPM) and use an unsigned image, but can not create an image signed by themselves.
With either boot, I nominally have control of the TPM, so far so good. But the PCR values written by the boot process will be different so I can not use keys from one boot in the other. For example, my encrypted filesystems from the google boot are inaccessible.
This is great for the security of my data if my chromebook is stolen. But it also means a web service like my companies' VPN or MPAA's movie server could demand that I use attestment to show I am using a google configured chromebook, if I did a custom boot the attestment will not have the right PCR values, so I am incapable of using the service.
> TPMs aren't needed to provide a DRM scenario - UEFI Secure Boot can do that by itself, right?
AFAIK, UEFI secure boot limits the device based on a list of public keys, but has no access to any form of secret key. So booting an insecure clone to contact a DRM protected service (or otherwise emulate the secured device) works perfectly fine.
The scenario you outlined is exactly the point of a TPM. In the case of an "MPAA movie server", exactly how would they verify the remote attestation? As I understand, they'd need to have some way of verifying your key. You would have had to opt-in to such a feature, right? The simple act of having a TPM doesn't give arbitrary third parties the capability to verify remote attestation. Unless I'm missing something critical.
On Secure Boot, you're right that a clone works. But if your device doesn't have an open Secure Boot system, like WinRT, then that device is DRM'd up as the OS can fully decide which programs to allow. An insecure clone means another device, but point taken.
Yep, to be clear I was pointing out that a TPM with remote attestation can't avoid implementing DRM in the true sense of protecting specific content to the extent possible on the device.
I think the permanently gimped system stuff like a key restricted secure boot is really something else. It is in some sense an acknowledgment of the impossibility of DRM actually preventing every single copier and gains more from leveraging its play time monopoly to lower the value of all non-DRM content which may or may not be pirated.
A system that denied all open content with a TPM would indeed be very broken in terms of design and would only start to make sense if the hardware was much more customized than a typical PC platform.
Another problem with UEFI Secure Boot is that boot images can apparently only be signed by one key, which is why we see crazy things like Canonical going to Microsoft to get their Ubuntu images signed. (It's a nice, subtle, anti-competitive trick, IMHO.)
The problem with TPM is that the quality of the implementation varies, and the interface is vulnerable to attack. When you move away from first tier oems like HP and Lenovo, you find all sorts of wacky things, TPM chips that don't implement the TCG standard, removable modules, etc.
For the average person, a TPM with a technology like BitLocker is a good way to protect your data. If you have compliance requirements or real secrets to keep, you need to understand your implementation in detail.
For corporate security, TPMs are a great gift. Installing TrueCrypt or requiring people to keep a password or USB key is extremely annoying. With a TPM, we can get a fairly decent level of security in a completely transparent way (much less to worry about lost laptops). And at the cost of a 4-digit PIN, we can up the security significantly.
I want to know this too. Last I ever heard about TPM was that Treacherous Computing campaign which said that TPM was supposed to be the ultimate DRM scheme which was supposed to lock you out of your media, files, and the computer if it didn't like what you were doing.
If I recall correctly, some motherboards feature a removable TPM module that uses a standard 2x10 0.1" header. Perhaps some sort of custom ATMega or FPGA based open source crypto module could be hand-built that conforms to this interface?
However, this only prevents an attacker copying the key to another machine. If the attacker has access to that key, then they have access to your machine. Not much stops them from installing malware and using your machine as a proxy for the session they want to establish to the endpoint (with the additional benefit of appearing to connect to that endpoint from your machine in any connection logs).
It should be noted that ssh, gpg-agent, and OpenPGP smart cards already provide the capability to store an SSH key on a removable smart card. Storing your key on a smart card provides the additional barriers that such a proxying setup would only work 1) while you have the card inserted, and 2) if you authorize that access by entering the PIN (optionally through an un-observable channel if you have a Class II or III reader). Of course such hypothetical malware would still be able to inject commands into a session once you log on to the endpoint, but it would be much harder to avoid your detection.
Of course, most modern machines come with a TPM (right? correct me if I'm wrong), while very few people have an OpenPGP smart card.