第 21 章 インターネットキー交換
IP データグラムのセキュリティ保護された伝送に必要な IPsec SA (セキュリティアソシエーション) のキー情報の管理をキー管理といいます。 自動キー管理では、キーの作成、認証、および交換に通信のセキュリティ保護されたチャネルを要求します。Solaris オペレーティング環境では、インターネットキー交換 (IKE) を使用してキー管理を自動化します。IKE を使用すれば、セキュリティ保護されたチャネルを大量のトラフィックに割り当てるために容易にスケーリングできます。IPv4 パケットの IPsec SAでは、IKE の利点を生かすことができます。
この章では、以下の内容について説明します。
IKE の概要
インターネットキー交換 (IKE) デーモン in.iked(1M) では、保護された方法でセキュリティアソシエーションのキー情報のネゴシエーションと認証を行います。また、SunOSTM によって提供される内部機能からキーのランダムシードを使用します。IKE は、PFS (Perfect Forward Secrecy) をサポートしています。つまり、データ伝送を保護するキーを使用しないで追加キーを取得し、データ伝送のキーの作成に使用するシードを再利用しません。
IKE デーモンでリモートホストの公開暗号鍵が検出されると、ローカルシステムでは暗号鍵が検出されたリモートホスト宛てのメッセージを暗号化できます。IKE デーモンでは、そのジョブを交換と呼ばれる 2 つのフェーズで実行します。
フェーズ 1 交換
フェーズ 1 交換はメインモードといいます。フェーズ 1 交換では、IKE は公開鍵暗号方式を使用して、ピア IKE エンティティによる IKE 自体を認証します。その結果が ISAKMP (Internet Security Association and Key Management Protocol) セキュリティアソシエーションで、IKE で IP データグラムのキー情報のネゴシエーションを行うためのセキュリティ保護されたチャネルとなります。IPsec SA とは異なり、ISAKMP セキュリティアソシエーションは双方向であるため、1 つだけ必要です。
IKE でキー情報のネゴシエーションを行う方法は、フェーズ 1 交換で設定可能です。IKE では、/etc/inet/ike/config ファイルから設定情報を読み取ります。設定情報には、影響するインタフェース、使用するアルゴリズム、認証方式、および PFS 使用の有無が含まれています。認証方式には、事前共有鍵と公開鍵証明書の 2 つがあります。 公開鍵証明書は自己署名付きにするか、PKI (Public Key Infrastructure) ベンダーから 認証局 (CA) によって発行できます。 ベンダーには、iPlanetTM Certificate Management System、Entrust、および Verisign があります。
フェーズ 2 交換
フェーズ 2 交換はクイックモードといいます。フェーズ 2 交換では、IKE は IKE デーモンを実行するホスト間の IPsec SA を作成および管理します。また、フェーズ 1 で作成したセキュリティ保護されたチャネルを使用して、キー情報の伝送を保護します。IKE デーモンでは、乱数発生関数 (/dev/random) によってキーを作成してキーを一定の割合で更新し (構成可能)、キー情報を IPsec ポリシー構成ファイルで指定したアルゴリズムに提供します。
IKE のネゴシエーション
2 つの IKE デーモンがある場合、相互認証を行うには、有効な IKE 構成ポリシーファイル ike.config(4) とキー情報が必要です。 ポリシーファイルには、フェーズ 1 交換の認証に事前共有鍵または公開鍵証明書を使用するかどうかを決定する IKE ポリシーエントリが含まれています。
鍵のペア auth_method preshared は、事前共有鍵が使用されることを示します。auth_method の値が preshared 以外の場合には、公開鍵証明書が使用されることを示します。公開鍵証明書は自己署名付きにするか、PKI ベンダーから発行できます。
事前共有鍵の使用
事前共有鍵は、1 つのシステムの管理者によって作成され、通信するシステムの管理者とアウトオブバンドで共有します。管理者は、大量のランダム鍵の作成、そのファイルとアウトオブバンド伝送の保護に十分注意する必要があります。鍵は、各システムの /etc/inet/secret/ike.preshared ファイルに保存されます。IPsec の場合は ipseckeys ファイルですが、IKE の場合は ike.preshared(4) ファイルとなります。ike.preshared ファイルにある鍵に問題があると、その鍵から導出されるすべての鍵に問題が発生します。
1 つのシステムの事前共有鍵は、通信するシステムの鍵と同一にする必要があります。鍵は特定の IP アドレスに連結され、そのセキュリティ保護は管理者が通信するシステムを制御する場合に最も強化されます。
公開鍵証明書の使用
公開鍵証明書を使用すると、通信するシステムが秘密鍵情報をアウトオブバンドで共有する必要がなくなります。公開鍵では、鍵の認証とネゴシエーションに Diffie-Helman 方式を採用します。公開鍵証明書には、自己署名付きまたは認証局 (CA) による認証の 2 つの方法があります。
自己署名付き公開鍵証明書は、管理者によって作成されます。ikecert local -ks コマンドを実行して、システムの公開鍵と非公開鍵のペアの非公開部分を作成します。その後、管理者は通信するシステムから X.509 形式で自己署名付き証明書の出力を取得します。通信するシステムの証明書は、鍵のペアの公開部分の ikecert certdb コマンドに入力されます。自己署名付き証明書は、通信するホストの /etc/inet/ike/publickeys ディレクトリに保存されます。
自己署名付き証明書は、事前共有鍵と CA 間の中間ポイントになります。事前共有鍵とは異なり、自己署名付き証明書は移動体システムまたは再番号付け可能なシステムで使用できます。これを可能にするには、管理者は DNS (www.example.org) または EMAIL (root@domain.org) の代替名を使用します。
公開鍵は、PKI または CA ベンダーで配信できます。 公開鍵とそれに関連する CA は、管理者によって /etc/inet/ike/publickeys ディレクトリに格納されます。また、ベンダーは証明書無効リスト (CRL) も発行します。管理者は鍵と CA を格納するだけでなく、CRL を /etc/inet/ike/crls ディレクトリに格納する責任があります。
CA にはサイトの管理者ではなく、外部のベンダーによって認証されるといった特長があります。その点では、CA は公証された証明書となります。自己署名付き証明書と同様に、CA は移動体システムまたは再番号付け可能なシステムで使用できます。その一方、自己署名付き証明書とは異なり、CA は通信する多くのシステムを保護するために容易にスケーリングします。
IKE ユーティリティおよび IKE ファイル
この節では、IKE 構成ファイルと IKE を実装するさまざまなコマンドについて説明します。IPv4 ネットワークに IKE を実装する方法の手順については、IKE の実装 (作業マップ)を参照してください。
表 21–1 IKE ファイルおよび IKE コマンドのリスト|
ファイルまたはコマンド |
説明 |
|---|---|
|
in.iked(1M) デーモン |
インターネットキー交換 (IKE) デーモン。自動キー管理を有効にします |
|
ikeadm(1M) |
IKE 管理コマンド。IKE ポリシーの表示および変更に使用します |
|
ikecert(1M) |
認証データベース管理コマンド。ローカル公開鍵の認証データベースの操作に使用します |
|
/etc/inet/ike/config ファイル |
IKE ポリシー構成ファイル。 インバウンド IKE 要求のマッチングとアウトバウンド IKE 要求の準備に関するサイトの規則が含まれています。このファイルがある場合には、in.iked デーモンがブート時に自動的に開始します |
|
/etc/inet/secret/ike.preshared ファイル |
事前共有鍵のファイル。フェーズ 1 認証の秘密鍵情報が含まれています |
|
/etc/inet/secret/ike.privatekeys ファイル |
非公開鍵のディレクトリ。公開鍵と非公開鍵のペアの非公開部分が含まれています |
|
/etc/inet/ike/publickeys ディレクトリ |
公開鍵と証明書ファイルを保存するディレクトリ。デフォルトでは、Sun 証明書が含まれます公開鍵と非公開鍵のペアの公開部分が含まれています |
|
/etc/inet/ike/crls ディレクトリ |
公開鍵と証明書ファイルの無効リストを保存するディレクトリ |
IKE デーモン
in.iked(1M) デーモンを実行すると、Solaris ホスト上の暗号キーの管理が自動化されます。また、同じプロトコルを実行するリモートホストとのネゴシエーションを行い、認証されたキー情報が、保護された方法でセキュリティアソシエーションに提供されます。そのデーモンは、セキュリティ保護された通信を行うすべてのホストで実行する必要があります。IKE 構成ポリシーファイル /etc/inet/ike/config がある場合には、IKE デーモンがブート時に自動的にロードされます。
IKE デーモンを実行すると、システムではそのピア IKE エンティティに対してそのシステム自体を認証します (フェーズ 1)。そのピアは、認証方式として IKE ポリシーファイルに定義されています。その後、セッションのキーが設定されます (フェーズ 2)。 ポリシーファイルで指定した時間間隔で、IKE キーが自動的に更新されます。in.iked デーモンを実行すると、ネットワークからの着信 IKE 要求と PF_KEY ソケット経由の出力トラフィックの要求を待機します。詳細については、pf_key(7P) マニュアルページを参照してください。
2 つのプログラムで IKE デーモンをサポートします。ikeadm(1M) コマンドを実行すると、管理者は IKE ポリシーを表示および変更できます。 ikecert(1M) コマンドを実行すると、管理者は公開鍵データベース ike.privatekeys と publickeys を表示および管理できます。
IKE ポリシーファイル
IKE 構成ポリシーファイル/etc/inet/ike/config により、IKE デーモン自体のキー情報、およびそのデーモンが管理する IPsec SAのキー情報が提供されます。IKE デーモン自体は、フェーズ 1 交換でキー情報を要求します。ike/config ファイルにある規則に基づいてキー情報が設定されます。ポリシーファイルにある有効な規則にはラベルが含まれています。その規則により、キー情報を使用するホストまたはネットワークが特定され、認証方式が指定されます。有効なポリシーファイルの例については、IKE 作業を参照してください。そのパラメータの例と説明については、ike.config(4) のマニュアルページを参照してください。
IPsec SA は、IPsec 構成ポリシーファイル /etc/inet/ipsecinit.conf で設定されるポリシーに従って保護される IP データグラムで使用されます。 IKE ポリシーファイルにより、IPsec SA の作成時に PFS を使用するかどうかが決定されます。
ike/config ファイルのセキュリティについては、ipsecinit.conf ファイルのセキュリティと同様です。詳細については、セキュリティについてを参照してください。
IKE 管理コマンド
ikeadm コマンドを実行すると、IKE 構成ファイルの構文チェック、IKE デーモンプロセスの要素の表示、および IKE デーモンに渡すパラメータの変更を行うことができます。また、統計情報の収集、IKE プロセスのデバッグを行うこともできます。それらのオプションの例と詳細については、ikeadm(1M) のマニュアルページを参照してください。実行する IKE デーモンの権限レベルにより、表示および変更可能な IKE デーモンの要素が決まります。権限レベルは 3 つあります。
-
0x0 (基本レベル) — 権限の基本レベルでは、キー情報を表示または変更できません。 基本レベルは、in.iked デーモン実行時のデフォルトレベルになります。
-
0x1 (modkeys レベル) — 権限の modkeys レベルでは、事前共有鍵を削除、変更、または追加できます。
-
0x2 (keymat レベル) — 権限の keymat レベルでは、ikeadm コマンドを指定して実際のキー情報を表示できます。
ikeadm コマンドのセキュリティについては、ipseckey コマンドのセキュリティと同様です。 詳細については、セキュリティについてを参照してください。
事前共有鍵ファイル
/etc/inet/secret/ ディレクトリには、ISAKMP SA と IPsec SA の事前共有鍵が格納されています。管理者が共有鍵を手動で作成すると、ike.preshared ファイルには ISAKMP SA の事前共有鍵、ipseckeys ファイルには IPsec SA の事前共有鍵が格納されます。 secret ディレクトリは 0700 で、その中にあるファイルは 0600 で保護されています。
-
ike.config ファイルが事前共有鍵を要求したときに、管理者は ike.preshared ファイルを作成します。そのファイルには、ISAKMP SA (つまり、IKE 認証) のキー情報が含まれています。IKE では、フェーズ 1 交換の認証に事前共有鍵を使用するため、 in.iked デーモンの開始前に ike.preshared ファイルを有効にする必要があります。
-
ipseckeys ファイルには、IPsec SA のキー情報が含まれています。IPv6 ホストの場合、管理者はそのファイルにあるキーを手動で作成および更新します。そのファイルを手動で管理する例については、IPsec 作業を参照してください。IKE デーモンでは、このファイルを使用しません。IKE によって IPsec SA に対して生成されるキー情報は、カーネルに保存されます。
IKE 公開鍵のデータベースおよびコマンド
ikecert(1M) コマンドを実行して、ローカルホストの公開鍵データベースを操作します。IKE では、ike.config ファイルが公開鍵証明書を要求するときに、それらのデータベースを使用してフェーズ 1 交換を認証するため、in.iked デーモンを起動する前にそれらのデータベースを格納したディレクトリを生成する必要があります。 3 つのサブコマンド certlocal、certdb、certrldb をそれぞれ実行して、3 つのデータベースを処理します。
ikecert certlocal コマンド
certlocal サブコマンドを実行して、/etc/inet/secret/ike.privatekeys ディレクトリにある非公開鍵データベースを管理します。このサブコマンドを選択すると、非公開鍵の追加、表示、および削除を行うことができます。また、自己署名付き証明書または証明書要求のいずれかを作成できます。-ks オプションを選択すると、自己署名付き証明書が作成され、-kc オプションを選択すると、証明書要求が作成されます。
非公開鍵を作成する場合、certlocal サブコマンドに渡すパラメータは、次の表に示すように、ike.config ファイルに反映する必要があります。
表 21–2 ike certlocal の値と ike.config の値の対応表|
certlocal オプション |
ike.config エントリ |
注 |
|---|---|---|
|
-A 対象の代替名 |
cert_trust 対象代替名 |
証明書を一意に識別するニックネーム。指定可能な値は IP アドレス、電子メールアドレス、およびドメイン名です。 |
|
-D X.509 識別名 |
cert_root X.509 識別名 |
国、組織名、組織単位、共通名を含む認証局のフルネーム。 |
|
-t dsa-sha1 |
RSA よりもわずかに遅くなります。 特許は登録されていません。 |
|
|
-t rsa-md5 -t rsa-sha1 |
auth_method rsa_sig |
DSA よりもわずかに速くなります。 特許の期限切れは 2000 年 9 月です。 RSA 公開鍵は、最大ペイロードを暗号化できるようにその長さを十分長くする必要があります。一般的に識別名などの ID ペイロードが最大になります。 |
|
-t rsa-md5 -t rsa-sha1 |
RSA 暗号化により、IKE にある ID が不正侵入者から保護されますが、IKE ピアには互いの公開鍵の認識が要求されます。 |
ikecert certlocal -kc コマンドを指定して証明書要求を実行する場合、そのコマンドの出力をベンダーに送信します。その後、ベンダーがキー情報を作成します。certdb と certrldb のサブコマンドへの入力としてベンダーのキー情報を使用します。
ikecert certdb コマンド
certdb サブコマンドを実行して、公開鍵データベース /etc/inet/ike/publickeys を管理します。そのサブコマンドを選択すると、公開鍵と証明書を追加、表示、および削除できます。また、通信するシステムで ikecert certlocal -ks コマンドを実行して作成された証明書を入力として受け入れます。手順については、自己署名付き公開証明書による IKE の設定方法を参照してください。さらに、PKI または CA から受信する証明書も入力として受け入れます。手順については、認証局による署名付き公開鍵による IKE の設定方法を参照してください。
ikecert certrldb コマンド
certrldb サブコマンドを実行して、証明書無効リスト (CRL; Certificate Revocation List) データベース /etc/inet/ike/crls を管理します。crls データベースには、公開鍵の無効リストが保存されています。よって、このリストには、すでに有効でない証明書が明記されます。PKI によって CRL が提供されるときに、ikecert certrldb コマンドを指定して CRL データベースにそれらの CRL を格納します。手順については、証明書無効リストを更新する方法を参照してください。
/etc/inet/ike/publickeys ディレクトリ
/etc/inet/ike/publickeys ディレクトリには、公開鍵と非公開鍵のペアの公開部分とファイルにあるその証明書、つまり「スロット」が格納されています。 /etc/inet/ike ディレクトリは 0755 で保護されます。そのディレクトリに格納される公開鍵データベースは、 各国で読み取り可能です (0644)。 ikecert certdb コマンドを使用して、そのディレクトリを読み込みます。
そのファイルには、別のシステムで生成された証明書の X.509 識別名がコード化形式で含まれています。自己署名付き証明書を使用する場合、そのコマンドへの入力として、通信するシステムの管理者から受信する証明書を使用します。PKI からの証明書を使用する場合、ベンダーからこのデータベースに 2 つのキー情報 (ベンダーに送信した情報に基づいた証明書、およびベンダーからの CA) を格納します。
iPlanet CMS の評価コピー PKI は、インストールパッケージの Media Kit で使用できます。
/etc/inet/secret/ike.privatekeys ディレクトリ
ike.privatekeys ディレクトリには、公開鍵と非公開鍵のペアの一部である非公開鍵ファイル、ISAKMP SA のキー情報が格納されています。このディレクトリは 0700 で保護されています。このデータベースにある非公開鍵は、publickeys データベースの公開鍵とペアにする必要があります。ikecert certlocal コマンドを実行して、コマンドのディレクトリを読み込みます。非公開鍵は、ペアとなる公開鍵、自己署名付き証明書や CA が /etc/inet/ike/publickeys ディレクトリに格納されてから有効になります。
/etc/inet/ike/crls ディレクトリ
/etc/inet/ike/crls ディレクトリには、証明書無効リスト (CRL) ファイルが含まれています。各ファイルは、/etc/inet/ike/publickeys/ ディレクトリにある公開鍵証明書ファイルに対応しています。PKI ベンダーにより、それらの証明書の CRL が提供されます。ikecert certrldb コマンドを使用して、そのデータベースを読み込みます。
IKE の実装 (作業マップ)
ikeadm(1M)、ikecert(1M) と ike.config(4) のマニュアルページには、個別に例に応じた説明があります。
表 21–3 IKE の実装 (作業マップ)|
タスク |
説明 |
参照先 |
|---|---|---|
|
事前共有鍵による IKE の設定 |
有効な IKE ポリシーファイルと ike.preshared ファイルを作成します。 また、システムをブートして IKE によって生成された鍵を使用する前に、IPsec ファイルも設定します。 | |
|
実行中の IKE システムでの事前共有鍵の更新 |
IKE 権限レベルをチェックし、通信するシステムの最新キー情報に応じて ipseckeys ファイルを編集します。 | |
|
実行中の IKE システムへの事前共有鍵の追加 |
IKE 権限レベルをチェックし、通信するシステムの最新キー情報に応じて ikeadm コマンドを実行します。 | |
|
自己署名付き公開鍵証明書による IKE の設定 |
ikecert certlocal -ks コマンドを指定して自己署名付き証明書を作成し、ikecert certdb コマンドを指定して通信するシステムからの公開鍵を追加します。 | |
|
PKI 認証局による IKE の設定 |
ikecert certlocal -kc コマンドから PKI に出力を送信し、ベンダーから公開鍵、CA、CRL を格納します。 | |
|
CA 無効リストの更新 |
ikecert certrldb コマンドを指定して PKI ベンダーの CRL を格納します。 |
IKE 作業
この節では、IPv4 アドレスを使用する 2 つのシステム間でトラフィックを保護する鍵を自動的に管理する手順について説明します。IKE 実装では、鍵の長さが異なるさまざまなアルゴリズムが提供されます。鍵の長さは、サイトのセキュリティに応じて選択します。一般的に、鍵の長さが長いほど、セキュリティが高くなります。
事前共有鍵による IKE の設定方法
-
システムコンソールからスーパーユーザーになります。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
正常に実行するために、システムごとに、グローバルパラメータと ipsecinit.conf の IPsec ポリシーを有効にする規則を指定して /etc/inet/ike/configファイルを作成します。たとえば、次のように指定します。
### ike/config file on enigma, 192.168.66.1 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 2 # ## The rule to communicate with partym { label "Enigma-Partym" localid 192.168.66.1 remoteid 192.168.55.2 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg des } p2_pfs 5 }
### ike/config file on partym, 192.168.55.2 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 2 ## The rule to communicate with enigma { label "Partym-Enigma" localid 192.168.55.2 remoteid 192.168.66.1 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg des } p2_pfs 5 }
注 –システム名は一例として使用しているだけです。システム間でトラフィックを保護する場合には、各自のシステムの名前とアドレスを使用してください。
-
システムごとに、次のように指定してファイルが有効であるかどうかをチェックします。
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config
-
Solaris システムでは、od コマンドを使用できます。たとえば、次のように指定します。
# od -x </dev/random | head -4 0000000 df97 6d2f 4ef5 2c28 02d5 02aa f9de 481d 0000020 2ae8 b949 67e6 b9b0 dd16 e6d4 b7ea 7278 0000040 ac07 7cc6 99c1 7055 848a 3cf3 4377 980a 0000060 5ad7 5b40 b428 9f3a da20 7daa 65a4 83fe
-
システムごとに/etc/inet/secret/ike.preshared ファイルを作成し、各ファイルに事前共有鍵を書き込みます。
この例 (手順 2 を参照) では、暗号化アルゴリズムは DES であるため、事前共有鍵は少なくとも 64 ビットにする必要があります。 鍵の長さが長いほど、セキュリティが高くなります。たとえば、次のように指定します。
# ike.preshared on enigma, 192.168.66.1 { localidtype IP localid 192.168.66.1 remoteidtype IP remoteid 192.168.55.2 # enigma and partym's shared key in hex (128 bits) key ac077cc699c17055848a3cf34377980a }
# ike.preshared on partym, 192.168.55.2 { localidtype IP localid 192.168.55.2 remoteidtype IP remoteid 192.168.66.1 # partym and enigma's shared key in hex (128 bits) key ac077cc699c17055848a3cf34377980a }
注 –事前共有鍵は同一にする必要があります。
-
システムごとに、他のシステムのアドレスとホスト名を /etc/hosts ファイルに追加します。たとえば、次のように指定します。
partym という名前のシステムでは、次のように指定します。
# Secure communication with enigma 192.168.66.1 enigma
enigma という名前のシステムでは、次のように指定します。
# Secure communication with partym 192.168.55.2 partym
-
各システムごとに、次の行を追加して /etc/inet/ipsecinit.conf ファイルを編集します。
enigma システムでは、次のように指定します。
{laddr enigma raddr partym} ipsec {auth_algs any sa shared}partym システムでは、次のように指定します。
{laddr partym raddr enigma} ipsec {auth_algs any sa shared} -
各システムをリブートすることで、セキュリティ保護された通信を可能にします。
# /usr/sbin/reboot
既存の事前共有鍵を更新する方法
この手順では、既存の事前共有鍵を変更するものとします。3DES、AES、Blowfish などの強力な暗号化アルゴリズムを使用すると、両方のシステムのリブート時に備えて、鍵を変更するスケジュールを作成できる場合があります。この手順は、トラフィックの保護に DES などのアルゴリズムを使用するシステムに適用されます。
-
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ランダム鍵を生成してそれらのいずれか 1 つを選択します。
Solaris システムでは、od コマンドを使用できます。
# od -x </dev/random | head -2 0000000 305e c563 69ca 62c2 ae80 4690 c571 3e18 0000020 be43 9533 d50f ec49 c7fe cf3c 8f13 91c0
-
システムごとに /etc/inet/secret/ike.preshared ファイルを編集して、現在の鍵を新しい鍵に変更します。
たとえば、enigma と partym のホストでは、key の値を be439533d50fec49c7fecf3c8f1391c0 のような新しい番号に変更します。
-
in.iked デーモンがキー情報の変更を許可するかどうか確認します。
# /usr/sbin/ikeadm get priv Current privilege level is 0x2, access to keying material enabled
コマンドから 0x1 または 0x2 の権限レベルが戻された場合には、キー情報を変更できます。レベル 0x0 の場合には、キー情報を操作できません。デフォルトでは、in.iked デーモンは 0x0 の権限レベルで実行されます。
-
in.iked デーモンを実行してキー情報を変更できるようにするには、ike.preshared ファイルの新しいバージョンを読み取ります。
たとえば、次のように指定します。
# ikeadm read preshared
-
in.iked デーモンを実行してキー情報を変更できないようにするには、そのデーモンを消去してから再起動します。
そのデーモンを開始すると、ike.preshared ファイルの新しいバージョンを読み取ります。
# pkill in.iked # /usr/lib/inet/in.iked
新しい事前共有鍵を追加する方法
in.iked デーモンを実行するシステムでは、そのデーモンを呼び出した後に ipsecinit.conf ファイルに追加したインタフェースに対する事前共有鍵を追加できます。この手順では、両方のシステムの /etc/hosts ファイルと /etc/inet/ipsecinit.conf ファイルに新しいインタフェースをすでに追加し、各システムに ipsecinit.conf ファイルをまだ読み込んでいないものとします。
-
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
in.iked デーモンがキー情報の変更を許可するかどうか確認します。
# /usr/sbin/ikeadm get priv Current privilege level is 0x2, access to keying material enabled
コマンドから 0x1 または 0x2 の権限レベルが戻された場合には、キー情報を変更できます。レベル 0x0 の場合には、キー情報を操作できません。デフォルトでは、in.iked デーモンは 0x0 の権限レベルで実行されます。
-
in.iked デーモンを実行してキー情報を変更できないようにするには、そのデーモンを消去してから正確な権限レベルで開始します。
たとえば、次のように指定します。
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting priv/usr/lib/inet/in.iked -pilege level to 2!
-
ランダム鍵を生成してそれらのいずれか 1 つを選択します。
Solaris システムでは、od コマンドを使用できます。
# od -x </dev/random | head -2 0000000 2d86 b6f6 eb7a e8a9 3d83 58b2 cd17 4164 0000020 8be4 fea4 b456 933a 46dd 149a 0a10 b2e4
-
各システムで ikeadm コマンドを入力して、新しいキー情報を追加します。
たとえば、enigma システムではホスト nemesis 192.163.55.8 のキーを次のように追加します。
# ikeadm ikeadm> add preshared { localidtype ip localid 192.168.66.1 remoteidtype ip remoteid 192.163.55.8 ike_mode main key 2d86b6f6eb7ae8a93d8358b2cd174164 } ikeadm: Successfully created new preshared key.ホスト nemesis では、管理者は次のように同一の鍵を追加します。
# ikeadm ikeadm> add preshared { localidtype ip localid 192.163.55.8 remoteidtype ip remoteid 192.168.66.1 ike_mode main key 2d86b6f6eb7ae8a93d8358b2cd174164 } ikeadm: Successfully created new preshared key.
注 –Error: invalid preshared key definition というメッセージは、add preshared コマンドに入力ミスがあったか、パラメータが省略されたことを示しています。コマンドを正確に再入力して鍵を追加してください。
-
ikeadm コマンドモードを終了します。
ikeadm> exit #
-
システムごとに、in.iked デーモンの権限レベルを低くします。
# ikeadm set priv base
-
システムごとに、ipsecinit.conf ファイルを有効にして、追加したインタフェースを保護します。
# ipsecconf -a /etc/inet/ipsecinit.conf
注 –このコマンドの実行時には警告を読んでください。ソケットがすでに使用中 (ラッチされた) の場合には、システムへの背面ドアが保護されません。
自己署名付き公開証明書による IKE の設定方法
-
システムコンソールからスーパーユーザーになります。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ikecert certlocal -ks コマンドを使用して、自己署名付き証明書を ike.privatekeys データベースに追加します。たとえば、次のように指定します。
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=ExampleCompany, OU=US-Example, CN=Example" \ -A IP=192.168.10.242 Generating, please wait... Certificate: Certificate generated. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----
-
その証明書を、通信するシステムの管理者に送信します。
その証明書は、次のようにして電子メールにカット&ペーストできます。
To: root@us.example.com From: root@un.example.com Message: -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----
-
/etc/inet/ike/config ファイルを編集して、通信するシステムからの公開鍵を認識します。 たとえば、次のように指定します。
# Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.10.242" cert_trust "192.168.11.241" ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 5 { label "UN-Example to US-Example" local_id_type dn local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example" remote_id_type dn remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example" local_addr 192.168.10.242 remote_addr 192.168.11.241 p1_xform { auth_method rsa_encrypt oakley_group 2 auth_alg md5 encr_alg des } } -
通信するシステムの管理者と一緒にキーが改ざんされていないことを確認します。
たとえば、その管理者に電話で連絡して以下に示す公開鍵ハッシュの値を比較できます。
# ikecert certdb -l Certificate Slot Name: 0 Type: if-modn Subject Name: <C=US, O=ExampleCo, OU=UN-Example, CN=Example> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
other system # ikecert certlocal -l Local ID Slot Name: 1 Type: if-modn Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
注 –上記の公開鍵ハッシュは、使用しているシステムで生成される公開鍵ハッシュとは異なります。
認証局による署名付き公開鍵による IKE の設定方法
-
システムコンソールからスーパーユーザーになります。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ikecert certlocal -kc コマンドを使用して、信頼されたルート証明書を ike.privatekeys データベースに追加します。
たとえば、次のように指定します。
# ikecert certlocal -kc -m 1024 -t rsa-md5 \ -D "C=US, O=ExampleCompany\, Inc., OU=US-Example, CN=Example" \ -A "DN=C=US, O=ExampleCompany\, Inc., OU=US-Example" Generating, please wait... Certificate request generated. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----
-
その要求を外部の認証局または PKI に依頼します。
ベンダーは、各データベースに入力される 2 つの証明書と CRL を発行します。
-
公開鍵証明書 – この証明書はベンダーに依頼した要求に基づいて作成されます。この証明書によって一意に識別されます。
-
認証局 – ベンダーの署名です。CA によって公開鍵証明書が正規のものであることが確認されます。
-
証明書無効リスト – ベンダーが無効にした証明書の最新リストです。
-
-
ikecert コマンドで 3 つの証明書を引数として入力します。
-
システムコンソールからスーパーユーザーになります。
-
次のように ikecert certdb -a コマンドと <Return> を入力します。
# ikecert certdb -a <Return>
-
次のようにベンダーから受信した証明書をペーストして、 <Return> と入力します。
-----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Return>
-
<Control-D> を入力して入力を終了します。
<Control-D>
-
次のように ikecert certdb -a コマンドと <Return> を入力します。
# ikecert certdb -a <Return>
-
次のようにベンダーの CA をペーストして <Return> と入力してから、<Control-D> と入力して入力を終了します。
-----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Return> <Control-D>
-
次のように ikecert certrldb -a コマンドと <Return> を入力します。
# ikecert certrldb -a <Return>
-
次のようにベンダーの CRL をペーストして <Return> と入力してから、<Control-D> と入力して入力を終了します。
-
-
/etc/inet/ike/config ファイルを編集して、ベンダーを認識します。
ベンダーから利用するように通知された名前を使用します。たとえば、次のように指定します。
# Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg 3des } p2_pfs 2 { label "UN-Example to US-Example - Example PKI" local_id_type dn local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example" remote_id_type dn remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example" local_addr 192.168.10.242 remote_addr 192.168.11.241 p1_xform { auth_method rsa_encrypt oakley_group 2 auth_alg md5 encr_alg des } } -
今までと同じ操作を、通信するシステムでも実行します。
上記の例に従って "C=US, O=ExampleCompany, OU=US-Example, CN=Example" システムで ikecert コマンドを実行します。その ike.config ファイルでは、ローカルパラメータにはローカル情報、リモートパラメータには使用しているシステムの情報を使用します。
たとえば、次のように指定します。
# Trusted root cert # This certificate is from Example PKI cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg 3des } p2_pfs 2 { label "US-Example to UN-Example - Example PKI" local_id_type dn local_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example" remote_id_type dn remote_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example" local_addr 192.168.11.241 remote_addr 192.168.10.242 p1_xform { auth_method rsa_sig oakley_group 2 auth_alg md5 encr_alg des } }/etc/hosts ファイルと /etc/inet/ipsecinit.conf ファイルを変更して、保護されたインタフェースを組み込み、システムをリブートすると、IKE デーモンを実行して公開鍵と CA による IKE 自体の認証を行います。
注 –RSA 暗号化認証方式により、IKE の ID が不正侵入者から保護されるため、IKE ではピアの証明書を検出しません。したがって、その方式では、IKE ピアが互いの公開鍵を認識することが必要になります。よって、ike.config ファイルの auth_method rsa_encrypt を使用する場合には、ピアの証明書を公開鍵データベースに追加する必要があります。
証明書無効リストを更新する方法
- © 2010, Oracle Corporation and/or its affiliates