On Fri, Oct 23, 2020 at 04:23:55PM +0200, Jethro Beekman wrote: > On 2020-10-23 12:17, 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 :-) > > > > This is nonsense. The whole point of sealing keys is that they don't > change every boot. If did they they'd have no value over enclave > memory. RAND means that the KEYID field from the KEYREQUEST is > included in the derivation (as noted in the source row of the table > you looked at). I just looked that the column name is RAND, the row is called "Provision key" and the cell has "Yes" in it. > -- > Jethro Beekman | Fortanix /Jarkko
