Provable boots

[osresearch]

For some applications it would be useful to cryptographically prove that an attested server has booted in a trusted state. Ideally these results would be published into a transparency log, which would allow auditing of which machines booted when and in which state.

But wait, you say, isn't that what attestation does? Except that there is nothing in the protocol for an outside observer to tie the quote to the EK -- the ephemeral AK signs it, and there is no proof of possession after the attestation server delivers the makecredential blob to the client. The client doesn't reveal the result of the call to activatecredential, which is the only thing that ties the AK and quote to the EK.

The encrypted assets delivered in the attestation could contain a host key and cert, which could be used as proof-of-posession after activatecredential delivers the session key. Although that doesn't tie this boot to the quote, only a boot. The attestation server could include an AK cert, which the client could then publish, but that shifts the trust to the attestation server.

This would be easier if the EK could sign things...

[osresearch]

The attestation server could generate a challenge and publish EK + AK + quote + hash(challenge) to the log. After activate credential, the client could sign challenge with the AK and publish this result. An auditor could pair these two entries to verify that activatecredential(EK,AK) succeeded to find the challenge, although an attestation server could collude with the client to fake this step.

It's worse than that -- anyone can fake this on their own by creating a fake AK and publishing fake entries to the transparency log for any EK.

[osresearch]

Too bad there isn't a way to get the decrypted seed from tpm2_import, since it uses the EK to decrypt the seed, which is the same as signing the value if we used the hash of the AK as seed.

[nicowilliams]

Well, what you'd do is publish a signature of the "message" (EKpub + AKpub + quote + challenge), or maybe just challenge on the attestation server side, and then on the attestation client side you'd publish the "message". If the two items are found, then the server did attest successfully.

To make this more useful we need a timestamp as well.

So I'd make it:

• attestation server logs timestamp, EKpub, Sign(challenge || timestamp || EKpub);
• attestation client logs timestamp, EKpub, challenge (all three the same as the attestation server, naturally);
• auditor looks for matching timestamp, EKpub entries then validates that the signature from the attestation server is a valid signature of challenge || timestamp || EKpub from the attestation client's log entry.

[nicowilliams]

although an attestation server could collude with the client to fake this step.

The threat model can't include all entities being compromised! :)

[nicowilliams]

This seems very much related to #141. In fact, I believe they are duplicates.

[osresearch]

Timestamps are useful, although there are always the questions of "how to set the time?" and "what is time?".

The problem with the attestation server generated challenge is that it can then fake the data for the client log entry. The client does not need to be involved, so a single compromise is all that is required.

[nicowilliams]

Sure, but recall that the client can get credentials from the enrollment server, so the client can also sign its entry with a key that is not known to the attestation server. (Essentially we can have a long-term AK.)

[nicowilliams]

Regarding time... we need time mainly to make it easier to locate the entries, but for real security we need to make sure that TPM resetCounts (which are in the quotes) don't go down. So time needn't be particularly accurate.