ベルリン工科大学(TU Berlin)のSecTらの研究チームが、マザーボード上の独立チップ型TPM(dTPM)を「PC全体を再起動せずにリセットする」手口で起動時の測定値を偽装し、BitLockerのディスク暗号鍵を取り出す攻撃を実機2台で再現しました。物理アクセス10分未満で、暗号化されたWindowsボリュームを読み書き可能な状態まで復号しています。
影響するのは、BitLockerを「TPMのみ(起動時のPIN入力なし)」で運用している組織です。これはWindows 11の既定構成であり、多くの企業がそのまま使っています。逆に、TPM+PINなどの追加認証要素がある構成は、この攻撃では突破されません。緊急パッチの話ではなく、盗難・紛失リスクの評価をやり直すべき話です。
この記事でわかること
- dTPM(独立チップ型)とfTPM(CPU内蔵型)の違いと、自社端末がどちらかを確認する方法
- TPMをリセットして測定値(PCR)を作り直す攻撃の流れ
- バス暗号化やBIOSパスワードでは防げない理由
- 影響を受ける構成/受けない構成の切り分けと、情シスが取れる現実的な対応
そもそもTPMとは何者で、どこに入っているのか
TPMとは、暗号鍵を安全に保管し、起動時に読み込まれたファームウェアやブートローダーの構成を「測定」して記録する、専用のセキュリティ機能です。BitLockerやデバイス暗号化の鍵の封印、Windows Hello のPIN保護、デバイス健全性証明などに使われます。Windows 11 は TPM 2.0 を既定で要求するため、「TPMなんて買った覚えがない」と思っていても、社内のWindows 11機には必ず載っています。
そして最も重要なのが「どこに、どういう形で組み込まれているか」です。Microsoftは TPM 2.0 の実装形態を3種類に整理しています。
| 実装形態 | どこにあるか | 代表例 |
|---|---|---|
| 独立チップ(dTPM) | マザーボード上の別チップ。CPUとはLPC/SPIバスで通信 | Infineon、STマイクロ、Nuvoton等のセキュリティチップ(実験機は Infineon SLB9670) |
| 統合TPM | 他の部品と同一パッケージ内に、論理的には分離された専用ハードウェアとして同梱 | チップセット内蔵型 |
| ファームウェアTPM(fTPM) | CPU/SoCの信頼実行環境上でファームウェアとして動作 | Intel PTT、AMD fTPM |
Microsoftは「どの実装方式が良いかについて立場を取らない」と明記しています。つまり同じ「TPM 2.0対応」でも中身は別物で、今回の攻撃が刺さるかどうかは実装形態で変わります。ところが資産管理台帳に「この端末はdTPMかfTPMか」まで書いている組織は、まずありません。
自社端末がdTPMかfTPMかを確認するには?
答えは「TPMの製造元IDを見る」です。tpm.msc の「TPM 製造元情報」、またはPowerShellで確認できます。
Get-Tpm
Get-CimInstance -Namespace root\cimv2\security\microsofttpm -ClassName Win32_Tpm |
Select-Object ManufacturerIdTxt, ManufacturerVersion
製造元IDがCPUベンダー(INTC=Intel、AMD)ならfTPMや統合型、IFX(Infineon)、STM(STマイクロ)、NTC(Nuvoton)などのセキュリティチップベンダーなら独立チップの可能性が高い、という見方が実務上は使えます。IDと企業の対応はTCGの Vendor ID Registry で公開されています。ただし目安にすぎないので、確実な判定は端末メーカーの仕様書やOEMへの確認で行ってください。
何が示されたのか:TPMをリセットして測定値を作り直す
Measured Boot は、起動の各段階で読み込んだコードのハッシュをTPMのPCR(Platform Configuration Register)に「追記」していく仕組みです。PCRはハッシュチェーンなので値を巻き戻せず、リセットはプラットフォーム全体のリセットと同時にしか起きないという前提の上に成り立っています。BitLockerの「TPMのみ」保護では、PCR 7(セキュアブートの構成と状態)とPCR 11 が鍵の封印条件です。
研究チームが壊したのは、この前提です。dTPMは外付けチップなので、電源線やリセット線をTPMだけ操作できてしまいます。
攻撃の流れ
- USBメモリの攻撃者制御Linux(Fedoraライブ環境)で起動し、OSの干渉を避けるためTPMドライバを一時的に切り離す
- dTPMだけをリセットする。ノートPC(Lenovo ThinkPad T480)では、公開回路図からM.2コネクタの PERST# ピンがオンボードdTPMのリセット線と同じレールにつながっていることを特定し、一瞬グラウンドに落とした。デスクトップ(ASRock B850 Pro+SPIピンヘッダ接続のTPMモジュール)ではVCC供給を抜き差しした。いずれも Startup(CLEAR) 状態を強制し、PCRが全ゼロになる
- ドライバを戻し、Linux起動時に取得したTCGイベントログを再生してPCRを積み直す。署名検証に使う証明書がWindowsとLinuxで違うためPCR 7 だけは一致しないが、Microsoftの Windows Production CA 2011 証明書から該当イベントを自作し、正規のWindows起動時と同じダイジェストを再現した
- 封印済みオブジェクトをボリュームヘッダから取り出して
TPM2_Unsealを実行し、32バイトのVMK(Volume Master Key)を入手。マウントしてユーザー文書まで読み書きできる状態を確認
2台とも成功し、所要時間は物理アクセス10分未満。大半はハードウェア操作とドライバの付け外しで、測定値の再生自体は軽い処理です。再現用コードはGitHubで公開されています。
なお、これは新発見の脆弱性ではありません。同じ発想の攻撃は Bernhard Kauer が2007年のUSENIX Securityで発表しており(TPM 1.1に対するもので、発見は2004年7月)、論文自身がそれを明示的に引き継いでいます。価値は「20年以上前から知られた攻撃が、TPM 2.0でも、Windows 11の既定構成でも今なお通用する」ことを実機で示した点にあります。TPMの実装バグを突くTPM 2.0参照実装の脆弱性や回復環境を悪用するWinREのBitLocker回避とは違い、こちらは設計上の前提を突く話です。
なぜバス暗号化やBIOSパスワードでは防げないのか
答えは「どちらも別の攻撃モデルを想定した対策だから」です。
バス保護(パラメータ暗号化・CPUとTPM間の相互認証)は、バスを流れる鍵を盗み見る受動的な盗聴には有効です。しかし今回のリセット/リプレイは、攻撃者が支配する環境でリセット後に正規のTPMセッションを張り直すため素通りします。本質はバス通信の機密性ではなく「測定チェーンが決定論的であること+ハードウェアリセットが可能であること」の組み合わせにあり、TCGのバス保護ガイダンスはこのギャップを扱っていないと論文は指摘します。
BIOSパスワードも浅い対策だと切り捨てられています。起動デバイス選択の段階で働くものなので、CMOSクリアジャンパやI2Cバス経由のリセットで無効化でき、さらにDXE段階のNVRAM操作(CVE-2025-3052)やLogoFAILのようにパスワード入力が求められる前に実行されるファームウェア脆弱性も存在します(この領域はUEFI脆弱性とブートキットと地続きです)。しかもコスト差が決定的です。バス盗聴には業務用ロジックアナライザで約1,500ドル、FPGA評価キットで約100ドル、安価なマイコンでも約10ドルかかりますが、リセット/リプレイはジャンパ線(0〜5ドル)で足ります。論文は「受動攻撃のほうが容易」というTCGの前提に反論し、端末盗難や国境での機器検査のような機会型の攻撃に乗りやすいと主張しています。
どこまでが「自分ごと」か:影響範囲と限界
| 構成 | この攻撃 | 備考 |
|---|---|---|
| BitLocker「TPMのみ」(Windows 11の既定) | 成立 | PCR 7+11の既定構成で実証済み |
| BitLocker TPM+PIN | この経路では防御される | 論文が明記。PINにはTPMのアンチハンマリング(総当たり対策)も効く |
| BitLocker TPM+起動キー等 | この経路では防御される | 追加認証要素があれば保護されるという整理 |
| Linux LUKS+TPM2による自動解錠 | 成立(著者が内部検証) | LUKSは既定のPCR構成を持たず利用者依存のため、対象ごとに作り込みが必要 |
| fTPM/統合TPM | バス経由の攻撃面は小さい | ただしAMD fTPMには電圧グリッチによる先行研究(faulTPM)があり、無敵ではない |
限界も著者自身が挙げています。設計によってはTPMのリセットがシステムリセットと連動して単独操作ができない機種依存があり、検証は2台のみです。当然ながら物理アクセスが前提で、遠隔からは成立しません。PC・スマホ紛失に備える暗号化とMDMの前提条件が一段細かくなった、と捉えるのが実務的でしょう。
研究の位置づけにも触れておきます。arXiv版は著者版で、正式版は2025年のACSAC併設ワークショップ(ACSAC Workshops 2025, pp.546–550)に採録済みでDOIも付いており、よくある査読前プレプリントとは事情が違います。一方で著者自身がこれを「ポジションペーパー」(問題提起型の論文)と位置づけています。新しい脆弱性の発見報告ではなく、既知の攻撃が今も通用することを示して業界の前提に異議を唱える論文なので、これ1本で「dTPMは無意味」と一般化するのは行きすぎです。研究資金はドイツ連邦研究技術宇宙省のプロジェクト(DI-SIGN-HEP、16KIS2074)によるものです。
現場目線の課題
一番効く対策がTPM+PINだと分かっていても、運用が重いのが本音です。深夜のパッチ再起動、リモートワーク先での再起動、キッティング、無人稼働の端末——PIN入力が挟まると、これらが全部止まります。多くの現場が既定のTPMのみを選んできたのは、怠慢というより運用との折り合いの結果でした。筆者の環境も例外ではありません。
もう一つ痛いのは台帳の粒度です。dTPMかfTPMかは見積書にも構成表にも普通は書かれていません。「うちの独立チップ型端末を洗い出そう」と思っても、棚卸しの粒度がそこまで無い壁に先にぶつかります。全台にスクリプトを流せば製造元IDは取れますが、それが即「実装形態の確定」にならないのも歯がゆいところです。
そして「暗号化してあります」という経営層への説明が、実は条件付きだったと分かる気まずさがあります。とはいえベンダーが隠していた話ではありません。Microsoftは公式ドキュメントで、TPMのみの構成は追加の認証要素を要求する他の選択肢より安全性は低いと書き、さらに機種によっては筐体を開けてはんだ付けが必要でも「妥当なコストで実行可能」だと明記しています。既定値としてそのトレードオフが受け入れられてきた、というのが正確な理解でしょう。
情シスはどうすべきか
自前で長いチェックリストを作るより、公式が攻撃者モデル別に整理してくれている資料を出発点にするのが早いです。
- Microsoft「BitLocker の対策」——攻撃者の能力別に推奨構成が整理されています。「スキルがあり長時間の物理アクセスを持つ攻撃者」に対しては、拡張PINを使ったTPM+PIN、スタンバイ電源管理の無効化、管理外に出る前のシャットダウンまたは休止状態を推奨。今回の攻撃者像はまさにこれです。
- PIN運用の重さが問題なら、BitLocker Network Unlockという緩和策があります。社内の有線LAN接続時はPINなしで起動し、社外に持ち出したときだけPINを要求できます。WDSサーバーが必要ですが、「全端末にPINは無理」で議論を止める前に検討する価値はあります。
- IPA「中小企業の情報セキュリティ対策ガイドライン」と「対策のしおり」——持ち出しルールや紛失時の初動、利用者への啓発の土台です。今回の攻撃は端末が攻撃者の手元に一定時間置かれることが出発点なので、「持ち出し端末を車内や宿泊先に放置しない」「紛失したら隠さず即報告する」という地道な教育がそのまま効きます。
- 新規調達では仕様書・RFPにTPMの実装形態(ファームウェア/統合/独立チップ)を明記させる。論文の結論もここで、新しい設計ではTPMをCPUやチップセットに統合すべきだとしています。
考察:漏えい報告の社内判定ルールへの影響
ここからは事実ではなく筆者の考察です。個人情報保護委員会のFAQでは、報告を要しない「高度な暗号化等の秘匿化がされている場合」に該当するには、(1)その事案が生じた時点の技術水準に照らして第三者が見読可能な状態にすることが困難な暗号化等の技術的措置が講じられていること、に加えて、(2)そのような技術的措置が講じられた情報を見読可能にするための手段が適切に管理されていること、の両方が必要だと説明されています。今回の研究が突いているのは(1)ではなく(2)です。AES-XTSのような暗号アルゴリズム自体は破られておらず、破られたのは「鍵を開けるための手段の管理」だからです。
ただし、個人情報保護委員会がTPMのみの構成をこの要件を満たさないと判断した、という情報は確認できていません。判断はその時点の技術水準と個別事案に依ります。ここで言えるのは、盗難・紛失時に「暗号化済みだから報告不要」と社内で機械的に判定するルールを持っている組織は、判定条件に構成(TPMのみか、PIN併用か)を入れておいたほうが安全——という運用面の示唆までです。断定的な法的評価は顧問弁護士や委員会への照会で確認してください。
まとめ
- Windows 11の既定であるBitLocker「TPMのみ」は、独立チップ型TPM搭載機では物理アクセス10分未満で解除されうることが実機2台で示された。ジャンパ線程度の機材で足り、再現コードも公開されている。
- TPM+PINなどの追加認証要素があれば、この経路は成立しない。バス暗号化やBIOSパスワードでは防げず、事前起動認証が実質的に唯一の実用的な壁になる。
- 持ち出し端末を優先してTPM+PINの適用可否を検討し、新規調達ではTPMの実装形態を仕様に入れ、社内の漏えい報告判定ルールに構成の観点を加えるのが現実的な次の一手。
出典
- Christian Werling, Tahmid Zahin, Jean-Pierre Seifert(SecT, TU Berlin / Fraunhofer SIT)”Not Discrete Enough: On the Inherent Insecurity of dTPMs for Measured Boot”, arXiv:2608.14736(2026年8月13日公開の著者版)/正式版:ACSAC Workshops 2025, pp.546–550, DOI: 10.1109/ACSACW69556.2025.00063 — https://arxiv.org/abs/2608.14736
- B. Kauer, “OSLO: Improving the security of Trusted Computing”, USENIX Security Symposium 2007(TPM 1.1に対する原型となるリセット攻撃)
- Microsoft「BitLocker の対策」 — https://learn.microsoft.com/ja-jp/windows/security/operating-system-security/data-protection/bitlocker/countermeasures
- Microsoft「TPM の推奨事項」(TPMの3つの実装形態、Windows機能ごとのTPM要件) — https://learn.microsoft.com/ja-jp/windows/security/hardware-security/tpm/tpm-recommendations
- Trusted Computing Group「Vendor ID Registry」 — https://trustedcomputinggroup.org/resource/vendor-id-registry/
- 個人情報保護委員会 よくある質問「『漏えい等が発生し、又は発生したおそれがある個人データについて、高度な暗号化等の秘匿化がされている場合』とは、どのような場合が該当しますか」 — https://www.ppc.go.jp/all_faq_index/faq1-q6-19_/
- IPA「中小企業の情報セキュリティ対策ガイドライン」 — https://www.ipa.go.jp/security/guide/sme/index.html
