図1 共通鍵暗号
リモートコンピュータと通信し、それを操作するプロトコルとして、Telnet、rsh、rloginなどが挙げられる。これらのプロトコルでは認証を含めた全ての通信を暗号化せずに平文のまま送信している。90年代初頭までこれらのプロトコルはネットワーク上でそのまま利用されてきたが、インターネットが発達してきたことを受け、人々が従来に比べてより重要な情報をネットワーク上で扱うようになったことから、様々な脅威の可能性が出てきた。ネットワーク上を平文通信しているということは、常に他のユーザに通信を盗聴或いは改竄される危険性があるということだ。Secure Shell（以後SSH）はこれらの非暗号通信プロトコルの代わりに、安全に通信が可能なプロトコルとして注目された。
世界で最初のSSHプロトコルとその実装は当時フィンランドのヘルシンキ工科大学に在籍していた研究者であるTatu Ylo"nen氏が開発し、1995年にソースコード付きのフリーソフトウェアとして公開された。開発のきっかけは大学内のネットワークが盗聴の被害に遭ったことである。当初SSHは完全フリーのソフトウェアであったが、公開と同時に世界中で大きな反響を呼び、それを受けてYlo"nen氏は年内にSSHの保守運用、開発、商用などを目的にSSH Communications Security社を立ち上げた。また、1995年内にYlo"nen氏はSSHプロトコルをInternet Engineering Task Forceのインターネット標準案として文章化した。しかし、このプロトコルは既に実装されたソフトウェアの動作を記述したその場しのぎの性質が高く、また世界に公開されて広く利用されるにつれて多くの脆弱性や制限が発見された。中には致命的なものも含まれたため、SSH Communications Security社は翌1996年に以前までのSSHプロトコルと互換性のない、新しいアルゴリズムを持つバージョンを発表した。ここでは、プロトコルを大きく分けて古いバージョンをSSH-1、新しいバージョンをSSH-2と呼ぶ。1998年にはSSH Communications Security社はSSH-2プロトコルを実装した新製品を発表するが、市場の変化は小さかった。SSH-1とSSH-2は非互換であるため、既にSSH-1に慣れていたユーザにとっては出費をしてまで使うほどSSH-2の実装は魅力的なものではなかったのである。しかし、1999年末にOpenBSD（UMIXのOSの一種）プロジェクトのバージョン2.6にフリーのSSH-2プロトコル実装であるOpenSSHがリリースされたことで状況は一変し、SSH-2プロトコルの実装は世界に普及した。その後OpenSSHは多くのOSへと移植され、また他のSSH-2プロトコルの実装が数多く開発され、現在ではより安全かつ柔軟なSSH-2プロトコルがSSHの主流となり、ほぼ全てのプラットフォームにわたり実装が出回っている。SSH-2への移行によりセキュリティの向上は果たされ、残ったSSH-1プロトコルは攻撃の危険性のため非推奨とされた。絶滅寸前ではあるが一部では現存するとされる。このため、SSHは互換性のない二つのバージョンのプロトコルが共存し、設定次第ではSSH-1プロトコルの脆弱性を突いた攻撃を受ける可能性もあるので、しっかりとした認識を持つ必要がある。
では、なぜSSH-1は使用されなくなったのか。そのプロトコルが持つ問題には一体どういったものがあったのか。本研究ではSSH-1とSSH-2の差異に焦点を当て、SSHプロトコルの進化について調査した。２章では前段階としてSSHを考える上で知る必要がある予備知識を説明する。3章ではSSHプロトコルの概要について説明する。4章では実際にSSH-1の持つ問題に迫り、対してSSH-2ではどういった改良がなされたのか比較を行う。5章では調査の結果感じたSSHにおける問題点や課題をまとめた。
SSHは暗号技術の利用によって安全な通信を提供している。以下ではSSHにおいて利用されているアルゴリズムについて説明する。
メッセージの暗号化と復号に同一の鍵を用いる暗号方式。鍵が第三者に渡ると秘密であるべきデータが任意に暗号化、復号されてしまうので鍵の受け渡し・管理が重要な課題となる。
RC4や後述するセッション鍵などがこれに該当する。
平文をビット単位、またはバイト単位で逐次暗号化する暗号である。このアルゴリズムでは生成した乱数と平文の排他的論理和を求めそれを暗号文としている。鍵の長さが可変長であることと処理が早いことが特徴である。現在では解析されて非安全であるとされている。
メッセージの暗号化と復号に別々の鍵を用いる暗号方式。暗号化するための鍵を公開し、これを公開鍵とする。復号するための鍵を安全に保持し、これを秘密鍵とする。公開鍵で暗号化された暗号文は数学的特性により対応する秘密鍵でなければ復号はできない。ゆえに他の全てのユーザからは暗号文を送信できるが、その中身を知ることができるのは秘密鍵を持つユーザだけである。
RSA、DH鍵共有や後述するホスト鍵やユーザ鍵などがこれに該当する。
メッセージに電子的に署名を行うためのアルゴリズム。署名者は自らの持つ秘密鍵で署名を暗号化し、メッセージそのものは暗号化せずに署名と共に送信する。メッセージと署名を得た者は署名者の公開鍵を使って署名を復号し、本当に正しい署名者がそのメッセージを書いたのかどうかを検証できる。
RSAなどがこれに該当する。
1977年に発明され、発明者の3方の名前の頭文字を取って命名された。RSA暗号の強固さは二つの大きな素数の積の素因数問題の難しさに由来している。秘密鍵を用いずに復号するには大きな数の素因数分解を求められる。これは非常に困難な課題であり、実際に証明されたわけではないが現実的に不可能と考えられている。また、RSA暗号方式において公開鍵と秘密鍵の役割を入れ替えることができる。これによりデジタル署名のシステムとしても利用できるのが特徴である。
公開鍵暗号の概念は1976年にWhitfield DiffieとMartin Hellmanが考案したものである。DH鍵共有アルゴリズムはその具体案として発表された初の公開鍵システムで、共通鍵暗号方式において二者間で安全に鍵の受け渡しを行うためのアルゴリズムである。このアルゴリズムのセキュリティは離散対数問題の難しさに由来している。SSH-2ではこのアルゴリズムを利用して鍵の受け渡しを行っている。
ある一つのデータが与えられたときにそのデータを表す一定桁の数値を生成する関数。このとき生成した値をハッシュ値と呼ぶ。元のデータが変化するとそれにあわせてハッシュ値も変化していく。よってデータ送信時の誤り検出や改ざん検出などに使われる。衝突耐性という考え方があり、二つの異なるデータから等しいハッシュが容易に生成できない性質を持つ。あらゆる異なったデータからはすべて異なったハッシュ値を生成できるのが理想的であるが、現実的には困難である。
CRC-32、MD5、SHAなどがこれに該当する。
巡回冗長検査。データを特定の定数で割り、その剰余を検査用の数値として用いる誤り検出符号の一種である。CRC-32方式では33ビットの定数を用いて32ビットのCRCを求め、データの偶発的変化を検知するためのハッシュ関数である。CRCは暗号としての性質を持っていないので容易に同値のハッシュ値を計算できてしまう。
前身であるMD4を改良して作られた128ビットのハッシュ値を出力するハッシュ関数。SSH-2公開時ではまた利用できるアルゴリズムであったが現在では衝突耐性が突破され暗号としては非安全である。
MD4を元にして開発されたハッシュ関数でMD5よりも安全だと考えられている。SSHで使われるSHA-1は160ビットのハッシュ関数である。他に長いビット出力をする後継形式であるSHA-2が存在する。
SSHでは特定の状況下においてそのセキュリティが破られ、攻撃されることがある。以下では本論文が取り上げるSSHが受ける攻撃について説明する。
攻撃者が正規のホストになりすましてユーザに別のホストと通信させることで、ユーザから情報を得たり間違った情報を与えたりしまう。多くの場合クライアントからサーバホストの解決にはDNSを用いる。ところが使用しているDNSサーバの情報があらかじめ書き換えられていた場合、クライアントはサーバから返されたアドレスに接続してしまう。これをDNSPoisoningと呼ぶ。
クライアントとサーバ二者間の通信に際して、双方の認証が完了する前に第三者である攻撃者が割り込むことがある。攻撃者はクライアント側にはサーバのように振る舞い、サーバ側にはクライアントのように振る舞う。認証完了後、たとえ通信が暗号化などによって保護されているように見えても、攻撃者にはそれら全てを盗聴、改ざんすることができてしまう。
暗号化されたパケットは解読することが難しい。ここで、パケット通信を監視している状態で何らかの手段を用いてそのとき実行されたコマンドと流れたパケットを関連付けできたとする。そのパケットを抜き出して挿入することで攻撃者は不正にコマンドを実行できてしまう。攻撃者は暗号を解読したわけではないが、挿入したパケット自体は正しいために攻撃は成立してしまう。
パスワード認証に際して考えうるあらゆるパターンを試行しセキュリティを突破する攻撃。人では実行不可能と思われる量の計算をコンピュータに任せる。認証における時間制限や失敗によるアカウント凍結がない場合は確実にパスワードを解析できてしまう。
SSHはネットワーク上において他のコンピュータにログインし、リモートマシンでコマンドを実行してファイルを転送するためのプロトコル及び実装である。SSHは安全でないネットワークにおいて強力な認証システムと安全な通信を提供するもので、その主な機能として以下の5点が挙げられる。
通信に際してネットワーク上を流れるパケットが誰にも盗聴されないことを保証することである。通常のコンピュータネットワークとして広く利用されるTCP/IPの通信は全て暗号化されていない平文状態である。よってその使用を前提としたHTTP、FTP、SMTPなども全て平文通信であり、盗聴に対する防御がなされていない。SSHでは多くの暗号化アルゴリズムをサポートし、SSHセッション開始前のネゴシエーションで使用を自分で決めることが可能である。
完全性とは通信に際して一方から送られたパケットがもう一方に届くまで全く変化していないことを意味する。これは伝送路におけるパケットの欠損のみならず、第三者によりパケットの改変までを含めて検査するものである。これは安全性を保証する上で重要な機能である。パケットが正しい順序で重複が生じないことを保証できるならば、リプレイ攻撃は通用しない。SSHではハッシュ関数を用いた完全性のチェックを行っている。
通信相手を確認するためのプロセス。二者間通信の際どちらか一方に偽者がいた場合でもセキュリティは崩れてしまう。ゆえにSSHではセッションを持つクライアントとサーバの双方に対して認証を行う。SSHでは公開鍵暗号を利用した鍵認証システムが一般的だが、パスワード認証やSolarisで用いられるPAM（後述）のシステムやその他のものもサポートしている。また、非推奨だが「.rhosts」というサーバが管理するファイル内に保存されたユーザを無条件に信頼するホストベース認証も可能である。
認証完了後、特定のユーザに対して特定の権限を与えることができる。
TCP/IP をベースにした非安全なアプリケーションをSSHセッション上にカプセル化し安全に利用することができる。これによりVPNを構成することが出来る。また、SSHの安全性に対する信頼から、ファイアウォールの通過を許可することがある。通常では外部からの接続を拒否するようなアプリケーションでもこうしてSSHを利用してフォワーディングすることでファイアウォールを越えて使用できる。
SSHはサーバ・クライアントモデルで動作する。クライアント側から接続が試行され、サーバがそれを受け入れた時点でプロトコルが開始される。SSHは以下の手順で接続を確立していく。
SSHでは4種類の鍵が存在し、サーバの公開鍵ペアをホスト鍵、クライアントの公開鍵ペアをユーザ鍵、SSHセッションの暗号化に使われる共通鍵をセッション鍵、セッション鍵の交換に利用される公開鍵をサーバ鍵と呼ぶ。
以上比較してみると、セッション確立までの手順に差があることが分かる。特にSSH-1側ではパラメータネゴシエーションやホスト認証に注目するとその工程の少なさに気づく。SSH-1ではSSH-2に比べてサポートしている項目が少ないため、それがSSH-1の弱さの一因にもなっている。以下には具体的に両プロトコルの差異とSSH-1の弱さについて検討していく。
完全性が保障されている状態であれば、通信の際にリプレイ攻撃は成立しない。攻撃者が何らかの方法で暗号化されたパスワード部のパケットを入手したとしても、サーバ側ではそれが重複したものであることを見抜いてしまうからである。
しかし、SSH-1において完全性チェックに使われているアルゴリズムはCRC-32である。CRCはパケット転送時の誤り検出に使われるハッシュ関数である。用途がそもそも違うため、暗号としての衝突耐性は持っていなく、同値のハッシュは容易に求めることができる。第三者が送信されたパケットを途中で確保し、これを改ざんして再度送信したとする。そのときにパケットに対するCRCを元の値に修正しておけば、受信者は途中でパケットが変更されたことにまったく気づかない。この事から、SSH-1において完全性は保たれない。
ゆえにSSH-1に対してリプレイ攻撃は有効である。SSH-1ではセッションの暗号化を行うセッション鍵共有のためにサーバ鍵という暗号鍵を利用している。サーバ鍵はサーバ側で生成され、セッション鍵の交換にのみ利用される公開鍵暗号の鍵である。サーバ鍵は定期的に更新され、デフォルトの設定においては1時間とされている。サーバ鍵が更新されると、セッション鍵も共に新しいものへと換えられる。パスワード認証ではサーバがパスワードを要求し、クライアントが入力を行い、サーバがその入力に対して比較を行うシンプルなものである。この間の通信はセッション鍵によって暗号化されている。SSHのパスワード認証ではプロトコルバージョンに関係なくこの方式を取っている。通常、サーバ鍵が更新されない1時間の間に関してはセッション鍵も不変であり、それによって暗号化されたパスワード部のパケットも不変である。よってこの間に関してはリプレイ攻撃が成功してしまう。
また、SSH-1のパスワード認証においてリプレイ攻撃を利用してパスワードをクラックされる危険性も存在する。この攻撃は特定の状況下でSSHが持つオプションの持つ弱点によって実行されうる。前提条件として、
の2点が求められる。
SSHにはNULLパスワードを無効にするオプションが備えられている。これは本来セキュリティの改善のためにあるオプションであるが、逆にこの機能を利用してパスワードを解析される可能性もある。なぜならば、このオプションが有効となっている間、NULLパスワードを受けると、サーバは丁寧にも「このパスワードはNULLであり無効です」と反応を返してしまうからである。
攻撃者はまずサーバとクライアント間の通信パケットを確保し、リプレイ攻撃が成功するように暗号化されたパスワードが送信されるまでの部分を入手する。そして、RC4暗号の特徴を利用してそのパケットを修正する。RC4のアルゴリズムは乱数と平文の排他的論理和と取ることで暗号文を生成するというものである。ここで、攻撃者はパスワードを推測する。推測された文字はバイトに変換される。推測された文字バイトとパスワードパケットのバイトを排他的論理演算にかけた場合、もし推測が正しかったならば、修正されたパスワードパケットを復号するとそのバイトはNULLになる。推測が間違っていたならばパケットの復号後別の文字になる。このときサーバがNULLパスワードオプションを有効にしているのであればその反応で攻撃者は推測の正否を知ることができる。
圧縮プログラムと圧縮対象文書を渡されれたXSLTプロセッサは、圧縮対象となるXHTML文書の検索を先頭から行い、XSLTスタイルシートに記述されたマッチング条件式と照らし合わせる。マッチングする要素が検索された場合、XSLTスタイルシートのテンプレートによる処理が行われる。
SSHパスワードパケット（SSH_CMSG_AUTH_PASSWORD）は以下のように構成されている。
表1 SSHパスワードパケットの構成
| 格納データ（降順） | バイト長 | 暗号化状態 |
|---|---|---|
| Packet length | 4 | 非暗号化 |
| Padding | 不定 | 暗号化 |
| Packet Type | 1 | 暗号化 |
| String Length | 4 | 暗号化 |
| String Value | String length 分 | 暗号化 |
| CRC checksum | 4 | 暗号化 |
1バイト目を解析した攻撃者はそのバイトを削除してパスワードパケットを1バイト分減らす。そうすると格納データは1バイト分だけ表の上側にずれ込む。こうしてこの作業を繰り返すことでパスワードパケットを全て解析できてしまう。
SSH-2ではCRC-32の利用を一切廃止し、ハッシュ関数だけでの利用を避け、代わりにMessage Authentication Code（MAC）と呼ばれるメッセージダイジェストを利用して完全性のチェックを行っている。MACでは秘密鍵とハッシュ関数を組み合わせて使用し、メッセージに対して鍵を持たない者では再現できない一方向の出力を行う。代表的なMAC生成法としてKeyed-Hashing for MAC（HMAC）と呼ばれるものがあり、使用するハッシュ関数を任意に指定できる。SSH-2ではMD5やSHA-1を利用したHMAC-MD5、HMAC-SHA1が用いられている。このうちでも最低限HMAC-SHA1のサポートは必須とされている。
SSH-1はユーザの公開鍵認証にチャレンジ－レスポンス方式を採用している。サーバ側はチャレンジと呼ばれる乱数を生成しクライアントに送る。クライアント側はチャレンジに演算処理を加えてレスポンスと呼ばれるデータを計算し、サーバに送る。この間サーバは自らもレスポンスを計算し保持する。最後にサーバはクライアントから送られたレスポンスを自身が持つレスポンスの値と比較する。値が一致したならば認証は成功する。
チャレンジはサーバが独自に生成した乱数であり、サーバ自身以外にはクライアントしか知りえない値であること。また、レスポンスはチャレンジがなければ計算できないことがこの認証方式のポイントとなっている。 以下この方式についてもっと詳しく見ていく。
SSH-1プロトコルの公開鍵認証においてサーバとクライアントはセッションIDと呼ばれるセッションを識別する値を計算する。セッションIDは交換済みのサーバのホスト鍵とクッキーと呼ばれる64ビット乱数のハッシュ値として計算される。 サーバとクライアントの利用する公開鍵はRSA暗号に限定される。 このとき、認証は2点の仮定を元に進められる。
まずクライアントは自身の持つユーザ鍵をサーバに送信し、この鍵が使用できるかどうか問い合わせを行う。ユーザ鍵はあらかじめ登録しておく必要がある。サーバから使用可能であるとの返事が返ってきたら、認証は進められる。次にサーバは256ビットの乱数であるチャレンジを生成する。チャレンジはクライアントの公開するユーザ鍵と前段階で既に共有しているセッション鍵で暗号化してクライアントに送信する。クライアントは自身の秘密鍵とセッション鍵でチャレンジを復号する。そしてチャレンジとセッションIDを足した値をMD5によって計算しこのハッシュ値をレスポンスとする。最後にサーバのホスト鍵とセッション鍵を用いてレスポンスをサーバへ返し、サーバはそれを復号した後自身の持つレスポンスと比較する。MD5を利用することは万が一のときレスポンスが第三者に漏れてしまった場合認証を不正に通り抜けて中間者攻撃を防ぐためである。
しかしこの認証はその前提が崩れてしまったために安全性が損なわれてしまう。セッションIDを導出するハッシュの計算式に弱点が発見されたため、セッションIDの複製が可能になった。ゆえに異なるホスト鍵を用いている状態で同一と認識されるセッションを並列確立することができてしまう。この弱点を利用することで、攻撃者は中間者攻撃の足がかりを得ることになる。チャレンジ－レスポンス方式は乱数の利用により毎回異なるデータのやりとりで認証を進めることでリプレイ攻撃を防ぐことが可能である。しかしこの方法ではチャレンジとレスポンスが最終的に相手側へ届けられていることしか確認ができず、仲介者が途中でその受け渡しをしていたとしても察知ができないのである。
仲介者の存在を防ぐため、クライアントとサーバは必ず双方が共に正しい相手と直接セッションを持っていることを確認しなくてはならない。SSHでは本来ならばセッションIDが現在のセッションは唯一のものであることを表すべきであったのだが、上記の通りSSH-1のプロトコルにおいてこれは複製が可能である。SSH-2では通信先が確実に正しい相手であることを確認するためにデジタル署名を利用する。
クライアントは事前に自らの公開するユーザ鍵をサーバに登録し、認証の際には自分のユーザ鍵をサーバへ送信し認証許可の問い合わせを行う。サーバから許可が下りたら、クライアントは交換済みの交換ハッシュからセッションIDを作成し、自身の秘密鍵でこれらにデジタル署名を施した上で、セッション鍵を使って全てのデータと署名を暗号化してサーバへ送る。暗号文を受け取ったサーバはセッション鍵でそれを復号し、続いてクライアントのユーザ鍵で署名を検証する。
UNIXシステムに古くから利用されている分散ファイルシステムにNetwork File System（NFS）というプロトコルがある。これはローカルにあるリモートコンピュータのストレージを共有して利用するものである。Windowsのシステムの同様の機能を持つServer Message Block（SMB）というプロトコルがある。NFSはrshと同時期に使用された古いプロトコルであり、rshと似たような仕組みを利用する場合が多いことから、残念ながらセキュリティに関しては強くない。それはリストファイルに保存されたIPアドレスだけからクライアントを信頼する極めて非安全なものである。SSH-1が公開された当初ではこの非安全なプロトコルに完全に対処しきれていなかった。
NFSとrshを共用していた時代ではSSHが持つ鍵認証の機能はなく、ただ信頼することを表すクライアントのリストとパスワードによる認証がメインであった。しかし、NFSとSSHの共用を考えたとき、NFSのアクセス権限から鍵認証の方法が問題となってくる。鍵認証は当然ながら該当するユーザアカウントのホームディレクトリ以下に存在する鍵ファイルにアクセスする必要がある。SSHのプログラムが作動するマシンと鍵ファイルの保存されているマシンが同一であるのならば、SSHはNFSが取得したroot権限を以って鍵ファイルにアクセスすることが可能である。ではSSHの作動するマシンと鍵ファイルの保存されているマシンがNFSを経由して接続されている別のマシンであったケースの場合はどうだろうか。NFSは一般的にあるマシンのroot権限が他のリモートマシンにまで拡張されることがないよう設定されているのである。つまりこのときSSHはリモートマシン上に保存されている鍵ファイルにアクセスすることができないのだ。ゆえに、SSHはローカルホストへ接続するときホスト鍵認証を無効にせざるを得ない。このケースにおいてSSHは接続先のサーバを無条件で受け入れることになる。現在ではNFSとSSHはともに新しいバージョンの登場によりこの処理はスムーズに行うことができるようになり、問題は解消されている。
結果的にクライアントは盲目的にDNSを信頼してサーバへ接続するしかない。このとき、DNSサーバがすでにPoisoningされている状態であれば、クライアントがローカルホストを解決したときに別のホストへリダイレクトされてしまい、なおかつそのことを検出することもできない。このことを防ぐため、SSH-1ではローカルホストを「localhost」で解決せず、「127.0.0.1」と入力する必要があった。
SSHのサポートしているオプションに「キーボードを用いた対話的な認証」というものがある。これは認証においてサーバとクライアントの対話を必要とするような認証技術を実装するための拡張機能である。代表例として一番分かりやすいのはパスワード認証である。サーバ側のパスワード要求に対してそれを入力して認証する手順は、対話的でキーボードを用いている。この他にもSolarisで使用されるPluggable Authentication Modules（PAM、交換可能な認証モジュール）のサポートに利用される。通常、認証とシステムは密接に結びついたものであり、認証方式を別のものへ変えようとするとシステムのプログラムを全て書き換える必要がある。しかし、PAMの導入によって認証部だけを自由に取り替えることが可能となる。PAMは様々な認証システムをサポートし、その中には当然ながらキーボードを用いた対話的な認証も含まれる。そのためPAMの利用にはこのオプションを有効にしなければならない。
キーボードを用いた対話的な認証では、その特性上通信に一定のパターンが見受けられる。対話的という名の通り、どうしても要求に対する反応という図式になってしまう。では、ここでキーボードを用いた対話的な認証の中でも一番基本的なパスワード認証について考える。ユーザがSSHを利用してリモートUNIXシステムでSUコマンドを入力しroot権限を入手したい場合、
以上の通信がやりとりされる。①において“sshuser@uname %”は文字のグループとして送信され、②の“su”の入力は二つのデータパケットとして送信される。一つは入力におけるキーストローク。もう一つはsuと画面に結果を返すエコーである。続いて④では入力されたルートパスワードはキーストロークのみの単一パケットとなる。ここにおいてエコーは存在しないため画面にも入力されたパスワードの表示はない。⑤では認証が通りroot権限の取得が出来たことを表し、“root@uname #”はやはり文字グループとして送信される。この通信はSUコマンド入力の度に行われるものである。
ここで、攻撃者はネットワークを随時監視しているとする。すると得られた膨大な観測量により、送信されたパケットが送信先へ届くまでの遅延とキーストロークの関連を経験に基づき推測することが可能である。総当り攻撃によってパスワード認証が破られることは既に周知のことであるが、上記の学習をあらかじめ行うことで効率の良い総当り攻撃を仕掛けることが可能となる。これはパスワード認証ではキーストロークとそれに伴いパケットが送信されるタイミングが一定であるからである。ここに暗号の欠陥などは存在せず、この手法が成立するのはネットワークトラフィック統計解析の結果である。
これを防ぐ認証の方法として、ワンタイムパスワード認証が挙げられる。これもキーボードを用いた対話的な認証であるが、毎回の認証ごとに異なるパスワードを使用するのが特徴である。この方式ではユーザはあらかじめローカルにパスワードを計算するためのプログラムを保持する。サーバに接続すると、ユーザはキーを提示される。そして自分が持つ秘密のパスフレーズと与えられたキーでパスワードを生成する。パスワードはログインごとか時間ごとに変化する。また、パスワード計算のために入力を受けてからパケット送信されるまでのタイミングもまちまちである。トラフィックを解析されたとしてもその結果によって総当り攻撃が容易になることはない。
トレードオフとは同時には成立しない排反事象の関係を言う。セキュリティの世界ではシステムの設計段階でトレードオフが重要となってくる。セキュリティをそのときの段階で究極的に堅くすることは可能であろう。例えばある人の声紋、指紋、網膜パターン、遺伝子を全て調べた上での認証ならば偽者が割り込む余地はない。しかしそこまでしてしまうと利便性は損なわれる。逆に誰もが手軽に利用できるシステムになるとどうしてもセキュリティのレベルは下げざるを得ない。前述したワンタイムパスワードは良い例である。確かに通常のパスワード認証よりはセキュリティの向上が見込めるのだが、その反面求められる作業は非常に手間がかかるのである。セキュリティの譲歩はその時々の状況にあわせて変化しなくてはならない。
SSHでは完全なセキュリティを提供しているわけではなく、むしろそれはユーザに委ねられている部分が大きい。SSH-2においてサーバとクライアント双方の認証にデジタル署名が使われるようになり、中間者の割り込みやホストのなりすましの可能性は少なくなったように見える。しかしここで前提として、あらかじめ両者の鍵を安全にお互いに送信し、登録することが求められる。この手法に関してSSHプロトコルでは言及していない。完全に実装、またはユーザに依存する形となっている。その手法次第ではやはりなりすましや中間者攻撃を受ける可能性が出てくるのだ。よってSSHにおける最大の問題点は通信するホストの認証にあると言える。
これに対する一つの答えとしてPublic Key Infrastructure（PKI：公開鍵基盤）の利用が挙げられる。デジタル署名を用いて送信元を検証すると言っても、結局はその署名に使用される公開鍵ペアを持つ者を信用することを前提として始まる。その者が顔なじみで長い付き合いがあれば信頼に足ることはわかるだろうが、ネットワーク越しの通信ではそれがわかるはずもなく、多くの場合それは叶わない。そこで、絶対信頼のおける第三者をあえて中間に挟むことで問題を解決するのがPKIのシステムである。PKIではあらかじめ信頼できる認証局を設定する。デジタル署名の利用者Aはまず自分の公開鍵を認証局に登録し、公開鍵証明書を発行してもらう。そして自分の秘密鍵で署名を行いBに送信する。Bは認証局から公開鍵証明書を受け取り、それに収められた公開鍵を使って署名の検証を行う。このモデルでは認証局が信頼できる限り、受け取った署名は正しいこととなり、正しく相手と通信していることが確認できる。現在の採用例ではHTTPプロトコルのセキュア化をメインとして利用されているSecure Socket Layer（SSL）が挙げられる。SSHにおいてもPKIの利用は可能である。SSH Communications Security社がSSH-2を実装した「Tectia」という商用製品ではPKIのサポートがなされているが、現在最も普及しているOpenSSHではサポートされていないため、SSH全体で考えた場合PKIの利用は一般的ではないと言える。
このため、SSHの大規模環境での利用は依然として問題が残る。SSHで提供されているセキュリティに対して、それを使うのが人間であるという点にSSHの落とし穴は存在するのである。しかし、それを欠点として考えるのではなく、SSHの導入の容易さと柔軟性の高さを生かした使い方をするのが理想的だ。それには利用者の意識が必要不可欠である。
本研究では既に利用されなくなったプロトコルであるSSH-１について調査し、危険を孕んだものであるかをまとめた。SSH-2の機能から、SSH-1を利用するメリットは全くないと言える。しかし、SSH-2の採用に伴いセキュリティは上昇したが、ユーザの設定次第ではまだまだ十分に突破される可能性があることに留意したい。例としてパスワード認証を採用する限りは総当り攻撃が成功しうる可能性が常に存在することが挙げられる。また、ここで取り上げたのはあくまでプロトコル段階の欠陥である。実際のセキュリティを考える上ではプロトコルよりも実装が問題となる。これに関しては日夜新しいセキュリティホールが発見されては埋められていき、また発見されるという果てのない戦いである。技術の進歩に伴いMD5の衝突耐性が10年の間に突破されて非推奨となったのは良い例である。
今後の課題としてはポートフォワーディングなどの機能も積極的に利用しSSHの有用性について更なる理解を深めていきたい。また認証においてサポートされている公開鍵認証以外の方式も実際に設定してテストすることで学ぶことが多いと考えられる。今回の研究を経て自分のセキュリティに関する認識が如何に甘いかということを実感させられ、同時に考えられないほど用心深くなったことに驚く。今回は既存の問題点をまとめる形となったが、今後は自分で新しい脆弱性を発見し、セキュリティに貢献できるようになることが目標である。