Bugtraq mailing list archives
Re: Trusted process on an untrusted machine?
From: crispin () WIREX COM (Crispin Cowan)
Date: Thu, 20 Jan 2000 06:16:12 +0000
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
Current thread:
- Re: IIS still revealing paths for web directories, (continued)
- Re: IIS still revealing paths for web directories Vladimir Dubrovin (Jan 12)
- Re: IIS still revealing paths for web directories Chris Tobkin (Jan 12)
- Altavista Free Internet Security Plex Inphiniti (Jan 14)
- Re: Altavista Free Internet Security Bill (Jan 17)
- Trusted process on an untrusted machine? Mike Frantzen (Jan 18)
- Re: Trusted process on an untrusted machine? Pavel Machek (Jan 19)
- Re: Trusted process on an untrusted machine? Mike Frantzen (Jan 19)
- Re: Trusted process on an untrusted machine? Pavel Machek (Jan 20)
- Re: Trusted process on an untrusted machine? Tim Newsham (Jan 19)
- Re: Trusted process on an untrusted machine? Anonymous Anonymous (Jan 19)
- Re: Trusted process on an untrusted machine? Crispin Cowan (Jan 19)
- Crafted Packets Handling by Firewalls - FW-1 case Ofir Arkin (Jan 19)
- Rh 6.1 initial root password encryption Ken Barber (Jan 20)
- Re: Rh 6.1 initial root password encryption Fabian Kroenner (Jan 22)
- Re: Crafted Packets Handling by Firewalls - FW-1 case Darren Reed (Jan 20)
- Microsoft Security Bulletin (MS00-005) Microsoft Product Security (Jan 17)
- Re: Microsoft Security Bulletin (MS00-005) bugtraq () NS DOOMSDAY COM (Jan 19)
- Re: Microsoft Security Bulletin (MS00-005) Matt Davis (Jan 19)
- Re: Microsoft Security Bulletin (MS00-005) Tabor J. Wells (Jan 19)
- Unixware ppptalk what's your style? (Jan 19)
- Re: Unixware ppptalk Andrew Malcolm (Jan 21)