topic I think your understanding is in Intel® Software Guard Extensions (Intel® SGX)

Offline Data Migration between Software Versions with SGX

Nicholas_S_2 — Wed, 23 Mar 2016 05:17:31 GMT

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?

I think your understanding is

Juan_d_Intel — Fri, 25 Mar 2016 18:37:59 GMT

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.

This was the white paper.

Nicholas_S_2 — Fri, 25 Mar 2016 18:47:51 GMT

This was the white paper.

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

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

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).

Signature Padding is included

Simon_J_Intel — Wed, 30 Mar 2016 00:19:00 GMT

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.

I see; is there a way to get

Nicholas_S_2 — Tue, 12 Apr 2016 02:14:31 GMT

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?

If you're working with the

Juan_d_Intel — Wed, 13 Apr 2016 13:21:13 GMT

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.