IPsec セキュリティーアソシエーション (SA) の鍵情報を管理することを「鍵管理」といいます。自動鍵管理には、鍵の作成、認証、および交換にセキュアな通信チャネルが必要です。Oracle Solaris では、インターネット鍵交換 (IKE) を使用して鍵管理を自動化します。IKE は、秘密鍵の手動配布に伴う管理オーバーヘッドとセキュリティーのリスクを排除します。
IKE では、ハードウェア暗号化アクセラレーションと鍵ストレージを利用できます。ハードウェア暗号化アクセラレータによって、CPU に負荷のかかる鍵操作をシステム外で処理できます。ハードウェア上での鍵の格納によって、保護機能が強化されます。
Oracle Solaris は、IKE プロトコルの 2 つのバージョンをサポートしています。
インターネット鍵交換プロトコルバージョン 2 (IKEv2)、RFC 5996 に基づく IKE バージョン 2 (IKEv2)
インターネット鍵交換 (IKE)、RFC 2409 に基づく IKE バージョン 1 (IKEv1)
FIPS 140-2 が有効化されたシステムでは、IKEv2 を FIPS 140-2 承認アルゴリズムのみで構成するようにしてください。詳細は、IKEv2 および FIPS 140-2を参照してください。
次の概念と用語は IKE の両方のバージョンに共通です。2 つのバージョンでは、異なる形で実装されている可能性があります。
鍵のネゴシエーションおよび交換 – セキュアな方法で行われる、鍵情報の交換およびピアの識別情報の認証。このプロセスでは非対称暗号化アルゴリズムを使用します。主な 2 つの方法は、RSA と Diffie-Hellman プロトコルです。
IKE は IKE デーモンを実行するシステム間の IPsec SA を作成および管理します。IKE は鍵情報の伝送を保護するセキュアなチャネルをネゴシエートします。デーモンは、/dev/random デバイスを使用して乱数発生関数から鍵を作成します。デーモンは、鍵を一定の割合 (構成可能) で変更します。この鍵情報は、IPsec ポリシーの構成ファイル ipsecinit.conf に指定されているアルゴリズムによって使用されます。
Diffie-Hellman (DH) アルゴリズム – セキュアでないチャネルで 2 つのシステムが共有シークレットをセキュアに生成できる鍵交換アルゴリズム。
RSA アルゴリズム – ピアシステムの識別情報の認証 (通常は X.509 証明書の所有権の提供による) に使用される非対称鍵アルゴリズム。アルゴリズム名は、作成者の Rivest、Shamir、Adleman の三氏に因んでいます。
Perfect forward secrecy (PFS) – PFS では、データ伝送を保護するために使用される鍵が、追加の鍵を導き出すために使用されることはありません。さらに、データ伝送を保護するために使用される鍵のソースが、追加の鍵を導き出すために使用されることはありません。したがって、PFS は以前に記録されたトラフィックの復号化を回避できます。
Oakley グループ – PFS のネゴシエーションに使用されます。インターネット鍵交換 (IKE) RFC のセクション 6 を参照してください。
IKE ポリシー – IKE デーモンがピアシステムとのセキュアな鍵交換チャネルの設定を試行する際に使用可能なパラメータを定義する IKE ルールのセット。これは、IKEv2 では IKE SA、IKEv1 ではフェーズ 1 と呼ばれます。
パラメータには、アルゴリズム、鍵のサイズ、Oakley グループ、および認証方式が含まれます。Oracle Solaris IKE デーモンは認証方式として事前共有鍵および証明書をサポートしています。
IKE デーモンを実行しているシステムは、このシステムと IKE デーモンを実行している別のシステムの間にセキュリティーアソシエーション (SA) を作成するのに必要なパラメータをネゴシエートできます。この SA および後続の IPsec SA のネゴシエーションに使用されるプロトコルは IKE と呼ばれます。Oracle Solaris のこのバージョンは、IKE プロトコルのバージョン 1 (IKEv1) およびバージョン 2 (IKEv2) をサポートしています。
IKE セキュリティーアソシエーション (IKEv1 では ISAKMP またはフェーズ 1 SA とも呼ばれる) は、これら 2 つの IKE システム間のさらなるプロトコル交換をセキュリティー保護します。これらの交換では、暗号化アルゴリズム、IPsec ポリシー、および IPsec SA の作成に必要なその他のパラメータをネゴシエートします。
IKE デーモンを実行しているシステムは、その他のシステムの代理として IPsec SA をネゴシエートするように構成することもできます。この方法で構成されたシステムは、セキュリティーゲートウェイと呼ばれます。IKE ネゴシエーションが成功すると、IPsec SA を使用してネットワークパケットを保護できます。
IKE SA を作成するためにネゴシエートされるパラメータには、IKE 交換および一部の認証情報を保護する暗号化アルゴリズムが含まれます。認証情報は、IKE プロトコル交換を含むパケットが信頼できるかどうかを判断するために使用されます。信頼とは、そのパケットが信頼できるシステムから来たもので、そのシステムになりすましているシステムから来たものではないことを意味します。
Oracle Solaris は、事前共有鍵と公開鍵証明書という 2 種類の IKE 認証情報をサポートしています。
事前共有鍵は、2 つの IKE システムのみが認識する 16 進数または ASCII 文字の文字列です。この鍵は、IKE 交換の前に両方のエンドポイントが鍵の値を認識している必要があることから、事前共有鍵と呼ばれます。この鍵は両方のシステムで IKE 構成に含まれている必要があります。事前共有鍵は IKE ペイロードの生成に使用され、IKE プロトコルを実装するパケットを作成します。これらの IKE ペイロードを処理するシステムは、受け取るペイロードの認証に同じ鍵を使用します。
事前共有鍵は、IKE エンドポイント間で IKE プロトコルを使用して交換されることはありません。通常、鍵は電話などの異なる媒体でピアシステムと共有されます。
この認証方法を使用するピアの事前共有鍵は同一である必要があります。鍵は各システム上のファイルに格納されます。
公開鍵証明書およびそれらのトラストチェーンが、秘密の情報を手動で交換することなくシステムをデジタルに識別するメカニズムを提供します。そのため、公開鍵証明書は事前共有鍵よりもセキュアです。
公開鍵証明書は、公開鍵の値、名前や署名者など証明書の生成に関する情報、証明書のハッシュまたはチェックサム、およびハッシュのデジタル署名をエンコードするブロブデータです。これらの値が一体となって証明書を形成します。デジタル署名は証明書が変更されていないことを保証します。
公開鍵は、非公開鍵と呼ばれる別の値から数学的に生成される値です。非公開鍵から公開鍵を生成する数学的アルゴリズムでは、公開鍵から非公開鍵を取得することはできません。そのため、公開鍵証明書は自由に共有できます。公開鍵の生成に使用されるアルゴリズムの例として、RSA および楕円曲線があります。
デジタル署名とは、RSA、DSA、ECDSA などのデジタル署名アルゴリズムによって証明書の内容を渡した結果です。これらのアルゴリズムは、証明書に含まれない非公開署名鍵を使用してデジタル署名を作成します。署名は証明書に追加されます。この場合も、証明書の内容および署名から署名鍵を計算することはできません。簡単に言うと、署名鍵から生成された公開値を使用して、証明書の署名、および証明書の内容を簡単に検証できます。
証明書は、自己署名することも (この場合、証明書の署名はその証明書の公開鍵で検証できる)、第三者が署名することもできます。第三者が証明書に署名する場合、証明書の検証に使用される公開鍵の値も公開鍵証明書として配布されます。この 2 つ目の証明書は、信頼される認証局 (CA)、または仲介者によって署名されます。この仲介者は最終的に署名機関、つまりルート CA またはトラストアンカーに信頼されます。
これら公開鍵証明書のコンポーネントとそれらを実装する手順および構造を合わせて、多くの場合、公開鍵インフラストラクチャー (PKI) と呼びます。組織の PKI の範囲は異なる場合があります。単純な PKI は、ローカル使用の少数の証明書に署名する CA で構成されていることがあります。より大きな PKI になると、グローバルに認知されているトラストアンカーを正式な CA として使用します。
このセクションでは、IKE での公開鍵証明書の作成および使用の全体的な手順を説明します。特定の手順については、事前共有鍵による IKEv2 の構成および 事前共有鍵による IKEv1 の構成を参照してください。
自己署名付き証明書または認証局 (CA) による証明書を使用するには、まず公開鍵/非公開鍵ペアを生成します。
自己署名付き証明書の場合は、次に IKE ピアがこれらの証明書を交換し、証明書が本物であることを帯域外で検証したあと、ピアの証明書をローカルのキーストアにインポートします。これにより、キーストアにオリジナルの自己署名付き証明書とインポートされた証明書が格納されます。
CA からの証明書の場合、さらにいくつかの手順を実行します。公開鍵/非公開鍵ペアを生成する際に、証明書署名要求 (CSR) も生成します。CSR には公開鍵および識別子が含まれています。一般的な識別子は、識別名 (DN)です。例:
DN=O=Example\, Inc, OU=qa, L=Silicon Valley, ST=CA, CN=enigma
署名のために CA に CSR を送信します。
一般的なプロセスでは、Web フォームに CSR を貼り付けて、そのフォームを CA に送信します。CA から複数の署名付き証明書が送信される場合があります。
CA から署名付き証明書を取得したあと、それらを IKEv2 キーストアまたは IKEv1 データベースにインポートします。
CA から送信されるすべての証明書をインポートする必要があります。これらの証明書は、トラストアンカー (ルート CA) から個々に識別される署名付き証明書への「トラストチェーン」で構成されます。
IKE ピアでこの手順を繰り返します。
IKE ルール内の証明書を使用します。
DN などの識別子で証明書を指定します。CA が署名する証明書の場合、特定の CA によって署名されている証明書を受け入れるように IKE を構成できます。
署名付き証明書は、署名機関がその有効性を保証するため、有効として信頼されます。証明書が損なわれた場合や無効と判断された場合は、CA によって取り消されます。
CA は、多くの場合証明書失効リスト (CRL) と呼ばれる失効した証明書のリストを保持しています。オンライン証明書ステータスプロトコル (OCSP) を使用して、証明書のステータスを動的に確認できます。一部の公開鍵証明書には URI が埋め込まれています。それらは CRL を確認できる Web の場所、または OCSP サーバーの Web の場所を識別します。
詳細は、RFC 2459: 証明書と CRL プロファイルおよび RFC 2560: オンライン証明書ステータスプロトコル - OCSP を参照してください。
公開鍵証明書には、発行日時および有効な残り時間が含まれています。そのため、証明書を生成および使用するシステム上のクロックが正確である必要があります。Network Time Protocol (NTP) ソフトウェアを使用して、システムのクロックを同期できます。Oracle Solaris のリリースにはデラウェア大学の NTP パブリックドメインソフトウェアが含まれています。ドキュメントは NTP ドキュメントの Web サイトで入手できます。service/network/ptp パッケージをインストールして高精度時間プロトコル (PTP) サービスを構成することもできます。ネットワーク接続された測定および制御システムの高精度時刻同期プロトコルのための IEEE 1588 規格を参照してください。
ルールごとに特定の IKE プロトコルバージョンの使用を要求することにより、対応する IKE 構成ルールを変更せずに IPsec ルールのみを変更できます。IPsec ルールに IKEv2 プロトコルを指定することは、旧バージョンの IKEv1 プロトコルから整然とシステムを移行する際に役立つ手順です。例については、使用例 29を参照してください。
次の表は、Oracle Solaris システムでの IKEv2 と IKEv1 のバージョンの実装を比較しています。
|