第2シリーズ 第5回：EKとAKは何が違うのか― Quoteを署名したTPMをどう信用するのか

ここまで、

PCR。

Event Log。

TPM2_Quote。

Nonce。

PCR Replay。

について見てきました。

Remote Attestationの仕組みは、

かなり見えてきました。

しかし、

まだ非常に重要な疑問が残っています。

TPM2_Quoteが、

正しいSignature付きで送られてきた。

Verifierが、

そのSignatureを確認した。

でも、

その署名に使われたKeyが、本当にTPMの中にあるKeyだと、どうやって分かるのでしょうか。

攻撃者がSoftware上でKey Pairを作って、

「これはTPMのAttestation Keyです」

と言ったらどうするのでしょうか。

ここで登場するのが、

EK

と、

AK

です。

Remote Attestationを理解するうえで、

非常に重要なKeyです。

まず結論

最初に、

EKとAKの役割を、

一言で整理します。

EK

「このTPMは本物なのか」を支えるKey

AK

「このTPMが、このPlatform Stateを証明しました」と署名するKey

です。

つまり、

EKは、

TPMのTrustを確立する側。

AKは、

実際のAttestationを行う側。

と考えると分かりやすいでしょう。

Microsoftも、TPM Manufacturerが作るEndorsement KeyとそのCertificateによって本物のTPMであることを確認し、日常的なAttestationではPrivacyのためにAttestation Identity Keyを利用する構成を説明しています。

EKとは何か

EKとは、

Endorsement Key

です。

TPM固有のTrustを確立するための、

非常に重要なKeyです。

MicrosoftのTPM Key Attestation資料では、

EKはTPM内部にある非対称Keyであり、

TPMごとに一意なものとして説明されています。

そして、

EK Public Keyを、

EKPub

Private側を、

EKPriv

と呼びます。

EKを「TPMの身分証」に例える

新人向けには、

EKを、

TPMの身分証明の土台

と考えると分かりやすいと思います。

例えば、

人間なら、

「私は山田太郎です」

と言うだけでは、

本人確認になりません。

そこで、

公的機関が発行した証明書を見る。

TPMでも似ています。

単に、

「私はTPMです」

と言うだけでは、

Software Emulatorかもしれない。

そこで、

EKと、

必要に応じてEK Certificateを使い、

本当に信頼できるTPMなのか

を確認します。

EK Certificateとは何か

EKには、

EK Certificate

が付属する場合があります。

EKCertです。

EK Certificateは、

EK Public Keyについて、

TPM ManufacturerなどのCredential Providerが発行する証明書です。

TCGには、

EK Credentialの内容やX.509形式を定義した、

TCG EK Credential Profile

があります。

2026年3月には、

TPM 2.0向けLevel 0 Version 2.7が公開されています。

EK Certificateが証明するもの

簡単に言えば、

EK Certificateは、

というTrust Chainを作るために使われます。

VerifierやCAは、

Certificate Chainを検証することで、

特定TPM ManufacturerなどをTrust Anchorとして、

EKを信用できます。

Microsoftも、

Manufacturer署名のEK Certificateを使うことで、

MalwareがTPMを装っているのではなく、

実際のTPMが存在することを確認できると説明しています。

すべてのTPMにEKCertがあるとは限らない

ここは注意点です。

すべてのTPMが必ずEK Certificateを持つとは限りません。

MicrosoftのTPM Key Attestation資料でも、

EKCertを持たないTPMが存在することが説明されています。

その場合、

別のTrust Model。

登録済みEK Public Key。

Enterprise管理。

Provisioning Service。

などを使って、

TPMをTrustする方法を設計することがあります。

ではEKでQuoteすればよいのでは？

ここで、

自然な疑問が出てきます。

EKがTPM固有の、

強いTrustを持っているなら、

そのEKを使って、

毎回Quoteへ署名すればいいのでは？

と思うかもしれません。

しかし、

通常はそのようには考えません。

ここで、

AKが登場します。

AKとは何か

AKとは、

Attestation Key

です。

Windows関連資料では、

AIK

Attestation Identity Key

という表現を見る場合があります。

AKは、

TPMに保護されたSigning Keyとして、

QuoteなどのAttestation Evidenceへ署名するために使います。

MicrosoftもAIKについて、

Private PortionはTPM外へ出ず、

TPM-definedな限られたSigning Operationで使用されるKeyとして説明しています。

EKとAKを身近に例える

会社員で考えてみましょう。

EKは、

社員証の発行元まで確認できる本人確認情報

に近い。

AKは、

その人が業務上使う、

社内用の電子署名Key

のようなものです。

毎回、

最も根源的なIdentity情報を外部へ見せる必要はありません。

まず、

「このAKは信頼できるTPMに属している」

ことを確認する。

その後の通常業務では、

AKを使います。

なぜEKを直接使わないのか

理由の一つが、

Privacy

です。

EKは、

TPMを強く識別できる情報です。

毎回同じEKを、

さまざまなServiceへ提示すると、

同じDeviceであることを追跡しやすくなる可能性があります。

そこで、

日常的なAttestationでは、

AKを使います。

Microsoftも、Privacy保護のため、多くのTPM ScenarioではEKそのものを直接使う代わりにAIKを利用すると説明しています。

AKは複数作れる

AKは、

EKとは違い、

用途に応じて複数作ることができます。

例えば、

Enterprise A用。

Cloud Service B用。

Management System C用。

など、

異なるAKを使う設計が可能です。

これによって、

同じEKを各Serviceへ直接公開し続けるより、

Privacyを保ちやすくなります。

しかし問題がある

Verifierからすると、

新しい疑問が出ます。

Attester：

「このAKでQuoteしました」

Verifier：

「そのAK、本当にTPMの中にあるの？」

という問題です。

Software上で、

普通のRSAやECC Key Pairを作り、

「AKです」

と言うことも理論上考えられます。

そこで、

EKとAKを結び付ける処理

が必要になります。

Credential Activationという考え方

TPM 2.0では、

このTrustを確立するために、

Credential Activation

という仕組みがあります。

代表的なCommandが、

TPM2_MakeCredential

と、

TPM2_ActivateCredential

です。

考え方を、

非常に単純化すると、

仕組みです。

まずAKを作る

TPM側では、

Attestation用のAKを生成します。

例えば、

AK Public。

AK Private。

があります。

Private側は、

TPMによって保護されます。

Outsideへそのまま取り出して使う、

という設計ではありません。

VerifierはAK Publicだけでは信用しない

Attesterから、

AK Public Keyが送られてきます。

しかし、

Verifierは、

それだけでは信用しません。

なぜなら、

そのPublic Keyが、

Softwareで作ったKeyなのか、

本当にTPM内のAKなのか、

まだ分からないからです。

EK Publicも使う

そこで、

Verifier側は、

TPMのEK Public Keyや、

それに関連するCredential情報を使います。

そして、

AKを特定する情報と、

EK Public Keyを使って、

そのTPMだけが正しく処理できる、

Credential Dataを作ります。

この処理に関係するのが、

MakeCredential

です。

Credential BlobをDeviceへ戻す

Verifier側：

EK Public

＋

AKに関する情報

↓

Credential生成

↓

Credential Blob

↓

Deviceへ送信

となります。

しかし、

そのCredentialは、

単純にSoftwareだけで取り出せるものではありません。

TPM側で、

正しいEKとAKの組み合わせを使う必要があります。

ActivateCredential

Device側では、

TPMへ、

Credential Blobを渡します。

そして、

TPM2_ActivateCredential

を実行します。

正しいEK Private。

正しいAK。

正しいCredential。

が組み合わさっていれば、

TPMはCredentialをActivateできます。

そして、

内部に入っていたSecretなどを取得できます。

VerifierへSecretを返す

TPMが取り出したSecretを、

AttesterがVerifierへ返す。

Verifier：

「私がCredentialへ入れたSecretと一致した」

となれば、

対象AKが、

期待するTPMのTrust Contextの中に存在する、

という強いEvidenceになります。

つまり、

EKのTrustを、

AKへ橋渡しできます。

全体を図にすると

概念的には、

次のようになります。

TPM

EK
＋
AK生成

↓

Verifierへ

EK Public
AK Public

↓

Verifier

EKのTrustを確認

↓

AKに対するCredentialを生成

MakeCredential

↓

Credential Blob

↓

TPMへ

↓

ActivateCredential

↓

TPMだけが取り出せるSecret

↓

Verifierへ返す

↓

Verifier

Secret一致

↓

AKをTrust

となります。

EKは「親Key」という意味ではない

ここで注意があります。

新人向け説明で、

EKを、

「AKの親Key」

と単純化すると、

誤解することがあります。

TPMには、

Hierarchy。

Parent Object。

Storage Key。

Signing Key。

など、

Key Treeの概念があります。

しかし、

Remote AttestationのTrust関係で、

EKとAKが重要だからといって、

EKが必ずAKの直接のParent Objectである

という意味ではありません。

ここは、

「Cryptographic Trustを結び付ける」

と理解したほうが安全です。

EKとAKは役割が違う

もう一度整理します。

EK

TPMそのもののTrustを確立するためのKey。

AK

Platform StateなどのAttestation Evidenceへ署名するKey。

つまり、

EK：

Who are you?

AK：

What is your state?

に近い役割分担です。

「Who」と「What」を分ける

Remote Attestationでは、

この2つを分けて考えると、

非常に分かりやすい。

まず、

Who

このEvidenceを出したTPMは、

信頼できるのか。

次に、

What

そのTPMが証明しているPlatform Stateは、

何なのか。

EKは、

主に前者。

AK / Quote / PCRは、

主に後者。

に関係します。

EKCertもAKも正しくても安全とは限らない

さらに、

重要な点があります。

EK Certificateが正しい。

AKもTPMにBindingされている。

Quote Signatureも正しい。

だから、

Deviceは安全。

とは限りません。

なぜでしょうか。

Platformが、

正しく悪意あるFirmwareを測定している可能性があるからです。

つまり、

Identity Verificationと、

Platform State Verificationは、

別です。

Remote Attestationを4段階で考える

ここまで来ると、

Remote Attestationは、

4段階で整理できます。

第1段階：TPM Trust

EK / EKCert

「このTPMを信用できるか」

第2段階：AK Trust

Credential Activationなど

「このAKは、そのTPMに結び付いているか」

第3段階：Evidence Verification

Quote / Signature / Nonce

「このEvidenceは本物でFreshか」

第4段階：Platform Verification

PCR / Event Log / Reference Value / Policy

「Platform Stateは許可できるか」

この4段階です。

この4段階は非常に重要

例えば、

AttestationがFailした。

単に、

「TPM Attestation Fail」

だけでは、

原因範囲が広すぎます。

どの段階でFailしたのか。

を見る。

EKCert Verificationなのか。

Credential Activationなのか。

Quote Signatureなのか。

Nonceなのか。

PCR Replayなのか。

Policyなのか。

これを分けるだけで、

Fault Isolationがかなり進みます。

TPM Provisioningとは何か

ここで、

Provisioningという言葉もつながってきます。

Remote Attestationを利用する前には、

例えば、

TPMを初期化。

必要なKeyを作る。

EK情報を取得。

AKを作る。

AK Credentialを取得。

Serviceへ登録。

といった準備が必要になる場合があります。

これが、

Attestation Provisioningです。

つまり、

Remote Attestationは、

Quoteを実行するだけでは始まりません。

その前に、

Trustを構築する準備

があります。

Factoryとの関係も見えてくる

PCメーカーでは、

さらに、

Factory Provisioning

も重要になります。

例えば、

EK Certificate。

Platform Certificate。

Device Identity。

Manufacturing Record。

Serial Number。

TPM情報。

これらを、

どこで生成するか。

誰が署名するか。

どうCloudへ登録するか。

という問題があります。

Remote Attestationを考えると、

工場までSecurity Architectureの一部になる可能性があります。

Supply Chain Securityへ広がる

ここから、

さらに世界が広がります。

Verifier：

「このTPMは本物です」

では、

誰が、

「本物」

だと保証しているのでしょうか。

TPM Manufacturer。

Certificate Authority。

Platform Manufacturer。

Provisioning Service。

これらをTrustします。

つまり、

Remote Attestationは、

最終的には、

Supply Chain Trust

にもつながります。

Certificate Chainが重要になる

例えば、

EK Certificate。

Issuer。

Intermediate CA。

Root CA。

というChainがあります。

Verifierは、

Certificateだけを見るのではありません。

IssuerはTrustされているか。

Certificateは期限内か。

Algorithmは安全か。

Revocationされていないか。

Policy上許可されたTPM Manufacturerか。

などを確認する必要があります。

Security Architectは「誰を信用するか」を決める

ここは、

Security Architectureの本質的な問題です。

どのRoot CAをTrustするのか。

どのTPM VendorをTrustするのか。

EKCertなしTPMを許可するのか。

Enterprise登録済みEKだけ許可するのか。

AK Credentialを誰が発行するのか。

これらは、

TPM Commandでは決まりません。

Security Policy

で決めます。

EKCertがない場合はどうするか

実際には、

EKCertが存在しない場合もあります。

その場合、

例えば、

事前登録したEK Public KeyをTrustする。

Enterprise AdministratorがDeviceを登録する。

Authenticated Enrollmentを利用する。

別のDevice Identityを使う。

といったTrust Modelがあります。

MicrosoftのTPM Key Attestationでも、

EK Certificateだけでなく、

管理者が登録したEK Public Keyなど、

異なるTrust Modelが用意されています。

Trust Levelは同じではない

どの方法でTPMをTrustしたかによって、

Assurance Levelが変わる場合があります。

例えば、

Manufacturer Chainで検証した。

Enterpriseが手作業で登録した。

User CredentialでTrustした。

これらは、

必ずしも同じ強度ではありません。

Security Architectは、

Resourceの重要度に応じて、

必要なAssurance Levelを決める必要があります。

EKとPrivacyのTrade-off

EKは、

TPMを強く識別できる。

これは、

Security上は便利です。

しかし、

Privacy上は、

注意が必要です。

同じEKを、

さまざまなServiceが共有すれば、

Deviceを横断的に追跡できる可能性がある。

そこで、

AKを複数利用したり、

Credential Serviceを介したり、

必要以上にEK Identityを露出させない設計が重要になります。

SecurityとPrivacyは別問題ではない

Security Engineerは、

「より強く識別できれば安全」

と考えがちです。

しかし、

Privacyを犠牲にしすぎると、

別のRiskが発生します。

Security Architectは、

Authenticity。

Privacy。

Manageability。

Interoperability。

を、

同時に考える必要があります。

TPM担当者のFault Isolation

Attestation Identity関連でFailした場合、

例えば、

次のように切り分けます。

EK Certificate Verification Fail

EKCert。

Certificate Chain。

Root CA。

Validity。

Provisioning。

を確認。

AK Provisioning Fail

AK Creation。

Template。

Algorithm。

Authorization。

を確認。

Credential Activation Fail

EK。

AK。

Credential Blob。

Name。

MakeCredential / ActivateCredential。

を確認。

Quote Signature Fail

AK。

Signature Algorithm。

Attestation Data。

Public Key。

を確認。

Quote成功・Policy Fail

PCR。

Event Log。

Reference Value。

Policy。

を確認。

このように、

層ごとに分けます。

「TPMが壊れている」とは限らない

例えば、

Credential ActivationがFailした。

しかし、

TPM Command自体は正常。

Verifierが、

違うAK情報を使ってCredentialを作っていた。

という可能性もあります。

あるいは、

EK Certificate Chainの設定が、

Server側で間違っていた。

可能性もあります。

Attestation Systemでは、

TPM。

Client Software。

Network。

CA。

Verifier。

Policy Server。

が関係します。

そのため、

Fault Isolationが非常に重要になります。

EKとAKを理解するとProvisioningが見える

TPM担当者にとって、

Provisioningは、

「何かWindowsが勝手にやっている処理」

に見えることがあります。

しかし、

EK。

AK。

Credential Activation。

Certificate。

を理解すると、

Provisioningの意味が見えてきます。

要するに、

このTPMと、このAttestation Keyを、Remote Serviceが信用できる状態へ持っていく

処理なのです。

TPMはDevice Identityの基盤にもなる

ここまで来ると、

TPMは、

BitLocker用Device。

PCRを持つDevice。

というだけではありません。

Hardware-backed Device Identity

の基盤にもなります。

そこから、

Device Certificate。

Enterprise Authentication。

Zero Trust。

Remote Attestation。

Cloud Security。

へ広がります。

TPM担当者からDevice Trustへ

TPM担当として、

EK Certificateを評価していた。

AKを確認していた。

Provisioning Testをしていた。

これらは、

一見個別の試験に見えるかもしれません。

しかし、

Architectureの視点では、

すべて、

Device Trustをどう構築するか

という問題につながっています。

Remote Attestation全体をもう一度整理する

ここまでの第2シリーズを、

一枚につなげます。

Device Boot

↓

Firmwareなどを測定

↓

Event Log

↓

PCR Extend

↓

AK Provisioning

↓

EK / EKCertでTPM Trustを確立

↓

AKをTPMへBinding

↓

VerifierからNonce

↓

TPM2_Quote

↓

AKで署名

↓

Quote + Event Log

↓

Verifier

EK / AK Trust確認

↓

Signature確認

↓

Nonce確認

↓

PCR Replay

↓

Reference Value比較

↓

Policy評価

↓

Attestation Result

↓

Access Decision

となります。

ここまで来ると、

Remote Attestationが、

かなり完全なSecurity Systemとして見えてきます。

今回のまとめ

今回覚えてほしいのは、

次の8点です。

1．EKはTPMそのもののTrustを支えるKey

2．AKはAttestation Evidenceを署名するKey

3．通常のQuoteではAKを使う

4．EK CertificateによってTPM Authenticityを確認できる場合がある

5．EKのTrustをAKへ結び付ける仕組みが必要

6．MakeCredential / ActivateCredentialがそのために利用される

7．EKはIdentity、AKはAttestationという役割分担で考えると分かりやすい

8．最終的にはCertificate ChainやSupply Chain Trustまで関係する

一言で言えば、

EK = TPMを信用するための根

AK = そのTPMが証明するための声

です。

次回

次回は、

「Verifierとは何をしているServerなのか」

を取り上げます。

Remote Attestationでは、

TPMばかりに注目しがちです。

しかし、

実は、

Verifier側も非常に重要です。

Verifierは、

QuoteのSignatureを確認するだけではありません。

EK Certificate。

AK。

Nonce。

PCR。

Event Log。

Reference Value。

Policy。

を組み合わせ、

最終的に、

このDeviceを信用してよいか

を判断します。

次回は、

Attestation Serverの中身を、

新人エンジニアでも理解できるように、

一つずつ分解します。