Secure RPC の概要

Secure RPC (リモート手続き呼び出し) では、認証メカニズムを使用してリモート手続きを保護します。Diffie-Hellman 認証メカニズムは、サービスを要求するホストとユーザーを認証します。この認証メカニズムはデータ暗号化規格 (Data Encryption Standard、DES) 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS ネームサービスが含まれます。

NFS サービスと Secure RPC

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

NFS サービスでは Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。このプロセスは、Secure NFS と呼ばれます。Diffie-Hellman 認証メカニズム AUTH_DH は、DES 暗号化を使用し、承認されたアクセスを保証します。AUTH_DH メカニズムは、AUTH_DES とも呼ばれます。詳細については、次を参照してください。

• Secure NFS を設定および管理するには、『Oracle Solaris のシステム管理 (ネットワークサービス)』の「Secure NFS システムの管理」を参照してください。

• RPC 認証トランザクションの概要については、「Diffie-Hellman 認証の実装」を参照してください。

Secure NFS での DES 暗号化

データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー、すなわち主体が同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。

DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されてメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティーシステムは鍵を頻繁に変更する必要があります。

Kerberos 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos には DES に基づく暗号化もあります。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側とサーバー側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細は、第 19 章Kerberos サービスについてを参照してください。

Diffie-Hellman 認証と Secure RPC

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

認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期している必要があります。詳細は、『Oracle Solaris のシステム管理 (ネットワークサービス)』の「Network Time Protocol の管理 (作業)」を参照してください。

公開鍵と非公開鍵は、NIS データベース内に格納されます。NIS では、これらの鍵を publickey マップに格納します。このファイルには、すべての潜在的なユーザーの公開鍵と非公開鍵が含まれています。

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

Diffie-Hellman 認証の実装

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

Secure RPC 用の公開鍵と秘密鍵を生成

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

Secure RPC 用に keylogin コマンドを実行する

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

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

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

Secure RPC 用の対話鍵の生成

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

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

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

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

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

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

Secure RPC におけるサーバーとの最初の通信

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

• クライアントのネットワーク名

• 共通鍵で暗号化された対話鍵

• 対話鍵で暗号化された「ウィンドウ」

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

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

• 暗号化されたタイムスタンプ

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

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

Secure RPC における対話鍵の復号化

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

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

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

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

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

Secure RPC におけるサーバーへの情報の格納

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

• クライアントのコンピュータ名

• 対話鍵

• ウィンドウ

• クライアントのタイムスタンプ

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

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

サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次のコンポーネントが含まれます。

• サーバーが自分の資格キャッシュに記録するインデックス ID

• クライアントのタイムスタンプから 1 を引いた値。対話鍵によって暗号化されます

クライアントのタイムスタンプから 1 を引くのは、タイムスタンプを期限切れにするためです。期限切れのタイムスタンプはクライアントのベリファイアとして再利用できません。

Secure RPC におけるサーバーの認証

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

Secure RPC におけるトランザクションの処理

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