test

IPsec と IKE の管理

第 4 章 IKE の管理 (手順)

この章では、使用するシステムにあわせて IKE を設定する方法について説明します。IKE の設定が完了すると、そのネットワークにおける IPsec のキー情報が自動的に生成されます。IKE の設定 (作業マップ)に、この章で説明する手順を一覧表示します。

IKE の概要については、第 3 章「インターネットキー交換 (概要)」を参照してください。ikeadm(1M)、ikecert(1M)、ike.config(4) の各マニュアルページの「EXAMPLES」セクションには、有益な手順が記載されています。

IKE の設定 (作業マップ)

作業 

説明 

参照先 

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

2 つのシステムに秘密鍵を共有させることにより、その通信を保護する 

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

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

公開鍵証明書を使って通信を保護する。証明書は、自己署名付き、または PKI 機関の保証付き 

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

公開鍵証明書を生成し、接続されたハードウェアに格納する設定 

Sun Crypto Accelerator 1000 ボードまたは Sun Crypto Accelerator 4000 ボードを使って IKE 操作を高速化する。Sun Crypto Accelerator 4000 ボードには、公開鍵証明書も格納できる 

IKE とハードウェアの使用 (作業マップ)

役割を使って IKE を設定する方法については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (手順)」を参照してください。

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

作業 

説明 

参照先 

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

有効な IKE ポリシーファイルと ike.preshared ファイルを作成する。また、システムをブートして IKE によって生成された鍵を使用する前に、IPsec ファイルも設定する

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

実行中の IKE システムでの事前共有鍵の更新 

IKE 権限レベルをチェックし、通信するシステムの ipseckeys ファイルに最新のキー情報を追加する

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

実行中の IKE システムへの事前共有鍵の追加 

IKE 権限レベルをチェックし、通信するシステムの最新キー情報に応じて ikeadm コマンドを実行する

新しい事前共有鍵を追加する方法

事前共有鍵が同一であることのチェック 

両方のシステムの事前共有鍵のダンプを行う 

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

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

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

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

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

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

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

    これらの規則やグローバルパラメータは、システムの ipsecinit.conf ファイルに設定されている IPsec ポリシーが正しく動作するものでなければなりません。次の ike/config の例は、2 つのシステム間のトラフィックを保護する方法の ipsecinit.conf の例に対応しています。

    1. たとえば、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 パラメータのすべての引数は同じ行になければなりません。

    2. 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 "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
}

  4. システムごとに、次のように指定してファイルが有効であるかどうかをチェックします。


    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. キー情報として使用する乱数を生成します。

    乱数発生関数がすでにある場合は、それを使用してください。Solaris システムでは、od コマンドを使用できます。たとえば、次のコマンドを入力すると、16 進数の数値が 2 行に渡って表示されます。


    % od -X -A n /dev/random | head -2
         f47cb0f4 32e14480 951095f8 2b735ba8
         0a9467d0 8f92c880 68b6a40e 0efe067d

    od コマンドの説明については、乱数を生成する方法と od(1) のマニュアルページを参照してください。

  6. 手順 5 の出力から、キーを 1 つ作成します。


    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    この手順の認証アルゴリズムは MD5 です (手順 3 を参照)。事前共有鍵として推奨する最小のサイズは、ハッシュのサイズ (つまり、認証アルゴリズムの出力のサイズ) で決まります。MD5 アルゴリズムの出力は 128 ビットすなわち 32 文字です。この例の鍵は、推奨されている最小文字数より長い 56 文字です。

  7. システムごとに /etc/inet/secret/ike.preshared ファイルを作成します。各ファイルに事前共有鍵を書き込みます。

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

    2. 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
	}
    注 –

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

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

この手順では、リブートすることなく、一定の間隔で既存の事前共有鍵を置き換えたい場合を想定しています。3DES や Blowfish などの強力な暗号化アルゴリズムを使用するときは、両方のシステムのリブート時に鍵を変更するようスケジュールしたほうがよい場合もあります。

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

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

    詳細については、乱数を生成する方法を参照してください。

  3. システムごとに /etc/inet/secret/ike.preshared ファイルを編集して、現在のキーを新しいキーに変更します。

    たとえば、ホスト enigma と partym で、key の値をそれと同じ長さの新しい数値で置き換えます。

  4. in.iked デーモンがキー情報の変更を許可するかどうか確認します。


    # /usr/sbin/ikeadm get priv
Current privilege level is 0x2, access to keying material enabled

    コマンドから 0x1 または 0x2 の権限レベルが戻された場合には、キー情報を変更できます。レベル 0x0 の場合には、キー情報を操作できません。デフォルトでは、in.iked デーモンは 0x0 の権限レベルで実行されます。

  5. in.iked デーモンがキー情報の変更を許可する場合は、ike.preshared ファイルの新しいバージョンを読み込みます。


    # ikeadm read preshared

  6. in.iked デーモンがキー情報の変更を許可しない場合は、デーモンを強制終了してから再起動します。


    # pkill in.iked
# /usr/lib/inet/in.iked

    デーモンは再起動時に ike.preshared ファイルの新しいバージョンを読み込みます。

新しい事前共有鍵を追加する方法

ipsecinit.conf ファイルのポリシーエントリごとに 1 つの事前共有鍵が必要です。IPsec と IKE が動作している間に新しいポリシーエントリを追加すれば、in.iked デーモンはそれらの新しい鍵を読み込むことができます。この手順では、次の条件がすでにそろっているものとします。

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. in.iked デーモンがキー情報の変更を許可するかどうか確認します。


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

    コマンドから 0x1 または 0x2 の権限レベルが戻された場合には、キー情報を変更できます。レベル 0x0 の場合には、キー情報を操作できません。デフォルトでは、in.iked デーモンは 0x0 の権限レベルで実行されます。

  3. in.iked デーモンがキー情報の変更を許可しない場合は、デーモンを強制終了します。次に、正しい権限レベルでデーモンを再起動します。


    # pkill in.iked
# /usr/lib/inet/in.iked -p 2
Setting priv/usr/lib/inet/in.iked -pilege level to 2!

  4. 乱数を生成し、64 〜 448 ビットのキーを作成します。

    詳細については、乱数を生成する方法を参照してください。

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

    両者は、同じ事前共有鍵を同時に追加する必要があります。

  6. 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

    id-type が IP のとき IP アドレスを指定する

    mode

    IKE モードを指定する。有効な値は main だけ

    key

    16 進数の事前共有鍵を指定する

    1. たとえば、ホスト enigma で新しいインタフェース ada 用のキーを追加します。


      # 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.

    2. ホスト ada でも、同じキーを追加します。


      # 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.

  7. ikeadm コマンドモードを終了します。


    ikeadm> exit
#

  8. システムごとに、in.iked デーモンの権限レベルを低くします。


    # ikeadm set priv base

  9. システムごとに、ipsecinit.conf ファイルを有効にして、追加したインタフェースを保護します。


    # ipsecconf -a /etc/inet/ipsecinit.conf
    注意 – 注意 –

    ipsecconf コマンドの実行時には警告を読んでください。in.iked デーモンの再起動時にも、同じ警告が表示されます。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。詳細については、ipsecinit.conf と ipsecconf のセキュリティについてを参照してください。

  10. システムごとに、ikeadm コマンドを実行して新しい規則を読み込みます。


    # ikeadm read rules

    ada および enigma システムの新しい規則の例がこの手順の始めにあります。規則は /etc/inet/ike/config ファイルに格納されているため、ikeadm コマンドでファイル名を指定する必要はありません。

  11. IKE 事前共有鍵がリブート時に確実に使用できるように、この鍵を /etc/inet/secret/ike.preshared ファイルに追加します。

    1. たとえば、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 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

    2. 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
}

  12. 両システムが通信できることを確認します。事前共有鍵が同一であることを確認する方法を参照してください。

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

通信する各システムの事前共有鍵が同一でない場合は、次のエラーメッセージが表示されます。


# rup system2
system2: RPC: Rpcbind failure

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. in.iked デーモンがキー情報の変更を許可していることを確認します。


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

    権限レベル 0x2 が返される場合は、キー情報を表示できます。レベル 0x0 の場合には、キー情報を操作できません。デフォルトでは、in.iked デーモンは、0x0 の権限レベルで実行されます。

  3. in.iked デーモンがキー情報の表示を許可しない場合は、このデーモンを強制終了します。次に、正しい権限レベルでデーモンを再起動します。


    # pkill in.iked
# /usr/lib/inet/in.iked -p 2
Setting priv/usr/lib/inet/in.iked -pilege level to 2!

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


    # 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).

  5. 両方のダンプを比較します。

    事前共有鍵が同一でない場合は、/etc/inet/secret/ike.preshared ファイルで、一方のキーを他方のキーで置き換えます。

  6. 確認が終わったら、in.iked デーモンの権限レベルを低くします。


    # ikeadm set priv base

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

作業 

説明 

参照先 

自己署名付き公開鍵証明書による IKE の設定 

ikecert certlocal -ks コマンドを指定して自己署名付き証明書を作成し、ikecert certdb コマンドを指定してリモートシステムからの公開鍵を追加する

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

PKI 認証局による IKE の設定 

ikecert certlocal -kc コマンドの出力を PKI 機関に送信し、その機関からの公開鍵、CA、および CRL を追加する

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

ローカルハードウェア上での公開鍵証明書の設定 

次のいずれかの作業を行う  

  • ローカルハードウェア上で自己署名付き証明書を生成し、リモートシステムの公開鍵をハードウェアに追加する

  • ローカルハードウェア上で証明書要求を生成し、PKI 機関から取得した公開鍵証明書をハードウェアに追加する

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

PKI 機関から取得した証明書無効リスト (CRL) の更新 

中央の配布ポイントから CRL にアクセスする 

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

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

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

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


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

    自己署名付き証明書を作成する

    -kc

    証明書要求を作成する。手順は CA からの署名付き証明書による IKE の設定方法を参照

    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

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

    2. 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-----

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

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

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


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

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


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

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

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

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


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

cert_trust "192.168.13.213"
cert_trust "192.168.116.16"

## 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_encrypt oakley_group 2 auth_alg md5 encr_alg 3des}
}

    2. 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
…

  5. システムごとに、受け取った証明書を追加します。

    1. 管理者の電子メールから公開鍵をコピーします。

    2. ikecert certdb –a コマンドを入力後、Return キーを押します。

      Return キーを押してもプロンプトは表示されません。


      # ikecert certdb -a
Return キーを押す

    3. 公開鍵を貼り付けます。続いて Return キーを押します。Control-D キーを押して入力を終了します。


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE-----
Return キーを押す
<Control>-D

  6. 通信するシステムの管理者と一緒にキーが改ざんされていないことを確認します。

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

    1. たとえば、partym システムで、格納されている証明書を一覧表示します。


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5
    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
    (Private key in certlocal slot 0)
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. enigma システムで、格納されている証明書を一覧表示します。


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5
    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
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
    注 –

    この例の公開鍵ハッシュは、使用しているシステムで生成される公開鍵ハッシュとは異なります。

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

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. ikecert certlocal -kc コマンドを実行して証明書要求を作成します。

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


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

    1. たとえば、次のコマンドでは、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-----

    2. 次のコマンドでは、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-----

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

    証明書要求の送信方法については PKI に問い合わせてください。ほとんどの機関は、Web サイトに送信フォームを掲載しています。フォームの記入に当たっては、その送信が正当なものであることを証明する必要があります。通常は、証明書要求をフォームに貼り付けます。要求を受け取った機関は、それをチェックしてから、次の 2 つの証明書オブジェクトと、証明書無効リストを発行します。

    • 公開鍵証明書 – この証明書は機関に送信した要求に基づいて作成される。送信した証明書要求も、公開鍵証明書の一部として含まれる。この証明書によって一意に識別される

    • 認証局 – 機関の署名。CA によって公開鍵証明書が正規のものであることが確認される

    • 証明書無効リスト – 機関が無効にした証明書の最新リスト。CRL へのアクセスが公開鍵証明書に組み込まれている場合には、CRL が別個の証明書オブジェクトとして送信されることはない

      CRL の URI が公開鍵証明書に組み込まれている場合には、IKE は CRL を自動的に取り出すことができる。同様に、DN (LDAP サーバー上のディレクトリ名) エントリが公開鍵証明書に組み込まれている場合には、IKE は、指定された LDAP サーバーから CRL を取得し、キャッシュすることができる

      公開鍵証明書に URI や DN エントリを組み込んだ例については、証明書無効リストを処理する方法を参照

  4. ikecert certdb -a コマンドを使って、各証明書をシステムに追加します。

    -a オプションを指定すると、貼り付けたオブジェクトが、システム内の適切な証明書データベースに追加されます。詳細は、IKE と公開鍵証明書を参照してください。

    1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    2. PKI 機関から受け取った公開鍵証明書を追加します。


      # ikecert certdb -a
Return キーを押す
証明書を貼り付ける
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Return キーを押す
<Control>-D

    3. PKI 機関の CA を追加します。


      # ikecert certdb -a
Return キーを押す
CA を貼り付ける
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Return キーを押す
<Control>-D

    4. PKI 機関が証明書無効リスト (CRL) を送信してきている場合は、これを certrldb データベースに追加します。


      # ikecert certrldb -a
Return キーを押す
CRL を貼り付ける
-----BEGIN CRL-----
…
-----END CRL----
Return キーを押す
<Control>-D

  5. /etc/inet/ike/config ファイルを編集して、PKI 機関が認識されるようにします。

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

    1. たとえば、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_encrypt oakley_group 2 auth_alg md5 encr_alg 3des}
}
      注 –

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

    2. enigma システムで、ローカルパラメータに enigma 値、リモートパラメータに partym 値を使用します。

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


      …
{
 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
…

  6. PKI 機関から CRL を受け取っていない場合は、キーワード ignore_crls を ike/config ファイルに追加します。


    # Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
ignore_crls
…

    ignore_crls キーワードにより、IKE は CRL を検索しなくなります。

  7. PKI 機関から CRL の一元的なディストリビューションポイントを知らされている場合は、ike/config ファイルを変更してこの場所を指定することができます。

    例については、証明書無効リストを処理する方法 を参照してください。

    注 –

    次の手順は、/etc/inet/ike/config ファイル内の auth_method に rsa_encrypt が設定されている場合にのみ必要です。

  8. auth_method パラメータが rsa_encrypt に設定されているので、ピアの証明書を publickeys データベースに追加します。

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

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

      1. たとえば、partym の管理者は次のような電子メールを送信します。


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

      2. enigma の管理者は次のような電子メールを送信します。


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

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


      # ikecert certdb -a
Return キーを押す
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Return キーを押す
<Control>-D

    RSA 暗号化認証方式を使用すると、IKE の ID が盗聴者から保護されます。rsa_encrypt 方式では ID が隠されるため、IKE はピアを知りません。そのため、ピアの証明書を取り出すことはできません。したがって、その方式では、IKE ピアが互いの公開鍵を認識することが必要になります。よって、/etc/inet/ike/config ファイルの auth_method に rsa_encrypt を指定する場合には、ピアの証明書を publickeys データベースに追加する必要があります。この結果、publickeys データベースには、通信するシステムペアごとに 3 つの証明書が存在することになります。

    • ユーザーの公開鍵証明書

    • CA 証明書

    • ピアの公開鍵証明書

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

ハードウェア上で公開鍵および公開鍵証明書を生成、格納するための要件は、次のとおりです。

ハードウェア上で公開鍵証明書を生成、格納する方法は、システム上で公開鍵証明書を生成、格納する方法とほぼ同じです。違いは次の 2 点です。

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. 自己署名付き証明書か証明書要求を生成し、トークン ID を指定します。次のオプションのどれか 1 つを選択します。

    注 –

    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 SUN-4000-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
-----BEGIN X509 CERTIFICATE-----
MIIBwjCCASsCBD9bz5swDQYJKoZIhvcNAQEEBQAwKDELMAkGA1UEBhMCVVMxGTAX
…
PiktCuvURc1TXswaFyftzmLKWafUOQ==
-----END X509 CERTIFICATE-----

      -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 SUN-4000-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

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

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

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


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    注 –

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

  4. 通信先に証明書を送信します。次のオプションのどれか 1 つを選択します。

    • リモートシステムに自己署名付き証明書を送信します。証明書は、電子メールに貼り付けることもできます。

    • PKI を処理する機関に証明書要求を送信します。証明書要求は、PKI 機関の指示に従って送信します。詳細については、CA からの署名付き証明書による IKE の設定方法の手順 3 を参照してください。

  5. システム上で、/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"  ローカルシステムの証明書
cert_trust "192.168.13.213"  リモートシステムの証明書

pkcs11_path "/opt/SUNWconn/lib/libpkcs11.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_encrypt oakley_group 2 auth_alg md5 encr_alg 3des}
}

    • 証明書要求の場合は、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"

pkcs11_path "/opt/SUNWconn/lib/libpkcs11.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_encrypt oakley_group 2 auth_alg md5 encr_alg 3des}
}

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

    手順 3 の場合と同様に、PIN 要求に応答します。

    注 –

    公開鍵証明書は、公開鍵を生成したハードウェアに追加する必要があります。

    • 自己署名付き証明書の場合、リモートシステムの自己署名付き証明書を追加します。


      # ikecert certdb -a -T SUN-4000-stor
Return キーを押す
自己署名付き証明書を貼り付ける
<Control>-D
Enter PIN for PKCS#11 token: ユーザー名とパスワードを入力する

      自己署名付き証明書の auth_method パラメータの値として rsa_encrypt を使用した場合、ハードウェアストアにピアの証明書を追加します。


      # ikecert certdb -a -T SUN-4000-stor
Return キーを押す
ピアの証明書を貼り付ける
<Control>-D
Enter PIN for PKCS#11 token: ユーザー名とパスワードを入力する

    • PKI 機関の証明書の場合、その機関が証明書要求に応じて発行した証明書と、認証局 (CA) を追加します。


      # ikecert certdb -a -T SUN-4000-stor
 Return キーを押す
PKI が発行した証明書を貼り付ける
<Control>-D
Enter PIN for PKCS#11 token: ユーザー名とパスワードを入力する


      # ikecert certdb -a -T SUN-4000-stor
Return キーを押す
CA 証明書を貼り付ける
<Control>-D
Enter PIN for PKCS#11 token: ユーザー名とパスワードを入力する

      PKI 機関から取得した証明書無効リスト (CRL) を追加する方法については、証明書無効リストを処理する方法を参照してください。

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

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

次の手順は、一元的なディトリビューションポイントの CRL を使用するように IKE に指示する方法を示しています。

  1. 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 サーバー上にもあることを示しています。ユーザーはこれら 2 つのうちのどちらかを使用できます。

  2. URI を使用する場合は、ホストの /etc/inet/ike/config ファイルにキーワード use_http を追加します。

    たとえば、ike/config ファイルは次のようになります。


    # Use CRL from organization's URI
use_http
…

    キーワード proxy を ike/config ファイルに追加して、Web プロキシを使用することもできます。キーワード proxy は、次のように引数として URL を取ります。


    proxy "http://proxy1:8080"

    IKE は CRL を取り出し、証明書の期限が切れるまで CRL を保持します。

  3. 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 を手動でローカルの certrldb データベースに追加できます。その場合は、機関の説明に従って CRL を抽出し、それを ikecert certrldb –a コマンドでデータベースに追加します。


# ikecert certrldb -a
Return キーを押す
PKI 機関からの CRL を貼り付ける
Return キーを押す
<Control>-D を押して CRL をデータベースに追加する

IKE とハードウェアの使用 (作業マップ)

作業 

説明 

参照先 

IKE キーの操作を Sun Crypto Accelerator 1000 ボードで行う 

PKCS#11 ライブラリのパス設定を行う 

IKE で Sun Crypto Accelerator 1000 ボードを使用する方法

IKE キーの操作とキーの格納を Sun Crypto Accelerator 4000 ボードで行う 

PKCS#11 ライブラリのパス設定と、使用可能なトークン ID の一覧表示を行う 

IKE で Sun Crypto Accelerator 4000 ボードを使用する方法

IKE で Sun Crypto Accelerator 1000 ボードを使用する方法

注 –

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

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. PKCS#11 ライブラリパスを /etc/inet/ike/config ファイルに追加します。


    pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"

    パス名は 32 ビット PKCS #11 ライブラリを指していなければなりません。ライブラリが存在していれば、IKE は、ライブラリのルーチンを使用して、Sun Crypto Accelerator 1000 ボード上の IKE 公開鍵操作を高速化します。ボードがこのような重い操作を行っている間、オペレーティングシステムのリソースは他の操作に使用できます。

  3. ファイルを閉じてからリブートします。

  4. リブートしたら、ライブラリがリンクされていることを確認します。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 データの一部です。

IKE で Sun Crypto Accelerator 4000 ボードを使用する方法

注 –

次の手順では、Sun Crypto Accelerator 4000 ボードがすでにシステムに取り付けられているものとします。さらに、ボードに必要なソフトウェアがすでにインストールされ、構成されているものとします。詳細については、『Sun Crypto Accelerator 4000 Board Installation and User's Guide』を参照してください。このマニュアルには、Sun Hardware Documentation の Web サイトの「Network and Security Products」の下からアクセスできます。

  1. システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。

    注 –

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

  2. PKCS #11 ライブラリパスを /etc/inet/ike/config ファイルに追加します。


    pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"

    パス名は 32 ビット PKCS #11 ライブラリを指していなければなりません。ライブラリが存在していれば、IKE はライブラリのルーチンを使用して、Sun Crypto Accelerator 4000 ボード上でキー生成および格納処理を行います。

  3. ファイルを閉じてからリブートします。

  4. リブートしたら、ライブラリがリンクされていることを確認します。PKCS #11 ライブラリがリンクされていることを確認するには、次のコマンドを実行します。


    $ ikeadm get stats
…
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 のデータを保持するためです。

    注 –

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

  5. 接続されている Sun Crypto Accelerator 4000 ボードのトークン ID を検索します。


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

"SUN-1000-accel                 "
"SUN-4000-stor                  "

    ライブラリは 32 文字のトークン ID (キーストア名) を返します。この例では、ikecert コマンドに SUN-4000-stor トークンを指定して IKE キーを格納します。

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

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