Offline Data Migration between Software Versions with SGX

[Nicholas_S_2]

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?

[Juan_d_Intel]

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.

[Nicholas_S_2]

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

[Simon_J_Intel · Accepted solution]

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. 

[Nicholas_S_2]

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?

[Juan_d_Intel]

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.