On Fri, 9 Jan 2004, Shawn Willden wrote: > On Friday 09 January 2004 12:10 pm, Jesse I Pollard wrote: > > All the TCPA really does is implement a trusted kernel to run a > > non-trusted OS (anybody recognize "microkernel" in this?). And prevent > > ANY access to the system other than theirs. > > I think you've been getting your TCPA info from slashdot ;-)
No, but I do see where you could get that idea. > TCPA actually doesn't do any of what you said, but does do several other > things. Only when combined with their (future) BIOS mandates, and when the software comes preloaded. > TCPA doesn't provide any sort of a kernel, a TCPA TPM (Trusted Platform > Module) is simply another device on the system bus that can do a few > things: > > 1. Hash data and store the hash in a register. The idea is that the BIOS > will feed boot data to the TPM and let it hash it. The kernel will then > feed other data to the TPM, etc. so that after the system is fully > operational, the register contains a hash that represents a particular > system state. To me, this would be the security kernel. > 2. Perform cryptographic operations using keys, which are effectively > stored in the TPM and never seen outside of it in unencrypted form. > Further, specific keys can be "bound" to specific system states (via the > register). > > 3. Generate cryptographic certificates attesting to the value in the hash > register. > > To see how this is useful (for people other than MS -- forget them for the > moment, although I'll come back to that), suppose you want to protect the > data on your hard drive from unauthorized access by persons who may get > access to your machine (e.g. by stealing it). A good way to do this is to > encrypt the data, but where do you store the keys? In your trusty TPM, of > course. But how do you control access to the keys, and how do you ensure > that your machine hasn't been trojaned? TCPA provides a way that you can > make sure the keys are only accessible when the system is booted into a > known state. In theory, if the system is built correctly, introduction of > a trojan will cause the hash to change and the decryption key to become > inaccessible. This is assuming a laptop... and that the owner will be allowed to load/generate the keys. Is mostly useless for multi-user systems (including multi-user laptops). > That's one example. There are others that make use of the remote > attestation capability. > > One thing TCPA can *not* do is control what software you run on your > computer. It has no ability to control the boot process; it just responds > to service requests and decides which ones it will and will not answer -- > much like a smart card, actually, but with a much faster processor and > data path. Depends on the BIOS - which would have to check hashes of the kernel it loads (the secondary loader/OS). The discussed spec (the original spec wasn't available to me, this was an article on the original) that I read incuded a mandatory "trusted" region on disk. > HOWEVER, there is a way that this useful security tool can be exploited by > MS or others. A cooperative system manufacturer can pre-install a > "approved" operating system on new machines, can then ask the TPM to > generate a certificate attesting to that configuration, and can then sign > that certificate, providing an assurance that the machine is > "trustworthy" (i.e. running the approved OS). you got it. > This signed certificate can then be presented by the system, along with a > current attestation, to prove on-line that the system is running the > approved OS, and on-line services can, of course, refuse to provide > services to unapproved systems. Further, strong DRM can be done by > sending decryption keys to a TPM, encrypted for that TPM only, in such a > way that the TPM will only decrypt them when booted in the approved > configuration. And, of course, the approved configuration will carefully > honor all DRM restrictions. Or the attestation is used internaly as a self check before checking for "authorized" applications, and denying unauthorized applications permission to run. (as in: no unsigned software may run...) > So, although TPM (as currently specified) cannot be used to prevent > "unauthorized" operating systems from running, it can be used to deny > useful services to those who use them, as long as manufacturers are > willing to help out. > > It's not clear that there's any way to use a TPM chip to identify a > configuration that wasn't created in a controlled environment. Maybe... though when done via the BIOS, it may be able to identify a trusted/controled system though. (the inverse) > Note that TCPA doesn't really help MS' stated aim all that much. It does > provide some assistance with protecting against trojans, but not really > very much, since it's not really clear what parts of the system should be > hashed and in what order to define the system state. This state needs to > be sensitive to small changes that could break security and simultaneously > tolerant of other kinds of configuration changes so as to continue being > available to legitimate users. It's not clear that you can do both. You can IF: 1. put the security kernel in ring 0 This is the real boot kernel... It uses it's own checks derived from the BIOS loader which must also perform the internal checks on the loaded kernel. This handles all program loads (not runs) so that it can verify the hashes (which may also be stored here/in the PROM chip). The last time I was dealing with MS, this would be the secondary loader (used to be MSDOS.SYS, hidden from directory listings...) 2. put the OS interface in ring 1 This would be current OS. HOEVER, all file access must be arbitrated by ring 0 access. (including executables). 3. put the user interface in ring 2 This one is more wishfull thinking, but is possible. It usually resides the the rest of the OS in ring 1, which would leave ring 2 unused. 4. leaving ring 4 for user mode. (I may have the ring order backward, but I don't think so) This would be a model for a microkernel derived system, with the security kernel in place to control the current OS. It could provide the block I/O for files and buss access. (USB might be exempt, since it cannot be used to boot from at the present time, but not sure since I'm not coding it). This is supposition, since I have nothing concrete about how MS will use it, but their PR indicates that the OS would be DRM trusted UNTIL some event removed their trust (as in running an untrusted application). > > The real vulnerability in TCPA is MS own -- the first of these systems > > that gets hacked will open ALL the other systems using it (when MS > > driven, that is). > > I don't think this is correct. The only central keys are the roots of > various certificate chains, and you can't get one of those from the TPM, > because they don't have the private keys. If you could extract all of the > secrets from one TPM, you could create hardware or software duplicates of > that TPM, however, which would make some exploits possible. No - hacked as in having the secret keys extracted from the chip and decoded. I can think of several ways to try this, though most would likely end up destroying the chip - as in, pop the cover off, locate the data lands, and then pass addresses directly into the chip and read the keys. In the case of vendor lockin operations, this attack would give access to all the keys that matter (the host keys of all installed systems - I doubt that there would be a unique host key for each unit. too many different hashes to generate, but is possible). It may also be vulnerable to a chip simulator... but I think physical attack is the most likely to work first. > > My major objection is that it requires handing over control of your > > system to MS. > > TCPA doesn't require it. TCPA plus collusion with hardware manufacturers > and others can make it painful to choose not give control to MS. And under their current contracts could mandate it- ...we cannot sell a computer without an OS installed... and installing it requires the TCPA to be configured. > BUT, there's a big hole here... as long as the TPM is a passive device, one > can always defeat it simply by lying to it. Replace your BIOS with > another that feeds the "desired" data to the TPM, boot a kernel that > continues giving the TPM what MS wants to hear, etc., and you can produce > perfectly valid attestations that are completely false. (as long as it can't do DMA on its own) I grant that the current implementation isn't everything MS wants, but it is the first big step. I expect them to put a second push (2 years) to have an additional CPU, ram, and expanded rom to be added to the chip (for "enhanced" security capability). > All of which must be why MS now wants to replace your BIOS with something > of their own devising... > > Personally, I think TCPA is an extremely valuable technology for users who > need serious security, but I'm also nervous about how it could be misused. It could be. Unfortunately, the current environment is NOT conducive to trusting the vendors of it. The last time built in crypto was done that I know of, it was on a Sun box (optional DES chip). And nobody really wanted that one either. ------------------------------------------------------------------------- Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
