名称

OPIE -何をするにもワンタイムパスワード

解説

OPIE は、繰り返し攻撃 (下記参照) からシステムを守るために役に立つ、 Bellcore S/Key バージョン 1 配布から派生したパッケージです。それは、安全なハッシュ関数とチャレンジ/レスポンスシステムを使用します。それは、OPIE 認証を使用するためにプログラムをどのように適合するかの実例と同様に、OPIE 認証を使用する login(1), su(1) と ftpd(8) プログラムの置き換えを提供しています。 OPIE は、United States Naval Research Laboratory (合衆国海軍研究所 (NRL)) で開発されました。 OPIE は、Berkeley Standard Distribution UNIX と Bellcore S/Key バージョン 1 配布と離れて作成されました。

普通のユーザの観点から、OPIE は、ユーザのアカウントが侵入されるのを防止する邪魔者です。ユーザが始めて OPIE を使用したいと望むとき、 OPIE データベースにユーザのためのエントリを入れるために opiepasswd(1) コマンドを使用する必要があります。その後、ユーザは、それをサポートするあらゆるプログラムでユーザ自身を認証するために OPIE を使用することができます。他のクライアントが使用されていないなら、これは、システムに telnet, rlogin, または ftp を行うために、(モデムのような) 端末ポートでログインするために、または別のユーザアカウントに切り替えるために OPIE を使用できることを意味します。通常パスワードの入力を求めるられるとき、彼らは、サーバからチャレンジ (課題) を受けます。そして、彼らは、電卓プログラムに、そのチャレンジ (課題) をコピーして (ウィンドウシステムのようなものでコピーとペーストの能力がないなら、タイプしなおして)、パスワードを入力して、次に、それらのパスワードとして電卓からの応答をコピーする (またはタイプしなおす) 必要があります。これは、最初は、厄介に思えるかもしれませんが、いくらか練習すれば容易になります。

術語 (terms)

ユーザ名

システムが利用者を認識している名前。例えば、"jdoe"。

秘密のパスワード

システムへのアクセスを得るために必要となる、通常ユーザによって選択されるパスワード。例えば、"SEc1_rt"。

チャレンジ (課題)

ユーザを認証したいとき、システムによって出力される情報のパケット。 OPIE で、これは、ハッシュ識別子、シーケンス番号とシード (種) から成る 3 項目のグループです。この情報は、適切な応答を生成するために OPIE 電卓によって必要とされます。例えば、"otp-md5 95 wi14321"。

応答

ユーザを認証するためにシステムによって使用される、チャレンジから生成される情報のパケット。 OPIE で、これは、チャレンジと秘密のパスワードを与えられた電卓によって生成される 6 つの単語のグループです。例えば、"PUP SOFT ROSE BIAS FLAG END"。

シード (種)

応答を計算するために秘密のパスワードとシーケンス番号とともに使用される情報の一部。その目的は、シードを変更することによって、複数のシーケンスのために、または異なるシードを使用することによって複数のマシンを認証するために、同じ秘密のパスワードを使用することができるようにすることです。

シーケンス番号

キーの繰り返しの経過を追ために使用されるカウンタ。 OPIE で、成功した応答がシステムによって受け取られるたびに、シーケンス番号は、減少します。例えば、"95"。

ハッシュ識別子

適切な応答を生成するために使用する必要がある実際のアルゴリズムを識別するテキストの一部。 OPIE で、2 つの有効なハッシュ識別子は、MD4 ハッシュを選択する "otp-md4"と MD5 ハッシュを選択する "otp-md5"のみです。

 

繰り返し攻撃

telnet(1) のようなネットワーク端末プログラムを使用するか、またはコンピュータシステムにログインするためにモデムを使用するときでさえ、利用者は、ユーザ名と秘密のパスワードを必要とします。理論的に、利用者だけが利用者の秘密のパスワードを持っているはずなので、システムにそれらを供給することができる人であれば誰でも利用者として認識されます。残念ながら現在、多くのコンピュータ通信メディアで盗聴することは、簡単です。モデム通信から多くのネットワークまで、利用者のパスワードは、通常リモートリンクに渡って安全ではありません。利用者がパスワードを送るとき、クラッカー (cracker) が盗聴することができるなら、彼 (彼女) は、将来いつでも利用者のアカウントにアクセスするために使用することができる利用者のパスワードのコピーを手に入れられます。一度ならぬ機会に、インターネット上の主要なサイトは、まさしくこの方法で侵入されています。

すべての攻撃者が行わなければならないことは、一旦利用者のパスワードを捕捉して、次に、それが要求されるとき、サーバにそれを繰り返します。たとえパスワードがコード化されるか暗号化された形式でマシンの間で通信されていても、クラッカーが単に事前に捕捉されていた通信を繰り返すことによって侵入することができる限り、利用者は、危険にさらされています。つい最近まで、Novell NetWare は、このように脆弱でした。クラッカーは、利用者のパスワードが実際に何であるかが分かりませんでしたが、彼 (彼女) は、分かる必要はありませんでした -- 利用者のアカウントに入るのに必要なものすべては、暗号化されたパスワードを捕捉して、それが求められるとき、サーバに送り返すことです。

ワンタイムパスワード

繰り返し攻撃の問題の 1 つの解決策は、別のシステムにリンクを越えて送られるものが、ただ一度だけ使用することができるように、パスワードがエンコード (コード化) される方法を変え続けることです。利用者がそのようなことができるなら、クラッカーは、好きなだけ何度も繰り返すことができます -- しかし、それらはまったく成功しないでしょう。しかしながら、クラッカーがパスワードが何か、または将来のエンコード (コード化) されたパスワードが何であるかを解明するためにエンコード (コード化) されたバージョンを使用できないような方法で利用者が間違いなくパスワードをエンコード (コード化) することは重要です。そうでなければ、エンコード (コード化) しないか、または固定のエンコード (コード化) にわたる改良をまだしている間に、利用者は、まだ、侵入されるかもしれません。

S/KEY アルゴリズム

これらすべての問題の解決策は、1981 年に Lamport によって発明されました。この技術は、Bellcore において Haller, Karn と Walden によって実装されました。彼らは、暗号化チェックサムと呼ばれるアルゴリズムを使用して "S/Key"と呼ばれるフリーソフトウェアパッケージを作成しました。暗号化チェックサムは、関数の結果が分かり、攻撃者が入力を都合良く決定することができないような強力な一方向の関数です。さらに、暗号化チェックサムは、巡回冗長検査 (サイクリックリダンダンシチェックサム (CRC)) と異なって、同じ出力をもたらす入力がほとんどないことです。

S/Key で、変化するものは、安全ハッシュをランスルー (練習、要約する) するパスワードの回数です。パスワードは、一度安全ハッシュでランスルーされ、次に、ハッシュの出力は、再び安全ハッシュでランスルーされます、その出力は、再び安全ハッシュでランスルーされ、そして、安全ハッシュでランスルーされるパスワードの回数が目的とするシーケンス番号と等しくなるまで繰り返されます。これは、たとえば、パスワードの前にシーケンス番号を置いていったん安全ハッシュをランスルーするより遅いのですが、それは、ある有意義な利益を利用者にもたらします。利用者が接続しようとしているサーバマシンは、その混乱の出力が正しいかどうか決定する何らかの手段がなければなりません。何らかのエンコード (コード化) なし、または通常のエンコード (コード化) で格納しているなら、クラッカーは、やはり利用者のパスワードを取得することがあり得ます。しかし、安全ハッシュで格納しているなら、シーケンス番号が変化するので、どのように毎回応答の変化を計算すればよいのでしょう? また、利用者がどんな方法でも盗聴できないマシンに決して到達できないと、どうなるでしょうか ? リンクを越えてパスワードを送信せずに、利用者は、どのようにしてパスワードを変更したらよいのでしょうか?

Lamport によって考案された巧妙な解決策は、S/Key システムで、シーケンス番号が常に 1 づつ減少し、単にシーケンス番号 N のどんな応答も安全ハッシュでランスルーすることによって、利用者は、シーケンス番号 N+1 の応答を得ることができますが、反対を行うことができないことを覚えておいてください。その時々で、システムが得た最後の有効な応答のシーケンス番号を N+1 とし、利用者が与える応答のシーケンス番号を N と見なします。 N の応答を生成するパスワードが N+1 の応答と同じであるなら、利用者は、N+1 回の合計のために、そして N+1 に戻るように同じ応答を得るように、もう 1 回、N の応答を安全ハッシュのランスルーができるべきです。いったん利用者が 2 つを比較し、それらが同じであることがわかったならば、利用者は、N から 1 を引いて、今、検証したばかりの N のキーは、キーを検証する必要がある次の回に使用するために常に保存できる N+1 の新しいキーになります。また、利用者のパスワードを変更する必要があるけれども、利用者のマシンにアクセスする安全な方法がないなら、利用者のパスワードを検証しなければならないことを実際に必要とするすべてのシステムは、利用者が始めたいシーケンス番号より 1 つ大きい有効な応答であることを意味します。

その上ちょうど、このすべてのどちら側も、実際に応答を生成して検証するとき、利用者のパスワードに関連するシード (種) を使用します。これは、万一の場合に、ほんの少し乱雑状態に役に立ちます。そうでなければ、多くの時間とディスク空間を手に入れられる人は、多くの頻繁なパスワードの応答をすべて生成して、システムを破ることもあり得ます。

これは、S/Key アルゴリズムがどう動作するか、または重要でないいくつかの詳細について決して最良の説明ではありません。そういう訳で、利用者は、この話題に関して現在発行されている論文のいくつかを参照するべきです。それは、単に中で何が行われているかについての間に合わせの紹介です。

OPIE の構成要素

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

また、OPIE システムに特有である OPIE 配布に 3 つのプログラムがあります: opiepasswd(1) は、ユーザがそれらの OPIE パスワードを設定し、変更でき、 opieinfo(1) は、ユーザが現在のシーケンス番号とシードが何であるか調べることができ、 opiekey(1) は、OPIE キー電卓です。

OPIE を他のプログラムに追加

OPIE 配布にクライアントとして含まれているプログラム以外のプログラムに OPIE 認証を加えることは、それほど難しくはありません。最初に、利用者は、プログラムのどこかに <stdio.h>をインクルードしていることを確かめる必要があります。次に、<stdio.h>のような他のインクルードの下で、変数宣言の前に、利用者は、<opie.h>をインクルードする必要があります。利用者は、タイプ "struct opie"の変数を利用者のプログラムに追加する必要があり、利用者は、ユーザからパスワードを得るために使用するバッファが OPIE_RESPONSE_MAX+1 文字を保持することができるくらい大きいことを確かめる必要があり、そして、利用者は、OPIE_RESPONSE_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 は、回線をのぞき見て利用者のパスワードを取得しようとしている人々に対して利用者を保護することができますが、利用者がパスワード自体を回線に決して送信しないようにしている場合のみです。重要なことは、利用者が実際に使用しているマシンのいずれかで、常に 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", 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", RFC-1321, DDN Network Information Center, April 1992. Rivest, R. "The MD4 Message Digest Algorithm", RFC-1320, DDN Network Information Center, April 1992.

作者

Bellcore の S/Key は、Bellcore の Phil Karn、Neil M. Haller と John S. Walden によって書かれました。 OPIE は、Randall Atkinson、Dan McDonald と Craig Metz よって NRL で作成されました。 S/Key は、Bell Communications Research (Bellcore) の商標です。 UNIX は、X/Open の商標です。

連絡

OPIE は、Bellcore の "S/Key ユーザ"メーリングリストで議論されています。参加するためには、次に電子メールの要求を送ってください: skey-users-request@thumper.bellcore.com