GoがFIPS 140-3認証を取得

 (csrc.nist.gov)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Certificate #5247 は Go Cryptographic Module に対する CMVP 認証であり、FIPS 140-3 標準で Active 状態として登録されている
  • Go Cryptographic Module は Go 標準ライブラリや他の Go アプリケーションに暗号機能を提供するソフトウェアライブラリであり、全体のセキュリティレベルは Level 1
  • 認証は approved mode で運用される場合に適用され、Sunset Date は 2031年4月26日 と表示されている
  • 検証履歴は 2026年4月27日 Initial で、試験機関は Lightship Security, Inc.
  • 供給者は Geomys LLC で、連絡担当者は Filippo Valsorda。関連ファイルとして Security Policy が提供されている

認証概要

  • Certificate #5247 は Go Cryptographic Module に対する Cryptographic Module Validation Program(CMVP) の認証項目
  • 標準は FIPS 140-3、状態は Active、全体のセキュリティレベルは Level 1 として登録されている
  • Sunset Date は 2031年4月26日 と表示されている
  • 検証履歴は 2026年4月27日 Initial で、試験機関は Lightship Security, Inc.

モジュール情報

  • Go Cryptographic Module は Go 標準ライブラリや他の Go アプリケーションに暗号機能を提供するソフトウェアライブラリ
  • Module Type は Software、Embodiment は MultiChipStand と表示されている
  • Security Level Exceptions は Physical security: N/A、Non-invasive security: N/A として登録されている

運用条件と制限

  • 認証は approved mode で運用される場合に適用される
  • 生成された SSPs、たとえば鍵については 最低限の強度保証はない と明記されている
  • 外部からロードされた SSPs、たとえば鍵やビット文字列、または外部ロード SSPs として設定された SSPs については 最低限のセキュリティ保証はない と明記されている

供給者と関連ファイル

  • Geomys LLC が供給者として登録されており、住所は 9450 SW Gemini Dr PMB 52960, Beaverton, OR 97008, United States
  • 連絡担当者は Filippo Valsorda と表示されている
  • Security Policy が関連ファイルとして提供されている

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Lobste.rsのコメント

  • かなり長い道のりだった。詳細は昨年の記事で読めるし、証明書に関する新しい記事もまもなく公開される予定。
    いつものことだが、FIPS 140-3が必要かどうかわからないなら、おそらく必要ない。しかし本当に必要なら、Goはそれを実現する最も簡単で安全な方法の1つだとかなり確信している。FIPS 140-3のルールを守りつつ、他のユーザーに提供してきたセキュリティと利便性を維持するのは特に難しかったが、かなりうまくやれたと思う

    • 特定の顧客環境でFIPS準拠が必要な大規模なbring-your-own-cloudデプロイを扱っているが、残念ながらGoはまったく使っていない。この変化がGo導入のきっかけになるかもしれない

  • GoはBoringSSLを使っているのでは？ それをどうやってFIPS認証したのか気になる

    • いや、それは以前の解決策だった。新しい方式は純粋なGo実装なので、CGOは不要: https://go.dev/blog/fips140
    • これまでFIPS準拠は、BoringSSLのソースツリーを使いつつOpenSSL向けにコンパイルする方式で可能だった。OpenSSLは準拠状態にあり、Red HatがRHELでそうしていて、私たちもすべてのワークロードでその方式に依存している。基本的には https://github.com/golang-fips/go と同じやり方。
      今回の新方式はすべてネイティブGoだ。もはやOpenSSLや他の回避策ではなく、単に標準ライブラリで解決できる

  • 実際にどんな結果が生まれるのか気になる。これでGoが一部の企業や組織にとってより魅力的な選択肢になるのか、それとも純粋にセキュリティ関連の変化なのか

    • セキュリティ面ではダウングレードだが、一部の政府環境で使えるようになる
    • これで米国の軍産複合体の契約企業が、より多くのGoプログラマーを雇って、それを基盤にソフトウェアを納入できるようになる
    • 全体としてはセキュリティにとってマイナス寄りだと慎重に見ている。(X)ChaCha20-Poly1305のような現代的な暗号が使えないため
    • 私たちの会社は商用製品と政府向け製品の両方を提供しているが、後者ではFIPSが必須要件だ。GoについてはRed Hatが正しく処理してくれることに依存しており、その結果どの環境でも使えるバイナリが得られる

  • いい話だ。以前、Red HatのFIPS版Goビルドを使ってデプロイしたことがあるが、FIPSに合わせるためにGoスタック全体を別バージョンにしなければならない点が常に気に入らなかった。
    米国政府に販売する多くの製品ではFIPSの利用が求められるし、FIPS版と非FIPS版を別々に作りたくないので、企業がGoを採用できるようになるという意味で大きい