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?
