Signature Verification for Secret Migration

[yoon__hyundo]

I was reading SGX Explained document. At the part where explains SGX Versioning Support, I am confused with the secret migration process.

For secret migration, is the signature in the SIGSTRUCT only used for enclave initialization? is there any signature verification used during secret migration process? I am considering scenario for local environment.

[JesusG_Intel]

Hello Hyundo,

It depends on the policy you choose for key derivation. Take a look at page 351 of the Developer Reference for Linux. You can select the contents of the MRSIGNER register to be used as an input for key requests. The CPU stores the contents of the enclave measurement in the MRSIGNER register during enclave initialization.

For more information on the Local Attestation process, see Intel_SGX_Developer_Guide.pdf, page 19 and Intel Software Guard Extensions Developer Reference for Linux, page 92. The Intel SGX SDK provides a LocalAttestation sample for your reference.

Regards,

Jesus

[Dr__Greg]

Good morning, I hope the week is going well for everyone.

I believe the secret migration that Hyundo is talking about involves the ability of an enclave to generate a symmetric sealing key that is identical to one that was generated by an antecedent enclave that shares the same identity characteristics.  The process doesn't involve local attestation, it is instead a function of the key derivation process that is conducted via invocation of the ENCLU[EGETKEY] processor instruction.

The process in question is described in section 5.7 of the Costan and Devadas paper, 'SGX Explained' that Hundo references.  The treatment of the process, while complete, is arguably confusing in its presentation.  Hopefully the following will help assist with an understanding of the principles involved.

If we make a simplification of ignoring Key Separation and Sharing (KSS) the identity of an enclave is defined by the following three parameters:

• Identity modulus signature (MRSIGNER).
• ISV product ID.
• ISV security version.

Key generation can be based on the enclave measurement (MRENCLAVE) value, but keys of this type are generally best used as ephemeral keys by a specific enclave.  The key migration process is only available for sealing keys that are generated using an MRSIGNER policy.

The following structure is submitted to the ENCLU[EGETKEY] instruction to configure the key derivation process:

struct Keyrequest {
        uint16_t keyname;
        uint16_t keypolicy;
        uint16_t isvsvn;
        uint8_t reserved1[2]l
        uint8_t cpusvn[16];
        struct {
                uint64_t flags;
                uint64_t xfrm;
        } attributes;
        uint8_t keyid[32];
        uint32_t miscselect;
        uint16_t config_svn;
        uint8_t reserved2[434];
}

Standard practice is to pre-pend this structure to the binary blob of sealed/encrypted data so that the exact data elements used to generate the sealing key is used to generate the key used to decrypt the blob.  Of particular importance is the 32 byte key identifier that is typically a randomly generated value.

The key derivation policy uses a straight forward rule.  An enclave can request key derivation using a security version value (isvsvn) value less then the current isvsvn value of the executing enclave but not vice-versa.  This policy allows an enclave to decrypt a blob of sealed data and then re-encypt the blob with a key derived from the current identity characteristics of the enclave.  This allows data to be 'migrated' from one sealing key to another sealing key.

When working with sealed data, it is the obligation of the code implementing the decryption of the data to compare the stored version of the key request structure elements to the characteristics of the executing enclave to determine whether or not the data should be re-sealed with a key derived from the current identity characteristics of the executing enclave.  One this operation is carried out the data can only be referenced by the current enclave or a subsequent version of the enclave.

An example of this approach can be found in the Intel Quoting Enclave (QE) that is used to generate and sign an enclave attestation report with the EPID group key that has been provisioned to the platform.  Review the verify_blob_internal() function in the psw/ae/qe/quoting_enclave.cpp file in the Intel SGX SDK.  The QE returns a flag variable from the verify_blob() ECALL function advising the runtime software as to whether or not the EPID 'blob' should be re-saved.  This flag is set when the QE determines that the EPID has been encrypted with a previous version of the quoting enclave.

The rationale behind all of this is the notion that the security version of an enclave should be updated whenever a security vulnerability has been addressed in the enclave source code.  Upgrading the security version of the enclave is used as an indication trigger that any keys that have been derived with the previous version of the enclave should be re-generated with new derivation parameters.  This results in an architecture where any security vulnerabilities that could be used to attack the confidentiality guarantees of an enclave can be remedied by re-encrypting the data with a key that can only be generated by an enclave that does not have the vulnerability.

A prime example of that is, once again, the QE that has had its security version updated a number of times secondary to updates to the codebase to address speculative execution vulnerabilities.

An astute observer will note that the key derivation request structure also contains the CPU security version.  While Intel does not document the layout of this field it is well understood to contain a number of variables that have a heirarchical relationship with respect to previous firmware/microcode levels.  A reseal event should also be triggered if the security version of the executing enclave is different then that of the value used to generate the previous sealing key.

Hopefully all of this provides useful background information on this issue.

Yes, we have authored an independent implementation of all of this.... :-)

Dr. Greg