When dealing with Initial trust it is important to figure out who is trusting what.
Verifier - The entity that wants to trust the platform.
Platform - the vPro platform everyone is buying (you are buying one aren't you?)
Platform Configuration - the set of software measured by the platform (vPro measures BIOS and if executing the VMM)
Platform credentials - evidence of the platform properties which on vPro includes presence of TPM and the ability to execute TXT.
Now with these definitions let us work through a few trust decisions.
IT wants to trust new platform in the enterprise
Here we are assuming that the platform is brand new. The IT department uses the platform credentials to ensure that the platform delivered matches the platform credentials. If the platform does not come with credentials IT can create credentials for internal IT use.
Trust here is on either supplied credentials or direct creation of new credentials.
IT wants to trust a platform as it attaches to the network
here the platform contacts an access point (wired or wireless) and before assigning an IP address the access point asks for the current platform configuration. The trust necessary here is that the access point has to have sufficient evidence of the platform properties (credentials from our first use model) and then the access point obtains the platform configuration and validates the TPM report. (note that this is just the network access control protocol)
The access point must be able to determine what is a valid platform configuration and it does not matter if it is the first time the platform connects or the 20th time. The only issue is does the access point understand the platform configuration, if it does then the access point grants access, if it does not the access point blocks access. Determination of a valid platform configuration includes knowing what BIOS is supposed to be present and which VMM is supposed to be running.
Trust in this model requires the platform evidence (credentials) and the ability to understand the platform configuration.
Timing for the first two models does not matter. Whenever IT creates the evidence it is sufficient for IT, does not matter if it is the first day of use for the platform or in the second year of use. If one is using NAC, then the credentials provide the root of trust to believe the measurements and then the measurements provide information on the platform configuration. What else is executing on the platform does not change what measurements were taken. Measurements are not a one time operation but occur each time the associated root of trust executes (static RTM that is on each boot, dynamic RTM occurs on each invocation of GETSECSENTER). It does not matter what else is executing or has executed, the measurement represents what occurred during the execution of the RTM.
Understand that platform configuration would not normally include the entire application stack. Rather the measured environment would provide additional measurements for applications. The entries in the PCR represent those components measured by the RTM and do not normally include applications. For instance when launching TXT the DRTM measures the SINIT authenticated code module, the measured launched environment (MLE), and a few registers. That is it. No applications, additional measurements would be provided by the MLE for applications or environments the MLE launches.
Applications can not just register with the TPM, there must be some process that measures the application and stores the measurement into some repository (which may or may not be the TPM).
Hopefully this little explanation helps in who is trusting what.
David
One question I have is with regard to the Dynamic vs Static root of trust for measurement, DRTM vs SRTM. I understand that Intel TXT implements the new DRTM. This allows the OS at any time to do a "late launch" of a measured environment. The computer is reset (to some extent) and TPM measurements pretty much start from scratch.
The advantage of DRTM as I understand it is not so much that you can launch late, because the post-launch environment is designed to be largely indistinguishable from the pre-launch one as far as the end user is concerned, so you might as well have launched early; in fact I suspect that in practice the DRTM will usually launch as part of the boot sequence. Rather DRTM is supposed to reduce the trusted computing base, that is the amount of code that has to be perfect in order for the whole chain of trust to work.
With the old SRTM you have the BIOS that starts up, the first part of the BIOS measures the rest of the BIOS, all this firmware in disk controllers and other devices that gets measured and executed. Any flaws here and your trust assumptions don't work. You have to make sure that the BIOS startup code (core root of trust) can't be reflashed - a provision that some PC manufacturers haven't met (hopefully not vPro machines). There are a lot of assumptions.
With DRTM the hope is that you can start with a clean slate well after the BIOS is done, and can go relatively quickly from the initial state into a hypervisor or microkernel, measuring each piece and not having too long a chain of trust. There is less code to measure, it comes from fewer vendors, and in general it is a much more controlled environment. (And, importantly for my interests, most of it can be open source.)
My question is A, is this reasoning correct; and B, to what extent can we really achieve this goal? Is the late launch really immune from misbehavior earlier in the boot sequence? Or are we still ultimately dependent on the BIOS and various firmwares doing the right thing during boot, so that in effect all that code is still part of the TCB? Thanks!