第 4 章 インターネットキー交換 (手順)
この章では、IKE の実装手順について説明します。使用するシステムのために構成された IKE は、そのネットワークにおける IPsec のキー情報を自動的に生成します。IKE の実装手順を 表 4–1 に示します。
IKE の概要については、第 3 章「インターネットキー交換 (概要)」を参照してください。ikeadm(1M)、ikecert(1M)、ike.config(4) の各マニュアルページの「EXAMPLES」セクションには、有益な手順が記載されています。
IKE の実装 (作業マップ)
表 4–1 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 無効リストの更新 |
一元的なディストリビューションポイントを通して PKI 機関の CRL にアクセスする | |
|
IKE に対する Sun Crypto Accelerator 1000 カードの使用 |
このデバイスのために PKCS#11 ライブラリへのパスを設定する |
IKE 作業
この節では、IPv4 アドレスを使用する 2 つのシステム間でトラフィックを保護する鍵を自動的に管理する手順について説明します。IKE 実装では、鍵の長さが異なるさまざまなアルゴリズムが提供されます。鍵の長さは、サイトのセキュリティに応じて選択します。一般的に、鍵の長さが長いほど、セキュリティが高くなります。
役割の使用方法については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (手順)」を参照してください。
事前共有鍵による IKE の設定方法
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
システムごとに、/etc/inet/ike/config.sample ファイルを /etc/inet/ike/config にコピーします。
-
システムごとに、規則とグローバルパラメータを ike/config ファイルに入力します。
これらの規則やグローバルパラメータは、システムの ipsecinit.conf ファイルに設定されている IPsec ポリシーが正しく動作するものでなければなりません。次の ike/config の例は、2 つのシステム間のトラフィックを保護する方法の ipsecinit.conf の例に対応しています。
-
たとえば、enigma システムの /etc/inet/ike/config ファイルを次のように変更します。
### ike/config file on enigma, 192.168.116.16 ## 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 des } p2_pfs 2 # ## The rule to communicate with partym { label "Enigma-Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des } p2_pfs 5 }
注 –auth_method のすべての引数は同じ行になければなりません。
-
partym システムのファイルを次のように変更します。
### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma { label "Partym-Enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des } p2_pfs 5 }
注 –システム名は一例として使用しているだけです。実際にシステム間のトラフィックを保護する場合には、各自のシステムの名前とアドレスを使用してください。
-
-
システムごとに、次のように指定してファイルが有効であるかどうかをチェックします。
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config
-
Solaris システムでは、od コマンドを使用できます。たとえば、次のコマンドを入力すると、16 進数の数値が 2 行に渡って表示されます。
# od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067dコマンドの説明については、乱数を生成する方法と od(1) のマニュアルページを参照してください。
-
システムごとに /etc/inet/secret/ike.preshared ファイルを作成します。各ファイルに事前共有鍵を書き込みます。
この例の認証アルゴリズムは MD5 です (手順 3 を参照)。事前共有鍵として推奨する最小のサイズは、ハッシュのサイズ (つまり、認証アルゴリズムの出力のサイズ) で決まります。MD5 アルゴリズムの出力は 128 ビットすなわち 32 文字です。鍵の長さは長いほうがよいので、この例の鍵の長さは 56 文字にします。
-
たとえば、enigma システムの ike.preshared は次のようになります。
# ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e } -
partym システムの ike.preshared は次のようになります。
# ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }
注 –事前共有鍵は同一にする必要があります。
これで、IKE は IPsec で使用できるように構成されました。
-
例 — 事前共有鍵が同一であるか検査する
通信する各システムの事前共有鍵が同一でない場合は、次のエラーメッセージが表示されます。
# rup system2 system2: RPC: Rpcbind failure |
事前共有鍵を表示するためには、in.iked デーモンが特権レベル 0x2 で動作していなければなりません。システムごとに、ikeadm コマンドを次のように実行して、事前共有鍵の情報をダンプします。
# /usr/sbin/ikeadm get priv Current privilege level is 0x2, access to keying material enabled # ikeadm dump preshared PSKEY: Pre-shared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym). |
両方のダンプを比較します。両者の事前共有鍵が同じでない場合は、/etc/inet/secret/ike.preshared ファイルで、一方の鍵を他方の鍵で置き換えます。
既存の事前共有鍵を更新する方法
この手順では、リブートすることなく、一定の間隔で既存の事前共有鍵を置き換えたい場合を想定しています。3DES や Blowfish などの強力な暗号化アルゴリズムを使用するときは、両方のシステムのリブート時に鍵を変更するようスケジュールしたほうがよい場合もあります。
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ランダム鍵を生成して、それらのいずれか 1 つを選択します。
Solaris システムでは、od コマンドを使用できます。たとえば、次のコマンドを入力すると、16 進数の数値が 2 行に渡って表示されます。
# od -X -A n /dev/random | head -2 03efe016 216e60ac e316f663 a2f073e0 7f90d069 316d99b5 00f8384c 2142610aコマンドの説明については、乱数を生成する方法と od(1) のマニュアルページを参照してください。
-
システムごとに /etc/inet/secret/ike.preshared ファイルを編集して、現在の鍵を新しい鍵に変更します。
たとえば、ホスト enigma と partym で、key の値をそれと同じ長さの新しい数値で置き換えます。
-
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
新しい事前共有鍵を追加する方法
事前共有鍵を使用する場合は、ipsecinit.conf ファイルのポリシーエントリごとに 1 つの事前共有鍵が必要です。IPsec と IKE が動作している間に新しいポリシーエントリを追加すれば、in.iked デーモンはそれらの新しいキーを読み込むことができます。この手順では、次の条件がすでにそろってるものとします。
-
in.iked デーモンが動作している。
-
IPsec を使って保護したいインタフェースが、次のように、両システムの /etc/hosts ファイルのエントリとして存在する。
192.168.15.7 ada
-
両システムの /etc/inet/ipsecinit.conf ファイルに新しいポリシーエントリが追加されている。たとえば、enigma のエントリが次のようになっている。
{laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}たとえば、ada のエントリが次のようになっている。
{laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared} -
両システムの /etc/inet/ike/config ファイルの ada 上にそのインタフェースの規則が作成されている。たとえば、enigma の規則が次のようになっている。
### ike/config file on enigma, 192.168.116.16 … ## The rule to communicate with ada { label "Enigma-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg blowfish } p2_pfs 5 }たとえば、ada の規則が次のようになっている。
### ike/config file on ada, 192.168.15.7 … ## The rule to communicate with enigma { label "ada-to-Enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg blowfish } p2_pfs 5 }
注 –auth_method のすべての引数は同じ行になければなりません。
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
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 privilege level to 2!
-
ランダム鍵を生成し、その出力を結合して 64 から 448 ビットの鍵を作成します。
Solaris システムでは、od コマンドを使用できます。
# od -X -A n /dev/random | head -4 0fb834c5 8d1fb4ee 500e2bea 071deb2e 781cb483 74411af5 a9671714 672bb174 9ad9364d 53574f27 4aacea56 c34861bb b4509514 145c1845 f857ff2b 6e5e3766コマンドの説明については、乱数を生成する方法と od(1) のマニュアルページを参照してください。
-
このキーを何らかの方法で通信するシステムの管理者に送信します。
両者は、同じ事前共有鍵を同時に追加する必要があります。
-
ikeadm コマンドモードの add preshared サブコマンドを使って新しいキー情報を追加します。
ikeadm> add preshared { localidtype id-type localid id remoteidtype id-type remoteid id ike_mode mode key key }id-type
id のタイプ
id
IP アドレス (id-type が IP の場合)
mode
IKE モード。有効な値は main だけ
key
事前共有鍵 (16 進数形式)
たとえば、ホスト enigma で新しいインタフェース ada 用のキー 192.168.15.7 を追加します。
# ikeadm ikeadm> add preshared { localidtype ip localid 192.168.116.16 remoteidtype ip remoteid 192.168.15.7 ike_mode main key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } ikeadm: Successfully created new preshared key.ホスト ada でも、次のようにして同じキーを追加します。
# ikeadm ikeadm> add preshared { localidtype ip localid 192.168.15.7 remoteidtype ip remoteid 192.168.116.16 ike_mode main key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } 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
注 –このコマンドの実行時には警告を読んでください。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。
-
システムごとに、ikeadm コマンドを実行して新しい規則を読み込みます。
ada と enigma の新しい規則の例がこの手順の始めにあります。規則は /etc/inet/ike/config ファイルに格納されているため、ファイルの名前を指定する必要はありません。
# ikeadm read rules
-
IKE 事前共有鍵がリブート時に確実に使用できるように、/etc/inet/secret/ike.preshared ファイルを編集します。
システムごとに、add preshared コマンドに対する引数をファイルに入力します。
-
たとえば、enigma システムで、次のキー情報を ike.preshared ファイルに追加します。
# ike.preshared on enigma for the ada interface #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 04413a3e68854b732742024d19995f7972136a2f33e5d302bdd7b2624e4c6429 } -
ada システムで、次のキー情報を ike.preshared ファイルに追加します。
# ike.preshared for the ada interface, 192.168.15.7 #… { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 04413a3e68854b732742024d19995f7972136a2f33e5d302bdd7b2624e4c6429 }
-
自己署名付き公開証明書による IKE の設定方法
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ikecert certlocal -ks コマンドを使用して、自己署名付き証明書を ike.privatekeys データベースに追加します。
# ikecert certlocal -ks -m keysize -t keytype \ -D dname -A altname[ ... ] [-f output]
-ks
自己署名付き証明書を作成する
keysize
キーのサイズ。 keysize は、512、1024、2048、3072、4096 のいずれか
keytype
使用するアルゴリズムのタイプ。keytype は、rsa-sha1、rsa-md5、dsa-sha1 のいずれか
dname
証明書主体の X.509 識別名。dname の一般的な形式は次のとおり : C = country (国)、O = organization (組織)、OU = organizational unit (組織単位)、CN = common name (共通名)。有効なタグは、C、O、OU、CN
altname
証明書の代替名。altname の形式は tag=value でなければならない。有効なタグは、IP、DNS、EMAIL、URI、DN、RID
output
エンコーディング出力の形式。指定できる値は pem (PEM Base64) と ber (ASN.1 BER)。-f を指定しないと、 pem が使用される
たとえば、次のように指定します。
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=ExampleCompany, OU=US-Example, CN=Example" \ > -A IP=192.168.116.16 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.116.16" cert_trust "192.168.13.213" ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } 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 "C=US, O=ExampleCompany, OU=US-Example, CN=Example" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method rsa_encrypt oakley_group 2 auth_alg md5 encr_alg 3des } } -
-
管理者の電子メールから公開鍵をコピーします。
-
次のように ikecert certdb -a コマンドと <Return> を入力します。
<Return> キーを押してもプロンプトは表示されません。
# ikecert certdb -a <Return キーを押す>
-
公開鍵を貼り付けます。次に <Return> を入力します。
-----BEGIN X509 CERTIFICATE----- MIICL… … KgDid/nxWPlWQU5vMAiwJXfa0sw/A12w448JVkVmEWaf -----END X509 CERTIFICATE-----<Return キーを押す>
-
<Control-D> を入力して入力を終了します。
<Control-D>
-
-
通信するシステムの管理者と一緒に、キーが改ざんされていないことを確認します。
たとえば、その管理者に電話で連絡して公開鍵ハッシュの値を比較できます。一方のシステムの公開鍵ハッシュは、通信するシステムの公開鍵ハッシュと同一でなければなりません。
-
たとえば、enigma で ikecert certdb -l コマンドを実行します。
enigma # 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 -
partym で ikecert certlocal -l コマンドを実行します。
partym # ikecert certlocal -l Local ID Slot Name: 1 Type: if-modn Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
注 –この例の公開鍵ハッシュは、使用しているシステムで生成される公開鍵ハッシュとは異なります。
-
認証局による署名付き公開鍵による IKE の設定方法
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
ikecert certlocal -kc コマンドを実行して証明書要求を作成します。
このコマンドに対する引数は、 ikecert certlocal -ks コマンドで使用する引数と同じでなければなりません。
# ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname[ ... ] [-f output]
-kc
公開鍵と非公開鍵のペアを作成する。さらに、-kc は、生成された公開鍵に基づいて証明書要求を作成する
keysize
キーのサイズ。 keysize は、512、1024、2048、3072、4096 のいずれか
keytype
使用するアルゴリズムのタイプ。keytype は、rsa-sha1、rsa-md5、dsa-sha1 のいずれか
dname
証明書主体の X.509 識別名。dname の一般的な形式は次のとおり : C = country (国)、O = organization (組織)、OU = organizational unit (組織単位)、CN = common name (共通名)。有効なタグは、C、O、OU、CN
altname
証明書の代替名。altname の形式は tag=value でなければならない。有効なタグは、IP、DNS、EMAIL、URI、DN、RID
output
エンコーディング出力の形式。指定できる値は pem (PEM Base64) と ber (ASN.1 BER)。-f を指定しないと、 pem が使用される
たとえば、次のコマンドを実行して証明書要求を作成します。
# 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 を処理する機関に送信します。
この機関は、外部の認証局や PKI の場合があります。また、会社によっては PKI を独自に運営する場合もあります。証明書要求の送信方法については PKI に問い合わせてください。ほとんどの機関は、Web サイトに送信フォームを掲載しています。フォームの記入に当たっては、その送信が正当なものであることを証明する必要があります。通常は、証明書要求をフォームに貼り付けます。要求を受け取った機関は、それをチェックしてから 2 つまたは 3 つの証明書オブジェクトを発行します。
-
公開鍵証明書 – この証明書は機関に送信した要求に基づいて作成される。送信した証明書要求も、公開鍵証明書の一部として含まれる。この証明書によって一意に識別される
-
認証局 – 機関の署名。CA によって公開鍵証明書が正規のものであることが確認される
-
証明書無効リスト – 機関が無効にした証明書の最新リスト。CRL へのアクセスが公開鍵証明書に組み込まれている場合には、CRL が別個の証明書オブジェクトとして送信されることはない
CRL の URI が公開鍵証明書に組み込まれている場合には、IKE は CRL を自動的に取り出すことができる。同様に、DN エントリが公開鍵証明書に組み込まれている場合には、IKE は、指定された LDAP サーバーから CRL を自動的に取り出すことができる
公開鍵証明書に URI や DN エントリを組み込んだ例については、証明書無効リストにアクセスする方法を参照
-
-
各証明書を 3 つの ikecert コマンドのどれかに対する引数として指定します。
これらのコマンドでは -a オプションを使用します。-a オプションを指定すると、貼り付けたオブジェクトが、システム内の適切な証明書データベースに追加されます。詳細は、公開鍵証明書の使用を参照してください。
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
-
次のように 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>
-
機関から CRL オブジェクトを受け取っている場合は、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 des } 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 "C=US, O=ExampleCompany, OU=UN-Example, CN=Example" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method rsa_encrypt oakley_group 2 auth_alg md5 encr_alg 3des } }
注 –auth_method のすべての引数は同じ行になければなりません。
-
PKI 機関から CRL を受け取っていない場合は、キーワード ignore_crls を ike/config ファイルに追加します。
ignore_crls を指定すると、IKE は CRL を検索しません。たとえば、次のように指定します。
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ignore_crls …
-
PKI 機関から CRL の一元的なディストリビューションポイントを知らされている場合は、ike/config ファイルを変更してこの場所を指定することができます。
例については、証明書無効リストにアクセスする方法 を参照してください。
-
この例に従うなら、前に行ったように、“…OU=UN-Example…” システムで ikecert コマンドを実行します。“…OU=UN-Example…” システムの /etc/inet/ike/config ファイルでは、そのローカル情報をローカルパラメータとして使用します。さらに、システムでは、システムの情報をリモートパラメータとして使用します。
たとえば、次のように指定します。
# Trusted root cert # This certificate is from Example PKI cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ignore_crls ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des } 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 "C=US, O=ExampleCompany, OU=US-Example, CN=Example" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method rsa_encrypt oakley_group 2 auth_alg md5 encr_alg 3des } } -
auth_method は rsa_encrypt であるため、ピアの証明書を公開鍵データベースに追加します。
注 –以下のサブステップは、/etc/inet/ike/config ファイルの p1_xform で rsa_encrypt 認証方式を使用する場合にのみ必要です。
-
その証明書を、通信するシステムの管理者に送信します。
その証明書は、次のようにして電子メールにカット&ペーストできます。
To: root@un.example.com From: root@us.example.com Message: -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----
-
システムごとに、ピアの証明書をローカルの公開鍵データベースに追加します。
たとえば、un.example.com システムで次のように入力してから、電子メールの内容を貼り付けます。
# ikecert certdb -a <Type the Return key> -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----
RSA 暗号化認証方式を使用すると、IKE の ID が盗聴者から保護されます。rsa_encrypt 方式では ID が隠されるため、IKE はピアを知りません。そのため、ピアの証明書を取り出すことはできません。したがって、その方式では、IKE ピアが互いの公開鍵を認識することが必要になります。よって、/etc/inet/ike/config ファイルの auth_method rsa_encrypt を使用する場合には、ピアの証明書を公開鍵データベースに追加する必要があります。この結果、公開鍵データベースには、通信するシステムペアごとに 3 つの証明書が存在することになります。公開鍵データベースには、公開鍵証明書、CA 証明書、およびピアの証明書が存在します。これに対して CRL データベースには、無効化された証明書が格納されています。
IKE デーモンは、次の処理が完了すると、公開鍵と CA を使って自身を認証します。
-
各システムの /etc/hosts ファイルに、保護されたインタフェースが追加されている
-
各システムの /etc/inet/ipsecinit.conf ファイルに、保護されたインタフェースが追加されている
-
両方のシステムがリブートされている
-
証明書無効リストにアクセスする方法
証明書無効リスト (CRL) には、認証局が発行した証明書のうち、期限切れになったりセキュリティが低下したりした証明書が記載されます。CRL を処理する方法には、次の 4 つがあります。
-
CA 機関から CRL が発行されない場合は、 /etc/inet/ike/config ファイルにある CRL を無視するように IKE に指定できる。このオプションについては、認証局による署名付き公開鍵による IKE の設定方法を参照
-
CA から受け取った公開鍵証明書に URI のアドレスが組み込まれている場合は、IKE は URI から CRL にアクセスする
-
CA から受け取った公開鍵証明書に LDAP サーバーの DN エントリが組み込まれている場合は、IKE は LDAP サーバーから CRL にアクセスする。その場合には、/etc/inet/ike/config ファイルの ldap-list キーワードに対する引数として LDAP サーバーを指定する
-
ikecert certrldb コマンドの引数として CRL を指定する
次の手順は、一元的なディトリビューションポイントの CRL を使用するように IKE に指示する方法を示しています。
-
ikecert certdb –lv certspec コマンドを実行して、PKI 機関から受け取った証明書を表示します。
-l
IKE 証明書データベースにある証明書を一覧表示する
-v
証明書を冗長モードで一覧表示する。このオプションは慎重に使用すること
certspec
certspec パターンと証明書のパターンを照合する
たとえば、次の証明書は Sun Microsystems から発行されたものです。詳細は変更されています。
# ikecert certdb -lv example-protect.sun.com Certificate Slot Name: 0 Type: if-modn (Private key in certlocal slot 0) Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com> Issuer Name: <CN=Sun Microsystems Inc CA (Class B), O=Sun Microsystems Inc> SerialNumber: 14000D93 Validity: Not Valid Before: 2002 Jul 19th, 21:11:11 GMT Not Valid After: 2005 Jul 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.sun.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.sun.com/pki/pkismica.crl#i DN = <CN=Sun Microsystems Inc CA (Class B), O=Sun Microsystems Inc> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information AccessCRL Distribution Points のデータに注目してください。URI エントリは、この機関の CRL が Web 上にあることを示しています。DN エントリは、CRL が LDAP サーバー上にもあることを示しています。ユーザーはこれら 2 つのうちのどちらかを使用できます。
-
URI を使用する場合は、ホストの /etc/inet/ike/config ファイルにキーワード use_http を指定します。
たとえば、ike/config ファイルの内容は次のようになります。
# Use CRL from organization's URI use_http …
IKE は CRL を取り出し、証明書の期限が切れるまで CRL を保持します。
さらに、ike/config ファイルにキーワード proxy を指定することによって Web プロキシを使用することもできます。proxy では、次のように、引数として URL を指定します。
proxy "http://proxy1:8080"
-
LDAP を使用する場合は、ホストの /etc/inet/ike/config ファイルの ldap-list キーワードへの引数として LDAP サーバーを指定します。
LDAP サーバーの名前は、使用する機関にたずねてください。ike/config ファイルのエントリは、次のようになります。
# Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …
IKE は CRL を取り出し、証明書の期限が切れるまで CRL を保持します。
例 — CRL をローカルの certrldb データベースに貼り付ける
この例は、一元的なディストリビューションポイントから得ることができない CRL を使用する方法を示しています。
使用する機関の証明書に一元的なディストリビューションポイントが含まれていない場合は、機関の CRL を手動でローカルの crls データベースに追加できます。その場合は、機関の説明に従って CRL を抽出し、それを ikecert certrldb –a コマンドでデータベースに追加します。
# ikecert certrldb -a<Return キーを押す> <PKI 機関からの CRL を貼り付ける> <Return キーを押す> <<Control-D> を押して CRL をデータベースに追加する> |
IKE で Sun Crypto Accelerator 1000 カードを使用する方法
注 –
次の手順では、Sun Crypto Accelerator 1000 カードがすでにシステムに取り付けられているものとします。さらに、カードに必要なソフトウェアがすでにインストールされ、構成されているものとします。詳細については、『Sun Crypto Accelerator 1000 Board Version 1.1 Installation and User's Guide』を参照してください。
-
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
注 –リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
-
PKCS #11 ライブラリのパスを /etc/inet/ike/config ファイルに追加します。
pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"
パス名は 32 ビット PKCS #11 ライブラリを指していなければなりません。ライブラリが存在していれば、IKE は、ライブラリのルーチンを使用して、Sun Crypto 1000 カード上の IKE 公開鍵操作を高速化します。カードがこのような重い操作を行っている間、オペレーティングシステムのリソースは他の操作に使用できます。
-
ファイルを閉じてからリブートします。
-
リブートしたら、ライブラリがリンクされていることを確認します。PKCS #11 ライブラリがリンクされていることを確認するには、次のコマンドを実行します。
# ikeadm get stats Phase 1 SA counts: Current: initiator: 0 responder: 0 Total: initiator: 0 responder: 0 Attempted: initiator: 0 responder: 0 Failed: initiator: 0 responder: 0 initiator fails include 0 time-out(s) PKCS#11 library linked in from /opt/SUNWconn/lib/libpkcs11.so #/etc/inet/ike/config ファイルの他のパラメータとは異なり、pkcs11_path キーワードは IKE の起動時にだけ読み込まれます。ikeadm コマンドを使って新しい /etc/inet/ike/config ファイルを追加したり再読み込みしたりしても、pkcs11_path は持続します。パスが持続するのは、IKE デーモンがフェーズ 1 のデータを保持するためです。PKCS #11 によって処理が加速されたキーは、フェーズ 1 データの一部です。
- © 2010, Oracle Corporation and/or its affiliates