osresearch
commented
2 years ago 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
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
EKpubcan 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 unsealwould 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:
Key rotation can be done by adding the anchor(s) to the enrolled assets, signing each next anchor with the previous one.