* replace ReadPublic() by DecodePublic() when creating and loading keys: the current implementation calls ReadPublic() even if public data is already accessible
* drop handle() from the ak interface: it is unnecessary
* add Blobs() to attest.Key: to allow agnostic key marshaling
Found manually looking through the code. The activate credential could
crash the client, the secureboot and challenge generation could crash
the server.
* tbs.dll to not initialize on start up
so that it's not initialized when tpm support is not required
Changed author to my google.com user
* initialize tbs.dll and proc Tbsi_GetDeviceInfo during probeSystemTPMs
initialization is done in probeSystemTPMs as it's called before openTPM which requires support of the dll
changed author to my google.com user
* tbs.dll to load once
Changed the author to my google.com email
* Tbsi_GetDeviceInfo check to happen once
changed the author of the commit
Event log verification is terrible and easy to mess up. Even if you
replay against the PCRs there are still values that can be tampered with
or reordered. PCRs also shouldn't be trusted unless they're attested to
have come from the correct TPM.
Given this, it seems advantageous to add some ability to consume raw
event logs, even if it's just for debugging.
* Export InvalidPCRs field in ReplayError
In order to retrieve the Invalid PCRs which couldn't be replayed against the Event log, we need this field to be exported as this gives the exact and true information. Replay error events will give all the events, but doesn't give the exact PCR index which doesn't get replayed.
Following is the test to extend PCR 7 and verify the PCRs 7,8,9 against the Event log. Output:
```
event log failed to verify: the following registers failed to replay: [7]
ReplayError Events:=[107]
Replay Error Events PCR indexes=[0 7 2 3 6 9 8 1 4 5]
```
* Add Comment to the exported field
Some fields have default values, which also means they should be treated
as optional. Fix up the tagging to handle that. The natural defaults
here will work, so no need to make them explicit.
Context-specific fields in ASN.1 don't have explicit type tags in the
ASN.1 stream, so encoding/asn1 infers the tag from the type of the
struct field the stream is being unmarshalled to. By default string is
assumed to be PrintableString, which is only permitted to contain a
subset of possible characters. If a field is defined as UTF8String in
the spec then it may contain characters that are not permitted in
PrintableString, and in this case Unmarshal() will return an error. We
can avoid this by explicitly tagging any context-specific UTF8Strings.
Systems with TXT enabled may issue the TPM2_Startup() command from a
locality other than 0. In this case, the initial value of PCR0 will
represent the locality that the call was made from. This is exposed to
higher layers by an EV_NO_ACTION event that has data containing the
NULL-terminated string "StartupLocality" followed by a single byte
representing the state of the locality. As this event is EV_NO_ACTION,
it does not represent an extension in itself.
So:
1) Ignore events that are EV_NO_ACTION when replaying the log, except:
2) For PCR0, if an event is EV_NO_ACTION and contains the string
"StartupLocality", use the final byte of the event data as the initial
value of PCR0 for the replay.
Handle platform certificates that only provide a single property
The spec states that the PlatformProperties field of the
PlatformConfiguration attribute should be a sequence of key value pairs.
However, it seems that if there's only a single property present, it's
sometimes being stored as a bare key value pair rather than a sequence
with a single entry. Work around that.
A number of the struct definitions had broken tag definitions, which
meant some parsing was working by accident and some parsing was entirely
broken. Fixing this uncovered some additional issues (a mixture of
incorrect definitions and platform certificates that violate the spec),
so this is all cleaned up as well.
Attribute certificates are generally using RSA-SHA1 or RSA-SHA256
signatures, so include those. In addition, the CA signing restrictions
imposed for general purpose certificates don't apply here - drop that
restriction from certificate signature validation.
