Solaris のシステム管理 (IP サービス)

第 23 章 IKE の設定 (手順)

この章では、使用するシステムにあわせて Internet Key Exchange (IKE) を設定する方法について説明します。IKE の設定が完了すると、そのネットワークにおける IPsec の鍵情報が自動的に生成されます。この章では、次の内容について説明します。

IKE の概要については、第 22 章インターネットキー交換 (概要)を参照してください。IKE の参照情報については、第 24 章インターネットキー交換 (リファレンス)を参照してください。詳細な手順については、ikeadm(1M)、ikecert(1M)、および ike.config(4) のマニュアルページで使用例のセクションを参照してください。

IKE の設定 (作業マップ)

IKE を認証するには、事前共有鍵、自己署名付き証明書、および認証局 (CA) の証明書を使用できます。規則として、保護しようとしているエンドポイントには、特定の IKE 認証方法を関連付けます。したがって、1 つのシステムに 1 つまたはすべての IKE 認証方法を使用できます。PKCS #11 ライブラリへのポインタによって、証明書は、接続されたハードウェアアクセラレータを使用できます。

IKE を設定したあと、IKE 設定を使用する IPsec 作業を実行します。次の表に、特定の IKE 設定に注目した作業マップを示します。

タスク	説明	説明
事前共有鍵で IKE を設定します	2 つのシステムに秘密鍵を共有させることにより、その通信を保護します。	「事前共有鍵による IKE の設定 (作業マップ)」
公開鍵証明書で IKE の設定します	公開鍵証明書を使って通信を保護します。証明書は、自己署名付き、または PKI 機関の保証付きです。	「公開鍵証明書による IKE の設定 (作業マップ)」
NAT 境界を越えます	IPsec と IKE を設定して、移動体システムと通信します	「移動体システム用の IKE の設定 (作業マップ)」
公開鍵証明書を生成し、接続されたハードウェアに格納するように設定します	Sun Crypto Accelerator 1000 ボードまたは Sun Crypto Accelerator 4000 ボードを使って IKE 操作を高速化します。Sun Crypto Accelerator 4000 ボードには、公開鍵証明書も格納できます。	「接続したハードウェアを検出するための IKE の設定 (作業マップ)」
フェーズ 1 鍵ネゴシエーションパラメータを調整します	IKE 鍵ネゴシエーションのタイミングを変更します。	「IKE 転送パラメータの変更 (作業マップ)」

事前共有鍵による IKE の設定 (作業マップ)

次の表に、事前共有鍵で IKE を設定および保守する手順を示します。

タスク	説明	説明
事前共有鍵で IKE を設定します	共有する IKE ポリシーファイルと 1 つの鍵を作成します。	「事前共有鍵により IKE を設定する方法」
実行中の IKE システムで事前共有鍵を更新します	通信するシステムに最新の鍵情報を追加します。	「IKE の事前共有鍵を更新する方法」
実行中の IKE システムへ事前共有鍵を追加します	現在 IKE ポリシーを実施しているシステムに、新しい IKE ポリシーエントリと新しい鍵情報を追加します。	「`ipsecinit.conf` の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法」
事前共有鍵が同一であることをチェックします	両方のシステムの事前共有鍵を表示して、その鍵が同一であることを調べます。	「事前共有鍵が同一であることを確認する方法」

事前共有鍵による IKE の設定

事前共有鍵は、IKE 用の最も簡単な認証方法です。2 つのシステムが IKE を使用するように設定している場合、さらに、両方のシステムの管理者である場合、事前共有鍵を使用することはよい選択です。しかし、公開鍵認証とは異なり、事前共有鍵は特定の IP アドレスに縛られます。事前共有鍵は、移動体システムなど、番号が変更される可能性があるシステムでは使用できません。また、事前共有鍵を使用するときには、接続されたハードウェアに IKE 計算を任せることはできません。

事前共有鍵により IKE を設定する方法

IKE 実装では、鍵の長さが異なるさまざまなアルゴリズムが提供されます。鍵の長さは、サイトのセキュリティーに応じて選択します。一般的に、鍵の長さが長いほど、セキュリティーが高くなります。

これらの手順には、システム名 enigma および partym を使用します。enigma と partym を各自使用しているシステムの名前に置き換えてください。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

システムごとに、/etc/inet/ike/config.sample ファイルを /etc/inet/ike/config にコピーします。

システムごとに、規則とグローバルパラメータを ike/config ファイルに入力します。

これらの規則やグローバルパラメータは、システムの ipsecinit.conf ファイルに設定されている IPsec ポリシーが正しく動作するものでなければなりません。次の ike/config の例は、「IPsec で 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 must be unique
{ 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 sha1 encr_alg aes }
  p2_pfs 5
}

注 –

auth_method パラメータのすべての引数は同じ行になければなりません。

partym システムの /etc/inet/ike/config ファイルを次のように変更します。

### 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 must be unique
{ 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 sha1 encr_alg aes }
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 コマンドについては、「Solaris System で乱数を生成するには」と od(1) のマニュアルページを参照してください。

注 –
ほかのオペレーティングシステムでは、ASCII 形式の鍵情報が必要になる場合があります。同じ鍵を 16 進形式と ASCII 形式で生成する方法については、例 23–1 を参照してください。

手順 5 の出力から、1 つの鍵を作成します。
f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
この手順における認証アルゴリズムは SHA–1 です (手順 3 を参照)。事前共有鍵として推奨する最小のサイズは、ハッシュのサイズ (つまり、認証アルゴリズムの出力のサイズ) で決まります。SHA–1 アルゴリズムの出力は 160 ビット、すなわち 40 文字です。例の鍵の長さは 56 文字であり、IKE が使用する鍵情報が追加されています。

システムごとに /etc/inet/secret/ike.preshared ファイルを作成します。

各ファイルに事前共有鍵を書き込みます。

たとえば、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
	}

注 –

両システムの事前共有鍵は同一にする必要があります。

例 23–1 オペレーティングシステムの異なる 2 つのシステムに対して同じ鍵情報を生成する

Solaris IPsec は、ほかのオペレーティングシステムと相互運用できます。ASCII 形式の事前共有鍵を必要とするシステムと通信する場合は、1 つの鍵を 16 進形式と ASCII 形式の 2 つの形式で生成する必要があります。

この例では、Solaris システムの管理者が 56 文字の鍵情報を使用しようとしています。管理者は、次のコマンドを使用して、ASCII パスフレーズから 16 進形式の鍵を生成します。オプション -tx1 を指定すると、一度に 1 バイトずつ、すべての Solaris システムに出力されます。

# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

オフセットを削除して 16 進出力を連結すると、Solaris システム用の 16 進形式の鍵は 7061706965726d616368652077697468206361736865777320616e64 になります。管理者は、この値を Solaris システムの ike.preshared ファイルに格納します。

# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

ASCII 形式の事前共有鍵を必要とするシステムでは、パスフレーズが事前共有鍵になります。Solaris システムの管理者は、相手の管理者に電話し、パスフレーズ papiermache with cashews and を伝えます。

IKE の事前共有鍵を更新する方法

この手順では、一定の間隔で既存の事前共有鍵を置き換えたい場合を想定しています。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

乱数を生成し、適切な長さのキーを作成します。

詳細については、「Solaris System で乱数を生成するには」を参照してください。Solaris システムが ASCII 形式を必要とするオペレーティングシステムと通信する場合、事前共有鍵を生成する方法については、例 23–1 を参照してください。

現在の鍵を新しい鍵で置き換えます。

たとえば、ホスト enigma と partym において、 /etc/inet/secret/ike.preshared ファイルの key の値を、同じ長さの新しい番号で置き換えます。

新しい鍵をカーネルに読み込みます。
- Solaris 10 4/09 リリース以降では、ike サービスを更新します。
  # svcadm refresh ike
- Solaris 10 4/09 リリースより前のリリースを実行している場合は、in.iked デーモンを強制終了および再起動します。
  1. in.iked デーモンの特権レベルをチェックします。
    # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled
    コマンドから 0x1 または 0x2 の特権レベルが戻された場合には、鍵情報を変更できます。0x0 の特権レベルでは、鍵情報を変更または表示する操作を行うことはできません。デフォルトでは、in.iked デーモンは 0x0 の特権レベルで実行されます。
  2. 特権レベルが 0x0 の場合、デーモンを強制終了および再起動します。
    
    デーモンを再起動すると、ike.preshared ファイルの新しいバージョンを読み取ります。
    # pkill in.iked # /usr/lib/inet/in.iked
  3. 特権レベルが 0x1 または 0x2 である場合、ike.preshared ファイルの新しいバージョンを読み取ります。
    # ikeadm read preshared

IKE の事前共有鍵を表示する方法

デフォルトでは、ikeadm コマンドではフェーズ 1 SA のダンプに実際の鍵を表示できないようになっています。鍵を表示するとデバッグに役立ちます。

実際の鍵を表示するには、デーモンの特権レベルを高くする必要があります。特権レベルについては、「IKE 管理コマンド」を参照してください。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–2 を参照してください。

始める前に

IKE は構成済みで、ike サービスは実行中です。

IKE の事前共有鍵を表示します。
# ikeadm ikeadm> dump preshared

エラーが発生する場合は、in.iked デーモンの特権レベルを高くします。
1. SMF リポジトリの in.iked デーモンの特権レベルを高くします。
  # svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat
2. 実行中の in.iked デーモンの特権レベルを高くします。
  # svcadm refresh ike ; svcadm restart ike
3. (省略可能) 特権レベルが keymat であることを確認します。
  # svcprop -p config/admin_privilege ike keymat
4. 手順 1 をもう一度実行して鍵を表示します。

IKE デーモンを基本の特権レベルに戻します。
1. 鍵を表示したあと、特権レベルをデフォルトに戻します。
  # svccfg -s ike setprop config/admin_privilege=base
2. IKE を更新してから再起動します。
  # svcadm refresh ike ; svcadm restart ike

例 23–2 Solaris 10 4/09 リリースより前のリリースで IKE の事前共有鍵を確認する

次の例では、現在の Solaris リリースが稼働していない Solaris システムで管理者が鍵を表示しようとしています。管理者は、このシステムの鍵が通信先のシステムの鍵と同じであることを確認する必要があります。2 つのシステムの鍵が同じであることを確認したあと、管理者は特権レベルを 0 に戻します。

まず、管理者は in.iked デーモンの特権レベルを調べます。

adm1 # /usr/sbin/ikeadm get priv
Current privilege level is 0x0, base privileges enabled

特権レベルが 0x1 または 0x2 になっていないため、管理者は in.iked デーモンを停止してから特権レベルを 2 に上げます。
adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

管理者は鍵を表示します。

adm1 # ikeadm dump preshared
PSKEY: Preshared key (24 bytes): f47cb…/192
LOCIP: AF_INET: port 0, 192.168.116.16 (adm1).
REMIP: AF_INET: port 0, 192.168.13.213 (com1).

管理者は通信先のシステムにリモートでログインし、鍵が同じかどうかを調べます。
その後、基本の特権レベルに戻します。
# ikeadm set priv base

`ipsecinit.conf` の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法

IPsec と IKE の実行中に IPsec ポリシーのエントリを追加した場合は、新しいポリシーおよび IKE ルールをカーネルに読み込む必要があります。Solaris 10 4/09 リリース以降では、新しい鍵を追加したあと policy サービスを再起動し、ike サービスを更新します。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–3 を参照してください。

始める前に

この手順では、次のように仮定しています。

enigma システムは、「事前共有鍵により IKE を設定する方法」で説明されているように設定されている。
enigma システムは、新しいシステム ada を使用して、そのトラフィックを保護しようとしている。
両システムで in.iked デーモンが動作している。
両システムの /etc/hosts ファイルには、各システムのインタフェースのエントリが登録されている。次に例を示します。
192.168.15.7 ada 192.168.116.16 enigma
この手順は、/etc/inet/ipnodes ファイル内の Ipv6 アドレスにも適用されます。Solaris 10 6/07 リリース以降では、IPv6 エントリは /etc/hosts ファイルに格納されています。

両システムの /etc/inet/ipsecinit.conf ファイルに新しいポリシーエントリが追加されている。この場合、エントリは次のようになります。

# ipsecinit.conf file for enigma
{laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}

# ipsecinit.conf file for ada
{laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

現在のリリースの場合は、次のコマンドを使用して、各システムの /etc/inet/ipsecinit.conf ファイルの構文を確認してある。
# ipsecconf -c -f /etc/inet/ipsecinit.conf

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

このシステムで乱数を生成し、64 から 448 ビットの鍵を作成します。

詳細については、「Solaris System で乱数を生成するには」を参照してください。Solaris システムが ASCII 形式を必要とするオペレーティングシステムと通信する場合、事前共有鍵を生成する方法については、例 23–1 を参照してください。

このキーを何らかの方法でリモートシステムの管理者に送信します。

両者は、同じ事前共有鍵を同時に追加する必要があります。この鍵の安全性は転送機構の安全性と同じです。登録済みメールや保護済み FAX マシンなど、帯域外機構を使用することが最良です。ssh セッションを使用して両方のシステムを管理することもできます。

enigma と ada の鍵を管理するための IKE の規則を作成します。

enigma システムで、次の規則を /etc/inet/ike/config ファイルに追加します。

### ike/config file on enigma, 192.168.116.16
 
## The rule to communicate with ada

{label "enigma-to-ada"
 local_addr 192.168.116.16
 remote_addr 192.168.15.7
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 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 sha1 encr_alg blowfish}
 p2_pfs 5
}

リブート時に IKE 事前共有鍵が利用できることを確認します。

enigma システムで、次の情報を /etc/inet/secret/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 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

ada システムで、次の情報を ike.preshared ファイルに追加します。

# ike.preshared on ada for the enigma interface
# 
{ 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 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

各システムで、IPsec ポリシーサービスを再起動して、追加したインタフェースをセキュリティー保護します。
# svcadm restart policy

各システムで、ike サービスを更新します。
# svcadm refresh ike

両システムが通信できることを確認します。

詳細は、「事前共有鍵が同一であることを確認する方法」を参照してください。

例 23–3 新しい IPsec ポリシーエントリに IKE 事前共有鍵を追加する

次の例では、現在の Solaris リリースが稼働していない Solaris システムに管理者が事前共有鍵を追加しようとしています。管理者は前の手順に従って ike/config ファイルと ike.preshared ファイルを変更し、鍵を生成し、リモートシステムに接続します。管理者は各種のコマンドを使用して、新しい IPsec ポリシーおよび IKE ルールをカーネルに読み込みます。

新しい鍵を生成する前に、管理者は in.iked デーモンの特権レベルを 2 に設定します。
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2
通信先のシステムに鍵を送信し、新しい鍵をシステムに追加したあと、管理者は特権レベルを低くします。
# ikeadm set priv base
次に、管理者は新しい IPsec ポリシーをカーネルに読み込みます。
# ipsecconf -a /etc/inet/ipsecinit.conf
最後に、新しい IKE ルールをカーネルに読み込みます。
# ikeadm read rules

事前共有鍵が同一であることを確認する方法

通信するシステム上の事前共有鍵が同一でない場合、それらのシステムは認証できません。

始める前に

テストしている 2 つのシステム間では IPsec が設定されており、有効になっています。現在の Solaris 10 リリースが稼働しています。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–2 を参照してください。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

各システムで、in.iked デーモンの特権レベルをチェックします。
# svcprop -p config/admin_privilege ike base
- 特権レベルが keymat であれば、手順 3 に進みます。
- 特権レベルが base または modkeys の場合は、特権レベルを高くします。
  
  その後、ike サービスを更新してから再起動します。
  # svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat

システムごとに、事前共有鍵情報を表示します。

# ikeadm dump preshared
PSKEY: Preshared 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 ファイルで、一方のキーを他方のキーで置き換えます。

確認が終わったら、各システム上で特権レベルをデフォルトに戻します。
# svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike

公開鍵証明書による IKE の設定 (作業マップ)

次の表に、IKE の公開鍵証明書を作成する手順を示します。これらの手順には、接続されたハードウェア上で証明書を高速化および格納する方法が含まれます。

タスク	説明	説明
自己署名付き公開鍵証明書で IKE を設定します	システムごとに 2 つの証明書を作成および格納します。自己署名付き証明書リモートシステムからの公開鍵証明書	「自己署名付き公開鍵証明書により IKE を設定する方法」
PKI 認証局で IKE を設定します	1 つの証明書要求を作成して、そのあと、システムごとに次の 3 つの証明書を格納します。証明書要求に応じて認証局 (CA) が作成した証明書 CA からの公開鍵証明書 CA からの CRL	「CA からの署名付き証明書により IKE を設定する方法」
ローカルハードウェア上で公開鍵証明書を設定します	次のいずれかの作業を行います。ローカルハードウェア上で自己署名付き証明書を生成し、リモートシステムの公開鍵をハードウェアに追加する。ローカルハードウェア上で証明書要求を生成し、CA から取得した公開鍵証明書をハードウェアに追加する。	「ハードウェア上で公開鍵証明書を生成、格納する方法」
PKI からの証明書失効リスト CRL を更新します	中央の配布ポイントから CRL にアクセスします。	「証明書失効リストを処理する方法」

公開鍵証明書による IKE の設定

公開鍵証明書を使用すると、通信するシステムは秘密鍵情報を帯域外で共有する必要がなくなります。事前共有鍵とは異なり、公開鍵証明書は、移動体システムなど、番号が変更される可能性があるシステムでも使用できます。

公開鍵証明書はまた、接続されたハードウェアに格納できます。手順については、「接続したハードウェアを検出するための IKE の設定 (作業マップ)」を参照してください。

自己署名付き公開鍵証明書により IKE を設定する方法

自己署名付き証明書は、CA からの公開鍵証明書よりもオーバーヘッドが少ないのですが、あまり簡単には拡大できません。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

自己署名付き証明書を ike.privatekeys データベースに追加します。

# ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]

-ks: 自己署名付き証明書を作成します。
-kc: 証明書要求を作成します。手順については、「CA からの署名付き証明書により IKE を設定する方法」を参照してください。
-m keysize: キーのサイズです。keysize は、512、1024、2048、3072、4096 のいずれかです。
-t keytype: 使用するアルゴリズムのタイプを指定します。keytype は rsa-sha1、rsa-md5、dsa-sha1 のいずれかです。
-D dname: 証明書主体の X.509 識別名です。dname の一般的な形式は次のとおりです。 C = country (国)、O = organization (組織)、OU = organizational unit (組織単位)、CN = common name (共通名)。有効なタグは、C、O、OU、CN です。
-A altname: 証明書の代替名です。altname の形式は tag=value です。有効なタグは IP、DNS、email、および DN です。
-S validity-start-time: 証明書の有効期間の開始時間を絶対値または相対値で指定します。
-F validity-end-time: 証明書の有効期間の終了時間を絶対値または相対値で指定します。
-T token-ID: PKCS #11 ハードウェアトークンで鍵を生成できるようにします。その後、証明書はハードウェアに格納されます。

たとえば、partym システムでは、コマンドは次のようになります。

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

enigma システムでは、コマンドは次のようになります。

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

証明書を保存し、リモートシステムに送信します。

証明書は、電子メールに貼り付けることもできます。

たとえば、次の partym 証明書を enigma の管理者に送信します。

To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

enigma の管理者は、次の enigma 証明書を送信してきます。

To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

システムごとに、受信した証明書を追加します。
1. 管理者の電子メールから公開鍵をコピーします。
2. ikecert certdb -a コマンドを入力して、Return キーを押します。
  
  Return キーを押してもプロンプトは表示されません。
  # ikecert certdb -a Press the Return key
3. 公開鍵を貼り付けます。続いて Return キーを押します。Control-D キーを押して入力を終了します。
  -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D

通信するシステムの管理者と一緒に、証明書がその管理者のものであることを確認します。

たとえば、その管理者に電話で連絡して次に示す公開鍵ハッシュの値を比較できます。共有の証明書の公開鍵ハッシュは、両システムで同一でなければなりません。

システムに格納されている証明書のリストを表示します。

たとえば、partym システムでは、公開鍵証明書はスロット 1 に格納されており、非公開鍵証明書はスロット 0 に格納されています。

partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

この値と enigma システムの公開鍵ハッシュを比較します。

公開鍵ハッシュは電話で伝えることができます。

enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

システムごとに、両方の証明書を信頼します。

/etc/inet/ike/config ファイルを編集して、証明書を認識します。

パラメータ cert_trust、remote_addr、および remote_id の値は、リモートシステムの管理者が提供します。

たとえば、partym システム上の ike/config ファイルは次のようになります。

# Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## 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 "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

enigma システムで、ike/config ファイルにローカルパラメータの enigma 値を追加します。

リモートパラメータには、partym 値を使用します。キーワード label の値が一意であることを確認します。この値は、リモートシステムの label 値とは異なる値でなくてはなりません。

…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

例 23–4 別の管理者の証明書が有効かどうかを確認する

この例で、管理者は被認証者名 (Subject Name) を使用して証明書が同一であることを確認します。

最初の管理者は、証明書の生成と一覧表示の出力をファイルに保存します。ikecert コマンドの出力は標準エラーに書き込まれるため、管理者は標準エラーをファイルにリダイレクトします。

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

管理者はファイルの内容を確認します。

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

次に、管理者はこのファイルを電子メールで 2 番目の管理者に送信します。

2 番目の管理者は、セキュリティー保護されたディレクトリにファイルを格納し、ファイルから証明書をインポートします。

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

ikecert コマンドは、-----BEGIN 行と -----END 行の間にあるテキストだけをインポートします。管理者は、ローカルの証明書の公開鍵ハッシュが co2sys ファイル内の公開鍵ハッシュと同じであることを確認します。

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

この電子メールを送信したのが最初の管理者であることを確認するために、2 番目の管理者は最初の管理者に電話して、証明書の被認証者名 (Subject Name) を確認します。

例 23–5 証明書の開始時間と終了時間を指定する

この例では、partym システムの管理者が、証明書の有効期間の日付を設定します。証明書は、2.5 日前の発効とし、作成日から 4 年 6 か月間有効とします。

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

enigma システムの管理者が、証明書の有効期間の日付を設定します。証明書は、2 日前の発効とし、2010 年 12 月 31 日の午前 0 時まで有効とします。

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

CA からの署名付き証明書により IKE を設定する方法

認証局 (CA) からの公開鍵証明書では、外部機関とのネゴシエーションが必要となります。この証明書は非常に簡単に拡大できるため、通信するシステムを数多く保護できます。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

ikecert certlocal -kc コマンドを使用して、証明書要求を作成します。

コマンドの引数については、「自己署名付き公開鍵証明書により IKE を設定する方法」の手順 2 を参照してください。

# ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

たとえば、次のコマンドでは、partym システム上に証明書要求が作成されます。

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

次のコマンドでは、enigma システム上に証明書要求が作成されます。

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

この証明書要求を PKI 機関に送信します。

証明書要求の送信方法については PKI に問い合わせてください。ほとんどの機関は、Web サイトに送信フォームを掲載しています。フォームの記入に当たっては、その送信が正当なものであることを証明する必要があります。通常は、証明書要求をフォームに貼り付けます。要求を受け取った機関は、それをチェックしてから、次の 2 つの証明書オブジェクトと、証明書失効リストを発行します。
- 公開鍵証明書 – この証明書は機関に送信した要求に基づいて作成されます。送信した証明書要求も、公開鍵証明書の一部として含まれます。この証明書によって一意に識別されます。
- 認証局 – 機関の署名。CA によって公開鍵証明書が正規のものであることが確認されます。
- 証明書失効リスト (CRL) – 機関が無効にした証明書の最新リストです。CRL へのアクセスが公開鍵証明書に組み込まれている場合には、CRL が別個の証明書オブジェクトとして送信されることはありません。
  
  CRL の URI が公開鍵証明書に組み込まれている場合には、IKE は CRL を自動的に取り出すことができます。同様に、DN (LDAP サーバー上のディレクトリ名) エントリが公開鍵証明書に組み込まれている場合には、IKE は、指定された LDAP サーバーから CRL を取得し、キャッシュできます。
  
  公開鍵証明書に組み込まれている URI と DN エントリの例については、「証明書失効リストを処理する方法」を参照してください。

各証明書をシステムに追加します。

ikecert certdb -a コマンドの -a オプションは、張り付けられたオブジェクトをシステムの適切な証明書データベースに追加します。詳細については、「IKE と公開鍵証明書」を参照してください。
1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
2. PKI 機関から受け取った公開鍵証明書を追加します。
  # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D
3. PKI 機関の CA を追加します。
  # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D
4. PKI 機関が証明書失効リスト (CRL) を送信してきている場合は、これを certrldb データベースに追加します。
  # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

cert_root キーワードを使用して、/etc/inet/ike/config ファイルの PKI 機関を識別します。

PKI 機関が提供する名前を使用します。

たとえば、partym システムの 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-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

注 –

auth_method パラメータのすべての引数は同じ行になければなりません。

enigma システム上で、同様なファイルを作成します。

特に、enigma ike/config ファイルは、次の条件を満たしている必要があります。

cert_root には同じ値を使用する。
ローカルパラメータには enigma 値を使用する。
リモートパラメータには partym 値を使用する。
labelキーワードには一意の値を作成する。この値は、リモートシステムの label 値とは異なる値でなくてはなりません。

…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

CRL を処理する方法を IKE に伝えます。

適切なオプションを選択します。
- No CRL available
  
  PKI 機関が CRL を提供しない場合、キーワード ignore_crls を ike/config ファイルに追加します。
  # Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …
  ignore_crls キーワードにより、IKE は CRL を検索しなくなります。
- CRL available
  
  PKI 機関から CRL の一元的な配布ポイントを知らされている場合は、ike/config ファイルを変更してこの場所を指定できます。
  
  例については、「証明書失効リストを処理する方法」を参照してください。

例 23–6 IKE の設定時における `rsa_encrypt` の使用

ike/config ファイルで auth_method rsa_encrypt を使用する場合には、ピアの証明書を publickeys データベースに追加する必要があります。

その証明書をリモートシステムの管理者に送信します。

証明書は、電子メールに貼り付けることもできます。

たとえば、partym の管理者は次のような電子メールを送信します。
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----
enigma の管理者は次のような電子メールを送信します。
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----

システムごとに、電子メールで送信された証明書をローカルの publickeys データベースに追加します。

# ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

RSA 暗号化の認証方法は、IKE 内の識別子を盗聴者から隠します。rsa_encrypt メソッドはピアの識別子を隠すため、IKE はピアの証明書を取得できません。結果として、rsa_encrypt メソッドでは、IKE ピアが互いの公開鍵を知っておく必要があります。

よって、/etc/inet/ike/config ファイルの auth_method に rsa_encrypt を指定する場合には、ピアの証明書を publickeys データベースに追加する必要があります。この結果、publickeys データベースには、通信するシステムペアごとに 3 つの証明書が存在することになります。

ユーザーの公開鍵証明書
CA 証明書
ピアの公開鍵証明書

障害追跡 – IKE ペイロードは 3 つの証明書を持っており、大きくなりすぎて、rsa_encrypt が暗号化できないことがあります。「authorization failed (承認に失敗しました)」や「malformed payload (ペイロードが不正です)」などのエラーは、rsa_encrypt メソッドがペイロード全体を暗号化できないことを示します。証明書を 2 つしか必要としない rsa_sig などのメソッドを使用して、ペイロードのサイズを減らします。

ハードウェア上で公開鍵証明書を生成、格納する方法

ハードウェア上で公開鍵証明書を生成および格納することは、システム上で公開鍵証明書を生成および格納することと似ています。ハードウェア上では、ikecert certlocal および ikecert certdb コマンドがハードウェアを識別しなければなりません。トークン ID に -T オプションを指定すると、コマンドがハードウェアを識別するようになります。

始める前に

ハードウェアの設定が完了していること。
/etc/inet/ike/config ファイルの pkcs11_path キーワードが別のライブラリを指している場合を除き、ハードウェアは /usr/lib/libpkcs11.so ライブラリを使用します。ライブラリが、 RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) に準拠して実装されているライブラリ、すなわち PKCS #11 ライブラリであること。

設定の手順については、「Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法」を参照してください。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

自己署名付き証明書または証明書要求を作成して、トークン ID を指定します。

次のオプションのいずれかを選択します。

注 –

Sun Crypto Accelerator 4000 ボードは、RSA で最大 2048 ビットのキーをサポートします。DSA の場合は最大 1024 ビットになります。

自己署名付き証明書の場合、次の構文を使用する

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

-T オプションの引数は、Sun Crypto Accelerator 4000 ボードのトークン ID

証明書要求の場合、次の構文を使用します。

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

ikecert コマンドの引数の詳細については、ikecert(1M) のマニュアルページを参照してください。

PIN のプロンプトに、Sun Crypto Accelerator 4000 ユーザー、コロン、ユーザーのパスワードを入力します。

Sun Crypto Accelerator 4000 ボードのユーザー ikemgr のパスワードが rgm4tigt の場合、次のように入力します。

Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

注 –

PIN の応答は、ディスク上に「クリアテキストとして」格納されます。

パスワードの入力後、証明書が印刷されます。

Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

通信先に証明書を送信します。

次のオプションのいずれかを選択します。
- リモートシステムに自己署名付き証明書を送信します。
  
  証明書は、電子メールに貼り付けることもできます。
- PKI を処理する機関に証明書要求を送信します。
  
  証明書要求は、PKI 機関の指示に従って送信します。詳細については、「CA からの署名付き証明書により IKE を設定する方法」の手順 3 を参照してください。

システム上で、/etc/inet/ike/config ファイルを編集して、証明書が認識されるようにします。

次のオプションのどちらか 1 つを選択します。

自己署名付き証明書

リモートシステムの管理者がパラメータ cert_trust、remote_id、および remote_addr 用に提供する値を使用します。たとえば、enigma システムの ike/config ファイルは次のようになります。

# Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

証明書要求

PKI 機関が cert_root キーワードの値として提供する名前を入力します。たとえば、enigma システムの 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"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

通信先から受け取った証明書をハードウェアに格納します。

手順 3 で応答したように、PIN 要求に応答します。

注 –
公開鍵証明書は、公開鍵を生成したハードウェアに追加する必要があります。
- 自己署名付き証明書
  
  リモートシステムの自己署名付き証明書を追加します。この例では、証明書は DCA.ACCEL.STOR.CERT ファイルに格納されています。
  # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password
  自己署名付き証明書が rsa_encrypt を auth_method パラメータの値として使用していた場合、ピアの証明書をハードウェア格納場所に追加します。
- PKI 機関からの証明書
  
  機関が証明書要求から生成した証明書を追加して、認証局 (CA) を追加します。
  # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password
  # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password
  PKI 機関からの証明書失効リスト (CRL) を追加する方法については、「証明書失効リストを処理する方法」を参照してください。

証明書失効リストを処理する方法

証明書失効リスト (CRL) には、認証局が発行した証明書のうち、期限切れになったりセキュリティーが低下したりした証明書が含まれます。CRL を処理する方法には、次の 4 つがあります。

CA 機関が CRL を発行しない場合、CRL を無視するように IKE に指示する必要があります。このオプションについては、「CA からの署名付き証明書により IKE を設定する方法」の手順 6 を参照してください。
CA から受け取った公開鍵証明書に URI (Uniform Resource Indicator) のアドレスが組み込まれている場合は、URI から CRL にアクセスするように IKE に指示することができます。
CA から受け取った公開鍵証明書に LDAP サーバーの DN (ディレクトリ名) エントリが組み込まれている場合は、LDAP サーバーから CRL にアクセスするように IKE に指示することができます。
CRL は ikecert certrldb コマンドへの引数として指定できます。例については、例 23–7 を参照してください。

次の手順に、中央の配布ポイントから CRL を使用するように IKE に指示する手順を示します。

CA から受信した証明書を表示する

# ikecert certdb -lv certspec

-l: IKE 証明書データベースにある証明書を一覧表示します。
-v: 証明書を冗長モードで一覧表示します。このオプションは慎重に使用してください。
certspec: IKE 証明書データベース内の証明書と一致するパターンです。

たとえば、次の証明書は Sun Microsystems が発行しています。詳細は変更されています。

# ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl 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 (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

CRL Distribution Points エントリに注目してください。URI エントリは、この機関の CRL が Web 上にあることを示しています。DN エントリは、CRL が LDAP サーバー上にあることを示しています。一度、IKE がアクセスすると、CRL は将来に備えてキャッシュに格納されます。

CRL にアクセスするには、配布ポイントまで到達する必要があります。

中央の配布ポイントから CRL にアクセスするには、次のメソッドのうちの 1 つを選択します。
- URI を使用します。
  
  キーワード use_http をホストの /etc/inet/ike/config ファイルに追加します。たとえば、ike/config ファイルは次のようになります。
  # Use CRL from organization's URI use_http …
- Web プロキシを使用します。
  
  キーワード proxy を ike/config ファイルに追加します。キーワード proxy は、次のように引数として URL を取ります。
  # Use own web proxy 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 を保持します。

例 23–7 CRL をローカルの `certrldb` データベースに貼り付ける

使用する機関の証明書に一元的な配布ポイントが含まれていない場合は、機関の CRL を手動でローカルの certrldb データベースに追加できます。機関の説明に従って CRL をファイルに抽出し、それを ikecert certrldb -a コマンドでデータベースに追加します。

# ikecert certrldb -a < Sun.Cert.CRL

移動体システム用の IKE の設定 (作業マップ)

次の表に、中央サイトにリモートからログインするシステムを処理するように、IKE を設定する手順を示します。

タスク	説明	説明
オフサイトから中央サイトへ通信します	遠隔地のシステムが中央サイトと通信できるようにします。遠隔地のシステムは移動体システムの可能性もあります。	「遠隔地のシステム用に IKE を構成する方法」
移動体システムからのトラフィックを受信する中央システムでルート証明書と IKE を使用します	固定 IP アドレスを持たないシステムからの IPsec トラフィックを受信するゲートウェイシステムを設定します。	例 23–8
固定 IP アドレスを持たないシステムでルート証明書と IKE を使用します	中央サイト (会社の本社など) とのトラフィックを保護するように、移動体システムを設定します。	例 23–9
移動体システムからのトラフィックを受信する中央システムで自己署名付き証明書と IKE を使用します	移動体システムから IPsec トラフィックを受信するように、ゲートウェイシステムを自己署名付き証明書で設定します。	例 23–10
固定 IP アドレスを持たないシステムで自己署名付き証明書と IKE を使用します	中央サイトとのトラフィックを保護するように、移動体システムを自己署名付き証明書で設定します。	例 23–11

移動体システム用の IKE の設定

適切に設定することで、ホームオフィスやノートブックから IPsec と IKE を使用して、会社の中央コンピュータと通信できます。公開鍵認証方法と結びついたブランケット IPsec ポリシーを使用すると、遠隔地のシステムは中央システムとのトラフィックを保護できます。

遠隔地のシステム用に IKE を構成する方法

ソースと宛先を識別するために、IPsec と IKE は一意の ID を必要とします。一意の IP アドレスを持たない遠隔地のシステムまたは移動体システムの場合、別の種類の ID を使用する必要があります。システムを一意に識別するために、DNS、DN、または email などの ID の種類を使用できます。

一意の IP アドレスを持つ遠隔地のシステムまたは移動体システムで、別の種類の ID で設定するようにします。たとえば、システムが NAT 越しに中央システムに接続しようとした場合、そのシステムの一意なアドレスは使用されません。NAT ボックスが任意の IP アドレスを割り当てるため、中央システムは認識できません。

事前共有鍵は固定 IP アドレスを必要とするため、事前共有鍵も移動体システム用の認証機構としては機能しません。自己署名付き証明書 (または PKI からの証明書) を使用すると、移動体システムは中央サイトと通信できます。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

移動体システムを認識するように、中央システムを設定します。

/etc/hosts ファイルを設定します。

中央システムは、移動体システムの固有のアドレスを認識する必要はありません。
# /etc/hosts on central central 192.xxx.xxx.x

ipsecinit.conf ファイルを設定します。

中央システムには、IP アドレスの広い範囲を許可するポリシーを必要とします。そのあと、IKE ポリシーの証明書で接続システムが合法であることを確認します。
# /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ike.config ファイルを設定します。

DNS は中央システムを識別します。証明書を使用して、システムを認証します。

## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=user1@mobile.domain.org"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

各移動体システムにログインして、中央システムを見つけるように構成します。

/etc/hosts ファイルを設定します。

/etc/hosts ファイルは、移動体システムのアドレスを必要としませんが、提供することは可能です。このファイルは、中央システムの公開 IP アドレスを含んでいる必要があります。
# /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x

ipsecinit.conf ファイルを設定します。

移動体システムは、公開 IP アドレスで中央システムを見つける必要があります。システムは同じ IPsec ポリシーで設定する必要があります。
# /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ike.config ファイルを設定します。

識別子は IP アドレスであってはなりません。移動体システムに有効な識別子は次のとおりです。

DN=ldap-directory-name
DNS=domain-name-server-address
email=email-address

証明書を使用して、移動体システムを認証します。

## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=user1@domain.org"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

IKE の設定をカーネルに読み込みます。
- Solaris 10 4/09 リリース以降では、ike サービスを使用可能にします。
  # svcadm enable svc:/network/ipsec/ike
- Solaris 10 4/09 リリースより前のリリースを実行している場合は、システムを再起動します。
  # init 6
  あるいは、in.iked デーモンを停止および起動します。

例 23–8 移動体システムからの IPsec トラフィックを受信するための中央コンピュータの設定

IKE は、NAT ボックス越しのネゴシエーションを開始できます。しかし、IKE の理想的な設定は NAT ボックスをはさまないことです。次の例では、ルート証明書は CA によって発行されています。CA 証明書は、移動体システムと中央システムに格納されています。中央システムは NAT 越しのシステムからの IPsec ネゴシエーションを受け入れます。main1 は、遠隔地のシステムからの接続を受け入れることができる会社のシステムです。遠隔地のシステムを設定する方法については、例 23–9 を参照してください。

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}

例 23–9 NAT 越しのシステムの IPsec による設定

次の例では、ルート証明書は CA によって発行されており、移動体システムと中央システムに格納されています。mobile1 は、家から会社の本社に接続しています。インターネットサービスプロバイダ (ISP) ネットワークは NAT ボックスを使用しているため、ISP はmobile1 に非公開アドレスを割り当てることができます。NAT ボックスは、非公開アドレスを公開 IP アドレスに変換します。この公開アドレスは、ほかの ISP ネットワークノードと共有されます。企業の本社は NAT を越えません。企業の本社のコンピュータを設定する方法については、例 23–8 を参照してください。

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

例 23–10 移動体システムからの自己署名付き証明書の受け入れ

次の例では、自己署名付き証明書が発行されており、移動体システムと中央システムに格納されています。main1 は、遠隔地のシステムからの接続を受け入れることができる会社のシステムです。遠隔地のシステムを設定する方法については、例 23–11 を参照してください。

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

例 23–11 自己署名付き証明書による中央システムとの接続

次の例では、mobile1 は家から会社の本社に接続しています。自己署名付き証明書が発行されており、移動体システムと中央システムに格納されています。ISP ネットワークは NAT ボックスを使用しているため、ISP は mobile1 に非公開アドレスを割り当てることができます。NAT ボックスは、非公開アドレスを公開 IP アドレスに変換します。この公開アドレスは、ほかの ISP ネットワークノードと共有されます。企業の本社は NAT を越えません。企業の本社のコンピュータを設定する方法については、例 23–10 を参照してください。

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

接続したハードウェアを検出するための IKE の設定 (作業マップ)

次の表に、接続したハードウェアを IKE に伝える手順を示します。IKE がハードウェアを使用できるようにするには、接続したハードウェアを IKE に伝える必要があります。ハードウェアを使用する手順については、「公開鍵証明書による IKE の設定」を参照してください。

注 –

オンチップハードウェアについては、IKE に通知する必要はありません。たとえば、UltraSPARC® T2 プロセッサには暗号化促進機能がありますが、オンチップアクセラレータを検出するよう IKE を構成する必要はありません。

作業	説明	説明
IKE キーの操作を Sun Crypto Accelerator 1000 ボードで行います	IKE を PKCS #11 ライブラリにリンクする	「Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法」
IKE キーの操作とキーの格納を Sun Crypto Accelerator 4000 ボードで行います	IKE を PKCS #11 ライブラリにリンクして、接続されたハードウェアの名前のリストを表示する	「Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法」

接続したハードウェアを検出するように IKE を設定する

公開鍵証明書は、接続されたハードウェアに格納することもできます。Sun Crypto Accelerator 1000 ボードが提供するのはストレージのみです。Sun Crypto Accelerator 4000 および Sun Crypto Accelerator 6000 ボードによってストレージが提供され、公開鍵の操作をシステムからこのボードに移行することができます。

Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法

始める前に

次の手順では、Sun Crypto Accelerator 1000 ボードがシステムに接続されていると仮定します。さらに、ボードに必要なソフトウェアがすでにインストールされ、構成されているものとします。手順については、『Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide 』を参照してください。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

PKCS #11 ライブラリがリンクされていることを確認します。

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 /usr/lib/libpkcs11.so
#

Solaris 10 1/06: このリリース以降では、ソフトトークンキーストアにキーを格納できます。

Solaris 暗号化フレームワークが提供するキーストアについては、cryptoadm(1M) のマニュアルページを参照してください。キーストアを使用する例については、Example 23–12 を参照してください。

Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法

始める前に

次の手順では、Sun Crypto Accelerator 4000 ボードがシステムに接続されていると仮定します。さらに、ボードに必要なソフトウェアがすでにインストールされ、構成されているものとします。手順については、『Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide』を参照してください。

Sun Crypto Accelerator 6000 ボードを使用している場合、手順については、『Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide』を参照してください。

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

PKCS #11 ライブラリがリンクされていることを確認します。

IKE はライブラリのルーチンを使用して、Sun Crypto Accelerator 4000 ボード上でキーの生成および格納処理を行います。PKCS #11 ライブラリがリンクされていることを確認するには、次のコマンドを実行します。
$ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $
注 –
Sun Crypto Accelerator 4000 ボードは、RSA で最大 2048 ビットのキーをサポートします。DSA の場合は最大 1024 ビットになります。

接続された Sun Crypto Accelerator 4000 ボードのトークン ID を見つけます。
$ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot "
ライブラリは、32 文字のトークン ID (キーストア名とも呼ぶ) を戻します。この例では、ikecert コマンドに Sun Metaslot トークンを使用すると、IKE 鍵を格納および高速化できます。

トークンを使用する手順については、「ハードウェア上で公開鍵証明書を生成、格納する方法」を参照してください。

ikecert コマンドにより、後続スペースが自動的に付加されます。

例 23–12 メタスロットトークンの検索と使用

トークンは、ディスク、接続されたボード、または Solaris 暗号化フレームワークが提供するソフトトークンキーストアに格納できます。次に、ソフトトークンキーストアのトークン ID の例を示します。

$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

ソフトトークンキーストアのパスフレーズを作成する方法については、pktool(1) のマニュアルページを参照してください。

次に、ソフトトークンキーストアに証明書を追加するコマンドの例を示します。Sun.Metaslot.cert は、CA 証明書を格納しているファイルです。

# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

IKE 転送パラメータの変更 (作業マップ)

次の表に、IKE 用の転送パラメータを構成する手順を示します。

タスク	説明	説明
鍵ネゴシエーションをより効率的にします	鍵ネゴシエーションパラメータを変更します。	「フェーズ 1 IKE 鍵ネゴシエーションの持続時間を変更する方法」
転送で遅延を許可するように鍵ネゴシエーションを構成します	鍵ネゴシエーションパラメータを長くします。	例 23–13
すばやく成功したり、すばやく障害を見つけるように鍵ネゴシエーションを構成します	鍵ネゴシエーションパラメータを短くします。	例 23–14

IKE 転送パラメータの変更

IKE が鍵ネゴシエーションを行うとき、転送速度がネゴシエーションの成功に影響します。通常、IKE 転送パラメータのデフォルト値を変更する必要はありません。しかし、非常に悪い回線で鍵ネゴシエーションを最適化したり、問題を再現したりするときには、転送パラメータの値を変更してもかまいません。

持続時間を長くすると、信頼性の低い転送回線で鍵ネゴシエーションを行うことができます。初期試行が成功するためには、特定のパラメータを長くします。初期試行が成功しない場合、後続の試行の間を空けることによって、ネゴシエーション全体が成功する時間を提供できます。

持続時間を短くすると、信頼性の高い転送回線で鍵ネゴシエーションを行うことができます。持続時間が短くなると、ネゴシエーションが失敗したときに素早く再試行するため、ネゴシエーション全体の速度が上がります。問題を診断するときにも、ネゴシエーションの速度を上げると、障害をすばやく再現できます。持続時間を短くすると、フェーズ 1 SA が自分の寿命に使用できるようになります。

フェーズ 1 IKE 鍵ネゴシエーションの持続時間を変更する方法

システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

注 –
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

各システムのグローバル転送パラメータのデフォルト値を変更します。

システムごとに、/etc/inet/ike/config ファイルのフェーズ 1 持続時間パラメータを変更します。

### ike/config file on system

## Global parameters
#
## Phase 1 transform defaults
#
#expire_timer      300
#retry_limit         5
#retry_timer_init    0.5 (integer or float)
#retry_timer_max    30   (integer or float)

expire_timer: 完了していない IKE フェーズ 1 ネゴシエーションを残しておく秒数。この時間が過ぎると、ネゴシエーションの試行は削除されます。デフォルトは 30 秒です。
retry_limit: 再転送の最大数。この回数を過ぎると、IKE ネゴシエーションは中断されます。デフォルトは 5 回です。
retry_timer_init: 再転送の間隔の初期値。retry_timer_max 値に到達するまで、再転送ごとに、その間隔は 2 倍にされます。デフォルトは 0.5 秒です。
retry_timer_max: 再転送の間隔の最大値。再転送の間隔は、この値より大きくはなりません。デフォルトは 30 秒です。

変更した設定をカーネルに読み込みます。
- Solaris 10 4/09 リリース以降では、ike サービスを更新します。
  # svcadm refresh svc:/network/ipsec/ike
- Solaris 10 4/09 リリースより前のリリースを実行している場合は、システムを再起動します。
  # init 6
  あるいは、in.iked デーモンを停止および起動します。

例 23–13 IKE フェーズ 1 ネゴシエーションの時間を長くする

次の例では、システムと IKE ピアはトラフィックが多い転送回線で接続されています。オリジナルの設定は、ファイルのコメント行にあります。新しい設定は、ネゴシエーションの時間を長くしています。

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180

例 23–14 IKE フェーズ 1 ネゴシエーションの時間を短くする

次の例では、システムと IKE ピアはトラフィックが少ない高速回線で接続されています。オリジナルの設定は、ファイルのコメント行にあります。新しい設定は、ネゴシエーションの時間を短くしています。

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20

第 23 章 IKE の設定 (手順)

IKE の設定 (作業マップ)

事前共有鍵による IKE の設定 (作業マップ)

事前共有鍵による IKE の設定

事前共有鍵により IKE を設定する方法

例 23–1 オペレーティングシステムの異なる 2 つのシステムに対して同じ鍵情報を生成する

IKE の事前共有鍵を更新する方法

IKE の事前共有鍵を表示する方法

始める前に

例 23–2 Solaris 10 4/09 リリースより前のリリースで IKE の事前共有鍵を確認する

ipsecinit.conf の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法

始める前に

例 23–3 新しい IPsec ポリシーエントリに IKE 事前共有鍵を追加する

事前共有鍵が同一であることを確認する方法

始める前に

公開鍵証明書による IKE の設定 (作業マップ)

公開鍵証明書による IKE の設定

自己署名付き公開鍵証明書により IKE を設定する方法

例 23–4 別の管理者の証明書が有効かどうかを確認する

例 23–5 証明書の開始時間と終了時間を指定する

CA からの署名付き証明書により IKE を設定する方法

例 23–6 IKE の設定時における rsa_encrypt の使用

ハードウェア上で公開鍵証明書を生成、格納する方法

始める前に

証明書失効リストを処理する方法

例 23–7 CRL をローカルの certrldb データベースに貼り付ける

移動体システム用の IKE の設定 (作業マップ)

移動体システム用の IKE の設定

遠隔地のシステム用に IKE を構成する方法

例 23–8 移動体システムからの IPsec トラフィックを受信するための中央コンピュータの設定

例 23–9 NAT 越しのシステムの IPsec による設定

例 23–10 移動体システムからの自己署名付き証明書の受け入れ

例 23–11 自己署名付き証明書による中央システムとの接続

接続したハードウェアを検出するための IKE の設定 (作業マップ)

接続したハードウェアを検出するように IKE を設定する

Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法

始める前に

Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法

始める前に

例 23–12 メタスロットトークンの検索と使用

IKE 転送パラメータの変更 (作業マップ)

IKE 転送パラメータの変更

フェーズ 1 IKE 鍵ネゴシエーションの持続時間を変更する方法

例 23–13 IKE フェーズ 1 ネゴシエーションの時間を長くする

例 23–14 IKE フェーズ 1 ネゴシエーションの時間を短くする

`ipsecinit.conf` の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法

例 23–6 IKE の設定時における `rsa_encrypt` の使用

例 23–7 CRL をローカルの `certrldb` データベースに貼り付ける