> From: Jonathan McCune [mailto:jonmcc...@cmu.edu] > Sent: Friday, September 09, 2011 8:56 AM > > Hello again, > > Some progress to report! I've decided to write in with an incomplete > investigation because I > suspect lots of other folks have similar questions / concerns. > > First, thank you JP for sharing your method.
Indeed--a very good programmatic method for calculating PCR 17. > Upon reading the spec more carefully, I realize that the nested SHA-1 > expression for the contents > of PCR-17 is indeed correct: > > SHA-1 ( SinitMleData.SinitHash | SHA-1 ( SinitMleData.BiosAcm.ID | > SinitMleData.MsegValid | > SinitMleData.StmHash | SinitMleData.PolicyControl | > SinitMleData.LcpPolicyHash | > (OsSinitData.Capabilities, 0) ) ) Whew ;-) > What was not initially clear to me is that SinitMleData.SinitHash is not > actually the hash of the > SINIT for a Version 7 SinitMleData. It is the PCR-17 value following the > "first extend". As with This is described in the first paragraph of that section: 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 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. If the SINIT To MLE Data Table (section C.4) version is 7 or greater, the hash of the SINIT ACM is performed using SHA-256, otherwise it uses SHA-1. If a SHA-256 hash was used, the SinitMleData.SinitHash field will contain the value of PCR 17 after the initial extend operation (see below for more details). > a version 6 SinitMleData, there are two extends to PCR-17. The nested SHA-1 > expression in the > spec is actually a verbose version of the "second extend". To me, the > following is more clear: > > /* first extend (XXX have not confirmed that these inputs are correct XXX) */ > Extend-PCR17 ( sha-256 hash ( SINIT ACM | EdxSenterFlags ) ) This isn't quite correct: first, the TPM_HASH_START/DAT/END sequence isn't exactly the same as TPM_Extend, in that DATA can be more than 160 bits. Second, what is sent as DATA is 'SHA-256(SINIT) | EDX' (i.e. 36 bytes; see above quote from MLE Guide). > /* not an input to either extend, rather an intermediate value to aid in PCR > reconstruction post- > launch */ Read PCR17 into SinitMleData.SinitHash > > /* second extend (have successfully confirmed that this is indeed correct) */ > Extend-PCR17(SHA-1 ( SinitMleData.BiosAcm.ID | SinitMleData.MsegValid | > SinitMleData.StmHash | > SinitMleData.PolicyControl | SinitMleData.LcpPolicyHash | > (OsSinitData.Capabilities, 0) ) > > Once more: The "second extend" is equivalent to the SHA-1 expression listed > in the spec. > > Now, I have successfully recomputed the "second extend" taking on faith that > SinitMleData.SinitHash does in fact represent the result of the "first > extend" shown above. > However, I don't want to take it on faith. I want to recompute it. What > follows is my current > read of the spec, which is so far INCORRECT. However, I still want to detail > my thinking here, in > case anybody is able to point out where it goes > wrong: > > The "first extend" listed above: > Extend-PCR17 ( sha-256 hash(SINIT ACM | EdxSenterFlags ) ) ...breaks apart > into: > SHA-1(0x00^20 | SHA-1 ( SHA-256 ( SINIT ACM | EdxSenterFlags ) ) ) ... and > that result should be > equivalent to the value that I find in SinitMleData.SinitHash. > > Right now the thing that I believe is most likely to be incorrect is the > value that I am using for > "SINIT ACM" in the input to sha-256. I am simply using the entire contents > of the file > i5_i7_DUAL_SINIT_18.BIN. I suspect I need to parse that file and strip off > some metadata. First, you need to adjust your calculation per the comment about 'SHA-256(SINIT) | EDX'. Second, the SHA-256 of SINIT is not performed on the entire binary. Appendix A.1 "alludes" to how the hash is calculated (since it is the same as what is used in the signature): RSASig The PKCS #1.5 RSA Signature of the module. The RSA Signature signs an area that includes the some of the module header and the USER AREA data field (which represents the body of the module). Parts of the module header not included are: the RSA Signature, public key, and scratch field. > I will write in again when if / when I get this figured out. > > In the mean time, thanks for any hints that anybody can provide! > > Regards, > -Jon > > ------------------------------------------------------------------------------ > Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted > this study that > outlines how and why cloud computing security and archiving is rapidly being > adopted across the IT > space for its ease of implementation, lower cost, and increased reliability. > Learn more. > http://www.accelacomm.com/jaw/sfnl/114/51425301/ > _______________________________________________ > tboot-devel mailing list > tboot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tboot-devel ------------------------------------------------------------------------------ Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
