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 を使用してネットワークパケットを保護できます。
FIPS 140-2 検証済みの暗号化の使用のみを認める厳密な要件がある場合は、Oracle Solaris 11.1 SRU 5.5 リリースまたは Oracle Solaris 11.1 SRU 3 リリースを実行している必要があります。Oracle は、これら 2 つのリリースの暗号化フレームワークに対する FIPS 140-2 の検証を完了しました。Oracle Solaris 11.2 は、この検証済みの基盤の上に構築され、パフォーマンス、機能、および信頼性に対処するソフトウェアの改良を含んでいます。これらの改良を活かすため、可能な場合はいつでも Oracle Solaris 11.2 を FIPS 140-2 モードで構成するようにしてください。
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 規格を参照してください。