> > [JC] When SENTER is executed, it will send the measurement of the SINIT > ACM to the TPM and that will cause the TPM to reset the DRTM PCRs (17-23) to > 0 and then extend PCR 17 with the hash of SINIT. SINIT will then execute > and extend more values into PCR 17, as described in sec. 1.9.1 of the TXT > MLE Developers Guide. > > PCR 18 is extended with the SHA-1 hash of the MLE. > Warning, bit of a rant here.
Let's suppose I want to prove to someone that I'm running a certain open-source piece of code, with a known hash. I want to prove that there is a particular key that can only be used for decryption by this particular piece of code. If that someone encrypts data to that key and sends it to me, he can have confidence that only this particular piece of code will be able to decrypt the data and process it. Since he knows what the code does (he has the complete source and binary) he can have confidence in how his data will be handled. To me, this is the fundamental problem statement that trusted computing aims to solve. It is where the name comes from. That person has reason to TRUST the COMPUTING which will be done on his data. TXT comes close to enabling this. It is a step forward because it reduces the amount of code that has to be trusted to behave properly. With regular TPMs you have the whole BIOS, all the other firmware that runs at boot time. Who knows what's in there. With TXT you have less. But not that much less. The problem is mentioned in the quote above: the SINIT module. What is this? What is in it? Who writes it? Is he competent? Is he trustworthy? The need to trust an opaque software entity, the SINIT module, is a huge barrier to achieving the goal I laid out above. It forces everyone who wants to use TXT to trust Intel or whomever else supplies the SINIT module. The fact that the SINIT module gets hashed into the PCRs is only a slight aid. Yes, the challenger can determine that a particular SINIT module was used. But what does that tell him about how trustworthy it is? Nothing much. Supposedly there is a signature on the SINIT module which gets verified by some Intel microcode, so the mere fact that the PCRs correspond to a particular SINIT module hash is evidence that the SINIT module was created by Intel, or someone they trust. But these modules are being updated periodically, and no one is told why. Were the old ones bad? Did they have security flaws? Should verifiers blacklist certain SINIT modules? There is nothing but silence on these issues. Challengers are not even allowed, by licensing restrictions, to disassemble SINIT. But it is absurd that we should even be considering such a step! Surely the obvious way forward is to publish the source code of the SINIT module, along with the build scripts and tool versions to allow any third party to confirm that a given SINIT source code produces a certain binary object file and a certain hash. This will provide transparency into the one major piece of code which everyone must trust, in order to use TXT. Without this transparency, the goal of Trusted Computing cannot be met. Users will never have solid ground to trust the attestations and signatures from a TXT protected module as long as there is a black box in the middle labelled "TRUST ME". Trust has to be earned, and the way to earn it when you are dealing with source code is to publish the code. That is the only mechanism which can allow trust to be based on reason rather than blind faith. I hope Intel is aware of how different these issues look from the outside versus from the inside. Of course Intel trusts SINIT; they can see what is in it! Imagine if some employee was responsible for this module and insisted on hiding the source code and providing the company only a binary image, promising that it did what it was supposed to. Obviously this would be intolerable in business. Well, that is exactly how the present practices look from outside. TXT has been around quite some time now. SINIT has gone through several iterations. Isn't it time to take the next logical step and remove this major obstacle to a fully transparent and truly trustworthy Trusted Computing technology? Rant off! Hal Finney
------------------------------------------------------------------------------
_______________________________________________ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
