Using the length of a digest to infer the hash algorithm is somewhat
fragile - if we end up with multiple hash algorithms that share the same
digest length, things will break. Instead, pass more complete digest
information through to relevant functions and figure things out by
mapping the TPM hash algorithm to the appropriate Golang type.
Crypto agile logs may contain digest types that we don't currently
handle. However, we still need to know how long each digest is in order
to read over the appropriate amount of the buffer. This information is
provided to us as part of the spec header - make use of it rather than
hardcoding the set of digests and lengths we know about.
@brandonweeks detected another case of the "make([]T, untrustedValue)"
pattern, which would allow an attacker to cause the parser to allocate
an unbounded amount of memory.
Fix this by reading one algorithm at a time instead of pre-allocating a
slice of algorithms.
A go-fuzz target for the ParseEventLog function. It has been tested
with go-fuzz and go-fuzz + libFuzzer.
oss-fuzz requires a statically built fuzzer binary, so `gofuzz` build
tags are added to avoid building files that depend on go-tspi. A mock
tpm_other.go file is also included to satisfy the `platformTPM`
interface.
It's best practice to define as much code, especially exported API, in
files that can build on any platform. With as little code as possible in
OS specific files.
Ensure files with build tags don't contain any exported APIs. This helps
us not accidentally define API that only works on one platform, or have
incompatible method defintions between OSes.
TODO: follow up with an "unsupported" implementation so this builds on
Mac or without CGO (e.g. for servers)?
Ensure an attacker can't alter the value we interpret by appending an entry of
the same type to the eventlog. Don't worry about events that come before the
EV_SEPARATOR for now.
This is being prototyped in an internal package as we start to open
source. This code will either live in attest, or in a separate eventlog
package in the future.
Currently the activation challenge lets a caller supply a source of
randomness other than crypto/rand, but it's not used in some places.
Plumb the source through the call chain.
This PR adds:
* Renames 'PlatformEK' to 'EK'
* More consistant support of EKs without certificates
* Removes HTTP GET to Intel EK certificate service
* Always populates EK.Public
This PR adds event log parsing logic. It's main goal is to require
validation at the same time as parsing, so structured events are always
verified against a quote. This new API replaces the exisitng "verifier"
package.
It's not a goal of this PR to parse the event data. This will be a
follow up, but since different users might want to parse different
events based on the OS, this API lets users of this package implement
custom event data parsing if they absolutely need to.
Event log parsing requires knowning both the public key and signing
parameters. Symmantically, this information should be from an attested
public key blob, not additional data passed by the client.
Introduce a new method for parsing an AIK's public key blob, returning
a new AIKPublic struct.
Was going through the godoc and it's not clear that this is ever used.
To clean up the API, remove KeyPurpose for now. This could probably be
an internal validation anyway, right?
We plan to identify AIKs based on their public key. The raw blob should
be available via the AttestationParameters, but we hope that users will
only use that struct for generating challenges.
Because this parses the public key on AIK creation and loading, this PR
should have existing coverage.
* Refactor serialized keys into own structure, in preparation for making Key an interface.
* Refactor key logic into separate structures for each platform/TPMversion invariant.
* Implement review feedback
* Generate and store a fake EK certificate in TPM 1.2 test setup.
* Fix run of gen_ekcert.go
* Write out NVRAM cert header when generating ek cert
* Remove build flag gating tpm12 tests.
