Jason Spence writes:

- Really fast PKI crypto on a dedicated processor for ipsec type stuff

I don't think the TCG TPM is the really fast processor you're looking for; from all accounts I've heard, it's really rather slow.

- Provide a trusted "hypervisor" or "ring -1" environment from which authorized code can spy on the operating system and make sure it's not running any reverse engineering tools or known cracks before the authorized code can install itself or download privileged data like strictly licensed content or restricted documents, etc

I don't think "spy on the operating system" is quite the right term. It might be better to say "prove that the relevant parts of the operating system, if any, are completely unmodified". There is no intrinsic value judgment and there is also no attempt to identify particular _ways_ of modifying the operating system as "bad". At the same time, you can also try to reduce the privilege of the operating system to affect certain things, so that it may not matter to certain secure operations whether the operating system is compromised or not.

- Protected cert store in hardware that is somehow immune or resistent to tampering (I don't completely understand how this can't be attacked by patching the nexus on the hard disk; I'm learning more about it)

There is an ingenious thing called a platform configuration register (PCR) that contains hashes of running code. The hardware is designed in a such a way that, if the PCRs are used at all, at least the first PCR will accurately reflect the code first loaded and to which control was first transferred. Because of the way the hardware is set up, if you load different code (a different or modified nexus, for example), the PCR values are guaranteed to be different. To put this a different way, the hardware has (minimal, but security-relevant) knowledge of what software is running. If different software is running -- for whatever reason -- the PCR values will be different. The encryption and decryption keys for the seal and unseal operation are derived by hashing the PCRs, and the PCRs are derived by hashing running code. There is supposed to be no way to get arbitrary values into PCRs (which is actually an oversimplification, but you can pretend it's true) and so you can choose not to use them at all, but you can't choose to load values into them that precisely correspond to the values they would have been loaded with if you had booted an operating environment other than the operating environment you actually did boot. Therefore, the _availability_ of a valid encryption or decryption key inside the TPM -- to make an unseal operation work properly -- depends on what software is really running. You can have many different operating environments installed on a single PC -- differing by a little or a while -- and in principle they cannot unseal one another's sealed data at all, because each one has its own family of PCR values that results when it's booted.

I write a worm. It's a nasty little bugger. It pokes around your machine and your network for anything that looks like a credit card number. It's allowed to install itself in the protected memory area because it's ostensibly a popup blocker or spam blocker or something and I got it certified by NGSCB or whoever'll be in charge of handing out signatures.

There is no central CA necessarily implied by NGSCB. Loading these applets should require some kind of user decision and should not be automatic based on presentation of a certificate. The trusted computing applets are not supposed to have direct access to any hardware (except that they can take input directly from the keyboard when no other process is doing so, and they can write output directly to the video framebuffer). That is the NGSCB model. So they can't themselves directly "poke around your machine and your network"; they would need to have an ordinary (unencrypted) user-space agent that does that. In priciple, it should be possible to detect and interfere with the operation of that agent by standard anti-virus or IDS techniques. If there is some reason that the user-space agent can't be disrupted or detected -- which I don't imagine is the case -- then you have a severe problem. But note that the trusted computing applet can't authenticate the identity of the user-space agent code.

It joins a p2p network of other worms which can't be spied upon because the crypto keys are located in curtained memory and since your debugger doesn't have access to curtained memory, you can't get a copy of them.

This part seems very possible.

You can't get a copy of the destination addresses that your credit card numbers are being sent to either, because those are also located in curtained memory.

Since the worm applet needs to use regular operating system services to access the network, and since your computer is connected to a network you can observe, you should be able to see the IP addresses of the peers -- you can just run netstat, or you can run a sniffer, or a firewall that monitors connection requests. You can tell who the peers are. Of course, the worm can conceivably conceal where the _ultimate_ destination is, if the worm network is a store-and-forward kind of network. In fact, the attacker who wrote the worm can join the worm network in a way that looks like just another infected peer -- but unlike other peers, the worm author can decrypt the messages from all the other worms and make use of them. (But that can be done today. Just have worms join an IRC channel and post data there encrypted with some public key. The worm author can join the same channel -- pretending to be another infected victim -- and log what gets posted there, and then decrypt it with the corresponding private key.)

Oh yeah, and it'll fire up your modem and wardial for fax machines and randomly fax the credit card numbers around too, just because I like to be a pain in the ass.

I'm told there is a scheme like this in Europe now where people are unwittingly calling the equivalent of 900 numbers. But remember that in NGSCB the code in curtained memory can't access the modem -- it needs to rely on a user-space agent to ask the OS to do that. The OS could still enforce a policy saying that the agent can't actually access the modem, or the agent could still be detected by an antivirus program. -- Seth David Schoen <schoen@loyalty.org> | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), | 464 U.S. 417, 445 (1984) _______________________________________________ linux-elitists http://zgp.org/mailman/listinfo/linux-elitists ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 0.97c removed an attachment of type application/pgp-signature]