Hi Joe -
I am interested in the cryptography being used with regard to the
SINIT module and I wonder if you could answer some questions?
One thing I've been curious about is how (and why) the SINIT module is
signed. I did an experiment to look at how the signature is computed
in the sinit module header. I took the sig value and raised it to the
17th power modulo the key modulus, and got this result:
0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff004ded501d729278ff815ec7a9cdf0267f686012b2
That's good, or at least pretty good, it has the PKCS-1 v1.5 padding
followed by a byte of zeros, then the 20-byte payload which should be
the hash of the data. Now actually you should have the payload
preceded by some ASN.1 to represent the SHA-1 algorithm, but this is
pretty close to standard.
Then I took the file and snipped out the key, sig and scratch area,
and ran sha1sum over it, and got:
b21260687f26f0cda9c75e81ff7892721d50ed4d
Again, that's pretty good, it matches the PKCS-1 payload, except...
it's byte-reversed. So that's kind of weird. It's not a problem per se
but it's nonstandard, and it is interesting that the chipset or
microcode or whatever does this reversal.
So some of my questions are, does the CPU/chipset actually check the
signature on the SINIT module? And then, what signing key does it use?
Is there a signing key built into the chipset that it expects to see,
or does it just use the signing key that it finds in the SINIT header?
The latter would be a little questionable cryptographically, since
anyone could create a key and sign any AC module, putting their own
key and signature into the header. I guess it depends on what Intel's
purpose is in having this signature at all.
Related to this, is there any information on exactly what gets hashed
into PCR17 when this SINIT module loads? Is it exactly the same
sequence of bytes that the signature covers? So what gets extended
into PCR17 would be the hash I listed above? In that case, according
to my calculations starting PCR17 with zeros and extending the hash
value above would lead to this as the content of PCR17 after the SINIT
module loads:
3ee34dd343b5b94704a5e6844d4f85814bbe6c2d
I wonder if you could report what is in PCR17 after a tboot launch
using this SINIT module?
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?
Sorry about all the questions, but of course this information is
necessary in order to relate the contents of the PCR registers to the
code that was loaded, which is of course one of the main points of
this technology! So I hope you or Intel will be able to provide some
information about this soon. Thanks very much -
Hal Finney
|
