この章では、Secure RPC で使用できる Diffie-Hellman 認証メカニズムについて説明します。
この章の内容は次のとおりです。
Secure RPC は、サービスを要求するホストとユーザーを認証するための認証方式です。Secure RPC では、Diffie-Hellman 認証メカニズムを使用しています。この認証メカニズムは DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。
NFS を使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS サービスでは、サーバーは、複数のクライアントから利用できるデータとリソースを保持します。クライアントは、サーバーがクライアントと共有するファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS の最も一般的な使用形態の 1 つは、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理することです。mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限を持たないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。
NFS サービスでは Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。このプロセスは、Secure NFS と呼ばれます。AUTH_DH
認証メカニズムは、Diffie-Hellman 認証で DES 暗号化を使用し、認証されたアクセスを保障します。AUTH_DH
メカニズムは、AUTH_DES
とも呼びます。
Secure NFS の設定と管理については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「Secure NFS システムの管理」を参照してください。
NIS+ テーブルの設定と cred テーブルへの名前の入力については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
RPC 認証手順の概要については、Diffie-Hellman 認証の実装を参照してください。
データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー、すなわちプリンシパルが同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。DES チップは暗号化をより高速にします。ただし、チップがなくても、ソフトウェアで代用できます。
DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号を使用します。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細は、第 7 章「SEAM について」を参照してください。
Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、独自の非公開鍵と公開鍵を使って共通鍵を作り出します。非公開鍵は秘密鍵とも呼ばれます。クライアントとサーバーは、相互に合意した暗号化機能 (DES など) と共通鍵を使って相互に通信します。この方式は、以前の Solaris リリースの DES 認証と同じです。
認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。
公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、これらの鍵を publickey マップに格納します。NIS+ では、cred テーブルに格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。
システム管理者は、NIS マップまたは NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する必要があります。非公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これにより、その非公開鍵はそのユーザーだけが知っていることになります。
この節では、DH 認証 (AUTH_DH
) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。
システム管理者は、認証を開始する前に、 newkey または nisaddcred コマンドを実行して公開鍵と秘密鍵を生成します。ユーザーごとに一意の公開鍵と秘密鍵が与えられます。公開鍵は、公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。公開鍵と秘密鍵のペアを変更するには、chkey コマンドを使用します。
通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin コマンドは必要ありません。ただし、これらのパスワードが異なる場合は、ユーザーはログインするときに keylogin コマンドを明示的に実行する必要があります。
keylogin コマンドを入力すると、Secure RPC パスワードの入力を求めるプロンプトが表示されます。コマンドは、このパスワードを使って秘密鍵を復号化します。次に keylogin コマンドは、復号化された秘密鍵をキーサーバーと呼ばれるプログラムに渡します。キーサーバーは 、各コンピュータ上でローカルインスタンスを伴う RPC サービスです。キーサーバーは、復号化された秘密鍵を格納し、ユーザーとサーバーが Secure RPC トランザクションを開始するのを待機します。
ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なり、ユーザーが常に keylogin コマンドを実行する必要がある場合は、keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、 ~/.cshrc、~/.profile ファイルなど) に設定することができます。この場合、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。
ユーザーがサーバーとトランザクションを開始すると、次の処理が行われます。
キーサーバーはランダムに対話鍵を生成します。
カーネルはこの対話鍵を使用して、クライアントのタイムスタンプの暗号化などを行います。
キーサーバーは、公開鍵データベースからサーバーの公開鍵を検索します。詳細は publickey(4) のマニュアルページを参照してください。
キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。
キーサーバーは共通鍵を使用して対話鍵を暗号化します。
次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。
クライアントのネット名
共通鍵で暗号化された対話鍵
対話鍵で暗号化された「ウィンドウ」
この場合の「ウィンドウ」とは、サーバーの時刻とクライアントのタイムスタンプとの間で許容される時間差のことで、クライアントが指定します。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。通常の状態では、クライアントは RPC セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。
暗号化されたタイムスタンプ
指定したウィンドウの暗号化されたベリファイアから 1 を引いた値
ウィンドウベリファイアは、他人がユーザーになりすますのを防ぐために使用されます。なりすましを試みる人は、資格やベリファイアの暗号化された各フィールドに正しい情報の代わりにランダムなビットを記入するプログラムを作成します。サーバーはこの対話鍵を任意のランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。結果は、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウとタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。
サーバーがクライアントから伝送データを受信すると、次の処理が行われます。
キーサーバーは、公開鍵データベース内でクライアントの公開鍵を検索します。
キーサーバーはクライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵を知っている必要があるため、そのサーバーとクライアント以外は計算できません。
カーネルは共通鍵を使用して、対話鍵を復号化します。
カーネルはキーサーバーを呼び出して、復号化された対話鍵によりクライアントのタイムスタンプを復号化します。
サーバーは、クライアントのタイムスタンプを復号化したあと、次の 4 つの情報を資格テーブルに格納します。
クライアントのコンピュータ名
対話鍵
ウィンドウ
クライアントのタイムスタンプ
サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。
この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証する必要があります。キーサーバーは、呼び出し側を認証するときに、DES 認証を使用できません。DES 認証を使用すると、デッドロックが発生するためです。キーサーバーは、 ユーザー ID (UID) ごとに秘密鍵を格納し、ローカルのルートプロセスへの要求だけを許可することによってこの問題を解決します。
サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次の構成要素が含まれます。
サーバーが自分の資格キャッシュに記録するインデックス ID
クライアントのタイムスタンプから 1 を引いた値。対話鍵によって暗号化される
タイムスタンプから 1 を引くのは、タイムスタンプを無効化するためです。これによって、タイムスタンプをクライアントのベリファイアとして再利用できなくなります。
クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。
一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いた値を対話鍵で暗号化して、返信します。
システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。
スーパーユーザーになるか、同等の役割を引き受けます。
# ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv |
# /usr/sbin/keyserv |
NIS+ セキュリティの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nisplus |
NIS+ クライアントを起動します。
# nisinit -cH hostname |
hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。
次のコマンドを入力して、クライアントを cred テーブルに追加します。
# nisaddcred local # nisaddcred des |
keylogin コマンドを使用して、設定を確認します。
パスワードを求めるプロンプトが出たら、この手順は正常に終了しています。
次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth が Secure NIS+ クライアントとして正しく設定されていることを確認しています。
# nisinit -cH pluto NIS Server/Client setup utility. This machine is in the North.Abc.COM. directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.earth@North.Abc.COM Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.) Network password: xxx Press Return Warning, password differs from login password. Retype password: xxx Press Return # keylogin Password: # |
次のコマンドを入力して、ユーザーをルートマスターサーバー上の cred テーブルに追加します。
# nisaddcred -p unix.UID@domain-name -P username.domain-name. des |
この場合、username.domain-name の終わりにピリオド (.) を付けてください。
次の例は、george という名前のユーザーに DES 承認がどのように与えられるかを示しています。
# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des DES principal name : unix.1234@North.Abc.COM Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.) Password: Retype password: # rlogin rootmaster -l george # keylogin Password: # |
クライアント上でスーパーユーザーになるか、同等の役割を引き受けます。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nis |
newkey コマンドを使用して、新しい鍵のペアを作成します。
# newkey -h hostname |
hostname は、クライアント名です。
次の例では、earth を Secure NIS クライアントとして設定します。
# newkey -h earth Adding new key for unix.earth@North.Abc.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. # |
スーパーユーザーとしてサーバーにログインするか、同等の役割を引き受けます。
NIS サーバーにログインしたときに、ユーザーの新しい鍵を作成できるのはシステム管理者だけです。
ユーザーの新しい鍵を作成します。
# newkey -u username |
username はユーザー名です。システムはパスワードを求めるプロンプトを出します。汎用パスワードを入力できます。非公開鍵は、汎用パスワードを使用して暗号化されて格納されます。
# newkey -u george Adding new key for unix.12345@Abc.North.Acme.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. # |
ログインして chkey -p コマンドを入力するように、ユーザーに伝えます。
このコマンドでは、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を暗号化し直すことができます。
earth% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@Abc.North.Acme.COM Please enter the Secure-RPC password for george: Please enter the login password for george: Sending key change request to pluto... # |
chkey コマンドを使用すると、新しい鍵のペアをユーザーに作成できます。
Diffie-Hellman の publickey 認証がネットワークで有効である必要があります。Diffie-Hellman 認証のために NIS+ の資格に root 鍵を設定する方法 および Diffie-Hellman 認証と NIS の資格を使用して root 鍵を設定する方法を参照してください。