プログラマのつぶやき

大袈裟なテーマですが、今プスプスと火種ができている状態です。おそらく今年の年末頃になるとマスコミでも取り上げられる問題になる可能性もあります。

「暗号アルゴリズムにおける2010年問題」の対応により「公開鍵長が2048bit以上」になる(2011年以降は2048bit証明書のみ発行される)と、例えばベリサインの「セキュア・サーバID」のルート証明書は「VeriSign Class 3 Primary CA - G5」を使用します。

しかし、このルート証明書は最近の端末にしか搭載されていないため、旧端末を救済するための方法として、ベリサインでは「クロスルート方式」が採用されています。

実際のサイト証明書までの証明階層構造を見てみましょう。

「セキュア・サーバID」公開鍵長1024bit
Class 3 Public Primary CA - G2
　　Class 3 Secure Server 1024-bit CA - G2
　　　　サイト証明書

1024bitではルート証明書は「Class 3 Public Primary CA - G2」となり、サイト証明書との間に中間証明書が入る３階層となります。

「セキュア・サーバID」公開鍵長2048bit対応端末
Class 3 Public Primary CA - G5
　　Class 3 Secure Server CA - G3
　　　　サイト証明書

2048bitの対応端末ではルート証明書は「Class 3 Public Primary CA - G5」に変更となり、サイト証明書との間に中間証明書が入る３階層となります。

「セキュア・サーバID」公開鍵長2048bit未対応端末
Class 3 Public Primary CA
　　Class 3 Public Primary CA - G5
　　　　Class 3 Secure Server CA - G3
　　　　　　サイト証明書

2048bitのルート証明書「Class 3 Public Primary CA - G5」を搭載していない未対応端末では、最上位に「Class 3 Public Primary CA」を追加して４階層となります。「Class 3 Public Primary CA」はほとんどの旧端末に搭載されているので認証できることになります。これが「クロスルート方式」といわれる方法です。

しかし、携帯端末にルート証明書が搭載されていればOKかというと、話はそうは単純ではないのです。そもそも端末仕様として2048bit暗号を扱える端末（またはアプリケーション）なのかどうかが問題となるのです。

6月に入り問題となった、auのEZアプリ(BREW)向けサービスの一部の通信ができないという事象は、まさに2048bit暗号を扱えないアプリの問題でした。
https://www.verisign.co.jp/ssl/about/20100601.html

そのため、クロスルート方式であっても、今までのように旧端末もすべてカバーするとうわけには行きません。事実、2G機種や古いスマートフォン、一部の3G機種では対応できないことが発表されており、大幅に対応数が減っています。各社、3G機種のみを対象としたり、2006年以降発売の機種を調査の対象としていることは、その事実を隠そう！？としているようにも思えます。

2048bit未対応3G機種(ベリサイン)
https://www.verisign.co.jp/ssl/about/mobile_list.html

1024bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL.html

2048bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL_2.0.html

いろいろな情報を総合すると、2G以前の携帯端末はほぼ全滅ということになりますが、2013年以降はマイクロソフトがOSから1024bitのルート証明書を強制的に削除するという発表したこともあり、2、3年は混乱が続くものと思われます。

今3年以上の1024bit証明書をとってもPC対応は厳しく、かといって、2048bit証明書をとると携帯対応率が激減してしまうという、悩ましい選択を私たちは迫られています。

あなたはどう対応しますか？