第3章 サポートされる標準およびプロトコル

Red Hat Certificate System は、可能な限りパフォーマンスと相互運用性を確保できるように、多くのパブリックプロトコルおよび標準プロトコル RFC に基づいています。本章では、Certificate System 9 で使用または対応している主な標準およびプロトコルについて、管理者がクライアントサービスを効果的に計画できるように、本章で概説しています。

3.1. TLS、ECC、および RSA

Transport Layer Security (TLS) プロトコルは、クライアントとサーバー間の認証と暗号化された通信の汎用的な標準です。クライアントとサーバーの認証は TLS 上で行われます。
TLS は、公開鍵と対称鍵の暗号化の組み合わせを使用します。対称キーの暗号化は公開鍵の暗号化よりもはるかに高速ですが、公開鍵の暗号化を使用すると認証の手法が向上します。TLS セッションは常に、ハンドシェイク と呼ばれるメッセージの交換で開始します。これはサーバーとクライアント間の初期通信です。ハンドシェイクにより、サーバーは公開鍵技術を使用してクライアントに対して自己認証を行い、必要に応じてクライアントがサーバーに対して認証できます。次に、クライアントとサーバーは、以下に示すセッション中に迅速な暗号化、復号、および整合性の検証に使用される対称鍵の作成において連携できるようになります。
TLS は、サーバーやクライアントの認証、証明書の送信、セッション鍵の確立などのさまざまな暗号化アルゴリズム (暗号) をサポートします。クライアントとサーバーは、異なる暗号スイートまたは暗号のセットをサポートする場合があります。その他の機能に加えて、ハンドシェイクは、サーバーおよびクライアントが相互に認証に使用される暗号スイートをどのようにネゴシエートし、証明書を送信し、セッションキーを確立する方法を決定します。
RSA や EllipticCurve Diffie-Hellman (ECDH) などの鍵交換アルゴリズムは、サーバーとクライアントが TLS セッション中に使用する対称鍵を決定する方法を管理します。TLS は ECC (Elliptic Curve Cryptography) 暗号化スイートおよび RSA に対応します。Certificate System は、RSA と ECC の両方の公開鍵暗号システムをネイティブにサポートします。
より最近の実施では、鍵交換アルゴリズムは、安全な通信のための共通の鍵を確立するときに、2 人以上の当事者のそれぞれが結果に影響を与える可能性がある 鍵共有プロトコルに取って代わられています。キー合意は、PFS (Perfect Forward Secrecy) の実装を許可するため、鍵交換が推奨されます。PFS を使用する場合、鍵共有の目的で、非決定論的アルゴリズムによってセッションごとにランダムな公開鍵 (一時暗号パラメーターまたは 一時鍵 とも呼ばれます) が生成されます。その結果、複数のメッセージの不正使用につながる秘密の値がなく、過去や今後の通信量は保護されません。
注記
コンピューティング機能が向上するのに合わせてセキュリティーを提供するには、より長い RSA キーが必要です。推奨される RSA 鍵の長さは 2048 ビットです。多くのサーバーは 1024 ビット鍵を使用しますが、サーバーは少なくとも 2048 ビット鍵に移行する必要があります。64 ビットマシンの場合は、より強力なキーの使用を検討してください。すべての CA は、可能であれば 2048 ビット鍵と、より強力な鍵 (3072、4096 ビットなど) を使用する必要があります。

3.1.1. サポート対象の暗号スイート

暗号化およびハッシュアルゴリズムは、さまざまな脆弱性とセキュリティー強度に関して絶えず変化しています。原則として、Red Hat Certificate System 9 は NIST ガイドライン に従い、サーバーキーに関連する TLS 1.1 および TLS 1.2 暗号スイートをサポートします。