Translated message

A translation of this page exists in English.

RHEL コア crypto コンポーネント

更新 -

はじめに

Red Hat Enterprise Linux では、暗号化ソフトウェアは特別に扱われます。なぜなら、多くの場合で暗号化ソフトウェアの実装は簡単ですが、正しく行うことが非常に難しく、今後も関連性と最新の状態を維持することはさらに困難だからです。その理由は次のとおりです。暗号化ソフトウェアは、絶えず拡大する脅威モデルから保護することが期待されています。たとえば、元々は攻撃者によるネットワーク盗聴を阻止するために設計されたソフトウェアは、現在、攻撃者と同じ CPU を共有する仮想マシンやコンテナーなどの環境下で同じセキュリティー保証を提供することが期待されています。また、複雑なシステムのリモートアクセスインターフェイスは暗号化の実装に依存するため、暗号化ソフトウェアがシステムのエントリーポイントになっています。

そのため、暗号化ソフトウェアは、最新の脅威モデルを反映するように継続的に更新されるだけでなく、前述の脅威に素早く対応できるように十分にシンプルで設定可能である必要があります。

そこで RHEL では、攻撃対象領域を減らし、新しい要件に迅速に対応できるように、比較的小さな暗号化コアを提供し、その上にさまざまな言語のフックを備えています。暗号化コアは、当社の ABI および API 保証 に基づき、徹底的なテストを受け、国内および国際標準の認証プログラムによる検証を頻繁に受けています。

RHEL のコア暗号化コンポーネントは?

RHEL 暗号化コアは、低レベルの暗号化アルゴリズム (暗号、ハッシュ、メッセージ認証コードなど)、暗号的にセキュアなランダム ジェネレーター、および TLS や SSH などのセキュアな通信プロトコルの実装を提供する次のコンポーネントで構成されています。

コンポーネント FIPS-140 暗号モジュール 説明
OpenSSL ◯ TLS および DTLS 実装を含む汎用暗号化ツールキットライブラリー
GnuTLS ◯ 使いやすい TLS および DTLS の実装を重視した暗号化ツールキット
NSS ◯ Firefox ESR のライフサイクルに従い非同期更新と機能の有効化または削除が行われる Firefox ブラウザーの暗号化ツールキットライブラリー
libgcrypt ◯ GnuPG 暗号化ライブラリー
kernel ◯ Linux カーネルの内部暗号化ライブラリー
OpenSSH ×: FIPS-140-2 関連の暗号化を実装せず、OpenSSL モジュールを使用します オペレーティング システムの SSH クライアントとサーバーアプリケーション
libssh ×: FIPS-140-2 関連の暗号化を実装せず、OpenSSL モジュールを使用します SSH プロトコルを実装したセキュア通信ライブラリー
Libreswan ×: FIPS-140-2 関連の暗号は実装しておらず、NSS モジュールを使用しています オペレーティング システムの IPsec クライアントとサーバーアプリケーション

上記のコンポーネントによって提供される暗号プリミティブは、セキュアな方法で使用することが難しい点に注意してください。セキュリティープロトコルのカスタム実装は避けるべきです。ネットワーク伝送の機密性と完全性を保護するために、TLS プロトコル、または該当する場合は SSH および Kerberos プロトコルなどの標準化されたプロトコルの使用をお勧めします。

より高いレベルの環境で推奨される暗号化コンポーネントは?

次の表は、高レベルの環境と言語でのセキュアな通信と暗号化コンポーネントに関する推奨事項をまとめたものです。

環境 推奨 API/コンポーネント 依存関係
Apache httpd mod_ssl openssl
GNOME glib-networking gnutls
Go crypto.go openssl (FIPS140 モード時)
Java javax.crypto
Node.js 暗号、TLS openssl
Perl IO::Socket::SSL,Net::SSLeay openssl
Python python-cryptography、python ssl openssl
Ruby OpenSSL openssl

提供されるコンポーネントの一貫性や統合性はどうでしょうか?

弊社は、オペレーティング システムで多数の暗号化ライブラリーを提供しているにもかかわらず、一貫した設定が全体に適用されるようにしています。特に、すべてのコンポーネントが 安全で一貫した暗号化ポリシー に従っていること、インターネット PKI における証明書の検証のために、同じルート CA 証明書のセットを共有して いることを確認します。ルート CA 証明書の共通セットは、Mozilla トラストストアをベースとして作成されます。

RHEL 8 では、システム全体の暗号化ポリシーを導入 し、オペレーティングシステムを最新の課題に対応させることができました。システムの使い捨て化が進む中、管理者は短命なアプリケーションや長命なアプリケーションの微調整に時間を費やすこともなく、アプリケーションが使用しているバックエンドを正確に把握し、適切に設定する必要もありません。そのため、使用中のバックエンドに関係なく、オペレーティング システムで一貫した設定を提供します。アルゴリズムやプロトコルの一貫性、業界標準への準拠、セキュリティーと相互運用性のバランスの良さをデフォルトで保証しています。システム全体の設定は、update-crypto-policies コマンドを使用して制御できます。

暗号化ランダムジェネレーターへの推奨アクセス方法を教えてください。

アプリケーションから CSPRNG にアクセスするには、暗号ライブラリーを使用しない場合に限り、カーネルの getrandom() インターフェイスを使用することが推奨されます。アプリケーションがすでに弊社のコア暗号ライブラリーに依存している場合、そのライブラリーの提供するインターフェイスを使用することをお勧めします。詳細については、Red Hat Enterprise Linux のランダムジェネレーターインターフェイスが このブログポストで詳しく 説明されています。

推奨されるハードウェアセキュリティーモジュールとスマートカードの使用方法は?

ハードウェアセキュリティーモジュール (HSM) を使用すると、アプリケーションのアドレス空間の外に秘密鍵を置くことができます。秘密鍵の分離アプローチは、システムセキュリティーに深層防御の原則を実装し、攻撃の余波でアプリケーションコードの問題がコストのかかる回復プロセスにつながることを防ぎます (例: ハートブリード攻撃 を参照してください)。

通常、ハードウェアセキュリティーモジュールとスマートカードは、業界標準の PKC S#11 インターフェイスを介してアクセスされます。すべての HSM には、アプリケーションによって使用されるインターフェイスを実装する共有ライブラリーが付属しています。

RHEL 8 では、p11-kit と pkcs11.conf(5) を使用して、HSM とその他の PKCS #11 モジュールをシステム全体で登録することを導入しました。これにより、Apache、OpenSSH、wget、curl などのコア暗号モジュールに依存するアプリケーションは、HSM とスマートカードを使用するための追加設定が不要になります。さらに、HSM や HSM 内に格納されたオブジェクトを識別するための PKCS #11 URI (RFC7512) をオペレーティングシステム全体で標準化し、すべての RHEL アプリケーション設定ファイル内でオブジェクトが一貫して参照されるようにしました。

コンポーネント 説明
NSS ライブラリー API のネイティブ PKCS #11
GnuTLS 公開鍵操作用ライブラリー API のネイティブ PKCS #11
OpenSSL openssl-pkcs11 コンポーネント (engine_pkcs11) を通して PKCS #11 のサポートを提供します。

サポートされるスマートカードの詳細は、Smart Card support in RHEL 8+ KB の記事を参照してください。

暗号認証

当社は、Red Hat Enterprise Linux を最新のコミュニティー機能拡張と機能を含む最新のオペレーティング システムにするよう努めていますが、同時に、導入するセキュリティー面の最重要機能については保守的であろうとしています。私たちの目標は、国際標準だけでなく、業界のベストプラクティスに従って、試行錯誤されたプロトコルとアルゴリズムを提供する暗号化コンポーネントを提供することです。

認定が重要な理由

認定はオープンソースコミュニティーに関係ないと思われがちですが、具体的な要件から一歩下がって見渡せば、既存の認定には以下の原則に関するものだとわかります。

  • 暗号実装のユニットテスト
  • 暗号とアプリケーションコードの論理的な分離
  • 保守的な暗号プリミティブへの依存

どちらのアルゴリズムがより保守的または強力であるかなど、特定の詳細については意見が分かれるかもしれませんが、これらの高レベルの原則は、長期間にわたって関連性を維持することを目的としたソフトウェアにとって重要です。認定プロセスにより、複雑な実装レビューを経ることなく、暗号化ソフトウェアの一連のプロパティーを「証明」できます。

どのような認定があり、何が対象か?

Red Hat Enterprise Linux の暗号化コンポーネントは、FIPS140-2 およびコモンクライテリア認定を受けています。特定の認定の詳細については、以下の記事を参照してください。

暗号化コンポーネントの認定では、必ず以下がカバーされています。

  • 暗号化アルゴリズム API (AES、SHA2-256、RSA など)
  • 暗号化プロトコル API (SSH、TLS など)

すべてのコア暗号コンポーネントのcompat-openssl10 や compat-openssl11 などの後方互換性のために提供されるコンポーネントは、認証を受ける必要がありません。

Red Hat Enterprise Linux の FIPS-140-2 認証はどの程度の頻度で取得されていますか?

Red Hat は、最初のマイナーリリースから Red Hat Enterprise Linux 8 以降のすべてのマイナーリリースを FIPS 140-2 で認証する意向です。完了済みおよび進行中の認定に関する最新の FIPS 認定ステータスは、Red Hat Government Standards ページ に掲載されています。

標準のセキュアではないアルゴリズムは?

国内または国際標準にセキュアではないアルゴリズムが含まれることはあまりありませんが、長い間、アルゴリズムの選択基準、特定のパラメーターの選択方法、含まれている脆弱なアルゴリズムの明らかな例については疑問視されてきました。 しかし、相互運用性とセキュリティーの両面で標準がシステムに与えるプラスの影響を考えると、標準と標準化団体が存在することの重要性を損なうものではありません。ただし、標準を批判的な目で見る必要性は強調されるべきです。

さらに、これらの問題のいずれもオペレーティングシステムに影響を与えなかったのは、そのような標準が 1 つの特定のアルゴリズムまたはソリューションを課すことはめったにないからです。多くの場合、受け入れ可能なさまざまなアルゴリズムまたはプロトコルを提供します。たとえば、FIPS 140-2 標準では、ランダムジェネレーターに複数のオプションが用意されています。このような場合、当社ではオペレーティング システムの認定を確保するために、学術界や他の暗号コミュニティーで疑問視されているアルゴリズムの受け入れ状況、性能と適合性の分析、他分野の専門家による意見などのさまざまな要因に基づき、独自の判断を行います。

セキュリティーにおける脆弱性への対処

Red Hat Enterprise Linux のコンポーネントは、認定ステータスに関係なく、セキュリティー上の脆弱性に対処するために常に更新されます。認定は、検証された特定のコンポーネントバージョンに関連付けられているため、ガイドラインによって検証済みのコンポーネントバージョンを使用する必要がある組織においては問題が発生する可能性があります。 このような事実は NIST などの認証機関にとって既知の問題であり、協力して対処していますが、当社としては脆弱性に対処するためにシステムの更新が不可欠であると主張しています。

RHEL は FIPS-140-2 要件をどのように扱っていますか?

(How RHEL 8 is designed for FIPS-140-2 requirements で、より詳細な記事もご覧ください。)

FIPS 140-2 要件は、サーバーの通常の使用には制限が厳しすぎます。たとえば、特定のキーサイズとキージェネレーターのみが許可され、必要に応じてより大きなキー サイズに切り替えることができません。そのため、デフォルトでは RHEL のアプリケーションはこのモードでは動作しません。

システム全体で FIPS モードを提供し、コア暗号化コンポーネントを対応する FIPS 140-2 モードに切り替えています。このモードでは、コア コンポーネントでランダム生成、必要時の電源投入、継続的なセルフテストが有効になっています (詳細は、次のセクションの を参照してください)。

RHEL 8 では、fips-mode-setup コマンドの導入により、FIPS モードへの切り替え方法が大幅に簡略化されました。管理者は、次のコマンドを使用してシステムを FIPS モードに切り替えることができます。

# fips-mode-setup --enable

詳細は、RHEL Security 強化のドキュメントの Switching system to FIPS mode のセクションを参照してください。

ただし、FIPS モードへの切り替えは、RHEL にシステムをインストールしたり、アプリケーションを設定したりする前に行う必要があります。そうしなければ、ソフトウェアが未知の環境で動作し、誤動作する可能性があります。

アプリケーションの FIPS140-2 準拠状況は?

RHEL でアプリケーションが FIPS 140-2 に準拠していることを確認するには、アプリケーション作成者が、依存しているコア暗号化コンポーネントのセキュリティーポリシーの「ガイダンス」セクションに従う必要があります。すべての暗号モジュールのセキュリティーポリシーは、コンポーネントの証明書のガイドとして、RHEL における FIPS 140-2 準拠のパッケージ要件 ページで使用できます。

次の段落では、FIPS140-2 モードのコア暗号コンポーネントに関する詳細情報を提供します。これは、RHEL で実行することを目的としたアプリケーションの非公式な経験則として機能します。

RHEL 暗号コアは、アプリケーションのコンプライアンスに必要な作業量を最小限に抑えるように設計されています。アプリケーションが当社のコア暗号コンポーネントまたは推奨されるラッパーを利用し、その開発が業界のベストプラクティス (CII ベストプラクティス、TLS に関する IETF の推奨事項 など) に従っている場合、RHEL FIPS140-2 モードでスムーズに動作することが想定されます。

アプリケーションの動作とそのコンプライアンスは、アプリケーションが使用する基本コンポーネントにより異なります。次の表は、FIPS モードでのコアライブラリーの動作をまとめたものです。

コンポーネント FIPS モードでの動作
OpenSSL 非承認アルゴリズムはブロックされる。アプリケーションは特別なフラグ (*NON_FIPS_ALLOW) を使用することにより、FIPS-140 で許可されていないアルゴリズムを使用することができる。
GnuTLS 承認されていないアルゴリズムはブロックされます。アプリケーションは、gnutls_fips140_set_mode 関数により、FIPS-140 で許可されていないアルゴリズムを使用することができます。
NSS アプリケーションは、承認されていないアルゴリズムの使用を回避することが想定されます。
libgcrypt アプリケーションは、RHEL 8 において承認されていないアルゴリズムの使用を開始することが想定されています (承認されていないアルゴリズムを使用すると、コンポーネントが非準拠モードに切り替わります)。RHEL 9 では、対称暗号モードと KDF を除き、承認されていないアルゴリズムがブロックされます。アプリケーションは、gcry_control API を使用して、暗号とモードの組み合わせまたは KDF が承認されているかどうかを問い合わせることができます。
kernel (AF_ALG) 承認されていないアルゴリズムはブロックされます。

RHEL のアプリケーションは、暗号のコアコンポーネントに依存しているのでしょうか?

Red Hat Enterprise Linux 8 以降のコンポーネントは、コア暗号コンポーネントに依存しています。FIPS-140-2 Validated cryptography を使用しない既知のアプリケーションは、この記事でリストアップ されています。

RHEL の他の暗号化ライブラリーはどうですか

Red Hat Enterprise Linux には、コア暗号コンポーネントの代替がいくつか含まれています。これらは、以下で説明する 2 つのカテゴリーに分類されます。推奨されるコア暗号コンポーネントの使用方法に関する セクション で言及されていない限り、これらのカテゴリーに分類されるコンポーネントの使用は推奨されず、さまざまな認定要件への準拠も不明です。

内部実装と見なされる低レベル コンポーネント

一部のコンポーネントは、不安定な API または ABI インターフェイス を提供する低レベル API のみを提供するか、FIPS 140-2 などのポリシー要件 (起動チェックなど) を満たすことができま　せん。このようなコンポーネントの例は、RHEL においては GnuTLS の内部コンポーネントと見なされる nettle です。

コア暗号コンポーネントをラップする高レベルコンポーネント

主に歴史的な理由から、コア暗号ライブラリーを環境 (たとえば python などの言語) 上でラップするコンポーネントはほとんどありません。これらは人気があるため RHEL で出荷されますが、セキュリティーポリシーに基づくコア暗号ライブラリーの使用状況などをはじめとするコンプライアンスステータスは不明です。このコンポーネントの例は、OpenSSL をラップする m2crypto です。

量子コンピューターの脅威は RHEL でどのように処理されますか?

量子コンピューターは今後数十年で既存の暗号システムに重大な脅威をもたらすと予想されており、RHEL 暗号コアも例外ではありません。従来の暗号システムをポスト量子安全アルゴリズムに置き換えるという課題には、いくつかの物流コストが伴います。これは、代替アルゴリズムの提供に限定されず、そのようなアルゴリズムと古い暗号システムのインプレース置換で起こりうる障害への対処、これらのアルゴリズムを広く受容されている標準として確立してセキュアな通信プロトコルに組み込むことまで含まれます。これは業界全体の取り組みであり、現在は第 1 段階である代替アルゴリズムの選択に取り組んでいます。それに向けて、NIST のポスト量子コンペティション など、標準化団体の活動を注視しています。さらに、量子コンピューターの脅威に対する短期的な緩和策として、オペレーティングシステムのコア暗号コンポーネントが、従来の暗号システムで事前共有キーと大きなキーサイズを使用して適切に動作するよう徹底しています。

その他の参考資料

Comments