Solaris のシステム管理 (第 2 巻)

Secure RPC の概要

Secure RPC は、ホストと、要求を依頼したユーザーの両方を認証する認証方法です。Secure RPC は、Diffie-Hellman 認証か Kerberos 認証のどちらかを使用します。これらの認証機構は両方とも DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。

NFS サービスと Secure RPC

NFS ソフトウェアを使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS システムでは、サーバーは、複数のクライアントから利用できるデータと資源を格納します。クライアントは、サーバーがクライアントにエクスポートしたファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS 環境の最も一般的な使用形態として、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理する方法が挙げられます。 mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限のないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。

NFS 環境では Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。これを Secure NFS と呼びます。認証機構 AUTH_DH は、Diffie-Hellman 認証で DES 暗号化を使用し、許可されたアクセスを確認します。AUTH_DH 機構は、AUTH_DES とも呼びます。AUTH_KERB4 機構は、Kerberos 認証で DES 暗号化を使用します。この機構は、AUTH_KERB とも呼びます。

『NFS の管理』には、Secure NFS を設定および管理する方法が説明されています。NIS+ テーブルの設定と cred テーブルへの名前の入力は、『Solaris ネーミングの管理』で説明しています。RPC 認証に含まれる手順の概要については、「Diffie-Hellman 認証の実装」を参照してください。

DES 暗号化

Data Encryption Standard (DES) 暗号化機能は 56 ビットの鍵を使用して、秘密鍵を暗号化します。資格を持つ 2 人のユーザー (主体) が同じ DES 鍵を知っている場合、彼らはその鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化機構です。DES チップは暗号化をより高速にします。しかし、チップがなくても、ソフトウェアが実行します。

DES 鍵だけを使用する危険性とは、十分な時間をかけて、同じ鍵を使用して暗号化した暗号テキストメッセージを十分に収集すれば、鍵を発見し、メッセージを復号化できることです。この理由のため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。

Diffie-Hellman 認証

Diffie-Hellman のユーザー認証方法は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化復号化機能 (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 トランザクションを発行するのを待ちます。

パスワードが同じ場合は、ログインプロセスが秘密鍵をキーサーバーに渡します。パスワードが異なる必要があり、ユーザーが常に keylogin を実行しなければならない場合は、keylogin プログラムをユーザーの環境の構成ファイル (‾/.login、‾/.cshrc、‾/.profile など) に入れておいて、ユーザーがログインするたびに自動的に実行されるようにします。

対話鍵の生成

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

キーサーバーはランダムに対話鍵を生成します。
カーネルはこの対話鍵を使用して、クライアントのタイムスタンプを暗号化します (他の動作も行います)。
キーサーバーは公開鍵データベースでサーバーの公開鍵を検索します (publickey(4) のマニュアルページを参照してください)。
キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。
キーサーバーは共通鍵を使用して対話鍵を暗号化します。

サーバーとの最初の接触

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

クライアントのネット名
共通鍵で暗号化された対話鍵
対話鍵で暗号化された「ウィンドウ」

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

クライアントのベリファイアは、次の構成要素を持ちます。

暗号化されたタイムスタンプ
指定したウィンドウの暗号化されたベリファイアから 1 を引いた値

ウィンドウベリファイアが必要な理由は次の場合です。誰かが別のユーザーになりすまそうとして、資格とベリファイアの暗号化されたフィールドに書き込む代わりに、ランダムなビットだけを埋め込むプログラムを書いたと仮定します。サーバーはこの対話鍵をなんらかのランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。その結果、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。

対話鍵の復号化

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

サーバーのローカルなキーサーバーが、公開鍵データベースでクライアントの公開鍵を検索します。
キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵を計算するためには、どちらか一方の秘密鍵を知っている必要があるため、これを行えるのはサーバーとクライアントだけです。
カーネルは共通鍵を使用して、対話鍵を復号します。
カーネルはキーサーバーを呼び出して、復号された対話鍵によりクライアントのタイムスタンプを復号します。

サーバーへの情報の格納

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

クライアントのコンピュータ名
対話鍵
ウィンドウ
クライアントのタイムスタンプ

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

注 -

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

クライアントに返されるベリファイア

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

サーバーが自分の資格キャッシュに記録するインデックス ID
対話鍵によって暗号化された、クライアントのタイムスタンプから 1 を引いたもの

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

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

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

追加のトランザクション

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

Kerberos Version 4

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号化を使用して、システムのログイン時にユーザーを認証します。認証は、送信側のシステムが共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。Kerberos Version 4 は、Solaris 2.6 リリースでサポートされています。

Kerberos は、ユーザーのログインパスワードを認証することによって動作します。ユーザーは、kinit コマンドを入力します。このコマンドは、Kerberos 認証サーバーから、セッション時間 (デフォルトのセッション時間は 8 時間) の間だけ有効であるチケットを取得します。ユーザーがログアウトするとき、このチケットは (kdestroy コマンドで) 削除できます。

Kerberos ソフトウェアは、MIT プロジェクト Athena から入手できます。Kerberos ソフトウェアは SunOS 5.x ソフトウェアの一部ではありません。SunOS 5.x ソフトウェアが提供するものは、次のとおりです。

クライアントがチケットを作成、取得、および確認するために使用するコマンドと API
Secure RPC の認証オプション
クライアント側デーモン kerbd(1M)

「NFS による Kerberos 認証の実装」に、Kerberos 認証手順の動作の概要を示します。