On Sat, Oct 24, 2020 at 4:34 AM Jarkko Sakkinen <kernel.org@xxxxxxxxxx> wrote: > > On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote: > > On 10/23/20 3:17 AM, Jarkko Sakkinen wrote: > > > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote: > > >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote: > > >>> + * Failure to explicitly request access to a restricted attribute will cause > > >>> + * sgx_ioc_enclave_init() to fail. Currently, the only restricted attribute > > >>> + * is access to the PROVISION_KEY. > > >> Could we also justify why access is restricted, please? Maybe: > > >> > > >> Access is restricted because PROVISION_KEY is burned uniquely > > >> into each each processor, making it a perfect unique identifier > > >> with privacy and fingerprinting implications. > > >> > > >> Are there any other reasons for doing it this way? > > > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and > > > PROVISION_SEALING_KEY also have random salt added, i.e. they change > > > every boot cycle. > > > > > > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume > > > 3D :-) > > > > Does that mean there are no privacy implications from access to the > > provisioning keys? If that's true, why do we need a separate permission > > framework for creating provisioning enclaves? > > As I've understood it, the key material for those keys is not even > required in the current SGX architecture, it was used in the legacy EPID > scheme, but the attribute itself is useful. > > Let's assume that we have some sort of quoting enclave Q, which guards a > public key pair, which signs quotes of other enclaves. Let's assume we > have an attestation server A, which will enable some capabilities [*], > if it receives a quote signed with that public key pair. > > 1. E gets the report key with EGETKEY. > 2. E constructs REPORTDATA (37.16) and TARGETINFO (37.17) structures. > The former describes the enclaves contents and attributes and latter > the target, i.e. Q in this artitificial example. > 3. E calls EREPORT to generate a structure called REPORT MAC'd with the > *targets* report key. It knows, which key to usue from REPORTDATA. > 4. The runtime will then pass this to Q. > 5. Q will check if ATTRIBUTE.PROVISION_KEY is set. If it is, Q will > know that the enclave is allowed to get attested. Then it will > sign the report with the guarded public key pair and send it to > the attestation server. I think you have this a little bit off. AIUI E won't have ATTRIBUTE.PROVISION_KEY set -- Q will. Q uses the provisioning key to convince an Intel server that it's running on a genuine Intel CPU, and the Intel server will return a signed certificate that Q can chain off of to generate attestations for E. Dave, I would rephrase what you're saying a bit. The PROVISION_KEY attribute allows enclaves to access keys that are unique to a processor and unchangeable. Unlike other SGX keys, these keys are not affected by OWNER_EPOCH changes and therefore cannot be reset. --Andy
