test

Solaris のシステム管理 (セキュリティサービス)

Diffie-Hellman 認証

Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、独自の非公開鍵と公開鍵を使って共通鍵を作り出します。非公開鍵は秘密鍵とも呼ばれます。クライアントとサーバーは、相互に合意した暗号化機能 (DES など) と共通鍵を使って相互に通信します。この方式は、以前の Solaris リリースの DES 認証と同じです。

認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、これらの鍵を publickey マップに格納します。NIS+ では、cred テーブルに格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS マップまたは NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する必要があります。非公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これにより、その非公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、DH 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

公開鍵と秘密鍵の生成

システム管理者は、認証を開始する前に、 newkey または nisaddcred コマンドを実行して公開鍵と秘密鍵を生成します。ユーザーごとに一意の公開鍵と秘密鍵が与えられます。公開鍵は、公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。公開鍵と秘密鍵のペアを変更するには、chkey コマンドを使用します。

keylogin コマンドの実行

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin コマンドは必要ありません。ただし、これらのパスワードが異なる場合は、ユーザーはログインするときに keylogin コマンドを明示的に実行する必要があります。

keylogin コマンドを入力すると、Secure RPC パスワードの入力を求めるプロンプトが表示されます。コマンドは、このパスワードを使って秘密鍵を復号化します。次に keylogin コマンドは、復号化された秘密鍵をキーサーバーと呼ばれるプログラムに渡します。キーサーバーは 、各コンピュータ上でローカルインスタンスを伴う RPC サービスです。キーサーバーは、復号化された秘密鍵を格納し、ユーザーとサーバーが Secure RPC トランザクションを開始するのを待機します。

ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なり、ユーザーが常に keylogin コマンドを実行する必要がある場合は、keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、 ~/.cshrc、~/.profile ファイルなど) に設定することができます。この場合、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。

対話鍵の生成

ユーザーがサーバーとトランザクションを開始すると、次の処理が行われます。

  1. キーサーバーはランダムに対話鍵を生成します。

  2. カーネルはこの対話鍵を使用して、クライアントのタイムスタンプの暗号化などを行います。

  3. キーサーバーは、公開鍵データベースからサーバーの公開鍵を検索します。詳細は publickey(4) のマニュアルページを参照してください。

  4. キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。

  5. キーサーバーは共通鍵を使用して対話鍵を暗号化します。

サーバーとの最初の接触

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

この場合の「ウィンドウ」とは、サーバーの時刻とクライアントのタイムスタンプとの間で許容される時間差のことで、クライアントが指定します。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。通常の状態では、クライアントは RPC セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。

クライアントベリファイアは、次の要素で構成されます。

ウィンドウベリファイアは、他人がユーザーになりすますのを防ぐために使用されます。なりすましを試みる人は、資格やベリファイアの暗号化された各フィールドに正しい情報の代わりにランダムなビットを記入するプログラムを作成します。サーバーはこの対話鍵を任意のランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。結果は、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウとタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。

対話鍵の復号化

サーバーがクライアントから伝送データを受信すると、次の処理が行われます。

  1. キーサーバーは、公開鍵データベース内でクライアントの公開鍵を検索します。

  2. キーサーバーはクライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵を知っている必要があるため、そのサーバーとクライアント以外は計算できません。

  3. カーネルは共通鍵を使用して、対話鍵を復号化します。

  4. カーネルはキーサーバーを呼び出して、復号化された対話鍵によりクライアントのタイムスタンプを復号化します。

サーバーへの格納情報

サーバーは、クライアントのタイムスタンプを復号化したあと、次の 4 つの情報を資格テーブルに格納します。

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。

注 –

この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証する必要があります。キーサーバーは、呼び出し側を認証するときに、DES 認証を使用できません。DES 認証を使用すると、デッドロックが発生するためです。キーサーバーは、 ユーザー ID (UID) ごとに秘密鍵を格納し、ローカルのルートプロセスへの要求だけを許可することによってこの問題を解決します。

ベリファイアをクライントに返す

サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次の構成要素が含まれます。

タイムスタンプから 1 を引くのは、タイムスタンプを無効化するためです。これによって、タイムスタンプをクライアントのベリファイアとして再利用できなくなります。

クライアントによるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

追加のトランザクション

一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いた値を対話鍵で暗号化して、返信します。