Add method to obtain TPM capabilities

[joshdrake]

This PR adds support for interrogating the TPM capabilities. The capabilities currently reported are the supported algorithms of the TPM.

As well, the TPMKMS will now:

• ensure that the TPM supports the algorithms for the requested signature algorithm
• default to the most appropriate supported signature algorithm based on supported algorithms

Future improvements may also ensure that the TPM supports the relevant hash/curve functions during sign operations.

💔Thank you!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ hslatman
❌ joshdrake
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[joshdrake]

@hslatman Any examples on how I would go about testing the SupportedAlgorithms implementation? Can I use the simulator testing bits in conjunction with legacy tpm2 package?

[hslatman]

Defining these here seems unnecessary if you make them assignments in both parts below.

[joshdrake]

v is used further down, I could refactor more of this code if you feel strongly.

[hslatman]

@hslatman Any examples on how I would go about testing the SupportedAlgorithms implementation? Can I use the simulator testing bits in conjunction with legacy tpm2 package?

I take it you mean the tpm.Capabilities method? It should be possible to use the simulator for a basic test. That test would go into tpm_simulator_test.go. Setup would look similar to the one for getting the TPM info: https://github.com/smallstep/crypto/blob/master/tpm/tpm_simulator_test.go#L60-L78.

The test would be limited to what the TPM simulator returns in terms of supported algorithms, which would always be the same, unless recompiled per test case, which doesn't sound enticing to me 😅 AFAIK there's no way to reconfigure the TPM simulator at runtime. To have more test variability we could look into mocking TPM responses on the io.ReadWriterCloser level, possibly fed by responses sourced from an actual TPM. For relatively static things like the capabilities, it'll probably be OK.

[hslatman]

Nice 👍

Just a linting issue left

[hslatman]

Can you turn the capabilities into a newSimulatedTPMOption, like withAK and withKey, only not operating on the tpm.TPM instance? Then it can remain variadic, and won't require changing it in the tests where you're now passing nil. It'll still need the special case to properly create the TPM instance, so there's still some logic needed to switch between "initialization" and "preparation" options.

[joshdrake]

Yea, I'll work on this more - I wanted to do that originally, but I think I'll have to change how options work between this package and the tpm package to be able to actually modify the capabilities.

[hslatman]

I think it can be done by changing the newSimulatedTPMOption to also return a type or bool (or to rework that into a struct), and to use that to differentiate between initialization and preparation options.

[joshdrake]

@hslatman Unless I'm not following you, I can't change this behavior without either exporting something from the tpm package to control the capabilities while under test (eg: either a helper Option setter, the options struct and field, etc.). I've removed that test code for now: what do you think about either mocking the tpm package itself or adding support to the Simulator to override the capabilities, eg (in the simulator package):

// the packed command buffer for CmdGetCapability (0x17A)
var getCapabilityAlgs = []byte{128, 1, 0, 0, 0, 22, 0, 0, 1, 122, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1}

func (s *WrappingSimulator) Write(p []byte) (int, error) {
	if bytes.Equal(p, getCapabilityAlgs) {
		// ...
	}
	return s.wrapped.Write(p)
}

[joshdrake]

Also, if you don't mind, I'll keep working on better tests for this after merging, so we can unblock work depending on these changes.

[hslatman]

I've added the test you had back in #590 and merged that into this branch. You're right we'll need that WithCapabilities method exported; didn't think about the package boundary. I've marked it experimental, and noted that it's primarily used for testing.

Some form of emulating responses from a TPM might be useful for future tests, and it would be great to have that available in plain Go, but I think it would be best in a new package, and not (partially) reliant on the C simulator (or at least separate from the current simulator code). I know Panos has looked a bit into generating Go code from the spec, so that might be a way to do it.

[hslatman]

Just saw the usage of withAK and was thinking how that could succeed, and then found that the algorithm is ignored here. I think that's fine for now, but we may want to add the capability check for AK creation too at some point. But IIRC AKs have stricter requirements, so there might be algorithms that will just fail at the TPM level.