tail head cat sleep
QR code linking to this page

manページ  — OPIE

名称

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 はこれが弱点でした。 クラッカーには本当のパスワードが何であるかは分かりませんでした。 しかし、クラッカーは知る必要もなかったのです — 何故なら、ユーザのアカウントに侵入する為には、 暗号化されたパスワードを捕捉しサーバに要求されたときに そのパスワードを返信しさえすればよかったからです。

ワンタイムパスワード

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

S/KEY アルゴリズム

これら総ての問題に対する解決策は、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 の構成要素

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

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

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 は保護可能です。しかし、これは実は限られた場合であって、 ユーザが必ずパスワードそのものを通信回線に送信しない様に 行動する時だけです。 肝腎なことは、OPIE 計算機を動作させるマシンは、常にユーザが 現実に手元で使用しているマシンでなければならないということで &#151; 決してネットワークやダイアルアップ回線の向こう側のマシンであってはいけません。

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


January 10, 1995 OPIE (4)

tail head cat sleep
QR code linking to this page


このマニュアルページサービスについてのご意見は Ben Bullock にお知らせください。 Privacy policy.

This philosophy, in the hands of amateurs, leads to inexplicably mind-numbing botches like the existence of two programs, “head” and “tail,” which print the first part or the last part of a file, depending. Even though their operations are duals of one another, “head” and “tail” are different programs, written by different authors, and take different options!
— The Unix Haters' handbook