Mike Frantzen wrote: > A PhD friend of mine (Rick Kennell) and I spent _alot_ of time discussing > how to establish a trusted client on an untrusted machine. His idea was a > customized kernel that would fetch a kernel module off the net at boot > time. The kernel module's purpose would be to verify that the running > kernel was intact and had not been subverted (only the known good kernel > was running without any unknown modules). I don't buy this at all. I understand the desire to solve this problem, but I don't believe either that you've solved it, or that it is possible to solve. > 2) Virtualized processor. Use something like VMWARE to run the kernel in > a virtual processor and take the checksum/key as soon as it is calculated. > Solution: There are operations that must be simulated in a virtualized > processor. Do alot of them and make the central authority > require the checksum/key be returned in a short amount of time. > (Example operation would be to add and remove TLB entries) Unworkable. VMWare on an Athalon or P III/750 is at least as fast as a 386. If you make the timing restriction tight enough to prevent virtualization, then you end up rejecting a significant number of legitimate clients. The new processors from Transmeta make this problem MUCH worse: the claim that certain operations must be simulated is due only to particular defects in the Pentium instruction set that prevent full self virtualizing processors. The Transmeta architecture would seem to allow one to load a software instruction set that efficiently virtualizes the x86 instruction set. Thus it is infeasible to resist the virtualized processor attack against a "trusted" client running on a hostile host. The remote host can interpret your pile of 1's and 0's in any way they choose. The only "trust" you can have in an anonymous remote processor is a cryptographic proof that the remote processor posseses a certain secret key. The assurance that the remote host posses the secret key is based solely on the computational difficulty in computing the correct solution to the cryptographic challenge, and that assurance comes only from imposing at least 40 orders of magnitude (128 bit keys) in difference between workload to solve the challenge with and without the key. Crispin ----- Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:29:23 PDT