Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
81 Views

Offline Data Migration between Software Versions with SGX

Jump to solution

I'm looking at the white paper from 2013 that describes moving data between enclave versions using a SEAL_KEY based on the MRSIGNER and ISVSVN values; however, looking at the algorithm for key derivation used by EGETKEY, there is (among other values) a value called padding in the key dependencies.

This value seems to be determined by the signature of the SIGSTRUCT, which itself is affected by the ENCLAVEHASH and ISVSVN values; this seems to suggest that even if I request that the SEAL_KEY be derived solely from the signing key, it will be indirectly affected by the current ENCLAVEHASH and ISVSVN, which defeats the point of trying to get a key from later versions of an enclave.

Am I missing something in the documentation?

0 Kudos

Accepted Solutions
Highlighted
Employee
81 Views

Signature Padding is included as an additional defense against padding attacks on the SIGSTRUCT signature. The signature padding being included in SGX keys results in the key being bound to a correctly composed signature over the enclave’s SIGSTRUCT and not key that signed the contents of SIGSTRUCT [MRSIGNER] or ISVSVN. 

View solution in original post

0 Kudos
5 Replies
Highlighted
Employee
81 Views

I think your understanding is correct. Could you send a link to the white paper from 2013? I'd like to have a look to understand the meaning of this value called padding.

On the other hand, I don't see any reference to a padding in Table 2-23 Layout of KEYREQUEST Data Structure and Table 5-43 Key Derivation in the Programming Reference.

0 Kudos
Highlighted
Beginner
81 Views

This was the white paper.

https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealin...

If you're looking at the SGX reference, it's mentioned in the key dependencies section of the EGETKEY pseudocode.

Relevant pseudocode section

 

If you look at Table 2-2 in the reference, it mentions that the padding in the SECS is derived from the signature (presumably from the SIGSTRUCT).

0 Kudos
Highlighted
Employee
82 Views

Signature Padding is included as an additional defense against padding attacks on the SIGSTRUCT signature. The signature padding being included in SGX keys results in the key being bound to a correctly composed signature over the enclave’s SIGSTRUCT and not key that signed the contents of SIGSTRUCT [MRSIGNER] or ISVSVN. 

View solution in original post

0 Kudos
Highlighted
Beginner
81 Views

I see; is there a way to get the effect described in the white paper, where you can use the extension to compute a key used by a previous version of the enclave?

0 Kudos
Highlighted
Employee
81 Views

If you're working with the SGX SDK, you can try calling sgx_get_key, which is a wrapper to the EGETKEY instruction, and provide the enclave's previous ISV SVN value you want in the sgx_key_request_t parameter.

0 Kudos