FIPS 140-3 Go暗号モジュール

The FIPS 140-3 Go Cryptographic Module by Filippo Valsorda (Geomys), Daniel McCarney (Geomys), and Roland Shoemaker (Google)

FIPS 140は暗号実装のための標準規格です。必ずしもセキュリティを向上させるものではありませんが、 FIPS 140への準拠は、Goの採用が進んでいる一部の規制環境において要件となっています。これまでFIPS 140準拠は、Goユーザーにとって大きな摩擦の種でした。安全性、開発者体験、機能性、リリース速度、コンプライアンスの面で問題を抱える、非サポートのソリューションを必要としていたからです。

Goはこの高まるニーズに対して、標準ライブラリと go コマンドに直接組み込まれたネイティブなFIPS 140 サポートで応えています。これにより、GoはFIPS 140に準拠する最も簡単で安全な方法になりました。 FIPS 140-3の検証を受けたGo Cryptographic Moduleは、今やGo組み込みの暗号ライブラリの基盤となっています。これは、昨年2月にリリースされたGo 1.24に含まれるGo Cryptographic Module v1.0.0から始まりました。

v1.0.0モジュールはCryptographic Algorithm Validation Program(CAVP)証明書A6650を取得し、Cryptographic Module Validation Program(CMVP)に提出され、5月にはModules In Processリストに掲載されました。 MIPリストに掲載されたモジュールはNISTのレビュー待ちの状態ですが、一部の規制環境ではすでに導入可能です。

Geomysは、Go Security Teamと協力してこの実装作業を主導し、Goコミュニティ全体の利益のために、幅広く適用可能なFIPS 140-3検証の取得を進めています。GoogleをはじめとするいくつかのステークホルダーはGeomysと契約関係を結び、証明書に特定のOperating Environment(動作環境)を含めています。

モジュールの詳細についてはドキュメントを参照してください。

一部のGoユーザーは現在、FIPS 140準拠戦略の一環として、Go+BoringCryptoというGOEXPERIMENT、あるいはそのフォークの一つに依存しています。FIPS 140-3対応のGo Cryptographic Moduleとは異なり、 Go+BoringCryptoは公式にサポートされたことは一度もなく、もっぱらGoogle社内のニーズのためだけに作られたものだったため、開発者体験の面で大きな問題を抱えていました。Googleがネイティブモジュールへの移行を完了次第、将来のリリースで削除される予定です。

ネイティブな開発者体験

このモジュールはGoアプリケーションに完全に透過的な形で統合されています。実際、Go 1.24でビルドされたすべてのGoプログラムは、FIPS 140-3で承認されたすべてのアルゴリズムに対して、すでにこのモジュールを使用しています!このモジュールは、標準ライブラリの crypto/internal/fips140/... パッケージの別名にすぎません。これらのパッケージは、 crypto/ecdsa や crypto/rand といったパッケージが公開する処理の実装を提供しています。

これらのパッケージはcgoを一切使用していません。つまり、他の通常のGoプログラムと同様にクロスコンパイルが可能で、FFIによるパフォーマンスのオーバーヘッドを払う必要がなく、Go+BoringCryptoやそのフォークとは異なり、メモリ管理に起因するセキュリティ上の問題に悩まされることもありません。

Goのバイナリを起動する際、GODEBUGオプションである fips140=on を使うことで、モジュールをFIPS 140-3モードにできます。これは環境変数として設定することも、 go.mod ファイル経由で設定することも可能です。FIPS 140-3モードが有効な場合、モジュールは乱数生成にNISTのDRBGを使用し、 crypto/tls は自動的にFIPS 140-3で承認されたTLSのバージョンとアルゴリズムのみをネゴシエートするようになり、初期化時と鍵生成時に必須のセルフテストを実行します。動作の違いはそれだけで、他にはありません。

実験的なより厳格なモードとして fips140=only も用意されています。これは承認されていないすべてのアルゴリズムがエラーを返すかパニックを起こすようにするものです。私たちは、これがほとんどのデプロイにとって柔軟性に欠けすぎる可能性があると理解しており、ポリシー強制の仕組みがどのような形であるべきかについてフィードバックを募集しています。

最後に、アプリケーションはGOFIPS140 環境変数を使うことで、より古い、検証済みバージョンの crypto/internal/fips140/... パッケージに対してビルドできます。 GOFIPS140 は GOOS や GOARCH と同じように動作し、 GOFIPS140=v1.0.0 に設定すると、CMVPへの検証提出時点のv1.0.0スナップショットのパッケージに対してプログラムがビルドされます。このスナップショットは、 Go標準ライブラリの他の部分と一緒に lib/fips140/v1.0.0.zip として同梱されています。

GOFIPS140 を使用する場合、 fips140 のGODEBUGはデフォルトで on になります。つまりまとめると、 FIPS 140-3モジュールに対してビルドし、FIPS 140-3モードで実行するために必要なのは GOFIPS140=v1.0.0 go build だけです。それだけです。

ツールチェイン自体が GOFIPS140 を設定した状態でビルドされている場合、そのツールチェインが生成するすべてのビルドは、デフォルトでその値を使うようになります。

バイナリのビルドに使われた GOFIPS140 のバージョンは、 go version -m で確認できます。

今後のバージョンのGoも、Geomysによって次のバージョンが完全に認証されるまでは、引き続きGo Cryptographic Moduleのv1.0.0を同梱し、それと共に動作し続けます。ただし、古いモジュールに対してビルドする場合、新しい暗号機能の一部が利用できないことがあります。Go 1.24.3からは、 GOFIPS140=inprocess を使うことで、 Geomysの検証がIn Processの段階に達している最新のモジュールを動的に選択できます。GeomysはFIPS 140ビルドがあまりにも古い状態のまま取り残されないよう、少なくとも年に1回、また呼び出し側の標準ライブラリのコード側では緩和できないモジュール内の脆弱性が見つかるたびに、新しいバージョンのモジュールを検証していく計画です。

妥協のないセキュリティ

このモジュールを開発する上で私たちが最優先してきたのは、既存のGo標準ライブラリの暗号パッケージのセキュリティに匹敵する、あるいはそれを上回ることでした。意外に思われるかもしれませんが、FIPS 140のセキュリティ要件への準拠を達成し、それを証明する最も簡単な方法は、その要件を上回らないことである場合があります。私たちはその道を選びませんでした。

例えば、 crypto/ecdsa は常にヘッジ署名(hedged signatures)を生成していました。ヘッジ署名は、秘密鍵、メッセージ、そしてランダムなバイト列を組み合わせてナンスを生成します。決定的ECDSA(deterministic ECDSA)と同様、乱数生成器が故障した場合の保護になります。そうでなければ秘密鍵が漏洩してしまいます(!)。決定的ECDSAとは異なり、ヘッジ署名は APIの問題やフォールト攻撃にも耐性があり、メッセージの一致を漏らすこともありません。FIPS 186-5ではRFC 6979 の決定的ECDSAへのサポートが導入されましたが、ヘッジECDSAへのサポートは導入されませんでした。

FIPS 140-3モードにおいて(あるいはさらに悪いことに、モードをまたいで)通常のランダム化されたECDSA署名や決定的ECDSA署名にダウングレードする代わりに、私たちはヘッジのアルゴリズムを切り替え、半ダースにも及ぶ文書の内容をつなぎ合わせることで、新しいアルゴリズムがDRBGと従来のECDSAの準拠した組み合わせであることを証明しました。その過程で、決定的署名へのオプトイン対応も追加しました。

もう一つの例は乱数生成です。FIPS 140-3には暗号学的な乱数の生成方法について厳格な規則があり、実質的にユーザー空間のCSPRNG の使用を強制しています。しかし私たちは、安全な乱数バイト列の生成に最も適しているのはカーネルであると考えています。なぜならカーネルはシステムからエントロピーを収集するのに最も適した立場にあり、プロセスや仮想マシンがクローンされたとき(これは本来ランダムであるはずのバイト列の再利用につながりかねません)を検知するのにも最も適しているからです。そのため、crypto/randはすべての読み出し処理をカーネルへとルーティングします。

この矛盾を解消するために、FIPS 140-3モードでは、AES-256-CTRをベースにした準拠のユーザー空間NIST DRBGを維持しつつ、読み出し操作のたびにカーネル由来の128ビットをそこに注入しています。この追加のエントロピーは FIPS 140-3の観点では「クレジットされない(uncredited)」追加データとして扱われますが、実際にはこれによって、多少遅くなるとしても、カーネルから直接読み出すのと同程度に強固になっています。

最後に、Go Cryptographic Module v1.0.0の全体が、Trail of Bitsによる先日のセキュリティ監査の対象範囲に含まれており、唯一の非informational(参考情報ではない)所見の影響を受けていませんでした。

Goのコンパイラとランタイムが提供するメモリ安全性の保証と合わせて、これによって、GoをFIPS 140準拠のための最も簡単で安全なソリューションの一つにするという私たちの目標を達成できたと考えています。

幅広いプラットフォームサポート

FIPS 140-3モジュールは、テスト済みまたは「ベンダー確認済み(Vendor Affirmed)」のOperating Environment (基本的にはオペレーティングシステムとハードウェアプラットフォームの組み合わせ)で運用された場合にのみ準拠しているとみなされます。できるだけ多くのGoのユースケースに対応するため、Geomysの検証は業界でも最も包括的な部類に入るOperating Environmentの集合に対してテストされています。

Geomysの検査機関は、さまざまなLinuxディストリビューション(Podman上のAlpine Linux、Amazon Linux、 Google Prodimage、Oracle Linux、Red Hat Enterprise Linux、SUSE Linux Enterprise Server)、macOS、 Windows、FreeBSDを、x86-64(AMDおよびIntel)、ARMv8/9(Ampere Altra、Apple M、AWS Graviton、 Qualcomm Snapdragon)、ARMv7、MIPS、z/Architecture、POWERといった様々なハードウェアの組み合わせでテストし、合計23のテスト済み環境を実現しました。

これらのうち一部はステークホルダーによって費用が負担され、その他はGoコミュニティの利益のためにGeomysが資金を提供しました。

さらに、Geomysの検証では、ベンダー確認済みのOperating Environmentとして、幅広い汎用プラットフォームの集合が挙げられています。

x86-64およびARMv7/8/9上のLinux 3.10以降
Apple Mプロセッサ上のmacOS 11〜15
x86-64上のFreeBSD 12〜14
x86-64上のWindows 10およびWindows Server 2016〜2022
x86-64およびARMv8/9上のWindows 11およびWindows Server 2025

包括的なアルゴリズムのカバレッジ

意外に思われるかもしれませんが、サポートされたOperating Environment上でFIPS 140-3モジュールによって実装されたFIPS 140-3承認済みアルゴリズムを使用するだけでは、必ずしも準拠には十分ではありません。そのアルゴリズムが検証の一環として明確にテストの対象になっている必要があります。そのため、GoでFIPS 140 準拠のアプリケーションをできるだけ簡単に構築できるようにするため、標準ライブラリ内のFIPS 140-3承認済みアルゴリズムはすべてGo Cryptographic Moduleによって実装されており、デジタル署名からTLSのキースケジュールに至るまで、検証の一環としてテストされています。

Go 1.24で導入された耐量子計算機暗号のML-KEM鍵交換(FIPS 203)も検証済みです。つまり crypto/tls は、X25519MLKEM768を用いたFIPS 140-3準拠の耐量子計算機セキュアな接続を確立できます。

場合によっては、同じアルゴリズムを異なる複数のNISTの名称の下で検証し、それぞれ異なる用途において完全に準拠した形で使用できるようにしました。例えば、HKDFは4つの名称の下でテストおよび検証されています。 SP 800-108 Feedback KDF、SP 800-56C two-step KDF、Implementation Guidance D.P OneStepNoCounter KDF、そしてSP 800-133 Section 6.3 KDFです。

最後に、XAES-256-GCMのような将来の機能を公開できるようにするため、 CMAC Counter KDFなどの内部アルゴリズムについても検証を行いました。

全体として、このネイティブなFIPS 140-3モジュールは、Go+BoringCryptoよりも優れたコンプライアンスのプロファイルを提供しつつ、FIPS 140-3に制約されたアプリケーションでより多くのアルゴリズムを利用できるようにしています。

この新しいネイティブなGo Cryptographic Moduleによって、Goの開発者がFIPS 140準拠のワークロードをより簡単かつ安全に実行できるようになることを楽しみにしています。

By Filippo Valsorda (Geomys), Daniel McCarney (Geomys), and Roland Shoemaker (Google)