Menu
▾
▴
Re: [tboot-devel] How to validate the PCR measured by TXT?
|
From: Cihula, J. <jos...@in...> - 2008-04-17 17:04:03
|
Here is the text from the draft of the updated TXT spec (empirically verified on my system): 1.9 PCR Usage As part of the measured launch, Intel TXT will extend measurements of the elements and configuration values of the dynamic root of trust into certain TPM PCRs. The constituent values of these measurements (indicated below) are provided in the SinitMleData structure described in Appendix C.4. While the MLE may choose to extend additional values into these PCRs, the values described below are those present immediately after the MLE receives control following the GETSEC[SENTER] instruction. 1.9.1 PCR 17 PCR 17 is initialized using the TPM_HASH_START/TPM_HASH_END sequence. The HASH_DATA provided in this sequence is the concatenation of the SHA-1 hash of the SINIT ACM that was used in the launch process and the 4 byte value of the SENTER parameters (in EDX and also in SinitMleData.EdxSenterFlags). As part of this sequence, PCRs 17-23 are reset to 0. The hash of SINIT is also stored in the SinitMleData.SinitHash field. PCR 17 is then extended with the SHA-1 hash of the following items concatenated in this order: SHA-1 hash of SCLEAN ACM - SinitMleData.BiosAcmID (20 bytes) STM opt-in indicator - SinitMleData.MsegValid (8 bytes) SHA-1 hash of the STM (or all 0s if opt-out) - SinitMleData.StmHash (20 bytes) LCP Control Field of used policy (PD or PO) - SinitMleData.PolicyControl (4 bytes) SHA-1 hash of used policy - SinitMleData.LcpPolicyHash (20 bytes) Thus, PCR 17's final value will be: Extend ( SHA-1( SinitMleData.SinitHash | SinitMleData.EdxSenterFlags ) ) Extend ( SHA-1 ( SinitMleData.BiosAcm.ID | SinitMleData.MsegValid | SinitMleData.StmHash | SinitMleData.PolicyControl | SinitMleData.LcpPolicyHash ) ) Where the Extend() operation is a SHA-1 hash of the previous value in the PCR concatenated with the value being extended (the previous value is 20 bytes of 0s in the case of the first extend to a PCR). 1.9.2 PCR 18 PCR 18 will be extended with the SHA-1 hash of the MLE, as reported in the SinitMleData.MleHash field. Thus, PCR 18's final value will be: Extend ( SinitMleData.MleHash ) Joe On Thursday, April 17, 2008 9:46 AM, Hal Finney wrote: > On Thu, Apr 17, 2008 at 4:31 AM, Seiji Munetoh <sei...@gm...> > wrote: >> Hi Folks, >> >> Is there any way to validate the PCR[17] and PCR18] values? >> >> In case of Static-RTM, we can validate the PCR values by using >> the BIOS eventlog stored at ACPI table. >> But for Dynamic-RTM we don't have such eventlog. >> >> I just tried different tpm_extend combinations from digests >> in the tboot's console message. but I can't find the right >> combination to produce the PCR17,18 values. > > Hi, Seiji - Joseph Cihula shared the information below with me that > explains what goes into PCR 17 and PCR 18. He says it will go into the > next edition of the TXT architecture spec: > >>>>>> I wonder if you could report what is in PCR17 after a tboot launch >>>>>> using this SINIT module? >>>>> >>>>> I'm planning to update the TXT Prelim Arch Spec with this information, >>>>> but in the meantime, the contents are: >>>>> TPM_Extend( SHA1( SINIT AC module) ) >>>>> TPM_Extend( SHA1( SCLEAN hash (20 bytes) | MsrValidBit (8 bytes) | >>>>> StmDigest (20 bytes) | LCP Control Field (4 bytes) | LCP Hash (20 bytes) >>>>> ) ) where the second extend is the hash of the concatenation of the >>>>> specified values (72 bytes in all). You can get the listed values from >>>>> the SinitMleData structure. >>>> >>>> In looking at the SinitMleData structure in section C.4 of the >>>> document, some of these fields have slightly different names. No >>>> SCLEAN hash is listed, rather there is an SinitHash at offset 36. Is >>>> this actually an SCLEAN AC module hash? Then, MsrValidBit is called >>>> MsegValid and relates to the SMM Transfer Module stuff that I don't >>>> understand yet. StmDigest is StmHash, LCP Control Field is >>>> PolicyControl, and LCP Hash is LcpPolicyHash. So the main question >>>> here is the SINIT vs SCLEAN hash. >>> >>> Sorry for the confusion--here is the mapping of terms above to fields in >>> SinitMleData: >>> >>> SCLEAN hash -> BiosAcmID >>> MsrValidBit -> MsegValid >>> StmDigest -> StmHash >>> LCP Control Field -> PolicyControl >>> LCP Hash -> LcpPolicyHash >>> >>>>>> And then (sorry about so many questions!) how about the measurement of >>>>>> the MLE, which gets hashed, I think, into PCR18 (or maybe PCR19)? Is >>>>>> there any information about that, what exactly is hashed and what >>>>>> sequence of extends are done? >>>>> >>>>> The hash of the MLE is extended into PCR 18. >>>> >>>> I see, thanks. I'm a little unclear about what exactly is hashed >>>> though. It looks like it might be the linear-address region (under the >>>> mapping defined by the MLE page tables) starting from the >>>> FirstValidPage field in the MLE header as described in Table 9, and >>>> extending for "MLE size" bytes as recorded in the OsSinitData >>>> structure? Does that sound right? >>> >>> PCR 18 is extended with the hash of the MLE, as described by the MLE >>> page table. The hashing starts at the first valid page and continues >>> until a non-valid page. It will hash to the size specified by >>> OsSinitData.MleSize. > > Seiji, have you tried reading PCR 17 and PCR 18? What values do you get? > > >> I'm using Fedora8 and Xen-3.2 on DQ35JO board (BIOS v865) and my grub.conf >> is >> >> title Fedora (2.6.21.7-2.fc8xen) XEN 3.2 w/ TBOOT >> root (hd0,4) >> kernel /boot/tboot.gz >> module /boot/xen.gz-3.2 vtd=1 com1=115200,8n1 >> module /boot/vmlinuz-2.6.21.7-2.fc8xen ro root=LABEL=/1 >> module /boot/initrd-2.6.21.7-2.fc8xen.img >> module /boot/BRLK_SINIT_20070910_release.BIN >> >> Actually, the xen and kernel digest I found in the console massage >> were correct (same as the sha1 digest of gunziped file). >> >> But, the digest of SINIT code was somehow different. >> >> TBOOT: sinit_hash= >> b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d >> >> # sha1sum /boot/BRLK_SINIT_20070910_release.BIN >> 46f4e1c199c2983e8a8a115cd90c88353e7b08dc > > The sinit_hash is not the hash of the entire SINIT module, but only of > certain portions of it. This is described in section A.1.2 of the > Preliminary Architecture Specification: "The RSA Signature signs an > area that includes the sum of the module header and all of the USER > AREA data field, > which represents the body of the module. Those parts of the module header not > included are: the RSA Signature, the public key, and the scratch > field." This is the data which gets hashed to form sinit_hash. > > Hal Finney > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |