FIPS 140-3はセキュリティ保証ではなく、監査人もそれを知っている

FIPS 140-3はセキュリティ保証ではなく、監査人もそれを知っている2026-08-05 · 14分主要なHSMベンダーの1社のセールスエンジニアが最近、FIPS対応HSMを購入した顧客の90パーセント以上がFIPSモードを無効にして運用していると私に語りました。彼らは証明書のためにプレミアムを支払った後、それが記述する構成をオフにします。この記事の終わりまでに、それがしばしば正しいエンジニアリング上の決定である理由を理解するでしょう。2026年9月21日、残りのすべてのFIPS 140-2証明書はNISTの履歴リストに移行し、そのリストにあるモジュールは連邦調達に含めるべきではなくなります。調達チームは夏の間、ベンダーにFIPS 140-3の書類を追いかけ、ベンダーは検証キューでそれを過ごしています。多くの資金と注意が証明書に流れています。したがって、静かな部分を大声で言うのに良い時期です。FIPS検証は狭い質問への回答であり、ほとんどの人が尋ねていると思っている質問ではありません。証明書は、特定のファームウェアバージョン、特定の構成の特定の暗号モジュールが、承認されたアルゴリズムを正しく実装し、特定の設計要件を満たしていることを証明します。それは、そのモジュールを取り巻く製品が安全であること、モジュールが検証された構成で運用されること、またはその内部の鍵が誰かに防御できる方法で生成および管理されたことを証明するものではありません。それらのものの代理として証明書を扱うことは、実際のインシデントが発生する場所です。これらすべてがFIPSに反対する議論ではありません。このプログラムは、詐欺的な暗号の世代を排除し、「検証なし、購入なし」は依然として賢明な調達の最低ラインです。議論は、証明書が何をカバーしているかについてです。なぜなら、それがカバーしているものと人々がカバーしていると信じているものの間のギャップは、驚くほど一貫しており、驚くほどよく文書化されているからです。その過程で、認定されたYubiKeyが同じ棚にあるコンシューマーモデルよりも弱かったこと、FIPSモードが実際に何であるかのベンチマーク、そしてパニックなしにビットコインウォレットを派生させることができない4行のGoプログラムについて説明します。証明書が実際に述べていることFIPS 140-3検証は、暗号モジュールの境界に適用されます。アルゴリズムは承認され、正しく実装されており、鍵はゼロ化でき、モジュールは起動時の自己テストを実行し、レベル2から4では、ハードウェアは物理的な改ざんに抵抗または応答します。それが全体の範囲です。モジュールを呼び出すアプリケーション、その周りのアクセス制御、鍵管理ポリシー、オペレーターカードを保持する人間、および最初の鍵を内部に配置したセレモニーはすべて境界の外にあり、それらのいずれも検査されません。検証はスナップショットでもあります。それは正確なファームウェアバージョンと正確な構成にバインドされます。デバイスが異なるファームウェアを実行した瞬間、またはレガシークライアントが必要としたために非承認モードが有効になって実行された場合、それはもはや証明書上のものではありません。私の経験では、展開されたHSMエステートのほとんどは数か月以内に検証済み構成から逸脱し、それが起こっても誰もダッシュボードが赤く点灯しません。同時に認定され、壊れている検証がセキュリティ保証ではないことの最も強力な証拠は、長年、ラボプロセスをまっすぐに通過して、悪用可能な欠陥を出荷した認定モジュールのリストです。ROCA（2017）。InfineonのRSA鍵生成における欠陥により、1024ビットおよび2048ビットの鍵が公開鍵のみから事実上因数分解可能になる、固定構造を持つ素数が生成されました。影響を受けたライブラリは、少なくとも2012年から出荷されており、FIPS 140-2およびCommon Criteria EAL5+認定を保持するデバイスに含まれていました。この欠陥は、鍵生成という検証が存在するまさにその機能の中にあり、プロセスは5年間何も発見しませんでした。エストニアはそれにより国家IDカードを一時停止しました。EUCLEAK（2024）。InfineonのECDSA実装における非定数時間モジュラー逆数は、電磁サイドチャネルを介した秘密鍵の抽出を可能にしました。NinjaLabの論文は、この欠陥が14年間、約80回の最高レベルのCommon Criteria評価で unnoticed であったと述べています。Yubicoの勧告は、YubiKey 5 FIPSシリーズとYubiHSM 2 FIPSが影響を受けたことを確認しており、YubiKeyのファームウェアはフィールドアップグレード可能ではないため、修正はハードウェアの交換でした。Dual_EC_DRBG（2004-2014）。10年間、NSAによってバックドアされた疑いのある乱数ジェネレーターがNIST承認アルゴリズムであり、他のすべてを検証するのと同じプログラムによってモジュールに検証され、RSAのFIPS検証済みBSAFEライブラリのデフォルトRNGでした。Snowden文書が問題を強制した後、NISTは2014年にそれをSP 800-90Aから削除しました。それらのモジュールをカバーするすべての証明書は、その間ずっと正確でした。アルゴリズムは承認され、正しく実装されていました。YubiKey FIPSシリーズ（2019）。これは特別な場所を占めるに値します。なぜなら、FIPS要件は欠陥を捉えるのに失敗しただけでなく、それらを引き起こしたからです。ファームウェア4.4.2および4.4.4では、起動後のランダム値を含むバッファには、FIPS起動時の自己テストから残った予測可能なコンテンツが含まれていました。ECDSA操作では最大80ビットの予測可能な値が使用され、256ビットのノンセが使用され、これは実用的な鍵回復の範囲内です。この問題はFIPSシリーズにのみ存在しました。通常のコンシューマーYubiKeyは問題ありませんでした。Yubicoは影響を受けた政府用鍵をリコールして交換しました。FIPS認定製品は、同じ棚にある非認定製品よりも測定可能に安全性が低かったのです。検証は触れたものを凍結しますラボプロセスは一度限りのペーパーエクササイズであり、スナップショットに対して行われます。スナップショットの取り直しは高価です。CMVPキューは歴史的に提出から証明書まで12〜18か月かかり、NISTはバックログを処理するために暫定検証スキームを発明しなければならないほどでした。UbuntuのFIPSチームが内部から説明しているように。その遅延は、検証済みモジュールのすべてのベンダーが最終的に直面する逆説的な選択を生み出します。セキュリティ修正を今すぐ出荷して、1年以上検証済みリストから外れるか、既知の欠陥がある検証済みビルドを出し続けるかです。アクティブな証明書を必要とする契約を持つ顧客は、実質的にベンダーに2番目のオプションを選択するように支払っています。2019年のYubiKeyインシデントは、メカニズムを明確に示しています。修正済みファームウェアは存在しましたが、NISTが新しいバージョンの認定を付与するまで交換品を出荷できませんでした。証明書は、フィールドに既知の脆弱なコードを文字通り保持することができます。Goは、凍結がコストをどれだけかけるかの最もクリーンなケーススタディです。なぜなら、歴史全体が公開されているからです。長年、GoにはGo+BoringCrypto以外の検証済みパスがありませんでした。これは、GOEXPERIMENT=boringcryptoで有効化されたBoringSSLの検証済みモジュールへのcgoバインディングであり、公式にはサポートされておらず、基本的にGoogleの内部ニーズのために維持されていました。クロスコンパイルを壊し、外国関数オーバーヘッドを追加し、Goのメモリ安全性にCへの穴を開けました。Red HatとMicrosoftはそれぞれ、代わりにOpenSSLとWindows CNGにバインドされた独自のフォークを維持していました。したがって、「FIPS準拠のGo」は3つの異なる非公式ツールチェーンを意味し、すべて証明書を満たすためでした。Go 1.24は、ついにGeomysとGoセキュリティチームによって書かれたネイティブGo暗号モジュールをリリースしました。これは、cgoなしの純粋なメモリセーフなGoでCMVP証明書#5247として検証されました。そして、凍結が再び主張しました。証明書はモジュールv1.0.0をカバーしており、Go 1.24のスナップショットが凍結されていますが、v1.26.0モジュールはModules In Processリストにあります。今日、認定モジュールに対してビルドされたGoバイナリは、2つのメジャーリリース前の暗号コードを実行します。それはGoの失敗ではありません。それはシステムが設計どおりに機能しているということです。これも、「FIPSモード」がオペレーティングシステムまたはアプライアンスで、受けるよりも少ない尊敬に値する理由です。それを切り替えると、通常はアルゴリズムセットが制限され、検証済み（古い）暗号プロバイダーにスワップされます。それは監査人がチェックを入れるボックスを変更します。それがあなたの実際の危険をどれだけ変えるかは、あなたの脅威モデルが何であったかに完全に依存しており、ほとんどのエステートにとって正直な答えは、誰もチェックしなかったということです。FIPSが実際に規定していること、そしてそのコスト公平な質問は、この時点で次のとおりです。FIPSは少なくともアルゴリズムをうまく実装するように強制しますか？部分的に。CAVPテストは実装を検証します。