On Tue, 2007-05-08 at 23:47 +0200, Alfred M. Szmidt wrote: > An attacker who has physical access to your machine can pull the > disk and put his own kernel on it that will perform his own > nefarious tasks. But if you made use of the TC module then I > believe you can prevent him from being able to do this -- the > system will simply refuse to load his modified kernel. > > The attackar can then copy all data, install keyloggers, trojans, > backdoors and what not, so you are SOL anyway.
That's not correct; at least, not with this hardware. If the data is protected by TPM (e.g., encrypted with a TPM-controlled key) he could copy it but not read it, and if the OS' TPM protection was enabled (e.g., only able to run binaries signed with a TPM-controlled key) then he wouldn't be able to install that software in a way that it actually ran. The best an attacker would be able to do would be to swap out the hardware of yours with something he had control of; but even then, the TPM in the new hardware (if it even existed) wouldn't be able to access your data since the encryption keys in the hardware would be different - you'd basically have to retrieve the keys out of the TPM chip via scanning electron microscopes or some such. In many ways, a TPM chip isn't that much different to the FSFE membership card - you can have encryption keys in the hardware which are pretty tough to extract, and if the user has control over those, there are a lot of security features you can turn on. The fact that it's inbuilt into the hardware makes it tough to tamper with. It cuts both ways: it's very useful technology, and it's pretty well designed. If it were easy to bypass, people wouldn't care about manufacturers using it for other purposes (e.g., DRM systems). > This begs another question, how can you trust that the TC module > doesn't have a backdoor? Atleast with software, I can disect the > assembly output. That's not a problem particular to TPM chips ;) Cheers, Alex. _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
