自堕落な技術者の日記 : 暗号 - livedoor Blog（ブログ）

暗号

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

2014年09月12日23:23

カテゴリ: 暗号; SSL証明書

ChromeのSHA1証明書のアラート表示ポリシの問題点

SHA1withなんとかで署名されたSSLサーバー証明書に対するGoogle Chromeの将来の取扱いポリシについて、Googleのブログで9月5日に情報公開され、ちょっとビックリした人も多いんじゃないでしょうか。私は、「こりゃちょっと問題だなぁ。」と思ったので今日はブログで書いてみようと思います。

SHA1が充分な暗号強度がなくなりつつある話

暗号の専門家ではないので、よくわからないのですが、例えばコレなんかをみてみるとSHA1ハッシュアルゴリズムの暗号強度が充分でなくなってきていると言われており、暗号に関する日本で主要なガイドラインであるCRYPTREC暗号リストではSHA1は「運用監視暗号リスト」、危殆化リスクが高まっているが互換性維持のため仕方なく使って良いリストに入っています。

このような状況を受けて、製品ベンダー、証明書発行サービスなどのサービサーなどはSHA1からSHA2への移行をようやく始めたところなのかなと思います。

米国の標準化機関であるNISTは2011年1月に「NIST SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lenghs(暗号アルゴリズムと鍵長の使用に関する勧告)」を発行しており、その中で「SHA1を使った署名の生成と検証は2013年12月31日以降、認められない。」としていますが、NIST内でもSHA1証明書を使ったサイトがまだ残っているそうで、「自分も守れてないじゃ～～ん」みたいな状態になっているそうです。

2013年11発表のMicrosoft製品のSHA1移行ポリシー

幾つかの業界や製品では先行してSHA1からの移行ポリシーを策定、公表しているものもありますが、SSLサーバー証明書に関しては幅広い製品やサービスで使われ、SHA1を使っている比率も高く移行は難しいのだろうと思います。本来ならCA Browser ForumのBaseline Profileで規定されてもよかったのだろうと思いますが、SHA1からの移行については言及されていません。そんな中、2013年11月12日に発表されたMicrosoft製品に関して公開された2つのSHA1移行ポリシーはちょっと衝撃的でした。

Windows Root Certificate Program - Technical Requirements version 2.0: このプログラムはWindows製品の「ルート証明書プログラム」という、Windowsの信頼するルート証明書に加えてもらうためには、どのような基準を満たさなければならないかを定めたものですが、「対象の認証局は2016年1月1日以降、SHA1証明書を発行をしてはならない。」としています。
Windows PKI Blog: SHA1 Deprecation Policy: 「Windows製品では2017年1月1日以降、SHA1のSSLサーバー証明書を受理しないためエラーとなる。」としています。すなわち、Windows製品でSSLを使えるようにするには、SHA1 SSLサーバー証明書を2016年12月31日までにSHA2にリプレースしなければならないという事だそうです。

SHA1 証明書がそろそろ偽造の危険性があるという認識も高まっており、充分な猶予期間もありますし、その頃には、SSLサーバー証明書を扱う全ての製品のSHA2対応もかなり進んでいるでしょうから、よく考えられた妥当なスケジュールなのかなと思います。

これに関して注目すべきポイントは以下の2つかと思います。

中間CA証明書やルート証明書のSHA1については言及していない。
2016年1月1日と、2017年1月1日という2つのマイルストーンを守りさえすればよい。

このMicrosoftのSHA1移行ポリシーのアナウンスを受けて、主要なSSL証明書発行サービスは、SHA1証明書の発行は2015年12月31日までとアナウンスをしています。

2014年9月5日に公開されたGoogle ChromeのSHA1 証明書対応ポリシー

2014年9月5日に「Google Online Security Blog: Gradually sunsetting SHA-1」にて、Google ChromeのSHA-1証明書にするポリシーの変更が発表され、一部の人は驚きを持って読んだのではないかと思います。 ITmediaエンタープライズでも「Google、「SHA-1」サポート中止のスケジュールを発表(2014.09.08)」として紹介されました。(何点か間違いがあるので、原文を参照するのがいいでしょう。)

これは簡単に言ってしまうと、「SHA-1のSSLサーバー証明書によってHTTPSの接続表示を近々(大きく)変えますよ」というアナウンスです。

Google ChromeのHTTPSステータス表示

Google ChromeのアドレスバーにおけるHTTPSのステータス表示は以下のようになっているようです。

表示	内容
	EV証明書でない正常なHTTPS接続の場合
	secure, but with minor errors 例えばHTTPSとHTTPのコンテンツの混在の場合などに出る。
	neutral, lacking security 平文のHTTPなど、セキュリティが無い中立の状態。
	affirmatively insecure 危険だと断言できる場合。
(参考) EV SSLサーバー証明書で正常にHTTPS接続できている場合

Google Chromeは証明書チェーンがSHA1かどうかチェック

WindowsのSHA1移行ポリシーはエンドエンティ証明書、すなわちSSLサーバー証明書がSHA1かどうかだけをチェックしており、中間CA証明書がSHA1かどうかは関係無かったのですが、Google Chromeの移行ポリシーは、全ての中間CA証明書もチェックするので注意しなければなりません。

で、ChromeでSHA1証明書でHTTPS接続した場合どうなるのか？

9月5日に発表された、ChromeでSHA1証明書にHTTPS接続した場合のURLアドレスバーのHTTPSステータス表示が、この半年で3回出てくるChromeのバージョンによって、どう変わっていくのかを整理したのが下の表です。

	Chrome 39 開発版の途中まで～2014.09.26 38安定版まで (～2014.11上旬)	Chrome 39 開発版の途中から (2014.09.26～ 2014.11.09) 39安定版リリースから (2014.11上旬～	Chrome 40 開発版の途中から (2014.11.09～ 2015.Q1) 40安定版リリースから (2015.01?～	Chrome 41 開発版の途中から (2015.Q1～ 2016.12.31) 41安定版リリースから (2015.03?～	2017.01.01～
有効期限が2016年5月31日までのSHA1証明書
有効期限が2016年6月1日から12月31日までのSHA1証明書
有効期限が2017年1月1日以降のSHA1証明書
Windowsの場合(Chrome同等の表示として)

表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。

今回のChromeのSHA1対応ポリシの問題点

今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。

最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思統一されたSHA1証明書の移行計画を示し、EV証明書のように準拠するブラウザは同じようなステータス表示にするべきだったと思います。
2つの有効期限の異なる証明書があって、その有効期限により表示状態が異なるということは問題です。今回はSHA1署名アルゴリズムの暗号危殆化を問題に取り上げているのですから、有効期限の長短にかかわらず、ある時点での暗号危殆化の程度は全く同じであり、同じものに対しては同一のHTTPSステータス表示にすべきではないでしょうか。
2017年1月1日からを、SHA1証明書を使ってはならない日と定めたとして、2年3ヶ月以上も前にユーザに表示を変えて伝える必要があるのでしょうか。2017年1月1日まではSHA1証明書を使って良いとするなら、いかなる警告もそのことで出す必要がなく、これはユーザも、ウェブサイト運営者も混乱させるだけです。2年以上も前に表示が異なってしまうことで、ユーザはサイトへクレームや問い合わせを入れるようになり、ウェブサイト管理者は仕方なく2年前倒しでSHA2証明書への移行を迫られることになります。
最近のモダンなブラウザではSHA2証明書に対応していますが、古いJavaや、組込み機器、ICカード、ガラケー(フィーチャーフォン)などSHA2証明書に対応できない環境は、未だに多数あります。これらの環境と歩調をあわせながらSSLサーバー証明書のSHA2移行を進める必要があったのではないでしょうか。
前述のOSなどのレベルでアルゴリズムとしてSHA2署名をサポートしていたとしても、検証などで使おうとするSHA2証明書のトラストアンカとなるルート証明書が「信頼するルート証明書」ストアに入っているかどうかは別の問題。例えば全てのお客様や、全社員のWindows XP SP3に対してルート証明書を追加させるという事はかなり困難。
Netcraftの2014年5月の調査によれば、インターネット上のウェブサイトのうち92%がSHA1証明書のままであり、SHA2証明書へ移行済なのはわずか7%にすぎません。HeartBleed脆弱性の影響で証明書のリプレースが多くあったため、SHA2への移行は進んだようですが、それでもたった7%です。このような状況で2014年9月にはHTTPSステータス表示を変えるというのは急すぎないでしょうか。(追記 SSLPulseによると2014年9月時点でSHA2は15%だそう)
SHA1証明書に対する表示変更のポリシーを2014年9月5日にアナウンスしてから、わずか21日後の2014年9月26日の開発版アップデート、安定版では2014年11月頃の39リリースで、影響を受けるサイトが出始めます。充分な猶予期間、準備期間を持てるように例えば半年や1年といったスパンで事前アナウンスをする必要があったのではないでしょうか。
SSLサーバー証明書は一般に2年や1年といった有効期間のものを購入される組織が多いと思いますが、例えば2014年6月1日から、アナウンスのあった2014年9月5日に2年物のSHA1証明書を購入し設定したウェブサイトは、早速2015年の1Qには、問題があるかのような黄色表示になります。事前に知らされていれば、1年物を買うとかSHA2証明書を買うとか対策ができたかもしれません。これは、あまりに不親切でユーザやサイト管理者の事を考えていない行為だと思います。
2017年1月1日以降が有効期限であるSHA1証明書が、2017年1月1日以降は使えなくなるという事は理解できるとして、2016年6月1日から2016年12月31日の間に有効期限がある証明書を分けてアラート表示をする必要があるとは思えません。

参考にすべきページ

今回のChromeのSHA1移行について問題提起や対策などを示している良いページがあるので、紹介しておきたいと思います。

CSO Online: Do you agree with Google's tactics to speed adoption of SHA-2 certificates?: CA Security Councilの中の人の問題提起。オンラインショップクリスマス商戦の時にこのような問題を起こすのや良くないとも言っている。Windows Server 2003ではhotfixなしでは非対応だと。他にも参考になるアドバイスがある。意見も募集している。
BLOG: IVAN RISTIC: SHA1 deprecation: what you need to know (2014.09.09): SSLの状態を調べられるQualysのSSLLabsを作っていたり、SSLの設定ガイドなどを書いているIvanさんのページで、今回のGoogle Chrome SHA1移行について、どのように対処するのが良いか解説しています。いつも冷静な分析をされる人ですが、今回に関し批評が無いのは寂しい。
CA Security Council: List of Operating Systems, Browsers, and Servers Which Support SHA-256 Hashes in SSL Certificates (last update Sep 8, 2014): 最新のSHA-256サポート状況のリストです。参考になります。でも、OSや環境レベルでSHA2をサポートしたと言っても、これから使おうとしているSHA2証明書のトラストアンカとなるルート証明書が信頼するルート証明書ストアに入っているかは別の問題。

おわりに

Google Chromeは良いブラウザだと思うし、便利だし、大好きなんですが、CRLSetの問題と、今回のSHA1対応の件はちょっとヒドイなぁと思います。サイトの運営者の方は、最初のマイルストーンの9月26日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

(訂正)バージョン番号の修正(2014.09.17)

バージョン38が既にリリースされていると勘違いして、今回のSHA1アラート表示の修正が、マイナーで入るのかと勘違いしたため表のバージョンの表記がおかしくなっていましたので修正しました。バージョンの確認はこちらでできるようになっており、直近のメジャーですと以下のようなリリース履歴であるとわかりました。すみませんでした。(影響日やバージョンについて再修正しました9/17 12:50)

安定版メジャー 37.0.2062.94 2014.08.26 for Win,Mac,Linux
安定版メジャー 36.0.1985.125 2014.07.16 for Win,Mac,Linux
安定版メジャー 35.0.1916.114 2014.05.20 for Win,Mac,Linux
安定版メジャー 34.0.1847.116 2014.04.08 for Win,Mac,Linux

通常は安定版(Stable Channel)のリリースは6週間おきだそうですが、40安定版についてはクリスマスシーズンを挟むので時期が未定なのだと思います。

タグ：: #Windows; #SHA256; #SHA2; #Microsoft; #Google; #Chrome; #SHA1; #SSL; #サーバー証明書; #証明書

2014年05月28日22:27

カテゴリ: 暗号

(小ネタ)楕円曲線暗号をなんとなく理解した気になるオススメのリンク4選

やっぱり、楕円曲線暗号(Elliptic Curve Cryptography)はRSA暗号に比べて格段になんだかんだ難しいと思うですよ。自分も勉強中なんですが、なかなか良い説明がなくて悶々としております。 jsrsasignの実装やビットコインを知る必要がある手前仕方なく。そんな状況の中、いろいろ見た中で、結構オススメなリンクを4つ紹介したいと思います。

CloudFlare: A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography
http://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography
長所	点の足し算の説明が絵的でわかりやすく最初の導入として良いのでは
短所	単に入り口に入ったところ、点の足し算程度で終わってしまう。
Zero to ECC in 30 Minutes (Entrust Inc.)
http://www.entrust.com/wp-content/uploads/2014/03/WP_Entrust_Zero-to-ECC_March2014.pdf
長所	楕円曲線暗号について中学の数学程度でわかるように解説している。絵も多用してわかりやすい。楕円曲線公開鍵暗号はよくわかる。
短所	署名(ECDSA)まで辿り着かない。
Elliptic Curve Cryptography Tutorial
http://www.johannes-bauer.com/compsci/ecc/
長所	工学系の人に向けてわかりやすく書いてある。ECDSA署名もある。プログラム例もある。結構オススメ。
短所	逆に数学をやった人には物足りない？
楕円曲線暗号入門「計算機緒論２」配布資料　伊豆哲也さん
http://researchmap.jp/mulzrkzae-42427/#_42427
長所	何より日本語でわかりやすい。でも大学数学の基礎素養がないと読み辛い。ECDSA解説もある。
短所	使われている記号が一般的なのとちょっと違うようで少し混乱する。

私は上の順序で読むのがいいのではと思います。誰かこれ全部まとめたやつを日本語で書いてくれるといいんですけどねぇｗ (オマエガヤレ)

コンピューター、IT関係の英語は何とか少しは読めるけど、数学の英語はやっぱり難しいですねぇ。

追記

2014.05.29 伊豆さんに最新版のリンクを頂いたので修正いたしました。伊豆さんあざます。
2014.10.11 私の書いたスライド「Bitcoinを技術的に理解する(p10-17)」のp10-17で内容8ページで楕円曲線暗号、ECDSAの署名・検証などエンジニア向けにざっくり説明した資料を作りました。我ながら短いページでよくできていると思うのでよかったらご覧ください。
2014.10.21 かなりわかりやすい英語の解説ページが出てきました。CoinDesk: The Math Behind Bitcoin これは、現時点では一番オススメ。英語だけど。

タグ：: #暗号; #公開鍵暗号; #ECDSA; #ECC; #楕円曲線暗号; #楕円曲線; #ビットコイン; #Bitcoin

2013年11月14日18:03

カテゴリ: Cipher Suite; 暗号

(小ネタ)Chrome 31.0.1650.48 のCipherSuiteを見てみたぞ

証明書ハンターであり、CipherSuiteウォッチャーの@kjurです。

ChromeのWindows、Macの新しい安定版版 31 が昨日、11月13日にリリースされたので早速CipherSuiteを見てみました。

これがアップデート前のChrome 30

Chrome 30.0.1599.101 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 20
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

これがアップデート後のChrome 31

Chrome 31.0.1650.48 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 18
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

CipherSuiteの数が20から18に減っています。

特徴的なところは

30から31になってGCMでないSHA2は全て削除された
30までGCMには対応していなかった
ちょっと順序も入れ替わっていてAES GCM SHA2が優先になっている

といったとこでしょうか。

これからOWASP Nightです。今日はこの辺で

タグ：: #Chrome; #CipherSuite; #暗号スイート; #GCM; #AES; #HmacSHA256; #SHA2

2013年09月08日22:16

カテゴリ: 電子署名; 暗号

(続)RSAとECDSA、署名生成と署名検証どっちが速い？

前回の記事では、署名生成と署名検証とか、RSAとECDSAとかどっちが速いのかOpenSSLやJava JCEを使って速度の比較をしました。一度作った署名を何回か検証に使うというケースもあるので、検証にかかる時間はとても重要だと思います。今日は、前回の比較をさらに掘り下げてみたいと思います。

・署名検証の速度は(今我々が普通に使う鍵長では)RSAの方が断然速い
・しかしながらECCは鍵長が長くても遅くならないという特徴があるのでいつか逆転するはず

鍵長が長いとRSA不利、ECDSA有利になってくるのでいつか速度の逆転が起きるのだろうと思います。では、それが鍵長としていつなのかを調べたいと思います。

NISTの暗号強度の比較表を再度引用します。

共通鍵暗号相当	RSA	ECDSA
80	1024	160-223
112	2048	224-255
128	3072	256-383
192	7680	384-511
256	15360	512-

まずは、同じ暗号強度のECC、RSAの鍵長に対して秒間署名検証回数をプロットしてみましょう。
cmp6-verify2

ご覧の通り共通鍵暗号で200bit相当、RSAなら9000bit、ECCなら200bit程度の所で署名検証ののスピードが逆転しているように見えます。我々が現在利用することの多い2048～4096bit程度の RSAの鍵ならまだまだ十分高速であることは言えるのではないかと思います。

上記のグラフが指数関数的なので今度は秒間署名回数の対数を取ってプロットしてみましょう。
cmp7-verify3log
グラフから、暗号強度に対してはほぼリニアに秒間署名速度の対数が推移し、共通鍵暗号相当の暗号強度の軸であるx座標が212.5423729(bit)の時に、 RSAとECCの署名検証の速度が逆転しています。

それでは、共通鍵暗号の強度で213bitということはRSAやECCではどの程度の鍵長に相当するのでしょうか。共通鍵暗号暗号強度と同等のECC、RSAの鍵長は最初のNISTの表からこれも指数関数的なのでRSAの鍵長と、ECCの鍵長の対数を使ってプロットしてみます。
cmp8-strength
すると、ご覧のように取った対数に対してほぼリニアに推移することがわかります。共通鍵暗号の暗号強度で213bitとする点はRSAだとy軸が3.965、ECCだと2.612となり、これらは指数に戻して

RSAとECDSAと同じ暗号強度で署名検証速度が逆転するのは
・RSAだと9234bit のとき
・ECCだと409bitのとき

ということのようです。この値に近づいてるようならECDSAへの移行を考えた方がよいということなんでしょうね。

今晩はこの辺で

あ、そうそう。これ書いている途中でizuさんのとてもためになる関連記事を発見してしまいました。杜撰な研究者の日記「RSA暗号の強度 (2009.11.19)」。

タグ：: #OpenSSL; #RSA; #ECDSA; #ECC; #楕円暗号; #署名; #電子署名

2013年09月05日22:19

カテゴリ: 電子署名; 暗号

RSAとECDSA、署名生成と署名検証どっちが速い？

2013年9月4日に開催されたOpenID Tech Night Vol.10 に参加してて、

大きなプロバイダではRSA署名の検証は結構大変です。 RSAは署名よりも検証の方が計算コストがかかるので...

みたいな話をされ、「んん？逆じゃないの。RSA署名の検証は署名生成よりも圧倒的に計算コスト低いよね。」とか思ってたわけで「がが～～ん」と。「まぁ、ちょっと調べてみるべぇ。」と手持ちのノートPCで調べてみました。

検証内容

以下のことを検証してみたいと思います。

署名の生成と検証ではどちらが速いのか。RSAとECC(ECDSA)では違いがあるのか。
同程度の暗号強度のRSA署名とECDSA署名ではどれくらい速度差があるのか。
RSA署名では鍵長が変わったとき、どれくらい速度差があるのか。
ECDSA署名では楕円曲線や鍵長が変わったとき、どれくらい速度差があるのか。
Ruby+OpenSSLとJava JCEではどれくらい速度差があるのか。

なんか、楕円「マンセー」みたいな人もおられますが、「楕円は鍵長が短いから圧倒的に速い」みたいな事を言い出す人もいて「ホンマかいな？」と調べてみたかったわけです。楕円って期待するほどそんなに速くないですよね？むしろ遅いですよね。

検証方法・検証環境

言語の偏りがあるのも良くないのでOpenSSLベースのものとJava JCEベースのものと調べます。いちいちOpenSSLをCで書くのも面倒なので。Rubyを使いました。処理時間の測定方法については、Ruby+OpenSSL、Java JCEで次のような観点で測定しています。

共通

鍵や証明書のロードの時間は処理時間に含めない。
測定条件統一のためハッシュ計算の時間は処理時間に含める。
同一のマシンで測定する。
再利用しない同一の鍵で2000回の署名生成、署名検証の時間を計測。
公開鍵暗号のパフォーマンスを知りたいだけなので署名対象は"aaa"の短い文字列。
SHA1withRSAもしくはSHA1withECDSAで比較する。

Ruby+OpenSSL

Ruby標準の'benchmark'モジュールを用い、リハーサルも行う。benchmarkのrealの時間を用いる。

Java JCE

イテレーションループの前後でのSystem.currentTimeMillis()の値の差を処理時間とする。

細かい検証環境情報は以下の通りとなります。

検証環境
マシン	Lenovo X201s
CPU	Intel Core i7 L620 2.00GHz
メモリ	8GB
OS	Microsoft Windows 7 Professional 32bit SP1
Java
バージョン	Oracle Java 1.7.0 build 1.7.0-b147
RSA署名JCEプロバイダ	SunRsaSign 1.7 Provider
ECDSA署名JCEプロバイダ	SunEC 1.7 Provider
Ruby (+ OpenSSL)
バージョン	cygwin C Ruby 1.9.3p194
OpenSSL	OpenSSL 1.0.1c

Ruby + OpenSSLで署名

Ruby + OpenSSLでRSAやECDSA署名するには、OpenSSLコマンドで普通に PKCS#5の秘密鍵と公開鍵を準備してこんな感じで署名生成、署名検証すればヨロシ。

# ECDSAの署名生成
prvKey = OpenSSL::PKey::EC.new(File.read(PKCS#5秘密鍵PEM))
hashed = OpenSSL::Digest::SHA1.digest(署名対象メッセージ)
sigVal = prvKey.dsa_sign_asn1(hashed)

# ECDSAの署名検証
pubKey = OpenSSL::PKey::EC.new(File.read(PKCS#5公開鍵PEM))
hashed = OpenSSL::Digest::SHA1.digest(data)
isValid = pubKey.dsa_verify_asn1(hashed, sigVal)

# RSAの署名生成
prvKey = OpenSSL::PKey::RSA.new(File.read(PKCS#5秘密鍵PEM))
sigVal = prvKey.sign("sha1", data)   

# RSAの署名検証
pubKey = OpenSSL::PKey::RSA.new(File.read(PKCS#5公開鍵PEM))
isValid = pubKey.verify("sha1", sigVal, data)

ECDSAの時はハッシュを自分で計算するのと、 ECDSAの署名値をASN.1構造で表現することに気をつければ問題ないかと思います。

Java JCEで署名

最近、キーストア使って楽してたので普通に鍵ファイルを読みたい場合には、 PKCS#8 DERじゃないといけないんだよなとか探してみると自分の記事「OpenSSLで鍵生成した秘密鍵をJavaで使う」が見つかって助かりました。秘密鍵ファイルはPKCS#8にしといて、公開鍵もPKCS#8にしようとしたら「読めな～～～い！！」鍵はパラメータの数値(BigInteger)を指定するか証明書じゃないといけないそうだ。仕方ないから無理やり自己署名証明書を作りました。

ECDSAの署名生成はこんな感じ。

KeySpec keySpec = new PKCS8EncodedKeySpec(PKCS#8秘密鍵DERのデータbyte配列);
KeyFactory kf = KeyFactory.getInstance("EC");
PrivateKey prvKey = kf.generatePrivate(keySpec);
Signature sig = Signature.getInstance("SHA1withECDSA");
sig.initSign(prvKey);
sig.update(署名対象データaaa);
sigVal = sig.sign();

RSAの署名生成はこんな感じ。

KeySpec keySpec = new PKCS8EncodedKeySpec(PKCS#8秘密鍵DERのデータbyte配列);
KeyFactory kf = KeyFactory.getInstance("RSA");
PrivateKey prvKey = kf.generatePrivate(keySpec);
Signature sig = Signature.getInstance("SHA1withRSA");
sig.initSign(prvKey);
sig.update(署名対象データaaa);
sigVal = sig.sign();

RSAやECDSAの署名検証はこんな感じ。

CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cer = (X509Certificate)cf.generateCertificate(new FileInputStream(公開鍵証明書));
pubKey = cer.getPublicKey();
Signature sig = Signature.getInstance("SHA1withECDSA"); // RSAならSHA1withRSA
sig.initVerify(pubKey);
sig.update(署名対象データ);
isValid = sig.verify(sigVal);

最初、BouncyCastle使えばいいかとも思ったんですが、 Java SE 7から楕円用のプロバイダSunECが標準提供されるようになったので、 Java SE 7の標準バンドルされたプロバイダを使うことにしました。サポートしている楕円曲線はどうだっけと思ったら前に自分で調べてあったのでそれを参考にしました。 ( 祝 Java SE 7 リリース記念「JCEはどうなってんの？」)

RSAとECCの暗号強度対応

一般に、

ECC 160bit は RSA 1024bitに相当する、とか
ECC 256bit は RSA 3072bitに相当する、とか

言われていますが、調べて見ると、 NIST SP800-57 Recommendation for Key Management - Part1: Generalの 5.6.1節 Comparable Algorithm Strengthで対象暗号、RSA、DSA、ECC(ECDSA)の鍵長と暗号強度の対応の表があり、 RFC 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layerでも引用してます。(こっちの方が見やすい)

表を引用しておきましよう。

共通鍵暗号	DSA	RSA	ECDSA
80	L=1024,N=160	1024	160-223
112	L=2048,N=256	2048	224-255
128	L=3072,N=256	3072	256-383
192	L=7680,N=384	7680	384-511
256	L=15360,N=512	15360	512-

(結果1)RSAの署名生成と署名検証はどっちが速いか

まずはRSA鍵での署名と検証がどれくらい違うのか見てみましょう。

署名と生成では、署名の方が圧倒的に時間がかかることがわかります。また、鍵長が長くなるほど指数関数的に時間がかかることがわかります。署名生成に関しては特にJava JCEの遅さが顕著です。

(結果2)ECDSAの署名生成と署名検証はどっちが速いか

グラフからECDSAではRSAとは逆に署名検証より署名生成の方がわずかながら速いですが、あまり変わらないということがわかります。また、同じ鍵長のsecp160r1, secp160r2, secp160k1とではほとんど処理速度には違いはなく、鍵長が長くなると処理時間は増えますが、 RSAが非常に鍵長の影響を受けるのに対し、ECDSAではあまり鍵長が長くなっても処理時間が長くはならない事がわかります。

(結果3)同じ暗号強度ではRSAとECDSAとどちらが速いか

ECC 160bit とRSA 1024bitはほぼ同等の暗号強度です。 ECDSAと比較して、RSAは署名生成はとても遅いが、署名検証はとても速いことがわかります。

鍵長が長いケース、ECC 256bit と同等なRSA 3072bit を比較してみると、順序関係は変わりませんが、鍵長が長くなった分、非常にRSA署名の生成時間が長くなっています。これに対し、ECDSAではRSAほどは鍵長が長くなった影響を受けていません。

まとめ

簡単にまとめると時間がかかる順に

RSA署名の生成には非常に時間がかかる
ECDSAの署名検証は署名生成よりほんの少し長く時間がかかる
ECDSAの署名生成は普通に時間がかかる
RSA署名の検証は非常に短時間であるECDSAの署名生成は普通に時間がかかる
RSAでは鍵長が長くなるほどその傾向が顕著になる。
ECDSAはRSAほどは鍵長が長くなる影響を受けない。

といった感じでしょうか。認識してたとおりで良かったなぁと思いました。今日はこの辺で。

タグ：: #OpenSSL; #Ruby; #RSA; #ECDSA; #ECC; #署名; #Java; #JCE

2013年04月08日21:34

カテゴリ: OpenSSL; 暗号

図説：PKCS#5秘密鍵をパスワード保護する共通鍵とIVの作り方(記事修正)

パスワードで保護されたPEM形式のPKCS#5 RSA秘密鍵を復号して取り出して署名なんかに使えるようなJavaScriptライブラリを作りたいと思ってるんですが、なんか現業が忙殺されておりそんな時間もなく。ただ、そんな事ではもうエンジニアとして詰んでいるなぁと思いリハビリのためにいろいろ調べてみることにしました。

パスワード保護されたPKCS#5 PEM形式の秘密鍵

OpenSSHの公開鍵認証や、OpenSSLベースでのCAや、Apacheサーバーの起動などでパスワード保護されたPKCS#5 PEM形式の公開鍵暗号の秘密鍵を使うことがあります。一般にはこんな感じのテキストファイルになってます。

-----BEGIN RSA PRIVATE KEY----- ←①PKCS#5 RSA秘密鍵を示すヘッダ
Proc-Type: 4,ENCRYPTED ←②共通鍵暗号で秘密鍵を暗号化していることを示す
DEK-Info: DES-EDE3-CBC,E83B4019057F55E9 ←③共通鍵暗号方式と、ソルトを含む初期化ベクタ

iIPs59nQn4RSd7ppch9/vNE7PfRSHLoQFmaAjaF0DxjV9oucznUjJq2gphAB2E2H ←④共通鍵で暗号化された秘密鍵本体
1r9k4e7lc7LZjF0RIgfeRl7MKmLHVCNo2EhPkt5yTb6bNdf3trS03+N+L5zBoaVp
以下、略

PEM形式の秘密鍵には"BEGIN RSA PRIVATE KEY"とか書いてあるやつと"BEGIN PRIVATE KEY"とか書いているやつがあるんですけど、それぞれPKCS#5形式とPKCS#8形式の公開鍵暗号の秘密鍵になります。 PKCS#5とPKCS#8の鍵形式の違いはざっとこんな感じ。

PKCS#5 秘密鍵

PEMヘッダに"BEGIN RSA PRIVATE KEY"のように公開鍵暗号アルゴリズムが書いてある。
鍵本体には公開鍵暗号鍵アルゴリズムを示す識別情報は書かれていないので PEMヘッダ側で区別する必要がある。

PKCS#8 秘密鍵

PEMヘッダは"BEGIN PRIVATE KEY"のように公開鍵暗号アルゴリズムが書いてない。
鍵本体には公開鍵暗号鍵アルゴリズムを示す識別情報がASN.1オブジェクト識別子(OID) で書かれている。
PKCS#8の鍵データは、PKCS#5の鍵本体とアルゴリズム識別子をまとめてASN.1オブジェクトとしたもの。

PKCS#5の秘密鍵にはその他に、暗号化されているかどうか、公開鍵暗号の秘密鍵をパスワードで保護するための共通鍵暗号のアルゴリズム、ソルトを含む初期化ベクタが書かれています。ソルトは同じパスワードを使っても共通鍵暗号の共通鍵が同じになってしまうことが無いように鍵の保存時につけられた8バイトの長さ固定の乱数です。共通鍵暗号のアルゴリズムや鍵長に依存して長さが含む「ソルトを含む初期化ベクタ」の先頭8バイト分をソルトとして使用します。

共通鍵暗号の共通鍵と初期ベクタIVはどうやって作るのか

秘密鍵を使うためのパスフレーズ(パスワード、PINコードとも呼ばれる)と、前述のソルトからどのように共通鍵と初期ベクタを生成するのかをOpenSSLのソースコードを眺めながら調べてみました。この処理を行う関数は "crypto/evp/evp_key.c" で定義されている "EVP_BytesToKey" という関数です。この関数は共通鍵と初期化ベクタ(IV)を同時に作るものですが、PKCS#5の鍵データを復号するためには生成された共通鍵のみを使い、初期化ベクタは関数より生成されたものではなく、PKCS#5ファイルのDEK-Infoに記載されたソルトを含む初期化ベクタ全体を使います。

パスフレーズとソルトからどのように共通鍵と初期ベクタ(IV)を生成するのかを図に書いてみました。
EVP_BytesToKey

基本的にはパスフレーズの文字列とソルトからMD5ハッシュアルゴリズムのハッシュ値を計算し、定められた長さを切り出して共通鍵とIVを取得します。今なおMD5固定で使われているというのはうーむという感じですね。

共通鍵と初期ベクタIVをOpenSSLコマンドで簡単に見るには

「公開鍵暗号の秘密鍵」を最終的に保護する「共通鍵暗号の共通鍵」と「初期ベクタIV」は、暗号化対象の秘密鍵の値には一切関係なく、単に共通鍵暗号アルゴリズムとパスコードとソルトのみで決まり、簡単にOpenSSLのコマンドで見ることができます。

例えば、共通鍵暗号がトリプルDES(DES-EDE3-CBC)で、パスコードが "hoge" で、ソルトが "E83B4019057F55E9" であったときの、共通鍵と初期ベクタは以下のコマンドで表示されます。

% openssl 共通鍵暗号 -p -in /dev/null -out /dev/null -pass pass:パスフレーズ -S 8バイト16進数ソルト
(例)
% openssl des-ede3-cbc -p -in /dev/null -out /dev/null -pass pass:hoge -S 1F2F3F4F5F6F7F8F
salt=1F2F3F4F5F6F7F8F
key=BD2B936A94EA6C2E0D15CD066C008F1F88735EE491687A29
iv =C180CD24D8B03454 (このIVは復号には使わない)

読みにくいOpenSSLのCのコード解析の後で

さんざん、読みにくい難解なOpenSSLのCのソースコードを読んだあとで、その鍵と初期化ベクタを取得する EVP_BytesToKey関数をPythonで書き直してくれている yasusii さんという方がいらっしゃいました。「Discreet Blog 25.6.2007 - OpenSSLのPBE(Password Based Encryption) (2007-06-25)」、先にこの記事見ときゃよかったorz

これで、なんとなくJavaScriptでPKCS#5鍵を解いてRSA署名するなんてことができるような気がしてきました。今日はこんなところで。

改訂

2013.04.10 - ソルトとIVの扱いについて調査不足というか誤解があったので修正しました。

タグ：: #図説; #図解; #PKCS#5; #秘密鍵; #OpenSSL; #IV; #ソルト

2009年08月17日19:46

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

jCryptionについて調べてみた

jCryption(jcryption.org)というウェブフォームの内容を公開鍵で暗号化して送信するようなJavaScript,JSON,jQuery,PHPを組み合わせて作ったオープンソースのライブラリ(フレームワーク?)のバージョン1.0が2009年8月2日に公開されて、紹介記事を見たセキュリティ技術者の方も多いと思うんですが、SSLはいらないとか、認証はしてないとか、なんとなく胡散臭そうに思えたので、ちょっと観てみることにしました。(だから、PHPの知識が錆付いてるのにVertrigoなんか持ち出してきたわけです。)まぁ、競合調査みたいなもんですかね(笑)

まずはセットアップ

VertrigoというApache,PHP,MySQLがインストール一発使え、設定もウェブで簡単というサーバースイートがあるので、これを利用しました。ウィザードでボタン押したらインストール完了で、すぐにPHPとMySQLが使えるようになってます。

jCryptionのサンプルを動かすには、どこかの仮想ディレクトリ(alias)か、VertrigoのApacheのコンテンツのフォルダに適当に解凍すればOKです。

まず手始めにサンプルを動かす

サンプルはjCryptionの配布アーカイブの"example1"ディレクトリにあるので、それをブラウザで開けばOK。"fill with samples"のリンクをクリックすると入力フォームを自動で埋めてくれますので、

この状態で"Submit"ボタンを押せばOKです。

上側が送信される暗号化データで、下側がサーバー側で復号した結果のデータです。

FORMの子要素の全てについてキーと値の連想配列の形で取得できているとわかります。

jCryptionの送信側のHTML

入力フォームの例は例えば example1/index.html なんかにありますが、概ね任意のFORMを公開鍵で暗号化してサーバーに送ることができます。やり方としてはFORMにidが振ってあるとしてHEADのところに

<script type="text/javascript" src="../jquery-1.3.2.min.js"></script>

<script type="text/javascript" src="../jquery.jcryption-1.0.min.js" ></script>

<script type="text/javascript">

$(document).ready(function() {

	$("#(ターゲットのFORMのid)").jCryption().fillInForm();

	$("input,select,textarea").removeAttr("disabled");

});

</script>

これを入れる。たったそれだけ。簡単ですね。

ソースをつらつら眺めてみるに、FORMのsubmitに対してフックを入れていて、そのセッションでRSA鍵ペアが無い場合には、鍵生成要求を送って、それをJSONで取得し、FORMの全ての要素(INPUT,SELECT,TEXTAREA,SUBMIT,RESET)の名前と値のペアをシリアライズして公開鍵暗号化して送信してくれます。

受け側PHPのサンプル

受け側のPHPのサンプルは example1/main.php にあります。処理概要はざっくりこんな感じ。

<?php

if (鍵生成要求) {

　・RSA鍵ペア生成

　・セッション変数に(モジュラスn, 公開指数e, 秘密指数d)を設定

　・モジュラスn, 公開指数eをJSONとしてクライアントに送信

} else {

?>

　・セッション変数よりモジュラスn, 秘密指数dを取得

　・モジュラスn, 秘密指数dにより送信されてきたメッセージを復号

　・復号結果を表示するHTML・・・

<?php

}

?>

鍵ペアは生成後、まずセッション変数に格納され

$_SESSiON["n"]["int"] モジュラス(10進数)
$_SESSiON["n"]["hex"] モジュラス(16進数)
$_SESSiON["e"]["int"] 公開指数(10進数)
$_SESSiON["e"]["hex"] 公開指数(16進数)
$_SESSiON["d"]["int"] 秘密指数(10進数)
$_SESSiON["d"]["hex"] 秘密指数(16進数)

公開鍵だけJSONでクライアントに送られます。

{ "e": "10001",

　"n":"c1061aa4add28f61abc4d5b8e1066b484f93f5be462e523de44107634aed98e1",

　"maxdigits":"35"}

処理フローのまとめ

フォームでボタンのワンクリックにより、フォームのコンテンツを暗号化して送信する際のフローはこんな感じになります。

ブラウザ側で入力フォームの表示の際に、JavaScriptにより送信FORMのSubmit時のフックとして、事前に公開鍵をJSONで取得し、その公開鍵でフォーム内容をシリアライズご暗号化して送信するように設定。

ユーザがフォームのフィールドに入力。

ユーザがフォームのSubmitボタンを押す。

ブラウザはフック関数により、サーバー側でRSA鍵ペア生成するよう要求を送る(GET)。

サーバーはRSA鍵ペアを生成する。

サーバーはブラウザに公開鍵をJSONで送る。

ブラウザはフォームの内容をシリアライズ(連想配列)する。

ブラウザはフォームの内容のシリアライズされたデータ全体を公開鍵で暗号化する。

ブラウザは暗号化データを送信(POST)する。

サーバー側でセッションで設定されている鍵ペアの秘密鍵を取得する。

サーバー側で秘密鍵を用い、POSTされてきたデータを復号する。

サーバー側で各フォームの要素(INPUT)のnameとvalueが取得できる。

セキュリティ考察みたいなもの

まず、セッション変数に秘密鍵格納しちゃマズイでしょ！: jCryptionではセッション毎に鍵ペアを生成しますが、その鍵ペアはセッション変数_SESSIONに格納されています。PHPの古いバージョンでは、セッションIDの作り方に問題があったり、セッションハイジャックの話があったような記憶があるんですが、ハイジャックされた場合に、ブラウザからサーバー側で保持されている秘密鍵の取得が可能です。
サーバーもクライアントも認証無しってわけにはいかないでしょ！: 暗号化されたデータを送るっていっても、サーバーおよびクライアントが本物かどうかわからないし、相手がニセサイトや詐欺師かもしれないのに、暗号化されたデータを送ったり受けたりしてもしょうがないでしょ、と思うわけです。中間者攻撃以前の問題でしょ、、、と。認証は他の仕組みでやるわけですが、結局これが高くつくんじゃないかと、、、
鍵ペア生成の質に不安がある: ソースを詳しくは見てませんが、main.phpの中でサーバー側でRSA鍵ペアの生成をしています。その際の乱数の品質に問題があるような気がします。鍵があらかじめ予測される範囲だとするとDebian鍵問題と同様の問題が起きる可能性があります。

秘密鍵の管理と認証の問題が解決されれば、特別なものは何もインストールしないで汎用のブラウザで使える仕組みなので、なかなかオモシロイとは思いましたが、ビジネスでこれを使うシーンがいまひとつ見えてこない＾＾；解説記事読んでるとJavaScriptだけでできるみたいな記述になっているのがありますが、結局 PHP を使うため、どうも体質的に合わないのでボクは使わないと思います。サーバー側がJavaならば、(多少胡散臭くても)もう少し迷ったと思うんですけどねぇ、、、

本記事には、認識の間違い等多々あるかもしれませんが、その際にはご指摘頂ければ幸いです。

リンク

・SOURCEFORGE.JP: JavaScript暗号化ライブラリ「jCryption 1.0」が登場 (2009.08.11)
・MOONGIFT: クライアントサイドで使える可逆暗号化ライブラリ「jCryption」(2009.08.10)
・PHPSPOT: RSAの公開鍵暗号方式でフォームのデータの暗号が行えるjQueryプラグイン「jCryption」(2009.08.10)
・yebo blog: jCryption 1.0がリリース(2009.08.11)
・水無月ばけらのえび日記: jCryptionはどんなとき使うのだろう(2009.08.13)

2009年08月05日07:22

カテゴリ: 電子署名; 暗号

図説RSA署名の巻

RSA鍵による署名って、フツーはJava JCEでもCryptoAPIでも.NETでもOpenSSLでも、一つのオペレーションになっていて、中でどう処理されているから知る必要もないんですが、やろうと思えばハッシュとRSA鍵による暗号化・復号の暗号プリミティブで実装することはできます。

今回はRSA署名の中身を図説したものって、なかなか良い物が無かったので、ちょっと書いてみて、関連した相互運用上の問題なんかを紹介します。

RSA署名とは何？よ～し父さん図説しちゃうぞ

RSA署名って、

文書のハッシュ取って秘密鍵で暗号化するんだよね

って簡単に解説しているものがあったりしますが、その説明って、なんか合っているようで合っていないというか、うそ臭いというか、「本当はどうなの？」っていうはなしが抜けているようで、これまでスッキリしませんでした。多分、それはパディングの話が無いからなんじゃないかと思うんです。

RSA署名の方式はPKCS#1 v2.1の中で定められているんですが、一般的な公開鍵証明書やCMS署名なんかは、その中で定められた "RSASSA-PKCS1-v1_5" というアルゴリズムを使っています。

RSASSA-PKCS1_v1_5アルゴリズムにかなり忠実に図説してみたのがコレ：

左から右(→)が「署名の生成」で、右から左(←)が「署名の検証」です。

RSASSA-PKCS1-v1_5 のオペレーションは大きく、

・ハッシュの計算
・パディング処理
・公開鍵暗号

の3つに分かれます。DigestInfoを作るとこも含めてパディング処理と読んだりすることもあり、この図の方が間違っているかもしれませんが、一般的なプログラミング上のパディング処理を知っている方なら、DigestInfoを作った後からをパディング処理と呼んだ方がスッキリするようなが気がします。

DigestInfoと相互運用性

署名では、署名対象データのハッシュ値とハッシュアルゴリズムを格納するためにDigestInfoというASN.1構造を使います。

RSA PKCS#1 v2.1より

DigestInfo ::= SEQUENCE {

  digestAlgorithm DigestAlgorithm,

  digest OCTET STRING

}



DigestAlgorithm ::= AlgorithmIdentifier { {PKCS1-v1-5DigestAlgorithms} }



PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= {

  { OID id-md2 PARAMETERS NULL }|

  { OID id-md5 PARAMETERS NULL }|

  { OID id-sha1 PARAMETERS NULL }|

  { OID id-sha256 PARAMETERS NULL }|

  { OID id-sha384 PARAMETERS NULL }|

  { OID id-sha512 PARAMETERS NULL }

}

署名生成時のアルゴリズムパラメータNULL

DigestInfoでハッシュアルゴリズムを指定する際に、アルゴリズムパラメータを指定できるんですが、SHA1、SHA2シリーズの場合にはNULLを指定します。このNULLを入れる入れないで、相互運用上の問題が起きたりします。

この辺りは昔、RSAとNISTの間で紆余曲折あったそうなんですが、解決のためにRSAはv2.1の訂正(PKCS #1 v2.1 Errat)を2005年12月に出しています。結論から言うと

・署名生成時：NULLを含めるものとする(SHALL)
・署名検証時：NULLがあってもなくても検証できるものとする(SHALL)

生成については、これまで自分が触ることができた10ぐらいの署名実装で一つを除き問題なくNULLが含まれていましたし、手当たり次第調べた証明書、CRLなんかも全てNULLが含まれた形になっています。残りの一つについても、パッチが出ているそうなので早く修正されるといいなぁ、、、と思います。(とある製品が国内2つの実サービスで使われているんですが、もう長いことパッチ未適用になってます。残念。)

検証については、目にした殆どの実装がNULLがあっても無くても検証できるようになっているんですが、入手できたうちの20%ぐらいの実装はNULLが無いと検証失敗します。

この辺りは、ハッシュとRSA暗号のプリミティブを使ってNULLの入ってない署名を作ったり、生の署名値、証明書、CMS署名、XML署名などで署名値のDigestInfoにNULLが入っているのかどうかをチェックするツールを作って調べました。

なんか、今回も細かい話ですみませんね。ではでは。

タグ：: #図説; #図解; #RSA署名; #RSA; #DigestInfo; #PKCS#1; #RSASSA-PKCS1_v1_5; #デジタル署名; #電子署名

2009年07月25日19:06

カテゴリ: セキュリティ; 暗号

スパイ大作戦みたく指定時間後に読めなくなる文書

Self-Destructing E-documents - NYTimes.com

New York Times: New Technology to Make Digital Data Self-Destruct By JOHN MARKOFF, July 20, 2009
A group of computer scientists at the University of Washington has developed a way to make electronic messages “self destruct” after a certain period of time, like messages in sand lost to the surf. The researchers said they think the new software, called Vanish, which requires encrypting messages, will be needed more and more as personal and business information is stored not on personal computers, but on centralized machines, or servers. In the term of the moment this is called cloud computing, and the cloud consists of the data ? including e-mail and Web-based documents and calendars ? stored on numerous servers.

ワシントン大学の研究グループが指定時間後読めなくなるテキストを提供するシステム"Vanish"というのを開発したのだそうです。Javaで実装されたっぽいローカルで動いている暗号化サーバーとテキストを時限つき暗号化、復号するFireFoxアドオンとで構成されています。

まさに、

おはよう、フェルプス君。そこで君の指名だが・・・・・ことにある。例によって君もしくは君のメンバーが捕らえられ、あるいは殺されても当局は一切関知しないからそのつもりで。なお、このテープは5分後に自動的に消滅する。

と、スパイ大作戦みたいな話ですねぇ。

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

Vanishプロジェクトのサイトに行って、まず Java のプログラムのインストーラーをダウンロード。

% java -jar vanish-0.1-win-install.jar

でウィザードに従います。で、次にFireFoxアドオン。これもサックリ入りました。

基本的には、ウェブページ上のテキスト、もしくはテキストエリアのテキストをセレクト状態にして右クリックメニューで「Venish→Create Vanish Message」を選んで時限付暗号化します。

ページのテキストを選んだ場合には、結果がこんな感じのダイアログで現れます。

時限付暗号化したテキスト：
Yeah, cooooool!!!. The message
"This text will self-destruct in a hour"
sounds like "MISSION: IMPOSSIBLE" :)
This text was written at 13:27.

テキストエリアの場合には、テキストが図中のBase64のメッセージに置き換えられます。

復号する際には、そのBase64のメッセージをブラウザの任意のテキストエリアに貼っておきメッセージを選択して、右クリックメニュー「Vanish→Read Vanish Message」すれば、時間内、回数内なら復号された元のテキストに置き換えられます。

別に日本語テキストであっても問題なく処理できるようです。

時間や回数の設定はFireFoxのアドオンの設定から行います。デフォルトで8時間見られるようになっています。単位は1時間単位です。もっと細かく秒とか分の単位で設定できると、よりスパイ大作戦っぽいですけどね。

とりあえず、1時間に設定変更して試してみたんですが、２時間過ぎたあとでもフツーに読めてしまいます、、、トホホ「だめじゃん」

８時間以上過ぎたらまた試してみたいと思います。

Vanishのサイトにはソースやムービーなんかもあるので興味あれば見てみてください。

成功を祈る！

＜追記2009.07.26＞
翌日、メッセージを復号してみたら、ちゃんと(汗)復号できなかった。
vanish02

有効時間の設定って何なんだろう、反映されてないや。デフォルトの８時間ならＯＫってこと？！テキストエリア探すのに困ったらVanishのサイトにも使っていいヤツがありますよ。

記事一覧(手作り)

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

暗号

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

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

ルート証明書数の推移

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

さらなる野望

おわりに

追記(2015.05.03 13:28)

関連記事

ちょっと遠い関連記事

SHA1が充分な暗号強度がなくなりつつある話

2013年11発表のMicrosoft製品のSHA1移行ポリシー

2014年9月5日に公開されたGoogle ChromeのSHA1 証明書対応ポリシー

Google ChromeのHTTPSステータス表示

Google Chromeは証明書チェーンがSHA1かどうかチェック

で、ChromeでSHA1証明書でHTTPS接続した場合どうなるのか？

今回のChromeのSHA1対応ポリシの問題点

参考にすべきページ

おわりに

本ブログの関連記事

関連リンク

(訂正)バージョン番号の修正(2014.09.17)

追記

検証内容

検証方法・検証環境

Ruby + OpenSSLで署名

Java JCEで署名

RSAとECCの暗号強度対応

(結果1)RSAの署名生成と署名検証はどっちが速いか

(結果2)ECDSAの署名生成と署名検証はどっちが速いか

(結果3)同じ暗号強度ではRSAとECDSAとどちらが速いか

まとめ

パスワード保護されたPKCS#5 PEM形式の秘密鍵

共通鍵暗号の共通鍵と初期ベクタIVはどうやって作るのか

共通鍵と初期ベクタIVをOpenSSLコマンドで簡単に見るには

読みにくいOpenSSLのCのコード解析の後で

改訂

まずはセットアップ

まず手始めにサンプルを動かす

jCryptionの送信側のHTML

受け側PHPのサンプル

処理フローのまとめ

セキュリティ考察みたいなもの

リンク

RSA署名とは何？よ～し父さん図説しちゃうぞ

DigestInfoと相互運用性

署名生成時のアルゴリズムパラメータNULL