search

aws / aws-nitro-enclaves-image-format

This library provides the definition of the enclave image format (EIF) file used in AWS Nitro Enclaves.
Apache License 2.0
13 stars 17 forks source link

Clarification around EIF signatures using different signing certificates #36

Open gkelly opened 3 days ago

gkelly commented 3 days ago

generate_eif_signature appears to expect to eventually be able to produce PcrSignatures that cover more than just PCR0 (https://github.com/aws/aws-nitro-enclaves-image-format/blob/main/src/utils/mod.rs#L316). There's even a type for this (EifSignature, https://github.com/aws/aws-nitro-enclaves-image-format/blob/main/src/defs/mod.rs#L227, but it's currently unused). However, the serialized PcrSignature structs will each contain their own signing certificate (https://github.com/aws/aws-nitro-enclaves-image-format/blob/main/src/defs/mod.rs#L232).

This means that when a new PCR is added to the EifSignature vec, or the in-place vec that currently used (https://github.com/aws/aws-nitro-enclaves-image-format/blob/main/src/utils/mod.rs#L316) that there could potentially be a different signing certificate for each PCR. Is that intentional? So that you could maybe provide a kernel+cmdline+ramdisk0 that had one vendor signature and a signature over the ramdisk1+ sections from a different source?

I understand this is very much not a current concern, but I got curious about the mechanics while reading the source.

gkelly commented 3 days ago

The presence of multiple signing certificates does bring into question the definition of PCR8, which is currently the hash of the DER-encoding of "the" signing certificate, which works while there's only one, but would seem ill-defined if there are multiple PCR signatures (each with their own signing certificate) as suggested by EifSignature.