自堕落な技術者の日記

Amazon AWSのELBとCloudFrontで使えるらしい、無料の証明書発行サービスで、AWS Certificate Manager(ACM)というのがあるそうです。([参考1])。ちょっと気になったきっかけはJavaからHTTPSで繋ぐと検証失敗するケースがあった

はてブを垂れ流すだけのフレンズ@matsuu

ん？これJRE同梱のルート証明書にACMのルート証明書が含まれてなかったってことか。どのバージョンから対応してるんだろ。決済連携などで決済会社の環境が古くてACMが使えないパターンありそう。 / “JavaクライアントからAWS…” https://t.co/pf9J6QRSTD

2017/04/30 11:57:07

というので、ちょっと見始めたらドツボにはまったので、少しメモを書き残しておこうかとおもいます。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Javaで繋がらないとなると、ルート証明書や中間CA証明書が入ってないんだろうと疑ってみるとおもいます。 とりあえず、ブラウザで繋いだりしてみました。Windows 7のChromeやIEだとこんなパス。

Mac OS X(や多分iOSも)だとSafariでもChromeだとこんなパス。

FirefoxだとOSによらず、WindowsでもMac OS Xでもこんなパス。

クライアント毎に使われている信頼するルート証明書が違うようです。 Starfieldルートになっているケースもありますね。 調べてみると、AmazonはGoDaddyからStarfieldルート認証局を一つ買ったのだそうです。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Amazonの証明書発行サービスはAmazon Trust Servicesというのだそうで、 証明書ポリシ、認証実施規程などの文書、ルート証明書、中間CA証明書などが置いてある リポジトリはこちらにあるようです。

リポジトリをよく見てみると、クロス証明書(片方向相互認証証明書、中間CA証明書)の リストがあるんですが、ハッシュと証明書のリンクが張ってあるだけで、大した説明もなく えらく不親切なページですよね。 認証局の構成がよくわからなかったので、これを元に図にしたのがコレです。(かなりの力作だとおもいます。)

なんかCAの鍵使いまわしてないですか？

このクロス証明書のリストで気になったのが、各Amazon Root 1〜4に対して、origとそうじゃないやつ、Starfieldに関してはv2とそうじゃないやつがある所です。 例えば、Amazon Root 1のorigとそうじゃないやつを比較してみると 以下の3点が違うだけで、

• シリアル番号が違う
• notBeforeが違う(origが2015年10月で、orig無しが2015年5月)
• authorityInfoAccess拡張のcaIssuerのURLが少し違う。 http://{crl,crt}.rootg2.amazontrust.com/rootg2.cer となっている。origがcrlで、origなしがcrt。

とほとんど同じで、caIssuerを直したいだけのつまらない理由のために、中間CA証明書を再発行したようです。 これって中間CAの鍵を使いまわしてますよね。マズくないんですかね？ さらに問題なのは、

• どちらが正しい証明書なのかわからない。
• ファイル名からはorigが古いように見えるが、 notBefore的には逆にorigが新しいようにも見える。
• どちらか一方を失効しているわけでもなく、どちらも有効。
• パス検証としてはどちらを使っても検証成功となるが、そんな事でいいのか？
• 将来、{crl,crt}.rootg2.amazontrust.comのいずれかを無くす計画があると思うが、 それが明らかになっていない。

といった所です。 ちなみに、caIssuerに記載されたURLは、今の所はどちらもアクセス可能なようです。 両方にアクセスできるなら、なおさら中間CA証明書再発行の必要があったんですかねぇ？ 単に、DNSの別名、CNAMEレコードの設定だけの問題なんじゃないですかねぇ。 また、本当はどちらに寄せたいと思っているのかも明らかにされてませんよねぇ。

同様に、Starfield Class 2 CAからStarfield Services Root CA G2に発行している 中間CA証明書も怪しくて、シリアル番号とnetBeforeだけが違う証明書があります。 どちらも失効していません。 こんなことして大丈夫なんですかねぇ？ 最近、Certificate Transparency(CT)でSSLサーバー証明書全ての発行履歴残されており、 (私は最初はCTは嫌いだったのですが、) 認証局が問題あると、 (シマンテックのように、、、、) いろんな人が指摘してくれます。 中間CA証明書の発行についても、CTログに残しておかないと、 ヤバイ運用があるんじゃないかなぁ、、、、と思います。

Amazonの認証局はWebTrust認定もしており、Ernst Youngが監査しているそうですが、 こんなんで本当に大丈夫なんですかね？

Java 8?のcacertsのaliasについて

Amazon AWSやACMとは全く無関係ですが、最近自分は、Javaはめっきり触らなくなってしまい、今回の件でかなり苦労しました。Javaの信頼する認証局のためのキーストアファイルであるjre/lib/security/cacertsファイルなんですが、中のファイルを取り出そうとすると、そんなファイルは無いと怒られてしまいました。 よく見ると使ってみた新しい8u121では、aliasはこのようになっており、

% keytool -list -keystore jre/lib/security/cacerts
　　：中略
globalsigneccrootcar5 [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46:
3A:1B:69:AA
starfieldservicesrootg2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:
E8:25:6F:3F
ttelesecglobalrootclass2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:
17:D8:94:E9
addtrustqualifiedca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:
C5:4D:8B:CF
　　：後略

例えば「starfieldservicesg2ca」だけではだめで、表示されている通り「starfieldservicesg2ca [JDK]」のようにちゃんと[JDK]までつけないといけなくなったのだそうです。知らなかったし、ハマりました。

GWなもんで、今日はこんなとこで。

参考リンク

A look at AWS Certificate Manager

ACMを使い始めるときに参考になる。ACMを使ったサイト。

Free SSL With Amazon’s AWS Certificate Manager (ACM)

ACMを使い始めるときに参考になる。(その2)

ACM FAQ

公式サイトのFAQ

昨日書いたマレーシアの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について追記

Adobe Acrobatで使うと便利な証明書とタイムスタンプサービスのセットである Adobe CDSに関する前回の記事を書いてから半年すこし立ちましたが、それまで5つあった証明書発行サービスがもう一つ増えて6つになっていました。 今日はちょっと補足情報を書いてみようと思います。

Adobe CDSサービスの価格比較

Adobe CDS対応の証明書発行サービスには、個人向けと企業(組織)向けがありまして、 発行サービスによって署名可能回数が無制限のものや回数制限を設けているものがあります。 以前、自腹で証明書買おうと思って、最初にあった国内1社を含む6社で価格を比較したメモを作っていました。 これに、新たに加わった1社を入れて表にまとめてみました。

結構価格差ありますよね。購入の際の参考にしてみてください。 個人的には署名回数に制限無いものの方が、心置きなくテストで使えるのでいいかなとも思うんですが、 たまにしか使わない個人の人ならTC TrustCenterの500署名2万円弱/年っていうのでも十分なのかもしれません。

署名回数制限の方法について想像してみる

証明書発行サービスによっては署名回数に上限を設けて価格設定している所があります。この署名回数の制限をどのように行うのか、上限を超えると本当にできなくなるのか、単なる紳士協定なのか、システムエラーなどで失敗した場合に回数のカウントはどうなるのかずっと疑問に思っていました。以下のようなこともあって署名回数のカウント方法がよくわからなかったのです。

• USBトークン自体には秘密鍵を使用する回数に制限を設けられているといった話を聞いたことがない。
• Adobe CDSで使用するタイムスタンプサービスはどこも認証無であるし、Adobe Acrobatで タイムスタンプサービスの認証設定の画面などは無い。

署名回数制限があるサービスの中で、タイムスタンプ署名の回数として制限をしているところがありました。Adobe CDS署名に使われた証明書にはスタンプサービスのURLが拡張領域に書かれていますがそれを見てみると

http://TSPのホスト/TSPアプリ/乱数のような長い値

となっていました。おそらくこのURL中の乱数のような長い値を以てユーザの認証をしているのかな、と思いました。

タイムスタンプURLによる認証の問題

タイムスタンプ要求の差異のURLへのアクセスにより認証していて、その回数がAdobe CDSの署名回数と同等だったとすると少し困った問題が起きると思います。

• タイムスタンプ付き署名されたPDF文書はコピーされて不特定多数に渡ったりするので、渡した先は必ずしも悪い事をしない人とは限りません。
• Adobe CDSのPDF署名文書から、この署名に利用したタイムスタンプサービスのURLは誰でも知る事ができます。署名者の証明書に記載されています。
• 記載されているタイムスタンプサービスは特にIDパスワードなどの認証も無いので、URLさえ知っていればアクセスすることができます。接続元IPなどを制限している風でもありません。
• すると、Adobe CDS署名されたPDF文書を受け取った誰か意地悪な人が何人かいたとして、署名に回数制限があるサービスだったとすると、そのURL誰かが何回もアクセスして、Adobe CDSの証明書を持っている人(サブスクライバ)の残り署名可能回数を0にしてしまう事ができるかもしれません。

どんな運用になってるのかは、開示されている情報も無いのでよくわかりませんが、実際のところどうなんでしょうね。自分のやつは回数制限の無いタイプにしたので、とりあえずこんな不安は無くて良かったなぁと思います。

ではでは、今朝はこんなところで。

関連記事

• 2009.11.15 AcrobatのAdobe CDSについて書いてみる
• 2009.11.22 dumpasn1用のAdobe CDS関連の設定の追加

自堕落な技術者の日記 : 続：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が問題なんですね。まとめは、別途書きます。

スラッシュドット・ジャパン | Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に

本家のストーリにもなっているが、認証局として知られる「Comodo」のアウトソース先の証明書販売業者が、mozilla.com用のサーバ証明書を関係のない第三者に発行してしまう事件が発生したようだ（eWeekの記事「SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy」、mozilla.dev.tech.cryptoグループに掲載されている事件の経緯）。

、、、だそうです、、、、

Comodoのリセラーからのスパムが煩いので取ってみたら審査も無しに取れちゃったということみたいですね。

これは、いけません。

随分前にちょっと調べて放置プレイになっていたヤツを少し整理みようと思います。

・Microsoft Windows 95 OSR2 4.00.950 B
・Internet Explorer 4.0 4.72.2016.9

という古ぅ〜〜い、古典的な環境に含まれる信頼されるルート認証機関(30認証局)を調査し表にしてみました。いや〜〜、Windows 95の環境を手に入れるのが結構骨で、当時は信頼するルートもフォルダにKey blob形式のファイルがぽっとおいてあるだけだったので、Key blobから証明書をひっこぬくプログラムも合わせて作ったんだと思います、確か、、、

まとめた表は以下のようになります。





気がついたのはこんなとこ、、、、

• 未だに有効期限がある認証局がある


• 未だ有効なものでWindwos XPに現在も含まれるものと、
  そうでないものがある


• 署名アルゴリズムはmd2WithRSAもしくはmd5WithRSAである


• 鍵長がRSA 1000bitの鍵を使っているものがある


• X.509証明書のバージョンがV1のものと拡張領域を持つV3がある


• 基本制約を持たないX.509 V3証明書がある


• CN(commonName)を拡張領域に持つ証明書がある


• 認証局の主体者DNにEmailAddressを持つ証明書がある


• 当時30認証局だったものが今は130認証局近くになっている

1997年頃当時の面影を知ることができ、なかなか良かったです。ハイ。

こういう情報はちゃんと国会図書館とか公文書館とかデジタルアーカイビングして公開したらいいんじゃないかと思うんですけどね、、、、長期保存では過去のトラストアンカの情報が必要になるので、、、、、、