メインコンテンツまでスキップ

Enclave Key (EK)

Overview​

Enclave Key(EK)はLCP Enclave内でsecp256k1 curveを用いて生成される署名鍵である。EKの秘密鍵(EKPriv)は決してEnclave外で読み取ることはできない。なお、この文書ではEKの秘密鍵をEKもしくはEKPriv、公開鍵をEKPubと呼び、EKPubからEthereumのaddressに派生させたものをEKAddrと呼ぶ。

ELCは、この鍵を用いてcommitmentに対してsignを行うことでcommitment proofとしてsignatureを生成する。このsignatureは、on-chainのLCP Clientにより検証される。

Key generation​

EKの生成は、LCP Nodeの起動後にAppを介したGenerateEnclaveKey commandの実行により行われる。EMにより生成されたEKはLCP Node内でSGXが提供するSealing機能を用いて暗号化した上で保存される。なお、Enclave内での秘密鍵の生成のためのシードには、sgx_read_rand(内部ではRDRAND)を用いる。また、Sealing Policyとしては、MRENCLAVE policyを用いる。これにより、LCP Enclaveの更新後に以前のバージョンで暗号化されたEKを再利用することを防ぐ。

Remote Attestation​

Remote Attestationは、Enclave内の実行の完全性を外部のpartyに証明可能にするための機能である。LCPでは、chain上のLCP Clientが期待されるEnclaveで生成されたEKであることを検証可能にするためにRemote Attestationを利用する。

LCP EnclaveはEKPubから派生したEKAddrをreport dataとして含むQuoteを生成し、Remote AttestationによりVerifiable Quoteを生成する。このVerifiable QuoteはQuoteに含まれるMRENCLAVEと一致するenclaveが生成したreport dataであることを検証可能にする。なお、このRemote Attestationの実行は、新しいEKの生成ごとに行う必要がある。

次の図は、EKを生成し、IASを利用してEKAddrを含むQuoteに対するAttestation Verification Report(AVR. cf. https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf )を得るフローである。

各ステップは次のようになる

  1. AppはGenerateEnclaveKey commandをEnclaveに送信する。
  2. EnclaveはEKを生成し、Sealing Keyを用いて暗号化し、Sealed EKを生成する。
  3. EnclaveはEKからEKAddrを生成し、Report Dataとして含めてQuoting Enclave(QE)へのReportを作成する。
  4. EnclaveはAppにReportとシーリングされたEKを返す。AppはこれらをDBに保存する。
  5. Appは、Quoting Enclave(QE)にReportを渡してQuoteの作成を要求する。
  6. QEは、Attestation Keyを使ってReportに署名を行い、Quoteを作成し、Appに返す。

以下のステップは、IASをはじめとする外部のAttestation Serviceを利用する場合のみ必要なことに注意。DCAP(ECDSA Attestation)の場合は、6で得られたQuoteを外部検証可能なVerifiable Quoteとする。

  1. Appは得られたQuoteをIASに送信する。
  2. IASは、Quoteの検証を行い、QuoteとEnclaveの検証結果で構成されるレポートに対して署名を生成する。そして、それらのデータと署名を含んだAttestation Verification Report(AVR)を返す。署名に用いられる鍵はIntelが公開する鍵によりcertifyされている。そのため、AVRはブロックチェーンのスマートコントラクトをはじめとした外部のpartyにより検証可能である。

Relayerによりこの得られたAVRはLCP Clientに送信され、検証された上でEKAddrをLCP Client上に登録する。このプロセスの詳細はRegisterEnclaveKeyで述べる。なお、LCP Clientは、AVRを検証して得られたEKをRAのtimestampを基準に有効期限をつけて保存する。Relayerが参照するEKの有効期限が切れた場合は、再度上記フローを行い、新しいEKを登録する。