## 定義 HSM APIセキュリティとは、ハードウェアセキュリティモジュール(HSM)が外部に公開するトランザクションAPI自体を悪用し、物理的な耐タンパ機構を迂回して鍵材料や暗証番号(PIN)を漏洩させる攻撃と、その対策の総体を指す。*Security Engineering* 第3版第20章は、HSMは物理的に鍵を取り出せなくする(耐タンパ性)だけでは不十分であり、より信頼されたコンポーネント(HSM)とより信頼されていないコンポーネント(それを呼び出すサーバやATM)の境界を、攻撃者が予期しないコマンドの組み合わせで探ってくることを前提に設計しなければならないと指摘する。代表的な攻撃には、鍵の型システムの不備を突く**xor-to-null-key攻撃**(2つの暗号化鍵成分をXORして「オール・ゼロ鍵」を非輸出可能な作業鍵として合成し、これで他の鍵を復号する)、後方互換性を悪用する攻撃(2キー3重DESの左右の鍵半分の結合を検証しないIBM 4758の欠陥)、チェック値を使った時間・メモリトレードオフ攻撃、誤りメッセージの有無からPINを推測する攻撃、そして**差分プロトコル解析(differential protocol analysis)**――同一プロトコルをわずかに変えたパラメータ(例えばPIN生成の小数化テーブル)で繰り返し実行し、暗号化された出力の変化を観察することで秘密を逐次的に割り出す手法――がある。著者はこれを「頑健な安全なマルチパーティ計算(secure multiparty computation、ある当事者の秘密情報と、敵対的な当事者が操作できる入力の両方を扱う計算)の設計がいかに困難かを示す実例」と位置づける。攻撃の根本原因は、決済プロトコルの多様なバリエーションに対応するためAPIにトランザクションを次々と追加していく「featuritis」(機能追加による複雑化)であり、これは2000年代初頭の攻撃だけでなく2019年のGemalto HSM(PKCS#11実装をファジングし認証機能にパッチを当てて鍵を読み出す攻撃)まで繰り返し現れるパターンである。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]], ch.20 §20.5〜§20.5.6) ## 横断的知見 - **ch.20 が扱う「HSM APIプロトコル自体の設計欠陥」への脅威モデルと、ch.11 が示す「ベンダー提供HSMコードそのものへの不信」という脅威モデルは、同じ「HSMをどこまで信頼するか」という問いに対する異なる切り口である**: [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] は、HSM のトランザクションAPIの型システムやプロトコル設計の不備(xor-to-null-key攻撃、差分プロトコル解析)を突いて鍵材料を漏洩させる攻撃を主題とし、HSM自体は正しく実装されている前提でそのAPI設計を疑う。一方 [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] は、公的CAの鍵材料を守るために商用ベンダーのHSMを使わざるを得ない状況で、そのベンダー提供コード自体(HSM連携ライブラリ)を検証できないブラックボックスとみなし、防御的な呼び出しコードを書き、nsjailで軽量プロセス分離した上で実行し、発見した問題をベンダーに報告するという、コードのサプライチェーンそのものへの不信を前提にした対策を取る。前者はプロトコル設計の欠陥を、後者は実装(メモリリーク等)とベンダーとの信頼関係の欠如を主眼に置いており、両者を合わせて初めて「HSMという同一のコンポーネントに対し、プロトコルレベルと実装・供給網レベルの二重の脅威モデルが存在する」ことが分かる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] ch.20 §20.5〜§20.5.6, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] §Securing Third-Party and Open Source Components) ## 未解決の問い - 「最新のHSMは鍵に強い型付けを持たせ形式的な推論をしやすくしている」と本章は述べるが、この形式手法による検証がどこまで実務のHSM APIの複雑さに耐えられるかは、本章の範囲(2020年時点)では検証されていない。 - 差分プロトコル解析という手法は、HSMのAPI以外の暗号プロトコル(例えばパディングオラクル攻撃、[[暗号利用モード]]が扱うCBCモードの完全性欠如)とどこまで同型の攻撃パターンとみなせるか。両者を統一的に扱う分類は本章では示されていない。 - クラウドHSM(Azure・AWSでのマルチテナント運用)において、各行固有の小数化テーブルのようなカスタムパラメータをハードコードする対策が、マルチテナント性とどう両立するかは、本章では「作業中(work in progress)」と述べられるのみで具体策は示されていない。 - ch.11 が示す「ベンダー提供HSMコードをnsjailでサンドボックス化する」という対策は、ch.20 が指摘するAPIプロトコルレベルの攻撃(xor-to-null-key攻撃・差分プロトコル解析)そのものを防げるわけではない。プロセス分離は実装バグ(メモリリーク等)の影響範囲を抑えるが、正規のAPI呼び出しの組み合わせを悪用する攻撃には無力なはずであり、この防御ギャップが実務上どこまで問題になるかは両章とも扱っていない。 ## 関連 - [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] — xor-to-null-key攻撃・差分プロトコル攻撃・EMV攻撃・Gemalto攻撃の詳細 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] — 公的CAがベンダー提供HSMコードをnsjailでサンドボックス化し防御的に扱う実務 - [[耐タンパ性]] — 物理的な耐タンパ機構だけでは防げないAPI層の攻撃という対比 - [[IBM 4758]] — 後方互換性攻撃・時間メモリトレードオフ攻撃の対象となった代表的HSM - [[認証局とPKIの信頼モデル]] — CA鍵材料保護というHSMの具体的な適用先 ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 20, §20.5. - Andy Warner, James Kasten, Rob Smits, Piotr Kucharski, and Sergey Simakov, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 11.