自堕落な技術者の日記

gregさんが新しいNexus 5をゲットして、ルート証明書リストを Root CA Viewer Lite でエクスポートして送ってくれたので(gregさんありがとう)、 早速比較してみます。

で、比較してみると

差分はこんな感じ。

バージョン	ルート認証局数	追加	変更
Android 4.0.4	134	-	-
Android 4.3.1	146	12	2
Android 4.4	150	4	-

たった 4 つしか増えていないと・・・まぁ、そんなもんか。

新規追加されたのは

以下が、新規に追加された4個のルート認証局の一覧です。

認証局の識別名(DN)	有効期間	署名アルゴリズム	鍵長
CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES	2011-2030	SHA1withRSA	RSA 4096bit
CN=Hellenic Academic and Research Institutions RootCA 2011, O=Hellenic Academic and Research Institutions Cert. Authority, C=GR	2011-2031	SHA1withRSA	RSA 2048bit
CN=Entrust Root Certification Auuthority - EC1, OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, O=Entrust, Inc., C=US	2012-2037	SHA384withECDSA	ECC secp384r1
CN=StartCom Certification Authority G2, O=StartCom Ltd., C=IL	2010-2039	SHA256withRSA	RSA 4096bit

ギリシャの認証局と、エントラストの楕円 SHA384withECDSA secp384r1なんかが 特徴的ですかね。

今日はこのへんで

関連記事

• Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ(2013年11月6日)
• Xperiaに搭載されたルート認証局証明書 (2010年4月26日)
• Android 4.0 以降のルート証明書ストアを調べるツールを作ってみたいぞ (2012年09月30日)
• (小ネタ)Android 4.0 ICSのルート証明書ストア (2012年09月04日)
• Windowsルート認証機関の更新(2009.02) (2009年04月03日)

昨日書いたマレーシアのDigicert Sdn認証局の記事で ちょっと補足しておこうと思います。

CRLについて

• Digicert Sdnの問題を指摘された2つの中間CAは、 発行した証明書にCRL配布点(CDP)拡張は無いんだけども、 CRL自体はきちんと3日おきに発行しているようです。
• Entrustは、 Digicert Sdnの中間CAを少し移行までの猶予期間を持たせ 11月8日かそれより前に失効させると声明しています。 現時点(11月7日18:50 JST)では失効されていません。
• GTE CyberTrust Global Root(Verizon)は 失効させるといった声明はありません。 現時点(11月7日18:50 JST)では失効されていません。

CRLの発行周期および最新のCRLの発行日の情報は以下の通りです。

認証局名	発行周期	thisUpdate	nextUpdate
Entrust.net CA 2048 ルート認証局	7日	2011年11月6日	2011年11月13日
Digisign Server ID - (Enrich) (Entrust用)中間認証局	3日	2011年11月6日	2011年11月8日
GTE CyberTrust Global Root ルート認証局	3ヶ月	2011年11月1日	2012年2月4日
Digisign Server ID (Enrich) (GTE用)中間認証局	3日	2011年11月6日	2011年11月8日

Mozilla(FireFox)の認証局ブラックリスト追加のソースコードの更新

Mozillaでは前回のDigiNotarの証明書をブラックリストに入れる際、 certdata.txt に証明書を登録し、これからコード certdata.c を自動生成しています。

http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt

このファイルの最終更新は2011年11月3日ですが、まだDigicert Sdnに 対応はしていないようです。

以上、ちょっと補足でした。アップデートがあれば、また書きます。

関連記事

• 2011.11.06 米ユタのDigiCertとは無関係なマレーシアのDigicert Sdn認証局の問題について見てみたぞ

2011年11月3日のニュース でマレーシアのDigicert Sdn. Bhd.社という認証局が問題のある証明書を発行しており

• 現在、解読が可能とされている512bitのRSA鍵の証明書を発行している
• SSLサーバー証明書として使うには証明書の拡張領域に問題があった
• マレーシア政府機関に発行したものにも512bitの弱い鍵が使われている
• 発行した22枚の証明書で512bit鍵が使われている

そのような運用が問題視され、

• MicrosoftやMozillaが問題のあったマレーシアのDigicert Sdnの中間証明書を ブラックリストに入れた。FireFoxでは8からの対応になる。
• Digicert Sdnの上位のルート認証局であるEntrust社は問題のある中間証明書を、少し移行までの猶予を持たせ11月8日かそれより前に失効させる

という対応を取りました。

最初、ツイッターなどでこの問題が紹介されたとき米ユタ州にある割と 有名な認証局Digicertの子会社が問題が起こしたのかと 勘違いされていたようですが、全く別のマレーシアの会社だったようで 米DigiCert社も声明を出しています。 米DigiCert社は先日のオランダのDigiNotar社の時も 名前が似てたため「うちは関係ないよ」と声明だしており、最近踏んだり蹴ったりですねw。 さて、今日はこのマレーシアのDigicert Sdn認証局について、 ちょっと見てみたので報告したいと思います。

マレーシアDigicert Sdn社の幾つかの認証局

マレーシアのDigicert Sdn社はルート、中間を含め(おそらく)13もの認証局を持っています。我々に危険性の影響があるのは図の左側、多くのブラウザに信頼するルート認証局として搭載されている EntrustとGTE CyberTrust(現Verizon)をルート認証局とする 2つの中間認証局です。

Digicert社のそれぞれの認証局の特徴などを下表にまとめてみました。

認証局	特徴
ルート認証局
Digicert Class2 Root	組織、個人(18歳以上)向けに発行する下位CAを持つ信頼レベル高中のルート認証局
Digicert Class1 Root	個人向けに発行する下位CAを持つ信頼レベル低のルート認証局
Malaysia Primier CA 1024	SHA1withRSA 1024bit 大量にMD5withRSAユーザ証明書を発行
他社ルートの中間認証局
Digisign Server ID (Enrich)	上位CAはGTE CyberTrust Global Root 自己署名証明書は公開してなさそう SSLサーバー証明書と(証明書管理者用?)ユーザ証明書を発行
Digisign Server ID - (Enrich)	上位CAはEntrust.net Certification Authority (2048) 自己署名証明書は公開してる SSLサーバー証明書と(証明書管理者用?)ユーザ証明書を発行 上のとは " - "(ハイフン)が違う
Digicert Class2 Root下位の中間認証局
Digisign Server ID	SHA1withRSA 1024bit 証明書管理者用のユーザ証明書を発行しているようだ 金融系やカード系が多い
Digisign ID (Enhanced)	S/MIMEにも使えそうなユーザ証明書を発行 変なプライベート拡張がある
Digisign ID (Basic)	一般のユーザ証明書を発行しているようだ
MyKAD Online	一般のユーザ証明書を発行しているようだ
DIGISIGN iVEST CA	ユーザ証明書かS/MIME証明書か？
DIGISIGN iVEST CA Enhanced	ユーザ証明書かS/MIME証明書か？
Digicert Class1 Root下位の中間認証局
DigiSign ID	現在でも大量のRSA 512bit鍵のユーザ証明書を発行しているようだ
Digisign Corporate Email	本中間CA証明書は2006年に期限切れ 下にユーザ証明書は見当たらず

これらのすべての認証局証明書の鍵長は 1024bitか2048bitで証明書プロファイルも 特に問題になりそうな点は見つかりませんでした。 他にも

• CIMB Investment Bank Berhad Enterprise CA
• Bank Negara Malaysia Sub CA

などマレーシアの銀行の認証局を運用しているようですが、 証明書が見つからず調査できませんでした。

EntrustとGTE CyberTrustルートのDigicert Sdn中間認証局

マレーシアのDigicert Sdnのルート証明書はIEやFireFoxなどの ルート証明書には搭載されておらず、 今回、Microsoft や Mozillaがブラックリストに入れたのは EntrustやGTE CyberTrustをルート認証局とするDigicert Sdnの 中間CA証明書です。 IEでみるとGTE CyberTrustルートの場合、証明書チェーンはこんな感じ、

IEでみるとEntrustルートの場合、証明書チェーンはこんな感じです。

両者を少し数字で比較してみましょう。

比較項目	GTE CyberTrustルート	Entrustルート
(a) 証明書発行枚数(2011年11月5日時点、延べ)	1198枚	984枚
(b) (a)のうち2011年11月3日時点で有効なもの	110枚	448枚
(c) (a)のうち2011年11月3日時点で有効なマレーシア政府のもの	69枚	205枚
(d) (a)のうちRSA512bit鍵のもの	37枚	8枚
(e) (a)のうちRSA512bit鍵で現時点(11/5)で有効なもの	7枚	7枚
(f) (a)のうちRSA512bit鍵で現時点(11/5)で有効なマレーシア政府ドメインのもの	0枚	5枚

ニュースで取り上げられている22枚という数字は どこから出てきたものなのかよくわかりませんね。

現在、解読された実績のある512bit RSA鍵の証明書を発行している ことは問題といえば問題ですが、利用者が鍵を生成して 証明書発行要求しているわけですから利用者側にも問題がありますよね。

問題のある証明書拡張領域とは？

拡張領域の違いはGTE CyberTrustルートとEntrustルートでは なくて、鍵長により微妙に拡張が違うようです。 これは鍵長2048bitのもの。

これは512bitのものです。

ニュースでは、通常TLSサーバー用とか TLSクライアント用とか書かれる 拡張鍵使用目的(Extended Key Usage)がないとか、他にも 拡張でおかしなところがあると言っています。 おかしなところをヤバい順にまとめてみましょう。

CRL配布点(CDP:CRL Distribution Points)が無い

これが無いため証明書を失効させることができません。 今回のように発行した証明書に問題があった時に失効できないことはホント致命的。

KeyUsageがないものがある

512bit RSA鍵の場合に拡張が無いようです。 RFC 3280的にはTLSでは署名検証に使うので必須(MUST)ですね。

拡張鍵使用目的(EKU:Extended Key Usage)がない

必須ではなかった気がしますが普通ついてます。

KeyUsageがあっても、不要なビットが立っている

Key Usage拡張は512bitより大きい鍵の証明書では有るようですが、 値としてDigital Signature、Non-Repudiation、Key Encipherment、 Data Enciphermentのビットが立っています。 SSLサーバー証明書ではNon-Repudiation、Data Enciphermentは余計ですよね。

RFC 5280 4.2.1.12 Extended Key Usageより
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions.
中略
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

RFC 5280ではExtended Key UsageとKey Usageが一貫している 事がMUSTになっています。

基本制約(Basic Constraints)が無い

なければ認証局証明書でないってことなんですが、一般にはつけることが多いですよね。 随分昔、あるメーラーで基本制約が無いことを無視して、ユーザ証明書から下位証明書発行しても検証成功だったことを発見してしまったり、、、

Authority/Subject Key Identifierで64bitは最近珍しい

ですよね？

結局、CRL配布点拡張がなく失効できないというのが一番の問題 だったんだと思います。失効できていれば、 単に問題のあった証明書を失効させ、鍵長や拡張領域に 問題があったとしても正しいものを再発行すれば よかっただけで、こんなに大きな問題にはならなかったはずです。 失効できないために認証局丸ごとブラックリスト化するしか 手が無かったわけです。 ニュースではEKUが無いのがおかしいとか わけのわからない事指摘してますよね。

CPS(認証実施規程)と照らしてどうなの？

認証局ではCPS(認証実施規程)で定めた運用に従い 証明書を発行するわけですが、これと照らしてどうだったのか Digicert SdnのCPSを ちょっと見てみました。

• 鍵長が512bit以下ではダメだという記述は見当たらなかったので CPS的に512bitの鍵に対して証明書発行することは問題が無かったようだ。
• 拡張領域については単に使用可能な拡張をまとめているだけで 発行する証明書の用途ごとに証明書プロファイルを定めて いなかったのでCDP拡張など拡張が不足していたり問題があったと してもCPS違反になることは無い。

とまぁ、このような感じでCPSに違反しているということは 無かったようです。

ただ、CPS中の証明書プロファイルについて、どのような拡張が 必ず含まれるのか、含まれないのか明確になっておらず、 CRL配布点拡張が無いという認証局設計上の重大な欠陥が 明らかになってこなかったという問題はありますけどね。

今回の問題に対する評価はこれでいいのか

今回の問題は、COMODOやDigiNotarのように攻撃されて サブCAやRAが乗っ取られ不正な証明書を出し放題になっていたわけでも なく、同列に問題を語られているのは違和感を覚えます。 高々、認証局ではなくSSLサーバ証明書の鍵が不正に使われるだけですよね。 512bit鍵の証明書を発行してしまったのは、利用者(お客さん)にも 問題があったわけですよね。 とても悔やまれるのはCRL Distribution Points拡張が 入っていなかったその一点です。 それさえ入っていれば、問題が発覚しても 単に証明書再発行すれば済んだのに、 中間CA証明書のブラックリスト入りという結果になってしまいました。 同じCAから発行されているSSLサーバー証明書でも 拡張のまともなものもあり

完全にとばっちりを食ったお客さんも多数いるわけですよね。 可哀想だなぁと思います。

GTE CyberTrust Global Rootを運用しているVerizonからは 何のコメントも無いのも変な感じですよね。

おわりに

以上、マレーシアのDigicert Sdnの認証局の問題について ちょっと調べたところを報告しまいた。 512 bit RSA鍵が問題だみたいなニュースの論調ですが、 あれはユーザの鍵なのでCA鍵と違って危殆化しても大した問題では なくて、それよりもCRL配布点拡張が無いことにより失効の手立てがなく、 中間CA自体を廃棄するしか手が無かったってことが問題だったわけです。

やべやべ、夜更かししちゃったよ。 ではでは、、、

関連リンク

• threat post 2011.11.03: Malaysian CA Digicert Revokes Certs With Weak Keys, Mozilla Moves to Revoke Trust
• SOPHOS Naked Security 2011.11.03: Another certificate authority issues dangerous certficates
• (マレーシアの)digicert Certification Authority
  • 本件のお知らせ
  • CRLリポジトリ
• 米ユタ州のDigiCert - DigiCert, Inc. Of No Relation to Recent "Digi" Insecure Certificates
• Entrust - Entrust Bulletin on Certificates Issued with Weak 512-bit RSA Keys by Digicert Malaysia
• ITmediaニュース 2011.11.04 SSL認証局問題が再び発覚、MicrosoftとMozillaが対応表明 今度はマレーシアのSSL認証局が発行した証明書に問題が発覚した
• InfoWorld SECURITY CENTRAL 2011.11.04 Mozilla, Microsoft withdraw trust in Digicert certificates

オランダの認証局DigiNotarが攻撃を受け、今わかっているだけで不正なSSLサーバー証明書を531枚 発行してしまった件を、気になってずっとウォッチしています。

いろいろ疑問に思っていることがあり時間があるとき、ここでも紹介していきたいと 思っているんですが、その気になるところの一つにDigiNotar Cyber CAというのがあります。 Torプロジェクトのページで不正に発行された証明書の一覧(531枚)がCSVやExcel形式で ダウンロードできるようになっており、不正な証明書を発行してしまったDigiNotar管理下の 認証局の一覧は

• DigiNotar Cyber CA
• DigiNotar Extended Validation CA★
• DigiNotar Public CA - G2
• DigiNotar Public CA 2025★
• Koninklijke Notariele Beroepsorganisatie CA
• Stichting TTP Infos CA

となっています。「★」印をつけたものは DigiNotarのページから ダウンロードできる中間CA証明書になんですが、 他のものはGoogle等で探してみてもダウンロードすることができませんでした。 被害があった認証局の証明書がDigiNotarのサイトで公開されていないのは 非常に問題だと思っていて、特に DigiNotar Cyber CAは "*.google.com"、"*.skype.com" などの想定被害の大きいSSLサーバー証明書を 発行しているCAなので、CA証明書が無いと対策の打ちようがないと思っていました。 不正に発行された証明書についてOCSPオンライン証明書検証の結果がほとんど有効のまま になっているのでは?と報告している人もいて(OCSPレスポンダ証明書が無効であれば 問題ないわけですが)それを調査するためにもCA証明書が必要になるわけです。

やっとみつけた

DigiNotarのサイトに無いのでちょっとあきらめ気味だったんですが、 FireFox 3.6.22 の証明書ストアを見てみたら以下の信頼するCA証明書がありました。

• DigiNotar Root CA
• DigiNotar Services 1024 CA
• DigiNotar Cyber CA (2枚)
• DigiNotar PKIoverheid CA Orgaisatie - G2
• DigiNotar PKIoverheid CA Overheiden Berdrijven

なんだ、DigiNotar Cyber CAあるじゃないですか、、、それも2枚も。 ぱっと見、ふんふん、名前がちょっと違うルート証明書で有効期間もちょっとだけ違うんだなと 納得しそうになったんです。まぁ、特別な事情があって同じようなルート作ったんだろうなぁ、、、と。

DigiNotar Cyber CA (1枚目)
　発行者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA,Email=info@diginotar.nl
　主体者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA,Email=info@diginotar.nl
　有効期間：2006.10.04-2011.10.04
DigiNotar Cyber CA (2枚目)
　発行者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA
　主体者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA
　有効期間：2006.09.27-2013.09.20

そしたら、あれれ？？？拡張領域あるじゃないですか？？？それも全く同じ値、、、、

発行者鍵識別子：
　A6:0C:1D:9F:61:FF:07:17:B5:BF:38:46:DB:43:30:D5:8E:B0:52:06
　C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions, Inc.,CN=GTE CyberTrust Global Root
　serial:01:A5
主体者鍵識別子：
　AB:F9:68:DF:CF:4A:37:D7:7B:45:8C:5F:72:DE:40:44:C3:65:BB:C2
証明書ポリシ：
　CPS: http://www.public-trust.com/CPS/OmniRoot.html
CRL配布点
　URI:http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl

ってことは、DigiNotar Cyber CAの証明書は2枚とも自己署名ルート証明書ではなくて 主体者名、発行者名が同じなのにGTE CyberTrust Global Rootから 発行された中間CA証明書ってことなんですよね。 CPSやCRLDPの場所もGTEを管理している所のものになっているみたいですしね。

この2枚の証明書がさらに不可解なのはシリアル番号で両方とも(0x0fffffff)で同じ値になっているってことです。CA鍵が同じっていうのもアレですが、同じシリアル番号の異なる証明書をGTE CyberTrustは発行したって事になるわけですよね。普通の認証局なら考えられない話ですし、シリアル番号をあえて同じにする意図もよくわかりません。

さらには、DigiNotar Cyber CA証明書の発行者は同じFireFoxに入っているGTE CyberTrust Global Rootではなくて、Mac OSXには入っていたシリアル番号(0x01A5)の方のGTE CyberTrust Global Root になっているわけです。 どのようなケースでDigiNotar Cyber CAのような移行策が必要だったのか、 そもそもメリットがわからないのよくわかりません。さぞかし大人の事情があったのでしょう。

OCSPの検証結果もまたわからない

2枚のうちどちらが使われているかわからないながらもDigiNotar Cyber CAの証明書は とりあえず入手できたわけです。 DigiNotar Cyber CAから発行されたSSLサーバー証明書が一枚も入手できていないので これがDigiNotarの共通のOCSPレスポンダで検証できるのかはわからないのですが、 ある一つの不正な証明書のシリアルとCyber CAの証明書により検証してみます。 すると2つのCAで別の結果が返ってきて

DigiNotar Cyber CA (1枚目)が発行者だったとした時のOCSP応答：
　malformed-request(1)
DigiNotar Cyber CA (2枚目)が発行者だったとした時のOCSP応答：
　Cert Status: unknown
　This Update: GeneralizedTime "00010101000000Z"
　Next Update: GeneralizedTime "00010101000000Z"

GeneralizedTimeとしてものすごい値が返ってきました。 他にもこのOCSPレスポンダは疑問に思うところが多々あって、 DigiNotar用にカスタムで実装したもののような気がしています。

返ってきた２つの値から、 DigiNotar Cyber CAから発行されたSSLサーバー証明書は OCSP失効検証をサポートしないと考えるのが自然でしょうか。

ちなみにDigiNotar Cyber CAの発行するCRLは？

ちなみにDigiNotar Cyber CAが発行するCRLのURLは1枚目が発行したものは見つかったものの2枚目が発行した方は見つかっていない。CRLの検証では鍵よりもむしろ発行者識別名の方が必要なので、1枚目と2枚目と同じCA鍵であったとしても、そのCRLは1枚目の方にしか使えないですよね。

今日はこんなところで

GTE CyberTrust Global Rootの発行するCRL(追記)

DigiNotar Cyber CA 中間CA証明書はFireFox 3.6.22の信頼する CA証明書リストに入っているのでGTE CyberTrust Global Rootからの 証明書検証をする必要もないですが、DigiNotar Cyber CA証明書には CRL配布点も書いてありますし、 GTE CyberTrust Global Rootは今でもCRLを発行しているので 失効検証はできます。そのCRLをちょっとみてみると、 大体3ヶ月おきに発行されているようで

thisUpdate: 2011.08.31
nextUpdate: 2011.12.03

となっており当然DigiNotar Cyber CAの2枚の証明書のシリアル 0x0fffffffは記載されておらず、DigiNotar Cyber CA証明書が GTE CyberTrustから失効されているということはありませんでした。

GTE CyberTrust Global Rootを信頼点として検証した場合、 結局、識別名のチェーンがつながらないのでパス検証失敗になりますけどね。

更新履歴

• 2011.09.11 - GTE CyberTrustのCRLについて追記

自堕落な技術者の日記 : 続：MD5の商用ルートCAの終焉 - livedoor Blog（ブログ）

う〜〜む、続々荒野の七人みたいなタイトルになってきましたね、、、（　´∀｀）

今回のMD5ニセサブCA問題について幾つか補足しておきます。

EV SSL証明書とMD5ニセサブCA問題

今回の問題のEV SSLサーバー証明書への影響についてCA Browser Forum議長
EntrustのTim MosesはIETFの関連MLに2009年1月1日以下のようにポストしています。

・EV SSLサーバー証明書を発行するCAでMD5を使って証明書に署名するCAは無い
・EV証明書は自動的な手続きにより発行されることは無い

EVのガイドラインではMD5は使えないようになっているので、これは皆さん遵守しているということでよかったです。また、今回のMD5ニセサブCA問題は、自動化された発行プロセスにより1日後のシリアル番号が予見できることに依存しているので、自動発行でないEVはこの問題の影響を受けにくいということになるかと思います。

今回の問題に関する各社の対応

幾つかの認証サービスのサイトを見ていますが、今回の問題について問題や対応の公表をしているところはまだ無いようです。RapidSSLなんかは早めにアナウンスする責任があると思うんですが、、、、

MD5のルートCAだとダメなのか

今回のニセサブCAは、衝突計算に要する時間(1〜2日)後の証明書シリアル番号が自動化された証明書発行プロセス予見されることが必要となるので、全てのMD5をルートCAに影響あるわけではないようです。

また、CA証明書がMD5withRSAであるかどうかは直接は問題なく、MD5withRSAの証明書を発行しているところが問題となるわけですが、ルートCA自己署名証明書がMD5withRSAなら発行する全ての証明書もまたMD5withRSAである場合が多いので「問題の影響有り」ということになるかと思います。

とりあえず、こんなところで、、、、

自堕落な技術者の日記 : MD5の商用ルートCAの終焉 - livedoor Blog（ブログ）

MD5 considered harmful today

前に書いたブログの続編です、、、、

今回はプレゼン資料やサイトの詳細情報などから、今回の問題を解説してみたいと思います。

2008年12月30日にドイツのベルリンで開催された25th Chaos Communication Congress(25C3)というカンファレンスでAlexander Sotirovらの研究グループが2007年に公表されたハッシュアルゴリズムMD5の脆弱性の攻撃方法を利用して商用のMD5withRSAのSSLサーバー証明書を発行しているサービス(RapidSSL、RSA Data Security、VeriSignなど)を利用して任意のHTTPSのサイトを中間者攻撃できることを実証したようです。

問題の詳細は以下のサイトで説明されています。
MD5 considered harmful today
http://www.win.tue.nl/hashclash/rogue-ca/

ニセサブCA作成手順

実証例として紹介されているのはRapidSSLから発行されたSSLサーバ証明書をから信頼されるニセサブCAを作ってしまいほぼ全てのブラウザではデフォルトで信頼されてしまうニセのSSLサーバー証明書をいくらでも発行できるサブCAを作ってしまっています
。

EquifaxルートCAは、現在GlobalSignなどにも一部移管されているようですが、デモで用いたのはRapidSSLのEquifax Secure eBusiness CA-1というルートCAを利用しています。RapidSSLのサービスは2005年3月まではFreeSSLというサービス名でした。(参考)。RapidSSLはGeoTrust Inc.の低価格ブランドのSSL証明書サービスでしたが、2006年5月にGeoTrust Inc.がVeriSign Inc.に買収されています。

さて、手順はこんな感じ、、、、

(1) RapidSSLのサービスは
　　Equifax Secure eBusiness CA-1 (RootCA) → 利用者SSLサーバー証明書
　　の直接信頼モデルになっています。
　　発行するSSL証明書はMD5withRSAで署名されており、
　　シリアル番号は連続番号になっており予測可能です。
(2) まず、SSLサーバー証明書をフツーに発行してもらい現状のシリアル番号を確認します。
(3) MD5ハッシュ衝突の脆弱性を突いて必要なSSLサーバー証明書(=ニセサブCA)の
　　tbsCertificateの部分(証明書の署名アルゴリズムと署名値を除く
　　部分)と実際に送信する証明書発行要求を計算します。要件は以下の通り。
　　【ニセサブCA側】
　　・シリアル番号は予想値を使う(計算に1日かかるならシリアルは何番？)
　　　計算に要する時間(1〜2日)との兼ね合いになる。
　　・識別名は本物のサブCAっぽいと良い
　　・元はSSLサーバー証明書(エンドエンティティ証明書)だが
　　　ニセサブCAが欲しいのでbasicConstraint拡張はcA=TRUE
　　・CRLDP、AIAなど失効情報を提供する拡張はあえて入れない
　　　ことで、多くのブラウザは失効検証しないので
　　　ニセサブCAは失効をチェックされることは無くなり長く使える。
　　・ハッシュ値の調整(衝突ビット)にはNetscapeComment拡張など検証処理には
　　　使われないものを使う。2007年に公表されたMD5のchosen-prefix collision
　　　(指定された先頭値による衝突)攻撃を使いハッシュ値が一致するように
　　　計算する。
(4) 生成したtbsCertificateと対になる実際に送る用の証明書発行要求(CSR)を
　　約1日後そのシリアル番号のものが出そうな時刻に連続して、
　　目的のシリアル番号の証明書が発行されるまで発行要求を続ける。
(5) 発行された目的のシリアル番号のエンドエンティティ用の
　　フツーのSSLサーバー証明書から証明書から署名値部分を切り出して
　　(3)で作っておいたニセサブCA用のtbsCertificate部分と組み合わせて
　　ニセサブCA証明書を作る。(4)の時に生成された対応する秘密鍵と
　　組み合わせてニセサブCA作成は完了。これで何枚でも既存のどんな
　　ホストであろうが信頼されてしまうニセサーバー証明書は発行できる。

この(3)の別原像を探す計算に要する時間は、以下の環境でおよそ1〜2日だそうです。
(a) プレステ3が200台構成のクラスタ
(b) デスクトップPCが8000 CPUコアのクラスタ
(c) Amazon Elastic Compute Cloud (EC2) 20,000米ドル分

デスクトップよりもプレステ3がこんなにもスゴイって事にびっくりしました。デュアルコアのデスクトップ4000台を個人で準備するのは無理ですが、プレステ3なら知り合いをかき集めれば200台集められるなんて人もいるんじゃないでしょうか。

EC2の環境は最初の準備が大変だそうですが、実機で数百〜数千台準備するよりもお手軽ですし値段も大したこと無いですよね。ニセサブCAさえ作れれば何枚でもSSLサーバー証明書を出せるのでたった200万円は安いかも。別の最適化を使えば20万円でもいけそうだということです。RapidSSLには無償再発行の分もあったりするので、目的のニセサブCAを得るためにRapidSSLに払ったのは7万円弱なんだそうです。

デモサイト

カンファレンスではデモ用無線LAN環境を提供して、そこから全てのHTTPSサイトに接続してもすべて中間者攻撃され通信は盗聴されているというデモを行った模様です。

Alexander Sotirovのサイト(http://www.phreedom.org/research/rogue-ca/)では、Rapid SSLから発行されるはずのSSLサーバー証明書を全てのブラウザが信頼してしまうニセサブ証明書にしてしまい、そこからニセのSSLサーバー証明書を発行しています。

デモサイトのURLはこれです。
https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/
この鍵が本当の不正に使えないようにあえてニセサブCA証明書やニセSSLサーバー証明書を2004年7月31日〜9月1日の有効期限に設定しているそうです。例えばPCの時計を2004年8月15日に設定して接続してみますと





のようにブラウザは信頼してしまう正しい証明書をニセのサブCA(MD5 Collisions Inc.)が発行しています。





現在時刻でやったら期限切れですと出ます。

IEやFirefox、ケータイなどほとんど全てのブラウザで信頼されてしまうニセのサブCAが作れてしまったので、信頼される不正なSSLサーバー証明書をどんなホスト名に対しても発行できてしまいます。

攻撃方法の詳細の公開について

この問題の対象となっている認証サービス（やブラウザ？）が対策を講じるまでは、この攻撃方法の詳細は論文公表しないそうで、数ヶ月の猶予はあると述べています。既に認証サービスと研究グループは調整を行っているそうです。

実際の盗聴などの中間者攻撃のために

以上の方法で信頼されてしまう不正なサブCAとSSLサーバー証明書を入手できますが、これを盗聴などの中間者攻撃に用いるには、DNSスプーフィングなどホスト名とIPを騙す必要があります。安全でない無線LANアクセスポイントやルーターなどもリスクとなります。

紹介された対応策について

カンファレンスのスライドでは主要な対応策として
・シリアル番号を乱数にし予測不能にする
・証明書発行要求の処理時間をランダムな長さとする
・ローカルOCSPをたて、不正サブCAのブラックリストを見るようにする
などが紹介されいていました。

せきゅめもさんとこでは「MD5」を使ったら弾くようなことを書いてありましたが、これは私も賛成です。ブラウザの設定でTLVv1、SSLv3など選択できるようなものがありますが、同様にMD5を使わない、将来的にはSHA1を使わない、警告を出すなどの設定があると良いかなと思います。

あと、今回の不正サブCAを作る方法では証明書チェーンの段数が一段増えることになるので、ルートCAのpathLenConstraintにより最大の段数の制限することとし、ブラウザの検証もこれをチェックするようになると良いかなと思います。

う〜〜ん、眠い、、、、今日はこの辺で、、、、、、

参考：
セキュリティホールmemo: MD5 considered harmful today: Creating a rogue CA certificate(win.tue.nl, 2008.12.30)
TechCrunch:MD5コリジョンでインチキ認証局は作れる（ネットにとっては悪い報せ)

MD5 considered harmful today

昨日、2008年12月30日、MD5の脆弱性をついてMD5ベースの商用ルートCAを使って信頼されてしまうニセCAを作れちゃったというものらしいです。NIST SHA3コンペのMLやIETFのS/MIME、PKIXのMLに以下のメールが流されました。

Russ Housleyのメール
From: Russ Housley
Subject:Further MD5 breaks: Creating a rogue CA certificate
Date: 2008.12.31 01:05

http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today
Creating a rogue CA certificate

December 30, 2008

Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key
Infrastructure (PKI) used to issue digital certificates for secure
websites. As a proof of concept we executed a practical attack
scenario and successfully created a rogue Certification Authority
(CA) certificate trusted by all common web browsers. This certificate
allows us to impersonate any website on the Internet, including
banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic
hash function that allows the construction of different messages with
the same MD5 hash. This is known as an MD5 "collision". Previous work
on MD5 collisions between 2004 and 2007 showed that the use of this
hash function in digital signatures can lead to theoretical attack
scenarios. Our current work proves that at least one attack scenario
can be exploited in practice, thus exposing the security
infrastructure of the web to realistic threats.

年末にちょっとビックニュースですね。とうとう、こんな時が来ましたか、、、
これから、サイトや論文読んでみます。

以下の商用CAがMD5のルート証明書を出しているようです。

- RapidSSL
- FreeSSL
- RSA Data Security
- Thawte
- VeriSign

＜追記＞
よく読んでみるとルートがMD5であることでなく、MD5(withRSA)で署名された証明書を発行しているCAが問題なんですね。まとめは、別途書きます。

gnoMintを使って独自の認証機関を設定する - SourceForge.JP Magazine

2008年10月03日 09:03AM

　gnoMintは、独自の認証機関（CA）を簡単に管理できるデスクトップ・アプリケーションだ。多くのセキュア通信テクノロジは、接続先の団体やサービスが成りすましではないことを確認するためにデジタル証明書を使用する。ほとんどの人にとってデジタル証明書を目にするのは、HTTPS Webサイトを開いて、正しいWebサーバに接続したことを検証するために証明書が提示されたときである。

ほほぅ、gnoMintとな、、、、時間があるとき試してみたいのでメモメモ、、、、

CA/Browser Forum - PKI Client Workshop

2008年12月3日にスペインの最北方バスク地方ビルバオでEV SSLサーバー証明書などの仕様を策定しているCA Browser Forumのワークショップがあるそうだ、、、、、

次回のETSI ESIといい、何故にビルバオ？！（　´∀｀）
ねぇ、おせ〜〜〜て

NAREGI Middleware V1 Download Site

2008年6月にオープンソースの認証局ソフトウェアであるNAREGI-CAの新しいバージョン2.2.4がリリースされていました。NAREGI-CAは名古屋工業大学のAiCrypto・AiCAをベースに開発されているわけですが、今後 SHA2 対応はどのようになるのか気になるところです、、、、