技術の面からいえば、インターネットで のセキュリティ(暗号技術)の方が、日常生活のそれ よりも安全である。なぜなら、前者には 数学的な根拠があるからだ。インターネッ ト全体を見渡すと、脆弱なのはセキュリ ティ技術ではなく、むしろユーザである。
この記事では、インターネットでのセキュ リティ技術を説明するとともに、その安 全性の根拠について解説していく。
この記事では、焦点を「通信の保護」と 「データの保護」に絞る。
「通信の保護」とは、ネットワーク上を 流れるデータの保護である。ネットワー ク上での盗聴を防止し、改竄を検知する ことだ。宛先に届けられた後のことは、 守備範囲ではない。例としては、IPsec、 SSH、SSL が挙げられる。
「データの保護」とは、ネットワーク上 のデータに加えて、コンピュータシステ ム上のデータも保護することである。デー タの保護の代表例は、暗号メールだ。受 けとった電子メールが、受信者だけが読 める(他人が読めない)形でファイルに保 存されることまで範中に入る。
後ほど説明するように、両者はほぼ同じ 機能を提供する。ただ決定的に違うのは、 秘密(暗号の鍵)の管理に関する安全性ま で考慮しているか否かだ。
前者は、秘密が生のままファイルに保存 されていも気にしない(というか、それ は守備範囲外)。たとえば、SSH デーモ ンの秘密鍵(後述)は生のままファイルに 保存されており、ルートだけが読めると いう線で妥協している。
後者は、秘密もデータであるから、秘密 を保護する仕組みを提供する必要がある。 たとえば暗号メールでは、秘密鍵を暗号 化してファイルに格納することが多い。
「データの保護」と「通信の保護」とに は、優劣はつけられない。そもそも、 「万全なセキュリティ技術などない」の だ。たとえば、SSH があるからといって、 暗号メールが不要になる訳ではない。
重要なのは、「用途に応じて最適なセキュ リティを選択し、正しく運用すること」 である。
「機密性」とは、適切な人だけが内容を 理解できることである。逆にいえば、内 容が他の誰かに盗聴されないよう保護す る機能である。たとえば、Alice と Bob が通信するときは、その内容が第 3 者 にバレないようにする仕組みだ。これは 「暗号」を用いて実現できる。
「完全性」とは、ある人が作成したデー タが、そのままの形で相手に届けられる ことである。誰かがそのデータを改竄し たら、それを検知できる機能だともいえ る。この実現には、後述の 「電子署名」 や「MAC(Message Authentication Code)」 を使う。
「認証」とは、ある名前を名乗る人が本 当にその人だと確認することである。こ れも、電子署名や MAC で実現できる。
MAC は 2 人が共有している秘密を確認 することで認証する。合い言葉を知って いる人は仲間だということ。
これに対し電子署名では、その人のみが 知っている秘密を確認することで認証す る。その人しか知らない秘密を、他人が どうやって確認するのか疑問に思うだろ う。この疑問を解くには、後述の「公開 鍵暗号」を学ぶ必要がある。
「否認防止」とは、後から内容を否定で きないことである。たとえば、本の発注 を受けたのに、受注元から「そんな注文 はしていない」といわれると商売あがっ たりだ。否認防止については忘れがちだ が、これがないと電子商取引が成り立た ないほと重要な機能だ。
否認防止は、電子署名で実現できる。 「完全性」と「認証」、つまり「その人 が書いたまま」で「確かにその人が書い た」のなら、内容を否定しようがない。 完全性と認証に出てきた MAC でも、否 認防止が実現できそうだが、実は無理だ。 その理由は後で説明する。
電子メールの機密性は暗号で守る。実用 的な暗号を使って暗号化した暗号文は、 それを解読するまでに宇宙の歴史よりも 長い時間が必要となる。封筒を破ること で、内容が漏洩する郵便の安全性と比較 するまでもない。
完全性についてはどうだろう。電子メー ルでは、1 ビットの変更も検知できる強 力な仕組みが利用できる。一方、郵便だ と「封を切られていない」「筆跡が同じ」 など、なんら確信を持てない根拠に納得 する他ない。
認証について考えてみよう。ある名前を 名乗ると、社会的な制約が生まれる。日 常生活では、戸籍や住民票の登録などい ろいろな制約に縛られている。
たとえば、クレジットカードを発行して もらうとき、クレジットカード会社はな にを認証しているのだろう？突き詰めて いくと、その名前を名乗る人が住むと主 張する住所で、その人がクレジットカー ドを受けとれるかを確認しているだけだ と分かる。
しかし郵便屋さんが、本当に受取人が正 しいのか確かめたりはしない。せいぜい 受領確認の印をもらうくらいだ。
電子メールでの認証に、話を戻そう。あ る電子メールアドレスを使い出すと、そ のアドレス宛のメールを受信できるころ にいるという制約が発生する。ここまで は、郵便と同じだ。
電子メールの場合は、さらに秘密を確認 することで認証する。ここが郵便とは決 定的に異なる。
最後に否認防止について、考察してみよ う。電子メールでは、否認防止を実現で きる。
しかし、郵便ではできない。完全性も認 証も、いい加減だからだ。(このため、 正式な契約を結ぶ際には、第3者を立ち 会わせたりする。)
オープンな環境であるインターネットで は、トラフィック解析を防止することは 難しい。
「いやがらせ」とは、文字通り相手を困 らせることである。スパムメールが典型 例だろう。スパムメールをできるだけ受 けとらないよう、対策を講じることは可 能だが、完全な解決策は存在しない。
暗号のモデルを図1に示す。「暗号鍵」 を使って「平文(ひらぶん)」を「暗号文」 に変換することを「暗号化」という。逆 に「復号鍵」を使って暗号を平文に戻す ことを「復号化」という。復号鍵を知っ ていれば、暗号文を簡単に平文に戻せる が、知らなければとても難しい作業にな る。
共有鍵暗号は、古来から使われてきた。 その典型例であるシーザ暗号の名が、そ れを雄弁に物語っている。
シーザ暗号は、アルファベットを 3 つ 後にずらすことで暗号化する。復号化の ときは、3 つ前に戻す。
シーザ暗号の最大の欠点は、暗号方式が 洩れれば、誰でも暗号を解読できる点で ある。暗号方式を秘密にしていることを 根拠に強度をうたっている暗号はビジネ スでは使えない。ビジネスでは、暗号方 式を不特定多数の顧客に公開することが 大前提だからだ。
シーザ暗号を一般化して、任意の数ずら すようにしても、鍵のパターンは 26 通 りしかなく、強くなったとはいえない。 暗号では、全パターン検索が不可能なほ どほど十分に長い鍵を利用できるように する必要がある。
暗号の歴史にとって、1970 年代後半は 大きな節目といえる。1977 年、暗号方 式を公開した共有鍵暗号 DES(Data Encryption Standard) が発表されたか らだ。それまでの暗号を近代暗号、それ 以降の暗号を現在暗号と呼んで区別する 人もいる。
以来、DES はビジネスで利用されるとと もに、暗号学者の共通の問題となり、彼 らの議論を通じて暗号学に多大な進歩が もたらされた。
DES は 64 ビットの平文を 56 ビットの 鍵で暗号化し、64 ビットの暗号文を出 力する。平文が 64 ビットより大きいな ら、64 ビットごとに区切って暗号化す る。残念ながら、56 ビットの鍵長は短 か過ぎるといわざるを得ない。また、暗 号方式自体にもさまざまな欠点が見つかっ た。
アメリカ政府は今年、DES に代わる共有 鍵暗号を採択しようとしている。最終候 補に残った Rijndael は、128 ビットの 平文を 128、192、256 ビットのいずれ かの長さの鍵で暗号化する。鍵長の数字 にどんな意味があるのかは後述する。
共有鍵暗号は、1人のユーザがファイル を保護する場合にはとても便利だ。鍵を ユーザが頭の中だけにとどめておけば、 他人にばれることはない。(分かりやす くするために、これ以降、共有鍵暗号の 鍵をパスワードと呼ぶ。)
しかし、離れた 2 人が、共有鍵暗号を 使って通信を暗号化しようとすると、途 端に話は難しくなる。パスワードをどう やって、共有すればよいのだろう？
暗号を使い始める前に、パスワードを共 有しなければならない。パスワードを相 手に伝えるには、安全な通信路が必要に なる。しかし、そもそも通信路が危険だ から暗号化したい訳だ。
「離れた 2 人が危険な通信路を使って 秘密を共有できるか」という問題は、 1970 年代の暗号学者の頭を悩まし続け てきた。
1978 年、最初の公開鍵暗号が発表され た。開発者の名をとって RSA (Rivest Shamir Adleman)と呼ばれる。
DES と RSA 以降、暗号は新しい時代に 入った。これまで政府や軍隊に独占され 機密にされてきた暗号が、市民の手に移っ たこともそれを象徴している。
公開鍵暗号では、1 組の鍵を生成する。 一方を公開し、他方を機密に保持する。 このため、それぞれを「公開鍵」および 「秘密鍵」と呼ぶ。
公開鍵暗号は、「鍵」と「錠前」の関係 を思い出すと理解しやすい。暗号化のと きは錠前を掛け、復号化の際は対応する 鍵で外す訳だ。
RSA では、「公開鍵で暗号化し秘密鍵で 復号化する」こともできるし、「秘密鍵 で暗号化し公開鍵で復号化する」ことも できる。
あるユーザが、公開鍵と秘密鍵を生成す ると、それらは他の誰のものとも一致し ない。理由は後述する。また、公開鍵か ら秘密鍵を推測することは困難であると いう性質もある。
将来、暗号の歴史を振り返るとき、2000 年は第 2 の節目となるかもしれない。 Rijndael の採択に加えて、RSA の特許 が切れ、誰もが暗号を気がねなく利用で きる環境が整ったからである。
Alice と Bob が通信することを考えよ う(図2)。まず、Alice は自分の公開鍵 を、危険な通信路を使って Bob に渡す。
Bob が Alice だけに内容が読める暗号 文を作成するには、Alice の公開鍵を使っ て内容を暗号化すればよい。これを復号 化できるのは Alice の秘密鍵のみであ り、それは Alice だけが持っている。
この方法で、理論上はうまくいく。ただ 実際に使ってみると、以下のような問題 が浮上する。
まず、「乱数」からパスワードを生成す る。そして、このパスワードを使い、内 容を共有鍵暗号で暗号化する。内容が大 きくても、共有鍵暗号は速いので問題な い。
次に、パスワードを相手の公開鍵で暗号 化する。共有鍵暗号の鍵長が高々 256 ビット程度であることを思い出してほし い。入力が少ない場合は、公開鍵暗号を 使っても実用的な時間内で暗号化が終了 する。
相手が複数いるなら、パスワードをコピー し、それぞれの受信者の公開鍵で暗号化 する。
そして、共有鍵暗号で暗号化された内容 と、公開鍵暗号で暗号化されたパスワー ドを相手に送る。受信者は、まったく逆 の手順で復号化できる。
再び Alice と Bob を登場させ、Alice が電子署名を作成する場合を考えよう (図4)。
Alice はまず内容のコピーをとり、その コピーを Alice の秘密鍵で暗号化する。 これが電子署名である。そして、Alice はオリジナルの内容と電子署名を Bob に送る。
Bob が電子署名を検証するには、最初に Alice の電子署名を Alice の公開鍵で 復号化する。そして、出てきた内容のコ ピーと、一緒に配布されたオリジナルを 比較する。
一致してれば、オリジナルのままだと分 かる。違っていれば、どこが改竄された のか理解できる。つまり、完全性を実現 している。
Alice の公開鍵で復号化できる暗号文は、 Alice の秘密鍵で暗号化されている。こ の秘密鍵は Alice しか持っていない。 だから、Alice を認証できたことになる。 Bob は Alice となんら秘密を共有して いないのに、Alice を認証できるのは驚 くべきことだ。
機密性の場合は、速度の速い共有鍵を利 用することで問題を解決した。電子署名 を洗練化するためには、「セキュア・ハッ シュ関数」を使う。
セキュア・ハッシュ関数は、高度なチェッ クサムである。任意の長さの入力をとり、 高速に十分に長い(たとえば 128 ビット) ハッシュ値を出力する。
ハッシュ値はほとんど衝突しないよう設 計されている。別のいい方をすれば、改 竄前と改竄後に、同じハッシュ値が生成 されるように内容を改変するのは困難だ。
また当然のことながら、出力から入力を 推測することは難しい。これを、セキュ ア・ハッシュ関数の「一方向性」と呼ぶ。
セキュア・ハッシュ関数の例としては MD 5 (Message Digest)や SHA-1 (Secure Hash Algorithm)がある。それ ぞれのハッシュ長は、128 ビットと 160 ビットである。
Alice は内容のハッシュ値をとり、これ を Alice の秘密鍵で暗号化して電子署 名を作る。そして、内容とこの電子署名 を Bob に送る。
Bob は、電子署名を Alice の公開鍵で 復号化し、ハッシュ値を取り出す。次に 内容のハッシュ値をとり、両者を比べる。
一致していれば、内容は完全で、認証も でき、さらに否認防止も達成できる。異 なっていれば、内容が不完全だというこ とになる。
内容をハッシュ値に集約しているため、 どこかが改竄されたと検知できるが、ど こが改竄されたかは分からない。これは 速度と具体性のトレードオフといえる。
電子署名の例としては、RSA と DSS (Digital Signature Standard)が挙げら れる。
MAC では前提として通信者同士が秘密を 共有する。今までさんざん問題にしてき た秘密の共有を、安易に前提条件にして 欲しくないと思う人もいるだろう。
MAC にとって、秘密をどう共有するかは、 守備範囲外だ。それでも納得できない人 のために共有方法の一例を挙げておこう。 なにも危険な通信路を使って秘密を共有 する必要はない。あらかじめ会って秘密 を共有し、その後離れて通信する場合も 実際多々ある。
MAC の手順を Alice と Bob を登場させ て説明しよう(図6)。Alice と Bob はあ らかじめ秘密を共有している。
Alice は内容に秘密を連結しハッシュ値 をとる。これが MAC である。そして、 Alice は内容と MAC を Bob に送る。
Bob は送られてきた内容と秘密を連結し ハッシュ値をとる。これを送られてきた MAC と比較する。
一致していれば、内容は完全だ。これは 自明だろう。認証もできたことになる。 なぜなら、その MAC を生成するには、 秘密を知っていなければならず、知って いるのは Alice と Bob の 2 人だけだ からだ。
否認防止は実現できない。Bob が 「Alice は以前こういった。その証拠に この MAC を見てくれ」と主張しても、 その MAC は Bob が生成したものかもし れない。Bob も秘密を知っているのだか ら。
MAC の例としては、HMAC-MD5 や HAMC-SHA-1 が挙げられる。
鍵長やハッシュ長には、少なくとも 128 ビット必要だ。たとえば、40 ビットの 鍵を使う共有鍵暗号や 64 ビットのセキュ ア・ハッシュ関数は論外である。
なぜなら、たとえば 2^64 の整数空間は、 世界中のコンピュータをフル稼働させれ ば、現実的な時間で全空間を網羅するこ とも夢ではない。
しかし、2^128 の整数空間は、世界中の 全てのコンピュータを利用しても、鍵を 見つけるのに宇宙の歴史よりも長い時間 がかかる。
公開鍵暗号では、1024 ビット以上の鍵 を使えといわれる。2^1024 は途方もな く大きな整数空間だ。しかし、たとえば RSA では素数のみを対象にするので、 2^1024 の中に、素数が何個あるのかが 問題になる。
天才数学者ガウスは 15 歳のとき、整数 n 以下の素数の個数は、n / log n 個に 近いという予想を立てた。この式から計 算すると、2^1024 の整数空間には、お おまかにいって 2^1014 の素数が存在す ることになる。もちろん、これはすべて の可能性を網羅するには多き過ぎるから、 安全だといえる。
1 つは、なぜ公開鍵暗号では、ユーザ毎 に違う鍵の組が生成されるのかという疑 問である。世界人口は 61 億人もいるの だから、全員が全員違う鍵になるなんて あり得ないと懸念するのももっともだ。
人間の感覚が、いかにいい加減か物語る 事例に「誕生日のパラドックス」がある。 たとえば、30 人を集めて、「この中に 同じ誕生日に人がいるか」と聞かれれば、 多くの人は「いない」方に賭ける。なん といっても、1 年は 365 日もあるのだ から。
しかし、23 人の時点で、確率は 50% を 越える。30 人もいるなら「いる」方に 賭けた方がいい。
365 個場合の数から、23 個を取り出す ことを大雑把にいい換えれば、2^9 から 2^5 個を取り出すことに近い。前述のよ うに、これは 50% に近い確率となる。
公開鍵の生成については、どうだろう？ 1024 ビットの素数空間から、世界中の 人が素数を拾い出すのは、2^1011 から 2^33 個を取り出すことに近い。これは、 ほとんど 0% である。(正確な算出はこ れとは異なるが、ほとんど 0% であるこ とには変りない。)
取り出す数が大きくても、母数がそれよ りも圧倒的に広大なら、重なる確率は 0% ということだ。人間の感覚がずれて いるのは、母数と取り出す数を正確に比 較していないことに起因する。
2 つ目の話題は、ハッシュ値の衝突であ る。これまで述べてきたように、2^128 ビットの整数空間は、あまりに巨大であ る。そこで、セキュア・ハッシュ関数が うまく設計されていれば、衝突しないに 十分な空間を提供しているといえる。
このように乱数もセキュリティの重要な 技術だ。乱数は、計算で生成する「疑似 乱数」と、本当にでたらめな「真性乱数」 とに区別できる。
c 以下の疑似乱数を生成する簡単な数列 を以下に示す。
Vn+1 = Vn * a + b (mod c)式を複雑にすれば、疑似乱数の性質がよ くなる、つまりもっとランダムになると 勘違いする人も多いだろう。しかし、式 を複雑にすると、乱数の性質が悪くなる 場合がほとんどである。
疑似乱数の性質のよし悪しは、なにで決 まるのだろう？ 疑似乱数を使って、あ る値が生成されたとしよう。次の値は、 数式から計算される。つまり、ある状態 から決定的に次の状態へ移る。さらに値 は有限(c 以下)である。この 2 つを総 合すると、疑似乱数は「周期」を持つこ とが分かる。
周期が長ければ長いほど、疑似乱数の性 質はよい。自明であるが最大周期は、生 成する値が表現できる最大値である。た とえば、128 ビットの値を生成する疑似 乱数は、どんなにうまく設計しても 2^128 より大きな周期は持ち得ない。
上記の式を複雑にしても周期を長くする ことは難しい。数学的な根拠を持たず、 いい加減に式を変更しても、周期が短く なるのがオチだ。
最大周期を持つ疑似乱数の生成としては、 LFSR(Liner Feedback Shift Register) が知られている。数学的な根拠は難しい ので割愛するが、CRC チェックサムと同 じ技術が使われている。
しかし、高性能の疑似乱数も、しょせん 疑似乱数だ。初期値がバレれば、それ以 降の系列を予測できる。公開鍵暗号の鍵 の生成などには、やはり本当にでたらめ な真性乱数が必要となる。
ではコンピュータで、真性乱数を作り出 すにはどうすればよいだろう？ 最近で は、キーボード、マウス、ネットワーク などハードウェアの割り込みのタイミン グを測る方法が用いられている。専門家 の間では、これは十分によい方法だとさ れている。
UNIX では、真性乱数を簡単に利用でき るように /dev/random というデバイス が用意されている。/dev/random を read() すると、真性乱数が読み込める 訳だ。
/dev/random では、現在蓄えている乱数 のバイト数と、乱数の状態を管理してい る。乱数の状態は、LFSR で表現されて いる。
ハードウェア割り込みが起こると、その タイミングを測り、乱数の度合を見積もっ て、乱数のバイト数を増やす。そして、 LFSR の状態を乱数の度合に応じて進める。 LFSR 自体は疑似乱数だが、状態の進め方 が真性乱数となっている。
/dev/random を read() したとしよう。 /dev/ramdom は LFSR の状態をセキュア・ ハッシュ関数にかけ真性乱数を出力する。 そして出力したバイト数だけ、乱数のバ イト数を減らす。(セキュア・ハッシュ 関数の一方向性により、出力からは LFSR の状態を予測できないことに注意 しよう。)
乱数のバイト数が 0 の場合は、ハード ウェア割り込みが起こり乱数のバイト数 が増えるまで、read() をブロックする。
典型的なアプリケーションは、 /dev/random を select() する。一定期 間ブロックされていると、select() は タイムアウトし戻ってくる。この場合ア プリケーションは、「キーボードと適当 に叩いて下さい」と表示し、ユーザに真 性乱数の生成に協力するよう求める。
前述のように公開鍵暗号では、秘密鍵と 公開鍵を利用する。安全な運用のために は、「秘密鍵を機密に保持する」ことが 重要となる。また、公開鍵は第3者に見 られてもよいが、改竄されてはならない。 つまり、「公開鍵の完全性を保ったまま 公開鍵を相手に届ける」ことも大問題で ある。
「秘密鍵を機密に保持する」には、共有 鍵暗号を使いパスワードで暗号化してお く方法をとる場合が多い。秘密鍵を利用 する場合、つまり署名を生成したり、自 分宛の暗号文を復号化する際に、パスワー ドを入力し秘密鍵を取り出す。
「公開鍵の完全性を保ったまま公開鍵を 相手に届ける」には、やはり署名を使う。 すなわち、公開鍵自体に署名するのであ る。署名された公開鍵を「証明書」と呼 ぶ。
「証明書を誰に発行してもらうか」つま り「誰に署名してもらうか」を「信用モ デル」という。信用モデルにはトップダ ウン的な方法とボトムアップ的な方法の 2 つがある。
トップダウン的な方法の典型例が CA (Certificate Authority)である。ユー ザは CA を信頼することが前提となる。 たとえば、Alice の公開鍵が CA によっ て署名されているとしよう。Bob は Alice の証明書を CA の公開鍵を使って 検証する。検証が OK なら、その鍵が改 竄されておらず、本当に Alice の公開 鍵だと信用する訳である。
CA を使うと、全ユーザの公開鍵を配送 する問題を、CA の公開鍵 1 つを配送す る問題に置き換えることができる。CA に階層構造を持たせることもある。
ボトムアップ的な方法の一例が、PGP が 採用している「信用の輪」である。信用 の輪では、ユーザ同士が互いの公開鍵に 署名し合う。そして、誰の署名をどの程 度信用するか私的なデータベースを作る。
たとえば、Alice の公開鍵に、Bob の署 名と Chris の署名が施されていたとし よう。Dave は、Bob の署名に 1 点、 Chris の署名に 2 点を与えているとす ると、Dave にとって Alice の公開鍵は、 3 点を獲得している。この得点を点数表 と照らし合わせて、Alice の公開鍵の正 当性を割り出すのである。
このように、セキュリティ技術の運用は いささか面倒だ。数学的に安全性が確か められているセキュリティ技術も、運用 を誤ると、まったく意味がなくなること を心に刻んでほしい。