信頼できる経路(Section 6.11参照)と同列なものに、 ユーザが使おうとしているプログラムやシステムが、本当に動作しているのかを ユーザに対して保証することが挙げられます。
これまでよくあった例が「ログインしたように見せかける(fake login)」 プログラムです。 プログラムがシステムのログイン画面のような表示をすれば、表示しっぱなしに しておけます。 ユーザがログインしようとすると、ログインしたように見せかけるプログラムは ユーザのパスワードを横取りし、後で利用します。
この問題に対する解決策が、「高信頼パス」です。 高信頼パスは、ユーザにやりとりしたい相手とやりとりできる確かさを提供する シンプルな仕組みです。やりとりする情報が何であっても、攻撃者が横取りしたり、 変更したりできないことを保証します。
パスワードを要求する場合、高信頼パスを用意するように心がけてください。 残念ながら、そこらの Linux ディストリビューションや Unix には、通常のログイン 手続きにさえ、高信頼パスが用意されていません。 解決方法の 1 つに、ログインする前に改竄できないキーの押下を要求する という手があります。たとえば、Windows NT や 2000 のユーザは、ログイン する前に「control-alt-delete」キーを使います。一般的な Windows のプログラム なら、このキーの組み合わせを横取りできません。このやり方が高信頼パスです。 Linux にも セキュア・アテンション・キー (Secure Attention Key (SAK)) という同等な機能が存在しています。これによると、「control-alt-pause」キー の使用を推奨しています。 あいにくこのドキュメントを書いている時点では、SAK は完成しているとはいえず、 Lihux ディストリビューションでもサポートしているとは言えません。 ローカルで高信頼パスを解決するもう 1 つの方法として、ログイン・プログラムだけ が動作する独立したディスプレイを管理する手もあります。 たとえば、信頼できるプログラムだけがキーボードのライト(Num Lock や Caps Lock、 Scroll Lock を示す LED)を変更できるなら、ログイン・プログラムは動作パタンを 表示して、それが本当のログイン・プログラムであると示せます。 残念ながら現状 Linux の一般ユーザが LED を変更できますので、LED は高信頼パス を確認するのに利用できません。
情けないことに、ネットワーク・アプリケーションとなるとさらに問題が深刻に なります。 高信頼パスを設けるのは、ネットワーク・アプリケーションにとって意味があり ますが、完璧に実行するのはかなり困難です。 ネットワーク越しにパスワードを送る時、せめて信頼できる終端同士間でパスワード を暗号化してください。 こうすれば少なくとも、システムに接続していない攻撃者はパスワードを盗聴でき ません。また少なくとも攻撃がやりづらくなります。 実際にやり取りするための高信頼パスが心配なら、必ずやり取りが暗号化され、 認証済みであるようにしてください(最低限、認証は済ましておくように)。
結果として、ネットワーク・アプリケーションは高信頼パスが十分ではありません。 とりわけ Web ベースのアプリケーションではこれが顕著です。 よく知られた手法として、Web ブラウザのユーザをだまし、実際は別のところなのに、 ある場所にいると思わせる手があります。 たとえば、Felten[1997]では、「Web スプーフィング」を論じていてます。 ユーザがある Web サイトのページを見ていると信じていても、実はその Web サイトのすべてのページは、攻撃者のサイトを経由して見ているというものです (攻撃者は、すべてのトラフィックを監視して、双方向に送られているどんなデータ も変更できます)。 これは URL の書き換えによって実現しています。 URL の書き換えは、他の技術(Javascript のような)を使えば、ほとんど見えなく することが可能で、ステータス行やロケーション行その他に形跡をほとんど残し ません。 詳細はドキュメントを見てください。 他にも URL を隠す技術として、ほとんど使われていない URL の文法を悪用するもの があります。たとえば、 「http://www.ibm.com/stuff@mysite.com」という URL は、実際には 「www.ibm.com/stuff」というユーザ名で「mysite.com」(悪意あるサイトかも しれません)を見る要求を発行します。 URL が長ったらしければ本当のサイト名は表示されず、ユーザはどうしてやられたか もほとんど気付かないでしょう。 さらにもう一つの方法に、サイトを作成してその名前をわざと「本当の」サイト と同じような名前にしてしまう手があります。ユーザは区別がつかないかもしれ ません。 上記すべてのケースにおいて、単に行を暗号化しても何にもなりません。攻撃者は 何が表示されるかを完璧に制御できるので、暗号化されたデータでまったく問題が ありません。
これらの問題を対処するのはさらに困難です。 現状では、「だまされた」Web ユーザを防ぐのに有効な技術的解決方法はわかり ません。 Web ブラウザの開発者に対して、そのような「だまし」を簡単に見つけられること で対抗するように働きかけるつもりです。 ユーザが正しいサイトに間違いなく接続できることが重要ならば、単純な手続きで 脅威に対抗しなければいけません。 たとえば、ブラウザを落として再起動し、Web のアドレスがとても解りやすくかつ 正しく入力してあるかを必ず確認します(そうすれば入力間違いは起こりえません)。 また、「似たような」発音である DNS 名いくつかの所有権を獲得してしまったり、 その他の DNS 名や実体を探し出して、攻撃者を見つけてしまってもよいでしょう。