入門解説

HSM/TPMとは
(鍵管理と改ざん耐性)

HSM は Hardware Security Module、TPM は Trusted Platform Module の略です。

NIST の定義では、HSM は 「暗号鍵を保護・管理し、暗号処理を提供する物理デバイス」 であり、改ざんの痕跡が分かる、または侵入耐性を持つものとして説明されています。
TPM は 「一部のコンピュータ基板に組み込まれる耐タンパな集積回路」 で、鍵生成を含む暗号処理を実行し、パスワードや暗号鍵のような少量の重要情報を保護する仕組みと定義されています。

HSMとTPMの違い

実務での違いを一言で言うと、HSMは“鍵管理と暗号処理の装置”、TPMは“端末/基板側の信頼の起点” です。

HSM

鍵管理と暗号処理の中核
NIST は、鍵管理コンポーネントの一部として、鍵の生成、配布、保管、失効、破棄などに使われると説明しています。

TPM

個別のデバイスの信頼基盤
プラットフォーム(基板)上で少量の秘密情報を保護しつつ、暗号処理を行う耐タンパICです。

つまり、HSM はより広いシステム全体での鍵管理・暗号処理の中核を担い、TPM は個別のデバイスが「信頼できる状態にあるか」を支える基盤に寄る、という理解が実務では分かりやすいです。

なぜ「鍵管理と改ざん耐性」に関係するのか

関連概念として、NIST は hardware root of trust(ハードウェアの信頼の起点) を「情報の完全性を維持する、本質的に信頼されたハードウェアとファームウェアの組み合わせ」と定義し、attestation(アテステーション) を「ハードウェアに安全に保持された測定値に対してデジタル署名を与え、相手がその署名と測定値を検証するプロセス」と説明しています。

HSMやTPM は、こうした “信頼の起点”“改ざんされていないことの証明” と一緒に語られやすく、OEMからの照会では
「(OTA等で使う)鍵をどこで守るのか」
「更新物やデバイス状態の正当性をどう担保するのか」
という質問に対する強力な説明材料になります。

サプライヤー実務での見方

サプライヤーのPSIRT実務やOEM回答において、HSMやTPMの技術的スペックそのものを詳細に説明することより、「それを何を守るために使っているか」を言えることが重要です。

たとえば次のような文脈(整理)です。

  • 「暗号鍵をソフトウェアだけで持たない(抽出を防ぐ)」
  • 「承認された秘密情報を耐タンパなハードウェア側で扱う」
  • 「ファームウェアが改ざんされていない状態を示す基盤として使う」

逆に、対象版数の特定や構成管理、脆弱性の影響評価といった基本的な証跡が無いまま「HSM/TPMが搭載されています」とだけ言っても、OEM照会や監査では「だから何?」と論破されてしまい強い説明にはなりません。
HSM/TPM は、あくまで鍵管理と改ざん耐性の基盤(防御の一部)として理解するのが安全です。

よくある誤解

  • 誤解1:HSMとTPMは同じものである

    違います。 HSM は鍵管理と暗号処理の「装置」であり、TPM はプラットフォーム側の耐タンパな「信頼基盤(IC)」です。役割と配置される場所のスケールが異なります。

  • 誤解2:HSM/TPMがあれば“修正した”ことまで自動で証明できる

    違います。 HSM/TPM は鍵や信頼の土台(Root of Trust)を強くしますが、脆弱性対応の実務では「いまどのバージョンが動いているか」を示す対象版数、更新記録、各種証跡、そして必要なら attestation(第三者への証明プロセス)のような別の説明材料と組み合わせて初めて証明が成立します。attestation 自体は、測定値に対する署名と検証のプロセスとして別概念です。


FAQ:HSM/TPMとは

Q1. HSMとは何ですか?

暗号鍵を保護・管理し、暗号処理を提供する物理デバイスです。NIST は、改ざんの痕跡が分かる、または侵入耐性を持つものとして説明しています。

Q2. TPMとは何ですか?

一部のコンピュータ基板に組み込まれる耐タンパな集積回路(IC)で、鍵生成を含む暗号処理を行い、パスワードや鍵などの少量の重要情報を保護します。

Q3. サプライヤー実務で、HSM/TPMは何に使うのですか?

実務上は、鍵管理、暗号処理、改ざん耐性、信頼の起点(Root of Trust)づくりに関係します。OEMに対して「どうやって機密情報を守っているか」「改ざんを防いでいるか」を説明する際の強力な技術的根拠となります。

自社製品の「対策の証明」を整理しませんか?

HSMやTPMをはじめとする製品のセキュリティ機能が、OEMからの脆弱性調査依頼に対して「影響なし」や「対策済み」を主張する上でどう使えるか。製品のアーキテクチャに基づいた影響範囲の説明ロジックを整理したい方はご相談ください。