Capabilities of the Attestation Mechanism

[hannestschofenig]

In discussion with Ming we were wondering whether there are restrictions regarding the attestation mechanism on what it can sign. Currently, the OTrP design assumes that the secure OS running in the TEE has access to the device certificate, which was provisioned during manufacturing, and that it signs whatever data is given to it. There may, however, be restrictions in what an attestation mechanism signs, for example when it offers only a restricted API. If that's indeed the case then a message from the TEE to the TAM would have to contain two signatures, namely one for the signed attestation data and another one for the signed message.

To get an answer to this question we thought it would be useful to survey existing attestation technologies.

[dmwheel1]

For SGX, and for other Intel TEEs, the Attestation Key is generally restricted, so you cannot sign "anything".
Typically the way this works (for Intel) is you get a signed attestation that includes a 256-bit or 512-bit value. This value could be a random nonce sent from the remote verifier, or it can be a hash of another structure "attached" to the attestation. In the case of a hashed structure, the verifier then must interpret the structure. The implication is that the attestation gives you data on the claimant, and the claimant provides the additional data. If the verifier believes it can trust the claimant based on the attestation, then it should be able to make some policy decision on the additional claims.

For TEEP running in SGX, the provided attestation would be an additional structure, which would be hashed, and then this hash would be signed in an attestation which would provide details of the SGX enclave code that requested the attestation (things like enclave-signer, hash-of-enclave-code, enclave-version-number, CPU-microcode-version, etc.) The verifier (TAM in this case) would need to validate the SGX Attestation, and then interpret the attached structure.

Hope this is clear enough.

[dmwheel1]

See new Pull Request to address this issue

[dthaler]

Filed a separate issue to track impact on the OTrP spec.