web-dev-qa-db-ja.com

Intel SGX-リモート認証

私は現在、IntelのSGX、特にリモート認証部分について読んでいます。このトピックについて質問があります。

次のプロトコルについて考えてみましょう。

エンクレーブAおよびBはリモート認証を行います。それらのそれぞれは、非対称鍵ペア（sk_X、pk_X）を生成します。彼らは引用符を交換します：

A -> B: QUOTE{pk_A}
B -> A: QUOTE{pk_B}

引用を傍受して転送するMitM攻撃者がいるとします。攻撃者が公開鍵を読み取ることは可能ですか、それとも何らかの形で暗号化されていますか？ドキュメントに適切な情報が見つかりませんでした。

次のドキュメントを見つけました： intel-sgx-developer-guide

見積もりには次のデータが含まれています。

  • エンクレーブ内のコードとデータの測定。
  • エンクレーブの初期化時に提示されたISV証明書の公開鍵のハッシュ。
  • エンクレーブの製品IDとセキュリティバージョン番号（SVN）。
  • エンクレーブの属性（例えば、エンクレーブがデバッグ・モードで実行されているかどうか）。
  • エンクレーブによってレポート構造のデータ部分に含まれるユーザーデータ。リモート認証プロセスにバインドされた安全なチャネルを確立できるため、リモートサーバーは認証されたエンティティにシークレットをプロビジョニングできます
  • Intel EPIDグループキーによって署名された上記のデータの署名ブロック

誰もがデータを読み取ることができるように思えます。 MitM攻撃を防ぐために、エンクレーブはISV（独立ソフトウェアベンダー）の公開鍵のハッシュと、おそらく製品IDを検証する必要があります。

man-in-the-middleremote-attestationintel-sgx
2
Donut

記事 コードサンプル：Intel Software Guard Extensionsリモート認証のエンドツーエンドの例 （IntelのJohn M.による）は、リモート認証の例を説明しています。 （記事で説明されているほとんどの関数のソースコードは、 ここ にあります。）

特に、この記事では、リモート認証の見積もりの​​構造について言及しています sgx_quote_t ：

見積もりの​​構造は sgx_quote.h で定義されています：

typedef struct _quote_t
{
    uint16_t            version;        /* 0   */
    uint16_t            sign_type;      /* 2   */
    sgx_epid_group_id_t epid_group_id;  /* 4   */
    sgx_isv_svn_t       qe_svn;         /* 8   */
    sgx_isv_svn_t       pce_svn;        /* 10  */
    uint32_t            xeid;           /* 12  */
    sgx_basename_t      basename;       /* 16  */
    sgx_report_body_t   report_body;    /* 48  */
    uint32_t            signature_len;  /* 432 */
    uint8_t             signature[];    /* 436 */
} sgx_quote_t;

構造体のメンバーの1つ sgx_report_body_t （ sgx_report.h で定義）はreport_data、タイプは sgx_report_data_t 。
report_dataは、エンクレーブがそのリモート認証引用の中に含めることができる任意の情報です。これは512ビットしかないので、おそらく公開鍵のハッシュをそこに配置します（そして、公開鍵自体を見積もりと一緒に送信します）。

どちらにしても、私が正しく理解していれば、report_dataはデフォルトでは暗号化されていません。


攻撃者がエンクレーブ内で任意のコードを実行できないと想定すると、作成できないため、Diffie-Hellman鍵交換の古典的なMitM（ here で説明）を実行できないことに注意してください有効な署名付きの見積もり。

1
Oren Milman