IE使うならVista以降が無難、SSLの暗号強度調査結果から

　秋葉原コンベンションホールで開催中の「Internet Week 2009」で25日、電子認証にかかわる話題を扱う「3時間でわかるこれからの電子認証」が行われた。本セッションでは、参加者にある程度の知識があることを前提に「電子認証にかかわる国内外の動向」と「運用の現状と課題」という2つのテーマで広範な話題が設けられたが、ここではその中から、ユーザーにとって身近な内容を取り上げる。

●より高い安全を目的に、変わるSSLサーバー証明書

　ネットワークを通じて商取引などをする場合には、SSL（Secure Socket Layer）を使って暗号化通信をすることが一般的になりつつある。これは、IDやパスワードなどの情報を第三者に盗み取られないようにするためだ。しかし、SSLで使用する「SSLサーバー証明書」は、その安全性を高めるために2010年を境にして大きく変わることになる。一般社団法人日本電子認証協議会（JCAF）の秋山卓司氏が行った「SSLサーバー証明書の動向」は、その内容について説明をしたものだ。

日本電子認証協議会の秋山卓司氏

　秋山氏は冒頭で「SSLの基礎知識」として簡単な説明をした後、SSLサーバー証明書についての認証レベルの違いから解説を始めた。SSLには、認証レベルの違いによって3つの種類がある。「DV SSL（Domain Validation SSL）」「OV SSL（Organization Validation SSL）」「EV SSL（Extended Validation SSL）」である。

　DV SSLは、ドメインの所有者に対して発行されるが、実在審査を伴っているわけではないため、同一組織内のサーバーなどサイトの運営者とアクセスするユーザーとの間にあらかじめ信頼関係があることが前提となる。それに対してOV SSLは、不特定多数のユーザーからのアクセスを前提として、サイトを運営する企業もしくは組織が実在することを各認証局（CA）が確認して発行される点が異なるわけだ。

　しかし、一般のユーザーにとってはDV SSLとOV SSLを見分けることが難しいという問題があり、また、OV SSLの審査基準も各認証局ごとに異なっていた。これらの点を改善し、一般の人にもわかりやすくするということで生まれたのがEV SSLであり、実在審査が国際標準で統一された。Webブラウザでは象徴的な「グリーンバー」で表示されることからもEV SSLとわかるようになっている。

　では現実問題として、EV SSLの普及の現状はどうだろうか。秋山氏によると、日本国内においても都市銀行をはじめとする主要な金融機関などについては順調に導入が進んでいるものの、全体から見ればまだまだ1割以下の普及率であり、OV SSLが全体の7割ぐらいを占めるのが実情だという。ただし、PC上の主要な5つのWebブラウザが対応を完了し、先日発表されたEV SSLの最新ガイドラインではさらに参加するベンダーも増えたことなどから今後の普及に期待したいとしている。

SSLにおける認証レベルの違い	EV SSLに参加するベンダー。Research in Motionは、スマートフォン「BlackBerry」の開発製造元

　次に、暗号アルゴリズムの“2010年問題”への対応として、2011年以降のEV SSLがどうなるかについての説明が行われた。そのポイントは、EV SSLを名乗るためには、RSA2048/SHA-1以上に対応しなければいけなくなったことにある。

　この問題は、特に携帯電話やゲーム機のような組み込み型の機器に対して顕著に現れるかもしれない。EV SSLは、そのわかりやすささから金融系やショッピング系を中心に普及が進むと考えられる。秋山氏は、「日本のインターネットの半分は携帯電話」とした上で、特に携帯電話ユーザーへの影響を心配しているということだった。

　セキュリティを考える上では、2つの点から考えなくてはいけない。1つは、より安全な方法をユーザーに提供すること。もう1つは、昨日までつながったのに、（認証が原因で）ある日を境に急につながらなくなるという問題を極力減らすことだ。ユーザーも、自分自身の安全を考える上で、自分が持っている機器の対応状況を一度調べてみる必要があるのかもしれない。例えば、古い携帯電話はもちろんだが、PCであっても、古い環境で使い続けている場合には（後述する神田氏の報告にもあるように）影響が出てくると考えられるからだ。秋山氏は、こうした問題については「認証局側でも、さまざまな選択肢を検討している」とした。

　秋山氏はまた、こうした問題以外にも、SHA-2、あるいはSHA-3への移行、EV SSL以外（DV SSLやOV SSL）の最低基準をどうしていくか、日本においてはEV審査の最適化などや証明書の日本語対応といった点を今後の課題として挙げた。

2011年以降のEV SSL	EV技術仕様の移行

●選択される暗号強度は、環境に大きく左右される

　NTT情報流通プラットフォーム研究所の神田雅透氏は、「TLS/SSLの暗号利用に関する現状と課題」と題して、昨年の「Internet Week 2008」で報告した「httpsで使われる暗号アルゴリズム」のその後を発表した。

NTT情報流通プラットフォーム研究所の神田雅透氏

　内容は、サーバー側の設定や運用、利用者側のブラウザ環境などによって使われる暗号の強度が変わってくるということを実際に調査し、まとめたものだ。これは、例えばあるサイトで「抜群の強度を誇る×××の暗号方式を採用」ということを大々的にうたっていたとしても、場合によっては最弱の暗号方式が選ばれているかもしれないということを明らかにしたものでもある。

　では、SSLやTLSで使われる暗号アルゴリズムがどのように決定されるかをあらためて見てみよう（TLSはTransport Layer Securityの略で、ここではSSLを変更して標準化したもの、すなわち同じような役割を果たすものだと考えていただいてかまわない）。

　まず、図1「暗号アルゴリズムの決定手順」を見てもらうとわかりやすいが、クライアントが自身で利用可能な暗号アルゴリズムの一覧をサーバーに送る。サーバー側は、その一覧を見て暗号アルゴリズムを決定する。これだけを見ると当たり前のようだが、次に図2「ブラウザが利用する暗号のデフォルト優先順位」に目を移していただきたい。

◆図1　暗号アルゴリズムの決定手順

◆図2　ブラウザが利用する暗号のデフォルト優先順位（この図に関しては、神田氏のご厚意によりデータをいただいた。あらためて感謝したい）

　この図を見てあらためて問題だと感じられるのは、例えばInternet Explorer（IE）6では暗号強度の弱いRC4のMD5が第一優先で選ばれることである。これは、例えばサーバー側が「RC4-MD5が使えます」としていた場合には、自然とRC4-MD5が採用されてしまうということでもある。

　Windowsで言えば、この傾向はWindows XP SP3でのIE8まで続き、その改善を見るにはVistaに移行しなければならない。その一方で、Firefoxは暗号強度が高い方式が優先される仕組みになっていることがわかる。

　面白いのはSafariで、暗号強度の優先順位がIEに合わされているように見える。ここからわかることは、暗号強度を高くしたいときにはWindows XP環境であればFirefoxを使い、IEを使いたいのであればWindows Vista以降のOSを採用するのが無難だということである。

　さて、では次に、サーバー側の状況を見ていこう。神田氏の調査は、政府・公共系の約145サーバー、金融系の約135サーバーを対象とし、2008年10月から11月、2009年5月から6月の2回に分けて調査を行ったものだそうだ。

◆図3　サーバー証明書の状況

　図3「サーバー証明書の状況」は、サーバー証明書が何のアルゴリズムを採用しているか、また、証明書の有効期間はどれくらいかを示したものだ。これを見ると、政府・公共系ではMD5と呼ばれる強度の低いアルゴリズムが有意に減少し、強度の高いSHA1-RSA2048が増加している。神田氏は、SHA1-RSA2048が増加したのはGPKI（GovernmentPKI）集約効果によるものであり、MD5が減ったのは管理担当者が積極的に変更を行ったのではなく、MD5が提供されなくなったあとでサーバー証明書の更新をしたためではないかと推測した。その一方で、金融系には目立った大きな変化が無い。SHA1-RSA2048 EVが増えたのは、EV SSL効果であると推測される。

　では次に、サーバーで受け入れ可能な主な暗号としてどのようなものが設定されているかを見ていこう（図4、図5）。ここで注目したいのは、より高い暗号強度のサポートよりも、使用があまり推奨されないRC4-MD5が非常に高い割合でサポートされている点だ。

　これがなぜ問題になるのか。それは、先に説明されたIE6のようなブラウザの存在があるからだ。これでは、いくら高い暗号強度を持っていたとしても空しくなるばかりではないだろうか。

◆図4　サーバーで受け入れ可能な主な暗号（政府・公共系）

◆図5　サーバーで受け入れ可能な主な暗号（金融系）

　では、ここからIEとFirefoxそれぞれでの接続結果を並べてみよう（図6、図7、図8）。ブラウザの違い、OSの違いでどれくらいの変化があるかを感じとってほしい。ちなみに、グラフ中に「今まで使っていたデータは誤りでした」とあるのは、RC4-SHAとRC4-MD5を表面上識別する手段は無く、前回の調査時には「まさか、RC4-MD5が優先されるとは思っていなかった」とのことで、あらためてパケットキャプチャをして判明したということであった。

◆図6　IE7（Windows XP）接続結果

◆図7　Firefox接続結果

◆図8　IE7（Windows Vista）接続結果

　これらの調査結果から神田氏は、整合的に暗号設定が行われている形跡が見いだせないとして、設定がベンダー任せになっていないかをもう一度見直すことを推奨した。また、設定の失敗例として、暗号強度を高めた結果、逆に強度の弱い暗号も選べるようになってしまった例や、証明書の不整合の見逃し、証明書の期限切れが意外と多いことなどが伝えられた。

SSLの調査結果から

　セッション後、暗号化に興味を持つ人々のために、神田氏より、手軽にできる暗号強度の確認方法を教えていただいたのでここで紹介する。

・Firefox 3
「ツール」→「ページの情報」、もしくは（右下の）「鍵マーク」をダブルクリック、もしくは（アドレスバーのhttpsの左側の）「EVSSLの識別マーク」をクリック→「詳細を表示」のいずれかの方法でページ情報が見られる。ただし、ハッシュ関数、秘密鍵交換用の公開鍵暗号名、デジタル署名の暗号名についてはわからない。また、暗号の部分が混在していたり、たまに表示をしないようにしているサイトもあるために、結果として「一部が暗号化されている」や「暗号化」とだけ表示されることもあるようだ。

・IE8
「ファイル」→「プロパティ」で表示される。ここでは、共通鍵暗号の暗号名と秘密鍵交換用の公開鍵暗号名が表示される。ただし、Firefoxと同様にハッシュ関数はわからない。