On 2/1/22 2:39 PM, Peter Gonda wrote: > On Fri, Jan 28, 2022 at 10:19 AM Brijesh Singh <brijesh.singh@xxxxxxx> wrote: >> The SNP_GET_DERIVED_KEY ioctl interface can be used by the SNP guest to >> ask the firmware to provide a key derived from a root key. The derived >> key may be used by the guest for any purposes it chooses, such as a >> sealing key or communicating with the external entities. >> >> See SEV-SNP firmware spec for more information. >> >> Reviewed-by: Liam Merwick <liam.merwick@xxxxxxxxxx> >> Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx> > Reviewed-by: Peter Gonda <pgonda@xxxxxxxxxx> > >> --- >> Documentation/virt/coco/sevguest.rst | 17 ++++++++++ >> drivers/virt/coco/sevguest/sevguest.c | 45 +++++++++++++++++++++++++++ >> include/uapi/linux/sev-guest.h | 17 ++++++++++ >> 3 files changed, 79 insertions(+) >> >> diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst >> index 47ef3b0821d5..aafc9bce9aef 100644 >> --- a/Documentation/virt/coco/sevguest.rst >> +++ b/Documentation/virt/coco/sevguest.rst >> @@ -72,6 +72,23 @@ On success, the snp_report_resp.data will contains the report. The report >> contain the format described in the SEV-SNP specification. See the SEV-SNP >> specification for further details. >> >> +2.2 SNP_GET_DERIVED_KEY >> +----------------------- >> +:Technology: sev-snp >> +:Type: guest ioctl >> +:Parameters (in): struct snp_derived_key_req >> +:Returns (out): struct snp_derived_key_resp on success, -negative on error >> + >> +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. > derived from ... > >> +The derived key can be used by the guest for any purpose, such as sealing keys >> +or communicating with external entities. > Question: How would this be used to communicate with external > entities? Reading Section 7.2 it seems like we could pick the VCEK and > have no guest specific inputs and we'd get the same derived key as we > would on another guest on the same platform with, is that correct? That could work. This method is using the idea that the guests would derive identical keys removing the need for a complex key establishment protocol. However, it's probably better to approach this slightly differently. The derived key can be used to produce a persistent guest identity key that can be recovered across instances. That key can sign an key establishment exchange (e.g. an ephemeral ECDH key) for establishing trusted channels with remote parties. Further, that identity key could be signed by a centralized CA. A way to approach that could be placing the fingerprint of the identity key into the REPORT_DATA parameter of the attestation request message. The attestation report will come back signed by the security processor and will contain the fingerprint. A CSR to the CA can be accompanied by the attestation report to prove the key came from the guest described in the attestation report. If the guest does not require keys or secrets to be persisted, or if the guest has other means for persisting keys or secrets, the derivation messages are not necessary. It's an optional security primitive for guests to use. thanks
