自堕落な技術者の日記

OCSPによる失効検証は、先日のApple macOS Big Burrのソフトウェアコード署名の大量の検証で、OCSPレスポンダ高負荷による失効検証の障害が出たのではと推測されるように、通信障害、サーバー障害などでOCSP応答が取れないなどのことがあって、最近非常に評判が悪いです。そのため、ウェブブラウザの世界では、Chromeでは CRLSet、Firefox ではCRLiteという別の失効検証方法を使おうとしているそうです。ChromeのCRLSetについては2013年2月に、CRLSetで本当に大丈夫なんだろうかと思い「将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話」というブログエントリを書かせていただきました。(が、その後、Chrome CRLSetがどうなっているのかよくわかっていません。)

で、Firefox CRLiteについてですが、 先日、「Querying CRLite for WebPKI Revocations」(2020.11.26)という記事が公開されました。Firefox Nightly バージョンで実装されているCRLite失効検証の機能を確認するためのPythonのツール moz_crlite_query が合わせて公開されています。Firefox Nightly 85.0 で実装されているということなので、2021年1月26日リリース予定のFirefox 85正式版ではCRLite失効検証が使われているということなのでしょう。(間違っていたらごめんなさい。) おお、FirefoxのCRLiteがいよいよ実運用されるんだなぁ、、、とwktkしながら、今日はこの moz_crlite_query を試してみたいと思います。

インストール

Python 3.7 以上の環境で

% pip install moz_crlite_query

とすればインストールすることができます。依存するPythonモジュールをビルドするのにgcc、g++が必要になるみたいです。

私のMac Book Airは古くから使っていてPython環境が汚れていて、OSで提供されるPython2.7、Python3?、macportsのPython2、Python3などあり、切り替えがうまくいかず、インストールでとてもハマりました。 古いPython setuptoolsだと、2.7等、バージョンが古くてもインストールエラーにならないようで、これでハマりました。 最初からpyenv使っときゃよかったんだよなぁ、、、。pyenvでPython 3.9を入れ直して、Windows 10 WSL2でインストールしたmoz_crlite_queryスクリプトをコピーし戻してやっと動くようになりました。pyenvでインストールしたときmoz_crlite_queryスクリプトはどこにインストールされるんだ？？？

Windows 10 WSL2のUbuntuに入れるのは、それほど大変ではありませんでした。aptコマンドで足りてなかった、gcc、g++、python3-devを入れてpipでインストールできました。

サイトで紹介されてる実行例は、いちいちPEM証明書ファイル持ってきてますが、「moz_crlite_query --hosts 調べたいTLSサイトFQDN」で調べられます。例えばMacでwww.nist.govを調べればこんな感じ、

Windows WSLでec.europa.euを調べればこんな感じで実行できます。

(絵文字使うんじゃね〜〜！！！)
PEM証明書を指定して「moz_crlite_query PEM証明書ファイル」でも調べることができます。

で、ちょっと見てみるぞ、と

CRLiteのデータベースは一日に4回更新して配布されるそうで、moz_crlite_queryコマンドは、データベースを確認して新しいのがあれば~/.crlite_dbにデータベース一式をダウンロードして使用します。ファイルの一覧はこんな感じ。

2020-11-24T00:08:12+00:00Z-full		2020-11-26T18:08:13+00:00Z-diff
2020-11-24T06:08:12+00:00Z-diff		2020-11-27T00:08:16+00:00Z-diff
2020-11-24T12:08:14+00:00Z-diff		2020-11-27T06:08:13+00:00Z-diff
2020-11-24T18:08:15+00:00Z-diff		2020-11-27T12:08:20+00:00Z-diff
2020-11-25T00:08:23+00:00Z-diff		2020-11-27T18:08:11+00:00Z-diff
2020-11-25T06:08:05+00:00Z-diff		2020-11-28T00:08:14+00:00Z-diff
2020-11-25T12:08:22+00:00Z-diff		2020-11-28T06:08:12+00:00Z-diff
2020-11-25T18:08:11+00:00Z-diff		2020-11-28T12:08:12+00:00Z-diff
2020-11-26T00:08:11+00:00Z-diff		2020-11-28T18:08:21+00:00Z-diff
2020-11-26T06:08:17+00:00Z-diff		intermediates.sqlite
2020-11-26T12:08:14+00:00Z-diff

コマンドを実行すると表示されている通り、2457のパブリックな中間CAが登録されているようで、FAQでは「すべてのCA」とか言っちゃってますが、そういうわけではなさそう。エンドエンティティがSSLサーバー証明書を発行しているような中間CAは概ね登録されているようですが、SSLサーバー証明書発行用でないCAや、中間CA証明書の検証に使うCAは登録されていないようです。登録されてない中間CAに対してクエリをかけると「Enrolled in CRLite: ✕」のように表示され登録されてないことがわかります。(絵文字ヤメロw)

「intermediates.sqlite」が中間CAのSQLiteデータベースになっており、中にはテーブルは一つしかなく、こんな感じでスキーマ定義されています。なんとなく想像つきますね。

CREATE TABLE intermediates (
  id TEXT PRIMARY KEY,
  last_modified TEXT,
  subject TEXT,
  subjectDN BLOB,
  derHash BLOB,
  pubKeyHash BLOB,
  crlite_enrolled BOOLEAN, -- crlite_enrolled = FALSEな中間CAは1656なので、対応してるのは801 CA?
  whitelist BOOLEAN); -- whitelist = TRUEな中間CAは登録されてなかった

とまぁ、こんな感じなんですが、CRLSetのときに書いた疑問は払拭されず、本当に信用できるのかモヤモヤしますね〜〜〜。なんかヤベーーーの見つけちゃった気もするし。ブラウザでどう使われているのか見ないと何ともいえないですが、、、、

今日はこんなとこで。環境も汚れてきたしバッテリーも酷い状況なのでM1 Mac Book Air買うかなぁ、、、

毎年恒例、日本ネットワークセキュリティ協会(JNSA)の主催セミナー PKI Day 2015「サイバーセキュリティの要となるPKIを見直す」に出させて頂きます。

http://www.jnsa.org/seminar/pki-day/2015/index.html

私は第2部の「SSL/TLS実装の今とこれから」で

• 「SSL/TLS生誕20年、脆弱性と対策を振返る」
• パネル：「SSL/TLSの実装が進むべき道を語ろう」

でお話をさせて頂きます。会場は「ヒューリックカンファレンス秋葉原」とありますが、浅草橋駅なのだそうです。 無料セミナーですので、よかったらお気軽に参加ください。

個人的には米丸先生の電子署名法の話と、小谷さんの自動車のPKIの話がとても気になります。JNSAさんから転送自由と書いてあったパートを載せておきます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　　  ＜JNSA PKI相互運用技術WG・電子署名WG主催セミナー＞
　　 PKI Day 2015「サイバーセキュリティの要となるPKIを見直す」
　　　　　　 http://www.jnsa.org/seminar/pki-day/2015/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 日　時： 2015年4月10日（金）9時30分〜17時40分（受付開始9時10分）

■ 場　所： ヒューリックカンファレンス秋葉原 ROOM 1
　　　　　 （東京都台東区浅草橋1丁目22-16 ヒューリック浅草橋ビル3F）
　　　　　　http://www.hulic-hall.com/access/

■ 主　催： NPO日本ネットワークセキュリティ協会（JNSA）
　　　　　　PKI相互運用技術WG・電子署名WG

■ 定　員： 132名

■ 料　金： 無料

■ 申　込： 下記URLページ文末の申込フォームよりお申し込みください。
　　　　　 　http://www.jnsa.org/seminar/pki-day/2015/

■ 講演資料:
　講演資料は上記URLよりPDFにて事前公開いたします。
　当日は講演資料の配布はいたしませんので、参加される方はご自身で
　ダウンロードいただき、当日お持ち下さいますようお願いいたします。

■ 開催趣旨：
　今日、サイバー空間におけるセキュリティの確保や信頼関係の構築にPKIは
　欠かせない技術になっています。また、サイバー空間の広がりとともに、
　IoT/M2M等の新しいPKIの応用領域も期待されています。
　その一方、社会基盤としてのPKIは、制度的な課題や、更には実装や展開等
　において様々な課題も浮上しています。
　PKI Day 2015では、以上のことを踏まえ、「サイバーセキュリティの要となる
　PKIを見直す」をテーマに、今後の社会におけるPKIの在り方を議論します。

  　              ■■■ プログラム ■■■

9:30-9:40
【ご挨拶】「PKI day 2015のオーバビュー」
　　セコム株式会社 IS研究所／PKI相互運用技術WGリーダー　松本 泰 氏

9:40-10:25
【基調講演】「サイバーセキュリティの状況とPKIの取組み」
　　　　　　　講師：東京工科大学 教授　手塚 悟 氏

◆第1部　新しい時代の電子署名◆

10:30-10:35
【第1部のプログラム紹介】
　　三菱電機株式会社 情報技術総合研究所　宮崎 一哉 氏

10:35-11:15
【講　演】「欧州の動向-電子署名指令からeIDAS規則へ」
　　　　　　講師：株式会社コスモス・コーポレイション　濱口 総志 氏

11:15-11:50
【講　演】「トラストリストと信頼のグローバル化」
　　　　　　講師：セイコーソリューションズ株式会社　村尾 進一 氏

11:50-12:30
【講　演】「電子署名法改正のポイント」
　　　　　　講師：神戸大学大学院法学研究科・法学部　教授　米丸 恒治 氏

　             ＝＝＝　昼休み （12:30-13:30)　＝＝＝

◆第2部　SSL/TLS実装の今とこれから◆

13:30-13:40
【第2部のプログラム紹介】
　　セコム株式会社 IS研究所　島岡 政基 氏

13:40-14:15
【講　演】「SSL/TLS生誕20年、脆弱性と対策を振返る」
　　　　　　講師：富士ゼロックス株式会社　漆嶌 賢二 氏, CISSP

14:20-14:55
【講　演】「Windows, Internet Explorerのセキュリティのいま」
　　　　　　講師：日本マイクロソフト セキュリティプログラムマネージャー　村木 由梨香 氏

15:00-15:30
【パネルディスカション】 「SSL/TLSの実装が進むべき道を語ろう」
　モデレータ： セコム株式会社 IS研究所　島岡 政基 氏
　パネリスト： 富士ゼロックス株式会社　漆嶌 賢二 氏, CISSP
　　　　　　　 日本マイクロソフト セキュリティプログラムマネージャー　村木 由梨香 氏

◆第3部　広がるサイバー空間に対応するPKIの新しい応用領域◆

15:50-16:00
【第3部のプログラム紹介】
　　セコム株式会社 IS研究所／PKI相互運用技術WGリーダー　松本 泰 氏

16:00-16:45
【講　演】「RPKIの技術課題と信頼構造」
　　　　　　講師：一般社団法人日本ネットワークインフォメーションセンター（JPNIC）技術部
　　　　 　　　　 インターネット基盤企画部 セキュリティ事業担当　木村 泰司 氏

16:50-17:40
【講　演】「PKIの新しい活躍の場=繋がる自動車。そこで生まれる恩恵と脅威、それらへの方策」
　　　　　　− PC/サーバでの10年のセキュリティ経験を踏まえた提案、標準化活動 −
　　　　　　講師：富士通研究所 R&D戦略本部IPR戦略室シニアエキスパート、博士（工学）、
　　　　　　　　　TCG理事　小谷　誠剛　氏


（※）予告無く講演内容が変更される場合がございます。予めご了承下さい

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

@raysato さんのTLを見ていたらTwitter社の人のブログを紹介していて、以下のようなエントリがありました。

REST API SSL certificate updates
https://dev.twitter.com/blog/rest-api-ssl-certificate-updates

TwitterはAPI用の証明書を切り替えるそうです。

まじかー。api.twitter.comの証明書を見てみると、 確かに有効期限が2013年12月31日までになっとるなー。

でもapi.twitter.comの証明書はちゃんとRSA 2048bit だからいいじゃんと思って 見てみたら、なるほどルートCA RSA 1024bit X.509v1証明書なんだね。そりゃだめだ。

認証サービスの共通ルールを作っているCA Browser Forumのガイド 「Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.5」というのが 出ていて

2013-12-31
CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor.

とあります。RSA 2048bit未満のCAは使えなくなっちゃうんだなぁと。

やべやべ、明日の資料を作らないと。

このブログのコメント欄でなひ様に教えてもらった

CodeFromThe70s.org
SSL BLACKLIST 4.0 Firefoxアドオン
SSL BLACKLIST Local Databse Firefoxアドオン
http://codefromthe70s.org/sslblacklist.aspx

を早速インストールしてみました。

これは、以前ブログでも何回か書いたDebianが生成したOpenSSH,OpenSSL鍵の危殆化問題に対応して、やばい鍵に警告ダイアログを出してくれることを主目的としたプラグインなようですが、MD5withほにゃららの証明書をHTTPSで使おうとした場合にも対応しているようです。

とりあえずの自衛策としてはいいんじゃないでしょうか。






＃なんか、間違い探しみたいですか？！（＾＾；（謎）

警告ダイアログっぽくないですね、、、赤・黄色・黒なんか使ってババ〜〜ンとやってほしかったです。

ちなみに、ステータスバーは問題無い証明書だとこんな感じ、、、、




MD5証明書だとこんな感じの警告が出ます。

カンファレンスでMD5ハッシュ衝突を用いたサブCAの偽造が発表されて、わずか数時間でRapidSSLサービスを提供している米VeriSign社はすぐにMD5withRSAのSSLサーバー証明書を発行することを止やめる対応をとりました。この米VeriSignの迅速な対応は私もすばらしいと思います。

日本ベリサインやグローバルサインでもMD5問題の報告をしています。

• 日本ベリサインのグローバル・サーバーIDでは現在、証明書発行を停止しており1月15日よりSHA1withRSAに切り替えて再開する。


• 既存のMD5withRSAのSSLサーバー証明書のオーナーには影響が無い。

と書いてあります、

米VeriSignのTom氏のブログは1月2日に読んだんですが、

米VeriSign Tim Callan氏のブログ(2008.12.30)より
Q: How many certificates are affected?
A: Zero. No end entity certificates are affected by this attack. The attack, when it worked, was a potential method for a criminal to create a new, false certificate from scratch. Existing certificates are not targets for this attack.

日本ベリサインの重要お知らせ(2009年1月6日)より
※尚、この攻撃は、既に発行されたサーバIDを利用した通信の「改ざん」「盗聴」などを可能にするものではありません。お客様のWebサイトにて現在ご利用いただいているグローバル・サーバIDおよびその他全てのサーバIDについて新たなリスクを生じさせるものではございません。

この「既存のMD5withRSAのSSLサーバー証明書のオーナーには影響が無い」ということですが、個人的には果たして本当にそうなのかと考えています。

新規に発行されるSSLサーバー証明書(の署名)はSHA1withRSAになったため偽サブCAは作れなくなりましたが、既存のRapidSSLなどMD5withRSAのSSLサーバー証明書(と私有鍵)のオーナーは、Sotirov氏らの研究成果があればいつでも、現時点で有効な偽サブCAを作れると思います。

研究では新規SSL証明書から偽サブCAを作ろうとしたために、シリアル番号の予見とか衝突計算時間が1日ぐらいといった制約があったわけですが、既存のMD5withRSA証明書と秘密鍵さえあれば多少ゆっくり数ヶ月とか時間がかかったとしても信頼されてしまう偽サブCA証明書は作れるのではと思います。この際、RapidSSLのSSLサーバー証明書の私有鍵がRSA 2048ビット以上であることが必要になると思うんですが(後日解説)そんなRapidSSLのMD5withRSA SSLサーバー証明書と鍵を持ち、研究成果さえ適用できれば可能なのかなと思います。失効していようが、期限切れだろうがかまわないわけです。期限切れになったSSLサーバー証明書と秘密鍵の組が不正利用のための価値を持つデータということになります。

すると、まさかSotirov氏らの研究グループはしないでしょうけど、彼らが安全だと判断して方法を公開してしまった後、公表された手法を用いて数ヶ月後からでもゆっくりと偽サブCAをつくりはじめればよいいことになります。

シリアル番号も、発行されたSSL証明書と、それから作った偽サブCA証明書では、あまり関係が無いように作れるようなので、今後出てくるかもしれない今後何年とかルートが有効である間は有効なこの偽サブCAは失効させることはできません。(いたちごっこです)。ちなみに Equifax Secure Global eBusiness CA-1 のCRLには今回のデモで作った偽サブCAのシリアル番号(0x41)は(まぁ期限切れなのですが)CRLに入っていません。(2009.01.07時点)

既に発行してしまったMD5withRSAのSSLサーバー証明書にも、今後のSHA1withRSAの証明書にも影響無いとしていますが、そうではありません。RapidSSLのサービスを利用しているかどうかに関わらず、どこのSSLサーバー証明書を使っていたとしても等しくSSL中間者攻撃の被害の可能性があるということです。

私はこの問題を解決するには、やはり、

・Windows UpdateやFireFox Updateなどで、信頼するルート証明書ストアからMD5withRSAのルートCA、少なくともEquifaxのルートは削除する)
・ルートCA・サブCAとウェブブラウザが基本拡張(BasicConstraints)のpathLen制約をサポートする
・ブラウザの設定でMD5withRSA証明書をはじくようにする(FireFoxプラグインができないでしょうか？)

しか無いのかな、、、と考えています。

勉強不足で思い違いをしているようでしたら、ご指摘いただけると有り難いです。

参考リンク：

・米VeriSign Tim Callan氏のブログ：This morning's MD5 attack - resolved (2008.12.30)
・Alexander Sotirov氏のブログ：Verisign and responsible disclosure (2009.01.06)
・セキュリティmemo：追記 MD5 considered harmful today: Creating a rogue CA certificate (2009.01.07)
・日本ベリサイン：MD5アルゴリズムへの衝突攻撃によるSSLサーバ証明書の偽造に関する報道について(2009.01.06)
・GMOグローバルサイン：MD5アルゴリズムへの衝突攻撃によるSSLサーバ証明書の偽造に関する報道について(2009.01.06)

自堕落な技術者の日記 : 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コリジョンでインチキ認証局は作れる（ネットにとっては悪い報せ)

あなたの知らないPKI：特集 - builder by ZDNet Japan

「あなたの知らないPKI」というタイトルでZDNetの連載記事を見つけたのでメモメモ、、、、

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

・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年頃当時の面影を知ることができ、なかなか良かったです。ハイ。

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

ECOMセミナー

第３３回　ＥＣＯＭセミナー 本人確認情報と属性情報の利用のあり方について

仕事の都合で最初のセッションしか聞くことができず中座してしまいとても残念でした。

最初の講演は属性証明書のチュートリアル的でありながら、個人的には属性証明書について考えさせられた興味深い講演でした。

属性証明書はパブリックにはあまり使われてないし、仕組み自体とても面倒くさく厄介だと思っています。これまでの属性証明書の議論でスコ〜〜ンと抜け落ちているのは属性証明書を発行する属性認証局(AA: Attribute Authority)なんじゃないでしょうか。PKIのエンドエンティティつまり一般ピープルなら誰でも発行できるものなので、認められた組織が発行した属性証明書かきちんと確認する事が非常に重要です。生成する側と検証する側で、属性認証局はトラストアンカと同等の扱い、つまり検証前に属性認証局がどこであるかを合意しておく必要があります。

属性認証局を明らかにし合意しないまま属性証明書を使うというのは本来ありえない話です。

このPKIエンドエンティティなら誰でも属性証明書を発行できるという仕様はX.509 PMIやRFC 3281の欠陥なんじゃないかと思っていて、属性認証局用の公開鍵証明書には拡張でも何でもいいから何らかの印をつけておくべきだったんじゃないかなぁ、、、とも思います。

ETSIのXAdESのプラグテストでも適当な人が勝手に属性証明書を発行しようとしたり、公開鍵証明書から紐付けることのできないものや、CAから属性証明書発行させようとしたり、とんでもない雰囲気でした。一応、指摘はしたんだけども誰も気にしていない様子でした。(そもそもXAdESソサエティーの人々の多くは証明書検証にはあまり興味が無いんです)

その割には属性証明書の検証情報の格納に拘ったりする、、、、検証なんかできていないのに、、、、全くわけがわかりません、、、、、

長期署名の場合には属性証明書の検証情報、即ち
・属性証明書自体の失効情報(もし必要ならば)
・属性認証局の公開鍵証明書(PKC)の認証パスおよび失効情報群
も必要になります。現在のETSI ESIの議論では、属性認証局PKCのパスは現状のCAdESの仕様では格納する場所が難しくて、certificatesフィールドに格納するしか手が無いというのも面倒臭いところです。

タイムスタンプの時刻監査証も属性証明書なんですよね、、、（＾＾；

認証された属性の共有の仕組みとして、SAMLの属性アサーションやOpenIDベースの仕組みが社会インフラとして普及したとするなら、属性証明書よりもそちらの方を保管したり長期署名に組み込む方が筋がいいんじゃなかろうか、、、とも思ったりもします（　´∀｀）つ

IDの話は下手な事言えないので、また別の機会にコッソリと（ｗ

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

2008年10月03日 09:03AM

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

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