第 13 部
利用者認証

467

第

1章

はじめに
現在コンピュータは社会の中で大きな位置を占めている。企業や教育機関はコンピュータを積極的に導入する傾向にある。それに加え、近年のコンピュータの低価格化とロー
カルエリアネットワークの普及が、その傾向をますます強いものにしている。その結果、を構築し 、さらにそれをに代表されるインターネットに接続するサイトも年々急激に増加している。このように多くの人がさまざまな計算機とを用いて、インターネットとの接続を確立し 、インターネットで提供されているさまざまなネットワークサービスを利用するようになってきている。
現在のインターネット環境では何十万という計算機が接続されており、利用者の数はこれをはるか超える。インターネット環境に接続されている計算機全てが厳重に管理されているわけではなく、システムのアカウントさえ取得できれば 、比較的誰でもインター
ネットにアクセスし 、インターネットのサービスを受けることができるようなオープンな環境である場合が多い。これは 、非常に多くの利用者が比較的簡単にインターネットを利用することを意味する。このため、特定の人々だけにアクセスを許しているシステ
ムやサーバに対して不正アクセスを試みる利用者が後を絶たないのも事実であり、インターネットにおける一つの問題となっている。
また、インターネット環境で提供される代表的なサービスの一つであるリモートログイ
ンでは、利用者がログインを行う際のパスワードは、この文字コードがそのままの形でネットワークに伝送される。
に代表されるバス型のネットワークでは盗聴が容易に行うことができる。また、インターネットを介してリモートログインを利用した場
合には、基本的に通信は第三者のネットワークを経由して送られることになる。このよ
うな場合に、通信路中の中継ホストにおいて盗聴が行なわれる危険性が、常に発生している。このような盗聴の問題は、現在のインターネット環境で提供されるサービスでは対処してあることが少なく、特にパスワード の盗聴は深刻な問題を招く。このため、現在のインターネットサービスに対して認証機構を強化したシステムや、通信データの暗号化機能を提供するシステムが研究、開発されてきている。
では 、これまで大阪大学のグループを中心としてネット
ワークセキュリティ、特に認証に関して研究が行われ、と呼ばれる認証システムが開発されてきた。
は暗号を用い、
等によって提案された認証プロトコルに基づいたプロトコルを用い、利用者の認証を行うシステムであったが、暗号処理性能の悪さ、管理構造の問題等いくつかの問題がLAN

WIDE Internet

OS

Ethernet

WIDE Project Security WG(authentication)[134] SPLICE/AS RSA
[135]
469

SPLICE/AS
Needham470

1992 年度 WIDE 報告書[136] 1992
(community)
SPLICE/AS-II

Security WG

SPLICE/AS

報告されていた。
年度のの活動では、このを基にコミュニティ
の概念を導入し 、それらの問題を解決する新たな認証システ
ムであるの設計・開発を行った。
での問題は、
暗号処理の高速化、二重化された認証サーバ、プロトコルの書換えによって解決し 、その応用としての対応化を行った。
本論文の第 章では、現在のネットワーク環境におけるセキュリティ問題、つまり他の計算機になりすますことやネットワークを流れるデータの盗聴・改ざん等の問題について述べる。第 章では利用者を認証するためにはどのような方法があるか、さらに認証に用いることが可能な暗号技術について述べる。第 章ではが導入したコミュニティに基づいた認証モデル、のプロトコル、開発したシステムが利用する設定ファイルについて述べる。第 章ではの応用としてのソースコードに対しての機能を適用する 以後化という ために行った変更点について述べる。 章ではシステムの評価、 章が本論文のまとめとなっている。

SPLICE/AS

RSA

telnet SPLICE/AS-II
2
3

4
SPLICE/AS-IISPLILCE/AS-II
5
SPLICE/AS-IISPLICE/AS-II( SPLICE
67telnet)第2章

ネット ワーク環境におけるセキュリティ問題
本章では、インターネット環境におけるネットワークセキュリティを考えた場合に、脅威となる行為について述べる。

(threat)1. 情報の盗聴
インターネット環境で行なわれる通信では、第三者の組織内のネットワーク機器を複数経由して行なわれることが多い。このため、盗聴を完全に防ぐことは容易ではない。また、のようなバス型のでは、パーソナルコンピュータレベ
ルのネットワークモニタ機器をケーブルに直接接続し 、通信内容を盗聴することが比較的容易である。さらに、リモートログ インサービスを提供する
コマンド、コマンドはパスワード 入力時の文字を暗号化せずに送信しており、パスワード の盗聴は深刻な問題を含んでいる。

Ethernet

EthernetLAN

telnetrlogin2. 他ホスト へのなりすまし通信されるデータに含まれる発信元情報を偽ることにより、他ホストになりすまし 、
情報を不正に得ることが可能である。
ではデータグラムヘッダに含まれる発信元アドレスフィールド のアドレスをもとに合いてホストを識別している。このため、簡単なプログラムを用いてこのフィールドを適当に変更すれば 、そのアドレスを持つホストになりすますことが可能である。

IP

TCP/IP

IP

IP

Eth-

さらに計算機の低価格化も他のホストへのなりすましを容易にしている。現在、インタフェースを具備した計算機は非常に安価になっている。そのような計算機が自由に扱えるのならば 、その計算機のアドレスを適当な値に設定し 、ネット
ワークに接続することによって他の計算機になりすますことが可能である。ただしこの時、なりすました相手の計算機が同じ上で稼働中であればアドレスが重複することになるが相手の計算機がネットワークに接続されていない、もしくは稼働を停止していることがわかっているならば 、なりすましは簡単にできてしまう。

ernet

Ethernet

3. ケーブルを流れるデータの改ざん
ネットワークを流れるデータを盗聴するだけでなく、そのデータの一部分を改ざんして戻すことも可能である。こうすることにより、不正なアクセス権を得られる可能性がある。

471

472

1992 年度 WIDE 報告書

4. 他ホスト、ネットワークへの不要メッセージ発信による運用妨害
これは一般ユーザでも簡単なプログラムを書くことによって可能となる。例えば 、におけるネットワークサービスの一つであるサービスを要求するパケットを、特定のホストに対して無限に送信するプログラムを書いたとする。このプログラムを実行すると、そのターゲットとなるホストはサービスの処理に追われ、コンソールからの入力さえ正常にできなくなってしまう。この種の攻撃は発見することはできても防ぐことは難しい。もし 、異なるネットワークからの攻撃
ならばゲートウェイでパケットフィルタリング
を行なえば 、多くの場合回避することができる。しかし 、攻撃者がパケットのソースアドレスを書き換えて、同じネットワーク内から発信されたように見せかけた攻撃を行った場合はパケットフィルタリングが有効にはならない。

TCP/IPecho

echo(packet ltering)

5. 誤ったネットワーク制御情報の発信

RIP (Routing In-

現在使われているルーティング情報を交換するプロトコルとしてが挙げられる。、
では受け取ったメッセージが通信中に改ざんされていないか、あるいは不正なホストから送り込まれたメッセージではないかといった点についてチェックを行わない。このことにより、偽のルーティング情報が流されると簡単にルーティングテーブルがおかしくなってしまう。

formation Protocol)

RIP

6. ト ラヒック解析
これは学術研究ネットワークにおいてはさしあたっての脅威とはならないが、トラ
ヒックを解析することにより攻撃者にとって有効な情報が得られる場合がある。パケットの発信元と送信先の統計を取ることにより、各種ネットワークサービスのサーバを推測することができる。

(2) (3) (5) (6)

いくつかの問題について述べてきたが、 、 、 、 の問題は通信路での暗号化機能を提供することにより一部阻止できる。
については攻撃の発見はできるが完全に防ぐことは不可能である。
、の問題については利用者認証機構を提供することにより解決できるようになる。この問題に対しバークレー コマンド
等 は、という信頼できるホストをファイルに記述しておき、そのホストからのサービス要求ならばそれに答えるという認証方法を用いている。しかし 、そのホストはいつも信頼できるとは限らない。また、そのホストのユーザ全てが信頼できるとは限らないという理由でこの方法は十分とは言いがたい。

(4)(1) (5)r(rsh, rlogin )trusted host

3章

第利用者認証技術と暗号
本章では、計算機環境での利用者認証技術と、それに用いることが可能な暗号技術について述べる。

3.1

利用者認証技術

計算機環境での利用者認証技術としては、これまでさまざまな方法が考案されてきており、代表的には以下の方法がある。

1. 鍵やカードなど 、本人だけが持っている物理的なもので認証する方法。
2. パスワード、暗証番号など 、本人だけが知っている情報で認証する方法。
3. 指紋、声紋、サイン、掌紋など 、本人の身体的特徴を何らかの形で入力させ、それを元に認証する方法。

(1)

これらの方法のうち、については様々な形で計算機環境に採り入れられてきている。例えば最近のでは、電源の投入を通常のスイッチとロータリーキーによってコントロールするものが多くなってきている。また、
ワークステーションに対しても、カードによる認証を行なうハード ウェアが利用可能になっている。またについてはあまり一般的ではないが、掌紋や眼底血管パターンなどの情報を利用したシステムが開発されており、一部では利用されている。
しかしながら、 、 を一般的な計算機利用環境に導入することを考えると、これらには特別なハード ウェアが必要である。このため、全てのインターネット環境で用いることは現実的に不可能である。また、ネットワークサービスについてこれらの技術を利用することは、現実的ではない。したがって、インターネットサービスを考えた場合には、このようなハード ウェアの使用を仮定するのは無理があり、さらに拡張性が悪くなるので採用しにくい。
一方、 については、現在多くの計算機システムにおいて採用されている。
の方法はシステムに登録した情報が他人に漏れてしまったときに、確かに本人かど うかとい
う認証がうまく行なえくなってしまう。しかしながら、登録された情報の保護を暗号技術を使って行なうことによりシステム側から情報が漏れることをある程度であるが防ぐ

PC

UNIX

(3)

(1) (3)

(2)

(2)

473

474

1992 年度 WIDE 報告書ことができる。ただし 、このときの暗号は一対一の暗号でなければならず、また、容易に逆変換できてはならない。さらに、ネットワーク環境での認証についても、らが提案した方法を適用することにより、原理的にはネットワーク環境においてもの方法を実装することが可能である。

[135]

(2)

3.2

Needham

暗号

ネットワークを流れるデータを盗聴、改ざんから守るためにはデータの暗号化が必要不可欠である。ここでは代表的な暗号方式として
暗号、暗号、ブートストラッ
プ暗号について述べる。

DES

RSA

3.2.1 DES 暗号

NBS(National Bureau of Standards)
1997
DES(Data Encryption Standard)[137]
LUCIFERDES は 56bit の鍵を用いて 64bit の平文を置換と排他的論理和 (XOR) よって暗号文に

米国が連邦政府関係の一般データに適用されるものとして年に発表したものがであり、そのアルゴ リズムはを発展させたものである。
する暗号化方式である。また、ソフトウェアによってもハード ウェアによっても実現されており、たいへん高速に暗号化、復号化が可能で、 コマンドとしてリリース
テープに含まれている ただし米国のみ ほど容易に使える暗号である。

(

)

DES

des

UNIX

Di e、Hellman その他専門家により脆弱性が懸[138][139]56bit では鍵の長さが十分ではないかも知れない。
S(pitfall) がありうると言われている [140]。
64bit 以上の長さを持つメッセージの暗号化には DES を繰り返し適用する必要がある。
どのように DES を適用するかにより ECB(Electoronic Code Book) モード、CBC(Cipher
Block Chaining) モード、CFB(Cipher FeedBack) モード、OFB(Output FeedBack) モードと呼ばれる適用方法がある。この中で CBC モードと CFB モードはあらゆる不法侵入(暗号文の探索、再生、挿入、削除等) に対して強いと言われている。
図 3.1に DES の CBC モード、図 3.2に DES の CFB モードの動作を示す。
米国において標準となっただが、念されている。その理由は、
そして、 ボックスには何らかの落し穴

3.2.2 RSA 暗号

RSA(Rivest{Shamir{Adleman) 暗号 [141] は平文 M を暗号化鍵 (e; n) を用いて暗号文
C をつくり、復号化鍵 (d; n) を用いて元の平文を得るアルゴ リズムである。
CM= M e mod n= C d mod n

第 13 部

475

利用者認証

CLEARTEXTBlock2Block1

IV

Key

DES
(Encipher)

Key

DES
(Encipher)

Block3Key

DES(Encipher)

CIPHERTEXT

Key

DES
(Decipher)

Key

DES
(Decipher)

Key

DES
(Decipher)IV

Block1

図

Block3

3.1: CBC モードの DES の適用方法

Synchronized 64-bit
shift register inputs(initial value from IV)

Transmitter

Key

Block2

DES(Encipher)

DES(Encipher)

Discard

CLEARTEXT

Key

DiscardCIPHERTEXT

図Receiver3.2: CFB モード の DES の適用方法

CLEARTEXT

476

1992 年度 WIDE 報告書

RSA 暗号では 0  M  n 0 1 を満たす M が与えられたとき、(M e mod n)dmodn = M(M d mod n)emodn = Mを満たす。この対称性により RSA 暗号を公開鍵システムとして秘密を守ること (con dentiality)、真正性 (authentication) を保障するために適用することができる。
ここで n は十分大きな素数 p と q の積

n = pqRSAであり、暗号の安全性は n を p と q に因数分解する計算量によっ ている。現在知られている最も高速の因数分解アルゴ リズムを使った場合の計算所要ステップ数はq

T = exp( ln(n)ln(ln(n)))( 3.3)

100

200で与えられる 図。ここで仮に p と q に各々桁の素数を用いたとすると n は桁となり ステップに 秒かかったとすれば n の因数分解に数十億年かかることになる。
また、p と q の選び方にも暗号の安全性は左右され、もし p と q が非常に近い数
であれば

1

1

RSA

p

p

p ' n; q ' n

により p と q のおおよその検討をつけることができる。
因数分解に対する防御手段として p と q の選定について以下の条件を満たせばよいと言われている。

[142]

1. p と q の桁数はほんの数桁だけ異なるようにする
2. p 0 1、q 0 1 も大きな素数を因数に持つようにする
3. gcd(p 0 1; q 0 1) は小さくする
暗号化で注意しなければならないのが M < n が成り立っていなければならないこと
で、もし 、平文が十分長ければ M > n となることがある。この時は平文を M < n の条
件が成り立つようなところで区切って M M1 M2
Mn 各々を暗号化すればよい。

( =

3.2.3

111

)

ブート スト ラップ暗号

RSA 暗号方式の問題は暗号化、復号化の処理が DES 暗号に比べ非常に遅いことである。
長いメッセージを暗号化するには RSA 暗号を複数回適用する必要があるが、実際の通信ではそのオーバーヘッドが問題となってしまう。この問題を解決するために Zimmermannによってブートストラップ暗号が提案されている [143]。
ブートストラップ暗号では単一鍵暗号の鍵ブロック (Key1 ; Key2 ; Key3 ; 1 1 1 ; Keyn )を用
いてメッセージを暗号化し、次にその鍵のブロック (ブートストラップブロック) を RSA で

第 13 部

477

利用者認証

12

10

Log10 T

8

6

4

2

50

100

150

200

250

Log10 n図3.3: n 桁の数字の因数分解の計算量

300

478

1992 年度 WIDE 報告書
CLEARTEXT
Key1Block2Block1

Key2

DES(Encipher)

Key

3

DES
(Encipher)

Block3

Key

n

DES

Block4

DES(Encipher)

Key1(Encipher)

DES

Key1

(Decipher)

CIPHERTEXT

Key

2

DES
(Decipher)

Key

3

DES
(Decipher)Keyn(Decipher)

DES

Key1

Block2Block1

図

Block3Block4

3.4: ブートストラップ暗号のアルゴ リズム
Encrypt by RSA
Encrypt by DESSingle key
Packet図Plaintext
Message

3.5: ブートストラップ暗号されたメッセージ
RSA

暗号化する。復号化では、まずでブートストラップブロックを復号化し、そこで得られた鍵を用いてそれに続く暗号文を復号化する。これにより、暗号の多用を減らし 、かつ暗号の特性を利用しながら高速に暗号化、復号化が可能となる。
は単一鍵暗号の種類は限定しなかったが、
では
の
モードの変
形を使っている。

RSARSASPLICE/AS-II

Zimmermann
DES CBC

第4章

認証システム
2章で述べた問題の解決策としていくつかの認証システムが開発、利用されている。ここでは、それらのうちから Kerberos 、Sun SecureRPC 、SPLICE/AS について述べる。

4.1 Kerberos
Kerberos[144] は M.I.T. で Athena プロジェクトの一環として開発された認証システムである。Kerberos では、パスワードのような他人に知られては困るようなデータをネッ
トワークに流す場合、すべてを DES で暗号化する。
Kerberos は既存のシステムに利用者が付加するシステムであり、既存のネットワーク
プロトコルの必要最低限の変更で使用できる。現在 NFS 、リモートログイン、電子メー
ル等が Kerberos 対応化 (Kerberized) されている。
Kerberos システムはセキュリティ問題に対する解決策の 1 つであるが以下のような問題がある [145]。
 Kerberos を使用するためにはすべてのネットワークサービスを利用するプログラムを作り直さなければならない。このためにはたいへんな労力が必要となる。

 タイムシェアリングシステムではうまく動かない。Kerberos では全ての計算機利用者が読み出す可能であるディレクトリに機密情報を保存する。もし他人がこの情報を複製し使用すれば不正なアクセス権を得ることができる。

 システムソフトウェアの改ざんには無防備である。プログラムにトロイの木馬等が仕込まれることには対応していない。

 認証サーバに侵入されたときシステムの安全性が全くなくなってしまう。

4.2 Sun SecureRPCSun SecureRPC(Remote Procedure Call) は以前の SunRPC に認証機能を付加した RPCであり、SunOS4.0 以降からシステムに付随している。DES を用いる点で Kerberos と同じであるが、SecureRPC には以下の特徴がある。
479

480

1992 年度 WIDE 報告書

 利用者の秘密鍵は公開鍵方式により暗号化され NIS で管理されている。これにより安全な認証サーバを仮定する必要がない。

 付加システムではないので、新たにインストールする必要がない。
現在、SecureRPC は NIS 、NFS で利用することができる。そのための設定は非常に簡単
であり、便利なシステムであるが、鍵の管理が十分に安全でないという問題がある [145] 。

4.3 SPLICE/AS
SPLICE/AS は WIDE Project Security WG の大阪大学のグループで開発を行なってきた認証システムである。 SPLICE/AS は Needham 等によって示された公開鍵暗号を用いた利用者認証プロトコル [135] を基本にシステムが構成されている。さらに管理構造として Internet における DNS(Domain Name System)[146] での名前管理構造に対応した階層的なド メイン構造を導入し 、ド メイン間の鍵の配送を階層的に行なうことで広域
ネットワークでの分散管理・運用を実現したシステムであるが、以下のような問題があ
る
。

[136]
 暗号処理性能が悪い。暗号方式に RSA を用いそれをソフトウェアで実現しているので認証サーバの処理が遅い。

 管理構造の問題。あるド メインに属する計算機や利用者の数が膨大になる場合があり、DNS に対応したド メイン構成では認証サーバに対してトラヒックが集中してしまう場合がある。

 認証サーバが多重化されていない。
 認証サーバによって提供される情報が十分ではない。

5章
SPLICE/AS-II の設計
第SPLICE/AS

前章で述べたようにには実際にインターネット環境に適用する場合に障害となる、幾つかの問題が解決されていなかった。そこで、本研究ではこれらの問題を解決するために、コミュニティという新しい概念を導入し 、新たな認証システムであるの設計と開発を行った。コミュニティを考えることにより、他の認証シス
テムにはない柔軟なアクセス制御を実現することができる。この章ではシステムのモデ
ル、プロトコル等について述べる。

SPLICE/AS-II

5.1 SPLICE/AS-II でのモデル
SPLICE/AS-II ではコミュニティ(community) という概念を導入した。通常、人間社会
では人はグループを作り、それらのグループに属している。そして、ある特定のグループに属しているというその人の「立場」によりそのグループ内でのサービスが受けられるようになっている。
のコミュニティとは、そのグループに対応したものであり、利用者とその利用者にサービスを提供するサーバから構成される。利用者は複数のグループに属することができるのと同様に、複数のコミュニティに属すことができる。また、利用者が複数のコミュニティに属することができるのと同様に、サーバも複数のコミュニティに属することができ、このサーバは複数のコミュニティに対してサービスを提供する。
現在のアクセス制御は、利用者のログ イン名、グループ名、どのホストからのアクセ
スかといった情報で行われるが、このホスト情報つまり、の危険性は 章で述べた。このためではコミュニティという概念を導入し 、その新たな情報に基づくアクセス制御を行う。この新しいアクセス制御は、利用者のログ イン名、利用者の属するコミュニティ名、コミュニティの認証サーバが利用者を認証したことを表す証明となるもの 認証子を用いて認証・アクセス制御を行い、利用者が「コミュニティに属するその利用者であること」であることでアクセスが許可されたり、拒否されたりする。
コミュニティは つまたは複数のリージョンに分かれる。コミュニティをリージョンに分ける理由は以下の通りである。

SPLICE/AS-IItrusted host

SPLICE/AS-II(

authenticator)

1(region) 認証サーバの管理の分散

481

2

482

1992 年度 WIDE 報告書

 認証サービスの分散
 データベースに侵入を受けたときの被害の軽減
 認証サーバ、利用者間のネットワーク切断による被害の軽減
利用者、サーバはコミュニティ内では 1 つのリージョンにのみ属する。また、リージョ
ンは DNS ド メインとは全く関係なく分けることができる。
各リージョンには 1 つの認証サーバがあり、認証サービスを提供する。1 つのコミュニティ内に複数の認証サーバが存在するとき、それらはそれぞれ自分のリージョンに属する利用者を認証し 、他の認証サーバはその結果を信用する。このような信頼関係にある
認証サーバをリンクが張られているという。
利用者がサーバにサービスを要求するときに、サーバと通信を行なうプログラムをク
ライアントと以後呼ぶ。クライアントは、それを起動した利用者が属するコミュニティに属すると考える。
コミュニティ内の利用者を識別するために、各利用者になんらかの情報を持たせる必要がある。
では各利用者に文字の名前を与え、これをログイン名とする。この名前を構成する要素となる文字はヌル文字以外の全ての文字の使用を許している。また、この名前は一つのデータベース内で一意、つまりリージョン内で一意であるとする。

SPLICE/AS-II

5.2

32

サーバの二重化

SPLICE/AS-II
Trusted Third-party Authentication

クライアントとサーバから見た場合、認証サーバは「第三者」に見えるということから、このような認証システムのことをと呼ぶ。このようなシステムでは認証サーバの安全性がシステムの安全性に直接つながる。そのために認証サーバが稼働する計算機を物理的に安全なところに設置するとともに、不必要なサービスをすべて停止しなければならない。これ以外に、認証サー
バのサービスの信頼性を高めるためには、計算機がダウンしたときに備えてサーバの多重化が必要である。
では認証サーバの二重化を行ない、通常認証を行なう認証サーバをマス
タサーバ、マスタサーバがダウンしたときに認証サービスを行なう認証サーバをスレー
ブサーバという。マスタサーバとスレーブサーバが管理するデータベースは同一性が保証される。そのためマスタサーバが持つデータベースに変更があると、マスタサーバはスレーブサーバにそれを知らせる。しかも、管理用ツールを用いてデータベースを変更できるのはマスタサーバに対してのみとし 、スレーブサーバはクライアント、サーバに対してデータを提供するだけで、スレーブサーバのデータベースを変更できるのはマス
タサーバからの要求のみとする。クライアント、サーバプロセスは、まずマスタサーバにコネクションを張ろうとし 、それに失敗するとスレーブサーバにコネクションを張る。
それにも失敗すると処理を断念する。

SystemSPLICE/AS-II

第 13 部

利用者認証

483

5.3 SPLICE/AS-II の構成
SPLICE/AS-II は以下の要素から構成される。
 認証サーバ
認証を必要とするプロセスに対して認証情報を提供する。

 データベース
先に述べたとおり、データベースはネットワーク的にも物理的にも安全な環境で管理されなければならない。
が用いるデータベースでは以下の情報を管理する。

SPLICE/AS-II{ リージョン内の利用者の秘密鍵、公開鍵、パスワード{ リージョン内のサーバの秘密鍵、公開鍵、パスワード{ 信頼できる他の認証サーバの管理者のパスワード

 ライブラリ群
認証サービスを利用するプログラムのためのライブラリ

 管理用ツール
利用者登録、パスワード 変更のためのプログラム

5.4

プロト コルSPLICE/AS-II が用いるプロトコルについて述べる。プロトコルの表記につ
5.1

ここでは
いては表
を用いる。

5.4.1

前提

SPLICE/AS-II では以下の点をプロトコルの設計の前提としている。
1. クライアントは自分のコミュニティの認証サーバのあるネットワーク内でのロケー
ションを知っている

2. サーバは自分のコミュニティの認証サーバのあるネットワーク内でのロケーション
を知っている3. 認証サーバが用いるデータベースは安全に管理されている

484

1992 年度 WIDE 報告書

記号

AS
S
C
L
Com
PW
PW'
U

AS

timestamp
life

SKX
PKX
SSK
msg

fM gK
[M ]K

意味
認証サーバ
サーバ
クライアントクライアントのログイン名
コミュニティ名に登録されている暗号化されたパスワード
ユーザが入力する暗号化されたパスワード
ユーザ
認証子を発行したタイムスタンプ
認証子の有効期間の秘密鍵の公開鍵
セッション鍵。十分大きな整数 乱数
セッション鍵よりも大きな整数 乱数を鍵としてメッセージ の暗号化を鍵としてメッセージ の
暗号化

X
X

( )
( )
M RSA
M DES

K
K
表 5.1: プロトコルの表記に用いる略称

第 13 部

5.4.2

485

利用者認証

利用者の認証() SPLICE/AS-II

利用者 ユーザ はのセキュリティ機能を利用するにあたり利用者自身の公開鍵と秘密鍵を認証サーバから手に入れる必要がある。しかし 、認証サーバそのものが偽物であるかもしれず、偽物の鍵を入手すると以後の通信を盗聴・改ざんされる可能性がある。よって認証サーバが利用者を認証するとともに、利用者も認証サーバを認証しなければならない。これには以下のプロトコルを用いる。

1. 利用者はコミュニティ名、ログイン名、パスワードを入力する。
2. ログインプログラムはコミュニティ名から AS を知る。
3. U!AS:(1 0 1)

U; AS; L

このメッセージには利用者のログイン名しか含んでいないので暗号化する必要はない。

4. 認証サーバは受け取ったメッセージのログイン名を用いて利用者のパスワードをデー
タベースから検索し 、そのパスワードを鍵として認証サーバの公開鍵を DES 暗号化する。利用者の名前がデータベースになければこのメッセージは偽物であるとする。

5. AS!U:AS; U; L; P KAS ; fAS; P KAS ; [P KAS ]PW gSKAS
1

2(1 0 2)

3

6. ログインプログラムは P KAS で f1 1 1g を復号し 、PKAS と P KAS を比較する。つぎにユーザが入力したパスワード P W 0で [P KAS ]PW を復号する。ここで、PW は本物の認証サーバだけが知っているので、[PKAS ]PW を作れるのは本物の認証サーバだ
1

1

2

3

3

けである。また、これを復号できるのは本物のユーザだけである。この復号で得られた P KAS3 と前の つの P K を比較する。これでユーザは認証サーバを認証することができ、正しい公開鍵を得ることができた。

2

7. ログインプログラムはセッション鍵 SSKと msgを生成する。
8. U!AS:
U; AS; L; fU; L; Com; SSK; msg; [msg]PW gPKAS(1 0 3)
9. 認証サーバはメッセージを SKASで復号しコミュニティ名のチェックを行い、msgを得る。次にユーザのパスワードと msgから [msg ]PW を生成し 、[msg]PW と比較す00る。これらが同一になるためにはユーザが正しいパスワードを入力する必要がある
ので認証サーバはユーザを認証することができる。

10. 利用者の認証ができれば認証サーバは以下の認証子 (authenticator) を作成する。
Authenticator = fL; Com; P KU ; timestamp; lifegSKAS(1 0 4)

486

1992 年度 WIDE 報告書

11. AS!U:

AS; U; L; [AS; P KU ; SKU ; Authenticator]SSK

12. このメッセージを復号することにより利用者は自分の本物の公開鍵と秘密鍵を得ることができる。ここでユーザのログ インセッションを終了する。利用者はこのAuthenticatorをサーバにサービスを要求するときまで保持しておく。

replay attack(1{1) (1{2) (1{3) replay attack

ここで用いている SSK は乱数であり SSK を新たに必要とする度に生成し 、を発見するために用いている。メッセージ
と
と
は
であっ
たとしても実害はない。攻撃者がを盗聴したとしても復号するためには認証サー
バの秘密鍵が必要となり、メッセージ内の SSK を知ることはできない。
がによるメッセージであるとするとクライアントがこのメッセージを正しく復号するためには SSK で暗号する必要がある。SSK は毎回新しく生成するのでのメッ
セージは正しく復号できない。このようにしてを発見する。以後同様の目的でセッション鍵を用いる。
これで利用者は自分の鍵を得たわけであるが、このプロトコルで重要な点は利用者のパスワードが一度もネットワークに流れていないことである。
では利用者のパスワードが他人に知られてしまえばその人になりすますことができる。このプロ
トコルを用いれば盗聴によってパスワードが他人に知られることはあり得ない。データ
ベースが他人に覗かれることがないと前提しているので、利用者が自分のパスワード を他人の目に触れるところに書いておかない限り他人が自分になりすますことはできない。
また、パスワードは容易に推測できるものであってはならない。

(1{3)(1{4) replay

attack(1{4)

replay attack

SPLICE/AS-II

5.4.3

サーバの起動サーバを起動できるのは、通常そのサーバの管理者だけである。サーバの起動では、そのサーバの管理者のみが知っているパスワード を入力し 、正しく入力したときのみ起動するようにする。
サーバも利用者と同じく自分自身の公開鍵と秘密鍵、認証サーバの公開鍵を入手する必要がある。そのためのプロトコルは、基本的には利用者の認証のものと同じだが 、サーバには認証子が不必要な点が異なる。また、サーバのログイン名、サーバが属するコミュ
ニティ名はサーバプログラムの中に書かれているので入力する必要はない。

1. サーバの管理者はパスワードを入力する。
2. コミュニティ名から AS を知る。
3. S!AS:(2 0 1)

S; AS

4. AS!S:AS; S; P KAS ; fAS; P KAS ; [P KAS ]PW gSKAS
1

2

3(2 0 2)

第 13 部

5. S!AS:

487

利用者認証

S; AS; fS; Com; SSK; msg; [msg]PW gPKAS(2 0 3)

AS; S; [AS; P KS ; SKS ]SSK

(2 0 4)0

6. AS!S:

7. このメッセージを復号することによりサーバは自分の本物の公開鍵と秘密鍵を得ることができる。

5.4.4

サーバのリンク

1 つのコミュニティには複数の認証サーバを置くことが可能であるが、他の認証サーバとリンクを張るときにその認証サーバがお互いに相手の公開鍵を得る必要がある。ここでは認証サーバ AS1の管理者が AS2にリンクを張るとする。このとき認証サーバど うしがお互いを認証しなければならないが、そのプロトコルは利用者の認証のものとほぼ同じである。

1. AS1の管理者は AS2のホスト名、パスワードを入力する。
2. AS1 ! AS2:

(3 0 1)

AS1; AS2 ; L

ここで L は AS1の管理者であることを識別する名前である。

3. AS2 ! AS1:
AS2; AS1; P KAS ; fAS2 ; P KAS ; [P KAS ]PW gSKAS
21

22

23

(3 0 2)2

4. AS1 ! AS2:
AS1 ; AS2 ; L; fAS1 ; L; Com; SSK; P KAS ; msg; [msg ]PW gPKAS
01

5. AS2 ! AS1:

AS2; AS1; [AS2 ]SSK

2

(3 0 3)(3 0 4)

6. このメッセージを復号することにより認証サーバはお互いの本物の公開鍵を得ることができる。

488

1992 年度 WIDE 報告書

5.4.5

クライアント ・サーバ間の認証

クライアントがサーバに対して何らかのサービスを要求するときはクライアントがサー
バを、サーバがクライアントを認証する必要がある。認証をより確かなものにするために、サーバはクライアントが認証サーバによって認証されたことの証明である認証子を要求する。
ここではクライアントはサーバの公開鍵を、サーバはクライアントの公開鍵を、また利用者の認証を行った認証サーバの公開鍵を知っているものとする。もし 、サーバとク
ライアントが同じリージョンに属しているとすると、クライアントは認証サーバにサー
バの鍵を要求し 、認証サーバはその鍵を自分のデータベース内に管理しているのでそれを取り出し返送すればよい。しかし 、クライアントとサーバが異なるリージョンに属している時は、認証サーバはサーバの鍵を取り出すことができない。このため認証サーバ
はそのサーバの鍵を管理している認証サーバに転送を要求するようにする。この時認証サーバが、どのようにして相手の認証サーバを決定するかという問題がある。この問題に答えるプロトコルは章、章で述べる。

5.4.6

5.4.7

1. クライアントはセッション鍵 SSKC を生成する。
2. C!S:
C; S; ffC; AS; SSKC ; Com; AuthenticatorgSKC gPKS

(4 0 1)

ここで ASは利用者を認証した認証サーバ、つまり Authenticator を発行した認証
サーバのことを表わす。

3. サーバはこのメッセージを復号し 、コミュニティ名、認証子の有効期間のチェックを行なう。このメッセージはクライアントの秘密鍵で暗号化されているので確かにクライアントが作成したメッセージであるといえる。

4. S!C:S; C; ffS; SSKC ; SSKS gSKS gPKC

(4 0 2)SSKS はサーバが生成したセッション鍵である。

5. クライアントは SSKC の整合性を確かめてサーバがクライアントを認証したと知る。
6. C!S:
C; S; ffC; SSKS gSKC gPKS
(4 0 3)
7. サーバは送られてきた SSKS の整合性を確かめて replay attack を発見する。
ここでクライアントとサーバがお互いを認証できた。以後のクライアント、サーバ間の通信は SSKC 、SSKS を鍵として暗号化する 図。

( 5.1)

第 13 部

489

利用者認証

encrypted by DES
with SSKc
ClientProcess

Server
Processencrypted by DES
with SSKs

図

5.4.6

5.1: 認証後のクライアント・サーバ間の通信

サーバの公開鍵の入手

クライアントがサーバの公開鍵を入手するプロトコルを述べる。このときに問題となるのが「認証サーバは自分のリージョン外のサーバがどのリージョンに属しているか分からない」ことである。このため、認証サーバは「そのサーバを知っていそうな認証サーバ」を知っている必要がある。実際のプログラムではコンフィグレーションファイルとして与えるがその詳細は章で述べる。
ここではクライアントが属するリージョンの認証サーバを AS1 、サーバを知っていそうな認証サーバを AS2とする。

5.5

1. C! AS1:

C; AS1; ffC; S; SSKC gSKC gPKAS(5 0 1)1

2. ここで Sがクライアントと同じリージョンに属しているならば認証サーバ AS1はサーバの公開鍵を知っているのでプロトコル (5{4) を送る。一方 Sが異なるリージョンに属しているならば AS1は S を知らない。AS1は S を知っていそうな認証サーバ AS2に次のメッセージを送る。

3. AS1 ! AS2:

AS1; AS2; ffAS1; S; SSKAS gSKAS gPKAS
1

1(5 0 2)

2

4. もし AS2が Sの公開鍵を知っているならば 、それを AS1に送る。
5. AS2 ! AS1:
AS2 ; AS1 ; ffAS2; S; SSKAS ; P KS gSKAS gPKAS(5 0 3)
6. もし AS2が Sを知らなければ 、同様に Sを知っていそうな認証サーバ AS3に (5{2)のメッセージを送り (3{3) のメッセージを受け取る。PKS を知った AS1はクライア
2

1

1

ントにそれを送る。

7. AS1 ! C:

AS1; C; ffAS1; S; SSKC ; P KS gSKAS gPKC
1

(5 0 4)

490

1992 年度 WIDE 報告書
2

AS 1

AS 2

3

1
4

C
図

5.2: サーバの公開鍵を入手する手順(5{2)

サーバを知っている認証サーバを求めてのメッセージがループするという可能性があるので、実装するときはホップカウントを付け加える必要がある。

5.4.7

クライアント の公開鍵の入手

5.4.6

このプロトコルは章のものと同様である。サーバはクライアントが送ってきた認証子の有効期限を調べる。このとき、この認証子を発行した認証サーバの計算機とサーバの計算機が同じ時刻を刻んでいればよいのだが、内部クロックは事故または故意に変更されることがあり、サーバのワークステーションの内部クロックを信用するのは安全とは言えない。そこで、ネットワークで接続されている計算機の内部クロックは同期がとれていないという前提のもとでプロトコルの設計を行う。認証子の有効期限を調べる
ためには認証子を発行した認証サーバの内部クロック時刻を知る必要があるのでクライアントの公開鍵とともにその認証サーバの現在時刻をサーバに送るようにする。

1. S! AS1 :2. AS1 ! AS2:

S; AS1 ; ffS; C; SSKS gSKS gPKAS(6 0 1)

1(6 0 2)

AS1; AS2 ; ffAS1; C; SSKAS gSKAS gPKAS
1

1

2

3. AS2 ! AS1:
AS2; AS1; ffAS2 ; C; SSKAS ; P KC ; timestampgSKAS gPKAS
1

4. AS1 ! S:

2

1

AS1 ; S; ffAS1 ; C; SSKS ; P KC ; timestampgSKAS gPKS
1

(6 0 3)(6 0 4)

第 13 部

491

利用者認証

2

AS 1

AS 2

3

1
4

S
図

5.5

5.3: クライアントの公開鍵を入手する手順

リージョンファイル

自分のリージョン内にないサーバがどのリージョンに属するのかを知るためにど うす
るかという問題があった。他のリージョンに属するサーバの名前とその公開鍵を知っている認証サーバが稼働している計算機をすべて並べたファイルを書けば良いが、サーバの数が何百にもなる場合があるので、この方法は現実的とは言えない。
リージョンはド メインとは関係ないのだが、実際にを利用するとド メイン毎にリージョンを分けることが多いと予想される。このため、サーバ
きは
ド メイン名でエントリを検索する方法が有名、そのサーバが稼働している計算機のド メインに従わないサーバのエントリも許さなければなら効と思われる。ただし 、では以下のような設定ファイルを考えた。
ない。

DNS

DNS

SPLICE/AS-II< Regionfile >< entry >< ログイン名 >< サーバアドレス >SPLICE/AS-II

DNS

DNS

::= f< Regionentry >g::= < ログ イン名 > < サーバアドレス > < 認証サーバアドレス >::= サーバ名 j ALL::= ホスト名 : DNSド メイン名

j DNSド メイン名
j ALL

< 認証サーバアドレス > ::= ホスト名 : DNSド メイン名

1

サーバ名とその計算機のフルネームが与えられたとき、このファイルを 行目から順に検索していき、一番最初に見つかったエントリを利用する。
はすべてにマッチする
予約語であり、これをデフォルトルールと呼ぶ。以下に例を示す。

"ALL"

ALL
ALL
stelnetrd.ecip.osaka-u.ac.jp
ecip.osaka-u.ac.jp
arpeggio.ics.osaka-u.ac.jp

asama.rd.ecip.osaka-u.ac.jp
raicho.rd.ecip.osaka-u.ac.jp
raicho.rd.ecip.osaka-u.ac.jp

492

1992 年度 WIDE 報告書
ALL
ALL

ics.osaka-u.ac.jp
ALL3

helios.ics.osaka-u.ac.jp
a.b.c.d

このとき、 .ecip.osaka-u.ac.jp のサーバはすべて raicho のリージョンに属しているが、そのサブド メイン .rd.ecip.osaka-u.ac.jp のサーバは asama のリージョンに属している。一方、 .ics.osaka-u.ac.jp のサーバはすべて helios のリージョンに属しているが、唯一 arpeggio のサーバ stelet だけは raicho のリージョンに属している。どのリージョンに属しているのか分からない場合はとりあえず a.b.c.d に属していることにする。以後は、a.b.c.d が処理を終えメッセージを送るのを待つ。

33

このようにデフォルトルールを加えることにより、すべてを列挙するときに比べエントリ数が減り、他リージョンのサーバの追加、削除には全く関与しなくてもよくなる。
最後に、このファイルは認証サーバだけが参照するファイルなので一般ユーザからは見ることができないようにしている。

5.6

コミュニティファイル

5.4.1章でクライアント、サーバは自分のコミュニティの認証サーバのある所を知っていることを前提とした。実際にはこれをコミュニティファイルというコンフィグレーショ
ンファイルとして与えている。その文法は< Communityfile > ::= f< entry >g< entry > ::= コミュニティ名 認証サーバのポート番号< マスタサーバ > < スレーブサーバ >< マスタサーバ > ::= マスタサーバが稼働しているホストアドレス< スレーブサーバ > ::= [スレーブサーバが稼働しているホストアドレス]と定めている。全てのクライアント、サーバプログラムは起動時にこのファイルを読むことで、接続すべき認証サーバのアドレス、ポート番号を得ることができる。このファ
イルは全てのユーザから見えなければならない、また、変更されても認証サーバには影響を及ぼさなので、全ての利用者が読むことができるようなパーミッションを設定してある。以下に例を示す。

genesis
miya

2500
2500

asama.rd.ecip.osaka-u.ac.jp
helios.ics.osaka-u.ac.jp

第 13 部

5.7

493

利用者認証

利用者、サーバの名前表現

コミュニティ内で各利用者を識別するために、利用者に次のような情報を持たせ、それによって識別する。

typedef struct f
IPaddraddress;
LoginName name;char
host[64];gID;

addressはクライアントプロセスを実行している計算機の IP アドレスであり、nameは利用者のログ イン名、host は利用者の属するリージョンの認証マスタサーバのアドレスである。クライアントプロセスはどの計算機で実行してもよいとするので、利用者のロ
グイン名は、リージョン内で唯一であればよい。
一方、各サーバを識別するためにも上の構造体を用い、address はサーバプロセスを実行している計算機のアドレス、nameはサーバ名、host はサーバの属するリージョンの認証マスタサーバのアドレスである。

IP

5.8

暗号

5.8.1

利用者認証のための暗号

SPLICE/AS-II では利用者の認証をインターネット環境で用いることの拡張性を考えてパスワード で認証を行う方法を採用した。このためには 3章で述べたように一対一であり、かつ、容易に逆変換できてはならい暗号が必要である。この条件を満たす暗号としてはの crypt(3) 関数の暗号化が一般的である。これは全てので標準で提供されており、かつ、現在のところ逆変換のアルゴ リズムは発表されていない。よって
ではこの暗号を用いることにする。
の/etc/passwd ファイルもこの関数で暗号化された情報を持っているが 、このファイルは一般ユーザでも閲覧可能であるところに問題がある。暗号の逆変換はできない
が、適当な単語を crypt(3)で暗号化し 、それを /etc/passwd のエントリと見比べること
によって他人のパスワードを知ることが可能である。筆者の経験でみると二ヵ月に一度はアイドルの名前をパスワードに使っている人を発見することができた。筆者が調べているユーザ数は人前後であるが、この人数で、この確率で発見できるのだから、いかに
パスワードが無防備であるかを知ることができる。このため、系のでは/etc/passwd のパスワード 部分だけを一般ユーザからは見えないファイルに書く shadow
でもパスワード ファイルだ
passward を使うことが一般的となっている。
けでなく、秘密鍵も管理しなければならないので、データベースファイルは一般ユーザ
からはアクセスできないようにする。

UNIX

UNIX

SPLICE/AS-II
UNIX

100

System V

SPLICE/AS-II

UNIX

494

1992 年度 WIDE 報告書

5.8.2

通信情報暗号化のための暗号

SPLICE/AS-II では RSA をソフトウェアで実現するため、その速度の問題から先で述
べたブートストラップ暗号を用い、RSA の鍵は 680bit としている。これは 10 進数に直すと約 200 桁の数字となり、現在の暗号処理の速度と暗号の安全性を考えてこの大きさにした。
の鍵生成はなるべくランダム性をユーザの意志に依存させるよう配慮した。そのための方法として利用者にキー入力をしてもらい、その入力した文字コードとキースト
ロークのインターバルをタイムで計測し 、それを乱数の種として利用している。鍵生成時の様子をリスト に示す。ただしこの出力は鍵生成テストプログラムを実行しているので、生成した鍵が画面に表示されている もちろん実際の鍵変更プログラムでは表示しない 。
これはでの実行結果である。
タイ
ムが :
:
: 秒であることを見れば鍵生成にかなり時間がかかることが分かる。
鍵生成に時間がかかることは悪いことではない。なぜならば 、手あたり次第に鍵を生成
し 、それを使って暗号文を復号化するといった攻撃をやりにくくするからである。
一方、認証後のクライアント・サーバ間の通信はをモードで暗号化している。

RSA

1

CPU

(

)
SPARC station IPX(27MIPS Memory 13MB)
64 3(43 3 + 21 0)

DES CFBCPU第 13 部

利用者認証

nozomi$ time ./keygentest
Generating an RSA key with a 677-bit modulus...
We need to generate 93 random bytes. This is done by measuring thetime intervals between your keystrokes. Please enter some text on yourkeyboard, at least 186 nonrepeating keystrokes, until you hear the beep:................................................................
.................?..............................................
....................................................ooooOOO*-Enough, thank you.
Ignored 1 keystrokes that were typed too fast.
....++++ .................................++++
SK.d:000000000000000003386380284234279582215194428534191234842375059388
85753013060976609224676180011063034644964745695393308206468667679623364
2594193504421966799484086213943529393126612142642845189649556313708817
SK.p:000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000011024342737368749370522749
8861663409288307553572423619904219608283183830454339974738455041070303
SK.q:000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000087706354195164382529815975
2501763896786135963117675951496895173668051022984871089316411077696177
SK.u:000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000066295306810771321637700537
5524857239121066548886159027589112681817701735826403712781314139891742
PK.e:000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000017
PK.n:000000000000000022201489602325587000263624812891964709915296637828
97799556515219950865695260737008390643952587182921326300488104644602241
1020312154827654674481345058171895583451771520640141078859403032305199
66.8 real43.3 user

21.0 sys

リスト 1: 鍵生成の様子

495

第

6章

応用
SPLICE/AS-II の認証機能を利用するために今回 telnet サービスを SPLICE/AS-II 対応に改造した。telnet のソースコードは BSD-tahoe のものを用いたが、システムコールを呼び出している箇所を以下のように書き直し 、認証を行なうライブラリ関数をクライ
アント側、サーバ側にそれぞれ 行加えただけである。
ただし 、
、
、
、
はソケットを対象にしたシステムコールのみを書き換える。
このように比較的簡単に化が行え、実際に使ってみてもログイン時に 分ちかく要するが、それ以後は普通のと変わらない使用感で安全な環境を提供することができた。

1
read recv write send

SPLICE
telnet

変更前

1

変更後

read splice client read
write splice client write
recv splice client recv
send splice client send
表 6.1: クライアント側の変更
496

第 13 部

利用者認証

変更前

変更後

read splice server read
write splice server write
recv splice server recv
send splice server send
表 6.2: サーバ側の変更

関数名クライアント側
サーバ側
表

splice client authentication
splice server authentication

6.3: 認証を行なうライブラリ関数

497

第

7章

システムの評価、考察

7.1

性能

今回作成したシステムで実際の認証にどのくらい時間がかかるのか測ってみた。時間を計測するためには getrusage(2)を用い、認証を行う直前と直後にこのシステムコールを呼び出し 、その差をとった 使用した計算機は。その結果を表に示す。

(

SPARC station IPX)

7.1

RSA をソフトウェアで実現しているため、このようにかなりの CPU 時間を必要としている。プログラムを UNIX の pro le 機能を用いて調べたところ、暗号・復号処理部分、

特に配列同士の乗算と剰余の計算ルーチンから呼び出される足し算、引き算ルーチンにかなりの時間が消費されていることが明らかになった。このルーチンだけを特性に合わせたコードを書くことによってより高速化が計れると思われる。

CPU

7.2

CPU

サーバの起動

また、現在のシステムではサーバが自動的に起動しない設計になっている。サーバプロ
グラムを起動する際にはパスワード 入力が必要であり、誰かが手で入力する必要がある。
このことはサーバの管理者が管理するサーバの数だけパスワード を覚え、起動し 、それを入力しなければならないことを意味する。これを煩わしいと思う人もいれば、セキュリ
ティのためだから仕方がないと考える人もいると思われる。自動的に起動するほうがよいとは誰もが思うであろうが、この管理者が自分の管理しているサーバを責任を持って定期的にチェックすることによりプログラムの改変を発見することができるので、Kerberos

USER time
SYSTEM time

認証サーバ
リージョン内認証

(

) (

認証サーバ
リージョン外認 証)

クライアント

14.72
21.74
18.75
0.22
0.21
0.11
表 7.1: 認証過程で消費された CPU 時間
498

サーバ

10.81
0.03

第 13 部

利用者認証

499

での問題であったプログラムの改ざんに対して無防備であるという問題が改善される。

7.3

システムの運用

secure

一般にセキュリティを向上させるシステムを使用するにはどこからどこまでがなのかということを知っておかなければならない。
は現システムの根底から改造したわけではなく、な環境の上にな環境を実現させただけであるので、どこかにその境界が存在するわけである。利用者はそれがどこなのかを理解してシステムを使用しなければが意味のないものになってしまう。

unsecure

SPLICE/AS-IISPLICE/AS-II
secure

第

8章

おわりに
SPLICE/AS-II では他の認証システムにはないコミュニティという概念を導入し 、柔軟なアクセス制御機能を提供し 、また、コミュニティをリージョンに分けることにより広域分散ネットワークでの認証を行うことを可能とした。
本研究ではこのシステムのモデルの定義、プロトコルの設計、データベースの設計を行い、システムの実装を行った。暗号処理部は、既存ツールの
暗号、暗号ソフトウェアの一部変更を行いシステムに組み込んだ。そして、の化を行い安全なリモートログイン環境を提供した。
セキュリティ問題はシステムを提供する側だけでなく、利用者側も十分理解しなければならないものである。一つの計算機が侵入されると、その計算機を足掛かりにして別の計算機へ次々と侵入を繰り返すことが可能となるので、ある計算機のセキュリティ管理を怠ることは、自分は構わないと思っていても他人の迷惑になりうる。しかし 、現在セキュリティツールが身近なものになっていないせいかユーザのセキュリティ意識は浅い。
現在では未実装の部分が幾つかあり、今後これを行い、さまざまなツールの化、そして普及に努めていく予定である。

SPLICE/AS-IIDES
SPLICE

RSA
telnetSPLICE/AS-IISPLICE500