OLS: Linux and trusted computing
Posted Jul 23, 2005 15:27 UTC (Sat) by
zblaxell (subscriber, #26385)
In reply to:
OLS: Linux and trusted computing by jwb
Parent article:
OLS: Linux and trusted computing
I'm having trouble parsing this...Who is "self" and who is learning? If "self" is the machine, then you're talking about AI software running algorithms that learn. If "self" is the machine's owner, then you're talking about a user exercising free software rights and learning some algorithms.
I don't see why it wouldn't be possible to run an AI under TPM, as long as the AI's bootloader doesn't change (or the AI is smart enough to have its SHA1 sums recertified before trying to do remote attestation ;-). Exercise of free software rights depends on who is signing the code, and what code they are willing to sign.
There are contexts where calcification is quite desirable. If I had one of these on my laptop, I'd use TPM to verify my initrd with the PCR's, then provide part of the key material that protects root and swap (why swap? software suspend). This turns dictionary attacks against the key into an exercise in hardware modification--without access to the data in the TPM, a significant part of the key material is missing. My key material in the TPM would be combined with a passphrase taken from the keyboard by initrd, so that a compromised TPM isn't sufficient to get the disk keys. I have no way to know whether a compromised TPM has permitted a trojan initrd to execute--but that's no different from the status quo.
Once this verification had been done and the key material retrieved, I'd have no other use for the TPM, so I'd put it in untrusted mode (which means I'd need to reboot to use it again). Once the machine is booted, connected to a network, and running application software, there's nothing I could store in the TPM chip (or on disk or in RAM) that couldn't be compromised by a malware attack or OS security breach.
Note that I might still use some parts of the trusted security stack even after booting--e.g. I might personally sign all of the executables in all of the packages I install, and configure the kernel to only execute executables signed by me--but no TPM is needed in this case, since the OS can (and due to limited space in TPM, must) do its own certificate management. That should slow some of the viruses down, if anyone bothers to write some. OTOH, as a user, if it makes OpenOffice.org load any more slowly, I'd probably just turn the whole feature right off. ;-)
To upgrade the kernel, I would reboot the machine, tell my initrd to go into single-user mode with the TPM still authenticated, verify the kernel is the same as the kernel I built, install it, certify it, put the TPM back in untrusted mode, and reboot (or kexec) with the new kernel. Hopefully the kernel's build-time environment or source code wasn't compromised.
Anyone capable of an attack on the physical hardware is probably beyond my ability to defend against them. To me, TPM is a device to prevent data extraction by common thieves, and little more.
TPM provides little or no protection against most malware as long as today's typical general-purpose OS architecture is used. TPM assumes that the OS is capable of enforcing access controls--TPM only ensures that the OS hasn't been modified, not that the OS is actually secure.
(
Log in to post comments)