2004年1月8日、ベリサインの中間CA局証明書のひとつが失効したことにより、既に出回っているクライアントソフトウェアのいくつかがSSLで通信を行うサーバに接続できなくなり、世界各地で小粒だが大量のトラブルが同時多発した。インフォテリアの社内でもいくつかの顧客システムでこの現象に遭遇し、サポートの電話が鳴っていた。
そんなお騒がせなトラブルのひとつに、こんな事件もあった。
※ 後日追加:上記の中間CA局証明書の問題と下記のノートンの問題は独立した問題でした。詳しくはコメント欄をご参照ください
米Symantecは、同社のNorton AntiVirusのユーザーから寄せられていた苦情について、その問題の原因が米VeriSignにあると発表した。ユーザーからの苦情の内容は、最新のウイルス定義ファイルをダウンロードして以来、コンピュータの動作が緩慢になったり、不安定になったりしたというものだ。
VeriSignの発行した証明書の一部が、先週有効期限切れとなったが、これにより、ユーザーがウェブサイトの暗号のかかったエリアにアクセスしようとした際に表示される害のないエラーメッセージよりも深刻な問題が発生していたようだ。Symantecでは9日(米国時間)、自社のセキュリティソフトウェア製品に生じた、ユーザーのPCの動作が緩慢になったり不安定になるという問題について、VeriSignを非難した。
ベリサインはこの問題のリスクを敢えて事前に注意喚起する姿勢を取らず、さらに当日になってもWebサイトのどこにも告知が行われていなかった。せいぜい、2002年12月18日に掲載したという証拠が以下にあるため免責されるという考えなのであろう。
グローバル・サーバID用の中間CA局証明書(有効期限2004年1月7日版)について
実際、仮に動作不良に陥ったクライアントシステムを調べてSSLのハンドシェークで例外が発生していることを突き止め、中間CA局の証明書が失効していることを突き止めたとしても、上記の案内ページをベリサインのWebサイトから見つけ出すのは容易ではない。また、MS CAPIベースでCRL(証明書失効リスト)を自動更新する真面目な実装を行っていたシステムほど被害が大きかったという点も、以下に示すような問題を顕在化させている。そして、ようやく13日になって以下のような言明が行われた。
今回は、この問題からセキュリティ技術の本質に迫ってみよう。
セキュリティとはいったい何だったのか
この件が示唆したのは、PKIの運用モデルは実際かなり複雑で、相当の運用知識がないとリスクを伴うものであるということだ。SSLを使ってセキュアなWebシステムを構築している(と思っている)サーバ管理者のいったい何割ぐらいが、今回の問題の内容を正しく理解できただろうか。
セキュリティ技術ほど本質が正しく理解されないまま印象や思い込みだけで使われているテクノロジーも珍しい。
PKIに限らず情報のセキュリティを実現する階層は、「ポリシー」を土台とし、「認証」、「許可」、「暗号化」、「監査」へと上方へ積み重なるピラミッド構造になっている。つまり、ポリシーなき認証には意味がないし、認証が成立していないところに存在する暗号化なども殆どの場合には無意味なのだ。こういった依存関係も、多くの場合には正しく理解されていない。
例えばHTTPSで典型的なサーバ認証なども、証明書に何らかの問題のあるWebサーバへブラウザから接続した場合、サーバ認証に失敗してこの図のようなダイアログボックスが出る。ここで、例えば信頼された証明機関から発行されていればとりあえずOKとするのか、それとも有効期限まで正しくなければNGとするのか、といったことをルール化し、オペレーションを徹底化させるのがまさに「ポリシー」である。しかし、セキュリティの専門家ではないエンドユーザが操作するWebブラウザで、このダイアログに表示される内容がどのようなリスクを意味しているのかを正しく(しかも短い時間で)理解することは期待できない。したがって、このユーザインターフェースはそもそも適切ではないのだ。
ポリシーとは自動化されるべきもので、ユーザに「選択」を迫るようなものであってはいけないのだ。そしてさらに、ポリシーとはベストプラクティスでなくてはいけない。ベストプラクティスが確立されれば、ポリシーは自動実行することができる。それができていないということは、基本的な意味で現在のセキュリティ技術はまだ未成熟なのだ。
しかし、このポリシーを決めなくては、例えば「暗号化」のような上層サービスは無意味なのである。なぜなら、ポリシーが徹底されず、偽者の証明書でも何でもユーザが「選択」により受け入れてしまえば「認証」は成立せず、つまり相手が「本物」か「なりすまし」かの判別ができない。「なりすまし」の相手が提供するウィルス・プログラムを「許可」したり、「なりすまし」の相手と「暗号化」された通信を密やかに行うことほど、滑稽なことはないだろう。
つまりセキュリティ技術を支える数学的モデルの高度さは、セキュリティを「運用」する上で、ポリシーの下位に存在するひとつのパラメータに過ぎず、それ自身の堅牢さよりはるかに低い次元のずさんな運用によって如何様にも脆弱になるという依存性を切り離せないのである。
PKIのパラドクス
中でもPKI (Public Key Infrastructure)は同じタネから作られる公開鍵と秘密鍵のペアをうまく活用したモデルで、一般に共有鍵方式に比べて鍵の管理性が高く強力な認証を行えるという特徴がある。そのためSSL (Secure Socket Layer)やデジタル署名などのアプリケーションで多く使われるようになってきた。(厳密にはSSLは共有鍵方式とのハイブリッドだが)
しかし、いかに共有鍵方式に比べて強度の面でメリットが多いとはいえ、PKIには問題も多い。
例えば証明書のステータスについては多くを定義したが、ほとんどが正しく運用されていない。例えば証明書が「無効」になるのは「有効期限切れによる失効」「意図的な廃棄による失効」「一時停止による失効」などがあるわけだが、これは各ノードが正しく、かつタイムリーにCRLによるステータスの同期を行うというモデルを前提としている。
しかし、今回の件で奇しくもベリサイン自身が過小評価したキャパシティプランニングで証明してしまったように、CRLベースで運用されている実装はそれほど多くないし、タイムリーでもいないのだ(時系列に平準化されていればこのようなピークは避けられた)。この問題の根は深く、例えば本来なら失効しているはずの証明書も有効として扱ってしまうような手抜きの実装をしている方が、実用レベルでは疎通性が高くユーザから見れば「快適」であることが多く、セキュリティ運用の厳密さに勝ることが多い。一方、良心的に厳密な実装をしていることは、失効によるサービス利用停止によりユーザに不便をかけることになり、ほとんどのケースでは利便性とのトレードオフで敗北を喫する。今回のノートンの件だって、バグか何かで証明書の検証が行われていなければ(つまり「実はセキュリティがかかっていない」状態ならば)、こんな問題に遭遇することはなかったのだ。
何と言うことだろう。そこには「セキュリティを正しく維持することの重要性・完全性・妥当性は、セキュリティ問題が発覚するまで理解できない」という非対称性が存在するのである。これは実装者の動機付けも含め、極めて深刻な問題である。
また、PKIの実現する暗号強度は用途によっては明らかにオーバースペックである。パスワードZIP圧縮のような「開けゴマ」の合言葉方式(共有鍵方式)の簡易な認証・暗号の方が扱いやすいシーンはいくらでもある。例えばネットワークを流通するパケットをたまたま覗いていたネットワーク管理者が平文で見えないようにするという程度の目的を仮定すれば、この運用コストの低い方法で十分に機能する。要するに利便性と堅牢性のトレードオフを平衡させるセンスだよ、という当たり前の話が、PKI万能論がはびこる現在では主張しにくい。
さらに、共有鍵方式に比べて鍵の管理性・配布性が高いというのも理論上の比較と現実の比較では状況が大きく異なる。例えば、ある親密な集合では共通のパスワードだって構わないことがあるだろうし、相手毎にパスワード文字列を登録する作業の方が、複雑な仕組みを理解して複雑な手続きで証明書データを加工・変換してインポートするのに比べれば(件数の絶対数の多寡よりも)よっぽど楽である、という主張は十分に成立するだろう。
セキュリティ技術の未来に向けて
さて、ここまでに述べたような事柄について考えたこともなく、セキュリティ技術を「暗号」などの記号化された属性だけで漫然と理解している人たちは非常に多いわけだが、そういった人たちは責めを負うべきなのだろうか。もちろん、セキュリティ分野を専門とするエンジニアなら容赦する余地はないのだが、例えば他に優先度の高い知識を必要としているアプリケーションエンジニアにも、この複雑怪奇な背景を抱えるセキュリティ技術を正しく理解する義務があるのだろうか。このような議論をする場合に私の立場はいつもNOでである。クリティカルマスを獲得する目的で、人々を技術に歩み寄らせるという方法が成功することは絶対にない。勉強しない人が悪いのではなく、勉強しなければならない技術の方が悪いのだ。理解が難しい技術は、その未成熟さを露呈しているに過ぎない。
突き詰めればセキュリティなんて共同幻想に過ぎないのだから、繰り返しになるがベストプラクティスがすべてなのだ。そして、私の経験値から言って今のPKIには運用上の大きな壁があって、ベストプラクティスに収斂するのに膨大な時間を必要としてしまうような気がしている。パスワードによる認証(共有鍵方式)がPKIのシェアを下回ることは永遠にないだろうし、そうこうしているうちにより大きなイノベーションの波が登場する予感がしてならないのだ。
もしPKIに続く利便性(決して強度ではない)の高い認証・暗号技術について研究されているという情報をお持ちの方がいたら、是非教えてください。
♪ Jaco Pastorius with Mike Stern / Mood Swings
※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
横浜工文社 on 2004/01/23
上記の匿名希望の方から、以下のようなご指摘メールをいただきました。有用な内容と考えましたので、ご本人同意の上でここに転載させていただきます。
ご指摘の通り、中間CA局証明書の件とノートンの件は別件で、私の早合点でした。ここにお詫び申し上げます。(ほぼ同日に2件のトラブルがあったということです)
ご指摘ありがとうございました。
<引用>
本論の部分の「猫も杓子もPKI」という運用と、実運用とのギャップ、「今のPKIには運用上の大きな壁」というあたりは多いに同感であります。
ただ、CNET Japan の方にもコメントしましたが、導入部の「ベリサインの混乱」の事実認定に関して少々疑義があります。
私は、今回のノートンの件は、原因自体はベリサインですが、グローバル・サーバID用の中間CA局証明書の失効とは直接関係ないと思います。このことは、あなたが本文中でリンクしているベリサインの公式発表
http://www.verisign.co.jp/press/2004/pr_20040113.html
ベリサイン CRL配布サイトのレスポンス遅延について
の原文
http://www.verisign.com/corporate/news/2004/pr_20040112.html
VeriSign Update on Certificate Revocation List Expiration
の末尾近くで
Please note that this situation is unrelated to the Intermediate CA expiration issue discussed at
http://www.verisign.com/support/vendors/exp-gsid-ssl.html
という具合にベリサインが主張しています。(抄訳のせいか、この重要な部分が日本版では欠落している)
今回の件は、シマンテックが2002年あたりにコード署名に用いた、VeriSign Commercial Software Publishers CA発行の証明書(シリアル 06BD 7A76 6172 E1EF 44F1 9F35 D5E8 2B34)に関連するCRLを、マイクロソフトが内部的に保持していて、それの次回更新日が到達した、というのが真相ではないでしょうか。
それについては、NAV2003のコード署名の証明書と、
http://www.microsoft.com/japan/technet/security/bulletin/ms01-017.asp
VeriSign 発行の誤ったデジタル証明書による、なりすましの危険性 (MS01-017)
http://www.microsoft.com/japan/technet/security/bulletin/fq01-017.asp
マイクロソフト セキュリティ情報 (MS01-017) : よく寄せられる質問
が根拠になると思います。
本論ではない部分ではありますが、「サーバ管理者のいったい何割ぐらいが、今回の問題の内容を正しく理解できただろうか。」という一文があるので、私の抱いた疑義をメールしました次第です。
私の指摘および事実認定に誤りがありましたら、ご教示頂ければ幸いです。
</引用>
また、よくよく考えるとこの件でシマンテックがベリサインを非難するというのはちょっと酷な話ですね。ピークを予期してそれに合わせたキャパプラで過剰投資しておけという話なので。CAPIの仕様による潜在的なリスクに気付かなかった、もしくはその実装方法を工夫しなかったシマンテック自身にも問題があるわけで、喧嘩両成敗といったところでしょうか。
いずれにせよ、PKIの問題の根の深さを示す事例ではありますね。
kenn on 2004/01/16
今回のノートンの件は、グローバル・サーバID用の中間CA局証明書の失効とは直接関係ないと思います。
シマンテックが2002年あたりにコード署名に用いた証明書、シリアル 06BD 7A76 6172 E1EF 44F1 9F35 D5E8 2B34 に関連するCRLを、マイクロソフトが内部的に保持していて、それの次回更新日が到達した、というのが真相ではないでしょうか。
なお、本論の「PKIの問題点」については私も同感です。
無記名 on 2004/01/15
ブログにコメントするにはCNET_IDにログインしてください。
この記事に対するTrackBackのURL:
メンバー限定サービスをご利用いただく場合、このページの上部からログイン、またはCNET_ID登録(無料)をしてください。
「PKIの問題点」の記事、面白く読みました。
「PKIに続く利便性(決して強度ではない)の高い認証・暗号技術について研究されているという情報をお持ちの方」とのお尋ねがありました。
弊社では、PKIの標準規格に拠らない、簡易PKIシステムを開発しました。証明書の有効無効・期限切れのチェックや再発行を簡便なプロトコルで単純化自動化するなど、運用を簡単にしました。
簡単な説明を http://www.kobu.com/certlet/ で公開しております。ご感想をいただければさいわいです。