自堕落な技術者の日記 : X.509 - livedoor Blog（ブログ）

X.509

2013年12月03日23:41

カテゴリ: SSL証明書; PKI

(小ネタ) Twitter REST API用の証明書の切り替え

@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証明書なんだね。そりゃだめだ。
path
認証サービスの共通ルールを作っている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は使えなくなっちゃうんだなぁと。

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

タグ：: #Twitter; #PKI; #X.509; #SSLサーバー証明書; #証明書

2009年10月08日08:07

カテゴリ: PKI; OpenSSL

pathfinderという証明書のパス検証フリーウェア試用奮闘記(泣) (第2話)

一昨日は悔しい思いをしたのでw、OpenSSLのDebian鍵脆弱性の時に作ったUbuntu環境を引っ張りだしてきて、pathfinderをインストールしてみることにした。

以下、備忘録的に、、、

% aptitude install openssh-server
■ D-Busのビルドに必要そうなパッケージのインストール
% apt-get install -s dbus (1.1.20だったので古すぎ)パッケージは使わなかった
% apt-get install autoconf
% apt-get install automake
% apt-get install libtool
% apt-get install expat
% apt-get install libexpat1-dev
■ D-Busのビルド
% ./configure
% make >& make.log &
% tail -f make.log
% make install
■ WvStreamsのビルドとインストール
% ./configure
Configure: error: C++ preprocessor "/lib/cpp" と出たので以下を実行
% apt-get install g++
% apt-get install libssl-dev
% make >& make.log &
% tail -f make.log
% make install
■ pathfinderのビルドとインストール

途中、パッケージのインストール中で再起動を求められたんですが、再起動後ネットワークアダプタが認識されなくなってしまいました。orz

どうやらD-Busが悪さをしているようです。結局、pathfinderのインストールまで辿りつけませんでした。

かなり心が折れている、、、

たかがパス検証なのに、どうしてこんなにも、どうでもよいパッケージに依存しているのかと、、、

タグ：: #X.509; #パス検証; #C++; #ツール

2009年10月06日19:28

カテゴリ: PKI; OpenSSL

pathfinderという証明書のパス検証フリーウェア試用奮闘記(泣) (第1話)

本当はやらなければならないことが山積しているのに、現実逃避でpathfinderというRFC 5280のパス検証に準拠したフリーソフトが公開されたようなので早速試してみた。特徴はこんなとこらしい

・証明書の署名値検証
・名前チェーン検証
・基本制約の検証
・証明書ポリシの検証(含ポリシーマッピング)
・鍵使用法の検証
・OCSPによる失効検証
・ブリッジCAを含むパス検証にも対応しているっぽい
・AIA拡張によるパス構築も対応してるっぽい
・C++で書かれているっぽい。

ソースコードはここ(code.google.com)からダウンロードできるようで、今日の時点でバージョンは1.1.2(2009.09.23版)だった。

インストール

ソースコードのみの配布なので、ビルドしないといけない。cygwin環境でやることにする。以下のものが多分必要になる。
・g++
・cmake

インストール先はデフォルトでよいので(cmakeを使ったことないのに)cmake一発してみることにする。

% cmake .

あえなくエラーで敗退。何やらサードパーティーのライブラリとして
・D-Bus
・WvStreams
・OpenSSL (まぁこれはあるけど)
が必要なんだそうだ。

バージョンの指定も無いので仕方なくD-Busのサイトからdbus-1.3.0.zipをダウンロードした。雰囲気的にDebianならバイナリパッケージがありそうだった orz

同様にWvStreamsの公式サイトから辿って、wvstreams-4.6.1.tar.gzを落としてきた。

再戦(1)：WvStreamsのビルド

公式サイトのトップに親切にもビルド法が書いてあるので有難くその通りやる。

% tar -xzvf wvstreams-4.6.1.tar.gz
% cd wvstreams-4.6.1
% ./configure
% make (as root:)
% make install

で、"./configure"してみたんだけどエラーが、、、

configure: WARNING: DBUS is missing.
configure: WARNING: PAM is missing.
configure: WARNING: Qt is missing.
configure: WARNING: Valgrind is missing.
configure: WARNING: readline is missing.
configure: WARNING: both tr1/functional and boost/function.hpp are missing.
configure: error: Required dependencies missing: boost/function.hpp

tr1やらboostって何って調べてみるにC++の標準ライブラリの拡張案Technical Report 1の実装のようだ。最近、C++に疎いので全然しらなかった。つ～～か、なんでg++には入ってないんだろう、、、老人にはビルドは辛いので是非標準でTR1を実装して頂きたい。

段々、面倒臭くなってきたorz

Boostのインストール

Boostの公式サイト(www.boost.org)からバージョン1.40.0のアーカイブをダウンロードして(おいおいソースtgzで40MBもあるよ)ビルドしようとしたんですが、cygwinで良く見たらboostパッケージあったよ。有難くパッケージインストールする。cygwinを良く見ましたが、D-BusとWvStreamsはパッケージは無いことを確認した。

D-Busのインストール

WvStreamsはD-Busを使うようなので、D-Busから先にインストールすることにした。

% ./configure --prefix=/usr
% make
% su make install

でいけるそうだ。gettextとexpat or libxml-2を必要とするらしい。cygwinのlibxml-2-develパッケージをインストールした。

で、ええいっ、、、っと"./configure"してみるも"./configure"が無いじゃ～～～ん。autoconfなのかな。わからないのでcmakeディレクトリに下りて

% cd cmake
% cmake .

してみた。cmakeはうまくいったようだ。で、

% make

う～～む、ビルドエラーだ。

cmakeはだめみたいだ。"autoconf"にするか、、、、仕方なく、cygwinのautoconf、automake、libtool(libtoolizeが入っている)のパッケージを追加する。でコンフィグレーション用のスクリプトがあるようなので実行してみる。

% ./autogen.sh

MD4に関して警告が出たが無視してしまった。

Now type 'make' to compile dbus.

と出たので、どうやら"./configure"ファイルの生成と実行はうまくいったようだ。

% make

で、エラー。どうやらshared library版をつくるためのオプションが間違っているようだ。libtoolまわりの記述がいけないのかもしれない。面倒なのでstaticだけにしてしまう。

% ./configure --enable-static --disable-shared

で、

% make >& make.log &
% tail -f make.log

とりあえず、D-Busのビルドは順調に進んでいるように見える、、、と思ったらコケた。多分aclocal.m4、acinclude.m4のマクロが処理できていないっぽい。autoconfから戻るか。

さきほどの"autogen.sh"の実行時の警告では、

libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

と出ていたので、"configure.in"をいじって

修正前
AC_INIT(dbus, [dbus_version])
修正後
AC_INIT(dbus, [dbus_version])
AC_CONFIG_MACRO_DIR([m4])

とすることにして、再度 "autogen.sh" を実行した。警告は無くなり無事 "configure" が実行されたようだ。(毎回こんなことを書いている。)また、staticライブラリのみにするようconfigureを再実行してビルドする。

% ./configure --enable-static --disable-shared
% make >& make.log &
% tail -f make.log

う～むだめだエラーだ～～～。dbus-sysdeps-unix.cがダメっぽい。

D-Busをソースからcygwinにインストールするのは諦めることにする。

たまたま、D-Busをちょっと古いけどcygwinパッケージにして配っているところを発見したのでこれを使ってみることにする。

http://ftp.daum.net/cygwin/release-2/dbus/

URLを指定して普通にはセットアップできなかったので、パッケージファイル(.bz2)を手でダウンロードして、

- dbus-1.2.16-1.tar.bz2
- libdbus1_3-1.2.16-1.tar.bz2
- libdbus1-devel-1.2.16-1.tar.bz2
を /tmp などで
% bunzip2 -dc dbus-1.2.16-1.tar.bz2 | tar xvf -
して、
% cp -r usr /
% cp -r etc/dbus-1 /etc
etc/{postinstall,preremove}を参考に
% mkdir -p /var/lib/dbus
% /usr/bin/dbus-uuidgen --ensure

すれば、D-Bus 1.2.16のパッケージはインストールできたのではないかと思う。

長かった、、、orz

再戦：WvStreamsのインストール

WvStreamsのインストールに戻ることにする。

% ./configure

D-Busは1.2.14以上が必要なようだ。D-Busが使えるようになっていることを一応確認した。

configure: WARNING: DBUS is missing.
configure: WARNING: PAM is missing.
configure: WARNING: Qt is missing.
configure: WARNING: Valgrind is missing.
configure: WARNING: readline is missing.
configure: WARNING: both tr1/functional and boost/function.hpp are missing.
configure: error: Required dependencies missing: boost/function.hpp

相変わらず、D-Busが無く、Boostも無いと怒られたorz

% ./configure --with-dbus --with-openssl

pkg-configがいるみたいだぞ。cygwinのパッケージを追加した。段々、頭きた。相変わらずTR1かBoostでは怒られる。

cygwinのBoostのパッケージのインクルードファイルの場所を見てみたら

/usr/include/boost がないので
% cd /usr/include
% ln -s boost-1_33_1/boost boost

これで、ようやく configure はうまく通った(やれやれ)。ビルドしてみる。

% make >& make.log &
% tail -f make.log

あらら、、、再度 configure しちゃってる(泣)。気長に待つことにする。あらら、やっぱりダメだった。

./include/wvtask.h:27:22: ucontext.h: No such file or directory
./include/wvtask.h:57: error: `ucontext_t' does not name a type

cygwinはUser Thread Contextが実装されていないので"ucontext.h"も無いため、そりゃビルドできないわけだ。

うむむ、残念、今日はこれくらいで、、、

方法が他に見つからないようならcygwinはあきらめて、Debian(Ubuntu)でビルドしてみることにします。

タグ：: #X.509; #パス検証; #C++; #ツール

2009年09月01日19:35

カテゴリ: SSL証明書; 脆弱性

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(続き1)

前回は、BlackHatで紹介されたSSLサーバー証明書の対象ホスト名を格納するCN(common name)属性の処理の不具合を突いた脆弱性について紹介しました。

今日は、実際にテストサーバーを立ち上げてブラウザで接続するとどうなるのか試してみます。

Challenge PKI Test Suite(改)の機能追加

手持ちの状態のTest Suiteでは、証明書識別名のオブジェクト識別子について
(1) オブジェクト識別子のサブ識別子で大きな整数を指定すると桁が溢れる(機知のバグ)
(2) X.690に違反して0x80でパディングしてエンコードすることができない。
といった状態でした。
RDNの属性タイプを表す方法として以下のサポートを追加して、テストコードを追加しました。
(1) CN, OU, O, C, serialNumberなど属性タイプを名前で指定できる。(現行)
(2) 1.2.3.4 のように十進カンマ区切りでOIDを指定できる。(現行、桁溢れのバグ)
(3) #550403 のように16進数で属性タイプを指定できる。(機能追加)

証明書の生成

SSLサーバーのホスト名に以下の2つを仮定して発行します。

CN=www.evil3.jp: 悪意のある攻撃者が本当に所持しているドメインのホスト
CN'=www.good-bank.com: 詐欺対象のホスト

本来ならばCN(2.5.4.3=0x550403)であるようなOIDを、騙すためのニセのCN(CN')の作り方としては以下の2つで行います。

(1) 末尾"3"をX.690に違反して0x80(複数可)でパディングする(0x05048003)
(2) 末尾"3"を64bit整数で桁あふれした後"3"となる値とする。

方法(2)については、桁溢れする数を"0x010000000000000003"(9バイト)として、これをビット表現にし末尾より7ビットで分割してこれをバイトとし、末尾を除き8ビット目を1とし、"2.5.4."の部分を連結すると、0x82808080808080808003となります。

OpenSSL 0.9.8kではどう見える？

OpenSSLのコマンドではどのように証明書の識別名が表示されるのか確認してみたいと思います。

■コマンド
% openssl x509 -in 証明書 -noout -text
■OID末尾"3"が0x8003の場合(X.690違反のゼロパディング)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.3=www.good-bank.com
■OID末尾"3"が0x82808080808080808003(64bit整数桁溢れ)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.18446744073709551619=www.good-bank.com

CNモドキはちゃんと区別して表示されているようです。CNは2.5.4.3なんですが、0x80パディングされたものとはきちんと区別しています。(18446744073709551619は0x010000000000000003の10進数表現です。)

dumpasn1での表示

■本物のCN(common name)の表示

SEQUENCE {

  #06 03 55 04 03

  OBJECT IDENTIFIER commonName (2 5 4 3)

  #13 0C 77 77 77 2E 65 76 69 6C 33 2E 6A 70

  PrintableString 'www.evil3.jp'

  }



■ニセのCN①(X.690違反の0x80パディング)

SEQUENCE {

  #06 04 55 04 80 03

  OBJECT IDENTIFIER '2 5 4 3'

  #13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D

  PrintableString 'www.good-bank.com'

  }



■ニセのCN②(64ビット整数桁溢れ)

SEQUENCE {

  #06 0C 55 04 82 80 80 80 80 80 80 80 80 03

  OBJECT IDENTIFIER '2 5 4 3'

  #13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D

  PrintableString 'www.good-bank.com'

  }

①も②も表示上は本当のCNと区別できています。しかしながら②では、OBJECT IDENTIFIER '2 5 4 3'となってしまっており、整数の桁溢れが起きていることがわかります。

まずは正式な(悪い人の)URLに接続

ちゃんと正しくSSL接続できてますんで、これは問題無し。

FireFox 3.5.2でニセCNのホストに接続

それでは、次にX.690に違反して0x80でパディングしてあるニセCNのURL "https://www.good-bank.com/" に接続してみます。

おお、ちゃんと警告出ますね。エライ。
cnoid02-ff35-dlg

おお、ちゃんとダイアログまで、、、メッセージにも嘘が無くて好感が持てます。ちなみに証明書はこんな感じで表示されます。
cnoid03-ff35-crtdlg

ニセCNについて、文字化けのように表示されているので、まぁ、怪しいとわかります。

64bit整数桁あふれする場合でも、表示は同じだったので、キャプチャは割愛します。

Internet Explorer 8でニセCNのホストに接続

先週あたりにWindows Updateした、ほぼ最新だと思うIE8でニセCNのURLに接続してみました。
cnoid06-ie8-goodbank

一切警告なくニセCNのサイトに接続できてしまいますね。
cnoid07

証明書ダイアログで観てみるとX.690違反の0x80パディングでも整数桁溢れでも表示上はCN(common name)であるとして表示されてしまいます。

Google Chrome 2でニセCNサイトに接続

今日の時点で最新だと思うGoogle Chrome 2.0.172.43で同様に接続してみました。
cnoid09

こちらも警告なく接続できてしまいます。
cnoid10

証明書もwww.good-bank.com用で問題ないことになっちゃってますね。

Opera 9.5で接続

この他にOpera for Windows 9.50 build10063でも試してみたんですが、Opera自体がDNSで引けないホストは表示ができないような気がするんです(ローカルPCのhttp://192.168.1.133/等でも接続不能)。そのためテストできませんでした。

と、、、思ったら単に余計なプロキシが設定されていただけでした。すみません。疑ってゴメンヨ。気を取り直して接続してみます。まずは、(怪しいけど)正しいHTTPS接続。
cnoid-opera-02

まぁ、安全です(笑)。
cnoid-opera-03

次にニセCNのサイトに接続してみます。
cnoid-opera-04

ちゃんと親切な警告がでます。もうちょっと色が変わったりインパクトがある警告だといいんですけどね。

これも、どっちのニセCNでも結果は同じでした。

Operaの最新版は現時点で9.64だそうで、ちょっと古いやつですが、ニセCN OID問題についてはちゃんと対応されているってことで、、、

ruby + httpclient2

rubyとhttpclient2のモジュールでも試してみました。OpenSSLベースですが、ニセCNサイトに接続するとちゃんとエラーになってくれます。

/usr/lib/ruby/1.8/openssl/ssl.rb:123:in `post_connection_check': hostname was not match with the server certificate (OpenSSL::SSL::SSLError)

以上、こんな感じで実験報告でした。

ではでは

※注意：この記事のウィンドウキャプチャ画像は、余計な部分、空白などを除くためにトリミングしたり、空白の削除等の加工をしています。

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(2009.08.29)

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(続き1)(2009.09.01)>

タグ：: #BlackHat; #SSL; #証明書; #脆弱性; #識別名; #Nullターミネーション; #X.509

2009年08月20日18:37

カテゴリ: SSL証明書; OpenSSL

Black Hatの証明書Null Termination攻撃 (その4:番外編 Ruby編)

一連のNull Termination攻撃の記事の番外編として、Rubyのhttpclient2ならどうなのか、ちょっと試してみました。

ここにはこんなことが書いてあるので

Rubyのnet/httpsより
注意。net/https は RFC2818 の 3.1 に定められた「サーバーの証明書に記載された身元のチェック」を自らはしない。接続しているはずのサーバのホスト名と証明書に記載されているホスト名が一致するかをライブラリの使用者が各自実装する必要がある。

Rubyはホスト名の一致確認はしてないのかと思ったら、gotoyuzoさんや、nahiさんが「Ruby News 2007.10.04: net/httpsライブラリにおける「中間者によるなりすまし攻撃」に対する脆弱性について」に書かれている通り、ちゃんとホスト名の一致確認はしていると教えてくれました。

それではと、Ruby(のOpenSSL)ではNull Terminationの問題は起きないのかと確認してみました。OpenSSLではNullがあっても識別名の属性値は正しく"\00"のように取得できるので多分問題無いだろうと思うわけですが、、、

Rubyはちょっと書ける程度で殆ど素人同然なんで、いろいろ準備が必要です。いろいろ考えた挙句、簡単そうなんでこんな環境で試すことにしました。

・cygwin上のRuby 1.8.7-p72
・rubygemsを使う
・http-client2を使う

セットアップ

Rubyを足すとこまでは、cygwinのパッケージで普通にやって、

gemsを足すにはこのサイトからrubygems-1.3.5.tgzをダウンロードして解凍してインストールできます。

http://rubyforge.org/frs/?group_id=126参照
% tar xvfz rubygems-1.3.5.tgz
% cd rubygems*
% ruby setup.rb

http-client2は

http://raa.ruby-lang.org/project/httpclient/2.1.4
% gem install httpclient --source http://dev.ctor.org/download/

以上です。すごいなぁ、セットアップは簡単です。

で、接続

Null Termination証明書の設定されたニセサーバーを立ち上げといて、以下のようなRubyのプログラムを実行します。テストなんで、ルートだけ追加しとかないといけません。

#!/usr/bin/ruby

require 'rubygems'

require 'httpclient'

URL = 'https://test.ibm.com/' #ニセのホスト

clnt = HTTPClient.new

clnt.ssl_config.set_trust_ca("00-ECOM-TEST-ROOTCA-SIG.pem")

puts clnt.get_content(URL)

で、早速接続。

/usr/lib/ruby/1.8/openssl/ssl.rb:123:in `post_connection_check': hostname was not match with the server certificate (OpenSSL::SSL::SSLError)
　　from /usr/lib/ruby/gems/1.8/gems/httpclient-2.1.5.2/lib/httpclient/session.rb:260:in `post_connection_check'

とエラー表示され

test.ibm.com
と
Subject: C=JP, O=Evil2, CN=test.ibm.com\x00.evil.jp
とは一致しない

と、正しくエラーとなりました。さすが、nahiさんのhttp-client2は簡単だし、ちゃんとしてますねぇ。ちょっとRubyに改宗したくなっちゃいますねぇ(笑)

gotoyuzoさん、nahiさん、ありがとうございました。ｍ（＿　＿）ｍ

今日のつぶやき

httpclient簡単につかえてかなり良いんですが、set_trust_caとか証明書読み込む時、DERでもPEMでも読めるようになってると、凄くウレシイなぁと思いました。あと、別件でsqlite3-rubyを入れたいんですが、cygwin上でかなりてこずってます(泣)。この二つが解決すればムフフプロジェクトのPerlのやつをRubyに移すかなぁと思っているんですが、はてさて、どうなることやら、、、

タグ：: #BlackHat; #証明書; #X.509; #X.509証明書; #Nullターミネーション

2009年06月21日10:40

カテゴリ: PKI

米国GSAでSCVP

DigitalIDNews | GSA rolling out PKI validation service

The General Services Administration will unveil Central Certificate Validator program that will of perform certificate path discovery and validation (PD-VAL) in compliance with RFC 5280 in support of PKI-based authentication mechanisms described in FIPS 201.

だそうだ、、、

米国政府調達庁(GSA)では証明書の認証パス検証のための検証サーバーであるSCVPが使えるようになるそうです。CoreStreetなのかな、、、ちょっとおもしろそう。

タグ：: #X.509; #SCVP; #パス検証; #RFC; #RFC5055

2009年05月26日23:23

カテゴリ: PKI

Mac OS Xの証明書ビューアーったら、、、

最近、Miyakawaさんが適格証明書(QC:Qualified Certificate)の論文を執筆されていて、何回かドラフト見せていただいたり電話を頂いたりしてますが、Mac OS Xの証明書ビューアーの拡張領域の表示がオモシロイことになっているというので「そりゃ、是非見せてください」と言ったら快くブログにアップして下さいました。その画像がこちら、、、、

図1: Mac OS X証明書ビューアのキャプチャ (出典：Miyakawaさんのブログ(2009.05.26))

ぎゃぼ～～～～～、なんじゃこりゃ～～～～(笑)

条件付き証明書明細書(1.3.6.1.5.5.7.1.3)

「条件付き証明書明細書」って、あ～～た、自動車運転免許証の「眼鏡等」とかいう条件付の身分証明書の更新費用の明細書みたいに聞こえますよすね。どんな証明書拡張なんだっつ～～～の！！！

これはOIDからするにRFC 3979 3.2.6 Qualified Certificate Statements(適格証明書宣言またはQC宣言)という、「この証明書は適格証明書ですよ」っていうことをあらわす拡張なんですが

・Qualified(適格)→なぜか「条件付き」
・Certificate(証明書)→これは合ってる(笑)
・Statement(宣言)→これも、なぜか「明細書」

っていうような、物凄い訳語になっちゃってます。

他にも「証明書運用明細書」なんて記述があって、これって「お宅の認証局運用してあげるけど、今月の明細はこんな感じね、、、」みたいに読めちゃいますが、これって「Certification Pracitice Statement(認証局運用規定とか認証実施規定とか呼ばれる)」ってものです。何か別物に聞こえますよね。あと「証明書鍵識別子(2.5.29.35)」って、これ主体者鍵識別子(Subject Key Identifier)と勘違いされる方がいるかもしれませんが、これOIDからするに発行者鍵識別子(Authority Key Identifier)のことです。全く逆の意味になっちゃうんで止めて欲しいです。訳せないなら訳さなきゃいいのに、、、、、、

欧州委員会(EC)では、「電子署名に係る欧州指令」というのを発行しており、そこでは自然人の手書き署名と同等の法的効果を持つ電子署名を適格署名(Qualified Signature)と位置づけて、適格署名であるためには

(1)先進署名(Advanced Electronic Signature):証明書を持つ本人が署名したことを厳密に特定できる署名(CAdES・XAdES・PAdESなど)
(2)セキュアな署名生成デバイス(SSCD:ICカード、ソフトウェアトークン等)による電子署名
(3)そして自然人のみに発行する厳格な本人確認行った適格証明書(QC)を用いた電子署名

の3つが要件になっているわけですが、「条件付き証明書明細書」なんて訳された日には、欧州委員会の人もうかばれますまい、、、、

iPhoneの証明書ビューアーもなかなかマニアックなものまで対応していてスゴイとIさんが教えてくれたんですが、Mac OS Xと同じで物凄い訳のはずですよね、、、、、、(＞Iさんキャプって見せてくださ～～～い)

Miyakawaさんの持っている証明書、私も欲しいなぁ、、、と思って、ちょっと調べてみたらビンゴ、、、、リポジトリにありました。ベルギーのeIDは認証用と署名用と分けていて、スペインとかのと違って生体認証の情報は無いんですね。

上のキャプチャで表示されている証明書と同じ発行者のゲットできた証明書を覗いてみると、QC宣言拡張にはETSI TS 101 862 v1.3.3 (2006-01)で規定されている

id-etsi-qcs-QcCompliance 0.4.0.1862.1.1

があって、先ほどの欧州委員会(EC)の電子署名指令に準拠して発行された適格証明書を示す値が入っていました。

タグ：: #証明書; #X.509; #X.509証明書

2009年04月13日21:50

カテゴリ: PKI; Java

今更ながらNIST PKITS

NIST PKITS(PKI Test Suite) Path Validation Testing Programとは米国標準技術局(NIST:National Institute of Standards and Technology)で2004年に開発された、RFC 3280で規定された証明書のパス検証を正しく実装されているか確認できるテストケースのセットです。

ドキュメント、テスト用の証明書・CRL・リポジトリ(LDAPサーバー)・CMS署名データが公開されているので、誰でもダウンロードして試すことができます。量的には、

テストケース数	だいたい250
テスト可能な証明書チェーン数	224
証明書の数	405
CRLの数	175

というなかなか、ものすごいもので、こんなの手で一つ一つやっていたら日が暮れちゃうぐらいやり甲斐がのあるテストです。

Java系の実装でApache Ant+JUnitベースでテストしたい

Apache Antは言わずと知れたmakeコマンドの代わりとなるコンパイルやビルドなどしてくれる有難いツールです。JUnitはJavaの単体テストのフレームワークですね。

Challenge PKI Test Suiteでは、テストをゴッソリ動かすようなPerlスクリプトを作って動かしていましたが、既存のNIST PKITSで使おうとすると証明書やCRLなどテストデータをいちいちデータベースに投入する必要があってかなり面倒でした。

パス検証クライアントがJavaベースの時にAnt+JUnitの組み合わせでもう少しシンプルに、PKITSのディレクトリ構成を生かしながらテストできないかな、、、と考えていました。前のChallenge PKIが古いNISTのテストケースを参照にしていたので、新しい(といっても2004年ですが)テストケース、ファイル構成に対応させたいと思っていました。

SunのCertPathValidatorでちょっと気になっていたこともあったりしたので、昨日ちょっと時間があったので作ってみました。

実現方法

基本は、「PKITSをAnt+JUnitでパパッとやってレポート作成もそちらにお任せしたい」ってことです。テストの実施は、以下のような感じのテストケースの設定ファイルをJavaのpropertiesファイルで作ってテストさせます。設定ファイルには検証対象の証明書のチェーンと、CRLのファイル名が設定されています。

# t040101_ValidSignaturesTest1.cfg

path.crt.1=TrustAnchorRootCertificate.crt

path.crt.2=GoodCACert.crt

path.crt.3=ValidCertificatePathTest1EE.crt

path.crl.1=TrustAnchorRootCRL.crl

path.crl.2=GoodCACRL.crl

検証パラメータも同じくデフォルトをプロパティファイルで与えます。テストケースファイルにも例外を書けるようにしておきます。

input.initial-policy-set=2.5.29.32.0

input.initial-explicit-policy=0

input.initial-policy-mapping-inhibit=0

input.initial-inhibit-any-policy=0

で、このテストケース設定ファイルを250近く手で作るのはえらく面倒なのでテストケース設計書のPDFから自動で作れないかと考えました。テストケース設定ファイルの自動抽出では以下のようなことをします。

・pdf2text を用い PKITS.pdf のテストケース部分(4章)をテキストにする
・改行の乱れなどスクリプトで自動修正する
・サブサブセクション名からテストケース名を取得
・その中の記述より検証対象の証明書・CRL名を取得
・テストケース設定ファイルを生成

テストケース設定ファイル群よりパス検証をJUnitテストにより行うJavaのコードを自動生成するようなスクリプトを作りました。

JUnit単体テストのクラス

package pkits.auto;

import java.util.*;
import junit.framework.TestCase;
import pkits.util.*;

↓4.1章 "Signature Verification Test"の節のテスト
public class T0401_SignatureVerificationTest extends PKITSTestCase {
　public T0401_SignatureVerificationTest(String name) { super(name); }

　protected void setUp() {}
　protected void tearDown() {}

　↓4.1.1節 "Valid Signatures Test1" のテストを設定ファイルを指定し実行
　public void test_t040101_ValidSignaturesTest1() throws Exception {
　　doPKITSTestCase("t040101_ValidSignaturesTest1");
　}
　↑コレをテストケース数だけ
　：以下略
}

クラスの頭の部分を"T0401_"にしたり、テストメソッドを"test_t040101_"のように節番号を含むようにしておくと、テストケース結果のレポートが節の順にきれいに表示されるので良いと思います。

テストの期待値ですが、基本的にはテストケース設定ファイルの名前"*_Valid*"、"*_Invalid*" で有効、無効を判断します。但し、4.8節の証明書ポリシのテストなどでは、テストメソッドが"test_t04080101_AllCertificatesSamePolicyTest1"のようにValid/Invalidは書かれていなくて、一つのテストの中で1～4のポリシ処理の条件を変えてテストするので書かれていないわけです。これは、面倒ですが手で設定ファイルを分けてテストケース中に期待値を書くようにしました。

# t040801_AllCertificatesSamePolicyTest1.cfg

expectValue=INVALID

input.initial-policy-set=2.16.840.1.101.3.2.1.48.2

input.initial-explicit-policy=1

でCertPathValidatorを実際に動かす全てのテストの抽象親クラスを作って作業は大体おしまいです。

実行してみると、、、、

ここまでお膳立てできれば後は "ant test" 一発で動かすだけ。

% ant test

Buildfile: build.xml

init:

prepare:

     [echo] ----------- NIST PKITS Test Runner 0.9.1 [2009] --------

prepare-src:

prepare-resource:

compile:

test:

    [junit] Running pkits.auto.T0401_SignatureVerificationTest

    [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 2.139 sec

      ：中略

    [junit] Running pkits.auto.T0404_BasicCertificateRevocationTestsTest

    [junit] Tests run: 21, Failures: 1, Errors: 0, Time elapsed: 1.921 sec

    [junit] Test pkits.auto.T0404_BasicCertificateRevocationTestsTest FAILED

      ：中略

[junitreport] Processing reports\TESTS-TestSuites.xml to null507600500

[junitreport] Transform time: 2874ms

BUILD SUCCESSFUL

Total time: 45 seconds

250のテストケースで11個失敗、つまり期待値と不一致となっています。

失敗したのはどれもCRL関係のやつです。Sunの実装はIndirect CRLとかDelta CRLとかサポートしていないので、当然といえば当然、、、、

サポートしていないDelta CRLのテスト結果のさらなる詳細はこんなの。
Invalidのテストケースで無効になった場合には大抵CertPathValidatorExceptionなんですが、期待値通り例外が発生した場合JUnitの単体テストとしては成功で、するとどういう理由で例外発生したからテスト成功だったのかを結果表で表示させることができないんですよね。これは、ちょっと困ったところ。

仕方なく、標準出力を見たりします。

以上、こんな感じでApache AntとJUnitでNIST PKITS Path Validation Testを動かすことができ、集計結果の表示についてもほぼ満足できるものが完成しました。パチパチ（＾＾ｖ

いや～～、最初からXMLか何かでテストケース書いてくれれば苦労も少ないんすけどね、、、、

今回はJUnitはJUnit 3.8という古いのを使ったんですが、今はJUnitは4.5になっており、それよりもTestNGの方が注目されているそうです、、、、知らなかった、、、そろそろTestNGに切り替える時が来たのかも、、、、、

JUnit 4.xはテスト結果のErrorが無くなってSuccess/Failureだけになってしまったので、これはちょっと困ったもんです。TestNGもこれは同じっぽい？？？あとJUnit 4.xもTestNGもJava 1.5以降のアノテーション機能を使っているので、古いJava 1.4を使い続けなければならない場合にちょっと困っています。

タグ：: #NIST; #PKITS; #Path; #Validation; #test; #パス検証; #X.509

2009年04月02日20:47

カテゴリ: PKI; Java

Sun Java CertPathBuilderの例外のイケズ

あるデジタル証明書が信頼するルート証明書から辿って有効であるかどうか判定するために認証パス検証(Certification Path Validation)という処理を行います。

これは、HTTPSで保護されたサイトに接続する時やS/MIME署名メールを開く際に実は裏で行われているとっても重要な処理です。

Java ではCertPathBuilderとCertPathValidatorというクラスがあり、仕組み的にはX.509公開鍵証明書に限らず汎用的に証明書のパスが検証できたり、いろいろな会社の実装したアルゴリズム、実装方法が選択できるようになっています。

Sun Java にはRFC 3280準拠のパス検証実装が含まれており、これに基づくX.509証明書のパス検証ができるようになっています。

CertPathBuilderのSunプロバイダのPKIXアルゴリズム: 検証対象証明書、中間証明書、CRL、証明書やCRLを取得するLDAPディレクトリ、OCSPレスポンダの設定、トラストアンカとなるルート証明書群を指定することにより、自動的にパス構築と(狭義の)パス検証を同時に行うことにより検証対象証明書のパスが有効であるかを判定します。内部でCertPathValidatorの実装が使われているわけではありません。
CertPathValidatorのSunプロバイダのPKIXアルゴリズム: 検証対象証明書からトラストアンカとなるルート証明書の一つ手前までの証明書のチェーン(CertPath)を与えることにより、(狭義の)パス検証を行います。

Sun PKIXのCertPathBuilderのパス構築をザックリ図にしたのが以下、、、

pathbuild02

SunプロバイダのCertPathBuilderのPKIXアルゴリズム実装なんですが、これが、またちょっとイケズな実装になっていてエラーメッセージというか例外処理がとても不親切なんです。

パスを構築するための証明書が不足していたり、CRLが取得できなかったり、失効していたり、期限切れだったり、鍵用途が間違っていたり、中間CA証明書にあるべき基本制約のcAフラグがTRUEでなかったりすると例外が発生しますが、どんな理由であっても全く同じ

sun.security.provider.certpath.SunCertPathBuilderException: 

unable to find valid certification path to requested target

という例外メッセージが表示されます。これじゃ何がエラー理由だったのかさっぱりわからない（＾＾；メッセージ "unable to find valid ..." でぐぐってみると皆さんエラー理由がわからず困っておられる様子、、、、

CertPathBuilderExceptionクラスではgetCause()メソッドにより、その例外が発生した元の原因となる例外を取得できるんですが、Sunの実装では深さ優先探索のせいか？！不親切なのか？！これが設定されていないため、パス構築・検証に失敗した原因がわからないんです。

パスの深さ優先探索とは

SunのCertPathBuilderのPKIXアルゴリズムの実装ではパスを見つける際、幅優先探索と深さ優先探索のうち深さ優先探索が使われています。(人工知能系の方、Prolog系の方はよくご存知、、、（＾＾；)

以下のような少し複雑なPKIモデルで考えて見ましょう。

cpb01

ここでは信頼するルート証明書からエンドエンティティ証明書まで3通りのパスがあるんですが、そのうち2つは無効なパスになっています。

・ROOT→AAAのCA証明書は証明書有効期限が切れているので無効
・ROOT→BBBのCA証明書は基本制約にcA=TRUEが無いため無効

SunのCertPathBuilderでパス構築した場合の、パス構築で辿ってみた順序を図説したのが以下です。

cpb02

Sun実装ではエンドエンティティ証明書から始めてトラストアンカであるルート証明書まで深さ優先探索でパス構築を試みます。深さ優先とは、ぶっちゃけちゃうと「行ける所まで行く」、

踏み出せばその一足が道となり、その一足が道となる。迷わず行けよ。行けばわかるさ。ありがとう！

的なアントニオ猪木の名言の様なアルゴリズムです。

(1) エンドエンティティ証明書HHH←GGGからパス構築開始
(2) CA証明書 GGG←EEE、EEE←BBB を辿る。
　　　その際に都度、個々の追加される証明書に対して署名値、
　　　識別名前の一致、鍵用途、各種制約の処理失効検証などを行う。
(3) BBB←ROOT証明書の基本制約拡張にcA=TRUEが無いのでGGGに戻る
(4) CA証明書 GGG←DDD、DDD←AAA を辿る。
(5) BBB←ROOT証明書は期限切れなのでGGGに戻る。
(6) CA証明書 GGG←FFF、FFF←CCC、CCC←ROOT を辿る。
(7) トラストアンカまで辿れたので(6)が有効なパスとなり
　　　パス構築・検証は完了。

幅優先の場合、途中選択肢を全て抱えたまま探索するので多くメモリを消費すると言われています。そうした意味では深さ優先はまぁ、妥当かなと、、、

Sun PKIX CertPathBuilder実装の例外のイケズ

ただ、次のようなケースの場合、パス構築を試みて結局は有効なパスが見つからないため「unable to find valid certification path to requested target(要求された対象(証明書)に対する有効な認証パスが見つかりません)」ということになります。

cpb03

この際のCertPathBuilderException例外のgetCause()には何も入っていないので、何故パス構築・検証に失敗したのかは(普通は)謎のままです。せめてパス構築失敗の元を最後に起こした例外がgetCause()に設定されていれば結構理由がわかるもんなんですけど、残念ながらそうなってません。深さ優先探索なので「前の例外なんかいちいち保存しておくかぁ！！」という実装なんでしょう。

最後に発生した例外をgetCause()に設定するだけだと下のようなケースでは本質的な問題がわからないケースもあるんですが、まぁ、それは現状の何も無いよりはましみたいな感じで残しておいて欲しいなぁ、、、、

cpb04

パス構築で辿った順序が何故わかるか？

では、何故上の方の図でSun PKIX CertPathBuilderが辿ったパス構築順序がわかったかというとログを見たからなんです。CertPathBuilderやCertPathValidatorでは、以下のように "-Djava.security.debug=certpath"のオプションを付ければデバッグログが標準出力に表示されます。

% java -Djava.security.debug=certpath [CertPathを使ったJavaプログラム]

ただ、ここから出てくるログは今まで見てきたログの中では「中の下」ぐらいのダメさ加減で、多分観てもうんざりするだけだと思います。

で、パス構築で辿った順を観るには以下ようなdepthFirstSearchForwardの部分を見ればよいです。



certpath: SunCertPathBuilder.depthFirstSearchForward(CN=HHH, C=JP, State [

  issuerDN of last cert: null

  traversedCACerts: 0

  init: true

  keyParamsNeeded: false

  subjectNamesTraversed: 

[]]

)

・・・中略・・・

certpath: SunCertPathBuilder.depthFirstSearchForward(CN=ROOT, C=JP, State [

  issuerDN of last cert: CN=ROOT, C=JP

  traversedCACerts: 3

  init: false

  keyParamsNeeded: false

  subjectNamesTraversed: 

[CN=GGG, C=JP, CN=HHH, C=JP, CN=CCC, C=JP, CN=FFF, C=JP]]

)

これを観ていくとHHH→GGG→EEE→BBB×後戻り→DDD→AAA×後戻り→FFF→CCC→ROOT○と二度の失敗にもめげずに辿ったんだぁなぁ、、、頑張ったなぁ、、、、よしよし、、、という風に感慨深いものがあります。

ログを観てもAAA←ROOTやBBB←ROOTの証明書で基本制限に違反しているからとか、期限切れだからとか、そうした理由はログには全く書かれていません。

3本パスがあるうち何故その順序で選んだか？

HHH→GGGと辿って、次にEEE、DDD、FFFのどれを選んでも良いような気がしますが、必ずEEE、DDD、FFFの順序になりました。

証明書を探す際の入れ物としてArrayListをベースにしたCollectionCertStoreを使っていたんですが、そこに中間証明書を加える順序に依存しているのかもしれません。

結局 CertPathBuilder が出す例外は全く役に立たない

というわけで、Sun PKIX CertPathBuilderの吐く例外やログはというのは、どのような理由でパス構築・検証の失敗したのかわからないため使い物にならず、、ただ「unable to find valid certification path to requested target」の例外メッセージが空しくも得られるだけということがおわかり頂けたかと思います。

ではパス構築・検証がダメ理由を知りたきゃどうするか？

SSLサーバー認証では多くの場合SSLサーバー証明書・必要な中間CA証明書・ルート証明書がチェーンの形でごっそり送られてきますし、S/MIME署名メールやCAdES/XAdES長期署名の場合なんかも検証すべき証明書チェーンが概ねわかっている時があります。

自分で証明書チェーンを
・主体者・発行者の名前の一致で
・署名値の一致で
作ることもできることがあります。

そんなときは、自分で簡易パス構築で証明書チェーン作ってCertPathオブジェクトを生成し、CertPathValidatorで(狭義の)パス検証だけを行うのがいいように思います。

例えば、今回のケースで言えば

自前でパス構築だけして、パス検証はCertPathValidatorを使えば、

HHH→GGG→DDD→AAA→ROOTのパスの期限切れエラーなら

×失敗： timestamp check failed
×失敗理由詳細： NotAfter: Sun Jan 02 09:00:00 JST 2000

HHH→GGG→EEE→BBB→ROOTのパスの基本制約のcA=TRUE不足エラーなら

×失敗： basic constraints check failed: this is not a CA certificate

と、例外CertPathValidatorExceptionのgetMessage()で理由がわかってスッキリします。

今回はこれまたマニアックなネタでごめんなさいね。

自分でもパス構築してみたくなったら今回の証明書セットはこちらからダウンロードできます。

＜参考リンク＞
・Sun J2SE 6 - Java PKI APIプログラマーズガイド
・Sun J2SE 6 - Java暗号化アーキテクチャー(JCA) リファレンスガイド
・Sun J2SE 6 - java.security.certパッケージ
・IPA: 電子政府情報セキュリティ相互運用支援技術の開発
　・GPKIアプリケーション実装ガイド報告書 (PDF 831KB)
　　　5章：Javaによる証明書パス構築・パス検証の実装の説明

タグ：: #X.509; #パス検証; #Java; #JCE; #JSSE; #SunJava; #CertPathValidator; #CertPathBuilder; #証明書検証; #図説

2008年09月28日09:35

カテゴリ: PKI; プログラミング

OpenSSLで対応しているDirectoryStringType一覧

自堕落な技術者の日記 : OpenSSLでNumericStringの入った証明書が読み込めない - livedoor Blog（ブログ）

RFC 3280では規定外になりますが識別名にNumericStringを含む証明書を作ってみて、そのPKCS#12を作ろうとOpenSSLで読み込ませてみたら見事にエラーになりました。

前のブログでOpenSSLでNumericStringを識別名に含む証明書を読み込むとエラーになると書きましたが他はどうなのか(別の調査のついでに)調べてまとめてみたのが以下です。

DirectoryString Type	Tag	OpenSSL サポート※1	RFC3280 Issuer※2	RFC3280 Subject※3
UTF8String	0c	○	○	○
NumericString	12	×	×	×
PrintableString	13	○	○	○
TeletexString	14	○	○	○
VideotexString	15	×	×	×
IA5String	16	○	×	○
GraphicString	19	×	×	×
VisibleString	1a	×	×	×
GeneralString	1b	×	×	×
UniversalString	1c	○	○	○
BMPString	1e	○	○	○

※1: OpenSSL 0.9.8hで証明書識別名で使われているものを読み込んだ際、エラー終了しなければ「○」
※2: RFC 3280 4.1.2.4でIssuerに使ってよいとしているDirectoryString Typeであるか
※3: RFC 3280 4.1.2.6 SubjectではIssuerのものに加え過去との互換性からメールアドレスにIA5Stringをつかってもよい。

X.680で定義されている文字列を扱うプリミティブをリストにしました。OpenSSLは0.9.8hで確認しました。RFC 3280でサポートされているDirectoryString Typeしかサポートしてないんですね。

読めなかったときのエラーはこんな感じです。

% openssl x509 -inform DER -noout -txt -in EE-ECOM-XMLDN-DS-VIDEOTEX-ASCII.cer
unable to load certificate
24264:error:0D07808C:asn1 encoding routines:ASN1_ITEM_EX_D2I:mstring wrong tag:tasn_dec.c:228:Type=ASN1_PRINTABLE
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=value, Type=X509_NAME_ENTRY
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:710:
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:710:
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=issuer, Type=X509_CINF
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=cert_info, Type=X509

タグ：: #OpenSSL; #NumericString; #TeletexString; #UTF8String; #GraphicString; #識別名; #X.509; #証明書; #ASN.1

記事一覧(手作り)

はてなブックマーク
された記事