Messages in this thread | | | From | Thomas Fossati <> | Date | Wed, 27 Sep 2023 21:05:39 +0200 | Subject | Re: [PATCH v4 2/6] configfs-tsm: Introduce a shared ABI for attestation reports |
| |
Hi Peter,
On Wed, 27 Sept 2023 at 16:38, Peter Gonda <pgonda@google.com> wrote: > > On Wed, Sep 27, 2023 at 2:25 AM Thomas Fossati > <thomas.fossati@linaro.org> wrote: > > > > On Wed, 27 Sept 2023 at 10:21, Dan Williams <dan.j.williams@intel.com> wrote: > > > It can be expanded when/if those platforms expand the > > > size of the supported user data, or another configfs-tsm backend arrives > > > that needs that capability. > > > > Makes sense, thanks. > > I'm not familiar with the rats eat spec but I would assume the > protocol would acquire more than just the nonce in the inblob. > Probably some combination of claims, nonce, and information about a > public key?
Looking at existing EAT-based (or EAT-like) serialisations:
Arm CCA has a single, 64 bytes challenge (see §A7 of “Realm Management Monitor (RMM) Specification” [1].)
CoVE too, see [2].
Nitro instead is doing something different: GetAttestationDoc() has optional user-provided public key, custom user data, and a custom nonce passed in as separate input arguments [3].
So, what @inblob's structure looks like really is a choice of the attester's vendor.
> Does the specification allow for the data needing to be > signed by the TSM to be hashed first?
EAT per se is mostly agnostic, it has a flexible and extensible type system, which can adapt to most attester “shapes”.
Hope this answers your questions.
cheers, t
[1] https://developer.arm.com/documentation/den0137/latest [2] https://github.com/riscv-non-isa/riscv-ap-tee/blob/main/specification/attestation.adoc#tvm-challenge-claim [3] https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/4b851f3006c6fa98f23dcffb2cba03b39de9b8af/nsm-lib/src/lib.rs#L218
| |