なぜb-casは失敗してインターネットはうまくいくのか？
前のエントリで書いたように、b-casは用途を広げた時に前提条件が変わってしまったために、小さな「あってはならないこと」が起きただけで、手当ての方法が無くなってしまいました。
では、これと同じような見方で、インターネットそのものに「あってはならないこと」が起きた時どうなるか、について書いてみたいと思います。「インターネットそのもの」と言っても、一般の人が目にする「インターネット」の中でセキュリティをしっかり守らなければいけないのは、オンラインショッピングの時に使われる「SSL」という通信方式です。
アドレスが「https://」で始まるサイトにアクセスすると、そのアドレスの横に鍵の形の「安心マーク」が表示されます。オンラインショッピングで決済の画面やクレジットカード番号を入れる画面では必ずそうなっていると思いますが、これが今「SSL」を使っているよ、「SSL」がうまく動いているよというお知らせです。
この鍵マークがどれくらい安心なのかという話を書いてみたいと思います。つまり、鍵マークの中の人にとって「あってはならないこと」が起きた時、何が起こるのか？復旧はできるのか？という話です。
ついでに、長くなりますが、その「SSL」の仕組みをなるべく専門用語を使わないで解説してみました。
インターネットは信頼できない
オンラインショッピングが気軽にできるということは、実は、ものすごく不思議なことです。というのは、インターネットは基本的に信頼できないものだからです。それは、情報の伝達網そのものがしっかり管理されていないからです。
たとえば、電話回線だったら、電柱には電話会社の人しか触れません。電話局も全部電話会社の施設で出入りが管理されています。
しかし、インターネットのプロバイダは、大小さまざまな会社がたくさんあるし、大学や企業がプロバイダの役割を果たすことがあります。実際、あなたがアマゾンにアクセスする時にも、たくさんのプロバイダの施設を経由して、データが届くことになります。
その多くのプロバイダのどこかの建物一つに不正侵入できれば、通信内容を盗聴したり書き替えたりできてしまいます。物理的に侵入できなくても、途中のコンピュータやルータ一つに不正アクセスできればいいのです。
もちろん、現実的には大半のプロバイダは問題なく管理していますが、海外も含めてたくさんのプロバイダを経由する以上、全部がOKという前提で考えるのは、危険だということです。
だから、インターネットは、「通信内容の盗聴と書き替えは自由である」という前提で運用されています。SSLは、「信頼できない経路を通して安全にオンラインショッピングをする(だけの安心できる通信を行う)」ためのプロトコルです。
デジタルトルーマンショー
ちょっと脱線しますが、「インターネットで見えるものは全部嘘の可能性がある」という事実を妄想的に膨らませて、ちょっとしたショートショートを書いたことがあります。
だいぶ前のものなので、今読んでも元ネタがわからなくて意味不明かもしれませんが、「ブロガーに嘘のニュースを見せて、その嘘ニュースについてのブログエントリを書かせて笑いものにする」という架空のテレビ番組の話です。
つまり、ターゲットにされた人がニュースサイトや2ちゃんねるにアクセスした時に、内容をすりかえてニセのニュースを見せるということです。
これは、法的に禁止されているので実際に起こることはまず無いと思いますが、技術的には充分可能なことです。
ネットワークの末端にいる者にとっては、(SSLの鍵マークがない限り)表示されている内容が本物か偽物か区別する方法はないのです。インターネットとはそういうものです。
暗号アルゴリズムと鍵
それで、そういう嘘ばっかりのいいかげんなものを安全に使うために暗号技術というものを使います。
しかし、暗号技術の開発や利用には、ひとつ大きな問題があります。
それは、暗号の方式が本当に安全なのかどうかという検討を誰に頼むかということです。
この検討をするということは、そのアルゴリズムの秘密を知られてしまうので、秘密を守れる信頼できる人でないとお願いすることはできません。暗号を使った製品を実用化した時に、これを検討した関係者は全員、その暗号を解読できてしまいます。でもできれば、内輪だけでなく外部のしかるべき専門家を招待して、検討に加わっていただきたい。
そこで、暗号アルゴリズムは、必ず入れ替え可能な数字を含むようになっています。その数字がわからなければ、方式を知っていても解読はできません。その数字を暗号鍵と言います。数字と言っても桁数が多いので、実物は長い意味不明の文字列に見えますが、数字であることは確かです。
入れ替え可能な鍵を持つアルゴリズムは、たとえ発明者であっても実際に使用された暗号を解読することはできません。鍵の数字がいくつであっても同じように安全である(解読が困難である)ということが、暗号化アルゴリズムに求められる重要な条件です。
たとえば、b-cas方式では、テレビの製造者は誰もが、映像ストリームの暗号化に使われたアルゴリズムをよく理解しているはずです。そうでないとテレビが作れません。しかし、アルゴリズムを知っていても、b-casカードからもらう鍵が無いと復元はできません。
テレビやチューナーを製造する企業はたくさんあるので、厳重に管理しても暗号方式を秘密にし通すことはできないでしょう。しかし、鍵とアルゴリズムが分離していれば、アルゴリズムを秘密にする必要はありません。アルゴリズムではなく鍵にアクセスできる人間を限定して、鍵を管理すればいいのです。
鍵をどうやって相手に届けるのか？
まあ、それで専門家の人たちが頑張って、実用的で安全なアルゴリズムを開発してくれたとしましょう。そうしたら、アマゾンに頼んであなた専用の鍵を用意してもらえば、アマゾンのサーバとあなたのブラウザの間で安全な通信ができます。
しかし、ここで一つ問題があります。アマゾンはその鍵をどうやってあなたの所に届けるのか？
暗号鍵は桁数は多いけどただの数字です。だから、インターネットで送ることも簡単ですが、これは問題外です。途中のプロバイダに悪い奴がいて鍵を送信している所を盗聴されたら、その鍵を使って暗号通信を解読できるので、クレジットカード番号がわかってしまいます。
だから、鍵をUSBメモリに入れて、郵送してもらうことになります。できれば書留がいいでしょう。
しかし、いちいち買い物するたびに、その企業用の鍵を郵送してもらうのでは大変です。コストもかかるし、思いたったらすぐその場で買えるという、ネットショッピングの利点が失われてしまいます。
「じゃあ、その鍵も暗号通信で送ればいい」そう思う人もいるかもしれません。結論から言えば、実際にそうなっているのですが、その鍵を送るための暗号の鍵はどうしたらいいでしょうか？
ひとつの考え方としては、そういう鍵を送るための鍵を事前に用意しておくという方法です。その鍵を送るための鍵は、アマゾン専用にする必要はありません。公的な団体を作って全ての鍵配送を一括してやってもらえばいいでしょう。そうすれば、ネットでなく郵送で送る鍵は、その「鍵配送財団？」の鍵一つだけでよくて、他の処理はオンラインでできるようになります。
しかし、この方法だと、「鍵配送財団」の鍵が非常に重要な意味を持ちます。その鍵だけあれば、配送される買い物用の個別の鍵を全部盗めてしまうからです。あなたの買い物の内容全てを盗聴できてしまうし、あなたのアカウントを使ってログインして勝手な発注ができてしまいます。
だから、その鍵配送のためのマスターキーは非常に重要な鍵になるのですが、買い物をする全てのネットショップの運営者に、その超大事な鍵を教えないと、オンラインで買い物ができません。
そういう鍵を託せる相手は限られてしまうでしょう。アマゾンのような大企業でも、末端の社員まできちんと管理されているか確かめないと、教えることは危険です。
「鍵とアルゴリズムを分離する」は第一歩ですが、それだけでは、今あなたがしているように、ネットショッピングを安全に手軽に行うことはできないのです。
公開鍵暗号というブレークスルー
で、実は、ここで大変なブレークスルーがありました。世紀の大発明があったんです。
と言っても、その発明はネットの普及以前のことなので、その時点では重要性が評価されず、ネット普及以降は、そこに最初から当然あるものとして扱われているので、ありがたみを感じる人は少ないのですが、本当に重要な発明がありました。
それは、公開鍵暗号という方法です。
公開鍵暗号は、開ける鍵と閉める鍵が違うという不思議な暗号です。ものすごい難しい数学を使った高度なアルゴリズムなのですが、その数学の中身を理解する必要はありません。「平文を暗号文にする鍵と、暗号文を平文にする鍵が違う数字である」ということがわかっていれば、大丈夫です。
アマゾンに接続したら、閉める鍵を送ってもらいます。そして、その閉める鍵で施錠して(暗号化)して、それをアマゾンに送ります。アマゾンは自分だけが持っている開ける鍵を使って、解錠(復号)します。ネットに流れたのは閉める鍵だけで開ける鍵はネットに流してないので、盗まれることはありません。
公開鍵暗号という非常に不思議な数学の魔法を使うことで、ネット上で安全に通信を行うことができるようになったのです。
公開鍵暗号は、処理に時間がかかるという弱点があるので、実際には鍵の配送にだけ公開鍵暗号を使って、実際のメッセージはその鍵を使った普通の暗号(共通鍵暗号と言います)で行ないます。しかし、SSLのセキュリティの枠組みを考える上では、「開ける鍵と閉める鍵が違う暗号を使って送る」というおおざっぱな理解でいいと思います。
身元確認という残された課題
これで全部解決かというとそうではありません。
公開鍵暗号が可能にするのは、「特定の誰かと通信する時に、盗聴されないことを保証する」ということです。しかし、インターネットではその「誰か」が本当は誰なのかわかってない、http://www.amazon.co.jp/と入力して通信を始めても、その「誰か」が本物のアマゾンなのは、保証されていません。
途中のプロバイダに不正侵入して、通信を横取りして、自分がアマゾンの代わりに応答する、という方法があります。
さきほどの「デジタルトルーマンショー」と同じような状況です。しかし、アマゾンの膨大なコンテンツを全部用意するのは難しいので、その悪い奴も自分でアマゾンに接続して、それを中継するのです。
これは、「man in the middle attack」という、歌の題名みたいな専門用語がある、立派な攻撃手法です。
あなたから送られてきたデータをそのままアマゾンに送り、アマゾンの返答をそのまま全部あなたに送り返します。こうすれば、結局表示されるのはアマゾンの画面なので、見ている分には違いがわかりません。しかも、安全なはずのSSLで送っているので、それを盗聴されることがないことは保証されています。
SSLは、第三者が横入りで盗聴することは許しませんが、この場合は、(アマゾンでなく)悪い奴が開ける鍵を持っているので、中身を知られてしまいます。
だから、「盗聴されない」「改竄されない」という要件を満たすためには、同時に「通信相手の身元を保証する」という機能が必要になります。実際に、ブラウザの鍵マークはこの両方が満たされないと表示されません。
デジタル署名というもう一つの大発明
ここで、「デジタル署名」というもう一つの大発明が出てきます。
と言っても、実は「デジタル署名」は、「公開鍵暗号」のちょっとした応用です。「開ける鍵」と「閉める鍵」の使い方を逆にすると、「通信相手の身元を確認する」という用途に使えるのです。
「公開鍵暗号」では開ける鍵を秘密にして、閉める鍵をネットに送信(=一般公開と同じ意味)しました。「デジタル署名」では逆に、閉める鍵を手元に残して秘密にし、開ける鍵を公開するのです。そうすると、箱を閉められる(暗号文を作成できる)のは地球上でただ一人なので、その箱に入っていた内容は、その人が書いたものだと証明できます。その確認の為に必要な開ける鍵は、公開されています。だから開けること(=本物かどうか検証すること)は誰にでもできるようになります。
だから、アマゾンの公開鍵という数字と一緒に、「この鍵はamazon.co.jpのものであると保証する」という一文をつけて、鍵を閉めておけば、公開鍵暗号による通信を開始する時点では、相手の身元(相手が man in the middleではなくてアマゾン本人であること)が確認できるわけです。
なお、ここでも公開鍵暗号の計算速度などの問題があるので、実際の利用時には、ハッシュ関数などの関連する技術を組み合わせて使われますが、ポイントは「閉める鍵を持っているのは一人だけ」ということです。
ここで、鋭い人だと「ではその身元保証する人の鍵はどうする？」という疑問が出てくるでしょう。
さきほどの「鍵配送財団」と同じで、結局、「ある鍵に別の鍵の身元保証をさせる」という方法では、どこかに「究極の鍵」が必要になります。
- 「こんにちは」
- 「どなたですか？」
- 「Aと言います」
- 「誰？」
- 「Bさんの知り合いです。ほらここにBさんからの紹介状があります」
- 「Bさんって誰？」
- 「BさんはCさんの知り合いです。Cさんの紹介状がありますので、それでBさんが確かな人だとわかると思います」
- 「そのCさんって人も知らないんだけど、それ誰？」
というやりとりを繰り返して、最後に
- 「...そのXさんの友達のYさんはZさんの友達です。紹介状はこれです」
- 「ああなんだ、Zさんの(間接的な)知り合いですか。Zさんならよく知っている、安心できる人だ。じゃあ、おあがんなさい」
ということは人間ではあり得ませんが、機械同士なら瞬時に確実にできます。SSL接続の開始時には実際、こういう判断が行なわれているのですが、それにしても結局、Zさんの身元保証という「究極の鍵」が必要になってきます。
結局、これは、問題を先送りしただけで、本質的な解決になっていないように見えます。
ルート認証局の「究極の鍵」
実際、ブラウザには「究極の鍵」が含まれています。
Chromeだと、設定→高度な設定→証明書の管理→認証局という所で見ることができます。他のブラウザにも同じ項目が設定の奥の方にあるはずです。ここに出ている鍵は(ほとんどの場合)ブラウザと一緒にインストールされた「究極の鍵」です。
これを「ルート認証局」と言い、ルート認証局が一般の認証局を認証して、一般の認証局がサーバの身元を保証します(中間に何段階も認証局が入ることもあります)。この仕組み全体をPKIと言います。
「ルート認証局」の証明書だけが事前に(ブラウザ本体と一緒)に配布され、その下は、「デジタル署名」の連鎖で保証します。デジタル署名の検証は、ただの計算処理なので、どこかと通信する必要はありません。
これが「鍵配送財団」というアイディアと大きく違うのは、「究極の鍵」を入手しても何も悪いことができないということです。これは、共通鍵暗号と公開鍵暗号の性質の違いによります。公開鍵暗号を使ったデジタル署名では、秘密鍵と公開鍵が、印鑑と印鑑証明のような関係になります。
共通鍵暗号では、大事な鍵を使わないと日常の運用ができないので、それをサーバに置いておく必要があります。使うために渡すべきサーバの数(=鍵にアクセスできる関係者の人数)が大きくなります。印鑑を常時携帯するようなものです。
それに対して、公開鍵暗号では、印鑑はしまっておいて、使う時だけ出せばよいのです。認証局の印鑑(=秘密鍵)は、証明書を作る時には必要ですが、それが終わったらしまっておけるのです。証明書には期限が設定されているので、定期的に出して新しい証明書を作る必要がありますが、使わない時はしまっておけます。証明書を確認したい人には印鑑証明(=公開鍵)を渡しておけばいいのです。
実際の運用はどうなっているか知りませんが、おそらく、USBメモリやCD-ROMなどの媒体にコピーして、金庫にしまっておくのではないかと思います。インターネットに接続したマシンの中に入れておく必要はないので、コンピュータの中だとしてもそのコンピュータは物理的に外部から遮断されたコンピュータだと思います。
媒体の不良や施設の火事などでこれが消えてしまうと大変なので、複数のコピーに分けて地理的に分散して保存しているかもしれませんが、外部とオンラインでつながっているコンピュータにそのまま置かれていることはあり得ないと思います。
つまり、ルート認証局の秘密鍵の盗難は、草薙素子ではなくてルパン三世の担当分野であるということです。どんな凄腕クラッカーでも電脳的な超人でも盗めません。盗むとしたら古典的な金庫破りしかないのです。
「これを盗まれたら大半だ」という究極の鍵ができてしまうのは、架空の「鍵配送財団」のケースと同じですが、日常の運用には不要なので、それにアクセスできる人を限定できる、ということが大きく違います。
ただ、それでも「あってはならないこと」が絶対無いとは言えません。
SSLの「あってはならないこと」
まとめると、インターネットという信頼できない通信経路を使って、安全な通信を行うSLLの仕組みは次のようになります。
- ルート認証局を作って、そこから木構造で認証局を認証し、認証局が個々のサーバを認証する
- ルート認証局の公開鍵(上の例だとZさんの印鑑証明)をブラウザと一緒に一般の利用者に届ける
- ルート認証局の秘密鍵(上の例だとZさんの印鑑そのもの)はオフラインで厳重に管理する
- サーバは自分の公開鍵と証明書(上の例だとZさんからAさんまで連鎖した紹介状)をブラウザに送信する
- ブラウザは、手持ちのルート認証局の印鑑証明を紹介状に押された印鑑と照合し、そこから間接的にサーバの公開鍵の正当性を確認する
- 公開鍵の身元が確認できたら、それを使って公開鍵暗号で通信に使う鍵を送受信する(その鍵の正当な持ち主以外には盗聴されない)
- その鍵を使って(共通鍵方式の)暗号通信を行う
SSLの「あってはならないこと」は、二つあります。
どちらのケースも、通信相手の身元が保証できなくなるので、「man in the middle attack」を防ぐことができない状態になります。つまり、ブラウザの鍵マークを確認してもフィッシングが防げないということです。
ただ、どちらのケースでも、「交換できない部品に依存したセキュリティが破られた為に対策が不可能」ということにはなりません。
まず、応急処置としては、ブラウザ内の証明書を削除します。設定→高度な設定→証明書の管理→認証局から、問題のあるデータを削除します(Chromeの場合)。これで、盗まれたルート認証局に依存する証明書は無視されます。(上記の例だと、Zさんを知らない状態になるので「どこの馬の骨だお前は？帰れ!」となる)
1.のケースでは、その後で、ブラウザに正しいルート証明書をインストールすればOKです。
2.のケースではそれに加えて、ルート認証局の鍵から作り直すので、その配下の認証局とサーバの証明書を全部作り直しになります。これは時間のかかる大変な作業ですが、一般ユーザは応急処置の証明書削除だけを行なっておけば、「鍵マークがあれば安全、なければ危険」といういつもの判断基準でフィッシングを防ぐことができます(対策完了までは本物でも鍵マークが出ないケースがあり得ますがそれは仕方ないとして)。
おそらく、ブラウザの自動更新の仕組みによって、これらの対策は数日単位でほぼ自動的に行なわれるでしょう*1
偽のルート証明書つきのブラウザの配布+大規模なフィッシング という攻撃は、技術的には可能というか想定の範囲になると思いますが、これを悪用できる期間がブラウザの自動更新が完了するまでなので、コストに合わないので誰も行わないのではないかと思います。
なお、ブラウザには、ブラックリストを使って、正当でない証明書を受けつけないようにする機能があります。だから、実際の運用としては、ブラックリストの更新の方が有効でそちらの方策がメインになるかもしれません。
公開レビューと離脱可能性で担保する安全性
ということで、SSLでは「あってはならないこと」が起きたとしても大したことにはならないし、すぐに復旧できると思います。少なくとも犯罪目的での大規模なSSLの乗っ取りはあり得ない(コストに合わない)と言えます。
もちろん、これは理論面(のごく基礎)の話であって、何であれ実際のシステム運用では、斜め上のわけのわからないことが起きるものです。だから、絶対安心だということはできませんが、それ以上に、SSL(やその運用面の基盤となるPKI)は基本的に公開されている技術だということも重要だと思います。
私がここに書いたことは、トップレベルの数学者やプログラマが長い時間をかけて検証したものです。関連するプログラムコードもたくさんの人がレビューをしています。
これだけ広く検証されている所になお残った穴を見つけたら、それは大きな名誉です。「俺はSSLの穴を見つけた」と言えば、どこでもセキュリティコンサルタントやプログラマーとして高級で雇ってくれるでしょう。犯罪よりよほど稼げるのは確実です。だから、多くの専門家が真剣にレビューした結果であると考えてよいと思います。
それと、ネットは個人も企業も自発的参加が原則になってることも重要だと思います。
アマゾンや他の多くのネットショップがSSLを使うのは、それを上から規格として強制されたからではなくて、それぞれの企業が自社の責任で自分が使う技術を検証して「これは大丈夫だ」と判断したからです。
インターネットでは、形式的にも実質的にも、ある枠組みに問題があると思ったら、別の枠組みを立ちあげることが可能です。意見が割れた時に、間違った方にはつぶれて退場する自由があります。その離脱可能性が、現行のシステムの真剣な運用を担保していると私は思います。
SSL(PKI)が、合理的に設計され、まともに運用されているのは、単にそれを作った特定少数の人が偉かったからだけではなくて、公開レビューと意思決定主体の自律性が実質的に確保されているという、社会的な仕組みの必然的な結果だと思います。
一日一チベットリンク→チベットよりも深刻なウイグルの苦難（前篇） 歴史から見る少数民族問題 WEDGE Infinity(ウェッジ)
