自堕落な技術者の日記 : ルート認証局リスト

ルート認証局リスト

2017年03月07日23:20

カテゴリ: PDF署名; ルート認証局リスト

追悼 Adobe CDS

PDF署名の利用拡大につながると、密かに期待していた、とても先進的なサービスだったAdobe CDSが、いよいよサービスを終了し、AATL (Adobe Approved Trust List)に移行すると知りました。まぁ、移行とは言えず、いろいろなものを捨て去っているわけですが、、、かつて自分も人柱としてAdobe CDS対応の証明書とトークンを購入し、使ってみたりもし、幾つかブログで書かせてもらい、良いサービスだったのですがとても残念です。悲しすぎるので追悼記事のようなもの書いてみたいと思います。

Adobe CDSとは何か

Adobe Acrobat には誰が署名をしたか、それが改ざんされていないかを示すためのPDF署名機能があり、Adobe Acrobat ReaderにはPDF署名の検証機能がついています。PDF署名の運用を厳格化し、Adobe Acrobat Readerのデフォルトであっても、ちゃんと本人確認をした証明書とハードウェアデバイスをつかって署名したPDF署名が検証できるようにするサービスがAdobe CDSでした。Adobe CDSには

HSMを使った組織によるサーバー向けPDF署名
USBトークンを使った個人によるPDF署名

の2種類に対応していました。ただのPDF署名とはどう違うのか、比較表にまとめてみました。

一般的なPDF署名	Adobe CDS PDF署名
証明書発行の際、本人確認をしようがしまいが構わない	証明書発行の本人確認はかなり厳格。例えば、パスポートのコピー、メールアドレスの送付と電話による(英語での)本人の意思確認など
秘密鍵の管理はなんでもよい	秘密鍵は必ずサーバー型ならHSM、個人型ならUSBトークンに格納され、エクスポート不可。(スマートカード対応の認証ベンダーはなかったはず。)
証明書はデジタル署名が可能ならなんでも良い。例えば、SSLサーバー証明書と秘密鍵でもよい	Adobe CDS署名専用の証明書であり、拡張領域に専用の拡張がある。証明書ポリシもCDS対応のものでないとAdobe CDSに登録できるCAとはならない。
PAdESタイムスタンプつきPDF署名である必要はなく、普通のPDF署名でもよい	署名するとPAdES署名タイムスタンプ付きのPDF署名となる
タイムスタンプをつけようとする場合、日本では一般に別途、タイムスタンプ事業者との利用契約が必要	Adobe CDS対応の認証局では、証明書を購入すればタイムスタンプサービスが合わせて提供される。Adobe CDSでは、認証サービスごとに、どのタイムスタンプサービスを使用するかが、証明書拡張に記載されており、固定である。認証サービス自体がタイムスタンプサービスを提供しているケースが多い。
信頼するルート証明書のリストはAdobe独自のものだった。この度これが、Adobe Approved Trust List(AATL)というルート証明書プログラムとして定義され、現時点で58のルート証明書が登録されている。WindowsやMac OS Xなどのルート証明書の数は400程度とこれよりかなり多いが、OSの持つルート証明書はAcrobat Readerのデフォルトでは信頼しておらず、これを信頼するようにするには設定変更の必要がある。	Adobe CDSのルート認証局はAdobeのルート一つであり、中間認証局としてAdobe CDS対応の認証ベンダー6つ程度があり、そこからユーザ用の証明書が発行される。Adobe CDS用の専用の運用ポリシ(CP/CPS)で運用されている。どのようなOSのAcrobat ReaderでもOSのトラストリストに関係なく同じ検証結果となる

Adobe CDSサービスのポイントは以下のようになると思います。

確かに本人が署名したと見なせる印鑑で言えば実印レベルのPDF署名ができる
(最近いろんな認証局が問題起こしていますが)運用のしっかりしていない認証局が紛れ込む可能性が比較的低い(けど、この中にも問題起こしたところありましたよね)
Adobe CDS専用の証明書で署名する
電子署名では、証明書が有効だった時刻に署名されたことを示すために、タイムスタンプが必須とされるが、Adobe CDSではデフォルトで署名タイムスタンプつきPDF署名となる
USBトークンなどのハードウェアデバイスを持っているはずの本人署名できず、他人がなりすまして署名をされる可能性は極めて低い

Adobe CDSのナイスなところ

タイムスタンプ付きPDF署名をしようとした場合に、日本では一般に署名用のクライアント証明書と、タイムスタンプサービスの利用がそれぞれ必要になります。これって、それぞれお金がかかるし、煩わしいですよね。日本でタイムスタンプ付き署名が流行らない理由の一つなのではとも思ってたりもします。海外の署名用証明書発行サービスでは、タイムスタンプサービスとセットで提供するものが多いですし、Adobe CDSもセット提供で、とても使いやすいです。

コード署名用証明書なんかも、RFC 3161タイムスタンプとは違いますが、似たようなカウンタ署名によるタイムスタンプの仕組みがセットで提供されるので、デフォルトでコード署名にはタイムスタンプがつきます。

Adobe CDSの何がいけなかったのか

Adobe CDSを使っているかどうかで、PDF署名に対する信頼の度合いは全く異なると思うのですが、Acrobat Readerでは、普通のPDF署名とAdobe CDS PDF署名との違いはありません。違いもないのなら、高いお金を払ってまでAdobe CDSを使うメリットも薄いですよね。

また、認証局にとっても、独立した中間CAを運用しなければならない。特別な証明書プロファイルも必要で、認証局にとってもとても負担となるプログラムだったと思います。相当利用が伸びないとサービスを維持するのは難しいと思います。

Adobe CDSのようにUSBトークンを使ったり、マイナンバーカードのようにスマートカードを使ったり、ハードウェアデバイスを使用して、厳格な本人確認のもと発行された証明書に関しては、共通の専用の証明書拡張を持たせるようにし、普通の署名とは区別し、EV証明書の緑のアドレスバーのような表示上の区別をしないと、ハードウェアデバイスを使った署名がなかなか普及しないのかなとも思います。

最近では、クラウド上で秘密鍵の管理をし、リモートで署名を行うような運用形態も増えており、ハードデバイスを本人が管理して署名するというのは、だんだん時代にも合わなくなってきたのかもしれません。

おわりに

Adobe CDSは、維持費用も結構かかるので、結局持ち続けることはできませんでしたが、「実印レベルのちゃんとした」PDF署名であるAdobe CDSは、なくなって欲しくはなかったです。ホントさびしい。バイバイ Adobe CDS。

タグ：: #Adobe; #CDS; #タイムスタンプ; #ルート認証局リスト; #トラストリスト; #USBトークン; #PDF署名; #PDF; #Acrobat; #AdobeCDS

2015年05月03日10:19

カテゴリ: SSL証明書; Windows

Windowsルート証明書の更新プログラム(2014.09)と戯言など

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15～25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。
country

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。
keylen
RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね～～。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。
osroot
iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
Macのテキストエディタで開きUTF-16で保存する。
MacのExcelでインポートする。
インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
ルート証明書リストのExcelが完成！！！ (泣)
ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。
windialog
なんかこう、あれです、411もあるわけですから、フルコンプしたいですよねぇ？先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや～、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ～か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？

ちょっと遠い関連記事

タグ：: #ルート認証局リスト; #トラストアンカ; #Windows; #Windowsルート証明書プログラム; #iOS; #Android; #MacOSX; #RootCAViewerLite

2013年11月10日17:11

カテゴリ: Android; ルート認証局リスト

Android 4.3.1 と 4.4 KitKatのルート証明書リストの違いを見てみたぞ

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

で、比較してみると

差分はこんな感じ。

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

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

新規追加されたのは

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

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

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

今日はこのへんで

タグ：: #Android; #Root; #CA; #ルート証明書; #Nexus; #5; #4.4; #KitKat; #ルート認証局リスト; #トラストアンカ

2013年11月06日08:25

カテゴリ: Android; ルート認証局リスト

Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ

熱があって体調激悪ですが、なんか書いてみましたの第一弾です。

4.4 KitKatが出る前に、手持ちのAndroid 4.0.4と4.3.1の信頼するルート証明書のリストの魚拓(=バックアップ)を取っておこうと Root CA Viewer Lite(for Android 4.x) に手を加えてみたんですが、別の会にでもお話をしようと思うハマったポイントがあり紆余曲折の末、まぁ何とか半日かけてアップデートができたわけです。

今回のRoot CA Viewer Lite 1.2.2の機能追加では、Android 4.xのルート証明書をシステム登録されたものも、ユーザ追加したものも全てASN.1 DERバイナリ形式で取り出し、ZIPで固めてこれをSDカードの領域にエクスポートするというものです。 (本当は処理中のグルグルとか表示させないといけないんでしょうけど、手抜きでホントすみません。)

で、比較してみると

これで無事、ルート証明書は取り出せるようになったので、比較してみましょう。差分の個数はこんな感じ。

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

古いXperiaの時にもルート認証局のリストを調べていますが、その時はAndroid 1.6 で 52のルート認証局でしたその時から比べて随分増えていますよね。

新規追加されたのは

以下が、新規に追加された12個のルート認証局の一覧です。欧州が多い感じがありますが、セコムトラストさんも追加されてますね。ほぼ、SHA256withRSAなんだなぁっていうのが特徴的かなと思います。

認証局の識別名(DN)	有効期間	署名アルゴリズム	RSA鍵長
CN=D-TRUST Root Class 3 CA 2 2009,O=D-Trust Gmbh,C=DE	2009-2029	SHA256withRSA	2048bit
CN=T-TeleSec GlobalRoot Class 3,OU=T-Systems Trust Center,O=T-systems Enterprise Services GmbH,C=DE	2008-2033	SHA256withRSA	2048bit
CN=Buypass Class 3 Root CA,O=Buypass AS-983163327,C=NO	2010-2040	SHA256withRSA	4096bit
CN=Swisscom Root CA 2,OU=Digital Certificate Services,O=Swisscom,C=CH	2011-2031	SHA256withRSA	4096bit
CN=Izenpe.com,O=IZENPE S.A.,C=ES	2007-2037	SHA256withRSA	4096bit
CN=Certinomis - Autorité Racine,OU=0002 433998903,O=Certinomis,C=FR	2008-2028	SHA1withRSA	4096bit
CN=Buypass Class 2 Root CA,O=Buypass AS-983163327,C=NO	2010-2040	SHA256withRSA	4096bit
CN=EC-ACC,OU=Jerarquia Entitats de Certificacio Catalanes,OU=Vegeu https://www.catcert.net/verarrel (c)03,OU=Serveis Publics de Certificacio,O=Agencia Catalana de Certificacio (NIF Q-0801176-I),C=ES	2003-2031	SHA1withRSA	2048bit
CN=A-Trust-nQual-03,OU=A-Trust-nQual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT	2005-2015	SHA1withRSA	2048bit
OU=Security Communication RootCA2,O=SECOM Trust Systems CO.,LTD.,C=JP	2009-2029	SHA256withRSA	2048bit
CN=D-TRUST Root Class 3 CA 2 EV 2009,O=D-Trust GmbH,C=DE	2009-2029	SHA256withRSA	2048bit
CN=Root CA Generalitat Valenciana,OU=PKIGVA,O=Generalitat Valenciana,C=ES	2001-2021	SHA1withRSA	2048bit

変更されたのは???

認証局の識別名(DN)	有効期間	署名アルゴリズム	RSA鍵長
CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA	1996-2021	SHA1withRSA	1024bit
CN=Thawte Server CA/emailAddress=server-certs@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA	1996-2021	SHA1withRSA	1024bit

両方ともThawteのやつなんですが、証明書の変更された差分を見てみると、認証局の鍵は1024bitのやつ同じものを使ったまま、署名アルゴリズムをMD5withRSAからSHA1withRSAにして、有効期限を1年延ばして、シリアル番号を変更して証明書をロールオーバーしちゃってます。鍵長もそうですが、同じ鍵を使い続けててこれ、ホント大丈夫なんですかね。運用規定違反になったりしないのかな。

おまけ

Root CA Viewer Liteで証明書をエクスポートすると、個々の証明書のファイルは「system_4fbd6bfa.0」みたいない感じになっており、JCEの証明書ストアの証明書のalias 「system:4fbd6fa.0」に対応しています。「4fbd6fa.0」はOpenSSLの認証局の証明書ファイルの保管方法によるもので、証明書の識別名のハッシュみたいなものから作られています。この名前の決まり方はJNSAのセミナー「OpenSSL 1.0.0のリリースについて」でお話しており、スライドのページ番号32、33をご覧頂ければと思います。この記事思い出して確認したんですが、ハッシュファイル名は -subject_hash_old の方、つまりOpenSSL 0.9.8ベースのハッシュファイル名になったままのようですね。とはいえ、ベースとなっているOpenSSLは0.9.8とは限らないので、どのなのかは調べる方法あるんですかね。

今日はこのへんで

タグ：: #Android; #ルート証明書; #ルート認証局; #ルート認証局リスト; #トラストアンカ; #RootCAViewerLite

2012年10月24日22:00

カテゴリ: Android; ルート認証局リスト

(小ネタ)Root CA Viewer Lite for Android(Free)の公開

JCE Provider Checkerに引き続き、 Android 4.0以降のルート証明書ストアを表示させるためのツール"Root CA Viewer Lite (for Android)"という無料アプリを昨日公開しました。

rootcaview1

標準機能でもルート証明書ストアは見られるんですが、国名、組織名、部署名といった証明書の識別名の一部と有効期間、フィンガープリントぐらいしか見られないんですよね。「それじゃあ証明書の特定はフィンガープリントでしかできないだろー!!!」みたいな••• いくつ証明書が入っているのかも地味に数えないとわからないし•••

とりあえずJavaのX509Certificateクラスをベースに証明書の基本領域、拡張領域など取得可能なものは表示できるようにしました。

識別名は文字列で処理してんるんですが、 emailAddressやserialNumberなどのマイナーな属性の相対識別名が OID.1.2.840.113549.1.9.1=#1615616161... みたいな表現になっちゃってたやつを文字列処理で "E=hoge@hoge.com"みたいに見やすいように変換しています。

このツールの残念なのは、 Javaの標準機能だけだとサポートしてない拡張領域の解析が面倒臭くてやってないのと、楕円の証明書の鍵長が取得できないんですよね。拡張領域の並び順もわかんなくなっちゃうし、、、その辺りはちょっとプログラムサイズの大きい無料の PRO版出すかなと思っているので乞うご期待ってことで、、、

クリティカルフラグの表示が"[!]"はクリティカル、"[-]"はノンクリティカルとかダサ過ぎるのと、基本領域を表すListViewの要素が"*** BASIC FIELD ***" ってダサ過ぎるので、このあたりは色づけしたりアイコンつけたり何とかしたいと思ってます。 (時間があればorz) しっかし、JCE Provider CheckerもRoot CA Viewerも同じようなListViewの見てくれで芸が無いっすねぇorz。

またDigiNotarと似たような事件とか勃発して「おーい、どのルート証明書を無効にしていいのかよくわかんないよー」とかいうときに思い出して活用していただければと思います。

ではでは

タグ：: #ルート認証局リスト; #トラストアンカ; #ルート証明書; #Android; #RootCAViewerLite

2012年09月04日21:52

カテゴリ: ルート認証局リスト; Android

(小ネタ)Android 4.0 ICSのルート証明書ストア

「恥の多い生涯を歩んできました」

最近、私はPKIな人ではなく、雑用に忙殺される悲しい毎日を送っております。先日、同僚にそそのかされ「中華パッド」なるものを買ってしまいサルのように喜んでつかっております。

組み込みのルート証明書ストア

何やら、Android 4.0 ICSになってからルート証明書ストアの方式が変わってしまったそうで、BouncyCastleプロバイダのJava Key Storeだったものが、OpenSSLのそれに変更になったそうです。

■Android 4.0 より前のルート証明書ストア
/system/etc/security/cacerts.bks ファイル
■Android 4.0 以降のルート証明書ストア
/system/etc/security/cacerts ディレクトリ

ディレクトリの中を覗いてみると、各ルート証明書はPEM形式で、 "00673b5b.0" みたいなファイル名で、まさにOpenSSLの"ca"コマンドで使われるハッシュファイル名形式になっています。

OpenSSL 1.0.0 コマンドでハッシュファイル名の計算方法を見てみましょう。

% openssl x509 -in 00673b5b.0 -hash -noout
2e4eed3c ←うーん一致しない

% openssl x509 -in 00673b5b.0 -subject_hash_old -noout
00673b5b ←おお、一致した

ということは、OpenSSL 1.0.0 で導入されたハッシュファイル名の計算方法ではなく、OpenSSL 0.9.8とかの古いハッシュファイル名の計算方法でファイルが置かれていることがわかります。

初期状態でのルート証明書の数は134個で、最近の多くのブラウザやOSからしてみると割と少ない方かもしれませんね。

ユーザが追加した認証局証明書ストア

前述のストアはシステム組み込みの認証局証明書ストアなようで、例えばPKCS#12などを読み込んだ際の中間認証局証明書は上の場所には入らずに別の場所に入ります。

/data/misc/keychain/cacerts-added/

ユーザの秘密鍵と証明書、パスワードのストア

ユーザの秘密鍵と証明書、パスワードは下記のフォルダに保存されます。

/data/misc/keystore/

クレデンシャルには名前をつけて保存されますが、秘密鍵、ユーザ証明書、ルート証明書までのチェーンはそれぞれ下記のファイル名で保存されているようです。ファイル形式は独自のバイナリで、先頭4バイトが0である以外は、どのようにそれらが作られているのかはわかりませんでした。

番号_USRPKEY_名前
番号_USRCERT_名前
番号_CACERT_名前

otacerts.zipファイルの謎

ちなみに、cacertsディレクトリはotacerts.zip なるファイルがあり何が入っているのか気になったので覗いてみました。ただ testkey.x509.pem というマルチRDNの自己署名公開鍵証明書が入っているだけなんですが、

DN: C=US, ST=California, L=Mountain View, O=Android, OU=Android, CN=Android/emailAddress=android@android.com

公開鍵の公開指数がいまどきセキュリティ上問題のある3なのがちょっと気になるところでしょうか。

あと、古いOpenSSL 1.0.0より前のやつでみると有効期間がだと化けちゃうのかなぁと思って見てみたら

Not Before: Feb 8 09:29:20 2012 GMT
Not After : May 21 03:01:04 1903 GMT　＜＜これ

ASN.1レベルでも

UTCTime '120208092920Z'
GeneralizedTime '19030521030104Z'

本当に開始が2012年で終了が1903年というものすごい証明書でした。いろいろ突っ込み所がある証明書を入れとく意義って何なんすかねぇ？

今日はこの辺で

タグ：: #Android; #ICS; #ルート認証局リスト; #トラストアンカ; #ルート証明書; #RootCAViewerLite

2010年04月26日23:15

カテゴリ: ルート認証局リスト; Xperia

初代Xperia(Android 1.6)に搭載されたルート認証局証明書

前回からの続きで、docomoのスマートフォンXperiaについて調べています。今回はXperiaに搭載されている信頼するルート証明書について書こうと思います。

XperiaのOSは2009年9月15日にリリースされたちょっと古めのAndroid 1.6なんだそうです。ルート証明書の一覧は "/system/etc/security/cacerts.bks" にあり、ファイルを取り出すにはAndroid SDKのツールを使って母艦にコピーします。

% adb pull /system/etc/security/cacerts.bks cacerts.bks

"cacerts.bks"はJavaのkeytoolで扱える証明書ストアになっているんですが、BouncyCastle JCEライブラリ専用の証明書ストアになっているので、これを指定して取り出します。

で、ルート証明書の一覧を見てみたところ、こんな感じでした。

全部で52のルート証明書が登録されており、Windowsの297に比べてかなり少なめ、下のリストのSun Javaと見比べるとやや古いSun Java J2SE 6.0 Update 5ぐらいの時期のルートをもとにしているのかもしれません。

Sun JDK 6.0 update 19 - 75
Sun JDK 6.0 update 18 - 72
Sun JDK 6.0 update 7 - 55
Sun JDK 6.0 - 43

登録されているルート証明書をみてみると、ほとんどが2009年11月のMicrosoftのWindows Root Certificate Programに含まれている証明書なんですが、3つだけ

Global Sign Root CA (C=BEのもの)
StartCom Free SSL CA
Sony Ericsson Secure E2E CA

だけがプログラムに含まれないAndroid独自の証明書のようです。(ソニエリ以外はSun Javaには入ってたのかな？)。Global Sign Root CAのkeyUsageのエンコーディングで警告がでますね。時間があるとき、見てみます。

ソニエリが入っているってことは、cacerts.bksは、Android OSに共通なものではなくて、機種毎に違うものなのかもしれませんね。

今日はこんなところで、、、

追記：GlobalSignのkeyUsageの警告

古いGlobalSignのルート証明書でkeyUsage拡張のエンコーディングで警告がでるので見てみました。ASN.1 BIT STRING型の値としてはkeyCertSign(5)とCRLSign(6)のビットが立っていて最上位が一つビットが立たないのでunused bitsが1になり、正しくは

03:02:01:06(BIT STRING 1 unused bits '1100000'B)

となるところが間違えて

03:02:00:06

となっちゃっているのでエンコーディングの警告が出ていたのでした。古い証明書ではたまにこんな間違いがありますよね。

タグ：: #ルート認証局リスト; #トラストアンカ; #ルート証明書; #Android; #Android1.6

記事一覧(手作り)

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