TPM 2.0参照実装に2件の脆弱性、AMDとIntelが影響

CERT/CCは2026年8月11日、TPM 2.0のリファレンス実装（参照コード）に2件の脆弱性があるとして脆弱性ノート VU#431093 を公開しました。日本では8月12日にJVNが JVNVU#96623328 として伝えています。AMDとIntelは自社のファームウェアTPMが影響を受けると表明しており、修正は各PC・サーバメーカーが配布するファームウェア更新として降りてきます。

ただし悪用には「TPMコマンドインターフェースへの特権ローカルアクセス」が必要です。リモートから単独で成立するものではないため、今夜サーバを止めて対応する種類の脆弱性ではありません。効いてくるのは、「TPMに守られているから安全」という前提を置いている仕組み（デバイス証明書、構成証明、ディスク暗号化）のほうです。

この記事でわかること

  • TPMとは何で、自社のどの機器に入っているのか（「うちは使っていない」が通用しない理由）
  • CVE-2026-6726 / CVE-2026-6727 の内容と、悪用に必要な条件
  • 「TPMの構成証明が偽造できる」ことが、ゼロトラスト設計に与える意味
  • 自社端末のTPMベンダーとファームウェア版数を確認する具体的な手順
  • TPMファームウェア更新でBitLockerの回復キーを要求されないための準備

TPMとは何者か — 買った覚えがなくても、ほぼ全台に載っている

TPM（Trusted Platform Module）とは、暗号鍵の生成・保管と、機器の状態の証明をハードウェア側で担う専用のセキュリティ部品です。鍵をOSやディスクの外側（耐タンパ領域）に閉じ込めることで、OSが乗っ取られても鍵そのものは抜かれにくくする、という考え方の土台になっています。

情シスの実務では、BitLockerによるディスク暗号化（回復キーなしで起動できるのはTPMが起動時の構成を確認して鍵を解放しているため）、Windows Hello / PIN（総当たりに強いのはTPM側で試行回数が制限されるため）、デバイス証明書・構成証明（「管理下の実機である」ことの根拠）といった場面で、意識せず使われています。TPM 2.0はWindows 11の必須要件でもあるため、Windows 11に移行した端末は原則として全台がTPMを持っています。

そして重要なのが「どこに組み込まれているか」です。TPMは独立したチップ（ディスクリートTPM）として載っている場合もありますが、現在の企業向けPCの多くはCPU側の機能として実装されたファームウェアTPM（fTPM）を使っています。Intelでは Platform Trust Technology（PTT）、AMDでは fTPM と呼ばれるものがこれにあたります。「TPMという部品を買った覚えはない」という組織でも、CPUの中で動いているわけです。今回影響ありと表明したのが、まさにそのAMDとIntelです。

何が起きたのか — 参照実装に2件の脆弱性

今回問題になったのは、個別ベンダーの製品ではなくTrusted Computing Group（TCG）が公開しているTPM 2.0の「参照実装」コードです。各社のTPMはこのコードを土台に自社製品を作るため、参照実装の欠陥は複数ベンダーに同時に波及します。

CVE番号 種別 内容 成立時に起きること
CVE-2026-6727 タイミングサイドチャネル RSA OAEP復号処理の実装に、処理時間の差から情報が漏れる欠陥 TPMが管理するRSA鍵（RSA Endorsement Key を含む）宛ての暗号文を復号されうる
CVE-2026-6726 情報漏えい 偽造したTPM鍵に対して、TPM対応の認証局（CA）から資格情報を取得できる欠陥 Attestation Key・DevID鍵・TLS認証鍵などを詐称し、不正なTPM 2.0構成証明を作れる

報告したのはIntelのセキュリティ研究者チームで、TCGの脆弱性対応チームと協調して開示されました。CERT/CCのアドバイザリにCVSSスコアの記載はなく、執筆時点でNVDの登録内容も確認できていません（NVD側が一時的に応答しない状態でした）。スコアが出そろうのを待つと判断が遅れるため、後述のとおり「取られる権限の高さ」と「影響資産の重要度」で優先度を決めるのが現実的です。

悪用にはどんな条件が必要か

CERT/CCは、悪用の成立条件を「TPMコマンドインターフェースへの特権ローカルアクセス」と明記しています。つまり、攻撃者はすでにその端末で管理者相当の権限を握っている必要があります。

これは「大した問題ではない」という意味ではありません。読み替えるとこうなります。

端末の管理者権限を取られた時点で、その端末のTPMが出す証明はもう信用できない。TPMは「管理者権限を取られた後でも鍵を守る」ために置かれているのに、その最後の砦の一部が崩れる。

なぜ「構成証明の偽造」が重い意味を持つのか

CVE-2026-6726の怖さは、鍵が漏れることそのものより「本物のTPMに守られた鍵である」という証明を詐称できる点にあります。

TPMを使ったデバイス認証は、①端末のTPMが鍵ペアを生成し秘密鍵はTPMの外に出ない → ②「この鍵は確かにTPMの中にある」とTPMが証明する → ③認証局（CA）がその証明を検証してデバイス証明書を発行する → ④以後その証明書を持つ端末を管理下の実機とみなす、という前提で成り立っています。今回の脆弱性は②と③の間を突き崩します。TPMの外にある（＝守られていない）鍵に対して、CAが「TPM保護された鍵だ」と誤認して資格情報を出してしまう可能性がある、ということです。

ゼロトラストの設計では、「誰が」に加えて「どの端末から」を信頼の判断材料に使います。その「どの端末か」の根拠としてハードウェア由来の証明を最上位に置いている組織ほど、前提の見直しが必要になります。デバイス証明書が通ったという事実だけで他の条件（ログイン挙動の異常検知、特権の分離）を免除する設計になっていないか、が確認ポイントです。仕組みの前提を整理するには公開鍵基盤（PKI）の解説記事も参考になります。

影響を受けるのはどれか

CERT/CCのベンダー一覧（2026年8月11日時点）の状況は次のとおりです。

状態 ベンダー 情シスから見た意味
影響あり（Affected） AMD、Intel 両社のfTPMを使う一般的な業務用PC・サーバが対象になりうる。実質的にWindows端末の大半が該当範囲
影響なし（Not Affected） Absolute Software、Ampere Computing、libtpms（IBM支援）、Meta 仮想環境で使われるソフトウェアTPM実装 libtpms は影響なしと表明
不明（Unknown） AWS、Google、Microsoft、Dell ほか多数 回答未受領。「不明＝影響なし」ではないため、各社の告知を継続確認する必要がある

修正はTPMベンダー側で参照実装の修正を取り込み、ファームウェア更新・OS更新・ソフトウェアパッチとして配布されます。利用者はプラットフォーム提供元（PCメーカー、マザーボードメーカー、サーバベンダー）から入手する形になります。個々の機種向け更新がいつ出るかはメーカー次第で、時間差が生じます。

自社端末のTPMを確認する手順

該当判定は、資産管理台帳を眺めるより実機で見たほうが確実です。Windows端末なら次の方法があります。

  • PowerShell（管理者権限）で Get-Tpm：ManufacturerIdTxt にベンダー識別子（Intelなら INTC、AMDなら AMD、他に IFX＝Infineon、NTC＝Nuvoton、STM＝STMicroelectronics など）、ManufacturerVersion にファームウェア版数が出ます。
  • tpm.msc：「TPM 製造元情報」で製造元名・製造元バージョン・仕様バージョンを確認できます。

ここでINTCやAMDが出れば、CPU内蔵のfTPMを使っている可能性が高く、今回の対象範囲に入ります。集計はスクリプトで全台から ManufacturerIdTxt と ManufacturerVersion を収集しておくと、後日メーカーが「この版数以降で修正」と発表したときにそのまま突き合わせできる状態になります。今のうちに取っておく価値があります。

現場目線：この手の脆弱性は「直せないまま残る」

正直なところ、ファームウェア層の脆弱性は最も放置されやすい領域です。理由ははっきりしています。

  • 資産管理ツールに出てこない：インストール済みソフトウェア一覧にBIOS/UEFIやTPMのファーム版数は載りません。台帳を見ても該当有無が分からない。
  • 脆弱性スキャナでも拾いにくい：ネットワーク越しのスキャンでは端末のTPMファーム版数までは見えません。
  • 配布経路がメーカーごとにバラバラ：OSパッチのように一括配信できず、機種ごとのBIOS更新ツールに依存します。混在環境ではその時点で手が止まります。
  • 失敗したときの怖さが違う：BIOS更新の失敗は端末の文鎮化に直結します。OSパッチと同じ気軽さでは回せません。

結果として、「重大だと分かってはいるが、次の機種更改まで実質的に手が付かない」という状態になりがちです。UEFI脆弱性とブートキットの記事でも触れたとおり、OSより下の層は「更新できる体制があるかどうか」自体が対策の中身になります。

TPMファームウェアを更新する前に：BitLockerの回復キー

実務でいちばん事故が起きるのがここです。TPMファームウェアやUEFIを更新すると、BitLockerが起動時に回復キーの入力を求めてくることがあります。TPMが計測している起動時の構成が変わるためで、Microsoftも既知の挙動として案内しています。

数百台に一斉配信した翌朝、全社から「パスワードみたいな長い数字を聞かれて起動できない」という電話が鳴る、という展開は避けたいところです。更新前に次を確認してください。

  • 回復キーが確実にエスクローされているか（Entra ID / Active Directory / MDMのいずれかに退避され、情シス側から即座に取り出せるか）。ここが担保できていない状態でファーム更新をかけないこと。
  • 更新前にBitLocker保護を一時停止する。Microsoftは Suspend-BitLocker コマンドレットを、ファームウェア更新で複数回の再起動が発生する場合は再起動回数に合わせて指定するよう案内しています。
  • まず数台のパイロットで挙動を見る。機種ごとに再起動回数も挙動も違います。

なお、TPMまわりの前提が崩れたときにディスク暗号化がどう回避されうるかは、WinREを悪用したBitLocker回避（CVE-2026-45585）の記事でも扱っています。併せて確認すると、暗号化の前提条件が見通しやすくなります。

情シスはどうすべきか

今回は「即時パッチ」で片付く話ではないため、優先度は①攻撃者に管理者権限を取られないこと ②取られた後にTPMの証明を過信しないこと ③更新できる体制を作ることの順で考えるのが妥当です。

  1. 今すぐ：全端末のTPMベンダー識別子とファームウェア版数を収集し、台帳化する（Get-Tpm）。メーカー告知が出たときに即座に突き合わせられる状態にする。
  2. 今すぐ：BitLocker回復キーのエスクロー状況を棚卸しする。ファーム更新の可否がここで決まる。
  3. 継続：利用中のPC・サーバメーカーのセキュリティ告知を追う。CERT/CCで「不明」となっているベンダーが多く、情報は今後追加される。
  4. 設計面：デバイス構成証明を単独の信頼根拠にしていないか点検する。端末が特権侵害された前提でも成立する多層の判定になっているか。
  5. 前提の強化：ローカル管理者権限の常時付与をやめる、特権アカウントを分離する。今回の脆弱性の入口条件そのものを潰す打ち手であり、費用対効果が最も高い。

組織全体の対策の優先順位付けに迷う場合は、自前でチェックリストを作り込む前にIPAの公的指針を土台にするのが早道です。中小企業の情報セキュリティ対策ガイドラインは、資産の把握と更新管理を含む体制づくりの標準的な型を示しています。あわせて、更新作業に伴う障害を想定した訓練にはセキュリティインシデント対応 机上演習教材が使えます。「回復キーが取り出せず全社が起動できない」は、演習の題材として非常に現実的です。

なお、TPM 2.0の参照実装をめぐってはCERT/CCが過去にも脆弱性ノートを出しています（メモリ破損に関する VU#782720、境界外読み取りに関する VU#282450）。今回のVU#431093は別件ですが、1つの参照コードを多数のベンダーが共有する構造そのものが同種の事象を繰り返し生む以上、次回も求められる動きは同じです。版数を把握しているか、回復キーを取り出せるか、ファームを更新できる段取りがあるか。今回この3つを整えておけば、次は情報が出た当日に動けます。

まとめ

  1. TPM 2.0の参照実装に2件の脆弱性（CVE-2026-6726 / CVE-2026-6727）が公表され、AMDとIntelが影響ありと表明した。両社のfTPMは一般的な業務用PCに広く使われており、「うちは関係ない」とは言いにくい。
  2. 悪用には特権ローカルアクセスが必要で、即時の全社停止級ではない。ただしTPMの構成証明を偽造されうるため、デバイス証明書を信頼の根拠に使っている設計は前提を見直す必要がある。
  3. 今できるのは「版数の把握」と「BitLocker回復キーのエスクロー確認」。修正は各メーカーのファームウェア更新として順次降りてくるため、それを受け取れる体制を先に整えておく。

出典

タイトルとURLをコピーしました