TPM 2.0に問い合わせることなく、AIKとEKの関係を証明できますか？
公開部分である保証キー（EK）はTPMチップで直接利用できます。AIKキーを生成し、そのキーで署名できることを知っています。ハッシュはTPMによって生成される必要があります。
アイデアは、次のアーティファクトでリモート認証を実行することです。
- 裏書きキー（EK）
- AIK公開キー
- AIKからの秘密鍵で署名するためにいくつかのナンスが送信されました
つまり、いいえ。ただし、TPMにEKの使用を依頼するのが難しいという意味ではありません。見積もり（証明書の主要部分）を依頼するのと同じくらい簡単です。
まず、ちょっとしたこと：AIK（証明IDキー）はTPM 1.2（およびそれ以前）のキータイプです。 TPM 2.0には、AK（証明キー）と呼ばれる同様のキータイプがあります。これらのキーの役割は似ていますが、同じではありません。 AIKは、いくつかの（3）異なる構造にのみ署名できます。 AKはTPMによってハッシュされたすべてのものに署名しますが、TPMは引用符などのマジックナンバーで始まるデータをハッシュしません。これは、TPM 2.0がAKを使用して偽の見積もりに署名できないようにする方法です。ただし、TPMには、偽の見積もりに署名する可能性のある非AK署名キーを含めることができます。
見積もりは、署名が付いた単なるデータの塊です。クライアントがTPMなしで構成証明データを送信することを完全に信頼している場合は、TPMを使用する理由はありません。 TPMを使用する場合は、見積もりに対する署名が実際のTPMからのものであることを確認する必要があります。 AKからの署名があることは、そのハッシュ/マジックナンバーの事柄のため、見積もりを信頼するのに適していますが、署名キーが実際にはAKであることを証明する必要があります。そのためには、署名キーを実際のTPMのみが持つことができるものにバインドする方法が必要です。そのTPMの製造元によって署名されたEK証明書。
EKは署名鍵ではないため、署名を生成することはありません。 AKをEKにバインドするには、MakeCredentialとActivateCredentialの2つのプロセスでカバーされるプロセスが必要です。 MakeCredentialはTPMで実行できますが、必須ではありません。これには、問題のTPMのEK証明書と、AKの「名前」が必要です。 EK証明書が有効であることを検証した後、複雑なプロセスで名前を使用して、公開EKでチャレンジを暗号化します。次に、そのデータをTPMに送り返し、TPMにActivateCredentialを実行させます。問題がなければ、チャレンジを返して比較します。返されたチャレンジが暗号化されたパッケージ内で送信されたチャレンジと一致することを確認した場合にのみ、見積もりに署名した鍵が本物のAKであり、見積もりが本物であると信頼できます。