OPIE − 全てにワンタイムパスワードを

OPIE は Bellcore 社の S/Key の第 1 版の配布物から派生したパッケージで す。このパッケージは、繰り返し攻撃 (下記参照) からシステムを守るのに 役 立 ち ま す。 OPIE ではこのような機能を果たす為に、暗号的ハッシュ関数と チャレンジ / レスポンスシステムを用いています。このパッ ケー ジ で は、 login(1) や、 su(1) および、 ftpd(8) などとの置換えとして OPIE 認証を組 み込んだプログラムを提供しています。更に、OPIE 認証を用いるためには、プ ロ グラムをどの様に書き直すべきかということも例示します。 OPIE は、合衆 国海軍研究所 (the United States Naval Research Laboratory "NRL") におい て、同研究所で使用する為に開発されました。 OPIE の或る部分は、 Berkeley Standard Distribution UNIX 及び、 Bellcore 社の S/Key の Version 1 の配 布物から派生したものです。

通 常のユーザの観点からすれば、 OPIE とは、ユーザのアカウントをクラック から守ってくれるものの、面倒くさいというのが実情でしょう。ユーザが初 め て OPIE を使いたいと思ったときには、 opiepasswd(1) コマンドを用いて、自 分自身に関する項目を OPIE データベースに登録する必要があります。その 後 で あ れば、このユーザは、OPIE を組み込んだどのようなプログラムにおいて も、自らを認証するために OPIE を使用できます。他に何もクライアントが 使 用されていない場合には、 telnet, rlogin, ftp によってシステムにログイン するとき、 (モデムのような) 端末回線にログインするとき、他のユーザに ア カ ウントを切り替えるときに、 OPIE を使用できます。通常ならユーザにパス ワードの入力を求めるというような場面では、サーバはチャレンジを表示し ま す。 この時、ユーザは、チャレンジをコピーして (又は、ウィンドウシステム のようなものによってコピーペーストが行えない場合には、手でタイプし直 し て) OPIE 計算機に入力し、更にパスワード (パスフレーズ) も OPIE 計算機に 入力しなければなりません。それから、このユーザのパスワードとし て、OPIE 計 算機からレスポンスをコピーしなければなりません (又は、手でタイプし直 さなければなりません)。最初は、このような手続きは厄介に思えるかもしれま せん。しかしながら、いくらか練習をすれば容易になるものです。

ユーザ名

システムがユーザを識別する名前です。例えば、"jdoe"。

秘密のパスワード

秘 密のパスワードは通常ユーザが選定するもので、システムへのアク セス権を得る為に必要となります。例えば、"SEc1_rt"。

チャレンジ (誰何)

ユーザを認証する必要がある場合にシステムにより表示される、一 組 の 情報です。 OPIE では、チャレンジを構成する組合せは、ハッシュ 識別子、シーケンス番号、及びシード (種) の 3 項目です。 OPIE 計 算 機が適正なレスポンスを生成するには、これらの情報が必要です。 例えば、"otp-md5 95 wi14321"。

レスポンス (応答)

このチャレンジから生成される一組の情報は、ユーザを認証する為 に シ ステムにより使用されます。 OPIE におけるレスポンスは、6 個の 単語を一組にしたもので、その生成はチャレンジと秘密のパスワー ド を 入力して OPIE 計算機を用いて行います。例えば、"PUP SOFT ROSE BIAS FLAG END"。

シード (種)

これは、レスポンスを計算する為に秘密のパスワードとシーケンス 番 号と一緒に使用される 1 個の情報です。その目的は同一の秘密のパス ワードを、シードを変更するだけで複数のチャレンジレスポンス系 列 に 対して使用できるようにしたり、異なるシードを使うことで複数の マシンに対する認証に使用できるようにすることです。

シーケンス番号

鍵の繰り返しを見張るために用いられるカウンタです。 OPIE で は、 シ ステムが受け取るレスポンスが成功する度にシーケンス番号は減っ ていきます。例えば、"95"。

ハッシュ識別子

正しいレスポンスを生成するために使用する、実際のアルゴリズム を 識 別するための文字列です。 OPIE では、有効なハッシュ識別子は 2 つしかありません。 1 つ目のハッシュ識別子は "otp-md4" で MD4 の ハッ シュ 関 数 を指定します。そして、 2 つ目のハッシュ識別子は "otp-md5" で MD5 のハッシュ関数を指定します。

読者が telnet(1) のようなネットワーク通信プログラムを使用している と き や、 コンピュータシステムにログインするためにモデム迄も用いているときに は、ログイン名と秘密のパスワードが必要となります。読者のログイン名と 秘 密 のパスワードをシステムに入力できる人であれば、誰でも読者であると識別 されてしまいます。それと言うのも、理論的には読者のパスワードを知って い る のは読者しかいないはずだからです。残念なことに、今や多くのコンピュー タ通信メディアでは盗聴が容易になっています。モデムや多様なネットワー ク に よって通信するとき、ユーザのパスワードは遠隔地へのリンクにおいて通常 安全とは言えません。ユーザがパスワードをネットワークに流すと き ク ラッ カー が盗聴していたら、そのクラッカーはパスワードのコピーを手に入れて何 時でも好きなときに読者のアカウントに侵入することができます。一 度 な ら ず、 インターネット上の多くのサイトではこの通りの手口で侵入されてきまし た。

攻撃者にしてみればたった一度でよいからパスワードを捕捉して、サーバに 要 求 されたときにそのパスワードを繰り返しさえすればよいのです。たとえパス ワードが符号化や暗号化されてマシン間で通信されていても、クラッカーが 事 前 に捕捉していた通信を繰り返しするだけで侵入できる限り、ユーザは危険な 状態にあります。ごく最近まで、Novell NetWare はこれが弱点でした。クラッ カー に は 本当のパスワードが何であるかは分かりませんでした。しかし、ク ラッカーは知る必要もなかったのです — 何故なら、ユーザのアカウントに侵入 す る為には、暗号化されたパスワードを捕捉しサーバに要求されたときにその パスワードを返信しさえすればよかったからです。

繰り返し攻撃の問題に対する一つの解決策は、パスワードを符号化する方法 を 変 え続けることで、リンクを越えて他のシステムに送り込まれる暗号を唯一度 だけしか使用できないようにすることです。もしこのようなことが可能であ れ ば、 ク ラッカーは何度でも気が済む迄繰り返し攻撃ができるでしょう — しか し、幾らやってもどこのシステムにも侵入できないでしょう。とはいえここ で 重 要なことは、符号化したパスワードを元にして真のパスワードやこれから使 用する符号化したパスワードをクラッカーが見破ってしまわない様な方法 で、 念 入りに符号化を施すことです。そうしなければ、符号化しない方式や固定的 な符号化の方式に比べれば改善ではあるものの、やはりアカウントは侵入さ れ る可能性があります。

こ れら総ての問題に対する解決策は、1981 年に Lamport が発明しました。こ の技術は、Bellcore 研究所において Haller, Karn, Walden らにより実装され ました。彼らが作成したフリーソフトウェアパッケージは "S/Key" と名付けら れ、暗号的チェックサム (暗号的検査合計) というアルゴリズムを使用して い ま し た。 暗号的チェックサムとは優れた一方向性の関数で、関数の出力が分 かったとしてもそれでもなお攻撃者は実質的には入力が特定できないような も のです。そして、巡回冗長検査のチェックサム (CRC) と異なっていることは、 暗号的チェックサムには結果が同一のハッシュ値となる入力が殆んど無いと い うことです。

S/Key では、変化するのはパスワードが暗号的ハッシュ関数に代入される回数 です。まずパスワードは暗号的ハッシュ関数に一度代入されます。その出力 の ハッ シュ関数値は再び暗号的ハッシュ関数に代入されます。その出力値は更に 又暗号的ハッシュ関数に代入されます。そして、この繰り返しは、パスワー ド が 暗号的ハッシュ関数に代入される回数が目標のシーケンス番号に達するまで 続けられます。この方式は、まあ、例えばシーケンス番号をパスワードの前 に 挿 入して暗号的ハッシュ関数に一回だけ代入するやり方よりもかなり遅くはな ります。しかし、この方式にはユーザにとってとりわけ意義深い利点があり ま す。 ユーザが接続しようとしているサーバマシンは上述のゴチャゴチャの計算 全体の結果が正しいかどうかを判断するための何らかの手段を持たなければ な り ません。サーバが何らの符号化もないままか、或いは通常の符号化だけでパ スワードを保管している場合には、クラッカーはやはりユーザのパスワード を 入 手できるでしょう。しかしサーバマシンが暗号的ハッシュでパスワードを保 持しているならば、シーケンス番号が変化しているのに、どうやって毎回レ ス ポ ンスの変化を計算すれば良いのでしょうか、また、盗聴できないようなマシ ンにユーザがどうやっても辿りつけない場合にはどうすべきでしょうか？ ユー ザ はリンクを越えてパスワードを送信せずにどうやってパスワードを変更した らよいのでしょうか？

心に留めておくべき Lamport が考案した巧妙な解決策とは、シーケンス番号は 常 に 1 づつ減少させること、次に S/Key システムでは単にシーケンス番号 N のレスポンスを暗号的ハッシュ関数に代入して計算するだけでシーケンス番 号 N+1 のレスポンスを得ることがるできこと、ただし、逆方向の計算はできない ということです。さて、任意の指定された時刻に最後に有効であったシステ ム が持っているレスポンスのシーケンス番号を N+1 とし、ユーザがシステムに指 定したレスポンスのシーケンス番号を N とします。 N 番のレスポンスを生 成 す る パ ス ワードが N+1 番のレスポンスを生成するパスワードと同じ場合に は、N 番のレスポンスを暗号的ハッシュ関数にもう一回代入して総計 N+1 回目 の代入を行い、 N+1 番のレスポンスと同じものを得ることができます。これら 2 個のレスポンスを比較して同じ場合には、N から 1 を引いて今証明したばか り の N 番のキーを N+1 番の新しいキーにすることができます。ユーザはこの 新しいキーを保存して次回にキーを証明しなければならないときに使用でき ま す。 このことは次のことをも意味しています。即ち、ユーザがパスワードを変 更しなければならないのにマシンにアクセスする安全な方法がない場合に は、 ユー ザ の パスワードを認証する為にシステムに本当に必要とされるものは、 ユーザが開始したいシーケンス番号より 1 つだけ大きいシーケンス番号に対す る有効なレスポンスであるということです。

良 い対策としてだけの理由で、実際にレスポンスを生成したり認証したりする 時に、この全ての認証のどちらの側においてもパスワードに加えてシードを 使 用 できます。これにより、万一の時に備えて状況を複雑に混ぜ返すことに多少 は役立ちます。そうでなければ、潤沢な時間とディスクスペースを自由にで き る クラッカーは、数多くのありふれたパスワードに対応するレスポンスを全て 生成してシステムを打ち負かすことができるでしょう。

以上記述したことは決して S/Key アルゴリズムがどう機能するかということや 幾 つ か のより細部の項目についての最良の説明ではありません。ですから、 ユーザはこの問題について現在公開されているいくつかの論文を参照するべ き で しょう。以上は覆いの下で何が行われているかということについてのほんの 間に合わせの入門です。

OPIE 配布物は 3 つの標準的なクライアントプログラムに組み込まれ て い ま す。即ち、 login(1) , su(1) , 及び ftpd(8) です。

OPIE 配布物には又、OPIE システムに固有な 3 つのプログラムがあります。即 ち、 opiepasswd(1) はユーザがパスワードを設定したり変更したりするのに使 用します。 opieinfo(1) はユーザが現在のシーケンス番号やシードを調べるた めに使用します。そして、 opiekey(1) は OPIE 鍵計算機です。

OPIE 配布物にクライアントとして含まれているプログラム以外のユーザプログ ラ ムに OPIE 認証を組み込むことはさして困難なことではありません。まず第 1 に、プログラムのどこかに <stdio.h> が include されていることを確認 し なければなりません。次に、<stdio.h> や他の include 宣言の後方でかつ、変 数宣言の前方に、 <opie.h> を include しなければなり ま せ ん。 "struct opie" 型の変数を読者のプログラムに加えなければなりません。読者がユーザ のパスワードを格納するのに用いるバッファが OPIE_RESPONSE_MAX+1 個の文字 を 充分保持できるだけ大きいことを確認する必要があります。そして、チャレ ンジ文字列を格納するバッファも OPIE_CHALLENGE_MAX+1 個の文字を充分保 持 できるだけ大きいことを確認しなければなりません。

読 者 が チャ レ ン ジ 文字列を表示してユーザの名前を知ろうとする時は、 opiechallenge 関数を呼出して下さい。更に、受取ったレスポンスを照合す る 為には opieverify 関数を呼出して下さい。例えば、

#include <stdio.h>

.

.

#include <opie.h>

.

.

char *user_name;

/* 常に末尾のヌル文字を忘れないこと! */

char password[OPIE_RESPONSE_MAX+1];

.

.

struct opie opiedata;

char opieprompt[OPIE_CHALLENGE_MAX+1];

.

.

opiechallenge(&opiedata, user_name, opieprompt);

.

.

if (opieverify(&opiedata, password)) {

printf("Login incorrect");

ユー ザが OPIE を使用する際には、誰かが盗聴をしてパスワードを捕捉できる ような安全でない経路を通じてパスワードを送信しない様に注意しなければ な り ま せ ん。回線を盗聴してパスワードを取得しようとする者から、ユーザを OPIE は保護可能です。しかし、これは実は限られた場合であって、ユーザが必 ず パスワードそのものを通信回線に送信しない様に行動する時だけです。肝腎 なことは、OPIE 計算機を動作させるマシンは、常にユーザが現実に手元で使用 しているマシンでなければならないということで — 決してネットワークやダイ アルアップ回線の向こう側のマシンであってはいけません。

X ウィンドウシステムに関しては注意が必要です。その理由は X ウィンドウシ ス テムを使うと事情が大きく変わるからです。例えば、ユーザが xterm (又は 好みの同等プログラム) をどこか別のマシン上で動作させそれをユーザのマ シ ンに表示させる場合には、OPIE 計算機をそのウィンドウで動作させてはいけま せん。秘密のパスワードをキーインした場合には、パスワードはやはりネッ ト ワーク上を xterm が動作しているマシンまで伝送されます。ネットワーク越し にしか OPIE 計算機を動作させられない X 端末のようなマシンを使用している 人 達は特に危険にさらされています。というのも、実はこのような人達には他 に選択の余地がないからです。また、他の何らかのウィンドウシステム (例 え ば、NeWS) と 同 じように X ウィンドウシステムを使用している場合、喩え OPIE 計算機をローカルマシン上で動作させていたとしても読者のキー操作を読 んでパスワードを捕捉することは往々にして可能です。 X サーバを守るために 常に読者のシステムで利用可能な最高のセキュリティ手段を使用する べ き で す。たとえそれが、XDM-AUTHORIZATION-1 や XDM-MAGIC-COOKIE-1、或いはホス トアクセスコントロールであったとしても。＊決して＊どのマシンでも読者 の サー バに接続できるようにしてはいけません。何故なら、こうしてしまうと、 読者が気がつかないうちに、読者の何らかのウィンドウやキー操作を読み出 す ことを、任意のマシンに許すことになるからです。

ftpd(8) login(1), opie(4), opiekeys(5), opieaccess(5), opiekey(1), opieinfo(1), opiepasswd(1),

Lamport, L. "Password Authentication with Insecure Communication (安 全 で な い通信におけるパスワードの認証)", Communications of the ACM 24.11 (November 1981), pp. 770-772。

Haller, N. "The S/KEY One-Time Password System (S/Key ワンタイ ム パ ス ワー ド シ ス テ ム)", Proceedings of the ISOC Symposium on Network and Distributed System Security, February 1994, San Diego, CA.。

Haller, N. and Atkinson, R, "On Internet Authentication (インターネット の 認 証 に関して)", RFC-1704、 DDN Network Information Center, October 1994。

Rivest, R. "The MD5 Message Digest Algorithm (MD5 によるメッセージダ イ ジェ ス ト のアルゴリズム)", RFC-1321、 DDN Network Information Center, April 1992。

Rivest, R. "The MD4 Message Digest Algorithm (MD4 によるメッセージダ イ ジェ ス ト のアルゴリズム)", RFC-1320、 DDN Network Information Center, April 1992。

Bellcore 社の S/Key は Bellcore 社の Phil Karn,
Neil M. Haller, John S. Walden が書きました。 OPIE は NRL に お い て Randall Atkinson, Dan McDonald, Craig Metz が作成しました。

"S/Key" はベル通信研究所 (Bell Communications Research [Bellcore]) の所 有する登録商標です。 "UNIX" は X/Open の所有する登録商標です。

OPIE は Bellcore 社の「 S/Key ユーザーズ」メーリングリストにおいて議 論 さ れています。このメーリングリストに参加するには、申込みの電子メールを 次のアドレスに送って下さい:

skey-users-request@thumper.bellcore.com