ABI v2: CoVE (AP-TEE) Sealing Interface

[sameo]

We may want to eventually extend the attestation TG-ABI to support data sealing.

The generic use-case for sealing is basically for a TVM to seal a piece of data that can be migrated to and unsealed by another TVM, synchronously or not. For example a TVM guest could seal a secret key or piece of data to an AP-TEE sealing key, store it in an untrusted storage and then later fetch it back to unseal it.

In order to unseal it, a TVM willing to use a previously sealed data blob must be able to generate the same sealing key that the blob was originally sealed with. As sealing keys are derived from CDIs, we must clearly define how those sealing CDI are composed.

We want to define to which security attributes a sealed piece of data would be bound to, and guarantee that a TVM running with the same (or stronger) attributes would be able to generate sealing keys that could unseal it. The sealing CDI composition, from which sealing keys are derived, provides that guarantee.

Moreover, we want sealed data to be protected against software and firmware rollbacks: For the same TVM TCB, current and future software versions should be able to unseal but older ones must not be able to do so. This anti rollback unsealing attribute can be provided through versioned sealing keys.

Sealing CDI

Sealing keys derive from the sealing CDI, which should be generated by the TSM as follows:

Sealing_CDI_N = KDF(N, Sealing_CDI_N-1, H(SealingInputValues), "SealingCDI")

Where SealingInputValues are:

• All TVM static measurements
• All TVM dynamic measurements
• Platform state
• Platform manufacturer ID

With those input values, two same TVMs (i.e. running with the same measurements), running on identical platforms operating in the same state should generate the same sealing CDI, regardless of platform software or firmware updates.

Versioned Sealing Keys

Not binding the sealing CDI to software or firmware components allows for sealed data to be unsealed by a TVM running on an older, potentially vulnerable platform TCB. To prevent that we want sealing keys to be versioned, i.e. to be derived first from a sealing CDI and then from a set of software and firmware versions.

References

OpenDice Versioned Sealing Keys

[sameo]

cc @rsahita

[rsahita]

queued for v2