HSM｜鍵生成・署名・証明書管理を担う

HSM

HSM（Hardware Security Module）は、暗号鍵を安全に生成・保管し、装置内部で暗号処理を完結させるための専用ハードウェアである。改ざん耐性筐体、侵入検知、ゼロ化機構、耐タンパ設計を備え、秘密鍵の平文搬出を原則として許さない。一般的なソフトウェア実装よりも鍵露出リスクが低く、規制・監査要件（金融、行政、医療など）に適合しやすい。PKIやコード署名、決済、データベース暗号化、IoT製造時の鍵インジェクションなど、鍵の真正性・機密性が不可欠な場面でHSMが利用される。

Table Of Contents

目的と基本機能

HSMの主目的は「鍵のライフサイクルを安全に制御し、暗号操作を信頼境界内で完結させる」ことである。主な機能は、(1)高品質なTRNGによる鍵生成、(2)装置内ストレージもしくはセキュアメモリ上での鍵保管、(3)署名・復号・MAC・ラッピング等の暗号演算、(4)改ざん検知と鍵ゼロ化、(5)強制アクセス制御・役割分割・二人承認、(6)監査ログの保全である。装置にはセキュアクロックや改ざんセンサー、ファームウェア完全性検証機構が組み込まれる。

アーキテクチャと接続形態

HSMはネットワーク接続型アプライアンスと、PCIe/USBカード型に大別される。前者はスケールアウトやHAクラスタを構成しやすく、後者はレイテンシの短さやオンプレ環境への密結合に利点がある。APIはPKCS#11、JCE、CNG、OpenSSL engineなどが主流で、鍵管理連携にはKMIPが用いられる。大規模環境では複数HSMをクラスター化し、セッション分散と冗長化でスループットと可用性を確保する。

鍵ライフサイクル管理

生成：TRNGで秘密鍵/KEKを生成し、鍵属性（用途・アルゴリズム・有効期限）を設定する。
配備：鍵を平文化せずラッピングしてHSM間で移送する。
ローテーション：暗号強度・運用ポリシーに基づき定期更新する。
バックアップ：分割知識（M-of-N）や二人承認で暗号化バックアップを作成する。
廃棄：失効・ゼロ化を実施し、監査証跡を残す。
監査：すべての鍵操作を改ざん困難なログへ記録し、外部SIEMへ転送する。

性能と運用

HSMは署名/復号スループットと同時セッション数が重要指標である。TLSハンドシェイクのオフロードやコード署名のバッチ処理では、レイテンシと安定スループットの両立が求められる。運用上は、RBAC、デバイスポリシー、二人承認、キークォーラム、遠隔管理の保護（管理チャネルの相互認証・証跡化）、そして障害時の迅速なDR計画が不可欠である。

規格と認証

HSMはFIPS 140-2/140-3のレベル適合（2/3/4）やCommon Criteria評価が一般的である。金融分野ではPCI PTS HSM、電子署名分野ではeIDAS準拠（QSCD相当）が参照される。規格適合は機能の優劣ではなく、実装と運用プロセスが所定の保証水準を満たすことを示す。要件に応じて認証レベルや監査可能性を選定することが望ましい。

ユースケース

PKI：ルートCA/サブCAの鍵をHSMに封じ込め、署名操作のみを委任する。
TLS：サーバ秘密鍵を外出しせずに署名し、鍵窃取リスクを低減する。
コード署名：ビルドパイプラインからHSM経由で署名し、サプライチェーン攻撃に備える。
データベース暗号化：TDEのマスター鍵やKEKをHSMで管理する。
決済：EMV、PIN処理、キー変換やDUKPTの保護に特化した決済向けHSMを用いる。
ブロックチェーン：ウォレット鍵やコールド署名をHSMで保護する。
製造：IoTデバイスへの鍵インジェクションや証明書発行をラインで実施する。

クラウドとマネージドサービス

クラウドHSMは専有ハードウェアを提供し、オンプレと同等の鍵境界を保ちつつスケールと可用性を得る。一方、KMSは利便性が高いが、鍵の論理境界や運用責任分界が異なる。BYOK/EKM、外部署名、ハイブリッド構成などの選択肢を比較し、コンプライアンス、遅延、コスト、運用成熟度の観点で評価する。

TPM・TEE・スマートカードとの違い

TPMはプラットフォーム信頼の根に位置付けられ、ブート測定やディスク暗号鍵保護に強い。TEEはCPU内隔離環境でアプリの秘密処理を行う。一方HSMは高スループットなサーバ側鍵業務や組織横断鍵管理に適し、鍵の生成・保管・署名を専用筐体内で完結させる。スマートカード/トークンはエンドユーザ認証や小規模署名に向くが、集約性能や可用性設計はHSMに及ばない。

可用性とバックアップの設計上の注意

HSMクラスタはアクティブ/アクティブで運用し、ノード障害時も鍵操作を継続する。バックアップはラッピング鍵と分割知識で保護し、保管場所の地理的分散と定期リストア演習で実効性を担保する。復旧手順はクォーラム制で、単独管理者による不正復元を防ぐ。

セキュリティ設計の落とし穴

APIの誤用（平文鍵抽出を許す権限設計）、弱い監査、未検証のリモート管理、旧式アルゴリズムの温存、サイドチャネル未対策、ファーム更新の署名未検証は典型的失敗である。アルゴリズム方針はRSA/ECC/Ed25519やAES-GCM、SHA-256/384を基軸に暗号アジリティを確保し、PQC移行に備えたハイブリッド運用を計画する。