lkml.org 
[lkml]   [2020]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION
From
Date
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).

--
Jethro Beekman | Fortanix

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2020-10-23 16:24    [W:0.225 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site