Skip to main content

Enclave Key (EK)

Overview​

The Enclave Key (EK) is a signing key generated within an LCP Enclave using the secp256k1 curve. The private key of the EK (EKPriv) can never be read from outside the Enclave. In this document, we refer to the public key of the EK as EKPub, and the Ethereum address derived from EKPub as EKAddr.

ELC uses this key to sign commitments, generating a signature as a commitment proof. This signature is verified by the on-chain LCP Client.

Key Generation​

The EK is generated by executing the GenerateEnclaveKey command via the App after the LCP Node starts. The EK generated by the EM (Enclave Manager) is encrypted and stored within the LCP Node using the sealing function provided by SGX. For the seed used to generate the private key within the Enclave, sgx_read_rand (internally RDRAND) is used. Additionally, the MRENCLAVE policy is used as the sealing policy. This prevents the reuse of the EK encrypted in a previous version after updating the LCP Enclave.

Remote Attestation​

Remote Attestation is a function that allows the integrity of execution within the Enclave to be proven to external parties. LCP utilizes Remote Attestation to enable the on-chain LCP Client to verify that the EK was generated by the expected Enclave.

The LCP Enclave generates a Quote that includes the EKAddr (derived from EKPub) as Report data and generates a Verifiable Quote through Remote Attestation. This Verifiable Quote makes it possible to verify that the Report data was generated by the Enclave whose MRENCLAVE matches the one included in the Quote. Note that this Remote Attestation must be performed each time a new EK is generated.

The following diagram shows the flow of generating the EK and obtaining an Attestation Verification Report (AVR. cf. https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf ) for the Quote including the EKAddr using IAS.

Each step is as follows:

  1. The App sends the GenerateEnclaveKey command to the Enclave.
  2. The Enclave generates the EK. It then encrypts it using the sealing key and generates a sealed EK.
  3. The Enclave derives the EKAddr from the EK and creates a Report to the Quoting Enclave (QE) including it as Report data.
  4. The Enclave returns the Report and the sealed EK to the App. The App stores these in the database.
  5. The App passes the Report to the Quoting Enclave (QE) and requests the creation of a Quote.
  6. The QE signs the Report using its Attestation Key, creates a Quote, and returns it to the App.

Note that the following steps are only necessary when using external Attestation Services such as IAS. In the case of DCAP (ECDSA Attestation), the Quote obtained in step 6 is considered an externally verifiable Verifiable Quote.

  1. The App sends the obtained Quote to IAS.
  2. IAS verifies the Quote and generates a signature on the Report consisting of the Quote and the Enclave verification results. It then returns an Attestation Verification Report (AVR) containing those data and the signature. The key used for the signature is certified by a key published by Intel. Therefore, the AVR can be verified by external parties, including blockchain smart contracts.

The AVR obtained by the relayer is sent to the LCP Client, where it is verified, and the EKAddr is registered on the LCP Client. Details of this process are described in RegisterEnclaveKey. The LCP Client stores the EK obtained by verifying the AVR with an expiration date based on the timestamp of the RA. If the EK referred to by the relayer expires, the above flow is performed again to register a new EK.