Langley氏のブログ記事のポイントはこんな感じ

• SSL証明書の失効検証をOCSPやCRLをダウンロードしオンラインで検証する方法を 将来のGoogle Chromeではやめにする。
• その代わりに各認証局の発行するCRL情報をまとめて軽量化したCRLSetという情報をGoogleからプッシュすることにより、これを失効検証に用いる。
• このような方針をとることにした理由は、
  • オンラインで失効検証ができない際、SSL証明書を有効としてしまうブラウザが他にも存在している
  • オンライン失効検証に係る通信や処理のオーバーヘッドがかなり大きい
• EV SSLサーバー証明書の検証については、新しい方式を使うかどうかは未定

ITmediaニュース記事「Google Chrome、SSL証明書のオンライン失効チェックを無効に」より引用
CAが発行する証明書をめぐっては、2011年に不正なSSL証明書が発行される事件が相次いだことを受け、主要ブラウザメーカーがソフトウェアアップデートを通じて証明書を失効させる措置を取った。Googleは今後、この仕組みを活用して、アップデートを使って失効した証明書のリストを管理していく方針だとしている。

それでは将来的にChromeではどのように失効情報提供しようとしているのか？

Googleはこれまでの

• (場合によっては巨大な)CRLファイルによるものでもなく
• 通信オーバーヘッドの大きいOCSPでもなく
• 迅速に失効情報をアップデートできないブラウザやOSのブラックリストを使う方式でもなく

crlsetツールから将来のGoogleの失効情報プッシュを想像する

「将来のGoogleの失効情報プッシュに関して興味があれば crlset というオープンソースのツールがあるので、これを見てみろ」とブログにあるので 早速見てみた。

GoogleはCRLの代わりにCRLSetというデータにより失効情報をGoogleから配信(プッシュ)しようとしているようだ。 crlsetというコマンドでは、CRLSetと呼んでいるデータをダウンロードしたり、 ダウンロードしたファイルを表示したりということができるようだ。

最新のGoogle Goをインストールし試そうと思ったがコンパイルできない。 ここにあるコードはGo1用のコードらしくビルドしようとすると"net/html"やら"json"やらパッケージの 場所やメソッドや不整合が起きる。(ﾑｷｰｰｰｯ!!!) できるところまで、最新のGo用に書き直したがバカバカしくなってやめてしまった。 Goはコンパイラのチェックが厳しめなので、ちょっとツールを作ったり 試してみたりするのに全く向かない。

ソースコード見てもらえばわかる通り"crlset.go"は全く大したことをしていないので、 大まかにPerlで書き直した。(Rubyにすりゃよかったと途中で後悔)

Google ChromeのCRLSetダウンロードの動き

"crlset fetch"を実行するとCRLSetをダウンロードするためのメタファイル(XML)がダウンロードされる。 "./crlset fetch"で標準出力に表示されるXMLメタファイルの 内容はこんな感じだ。

<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response" protocol="2.0" server="prod">
　<daystart elapsed_seconds="56280"/>
　<app appid="hfnkpimlhhgieaddgfemjhofmfblmnib" status="ok">
　　<updatecheck
　　　codebase="http://www.gstatic.com/chrome/crlset/100/crl-set-10371439235811702542.crx.data"
　　　hash="" size="0" status="ok"
　　　version="100"/>
　</app>
</gupdate>

記載されたURLをダウンロードしてみると何かしらのヘッダ領域があり、ZIPファイルのデータがあることがわかる。 ZIPファイルのデータを取り出すと2つのファイルが含まれるZIPアーカイブであることがわかる。

• manifest.json
• crl-set

{"name": "CRLSet", "version": "0"}

ZIPアーカイブに含まれるもうひとつの"crl-set"ファイルが今回調査すべきメインである。 Google Chromeのオープンソース部分であるChromiumの "net/base/crl_set.cc"の ソースコードにcrl-setファイルのデータ構造の定義が記載されており ざっくりとしたデータ構造の定義はこんな感じである。

・crl-setのJSON形式のメタデータのバイト長(2バイト)
・crl-setのJSON形式のメタデータの値文字列
・CAや中間CA毎にある失効情報の並び[]
　・あるCAの失効情報(証明されてない失効リスト相当)
　　・parent_spki_sha256 - CA証明書のSubjectPublicKeyInfoのSHA256ハッシュ値バイト列
　　・失効した証明書のシリアル番号の並び(4byte非負整数)
　　・シリアル番号の並び[]
　　　・serial_length - シリアル番号のバイト数(1バイト)
　　　・serial - シリアル番号のバイト列
注："[]" は同じ要素が繰り返されることを示す

{ "Version":0,
　"ContentType":"CRLSet",
　"Sequence":100,
　"DeltaFrom":0,
　"NumParents":35,
　"BlockedSPKIs":[]}

• 幾つかのCAまたは中間CAの発行するCRLをまとめたファイルである
• CAの識別はCA証明書のSubjectPublicKeyInfoフィールドのSHA256ハッシュ値による
• CRLSetはデジタル署名で保護されない
• CRLSetはHTTP平文で配信される
• ただの失効した証明書のシリアル番号のリストである
• 失効時刻は記載されない
• 失効理由などCRLエントリ拡張に相当するものは無い
• CRLSetの世代管理は番号(Sequence値)により管理されている。(CRLのCRLNumber拡張と同等)
• delta CRLにも対応している

Googleは、CRLSetファイルをGoogleがプッシュ(=データ配信)するために認証局にCRL提供の呼び掛けを行っていくという事のようだ。

どれくらいCRLを圧縮できるのか

一つのCAが発行するCRLに対し、CRLからCRLSetに変換した場合、 ファイルサイズはどれくらい縮小されるのかを予想してみた。 鍵長やシリアル番号の桁数、拡張の有無なども影響するが、 ZIP圧縮の効果もあり概ね40%程度に圧縮されるものと思われる。

失効証明書数	131,967	4,596
シリアル番号バイト数	16	16
CRLファイルサイズ	4.4MB	157KB
CRLSetファイルサイズ(予想,ZIP圧縮前)	2.2MB	78KB
CRLSetファイルサイズ(予想)	1.8MB	63KB

CRLSetではZIP復元処理が2回あるのでCRLのASN.1の 処理コストと比較して5分5分といったところだろうか。

ちなみに、現在プッシュしているCRLSetはたった35のルートCA,中間CAしかサポートしていない。

ImperialVioletのブログの主張のおかしな点

「オンライン失効検証ができない場合様々な問題が起きる」として幾つか問題点を述べている。

• 「"captive portal"(ホテルのインターネットなどでウェブブラウザで認証してから ネットが使えるようになる仕組みの事)などでは接続前はオンラインの失効検証が できない」としているが、その時点ではホテルのサービスの認証のページしか繋がる 必要が無いのであまり大きなリスクとも思えない。特定の問題なので 別に解決策もあると思う。
• 「認証局のCRLを提供するリポジトリやOCSPレスポンダがダウンした場合、 そこが単一障害点になる」と述べており、まぁ、確かにその通りだが 認証局はそんなものダウンさせたら大問題になるし、 一般にそのための十分な冗長構成を備えているので 検証側がそれほど心配する問題ではない。
• 「オンライン失効検証が失敗した場合に、検証が成功してしまう ブラウザがある」と述べており、過去にブラウザを幾つか調査している ようだが、検証結果にかなりの誤解と思いこみがあるんじゃないかと思う。 まず、大前提として一部のウェブブラウザではデフォルトで 失効検証が無効になっているものがあり、失効検証を有効にしてから でないとテストの意味がない。(デフォルトで失効検証ONにして ブラウザ等を提供して欲しいんですけどね。) あと、Microsoft等の製品ではオンラインで失効検証できない場合、 例えば最新のCRLを取得できない場合やOCSPレスポンスが取得できない 場合、キャッシュにあるCRLやLight Weight OCSPのOCSPレスポンス が有効期間的に問題が無い場合これを利用して失効検証する。 また、証明書の検証結果もまた維持されるようになっており、 ブラウザの利用の途中で通信断があったとしても直近の検証結果を利用して SSLに用いる。ブラウザを再起動しないと検証結果の状態がクリアされない場合がある。 このように、設定、キャッシュ、認証結果の維持のために、 オフラインでも検証結果が「有効」となるブラウザがあるという事である。 また、オンラインかオフラインかにかかわらず失効検証できない場合は (RFC 5280的にも)証明書の検証結果は「無効」とするのが正しいし、 もしそれができないならブラウザの瑕疵だ。 いろいろ攻撃の例を述べているが、 攻撃者者がいくらオンライン失効検証ができないようにしたとしても、 失効検証ができない場合にはブラウザの証明書検証結果が「無効」になれば、 即ちフェールセーフになっていさえすれば問題がない。
• 「以上に述べたオンライン失効検証の問題から、 「(オンライン失効検証ができない場合でも有効としてしまうブラウザがあるような)失効検証 の仕組みは、衝突するとポキッと折れてしまう車のシートベルトのようなものだ。 99%動作するかもしれないが、必要な時に動作しないのでは価値がない。」と述べている。 ブラウザがフェールセーフになっていれば99%のケースで使えれば全く問題がない。 これって、「銀行強盗、誤った本人確認や、行員の不正着服があったりして利用者の預金が 危険なので銀行の仕組みを一切やめて他の仕組みを使います。」みたいな話じゃないですか？
• 「OCSPレスポンダへの通信の遅さや、OCSPレスポンダを使った際のIPを認証局が ログ取得できるためにユーザがどのサイトにアクセスしたのかを認証局が 知りえてしまうというプライバシーの問題がある」と述べている。 確かにOCSPレスポンダは、遅いものもあるし、検証の処理コストも高いが Light Weight OCSPを使ったり、CRLのキャッシュを使ったり オンライン失効検証のコストは小さくなるような工夫は認証局もブラウザもしている。 また、プロキシやNATもある状況で接続元IPと接続先の証明書中のホスト名が OCSPレスポンダに残っていることがそれほど大きなプライバシー問題になるだろうか？

Google ChromeのCRLSetプッシュ方式の問題点

結局、CRLSetはGoogleのやる軽量なCRLアグリゲーションのようなものだ。

CRLSet失効情報が改ざんされてないと誰が証明してくれるのか？

CRLSetのGoogleからのプッシュでは、HTTPSは使わないし、デジタル署名もつかないようだ。 悪意のある中間者によりCRLSetが改ざんされたとしても、それを知る方法がない。 また、HTTPSもCRLSetを元に失効検証しているならHTTPSの証明書の有効性を判断できない。

Googleは誤ったCRLSetを発行したとしても多分罪を認めたりはしない

CRLSetのデータは各認証局から発行されているCRLを元にこれをまとめてCRLSetデータを 生成するが、CRLSet生成の過程でバグや故意の間違いがあったとしても、 有効な証明書が無効になったり、無効な証明書が有効になったりしても、 通信路の改ざん防止機能はないし、デジタル署名されているわけでもないので Googleの誤りなのか、通信路の問題か、中間者攻撃なのか判断ができない。 ニセのサイトにSSL接続して詐欺被害にあったとしても Googleは多分罪を認めたりはしないだろう。

Googleが回収したCRLを検証するかかなり怪しい

Googleは、申し入れのあった認証局からCRLをロボットにより回収し、 CRLSetを生成するようだが、個々のCRLの有効性、即ち正当な認証局から 発行されたCRLであるかを確認するかどうかはかなり怪しいと思う。 おそらく何も検証せずにCRLSetを生成するだろう。

Googleはビッグブラザーになりはしないか

GoogleがCRLを集約した(ふりをして)署名もしないCRLSetを発行することで、 Googleは証明書の検証結果を意図的にコントロールできる立場になったことに 注意しなければならない。 Googleの意向一つでCRLSetを発行でき、SSLサーバー証明書は有効にも無効にもできるのだ。

CRLSetのファイルサイズや発行周期が問題にならないか

CRLは認証局により発行周期が異なっている。毎日、3日おき、1週間おき、1ヶ月おき等 さまざまであるが、CRLSetを更新する周期はどうするのか、頻度に高いものに あわせるのか気になるところだ。また、CRLSetは複数のCRLをまとめたデータとなるので 現行の全てのルートCA、中間CAをサポートするとなれば巨大なファイルサイズになることが 予想される。(ルートCAだけでも400近く、中間CAも含めたら3倍以上になるのではと想像する。 一回のアップデートで使うかどうかもわからないほとんど無用な失効情報をダウンロードするならば 現行の必要なCRLだけをダウンロード、キャッシュして使う方が効率的ではないだろうか。

全てのCRL発行モデルに対応できるのか

CRLSetはdelta CRLには対応しているようだが、CRL/ARLモデルなど一部の 発行モデルで対応できないケースが無いだろうか。

OCSPでしか失効情報を提供していない場合どうするか

認証局によってはOCSPでしか失効情報を提供しないものもあるが、 そのような場合にはCRLSetでは対応できない。

CRLSetはCRLほどは新鮮でない

CRLSetは認証局がCRLを発行してから、ある期間を経た後に 発行されるのでCRLほどは新鮮ではない。1日以上のタイムラグは 覚悟しておく必要があるだろう。 失効情報の鮮度という意味ではOCSPもまた多くの場合、 CRLの失効情報を元にOCSPレスポンスの値が決まるケースが多いので CRLとほぼ同等かちょっと古いかだ。

おわりに

私は個人的にOCSPが嫌いでOCSPレスポンダ証明書をちゃんと検証してるよね？とか、 OCSPレスポンス検証のオーバーヘッドだってかえって大きくなるぐらいだよねとか、PKIを ややこしくしていると思っていてAdamさんのOCSPに対する文句もわからなくはないが、 かといってCRLSetプッシュもまた多くの問題を抱えていることは、このブログで 少しは知っていただけたのではないかと思う。

オンライン失効検証にこだわる必要はあまりなく、 CRLをキャッシュして使い、オフラインでも、通信障害でもCRLが取れなければ、 nextUpdate的に問題なければそれを使うというので全く問題無いように思う。 キャッシュされたCRLを使う方がCRLSetを使うよりよっぽど良い。 スマホなんかはディスク容量いっぱいあるしね、、、

参考リンク

• ImperialViolet: Revocation checking and Chrome's CRL (05 Feb 2012)
• ars technica: Google to strip Chrome of SSL revocation checking (2012.02.07)
• ITmediaニュース: Google Chrome、SSL証明書のオンライン失効チェックを無効に (2012.02.09)
• NETWORKWORLD: Google Chrome will no longer check for revoked SSL certificates online (2012.02.08)
• Google Chromiumのnet/base/crl_set.ccのソースコード
• cryptography@randombit.net: Re: Chrome to drop CRL checking

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)では失効されていません。

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

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

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

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

関連記事

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

• 現在、解読が可能とされている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は最近珍しい

ですよね？

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

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

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

今日、某IPアドレスで書かれたサイトにHTTPSでアクセスしてみると うむむ、FireFox 3.6.23だと 信頼できない接続のアラートが、、、

IE8だと問題ありません。

んなアホな。 うむむと思ってSSLサーバー証明書を見てみると

SubjectAltNameのGeneralName値が

dNSName: 192.168.1.5

みたいにDNS NameのところにIPアドレスが 書いてある証明書のせいみたいなんです。

RFC 3280 ではsubjectAltNameにドメイン名を入れる場合には dNSNameフィールドに入れなければならず(MUST)、 RFC 1034の"prefered name syntax"でなければ ならない(MUST)となっています。

RFC 3280 4.2.1.7 SubjectAltNameより
When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034].

で、RFC 1034のpreferred name syntaxを見てみると 普通のFQDNドメイン名でありラベルの先頭は英大小文字の A-Zにでなければならないので、 dNSNameには "192.168.1.5" のようなIPアドレスは 入れてはならないことになります。

IPアドレスを指定したい場合にはiPAddressフィールドが使えますよね。

GeneralName ::= CHOICE {
　　 otherName　　　　　　　　　　　 [0]　　 OtherName,
　　 rfc822Name　　　　　　　　　　　[1]　　 IA5String,
　　 dNSName　　　　　　　　　　　　 [2]　　 IA5String,
　　 x400Address　　　　　　　　　　 [3]　　 ORAddress,
　　 directoryName　　　　　　　　　 [4]　　 Name,
　　 ediPartyName　　　　　　　　　　[5]　　 EDIPartyName,
　　 uniformResourceIdentifier　　　 [6]　　 IA5String,
　　 iPAddress　　　　　　　　　　　 [7]　　 OCTET STRING,
　　 registeredID　　　　　　　　　　[8]　　 OBJECT IDENTIFIER }

FireFoxは厳密にsubjectAltName dNSNameをみて それがFQDNでないとリジェクトしちゃうけども、 IE8はIPアドレスが書いてあっても通してしまうと、、、 結局は発行した証明書のsubjectAltNameが 間違ってるってことなんですが誰に言えばいいんですかねぇ、、、

これに対しW3Cは "Some notes on the recent XML Encryption attack" というコメントを発表しました。

これはぶっちゃけちゃうと「CBC使わずにGCM(Galois Counter Mode)なんかを使ってね。 標準にもなってるしね。」という内容なんですが、 標準になっているといってもOPTIONALですよね。

引用：W3C XMLEnc 5.2.4 AES-GCM
- http://www.w3.org/2009/xmlenc11#aes128-gcm (OPTIONAL)
- http://www.w3.org/2009/xmlenc11#aes256-gcm (OPTIONAL)

手軽に手に入りやすそうな比較的メジャーなJava XML暗号ライブラリというと こんなところかと思います。

• Apache Santuario/XML Security for Java - サポートするアルゴリズム情報
• IAIK XML Security Toolkit (XSECT) - サポートするアルゴリズム
• IBM SDK Java Technology Edition Verion 7

結局、W3Cは「GCM使えばいいじゃん」というものの「使えそうな実装がない」 という、何ともとほほな状況であることがわかりました。 自前でAES-GCM対応するしかないですかね。

まずメッセージヘッダの特徴的なところを

Content-Type: multipart/signed;
　　　　micalg=sha1;
　　　　boundary=Apple-Mail-XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX;
　　　　protocol="application/pkcs7-signature"
X-Mailer: iPhone Mail (XXXXX)
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)

Content-Disposition: attachment;
　　　　filename=smime.p7s
Content-Type: application/pkcs7-signature;
　　　　name=smime.p7s
Content-Transfer-Encoding: base64

署名データの中身は

PKCS#7 SignedData形式である署名データを覗いてみて 特徴をまとめてみました。

フィールド	値
version(SignedData)	1
digestAlgorithms	SHA1
certificates	EE証明書のみ

SignedDataの中のSignerInfoの特徴はこんな感じ。

フィールド	値
version(SignerInfo)	1(=IssuerSerial)
digestAlgorithm	SHA1

SignerInfoの中の署名属性(signedAttributes)の一覧は以下の通り。

フィールド	値
contentType	data
signingTime	UTCTime
messageDigest	署名対象のSHA1ハッシュ値
microsoftRecipientInfo(1.3.6.1.4.1.311.16.4)	受信者のIssuerSeiralセット
encrypKeyPref(1.2.840.113549.1.9.16.2.11)	送信者の暗号用証明書のIssuerSerial
signatureAlgorithm	rsaEncryption(1.2.840.113549.1.1.1)

暗号データの中身

次にPKCS#7 EnvelopedData形式である暗号データを覗いてみました。 特に特徴的なところはなくてTriple DES EDEモード(des-EDE3-CBC 1.2.840.113549.3.7) が使われているというだけでしょうか。

まとめ

というわけで、iOS5のメールのS/MIME機能は使われている フォーマットや暗号アルゴリズムは至って普通で とても相互運用性が高いものになっていると言っていいんでしょうかね。 うーん、つまらん。

ようやく私も昼ごろアップデートできました。ある方は「TLにiOS5のS/MIME対応について何も流れてない」と心配されており、私も検索してちょっと心配になってみたりしたんですが、まぁ、早速試してみるべ～～～と。と、いうかiOS5のアップデートで「ほとんど、そこ」にしか喰い付いてないという話もあります。というわけで、iPhone iOS5からサポートされるようになったS/MIME署名暗号メール機能についてのレポートです。

Outlook, Outlook Express, Thunderbird, Becky!, Mac OS X Mailなど 最近のメジャーなメーラーではデフォルトで S/MIME署名暗号メールに対応していて、 S/MIME対応の証明書と鍵さえあれば、 自分のメールを途中で改ざんされないように署名したり、 知り合いにムフフと秘密のメールを送ることができます。 iPhone iOS5になって初めてS/MIME対応になり どんな感じなのか見てみました。

とりあえず、どこ設定すんだ？

すでに自分のメールアドレス用に使えるクライアント証明書というかS/MIME用証明書をを持っていたので、そんなのがあると仮定して話を進めます。無い方はどこかの証明書発行サービスから買うとか、適当な認証用の(メールアドレスの入っている)証明書をゲットするとかしないといけません。

とりあえず、Google大先生に聞いてみると「GEMINI Securityのブログがあるぞよ」と仰るので斜め読みしてみると、ざっくり以下の手順でS/MIMEのメール設定ができるようです。

• (1) iPhone iOS5 で「設定」アイコンを開く
• (2) 項目「メール/連絡先/カレンダー」を開く
• (3) S/MIME用に使える証明書(と鍵)がインストールされているメールアドレスに 対応するアカウントを開く
• (4) 項目「詳細」を開く
• (5) すると最下部に「S/MIME」の項目があるので「オン」にする
  
  
• (6) 送信時には必ずS/MIME署名メールにしたい場合には「署名」の項目を選び、 署名を「オン」にし使用する署名に使用する証明書(と鍵)を選択します。
  
  例えば証明書の詳細を見てみるとこんな感じ、、、
  
  ここで証明書は自分のメールアドレス用のもの、即ちiPhoneの証明書の詳細表示でコモンネームかサブジェクト代替名のメールアドレスに自分のメールアドレスが記載されているものでなければなりません。(そのような証明書をとりあえずタダで入手できる方法についてはグーグル大先生で調べるか、私の知り合いの人はこっそり聞いてください。)
• (7) 同様に、送信時には可能ならば必ずS/MIME暗号メールにしたい場合には「暗号」の項目を選び、暗号を「オン」にし復号時に使用する証明書(と鍵)を選択
  (普通の人は署名用と暗号用の証明書は同じ人が多いです)
• (8) アカウント設定に戻り右上の「完了」ボタンを押せば設定は終わり

さてと、軽ーくS/MIME署名メールを送ってみますか

とりあえず、S/MIMEのための設定は終わっているので、フツーにメール送ってみることにします。受け取り側は、Outlook Expressなんですが、問題なくS/MIME署名メールとして有効なものが受信できました。

次に外部(Outlook)から暗号のみのメール、署名暗号メールをiPhone iOS5で受けてみます

まずは暗号だけのメール。南京錠のアイコンが差出人名につくことで暗号化されていることがわかるようです。

差出人をクリックするとこんな感じに「暗号化済み」と表示されます。

次に署名暗号メールを受信してみます。 差出人名にチェックと南京錠のアイコンが表示されます。 これにより署名暗号メールであることがわかります。

同様に差出人の詳細を見てみると、

有効な署名メールだと青で無効な署名メールだと赤になるんだと 思います。(後述)

さて次に暗号メールを送信してみましょう

すでに誰かからS/MIME署名メールを受け取ったことがあれば おそらくそのS/MIME署名書は自動的に(見るすべはありませんが) keychain に登録されるようです。 証明書が自動登録済である人にメールを送ってみようとします。 宛先名が青になり、この場合には問題なく署名暗号メールが 送られます。

次に、まだ証明書を持っていないであろう人に 署名暗号メールを送ってみようとしましょう。 宛先名が赤になり南京錠がかかってない状態になります。 この状態のときには「証明書を持っていないので 暗号メールを送れませんよ」という意味のようです。

残念なことにiOS5の「住所録」は従来のものと全く変わらず、 住所録に送信したい相手のS/MIMEがあるかどうかを知るすべが ありません。

あと、普通の人は場合によっては署名をつけたり、暗号化したり、 動的に切り替えるのが普通で、Outlook Expressなども そのような署名と暗号を切り替えるトグルボタンが メール送信にはついていますが、 iPhoneには一切それはありません。 共通の設定にさかのぼって署名をするか、暗号化するか 決めないといけません。 これは何とも厄介な仕様だなぁ、、、、と思います。

おわりに

以上、iOS5のS/MIME署名暗号メール機能がとてもうれしかったので レポートしてみました。 ただ、実用で使うにはトグルボタンが無いので かなり苦しいかなぁという印象です。 次回は、iOS5が出すメールの中身や、S/MIME(=PKCS#7) 署名データ、暗号化データの構造なんかをマニアックに のぞいてみたいと思います。

今日は、中央線やら丸ノ内線の事故でえらい目にあって 疲れちゃったので、この辺で、、、、おやすみなさい Zzzz....

参考リンク

• @IT: 【特集】S/MIMEでセキュアな電子メール環境をつくる！～実は危ない電子メール、安全性を実現するS/MIMEの詳細解説～
• GEMINI Security Blog: Sending and Receiving S/MIME Encrypted Email on iOS 5 (Beta)
• Secure-Mail - S/MIME署名暗号対応 iPhone メールアプリなんだそう。iOS5じゃなくても使えちゃうんだろうからすごいっすね。

謝辞

S/MIMEのテストを自分一人でやるのはいろいろ面倒だったので、 送り相手をうちのチームの平井堅に似た人にお願いしてしまいました。 ありがとね。この場を借りてお礼しまふ。

私が食いつくのは暗号ライブラリ(Java Cryptography Extension(JCE))の部分しかありません。 先日Oracle(Sun) Java J2SE 7.0がリリースされたばかりですが、 IBMの方はどうちがうのか見ていきましょう。

早速IBM Java 6.0と比較

まずはIBM Java 6.0と比較してどうなのか調べていきましょう。 下に示す両者の間でどう違うのか見ていきます。

Java	IBM Java 6.0 Win	IBM Java 7.0 Linux
Build	pwi3260sr1-20080416_01(SR1)	pxi3270-20110827_01
Arch	Windows XP x86-32	Linux x86-32

IBM Java 7.0 に同梱されたJCEプロバイダの一覧は以下の通りです。 変更の概要についても簡単に書いておきました。

Provider	IBM Java 6.0 Win	IBM Java 7.0 Linux
IBMJSSE2	1.6	1.7 TLSv1.1/v1.2サポートを追加
IBMJCE	1.2	1.7 楕円(EC,ECDH)追加 SHA1/256/384/512withECDSAを追加 HmacSHA256/512を追加
IBMJGSSProvider	1.6	7.0
IBMCertPath	1.1	1.1
IBMSASL	1.5	1.7 NTLM認証を追加
IBMXMLCRYPTO	1.0	1.0 変更無
IBMXMLEnc	1.0	1.0 変更無
IBMSPNEGO	1.0	1.0 変更無
SUN		1.7 新規追加 ポリシ対応のみでほぼ空

SSL/TLS CipherSuitesについて

次に、IBMJSSE2プロバイダがサポートするCipherSuitesを見てみようと思います。 簡単なTLSクライアントを実装して接続して試してみました。 以下のようなところが特徴的かと思います。

• 28のCipherSuitesをサポートとSun Javaに比べ少なめ
• 楕円系(ECDSA,ECDHをサポート)
• MD5は1つのみで残り27はSHA1
• NSA Suite-Bはサポートしない(GCM,SHA2がない)
• 安全な再ネゴシエーション(RFC 5746に対応している
• AESが基本でRC4、3DESがちょっと
• Sun JavaでサポートするSHA2系のCipherSuitesが無い

SSL/TLS 拡張について

同様にSSL/TLSネゴシエーションの際のSSL/TLS拡張について 見てみました。特徴的なところは次の2点です。

• SNI(Server Name Indication)在り
• 楕円曲線拡張 (25曲線)

今日はこの辺で

ocsp-nocheck拡張とOCSPレスポンダ証明書の有効期間のミスマッチ

まず最初に、 validation.diginotar.nlのOCSPレスポンダ証明書には ocsp-nocheck拡張が設定されています。 これは、「(OCSPレスポンダ証明書の有効期間が非常に短く設定されており、OCSPレスポンダの 鍵は頻繁に更新するので鍵危殆化リスクが少なくOCSPレスポンダ証明書を 失効させることもないので)OCSPレスポンダ証明書を失効検証する必要はありませんよ」 という意味を持つフラグです。 ところが、validation.diginotar.nlのOCSPレスポンダ証明書の有効期間は

notBefore: 2007.11.21
notAfter: 2017.11.21

オレオレOCSP???

なんと驚いた事にvalidation.diginotar.nlのOCSPレスポンダ証明書には 機関情報アクセス(authorityInfoAccess)のOCSPのフィールドがあり、 他のSSLサーバー証明書などと全く同じ http://validation.diginotar.nl という URIを持っています。つまり、OCSPレスポンダ証明書自体がOCSPで検証してよいことを言っています。

これはおかしな話で「OCSPレスポンダ証明書が有効かどうかOCSPレスポンダに聞きに行く」って ことで、こりゃオレオレですよね？

最悪の場合、実装によってはOCSPを使ったパス検証がループしてしまう可能性だってあります。

- www.diginotar.nl が正しいか聞く
　- 失効検証のため www.diginotar.nl が有効かOCSPに聞く
　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　　　•••永遠に続く

おわりに

前回紹介したDigiNotar Cyber CAの証明書も怪しかったですが、 DigiNotarのOCSPレスポンダ証明書も相当怪しいです。 DigiNotarは全体的に凝ったPKI設計になっていますが、いろんなところで間違えています。 (できないなら)シンプルに行った方がいいんじゃないかと思うんですけどねぇ。

今日はこんなところで

関連記事

• 2011.09.11 わけのわからないDigiNotar Cyber CAの証明書

注文してやってくるまで

私はここで買ったんですが、注文が殺到しちゃっているみたいで、8月上旬に注文して 8月末か9月上旬に来る予定になっていたみたいですが、結局着いたのは9月10日でした。 いつ到着するかは知りませんがmagic cube shopさんの方が18,800円と安いみたいです。

iPhoneへの接続

いろいろ試してみて何とかiPhone、iPadに繋げたんですが、 後から日本語サイトが あったり、そこで 日本語マニュアル、 iPhone接続マニュアル、 FAQを公開していたりすることを知りました。 最初から見ておけばさらに苦労がなかったのかも知れません。 それくらい内包されている英語のマニュアルは 読みにくい上に情報が無いのです。

接続するときのつまづきやすいポイントは以下の通りです。

• 買ったらフル充電されるまでUSB接続する
• USB接続のフタを開けたとき基本的にトグルスイッチは「HID」側に 倒しておく。「SPP」は「HID→SPP→HID」という設定リセット用途でしか使えない。
• Blutoothで接続したら機器の認証のため投影されたキーボードから iPhoneで表示された4桁の数字を入力する

iPhoneとの組み合わせでまず困るのは日本語入力の切り替え

繋いでからすぐ、ローマ字入力はできるんですが、英字入力に切り替える方法が どこにも書いてな~~~い!!! 接続デバイス依存ですから、、、と、、、 そりゃそうかもしれないけど、、、 結局、

FN+スペース＝日本ローマ字入力に切り替え
MENU+スペース=日本語テンキー→日本語ローマ字→英字のローテーション
なので
FN+スペース＝日本ローマ字入力
MENU+スペース=英字

キー入力時のタイプ音がいかにも安っぽい

デフォルトではキー入力する時、安っぽいビープ音が出ます。 こういうのは静かな喫茶店とかでは最悪。 折角サイバーで近未来的な気分に浸っているのにあんまりです。 キー入力音の大小の調節は

FN + ↑
FN + ↓

テキスト入力状態で電源切ると誤入力が、、、

テキスト入力状態にある時にMagicCubeの電源を落とそうとすると 意味不明なキー入力が入ってしまいます。 キーボード入力やめたいときにはキーボード投影をしない 省電力モードがあるそうで、そうしてから電源切るのがいいかもしれません。

FN + バックスペース(Back) = 省電力モードへ
キーボードが投影されるあたりの任意の場所で3本指同時にタッチ = 省電力からの復帰

その他のインプレッションはこんな感じ

• 入力する他の指をきちんと浮かせとかないと誤入力されてしまう。 最悪、慣れるまでは一本指入力か二本指ぐらいの入力の方がいいのかも。 誤入力を頻繁にしてしまうイライラ感は結構あります。
• カンマ、コロンなどが一般的な日本のキーボードと違って上の方にあるので 慣れる必要があります。多分韓国のメーカーなので韓国のキー配列なのかも。
• メーカーが言うように折りたたみのキーボードのようにメカニカルな部分がないので 壊れにくいというのはあるかもしれませんが、電源のオン/オフスイッチは 早いうちに接触が悪くなりそうな気がします。
• 一応フルサイズのキーピッチに余裕があるキーボードなので コンパクトな折りたたみ型よりかは打ちやすいと思う人もいるかもしれない。
• Bluetooth対応で78gと軽いのは確かに良い。
• 大量に文字をうたなければならない場合に、MagicCubeが使えるか? と言われるとちょっと考えてしまう。 例えば Apple Wireless Keyboardならフルキーボードで 電池込みで重さ324gと大したことないし、それほどかさ張らない。

結局のところ

サイバーでハイパーな雰囲気(笑)を味わいたいから これを使うんであって、多少の入力のしにくさも含めて 楽しめるようでないとダメっすかねぇ(笑)

娘にちょっと入力してみてもらったのをiPhoneで撮影してiMovieでフリーの音楽つけてみました。(単にiMovieを初めて使ってみたかっただけorz)

今日はこんなところで

リンク

• Magic Cube製造元 CelluonのMagic Cubeのページ
• Magic Cube 公式日本語サイト
• ZONESTYLE 赤色レーザーの未来型キーボードでブラインドタッチに挑戦！Celluon Magic Cube

いろいろ疑問に思っていることがあり時間があるとき、ここでも紹介していきたいと 思っているんですが、その気になるところの一つに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のサイトに無いのでちょっとあきらめ気味だったんですが、 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 (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

この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"

返ってきた２つの値から、 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

更新履歴

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

右の方のカラムに「Sun(Oracle) Java JCA」と書いてあるのがそれです。

• 緑(o)がデフォルトで有効になっているもの
• 赤(x)がデフォルトで無効になっているもの
• 灰(-)がサポートしていないもの

この表から読み取れるのはざっくりこんなとこ。

• Java SE 1.4.1よりAES系CipherSuitesをサポート
• Java SE 5よりケルベロス系のCipherSuitesをデフォルトで無効
• Java SE 6より楕円系CipherSuitesをサポート
• Java SE 7よりSHA2系CipherSuitesをサポート
• Java SE 7でも米国政府のSuites-BはGCMモードがないのでサポートしてない
• 共通鍵暗号化なしはデフォルトで無効
• 認証なし(anonymous)はデフォルトで無効
• とても弱い共通鍵暗号はデフォルトで無効
• 鍵交換のDHはサポートせずDHEのみをサポート
• 認証にRSA, DSSを公平にサポート

今日はあっさり、この辺で、、、ではでは。

関連記事

• SSL/TLS Supported Cipher Suites

• 祝 Java SE 7 リリース記念「JCEはどうなってんの？」 (2011.07.29)
• 祝 Java SE 7 リリース記念(第2弾)「証明書検証の弱いアルゴリズムの制限機能」 (2011.08.01)
• 祝 Java SE 7 リリース記念(第3弾) 「世界最強(かもしんない)CipherSuite一覧の更新」 (2011.08.03)

• RSA BSAFE Shareを試してみました(その3) (2009年04月28日)
• ブラウザが対応するSSL/TLS CipherSuite一覧 (2010年03月05日)
• Xperia上のブラウザがサポートするSSL/TLS CipherSuites (2010年04月24日)
• Google Chrome が NSS を使うようになったのでSSL/TLS CipherSuite一覧を更新 (2010年09月11日)
• ニンテンドーWiiのSSLクライアント認証 (2010年10月31日)
• Apache HarmonyのJSSE(Java Secure Socket Extension) (2011年01月28日)

CertPath Algorithm Disabling
Weak cryptographic algorithms can now be disabled. For example, the MD2 digest algorithm is no longer considered secure. The Java SE 7 release provides a mechanism for denying the use of specific algorithms in certification path processing and TLS handshaking. See Appendix D: Disabling Cryptographic Algorithms in Java PKI Programmer's Guide and Disabled Cryptographic Algorithms in Java Secure Socket Extension (JSSE) Reference Guide for more information.

プロパティファイル java.security の違い

Java SE 6 と7では若干$JRE_HOME/lib/security/java.securityのファイルの内容が違うんですが、 大きく追加されているのは3点あります。

• Policy for failed Kerberos KDC lookups - Kerberosの設定
• Algorithm restrictions for certification path (CertPath) processing - (証明書の)認証パス検証処理のアルゴリズム制限
• Algorithm restrictions for Secure Socket Layer/Transport Layer Security (SSL/TLS) processing - SSL/TLS処理のアルゴリズム制限

jdk.certpath.disabledAlgorithms=MD2

jdk.tls.disabledAlgorithms

アルゴリズムの無効化の指定方法

# MD2を無効化(デフォルト)
jdk.certpath.disabledAlgorithms=MD2
# MD2, SHA1, DSA, ECDSAを無効化
jdk.certpath.disabledAlgorithms=MD2, SHA1, DSA, ECDSA
# MD2, SHA1 を無効とし、鍵長2048bit未満のRSAを無効
jdk.certpath.disabledAlgorithms=MD2, SHA1, RSA keySize < 2048

プログラムの中でアルゴリズム制限を指定する

上記のようにプロパティファイルで指定することもできますが、 プログラムの中でも動的に指定することも可能です。

import java.security.Security;
・・・
Security.setProperty("jdk.certpath.disabledAlgorithms", "MD2, MD5, DSA");

で、実際に使ってみた

試しにRSAの鍵長を可変にして、どうなるか試してみました。

# jdk.certpath.disabledAlgorithms=RSA keySize < 1024 -- RSA1024bit未満を禁止
→検証成功
# jdk.certpath.disabledAlgorithms=RSA keySize < 2048 -- RSA2048bit未満を禁止
→unable to find valid certification path to requested target

仕方ないのでデバックメッセージを表示するようにして (java -Djava.security.debug=all) メッセージを見てみるとアルゴリズムを禁止した場合と鍵長を制限した 場合とでメッセージが異なるみたいです。

# jdk.certpath.disabledAlgorithms=RSA -- RSAを禁止してみた場合
algorithm check failed: SHA1withRSA disabled
# jdk.certpath.disabledAlgorithms=RSA keySize < 2048 -- RSA2048bit未満を禁止
algorihtm constraints check failed

暗号アルゴリズムの危殆化情報の管理と自動処理

暗号アルゴリズムは時代の変遷とともに脆弱になり、推奨されない暗号の鍵長もまた 変わっていきます。特に過去の電子署名ファイルや暗号化されたファイルで 使われている暗号アルゴリズムが当時大丈夫だったのかは気になるところです。 「 RFC 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)」というデータフォーマットがありますが、これは、 は、 どの暗号アルゴリズムや鍵長が何時の時代に、どのくらいの期間までは安全とされていたかを規定することができるデータフォーマットです。

現在、DES、MD5、SHA1、鍵長の短いRSAなど暗号アルゴリズムの危殆化が話題になっていますが、どのアルゴリズムが何年から何年頃までは使い物になったのかをNIST、CRYPTRECなど暗号アルゴリズムの公的な評価機関がDSSCのような電子データの形式として公開、発行して頂けると、このデータを検証ポリシーとして使用し、過去のあるデータが「当時安全とされていた暗号アルゴリズム(や鍵長)」を使っていたかを自動的に判定できるようになります。

DSSCの内容により自動的にjdk.certpath.disabledAlgorithmsに反映させて検証するなんてこともできますね。

おわりに

今日はJava SE 7で新たに提供されることになった証明書検証における弱い暗号アルゴリズムの制限機能について紹介しました。 これまでに、暗号スイートのレベルで制限することはできましたが、ハッシュや公開鍵暗号アルゴリズム、鍵長のレベルでミドルウェアで制限が加えられる汎用の製品はJava SE 7が初めてなのではないかと思います。 SSL/TLSにも使えるので、そろそろ "jdk.tls.disabledAlgorithms=MD2" などとしてもいい頃ですよね。

やべやべ、会社は夏休みなんだけど明日から一週間休日出勤だ。風呂入って寝よう。ではでは。

関連記事>

• 祝 Java SE 7 リリース記念「JCEはどうなってんの？」 (2011.07.29)
• 祝 Java SE 7 リリース記念(第2弾)「証明書検証の弱いアルゴリズムの制限機能」 (2011.08.01)
• 祝 Java SE 7 リリース記念(第3弾) 「世界最強(かもしんない)CipherSuite一覧の更新」 (2011.08.03)

早速ダウンロード

7月28日になって何度もダウンロードページを訪れていたんですが、日本時間で夜の10時か11時頃にようやくダウンロードできるようになっていたみたいです。バージョンを見るとこんな感じ、、、

% java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)

サポートするJCEプロバイダの差分をみてみましょう

Java SE 7 で変更点のひとつの目玉は楕円暗号のサポートなんだそうです。 Java SE 6 と Java SE 7(b147) でJCE(Java Cryptographic Extension)プロバイダの提供物の違いをdiffを取ってつらつら眺めてみました。 全体的にsun実装の内部パッケージ名がcom.sun.net.ssl.internalからsun.securityに変更になっているようです。

Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM)

楕円暗号(Elliptic Curve Cryptography)のサポート

Java SE 7になってようやく楕円暗号のためのJCEプロバイダであるSunECが新たに提供されるようになりました。ECDH、ECDSAをサポートしておりSSL/TLSや署名なんかにちゃんと使えます。 署名アルゴリズムについては以下をサポートしています。

その他気になった変更点

セキュリティ関係の変更点はここにまとめらているんですが、その中で気になったところをかいつまんで紹介したいと思います。

JSSE(SSL/TLS), TLS 1.1, TLS 1.2

TLSv1.1, TLSv1.2 がサポートされるようになりました。

JSSE(SSL/TLS) Connection-sensitive trust management

SSL/TLSで使われるアルゴリズムを署名アルゴリズム等弱い物を使わない等指定できるようです。 証明書の中のアルゴリズムまで制限できるのか気になるところ。

JSSE(SSL/TLS) Endpoint verification

HostnameVerifier()を定義すれば、 SSL/TLSのホストの一致確認方法を実装側で 制御できるようです。逆にホスト名をチェックしないこともできたり、証明書のへんなところに入っている ホスト名であっても認証できるようにしたりできますね。

JSSE(SSL/TLS) TLS renegotiation

2009年3月に発表されたSSL rebindingやSSL renegotiationといわれるSSL/TLSの仕様の欠陥をついた攻撃を防ぐためのTLS renegotiation拡張をサポートしているそうだ。

JSSE(SSL/TLS) Server Name Indication (SNI) for JSSE client

SNI拡張がサポートされた。確かにパケットキャプチャするとClientHelloに入っている。一台のウェブサーバーで複数のバーチャルホストに対してちゃんとHTTPS接続することができるようになります。これはテスト目的で前から非常に欲しかった機能。

以上、Java SE 7 リリース記念ということで、JCE関連の機能の変更点をみてみました。やべやべ、もう寝ないとorz

参考リンク

• Java™ Cryptography Architecture (JCA) Reference Guide
• Java™ SE 7 Release Security Enhancements
• Java™ Cryptography Architecture Oracle Providers Documentation for Java Platform Standard Edition 7
• Java™ PKI Programmer's Guide

関連記事>

• 祝 Java SE 7 リリース記念「JCEはどうなってんの？」 (2011.07.29)
• 祝 Java SE 7 リリース記念(第2弾)「証明書検証の弱いアルゴリズムの制限機能」 (2011.08.01)
• 祝 Java SE 7 リリース記念(第3弾) 「世界最強(かもしんない)CipherSuite一覧の更新」 (2011.08.03)

変更履歴

• 2011-07-31 参考リンクにおいてリンク切れを修正、JCA、PKIを追加

SignNowってどういうサービスなの？

SignNowは 米国のオンライン電子公証サービスNotaryNowの提供するウェブオンライン電子署名サービスでテキストやPDFなどのファイルを送信し、ウェブ画面上で手書き署名画像の場所を決めてやれば、サーバー側で電子署名してくれて署名済みPDFファイルをダウンロードできるようになっているというものです。サービスを利用するために事前/事後でアカウント作成をする必要はなくすぐに利用することができます。アプリケーションも一切必要なくウェブブラウザだけでできるそうです。

使ってみましょ

試しに、"aaa"という文字が入ったテキストファイルをアップロードして署名してみましょう。

1. SignNowのトップページをウェブブラウザで開き「Upload&Go」のボタンをクリックします。
   
   
2. 署名してもらうファイルを選択します。テキストファイルやPDFなど 多分、OpenOfficeで扱えるフォーマットなら何でもアップロード できるんだと思います。
   
   
3. アップロードしたファイルがPDFに変換されます。付箋など貼ることも できるようです。表示されているファイルをクリックすると 手書き署名入力ダイアログが表示されます。マウスじゃうまく 手書き署名はできないし、毎回同じように書けっこないから こりゃあくまでも飾りですね。
   
   
4. 手で書くのが面倒ならば自分の名前をタイプして手書き風フォントで 手書き署名風の画像を表示させることもできます。
   
   右側にメールアドレスを入力する箇所があります。 正しいアドレスを入れなきゃいけない風のことを書いてありますが、 別に嘘のアドレスでも問題はありません。
5. 次に手書き署名画像を表示させる場所をマウスで動かして設定します。 右にあるオレンジの「Complete」ボタンを押せば完成です。
   
   
6. 最後に署名完了の画面が表示されます。 画面中の「Click here to download」から署名済みPDFファイルを ダウンロードできます。
   
   

生成された電子署名付きPDFを開いてみよう

さて、生成されたPDFファイルを開いてみましょう。署名パネルボタンを開き、「すべてを検証」のリンクをクリックしてもAdobe Acrobat Reader のデフォルト設定では「文書の証明の完全性が不明です。 作成者を検証できませんでした。」と表示されます。 デフォルトではWindowsのルート証明書ストアを使わないよう 設定されているためです。

証明書の話は後でやりますが、これを検証できるようにするには メニュー「編集＞環境設定」を開き「セキュリティ」を選択します。 「詳細環境設定」のボタンを押します。

「電子署名の詳細環境設定」で「Windows統合」のタブを開き以下の2つにチェックを入れます。

• Windows証明書ストアからの証明書取り込みと使用を有効にする。
• 証明済み文書を検証

PDF署名をみてみると

証明書の話は後にして、PDF署名の署名ディクショナリはこんな感じ

/Type /Sig
/Filter /Adobe.PPKLite
/SubFilter /adbe.pkcs7.detached
/ByteRange [0 10060 21804 57036]
/Contents <308212....>

• contentType
• signingTime
• messageDigest
• sMIMECapabilities

/Reason (
IP Address: 192.168.128.110
Email address of signer (unconfirmed): foo@foo.com
Date/Time: 1:08 EDT 4/7/2011
This document has not been modified.
This certificate was signed using SignNow.com
SignNow itself does not sign this document.
This is to be used only for data integrity, not identification.
)

さて署名者証明書とその証明書チェーンは？

PDF署名に使われた署名者証明書はドイツの認証サービス TC TrustCenterから発行されたもので以下のような 証明書チェーンになっています。

• ルートCA：TC TrustCenter Universal CA I
• 中間CA：TC TrustCenter Class 1 L1 CA IX
• 署名者証明書：SignNow Online

署名者証明書の主体者識別名はこんな感じ。 雑な感じですねぇ。

/C=US
/ST=CA
/L=Newport Beach
/OU=To verify, email: verified@signnow.com←ええ？？
/CN=SignNow Online
/SERIALNUMBER=online signing service←なんじゃこりゃ？

• クライアント認証 (1.3.6.1.5.5.7.3.2)
• S/MIME電子メールの保護 (1.3.6.1.5.5.7.3.4)
• IPsecVPNユーザー (1.3.6.1.5.5.7.3.7)
• スマートカードログオン (1.3.6.1.4.1.311.20.2.2)

というわけでこれは何を証明してくれるのか？

これは、Adobe eSIGNATURESの時にも述べたように 文書の作成者、受領者、承認者でもない、 なんでもない人による自動的な署名なんですよね。 SignNowは署名対象に対して何の保証もしてくれません。 また、途中誰でも文書を改竄してから再署名するチャンスが いくらでもあるので文書の完全性についても怪しいです。 Adobe eSIGNATURESについてはアカウントを持っている人が 行っていることになるのでAdobeが公証人として信頼できる組織ならば 証明にもなるかもしれませんが、SignNowについては 何ら本人を認証するものではないので、 生成された署名には何の意味もありません。

これって優良誤認じゃないの？

サービスの 「Legal & Secure」のページに 「電子署名は手書き署名と同等の法的効力を持つ」とか 「電子政府でも使われている」とか 各国の電子署名法を参照してみるとかして SignNowのサービスによる電子署名が 法的効力を持っているかのように 「Don't worry! Even if your signature looks weird, It's still legally valid.」みたいな 事を書いていますがとんでもない話です。 EUの電子署名に係る指針であったり米国のESIGN Actなどで 電子署名が手書き署名と同等の法的効力を持つためには 「署名者(signatory)本人が電子署名を行ったと 特定できる場合にのみ電子署名が手書き署名と同等の法的効力を持つ」 としてます。 通常はスマートカードなどを用いて本人しか使用することができない 鍵がきちんと管理されており、その鍵と本人との関係が電子証明書により 紐づけられており、その鍵を使用して署名した場合に 法的効力を持つのです。 SignNowの場合は誰が署名したかなんて全くわからないわけですよね。 SignNowの署名が法的効力を持つかのような表現をしているのは いけない事です。JAROに訴えちゃいたくなります。

EUの電子署名に係る指針に基づいて欧州各国の電子署名法を定めていますが電子署名が手書き署名と同等の法的効力を持つためには適格電子署名(qualified electronic signature)である必要があるとしています。

・適格電子署名(qualified electronic signature)は以下が必要
　・署名者である自然人が特定できる適格証明書(qualified certificate)を用いて署名されている。
　・署名者本人がのみが利用可能なセキュアな署名デバイスにより署名されていること。
　・証明書と署名データとの関係をより厳密に特定できる高度電子署名(advanced electronic signature)が使われている事。

また、ホームページを見るとiPhoneからでも 署名ができるかのような表現になっていますけど、 現在 iPhone 用のアプリを提供しているわけでもないし、 ファイルアップロードボタンが表示されないので iPhoneのSafariから本サービスを利用することはできません。 これも優良誤認ですよね。 (もう一度iPhoneで開いて良く見てみたら mobile uploads coming soonとなってますね（＾＾；)

おわりに

というわけで、おもしろそうなサービスだし、 電子署名の新しい可能性を示してくれている感じもしますが 何の役にも立たない上に、優良誤認というか 詐欺まがいの代物だと思いますがどうでしょうか？ なんか、長くなっちゃいましたが、今日はこの辺で、、、

関連リンク

• Adobe eSignaturesを試してみたんですが、、、(2010.05.17)