manページ  — OPIE

これら総ての問題に対する解決策は、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 認証を組み込むことはさして困難なことではありません。 まず第 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 計算機を動作させるマシンは、常にユーザが 現実に手元で使用しているマシンでなければならないということで &#151; 決してネットワークやダイアルアップ回線の向こう側のマシンであってはいけません。

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

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

skey-users-request@thumper.bellcore.com