RHEL7 コア暗号化コンポーネント

はじめに

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

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

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

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

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

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

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

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

提供されたコンポーネントの一貫性は?

当社は、オペレーティング システムで多数の暗号化ライブラリーを提供しているにもかかわらず、一貫した設定が全体に適用されるようにしています。特に、これらのコンポーネントのいずれも、セキュアでない、または陳腐化しているとみなされるアルゴリズムやプロトコルをデフォルトで有効化しないように徹底し、インターネット PKI での証明書の検証のために、それらが 同じルート CA 証明書のセットを共有 することを確認しています。ルート CA 証明書の共通セットは、Mozilla トラストストアをベースとして作成されます。

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

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

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

RHEL では、アプリケーションに対して透過的な方法でこれらのハードウェアセキュリティーモジュールをサポートするよう努めています。次のコアライブラリーは、API で HSM とスマート カードのサポートを提供し、その下で PKCS#11 インターフェイスを使用しています。

RHEL でサポートされているスマートカードの詳細については、この記事を参照 してください。

暗号認定

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

認定が重要な理由

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

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

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

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

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

• RHEL コモン クライテリア FAQ
• RHEL リリースの認定一覧
• RHEL リリースが準拠している政府基準

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

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

Red Hat Enterprise Linux FIPS140-2 の認定頻度は?

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

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

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

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

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

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

RHEL における FIPS140-2 要件への対処

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

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

システムを FIPS140-2 モードに切り替える場合は、RHEL セキュリティーガイドで FIPS モードの有効化 を参照してください。

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

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

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

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

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

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

RHEL におけるその他の暗号ライブラリー

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

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

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

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

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

RHEL における量子コンピューターの脅威への対処

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

その他の参考資料

• Red Hat Enterprise Linux 8 暗号コンポーネント