On Sat, Nov 29, 2014 at 6:44 PM, Mick <michaelkintz...@gmail.com> wrote: > > Thanks Rich, it seems not all modern MoBos have it. This doesn't: >
Interesting, I had really thought they were ubiquitous. > > If I enable this TPM thing, do I automatically open ports at pre/post-boot > time giving access to my machine? Or is remote attestation something I have a > say over? > It has to be implemented in software. The only thing the chip does is let software call it and ask it to sign data. The chip can't talk to the network on its own. Remote attestation doesn't actually give anybody access to your machine. Now, it does let you prove to somebody that they actually do have access to your machine, if you installed software that gave them access. Suppose I gave you a piece of software and asked you to install it on your machine so that I could evesdrop on everything you do. If you refuse to do it I'll fire you from your job. Without remote attestation you could install that software in a VM or emulator somewhere and tell me you complied, and it would be impossible for me to tell that you did this if your VM was well-implemented. On the other hand, if my software implemented remote attestation then the best you could do is block it, in which case I brand you as non-compliant and fire you. With remote attestation I could get a list of the boot path from the firmware to my software and see if there is anything in it that could tamper with my software. If I dictate that you have to run TrustedCo Linux v5 then I could see that you're running an unpatched version of it and know that my process is directly talking to the kernel, which I know doesn't let you tamper with it, and that kernel is directly running on the hardware having been loaded by a trusted firmware/bootloader. > Also, what happens if the TPM chip, or the whole MoBo blows up? Will I ever > be able to access my data using another PC? Only if you encrypted it. A TPM chip doesn't do much more than except store and retrieve data, and digitally sign things. It just tends to be used in a way that greatly limits the ability of arbitrary processes to access the data stored on the chip. With Linux you're basically completely in control. You choose to encrypt your drive and store the key in the TPM, and you instruct the TPM to only hand it over under the conditions you specify, such as a particular bootloader, kernel, and initramfs (or something like that - I've never implemented it myself). If somebody tries to boot your system with some other kernel/bootloader/initramfs then the TPM will not have the valid signature chain and it will refuse to divulge your full-disk encryption key. I imagine that you could generate the key outside the TPM and keep a copy of it somewhere and load it into the TPM, so that if you mess up you can just mount it manually. It is a bit like UEFI - if you use it properly it becomes a tool which allows the device owner to secure his own device against other intruders. The problems only come when people want to treat your device as if it is their device. With Linux you control almost all of it, though I would GREATLY prefer it if TPM chips did not come with vendor-supplied certificates (that is, if there was no way for anybody to determine if the master key inside was externally loaded by the end user or not). If they didn't come pre-loaded with certificates then they would be just as usable for securing your own machine (since you could add your own certificate/etc), but they would be useless for DRM (since no key was ever in the chip at a time when it was in the possession of somebody trusted by the media companies). I also don't have much more than a general interest in this area, so I'm sure there are some fine details above which are inaccurate. The gist of it should be right though. -- Rich
