Enrolled assets need authentication

[nicowilliams]

We don't authenticate the enrolled assets returned by the attestation server.

This means that an attacker who knows an enrolled device's TPM's EKpub can substitute any assets they like.

We could authenticate the attestation server by using HTTPS, but we don't necessarily have trust anchors at that time. Also, we'd rather authenticate the enrollment server's production of assets.

My best current design is to have the enrollment server sign each asset it produces with a private key, then add to the enrolled device's entry those signatures and the public key or certificate (and chain) for the private key. This does not stop an attacker with access to the enrollment server from deleting items unless the enrollment server also produces and signs a manifest. The client side, probably in sbin/tpm2-attest unseal would validate all the signatures, but it would need a trust anchor...

So how do we get a trust anchor on the client? I see two options:

• learn one TOFU-style (trust on first use), where "learn" means "write a hash of it to an ordinary NV index"
• learn one from booting from trusted media (e.g., USB stick, not PXE)

Key rotation can be done by adding the anchor(s) to the enrolled assets, signing each next anchor with the previous one.

[osresearch]

If UEFI SecureBoot is enabled and the Platform Key updated, the system will only boot (via local disk or PXE) a PK signed kernel and initrd. The initrd could contain the root cert for the enrollment server, which would allow the client to validate the reply from the attestation server. The attestation server would only release the enrolled data to the client if the PCR's match the correct PK, so an adversary who can change the PK can't get the secrets delivered to an insecure system.

However, under the usual threat model of a fake attestation server delivering fake enrolled data would not allow access to any real enrolled secrets, so it was not considered to be a risk since the worst case is that they would deliver a key that would not unlock the disk and the system would not be able to continue booting. Is there a different risk that needs to be taken into account?

[nicowilliams]

See PR #140.