第 10 部

認証機構

411

第 1章
まえがき

近年、計算機の小型化、高性能なワークステーションの出現に伴い、計算機間での資源を共有することを目的として、を用いて複数の計算機を互いに結合したネットワークシステムを構築する
ことが 、一般的に行われている。このような環境において、ネットワーク
上の複数の計算機を協調して働かせるために、数々のネットワークアプリ
ケーションが開発されてきた。これらのアプリケーションの多くは、処理を必要とするプロセス（ クライアント ）が処理を実行するプロセス（サーバ ）にサービスを依頼し 、その結果を受け取るような、いわゆるサーバ・
クライアントモデルに基づいたものが多い。

LAN(Local Area Network)

これらのアプリケーションの中には、サービスを受けることのできる利用者を限定するものや、利用者によって提供するサービスの範囲を限定するものがある。前者の例として、有料のサービスが挙げられる。これは、料金を支払っている利用者のみがサービスを受けられる。後者の例は、パスワードの更新がある。普通、利用者は自分自身のパスワードしか変更できず、他者のパスワードは変更できないようになっている。このようなサービスにおいては、利用者によって正しい利用許可の発行を行う必要があり、利用者の認証が必要である。つまり、利用者を識別する機構を実装しなければならない。
このようなアプリケーションの運用を、ネットワーク環境で行うことを考える。対象となるネットワークシステムが非常に小規模の場合、単一の管理組織による利用者の登録の制限や、パスワードの管理などが可能である。このような環境では、利用者の認証は従来のパスワードを用いた方法を利用でき、これに基づいて利用許可を適切に発行することにより、サービスの運用を安全に行うことができる。また、盗聴などによる不正な情報の取り出しや、不正なユーザによる計算機の利用についても、対象となる
ネットワークの物理的あるいはネットワークプロトコル的な隔離・保護や、通信の積極的な制限が容易となる。
一方、最近では国内においてもLAN 等の小規模のネットワークが相

413

414

1989 年度 WIDE 報告書

互結合され、一つの大規模な広域ネットワークを形成しつつある。このようなネットワークでは、複数の管理組織が独立に管理を行っているネット
ワークシステム（サブネットと呼ぶ）を、相互に接続したものととらえることができる。このようなネットワークシステムでは、各管理組織が独自の方針にしたがって管理を行っている。このため、ネットワーク全体での統一的なセキュリティ管理を行うことは難しい。したがって、一部のサブ
ネットワークにおいて、十分なセキュリティ管理が行われていないような場合、通信路での通信内容の傍受や他の利用者のアカウントの不正利用、
パスワード の偽造などが発生しやすい。また、現在のネットワークアプリ
ケーションにおいては、十分なセキュリティ対策を施しているとはいえなシステムにおけるや等のいくつかのネットい。例えば 、
ワークアプリケーションでは、パスワード などの保護すべき情報が、暗号化などの保護を行われない状態でやりとりされている。このような状況では、一般のユーザが 、比較的簡単にこれらの情報を手に入れ、悪用することが可能である。

UNIX

ftp telnet

このような環境でのネットワークアプリケーションの実現およびその安全な運用を考えた場合、なんらかの通信路における通信内容の保護、利用、利用者の正確な認証、利者の識別方式などを行う機構が必要用者に対する適切な利用許可の発行である。特に、これらの機能のなかで、利用者認証は最も基本的な機能であると考えられる。

(identi cation)

1.1(authorization)(authentication)

WIDE プロジェクト と本研究の目的

1988 年に開始された WIDE (Widely Integrated Distributed Environment) プロジェクト [29] は、大規模な広域ネットワーク上での分散環境を提供することを目標にしている。WIDE プロジェクトでの研究は、二つのカテゴリに分けることができる。一つは、WIDE インターネットと呼ぶテ
ストベッド ネットワークを構築するためのネットワーク間接続技術の開発と、運用技術の確立が行われている。現在までに、ディジタル専用線、
パケット網、などの通信サービスを利用して、プロジェクト参加組
年
織のネットワークを相互接続するための技術開発が行われており、
月現在、国内の 大学 企業が WIDE インターネットに接続され、まインターネットとの接続も完了している。もう一つは、こた、米国のような大規模な広域ネットワークを構築する際に起こる基本的な問題を同定することである。広域ネットワークを構築する際には、ネットワーク
管理技術、セキュリティ管理技術、広域分散環境に適したプロセス間通信

X.25

ISDN

2

ARPA

6

5

1990

第 10 部

認証機構

415

技術などを研究する必要がある。WIDE プロジェクトでは 、これらの研究を通じて、問題点を同定し 、さらに WIDE インターネットに対して開発した技術を適用することで、有効性などを検証していく。
現在、WIDE インターネットには大学、研究所、企業などの様々な組織が接続されており、利用者にはネットワーク上に分散した多くの計算機によって各種のサービスが提供されている。サービスを提供する計算機にとって、利用者によって受けられるサービスを限定するためには、利用者を識別することが重要である。しかし 、計算機や利用者が 、すべて組織的な管理を受けているとはいえない。したがって、他人のアカウントを使用するなどの不正なサービスの利用が発生する可能性がある。このため、ネッ
トワークプロトコルやネットワーク上のサービスに何らかのセキュリティ機構を提供しなければならない。また、組織の管理下にない計算機がネッ
トワークサービスを受けるためには、その利用者とサービスを提供する主体が互いに認証を行うことが必要である。
本研究では、WIDE プロジェクトにおける、セキュリティに関する研究を開発する。SPLICE/ASの一環として、SPLICE1 /AS
は、WIDE インターネットでのサービスに対して、サービスを受ける利用者を識別する手段を提供する。このシステムは、WIDE インターネッ
トのセキュリティ管理の基本的な構成要素であり、この上位に、利用許可
機構や、アカウント機構が構築される。今年度を与えるにおいては、鍵の管理を行うサーバを作成し 、これを実際のネットワーク
アプリケーションに組み込むことを目標とする。

(Authentication System)(Authorization)

1.2

用語・表記

以後の議論を明確にするために、次のように用語を定義する。
分散環境: ここでの分散環境とは 、独立した管理組織に管理された計算機ネットワーク（サブネットワークと呼ぶ）が相互に結合されているような広域分散環境を指す。
ユーザ・クライアント ・サーバ: ユーザは分散環境における利用者である人間を表す。ユーザは分散環境において何らかのサービスを受ける場合、サーバと通信するためのプロセ
スを計算機上で起動してネットワーク上にあるサーバのプ
ロセスに対して処理要求を送り、サーバは処理要求に対して処理を行って何らかの処理結果をクライアントに送り返
1Supercomputer,Personal workstation and Local area network InterConnected
Environment

416

1989 年度 WIDE 報告書
す。この一連の処理によって、ユーザは対象とする分散環
境で提供されるサービスを利用することができる。
エンティティ(entity): 分散環境で通信を行う実体。ここでは、計算機上のプロセスを指す。

AS(Authentication Server): エンティティに対して利用者認
証のサービスを提供するサーバ。利用者認証のサービスを要求するすべてのエンティティのサーバとして存在する。
ド メイン (domain): 一つのティの論理的な集合。

AS が管理する計算機やエンティ

公開鍵・秘密鍵・プライベート 鍵: 公開鍵暗号方式において、所有者だけが知ることができる鍵を秘密鍵、公共に公開された鍵を公開鍵と呼ぶ。これと区別をつけるため、慣用暗号方式で用いる鍵をプライベート鍵と呼ぶ（プライベート鍵
は利用者のパスワードに等しい）。各クライアントは、それぞれこれらの鍵を持つ。
また、プロトコルを記述するために以下のような表記方法を導入する。

A ! B: message :A から B へのメッセージの送信を表す。
message はその通信内容

message の内容は以下に示す表記を用いて記述する。

A:A の名前P KA:A の公開鍵
SKA:A の秘密鍵CKA:A のプライベート鍵
key
fmessgeg:公開鍵暗号方式で公開鍵 (あるいは秘密鍵)
key を用いて message を暗号化したもの［ messge ］key :慣用系暗号方式でプライベート鍵 key を用いて message を暗号化したもの(kind):メッセージの種類・目的を示す識別子
以下に示す例では 、X が自分の名前と Y の名前を、X のプライベート鍵で暗号化したものと、Y の名前をメッセージとして Y に送っていることを表す。

X 0! Y : Y, ［ X,Y ］CKX

第 2章
過去における研究

広域ネットワーク環境においては 、第三者による通信内容の傍受を防ぐために、通信内容を暗号化することが一般的に考えられており、暗号化の技術を発展させて利用者認証に適用することが研究されてきた。これまで多くの研究者によって、暗号を利用した利用者認証プロトコルが提案さ等によって二つの方法れているが 、代表的なものとして、が提案されている。

Needham [49]

 慣用系暗号方式
慣用系暗号方式では、ユーザはそれぞれ一つの鍵を持っていて、自分以外に知られてはならない。あるユーザが他者と通信する場と合、自分の鍵を使って暗号化しても他者が解読できないため、二人だ
けで共通の鍵を持つ必要がある。この共通の鍵の生成・配送のために、を配置し 、 が鍵の生成・配送に必要な、ユーザ の鍵サービスを提供する。ここで、ユーザ の鍵を、共通の鍵をとする。 と がを得るまでのプロセをスは以下のようになる。

AS

Authentication Server(AS)
KB

CK

AS
A
KA
A B CK

A 0! AS
AS 0! A
A 0! B: A; B; id: [id; B; CK; [CK; A]KB ]KA: [CK; A]KB

B

(2.1)
(2.2)
(2.3)

id は AS との通信に使われる一回限りの識別子で、返信のメッセージ
中の id と比較して、通信が安全に行われたかど うかを確かめるものである。ただし 、このプロセスでは認証はなされていない。つまり、通信相手が本物かど うかはこれだけでは分からない。これに認証機能を加えるための一つの方法として、平文にある操作を行い、得られた値を認証のための識別子とする方法が提案されている。まず、平文をを定義する。
入力として、その平文に対してある値を与える関数

f()

CS = f(message)
417

418

1989 年度 WIDE 報告書

A

B

f

ユーザ は、ユーザ に送るメッセージ message に関数 を適用し 、CS という値が得られたとする。 はこれを に送り、 はこれに自分の鍵で暗号化して に送り返す。

A

A

AS

AS

(2.4)
(2.5)
KAS は AS の鍵である。A はこれを メッセージの後につけて B に
A 0! AS
AS 0! A

: A; [CS ]KA: [A; CS ]KAS送る。

: [message; [A; CS]KAS ]KB(2.6)
B はこれを復号すると、message0 と [A,CS]KAS を得て、message0 に
A と同じ操作を行い、CS0 という値を得たとする。B は [A,CS]KAS を
AS に送ると、AS は CS を送り返す。
B 0! AS : B; [A; CS ]KAS
(2.7)
KB
AS 0! B : [A; CS ]
(2.8)
B はこれを復号化して、CS を得る。B は CS と CS0 を比較して、同じ 値が得られれば 、このメッセージが本当に A から送られたものだ
A 0! ASと判断できる。

 公開鍵暗号方式
公開鍵暗号方式では、ユーザはそれぞれ公開鍵・秘密鍵の二つの鍵を持つ。公開鍵で暗号化したものは秘密鍵で復号でき、その逆も可能で以外に知られてはならないが、ある。したがって、秘密鍵は自分と
公開鍵は誰に知られてもよい。よって、公開鍵の配送に関しては秘密保持のための暗号化は必要ない。また、公開鍵暗号では、秘密鍵はその所有者しか使えないので、認証を行うには秘密鍵で暗号化するだけでよい。例えば 、 が にメッセージ message を送る場合、次のよ
うに通信を行う。

AS

A B: A; B(2.9)
SK: fP KB ; Bg AS(2.10): ffmessagegSKA gP KB(2.11)SKAS は AS の秘密鍵、SKA は A の秘密鍵、SKB は B の公開鍵である。まず、A は B の公開鍵をもっていないので、AS にそれを要求する。AS は A に B の公開鍵を返すが、このとき、AS の秘密鍵で暗A 0! AS
AS 0! A
A 0! B

第 10 部

419

認証機構

A

AS

号化することによって、 は確かにからのメッセージであることがわかる。次に、 は自分の秘密鍵で暗号化して、さらにそれを の公開鍵で暗号化して に送る。 はまず、自分の秘密鍵で復号化し 、の公開鍵で復号化し 、意味のあるメッセージが得られればそれが本当に からのものだということがわかる。この二つの鍵での暗号化を二重暗号化と呼び 、通信内容の保護と認証が同時に行える。

A

A

B

B

B

A

Voydock [82]Security

等
は、ネットワークプロトコルにおける
また、について体系的に説明し 、を用いた利用者認証方法を示している。しかし 、の研究も含めて 、これらの研究においては、プロトコルを設計し 、その安全性を議論しているが、実際のシステムでの実現や運用における問題についてはあまり考えられていない。
一方、実際にネットワークにおいて利用者認証の機構を構築した代表のが挙げられる。
的なものとしては、では 、が示した方法を基礎として 、システムを中心とした分散環境において利用者認証の機構を構築し 、また 、実際にを適用したネットワークアプリケーションを多数開発している。
では 、暗号化に必要な鍵のデータベースを管理するサーバはひ
とつのマスタ・サーバと複数のスレーブ・サーバから構成し 、負荷が集中しないようにしている。しかし 、鍵の変更が発生した時にマスタ・サーバ
からスレーブ・サーバに対して鍵の更新を行う必要があり、この更新を行
うための有効なプロトコルは現在のところ実現されていない。また、ある
サーバ が管理するネットワークシステムに属する利用者が、他のサーバ が管理するネットワークシステムで提供されている
サーバ が管理するサービスを要求する時には、利用者はまずネットワークにアクセスするためのチケットをサーバ からもサーバ にアクセスする。すなわち、
らい、その鍵をもって個のサーバが存在するネットワークシステムでは 2 個の鍵をサーバにアクセスするために共有していなければならない。このサーバの数が多くなると、これらの鍵の管理が難しくなる
ため、といった欠点がある。したがって、をそのまま広域ネットワークに適用することは、多くの技術的困難を伴うと考えられる。

Kerberos

DES(Data Encryption Standard)
Needham

MIT Athena Project Kerberos [66]Voydock
UNIX

Kerberos
Kerberos

Kerberos
Kerberos

Kerberos
Kerberos
KerberosA

B

Kerberos

B

Kerberos
B
KerberosA

Kerberos

n

n

第 3章
SPLICE/AS の概略
この章では、昨年度の基本設計を踏まえて SPLICE/AS の概略を述べる。

3.1

暗号を用いた利用者認証方式

実際に利用者認証システムの設計を行うにあたって、暗号方式の決定を行い、それに即した設計を行わなければならない。ここで問題となるのが、鍵の管理と鍵の配送である。我々は、効率良く鍵の管理・配送ができるような暗号方式を選択しなければならない。これに関して 章で述べたように、によって、二つの方法が提案されている。この二つの暗号方式を比較した場合、広域分散環境においては、鍵の配送に関して公開鍵暗号方式の方が有利であることは明らかである。以上のことから、我々は公開暗号方式がネットワークでの運用により適していると判断し 、公開鍵方式をが提案した方式に基づいて、SPLICE/AS
採用することにした。
では、鍵の管理・配送を行うためのと、それに対す
るインターフェイスを開発する。

2

NeedhamNeedham

3.2

Authentication Server

階層的ド メイン一般に広域ネットワークでは、複数の管理組織が独立に管理している
サブネットワークが相互に接続された、一つの大規模なネットワークシスのようにモデル化する。
テムととらえることができる。これを図は、ユーザとサーバの、公開鍵・秘密鍵およびプライベート鍵のデーで管理した場
タベースを持っている。全ての利用者の公開鍵を単一の合、ネットワークが小規模な場合であれば有効にサービスを提供できるが、ネットワークが広域化してくると、このデータベースが巨大になるばかりに負荷が集中するという問題が発生すると考えられる。
でなく、そのこのトラヒックの集中に加えて、管理組織の問題もある。広域ネットワー
クでは、複数の管理組織がそれぞれ独自の方針でサブネットワークの管理

3.1

AS

AS

AS

420

第 10 部

421

認証機構

を行っている。このため、ネットワーク全体を一つの管理の単位とした場
合、各管理組織の管理方針を反映させることは難しい。
を配置し 、そこでのサービス
そこで各管理組織ごとにローカルなを独立に提供してゆく方法が考えられる。こうすることにより負荷の分散
や組織単位での管理が行え、実際のネットワークに即したサービスが行えによるサービスを受ける計算機やローカルなネッる。ここで、一つのトワークシステムの論理的な集合をド メインと呼ぶことにする。
ここで、ド メイン間での公開鍵の配送という問題が発生する。SPLICE/AS
では、この解決策として、幾つかのド メインをサブド メインの集まりとみなして、新たな一つのド メインを構成することを考えた。そしてそのド メの公開鍵を管理するため、インの中の、サブド メイン上のを置いた。
は 、下位のド メインのでの鍵の配送における安全性を暗号化の手法を用いて提供している。このよの公
うにド メインに階層的構造を持たせることにより、 が上位のを通じて他のエンティティの公開鍵を確実に手
開鍵を持っていれば 、に入れることができる（ 具体的なプロトコルについては後述）。 また、鍵とだけで行えばよい。さらに階層構造をの更新も、更新を行う
増やすことにより、広域なネットワークに対応していくことができる。こおよびは、図のように木構造の形でとらえることがでのとききる。このような木構造は、実際のネットワーク管理における組織間の関係に対しても、適合性がよい。SPLICE/AS では、この階層化したド メイン
構造の考え方を導入し 、を構築している。

AS

AS

AS

thentication Server(MAS)

Master AuAS

MAS

AS

MAS

MAS

AS MAS

AS

MAS

3.2

Authentication Server

3.3

名前構造

AS

ネットワーク全体での利用者認証サービスを考えた場合に、各はエンティティを階層型のド メイン構造の中で一意に識別する必要がある。
SPLICE/AS が対象とするネットワークは、WIDE インターネットを想定が用いしている。WIDE インターネットにおいては、によれば 、通信を行うエンティティは、イられている。
ンターネットアドレスとトランスポート層でのポート番号によって一意に識別することが可能である。そこで、以下の要素を組み合わせてエンティ
ティを表すことにした。

Internet Protocol

struct entname fchar *name;u short id;
char addr[4];Internet Protocol

422

1989 年度 WIDE 報告書

gchar domain[256];

1. name
対象となるエンティティがサーバであれば 、それが提供するサービス
名。クライアントであればそのクライアントを起動した利用者のアカ
ウント名。

2. id
対象となるエンティティがサーバであれば 、そのポート番号（ポート番号は、 オクテットの整数として扱う）。クライアントであれば 、そのクライアントを起動した利用者のユーザ 。

4id

3. addr
対象となるエンティティが稼働している計算機のインターネットアド
レス。インターネットアドレスは、 オクテットから構成される。

4

4. domain"."()

エンティティの存在するド メインを、下位のものから順に
ドットで区切って並べたもの。例えば 、大阪大学基礎工学部情報工学科のドメインは次のように表すことができる。

ics.osaka-u.ac.jp

3.4

SPLICE/AS の実装環境

AS

SPLICE/AS において、はこのシステムのもっとも重要な部分である。 のおかれている環境下には、公開鍵・秘密鍵・プライベート鍵のデー
タベースなど 、 以外にアクセスを禁止するようなファイルが集中している。これらのファイルでは、必要に応じて暗号化などの安全策をとっているが、データベースファイルからの情報の不正な取り出し 、データベース
ファイルの破壊などの問題が発生する可能性がある。したがって、セキュ
リティの面から考えて、 は、物理的にもネットワーク的にも安全な環境におかれる必要がある。

AS

AS

AS

3.5

プロト コルの設計

Needham

SPLICE/AS で使用しているプロトコルは、等が提案した、公開
鍵暗号を用いた利用者認証プロトコルを基礎としている。さらに SPLICE/AS

第 10 部

AS

423

認証機構

replay attack に対処するための
replay attack については後述）。

では、階層化された間での鍵の配送、
プロトコルの拡張を行っている（
3.5.1

ログイン時の鍵入手プロト コル

AS

ユーザは
のサービスを受ける場合、通信するためのプロセスを起動するが、起動直後においては、ユーザは自分のド メインのの公開鍵および自分の公開鍵・秘密鍵を持っていない。そこで、利用者はまず、「にログイン」して、これらの鍵を取ってこなくてはならない。ここでは情報の保護のため、利用者のパスワードをプライベート鍵として、慣用系暗に、このプロトコルを示す。
号を使用する。図
は利用者のパスワードをデータベースとして持っており、要求が来るとデータベースを検索してプライベート鍵を取り出し 、メッセージの暗号化に使用する。 はセッション と呼び 、各鍵入手セッションごとに異なった値が設定される。これは送信者が返信を受け取った時、この値が同じかど うかを見て安全に通信が行われているかど うかを判断するのに使用
される。

AS

AS

3.3

id

id

AS

424

1989 年度 WIDE 報告書

3.5.2

公開鍵入手のプロト コル

あるユーザが他者と安全な通信を行いたい場合、他者の公開鍵で暗号化をする必要がある。したがって、に他者の公開鍵の要求をしなけれにこのばならない。ここでは同一ド メイン内での通信をを考える。図プロトコルを示す。

AS

AS

3.4

ここで、返信のメッセージ中で、 の秘密鍵で暗号化が行われている。
の秘密鍵は
しか使え
これは認証のための暗号化である。基本的には、このメッセージがからのものである、ということないので、がわかるわけである。また、メッセージとして送られるものは公開鍵であるので、情報の保護は行う必要はない。

CL1

3.5.3

AS

AS

AS

複数ド メイン間での鍵入手プロト コル

ここでは 、複数ド メインにまたがって公開鍵の要求を行う場合を考えにそのプロトコルを示す。認証を行なうため、
ではすべて
る。図
送信側の秘密鍵で暗号化されている。メッセージとして送られるのは公開鍵であるので、受信側の公開鍵で暗号化して情報を保護する必要はない。
また、ド メインの数や管理組織の数が増加するのに応じて、階層の深さをのが自分の上位大きくすることによって対応する。この場合、図にリクエストをかけることになる。
の

3.5

4,5,6

3.5 MAS

MAS

3.5.4

通信要求のプロト コル

ここでは 、ある利用者が他者と通信を行う際、互いに認証を行うためにこのプロトコルを示す（ 相手の公開鍵はのプロトコルを考える。図既に入手済みとする）。

3.6

各メッセージには timestamp と life の二つが含まれている。timestamp
はメッセージが作られた時刻で、life はメッセージの有効期間である。この検出のために使われる。
れらはreplay attack
replay attack とは、第三者がネットワーク上に流れているメッセージを傍受し 、それを蓄積しておき、後になってそれを発信するものである。これに対する対策がなされていなければ 、受信側ではされたメッセージと正当なメッセージ区別をつけることができず、この不当なリクエストを受け入れてしまうことになる。

replayreplay attack を検出するため、life の値を、以下のように設定する。
life = (timestamp を発行からメッセージの送信までにかかる
時間)+ (メッセージのネットワーク内での最大存在時間)

第 10 部

425

認証機構

+

受信側では、メッセージを受け取った時、timestamp life が現在の時間とみなせばよい。このような判断を正しく行なうたを過ぎていれば
めには、送信側のクロックと、受信側のクロックの時刻が同期している必要がある。しかしながら、実際にシステム上で正確にクロックの時刻を一致させるのは困難であり、この場合には送・受信者間でのクロックの誤差の値としてはを考慮しなければならない。このため
0
クロックの最大誤差0のようにを求めこれを用いる。
また、メッセージ では 、二重暗号化が用いられており、通信内容の保護・認証が同時に実現できる。メッセージ では、 が正しければ 、返信が正しい相手から返ってきたと判断できるので、二重暗号化は用いていない。

replaylife = life + (
life
1

3.5.5

life

)

2

id

鍵の有効期間我々が使用する暗号は時間をかけて計算を行えば破られる可能性がある。これは鍵の長さに依存しており、安全が保証できる程度に鍵の長さを設定しているが、あまりに長時間同じ鍵を使い続けるのは危険である。したがって、ある期間をおいて鍵の更新をする必要がある。

426

1989 年度 WIDE 報告書

'

'

$

$

subnet A


admin


P%
$
PPPP'
&
subnet C
0

00
'
$
subnet B

admin


&
&
図








%

admin



&

%
%

3.1: ネットワークモデル,,$,
domain G
,

,
MAS
8

8
$
'
$ bb'
8
b
domain Q
8domain P
b
bb

888
AS
AS


SS
S




 

S
 
CL
CL

'

CL
CL



&
%
&

図

CL
CL



&
%
%

3.2: ド メインの階層構造

第 10 部


AS


1

6

2

?


427

認証機構

1. CL → AS:CL,[CL,AS,id]PASSWD ,(initr eq )AS へログイン要求

2. AS → CL:AS,[CL,AS,id,PKCL ,SKCL ,PKAS ]PASSWD ,(initr pl)
クライアントへ PKCL ,SKCL ,PKAS を返す

CL


図

3.3: AS へのログイン


AS



1. CL1 → AS:CL1,CL2,id,(key request)

AS に CL2 の公開鍵を要求
 2 AA  A 2. AS → CL1:AS,fAS,CL1,id,PKCL gSKAS ,(keyr eply)

1

2

CL1


CL2


図

3.4: 公開鍵の入手


MAS

2  T 30/5 AKTAU
4 A T
AS1
AS2



6 6

?

CL1


1


CL2

図

CL1 に CL2 の公開鍵を返す

1. CL1 → AS1:CL1,CL2,id,(key request)
CL1 から AS1 へ CL2 の鍵を要求
2. AS1 → MAS:AS1,CL2,id,(key request)
AS1 は CL2 の公開鍵を持っていないので、MAS に鍵を要求
3. MAS → AS2:MAS,CL2,id,(key request)
MAS は AS2 に鍵を要求
4. AS2 → MAS:AS2,MAS, AS2,MAS,id,PKCL2 SK2 ,(keyr eply )AS2 は MAS に鍵を返す
5. MAS → AS1:MAS,AS1, MAS,AS1,id,PKCL2 SKM ,(keyr eply )MAS は AS1 に鍵を返す
6. AS1 → CL1:AS1,CL1, AS1,CL1,id,PKCL2 SK1 ,(keyr eply )AS1 は CL1 に鍵を返す

3.5: 複数ド メインでの公開鍵の入手

f
f
f

g
g
g

428

1989 年度 WIDE 報告書

 1 CL1
2


f

f

g

g

1.CL1 → CL2:CL1,CL2, CL1,timestamp,lif e, id,(request) PKCL2 SKCL1
 CL2 へ通信要求を出す
CL2

2.CL2 → CL1:CL2,CL1, CL2,id,timestamp,lif e,(reply ) PKCL1
CL1 へ reply を返す

f

図3.6: 通信要求g

第 4章
SPLICE/AS の構成

7

 - 66MAS

BB BMB
BN B
AS

6
?

interfaceclient

図

4
5
5
DB

7
- 66



DB

4
5
5

 -

interfaceserver

4.1: SPLICE/AS の構成

SPLICE/AS は以下のソフトウェアから構成される。

 プライベート鍵データベース
 公開鍵データベース
 秘密鍵データベース
 ユーザインターフェイス
 プログラムインターフェイス
 Authentication Server(AS) Master Authentication Server(MAS)
これらは図4.1に示すような構成になっている。
429

430

1989 年度 WIDE 報告書

4.1

AS の持つデータベース

AS は鍵の管理のために幾つかのデータベースを持っている。これらには二つの種類があり、

 ユーザの鍵の管理のためのデータベース
 AS の鍵の管理のためのデータベース

AS

splice-asと設定されているために、に分けられる。 のサービス名は全てを区別することができない。 ど うしの識別には、
サービス名だけでそのが存在するマシン名を用いる。以下、それぞれのデータベースについて説明する。

AS

AS

AS

1. ckdb
ユーザのプライベート鍵を登録するデータベース。データベースののアルゴ
エントリは以下の通り。ユーザのプライベート鍵は、リズムを用いて暗号化を行う。まず、乱数などで暗号化のキーを生成
し 、それを一定長のブロックに分けた平文に順次適用し 、暗号文の頭にキーをつける手法である。

DES

f ユーザの名前 : ユーザのプライベート鍵を暗号化したものg

2. pkdb
ユーザの公開鍵を登録するデータベース。データベースのエントリは以下の通り。

f ユーザの名前 : ユーザの公開鍵 g

3. skdb
ユーザの秘密鍵を登録するデータベース。秘密保持のため、秘密鍵はプライベート鍵で暗号化してある。データベースのエントリは以下の通り。

f ユーザの名前 : f 利用者の秘密鍵 gCK g

4. asckdb
AS のプライベート鍵を登録するデータベース。データベースのエントリは以下の通り。AS のプライベート鍵は、ckdb と同様の手法でで暗号化されている。

第 10 部

431

認証機構

fAS の存在するマシン名 : AS のプライベート鍵を暗号化したもの g

5. aspkdb
AS の公開鍵を登録するデータベース。データベースのエントリは以下の通り。

fAS の存在するマシン名 : AS の公開鍵 g

6. asskdb
AS の秘密鍵を登録するデータベース。秘密保持のため、秘密鍵はプ
ライベート鍵で暗号化してある。データベースのエント リは以下の通り。

fAS の存在するマシン名 : fAS の秘密鍵 gCK g
次に、データベースにアクセスするためのライブラリ群について説明で提供されているを利用して実現する。これらはしている。

Berkeley UNIXndbm

1. プライベート鍵データベースにアクセスするためのライブラリ ck store(dbname,username,ck)
 ck delete(dbname,username) ck fetch(dbname,username)ck store()

はエンティティ名と公開鍵データを受け取り、それに対するエント リを新たにデータベースに追加する。もし 、すでにそのエント リが存在すればそこにデータを上書きする。
は指定は渡されたエされたエンティティのエントリを削除する。
ンティティ名からそれに対応するデータを取りだしそのポインタを返を返す。
す。もし 、対応するエントリがなければ 、

ck delete()ck fetch()null

2. 公開鍵データベースにアクセスするためのライブラリ pk store(dbname,username,pk)
 pk delete(dbname,username) pk fetch(dbname,username)
機能的にはプライベート鍵データベースライブラリと全く同じルーチンが用いられている。

432

1989 年度 WIDE 報告書

3. 秘密鍵データベースにアクセスするためのライブラリ
 sk store(dbname,username,sk,ck)
 sk delete(dbname,username) sk fetch(dbname,username,ck)
秘密鍵のデータをプライベート鍵で暗号・復号化する所以外は、プライベート鍵データベースライブラリと機能的に全く同じである。これ
らのデータベース操作のためのライブラリは、データベースを保守すによって使用される。
るためのコマンド

asdbm

4.2

ユーザインターフェイス

ここでは、ユーザインターフェイスとして提供されるユーティリティについて説明する。
4.2.1

asinit%asinit okayama
Please answer your password.
passwd:(パスワードを入力)
Now,the SPLICE/AS service is available.
%
図4.2: asinit の使用例

AS のサービスを受けるためには asinit コマンドを使用する。これを使用すると、まず利用者名を聞かれ、ついでパスワードを聞かれる。パスワーに、名前がドチェックが通れば 、ユーザは各サービスが受けられる。図であるユーザのの使用例を示す。

okayama
4.2.2

asinit4.2

asdbm

公開鍵や秘密鍵・プライベート鍵の更新や、新規ユーザの登録・ユーザの登録削除などはコマンドを使用する。このコマンドは、の存在する計算機上でしか行えない。一般ユーザがの存在しない計算機（ リモートマシンと呼ぶ）から鍵の更新を行う場合は、次に述べコマンド を使用する。また、新規登録・登録削除は管理者しるか行えない。

asdbm

aspasswd

AS(MAS)

AS(MAS)

第 10 部
4.2.3

433

認証機構

aspasswd

リモートマシンにおいて、一般ユーザが、鍵の更新を行いたい場合にはを使用する。これは、 システムで提供されていると概念的に同じである。

aspasswd
4.2.4

YP

yppasswd[68]

デーモン

#
asd

-

7
6

"! 6

DB

4
5
5



'$
asdbmd&%SSSoSS
00
0
S SS
000
SS S
0
Sw # 09CL"!
図4.3: クライアント・asd・asdbmd の関係

AS 自身は、ユーザの鍵の更新や、新規ユーザの登録・削除などは行わない。これらを受け付けるサーバプロセスとして、asdbmd というデーモンがある。これは AS と同じ計算機上で走らせておき、asdbm コマンドや
aspasswd コマンドを受け付けて処理を行う。また、AS は asd というデーモンを起動する。クライアント、asd 、asdbmd の関係を図 4.3に示す。
4.3

プログラムインターフェイス

ここでは、SPLICE/AS のサービスをプログラムから直接利用するためのライブラリについて説明する。

 as initserv(socket,sevicename)
これは認証機構を必要とするサービスを提供するサーバの起動を行うためのものである。

 get pk(socket,sender,receiver)434

1989 年度 WIDE 報告書
これは受信エンティティの公開鍵を得るためのものである。送信エンおティティの名前および受信エンティティの名前を与えると、で述べたプロトコルにしたがってと通信し 、公開鍵を
よび
返す。

3.5.3

3.5.2

AS

 authent(socket,sender,receiver,pk,sk)
送信エンティティの名前および受信エンティティの名前、相手の公開で述べた通信要求のプロトコルに鍵、自分の秘密鍵を与えると、したがって、通信相手の認証を行い、相手に返信する。

3.5.4

 as init(socket,asname)

3.5.1

AS

これは
で述べた
へのログ インのプロトコルにしたがってパの公開
スワードチェックが行われ、自分の公開鍵・秘密鍵およびコマンド もこれを利用して実現
鍵を得ることができる。前節のされている。

asinitAS as kchange(socket)
 as pcahnge(socket)

as kchange() は利用者の公開鍵・秘密鍵の更新を行い、as pchange()
は利用者のプライベート鍵（パスワード ）の更新を行うものである。
前節の
コマンドや
コマンドは、これを利用している。

asdbm

aspasswd

 as register(socket,username) as expel(socket,username)as register() は新規のユーザ・サービスを AS に登録するためのもの
で、as expel() はユーザ・サービスを AS から削除するためのものである。これらは特定のユーザ（管理者）だけが行える。前節の asdbm
コマンドは、これらのライブラリを利用している。

4.4

Authentication Server(AS)AS

AS

ここでは 、SPLICE/AS の核をなすについて述べる。
は立ち上を読み込み、それに応じて各種環境を設定すげ時に設定ファイルる。設定ファイルでは、以下の項目について記述できる。

as.con g

第 10 部 MODE
立ち上げ時のモードを選択する（の詳細については後述。）

認証機構

435

AS モード・MAS モード、各モード

 AS,ASDOMAIN
自分のマシン名およびド メイン名

 MAS,MASDOMAIN（ 自分の上位のン名

MAS が存在する場合）MAS のマシン名およびド メイ

 ASLIST

MAS モード の場合、自分の下位の AS(MAS) が存在しているマシンのリスト

 CKDB,PKDB,SKDB
ユーザの公開鍵、秘密鍵、プライベート鍵データベースのファイル名

 ASCKDB,ASPKDB,ASSKDBAS の公開鍵、秘密鍵、プライベート鍵データベースのファイル名
as.con g の記述例を図 4.4に示す。

また、

MODE
PKDB
SKDB
CKDB
ASPKDBASSKDBASCKDBAS
ASDOMAINMAS
MASDOMAIN
図4.4: as.con g の例

as/usr/local/lib/as/pkdb/usr/local/lib/as/skdb/usr/local/lib/as/ckdb/usr/local/lib/as/aspkdb/usr/local/lib/as/asskdb/usr/local/lib/as/asckdb
neptuneics.osaka-u.ac.jp
mars
osaka-u.ac.jp

4361989 年度 WIDE 報告書

4.4.1

AS モードas.con g で AS モードを指定することAS として起動される。AS は以

サーバプロセスは設定ファイル
によって、最も下位のド メインに位置する
下のような機能を持つ。

 自分の管理しているド メイン内のエンティティに対し 、必要としている公開鍵を提供する。

 他のド メインの公開鍵を要求された時、その要求を上位の MAS に転

MAS から得た鍵を要求を行ったエンティティに与える。

送し 、

 利用者および管理者からの鍵の更新、新規登録、登録削除などの要求を受け付ける。
4.4.2

MAS モード

MAS は AS の上位のド メインに位置するものであるが、そのド メインにもクライアントが存在する場合もあり、また、下位の AS(MAS) もクラ
イアントみなすことができる。したがって、MAS モードでは、AS モードの機能を含んでいなければならない。前節の AS モード の機能に加えて 、MAS モードには次のような機能がある。
 下位のサブド メインの管理を行っている AS(MAS) の鍵の情報をデー
タベースとして持ち、その登録・更新などの管理を行う。

 3.5.3で述べたようなプロトコルにしたがって、下位の AS(MAS) からの公開鍵の要求を処理する。

4.5

暗号ライブラリ

SPLICE/AS で使用される暗号方式は公開鍵暗号方式と慣用系暗号方式がある。したがって、その二つについてそれぞれライブラリを用意した。

 rsa encrypt(key,plaintext,size)
 rsa decrypt(key,ciphertext,size)

rsa encrypt()rsa decrypt()

これらは公開鍵暗号方式のライブラリである。
は、公開鍵
（秘密鍵）
・平文・平文のサイズを与えると暗号文を返し 、は、秘密鍵（公開鍵）・暗号文・暗号文の長さを与えると平文を返す。

第 10 部

認証機構

437

 des encrypt(ck,plaintext,size) des decrypt(ck,ciphertext,size)

des encrypt()des decrypt()

これらは慣用系暗号方式のライブラリである。
は、プラ
イベート鍵・平文・平文のサイズを与えると暗号文を返し、は、プライベート鍵・暗号文・暗号文のサイズを与えると平文を返す。

RSA

DES

、慣用系暗号方式に
また 、SPLICE/AS では公開鍵暗号方式にを使用しているが、この部分の変更によって他の暗号方式を使うことがで
きる。

第 5章
応用例
WIDE インターネットにおいて、もっとも利用者認証が必要とされるアである。そこで、SPLICE/AS
プリケーションは、ファイル転送プログラム
を WIDE インターネットに実装するにあたり、
システム
で提供されているに対して、SPLICE/AS を利用するように改造を加える。 は、ネットワーク上のファイル転送プログラムで、サーバ・クライ
アント形式をとっている。ネットワーク上の各計算機では、サーバプロセ（
デーモン ）が動いており、ユーザは、 コマンドでクスである
ライアントプロセスを起動し 、ターゲットの計算機上のと通信を行うことによってファイル転送を行う。

ftp

ftp

ftp

ftpd ftp

Berkeley UNIX
ftp
ftpd

ftp

しかし 、 コマンドでは、ネットワーク上の通信の際、メッセージに対して何の操作もなされていない。したがって、第三者がそのメッセージを傍受すれば 、メッセージの内容がそのまま見えてしまう。これは、 のパスワード チェックに関しても同様であるので、そこからパスワードが他人に知られてしまう恐れがあり、ネットワークのセキュリティ上、非常に危険である。そこで、我々の開発した SPLICE/AS をこれに実装することによって、安全にファイル転送が行える環境を提供しようとするものである。

ftp

5.1

通信路確立のプロト コル

AS

SPLICE/AS の実装にあたって、の果たす役割は、安全な通信路を確立することに尽きる。いったん通信路が確立してしまえば 、クライアン
トとサーバの間で通信のための鍵を作るなどして、その通信路の安全を維に、通信路確立のプロトコルを示す。
持すればよい。図

5.1

ftpd

は自分の公開鍵・秘密鍵お
ここでは、すでにクライアントおよびの公開鍵をもっているとする。また、クライアントとが同じよび
ド メイン上にない場合は、で示されたようなプロトコルを使用する。

AS

3.5.3

438

ftpd

第 10 部

5.2

439

認証機構

通信路確立後のクライアント と ftpd との通信

AS

さて、一度安全な通信路が確立すれば 、 がこれに関与する必要はなの間で通信を行えばよい。このとい。ここから後はクライアントとき、クライアントは二つの方法が選べる。一つはメッセージに対して暗号化を行わずに通信する方法で、もう一つは暗号化を行って通信する方法である。なぜならば 、第三者に内容を知られたくないファイルのみに暗号化を行えばよいのであって、そうでなければ 、暗号化をしない方が暗号化のオーバーヘッドがないため、高速にファイル転送が行えるからである。前者は従来通りのものなので、ここでは後者を考える。この暗号化には、慣が行う。まず、クライアントは、通信要用系暗号を使い、鍵の生成は、求の際に、暗号を使って通信したいことをに知らせる。すると、はそれを受けて、通信用の鍵を生成し 、クライアントへ送り返す。この後に図で示すような通信を行えばよい。
れは図

ftpd

ftpd

5.1

5.2

key

ftpd

ftpd

1.CL → AS:CL,ftpd,id1
AS に ftpd の公開鍵を要求

f

CL に ftpd の公開鍵を返す

AS


2 B

2 B
22 22222 BMB BBBBBN5
BB
22 2 2 3 -4B #
CL

ftpd

1

6

g

2.AS → CL:AS, CL,AS,id1 ,PKftpd SKAS



f

f

g

ftpd に通信要求を出す
4.ftpd → AS:ftpd,CL,id3
AS に CL の公開鍵を要求

5.AS → ftpd:AS,fftpd,AS,id ,PKCL g
"!
3

SKAS

ftpd に CL の公開鍵を返す

fg

6.ftpd → CL:ftpd,CL, ftpd,id2 ,timestamp,lif e,(reply ) PKCL
CL へ reply を返す

図5.1: ftp における通信路確立のプロトコル
keyの更新が必要となる。これ
また、通信が長時間になると、途中では、ある一定の期間（の長さに依存する）が経つと、が新たなを生成して、クライアントにそれを知らせればよい。そのときのメッセー
ジは次のようになる。

keyg

3.CL → ftpd:CL,ftpd, CL,timestamp,life, id2 ,(request) PKftpd SKCL

ftpd

key

ftpd → CL : ftpd,CL,[ftpd,id,timestamp,lif e,(change key ),newkey]oldkey

440
5.3

1989 年度 WIDE 報告書
ftp への実装

これまでに述べたような機能を実現するために、以下の手順で実装を行う。

 クライアントプロセスを起動するためのコマンド ftp へ、4.3で示した
ユーザインターフェイスのライブラリを組み込む

 ftpd に 4.3で示したユーザインターフェイスのライブラリを組み込む
 ftpd に通信用の鍵の生成ライブラリを組み込む

第 10 部

441

認証機構

f

f

g

g

7. CL → ftpd:CL,ftpd, CL,timestamp,lif e, id,(use cryption) PKftpd SKCL

7 - 通信に暗号を使用することを要求



CL

8

ftpd

f

f

g

g

8. ftpd → CL:ftpd,CL, ftpd,timestamp,lif e, id,(reply ),key PKCL SKftpd

通信用の鍵 key を生成し 、CL に送る
図

5.2: 通信用の鍵の要求

第 6章
今後の課題

今後に残された課題として、以下の点が挙げられる。

 鍵のキャッシュの問題あるユーザが通信を安全に行いたい場合、これまでに述べたようにに相手の公開鍵を要求しなければならない。ここで、同じ相手とと通信を行う必要
しばしば通信を行う場合を考えると、その度にが生じる。このオーバーヘッドを軽減するためには、鍵のキャッシュが効果的であると考えられる。つまり、最初の通信で得た相手の公開鍵を持っておき、次回からはその鍵を使って直接相手と通信を行う。
の負荷を軽減でき、ユーザも通信のオーバーヘッ
これによって、ドが減少するというメリットが生じる。

AS

AS

AS

鍵のキャッシュを行う場合に考慮しなければならないのが、キャッシュする鍵の安全性と、鍵の更新である。鍵の安全性については、キャシュ
する鍵は公開鍵であるので、安全性の問題は発生しない。

A ftpdと頻繁に一方、鍵の更新では問題がある。例えば 、ユーザ はの公開鍵をキャッシュしている場合を考える。
通信を行うため、が自分の公開鍵・秘密鍵の更新を行った場合、 がキャッシュ内の鍵を利用すると、の古い公開鍵で暗号化を行い、に メッ
セージを送ることになる。当然、はこのメッセージを正しく復号
では、このメッセージが古い鍵化することはできない。この時、を使ったことに起因するものなのか、それともメッセージ自体が不正であったり、途中で第三者の妨害が入ったりしたのかを認識することからの反応がないので、コネクショはできない。また、 ではンを張るために何度も再送を行うことになる。

ftpd

ftpd

A

ftpd

A

ftpd
ftpd

ftpd

ftpd

以上のように、鍵のキャッシュに対しては何らかのチェック機構や、整合性を保つ機構を導入しなければ 、鍵入手の効率化どころか、かえって通信の妨げとなってしまうと考えられる。したがって、このためのプロトコルの開発、システムの拡張が要求される。

442

第 10 部 プロトコルの検討

443

認証機構

Needham

SPLICE/AS では、等によって提案された、公開鍵暗号を用いた利用者認証の手法に基礎とし 、それを拡張することによって広域ネットワークに適応させている。これをネットワークアプリケーションに実装した場合、このプロトコルの安全性を検討し 、実際のネット
ワークアプリケーションでの SPLICE/AS の利用のガイド ラインを作ることが必要である。

 性能評価AS

SPLICE/AS の実装のガイド ライン作りにあたって、 の性能評価も必要になると考えられる。性能評価のポイントとしては、

1. プロトコルのオーバーヘッド
2. 階層レベル数とオーバーヘッドとの関係
3. ユーザ数と鍵を取ってくるまでの時間の関係
4. 暗号ルーチンの性能などが挙げられる。

 SPLICE/AS の運用

1990 4SPLICE/AS は、
年 月より WIDE インターネットにおいて実際の運用を開始する予定である。現在の SPLICE/AS の管理・運用面から見たユーティリティは、不足していると考えられる。今後、実際の運用を通して、問題点を検討していく必要がある。

第 7章
あとがき

本研究では昨年度の研究に基づいてネットワーク上のサービスに利用者認証のプロトコルの詳細設計およびソフトウェアの構成を行い、実際に、さらに、それを分散環境
利用者認証の機能を提供するサーバとしての実装を行った。
に拡張するものとして
SPLICE/AS の作成に当たって公開鍵方式の暗号が必要であったため、方式を用い、ソフト
その暗号化アルゴ リズムが明らかにされているウエアでの実現を行った。
SPLICE/AS では、暗号化を行う部分は利用者認証システムの中で独立に考えることができ、同じ暗号系の暗号方式であれば容易に置き換えが行なえるような設計を行なうことが可能である。従って、将来ハード ウエア
等でさらに有効な公開鍵暗号が提供されれば 、暗号ルーチンに対するイン
タフェースに変更を加える事により、それを用いる事ができる。
、の作成がほぼ完了して現時点では、各種ライブラリおよび
おり、WIDE インターネットにおける実装を行うための細かい部分の変更・修正を行っている。
などのアプ リ
今後、この部分を完全なものとし 、この応用としてケーションプログラムに SPLICE/AS を組み込み、 の性能向上に向けてより一層の改善を施していかなくてはならない。

AS

MAS

RSA

AS MASAS

444

ftp