自堕落な技術者の日記 : 暗号ライブラリ

暗号ライブラリ

2020年07月21日12:10

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

jsrsasignの寄付金を募ることにしてみました(やりがいって何だっけ？)

私はjsrsasignというJavaScriptのオープンソース暗号、PKIライブラリを個人的な趣味で開発し公開しています。ところが最近、npmパッケージのダウンロードが月間60～70万件と、異常にユーザーも増え、製品でも使われ始め、ちょっと厄介なことになっており、いろいろ悩んだ挙げ句、これが正解なのかもわかりませんが、ライブラリの維持のために寄付金を募ることにした次第です。今日は、心の吐露をつらつら書いていくことにします。

jsrsasignとは

2010年ごろ、スタンフォードの学生さんであるTom Wooさんという人のJavaScriptでRSA暗号化できるコードを見つけ、自分はPKIや電子署名を専門にしていたので「JavaScriptでRSA署名できたら面白いな」と思い、2010年6月に、ほんのRSA署名単機能のライブラリとして公開したのが jsrsasign です。当時のはしゃぎっぷりはブログでこんな感じ。小躍りしてツイートしてたのはこんな感じ。

Kenji Urushima@kjur
BigIntegers and RSA in JavaScript http://www-cs-students.stanford.edu/~tjw/jsbn/ マジか、JavaScriptでRSA暗号してるよ。
2010/05/24 07:17:03

Kenji Urushima@kjur
秘密鍵フォーマットもPKCS#1/8があつかえるといいかもしんない。そのためにも簡易ASN.1だ BigIntegers and RSA in JavaScript http://www-cs-students.stanford.edu/~tjw/jsbn/
2010/05/24 07:22:46

Kenji Urushima@kjur
実は昨日JavaScriptでRSASSA-PKCS1-v1_5 RSA署名できたのだ。任意の文字列にSHA1withRSAで署名できると思う。DigestInfo生成は文字列連結なので簡易ASN.1を作りたいとこ♪コレ活用→ http://bit.ly/9dUYXP
2010/05/28 17:04:02

その後、ASN.1ライブラリ、X.509証明書、CRL、CMS SignedData、タイムスタンプ、CAdES-BES/EPES/T、OCSP、CSR、共通鍵暗号、楕円曲線暗号、RSA-PSS署名、DSA署名、JSONのJWS、JWT、JWKの対応など、自分が欲しいと思う機能を少しずつ建て増しをして10年になります。多くの個人のオープンソースプロジェクトは1年くらいで終わってしまうそうですが、まぁ、なんとか自分のために追加開発やメンテナンスを続けています。

このライブラリが特徴的なのは、

なんでも入っている: 一つライブラリに多くのPKI、暗号の機能がつめこんであります。 Swiss Army Knife(スイスの十徳ナイフ)スタイルというそうです。自分がものぐさなので、これをロードしさえすれば何でも試せるように作りました。
とにかく使い方が簡単: どんな秘密鍵でも公開鍵でも自動判定してロードできるようになっていたり、ASN.1 DER構造の中身に簡単にアクセスできたり、面倒くさいことはなるべくライブラリに任せてできるようになっています。証明書やタイムスタンプなどはJSONのプロパティから簡単につくることもできます。共通鍵暗号も簡単です。APIの構成はJavaのBouncyCastleライブラリやIAIKライブラリなどのJCEアーキテクチャを参考にしているので、それを知っていればさらに使いやすいでしょう。自分がものぐさだから(二回目)、極力短いコードでいろんなことができるようになっています。
ドキュメント、サンプルが非常に豊富: ライブラリはあってもAPIドキュメントがなくてどんなAPIがあるのわからなかったり、BoucyCastleみたいにメソッドはわかるけど呼び出し方がわからないなどのことが無いようにAPIドキュメントの記述が充実しており、APIドキュメント中に例も入れています。また、Wikiなどの入門解説ページや、多数のオンラインでも試せるサンプルコード、テストコードがあり、自学習でもかなり何とかなると思います。APIが前提知識最小でも行けるように工夫してますので。
環境依存がほぼ無い、他のパッケージの依存がない: JavaScriptが動く環境であればどこでも動作します。古いブラウザでもほとんどの機能は動作しますし、Node.jsでも動きます。npmパッケージでも公開されていますし、CloudFlareなどのCDNからも利用できます。必要なサードパーティの関数は含まれており、他のライブラリ、パッケージに全く依存しておらず単独で使えます。Nodeの中でOpenSSLに依存していることもありませんし、(ブラウザ互換性でいつも悩まされる、この先どうなるかもわからない)W3C Web Cryptography APIを使っているわけでもありません。
いろんなツールがすぐ使える: 自分でプログラミングしなくても、オンラインで公開しているツールで証明書を発行したり、鍵ペアを生成したり、デジタル署名の生成や検証したり、JWTを生成したり、いろんなことができます。Nodeで実装されたいろんな便利なPKI関連ツールもついています。
速いとは言えない: 自分がPKI関連のいろんなことを少ないコードで簡単にテストするために作っていますので、高速に動作することを目的にしていません。数百万のトランザクションを処理したいといった目的なら他のライブラリを使う方がいいでしょう。

一人でここまでよくやったなぁ、、、と。お節介か、、、www

jsrsasignの歴史を振り返る

10年だもの、まぁ、いろいろありますよ。自分のためにちょっと歴史を振り返ってみます。

2010年6月：v1.0：jsrsasign初版公開。RSA署名だけ。
2012年4月：v1.2：公開リポジトリをGitHubに移行。
2013年4月：v2.0：PKCS#1 PEMなどの鍵のロード機能がつき始める。 JavaライクなSignature、MessageDigestクラス、ASN.1エンコーダー、X.509証明書エンコーダー、RSA-PSSサポートなど
2013年5月：v3.1：暗号化されたPKCS#5鍵のロードのサポート
2013年6月：v4.0：ECDSA署名サポート
2013年9月：v4.1：PKCS8など柔軟な鍵ロード用クラス KEYUTIL を追加
2013年10月：v4.2：DSA鍵、署名のサポート
2014年4月：v4.5：CMS SignedDataサポート
2014年5月：v4.6：RFC 3161 Timestampサポート
2014年7月：v4.7：RFC 5126 CAdES-BES/EPES/Tサポート
2015年6月：v4.8：NodeJS npm、JSON JWS、JWK、JWTサポート
2015年10月：v5.0：CSRサポート、便利なNode.JSスクリプトの追加
2016年9月：v6.0：OCSPサポート
2016年11月：v6.2：識別名のmulti valued RDN、RFC 2253 LDAP識別名文字列表現のサポート
2017年6月：v8.0：コードのスリム化、長期間非推奨(Deprecated)だった関数の削除
その後、細かい機能追加や脆弱性指摘対応などが続き現在に至る

jsrsasignはどれだけ使われているか

自分の趣味でやってる調査のために開発したライブラリですが、Node.JSのパッケージ npm で公開した2015年あたりから利用者ダウンロードが増えています。github.comからのダウンロードや、勝手に行われている公開CDNからの利用もあると思いますが、npmパッケージのダウンロード数だけでいうとnpm-stat.comさんのダウンロード数グラフを見てみるに、2018年あたりからブリブリ増えてしまっており、2019年あたりからサチりはじめ、それでも最近の月間ダウンロードは60万件超、先月は70万を超えてしまいました。npmでは他のパッケージの依存関係を書けるのですが、2020年7月現在で379ものnpmパッケージのプロジェクトがjsrsasignに依存していることがわかります。とほほ。

jsrsasignは自由に使ってもらっていいですが、ライセンスは放棄はしていないので、ライセンス掲載の義務はあり、たまにエゴサーチでPDFで検索してみると、いろんな製品の中でも使われちゃってることがわかります。

独シーメンスのConnect X300というビル制御システムで使われていたり [OSS一覧]
EUの公共向けシステムらしいCITADELで使われていたり [OSS一覧]
セールスフォースのSalesforce DMPで使われていたり [OSS一覧]
ソニーのビデオプロジェクターLSPX-A1、映像製作機材XDS-1000、PDW-HR1等で使われていたり [LSPXガイド] [XDS OSS一覧] [PDW OSS一覧]
キヤノンの複合機 iR-ADV や印刷機 imagePRESS C165 で使われていたり [iRADV8505 OSS一覧] iRADV4500 OSS一覧] [imagePRESSガイド]
横川電気のSMARTDAC+というデータ測定機器で使われていたり[マニュアル][英語]
VERINTという通話記録機器など提供する会社の製品で使われていたり [OSS一覧]
Oracle Blockchain Platformで使われていたり [ライセンス情報]

あとは、以前シャニマスのライセンス表示にjsrsasignが載っていたり、某社は使っているのにオープンにしていただいてなかったり、、、、（＾＾；こんな、個人が趣味で開発しているライブラリに、みなさん乗っかっちゃって大丈夫なんですかね。逆に心配になっちゃいますね。

ユーザが増えた悩みの始まり

最初は、「自分の調査のために趣味で維持しているライブラリがみなさんの役にたって、使ってもらえてるなら良いことだなぁ。これからも趣味で自分の必要そうな機能は追加していこうかなぁ、、、」で済んでたんですが、最近ユーザーも増えてそうも言ってられなくなってきたんです。

そもそも、jsrsasignは MITライセンスの下で無償、無保証で配布されています。もし、セキュリティ脆弱性やバグがあっても、私には修正する義務はないし(とはいえ、指摘されたら直すわけですが)、オープンソースなので問題があれば好きに修正して使っていただいていいわけです。もちろん修正コードをもらえれば、それは反映してすぐに公開します。

そんな中おきたThe RegisterやUsenixの指摘

2020年5月にITセキュリティのニュースサイトであるThe Registerで「What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out」という記事が掲載されました。JavaScriptのバージョンの違いを吸収するためのCore-jsという有名なライブラリがあって、その開発者がバイクで交通事故を起こして被害者の方が亡くなり収監されて、ソフトウェアのアップデートが滞っており問題だというものでした。

この記事の中で、私のjsrsasignも、2018年4月から2020年まで更新されてないと指摘をされてしまいました。

(記事引用)
Another JavaScript cryptographic library known as jsrsasign faces a similar challenge: its maintainer, Kenji Urushima, hasn't been active since April 2018. Programmers who use the software have expressed concern about the lack of communication and an unaddressed vulnerability, noting that 350 npm projects depend on the library, including some by Microsoft and Mozilla,
(抄訳)
jsrsasignとして知られている別のJavaScript暗号ライブラリも同様の課題に直面している。その管理者である Kenji Urushima は、2018年4月から活動していない。このソフトウェアを使用しているプログラマは、対話の欠如と対応されていないある脆弱性について関心を寄せている。注目すべきは、MicrosoftやMozillaを含む350のnpmプロジェクトがこのライブラリに依存しているという事である。

指摘された問題は、Minervaと呼ばれるECDSA署名のタイミング攻撃により処理時間を大量監視していれば秘密鍵が復元できる可能性があるというもので、元々、楕円曲線暗号の部分はBitcoin-JSを使っており、自分のコードではないので、調査するにしてもかなり時間がかかる根の深い問題でした。また、自分は本業の方も忙しい時期だったのでなかなか調査もできず、誰からも修正コードの支援をしてもらえないままでいました。jsrsasignは大量のトランザクションで使われることもあまりないし、攻撃の実現はかなり低いと考えていました。他の簡単に回答できるものには回答していましたが、根が深いのでこの問題は手付かずにしていたのです。

おそらくこの記事をうけて、USENIXという団体の機関紙のコラム「Who Will Pay the Piper for Open Source Software Maintenance? Can We Increase Reliability as We Increase Reliance?(誰がオープンソースソフトウェアの保守の費用を負担するのか？(オープンソースの)依存が増える中、信頼性を上げることできるのか？」の結論でも、jsrsasignを「(開発を)撤退したソフトウェア」として取り上げられてしまいました。

やっとMinerva脆弱性の修正

jsrsasignの根深い問題の調査まで手がまわらない状態が続いていたのですが、プライベートで慌ただしい時期がようやく終わりかかり落ち着きだした2020年4月、Node.JSのパッケージマネージャーを管理するnpmのセキュリティチームからもMinervaの脆弱性指摘が来てしまい、いよいよ直さざるをえない状況になりました。他の人が作ったコードを解析し、修正し、テストケースを作成して確認し、修正リリースを出しました。[勧告]

そしてまた別のMalleabilityに関する脆弱性指摘が3つも

2020年6月に Antonio de la Piedra さんから、3つのmalleability(展性)に関する脆弱性の指摘を受けてしまい、初めてUS-CERT、MITREの脆弱性データベースにCVE登録されてしまいました。3つのうちの1つは、npm のセキュリティチームからも対応依頼が来ました。「malleability(展性)」とは、金属を叩いて延ばしても破壊されずに広げることができる性質のことを言うのですが、ソフトウェアの世界では、同じ意味のデータを別の表現ができるという事をmalleabilityと呼んでます。例えば、10進数で数値の12345という値があったとして、先頭にゼロを幾つかつけて00012345としても値は同じであるといった事です。

暗号では、大きな数値を使って暗号文、署名値など表現することが多いですが、指摘された3つの脆弱性は簡単には以下のようなものでした。

CVE-2020-14966 ECDSA署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう等。(CVSS3.X 7.5, CVSS2.0 5.0)
CVE-2020-14967 RSA暗号の暗号文が、前述のようなゼロを先頭に足した値を使ったものでも復号ができてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)
CVE-2020-14968 RSA-PSS署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)

これが深刻な脆弱性にあたるかに関しては疑問があり、前述のようにゼロを足したとしても、別の署名対象文書を正しい署名として受け入れたり、暗号文の内容を別の内容に書き換えることができたりといった攻撃とは無関係です。また、大量にゼロを足した場合にメモリ破壊が起きると指摘されましたが、JavaScriptのBigIntegerでは、C言語のような桁あふれも発生しないので指摘にはあたらず、脆弱性を利用した攻撃は実現できないと考えています。vulndbのCVSSスコアはそれほどでもなかったですが、US-CERTのスコアはやたら高いです。

6月頃は仕事もプライベートも落ち着いていたので、週末や夜に対応の時間を取ることができ、問題の調査をし、コードを修正し、Antonioさんにもらったテストコードで問題なくなった確認し、2週間くらいで修正リリースし、セキュリティアドバイザリを公開しました。 [勧告1] [勧告2] [勧告3] かなり短期に対応できたかと思います。ちなみに、RSA-PSSはDaveさんが提供してくれたコードで、自分で解析して修正しなければならないので厄介でした。ECDSAについては、署名値が厳密なASN.1 DER構造であることをチェックしていなかったために起きた問題で、その厳密なチェックをする機能を追加するのにテストケースが多すぎて骨が折れました。

というわけで、オープンソースのライセンスで、現状有姿、無保証で提供するという条件で利用してもらっているにもかかわらず、結局、義務的に直さざるを得ず、問合せ対応や、報告者への対応、セキュリティアドバイザリの作成などしなければならない状況になっているのです。ソフトウェアの開発や保守でお金をもらっているわけでもないのに、とてもモヤモヤします。もちろん、本当に攻撃の影響を容易に受けてしまうような深刻な脆弱性については、何とか時間を作って急いで修正します。でも、「自分のために作ったライブラリを他の人が喜んで使ってくれるなら開発にかかったコストも要求せず、無料で、現状有姿で提供しましょう。」と言っただけなのに、多くの土日や夜まで潰して手厚いサポートまでタダで求めてくるのは「それは善意の搾取です！！！」とガッキーのように叫びたくなります。

同じオープンソースの暗号ライブラリでも、OpenSSLのように多くのメンバーが開発に関わっていて、修正パッチの提供も有志がやってくれるような状況なら、脆弱性指摘を対応する体制も作れますが、私一人で開発しているような状況なので、仕事やプライベートの都合でタイムリーに脆弱性対応できないケースがあります。そんな手厚いサポートを求められても困るのです。

私は、製品のセキュリティインシデントレスポンスチームであるPSIRTの仕事もしていたので、外部から脆弱性を指摘された場合に、しかるべき機関と調整しながら脆弱性対応する必要があることもわかっています。ただ、こうしたライブラリの場合は厄介で、よく使われる機能も、そうでない機能も様々取り揃えてライブラリを構成しているので、問題への影響が大きいのか小さいのかという判断をつけにくいです。そのため、リスクが高かろうが低かろうが「直せ」と要望が来てしまいます。なんか、段々、オープンソースを公開するのが面倒くさくなってしまいました。

そして寄付金を募ることにしました

「お金もらってるわけでもないのに文句言うな」とモヤモヤした気持ちを抱えたまま、jsrsasignを維持し続けるのもモチベーションが持ちそうにないので、ふと「寄付金」を受け付けてみてはどうかなぁ、、、と思いました。寄付金制度を導入すれば、どれだけの人がこの一人プロジェクトを応援してくれてるのかわかるし、「こんなに応援してくれてるんだから、ちょっと頑張らなきゃなぁ」という気持ちになるかもと思ったわけです。調べてみると、

(1) GitHubのスポンサー制度(毎月いくらとか設定して応援してもらえる。日本の口座もOK)
(2) Bitcoin、Bitcoin Cashなどの仮想通貨による寄付(自分の口座が放置されてた)
(3) Paypalによる寄付 (日本の金融機関ではできない)
(4) Open Collective (日本ではかなり敷居が高そう)
(5) Buy Me A Coffee (これも面倒くさそう。でも決済がGitHub Sponsorsと同じStripeだから可能性あるかな)

(1)は検索してみると日本の開発者の方も設定しているようで、いろんな方の設定内容を参考に設定することができました。(2)は、仮想通貨口座のアカウントの復旧、追加本人確認手続きが結構面倒だったんですが何とか復活させることができました。(3)はちょっと考えがあるので、そのうちチャレンジしてみようと思います。(1)の審査までの準備は、わからないことも多くて相当かかったのですが、審査申請して2週間と言われてたところを2日くらいで承認されました。(2)と合わせて、ようやく今日、READMEに寄付受付を書いてみました。

今後、そのうちどうするか

と、まぁ、サポートや脆弱性対応のモチベーションは何とか寄付金で自分をだましだましやろうと思うんですが、自分もいい歳なので、自分が開発、サポートができなくなった時にどうするかですよね～～。急遽、長期入院などして何もできないことがあるかもしれませんし。GitHubでは、後継者を指定して何かあったとき、その人に管理を譲ることができる機能があるんですが、こんなわけのわからないソフトのメンテと問合せサポートを他人に押し付けるわけにもいかないので、多分自分が開発できなくなったら一代限りで終わりなんでしょうねぇ。ソースは全てリポジトリにあるので、引き継いでくれる人が世界のどこかから出てくるのかもしれませんが、完全にお任せで好きにしてもらうのが良いんじゃないかと思ってます。

ただ、自分に何かあったとき、「このプロジェクトは今後一切、メインの開発者がサポートできなくなりました。」と伝えてあげる必要はあるなぁと思っています。娘か知り合いに託すしかないのかなぁ。そうしないと、また The Registerの記事のような騒ぎになってしまうので、、、なんか、デジタル遺品とか終活ノートみたいな話ですね。

趣味でちょっと、好きなものだけ好きなように開発したかっただけなのになぁ、、、なんでこんなことになっちゃったのかなぁ、、、

こんなこと書いちゃってますが、開発はぼちぼち続けていきますよ。本人はいい加減な人間なので、そんなに気に病んでるわけでもないので、どうかお気になさらずに。なんか、愚痴っぽい話につきあってもらってすみません。今日はこの辺で。

タグ：: #jsrsasign; #JavaScript; #暗号ライブラリ; #PKIライブラリ

2015年01月19日20:19

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

W3C Web Cryptography APIとの果てしなき戦い(第3回動くサンプル1)

前回はW3C Web Cryptography APIの鍵生成、署名などについて説明しましたが、実際に動く実例がないとAPIの有り難みもわかないのかなと思いまして、とりあえず3つのサンプルを作ってみました。サンプルはChromeやFirefoxでは動くようになっています。画像をクリックするとサンプルページが開くようになっています。

ハッシュ関数

ハッシュアルゴリズムを選んで、ハッシュ計算したい文字列(UTF-8だから日本語も可能)を入力して、「ハッシュ計算」のボタンを押すだけで、16進数でハッシュ計算結果が表示されます。

公開鍵ペアの生成

RSA公開鍵ペアを生成します。W3C Web Cryptography APIでは、鍵生成やインポートの際、どのような用途で、どのようなハッシュ関数と一緒に使用するかを指定する必要があるようで、生成時に選択するようにしていますが、PKCS#8 で秘密鍵や公開鍵をエクスポートする際には、まぁ、関係のない話になってしまいます。PKCS#8のバイナリデータ(ArrayBufferView)をPEM形式に変換するのにjsrsasignライブラリを使っています。

RSA鍵による署名と検証

RSA鍵でUTF-8の文字列に対してSHA256withRSA署名アルゴリズムで署名と署名検証ができます。鍵はW3C Web Cryptography APIで内部生成した鍵ペアで署名と署名検証することもできますし、PKCS#8 PEM形式やJSON Web Key(JWK)フォーマットの秘密鍵や公開鍵をインポートして署名や署名検証することもできます。

サンプルの動作環境

これらのサンプルページは新しいChromeのWindows、Android、Mac OS X、Linux版、新しいFirefoxのWindows、Mac OS X、Android版で動作します。Safariでは一部がMac OS X版、iOS8+などで動作します。Internet ExplorerではPromise APIをサポートしていないので動作しません。IEでも動作するようにコード書くのはちょっと面倒で、それらの相互運用性を持たせるような実装の仕方については別途紹介しようかと思っています。

おわりに

とりあえず、いろんなブラウザでW3C Cryptography APIの動作を試してみることができるので、遊んでやってください。ソースコードはgithubに置いてあるのでご覧ください。FirefoxとChromeだけでも相互運用性持たせるのに結構壁にぶちあたったりして、その上、SafariやIEなども一緒にサポートするコードを書くのはかなり骨が折れるんですよね。でも、AndroidのFirefoxでも動くのを見ると、ちょっと目がうるうるしてきたりしますw。今日はこのへんで。

タグ：: #W3CWebCryptographyAPI; #W3C; #Cryptography; #API; #暗号ライブラリ; #署名; #インポート; #JavaScript; #RSA; #RSA署名

2015年01月05日03:28

カテゴリ: 暗号プログラミング; フリーウェア

W3C Web Cryptography APIとの果てしなき戦い(第2回 RSA署名生成と検証)

前回は、 W3C Web Cryptography APIについて、一番簡単そうなハッシュの生成を紹介しながら、幾つかの課題について紹介しました。

今回は、W3C Web Cryptography APIによる、 RSA公開鍵暗号によるデジタル署名の生成と検証を紹介していこうと思います。

署名と検証の例題って、よく一人の人というかプログラムが、鍵ペアを生成して、署名して、検証するサンプルを出しますよね。( sjclの楕円暗号のテストコードとか・・・) 一人の人が同時に署名と検証を行うってユースケースとしてありえないと思うんですよね。実際、私が見た当時、sjclでは鍵オブジェクトの秘密鍵と公開鍵を分けてエクスポートができないようで、実際問題使えないことがありました。

そんなわけで、今回はまず、ちゃんとOpenSSLで生成した秘密鍵と公開鍵をインポートして、署名の生成と検証をできるようにしたいと思います。その後で、RSAの鍵ペアの生成をします。

データの準備

W3C Web Cryptoで鍵生成してもよいのですが、今回はOpenSSLで作ったRSA 2048bitの秘密鍵で署名することにしたいと思います。PKCS#5 PEM形式の2048bit RSA秘密鍵を生成し、それを平文のPKCS#8 DER形式に変換し、 bin2hexスクリプトで16進数文字列表現に変換します。

% openssl genrsa 2048 > k2048.p5p.pem
% openssl pkcs8 -topk8 -nocrypt -in k2048.p5p.pem -outform DER -out k2048.p8p.der
% bin2hex < k2048.p8p.der > k2048.p8p.hex #16進数形式のRSA秘密鍵

鍵ペアとなる公開鍵について、同様に16進数文字列形式のものを取得します。

% openssl rsa -in k2048.p5p.pem -pubout -out k2048.pub.pem # PEM形式の公開鍵
% openssl rsa -in k2048.p5p.pem -pubout -outform DER -out k2048.pub.der #DER形式の公開鍵
% bin2hex < k2048.pub.der > k2048.pub.hex # 16進数形式のRSA公開鍵

次に"aaa"という文字列に対して署名するとして、この文字列が含まれる署名対象データファイルを作っておきます。

% echo -n aaa > aaa.txt

OpenSSLで前述の秘密鍵と署名対象データを使ってSHA1で署名すると結果のデータは以下のように作られます。同様に16進数データを作っておきます。

% openssl dgst -sha -sign k2048.p5p.pem aaa.txt > k2048oaaa.sig.bin
% bin2hex <  k2048oaaa.sig.bin >  k2048oaaa.sig.hex

OpenSSLで前述の公開鍵と署名対象データと生成された署名値データを使って検証するには以下のように行います。

% openssl dgst -sha1 -verify k2048.pub.pem -signature k2048oaaa.sig.bin aaa.txt
Verified OK

署名値は正しいことがわかります。

秘密鍵のインポートと署名の生成

秘密鍵の16進数値を使って文字列"aaa"に対してSHA1withRSAで署名する場合の、 W3C Web Cryptoのコードは以下のようになります。

var prvHex = "308204bd02010030...";   // 前節の16進数秘密鍵
var prvUint8a = hextouint8a(prvHex);  // 秘密鍵のUint8Array
var aaaUint8a = asciitouint8a("aaa"); // 署名対象aaaのUint8Array

// PKCS8形式の秘密鍵を署名用にインポート
window.crypto.subtle.importKey(
  "pkcs8", prvUint8a, 
  { name: "RSASSA-PKCS1-v1_5", hash: {name: "SHA-1"} },
  true, ["sign"]
).then(
  // 秘密鍵インポートに成功したら署名する
  function(prvKey) {
    console.log("**importKey** 成功");
    console.log("prvkey=" + prvKey);
    return window.crypto.subtle.sign("RSASSA-PKCS1-v1_5", prvKey, aaaUint8a);
  },
  function(e) { console.log("**importKey** エラー: " + e); }
).then(
  // 署名に成功したら署名値(ArrayBuffer)を16進数表示
  function(sigVal) {
    console.log("**sign** 成功");
    console.log("sigVal=" + abtohex(sigVal));
  },
  function(e) { console.log("**sign** エラー: " + e); }
);

実装で注意しなければいけないポイントは以下の通りです。

OpenSSLの(平文の)PKCS#8秘密鍵を使うにはimportKeyで"pkcs8"を指定する。
鍵使用目的で["sign"]を指定する。

コンソールに"sigVal="で表示された16進数の署名値は、 k2048oaaa.sig.hexファイルの値と同じになっていると思います。 hex2binスクリプトで署名値をバイナリデータに変換して、以下のようにOpenSSLで検証することができます。うまく検証できたでしょうか。

署名値16進数をk2048waaa.sig.hexとして保存
% hex2bin < k2048waaa.sig.hex > k2048waaa.sig.bin
openssl dgst -sha1 -verify k2048.pub.pem -signature k2048waaa.sig.bin aaa.txt
Verified OK

hextouint8aについてはこちらをご覧ください。

公開鍵のインポートと署名の検証

前々節のOpenSSLで作った署名値でもよいですし、前節で生成された署名値でもよいですが、これをインポートした公開鍵で検証してみましょう。以下のようなコードで検証することができます。

var pubHex = "30820122300d0609..."; // 前々節の16進公開鍵
var sigHex = "afd36b6f3f2af788..."; // 前節or前々節の16進署名値
var pubUint8a = hextouint8a(pubHex); // 
var sigUint8a = hextouint8a(sigHex);
var aaaUint8a = asciitouint8a("aaa");

window.crypto.subtle.importKey(
  "spki", pubUint8a, 
  { name: "RSASSA-PKCS1-v1_5", hash: {name: "SHA-1"} },
  true, ["verify"]
).then(
  function(pubKey) {
    console.log("**importKey** 成功");
    console.log("pubKey=" + pubKey);
    return window.crypto.subtle.verify("RSASSA-PKCS1-v1_5",
                                       pubKey, sigUint8a, aaaUint8a);
  },
  function(e) { console.log("**importKey** エラー: " + e); }
).then(
  function(isValid) {
    console.log("**verify** 処理成功");
    if (isValid == true) {
      console.log("**verify** 署名検証成功(一致)");
    } else {
      console.log("**verify** 署名検証失敗(不一致)");
    }
  },
  function(e) { console.log("**verify** エラー: " + e); }
);

実装で注意するポイントは以下の通りです。

OpenSSLの公開鍵をインポートする際には"spki"を指定する。
インポートする際の鍵使用目的に"verify"を指定する。
署名検証の結果はブール値(isValid)で返されるのでこれに従う。関数が呼ばれただけで安心して終わりにしない。

RSA鍵ペアの生成

上の例ではインポートした秘密鍵、公開鍵を使っていますが、鍵ペアの生成だってできます。(現状RSAだけのようですが・・・) RSA 2048bitの鍵ペアは以下のように生成します。

var paramKeyGen = {
  name: "RSASSA-PKCS1-v1_5", // 現状ではRSA-PSS, RSA-OAEPは指定できなそう
  modulusLength: 2048, // 鍵長
  publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 公開指数 65537
  hash: { name: "SHA-256" } // 署名のハッシュアルゴリズム?別に利用外のを指定しても良い?
};

window.crypto.subtle.generateKey(
  paramKeyGen,  // 生成する鍵ペアのための鍵長等の各種パラメータ
  true, // エクスポート可能にするかどうかのフラグ
  ["sign", "verify"] // 鍵使用目的
).then(
  function(key) {
    console.log("**generateKey** 成功");
    console.log("秘密鍵:" + key.privateKey);
    console.log("公開鍵:" + key.publicKey);
  },
  function(e) {
    console.log("**generateKey** エラー: " + e);
  }
);

Web Crypto APIの困った所5：importKeyの融通の利かなさ

こうしてこのブログをすんなり見ていただくと、「W3C Web Cryptoって簡単じゃん」と思われるかもしれませんが、このような動く例を見つけるまで、かなりの紆余曲折があり時間がかかっています。importKeyの正しく動く例というのが、仕様に記載されておらず、他の方のサンプルも動くものあり、動かないものあり、何が正しいのかよくわかりません。 importKeyの引数には、

format - 鍵データの形式 (pkcs8, spki, jwk, raw)
keyData - 鍵データ (ArrayBufferView(Uint8Array)かJSONデータ)
algorithm - アルゴリズムのJSONデータ
exportable - エクスポート可能かのブール値
keyUsage - 鍵使用目的の配列 ["sign", "verify"] 等

を指定しますが、仕様がイケてないと思うのは

鍵のデータ形式など指定させる必要があるのか。公開鍵か秘密鍵のバイナリかはASN.1構造を見ればわかる話。JWKだって区別はできる。
アルゴリズムの指定も必要性がよくわからない。pkcs8、spkiであれば、鍵アルゴリズムが何であるかわかるし、鍵のインポートの際に署名アルゴリズムやハッシュアルゴリズムを指定させる意味がわからない。"RSASSA-PKCS1-v1_5"にするか"RSA-PSS"にするかは、鍵インポート時に決める必要がない。署名のハッシュアルゴリズムについても同様に決める必要がないのに、"MD-5"などサポート外のアルゴリズムを指定するとエラーとなる。JWKデータも同様に鍵アルゴリズムの指定の必要がない。
keyUsageの指定の必要性もよくわからない。例えば、RSASSA-PKCS1-v1_5で秘密鍵をインポートしたらkeyUsageはsignに決まっており、省略できることの方が多い。
JSON等指定の自由度が非常に高い割に、値の指定を間違えるとすぐにエラーとなり融通が利かない。省略可能やデフォルト値を持つ引数、パラメータがあっても良さそうだが、そのようにはなっていない。
algorithmのhashのパラメータ値でMozillaのテストコードでは"SHA-1"となっているが、仕様上は{name: "SHA-1"}となるのが正しいようでこれならChromeでもFirefoxでも動作する。前述のように必要の無いパラメータの指定方法が原因で実装により動作するもの、しないものがあり、相互運用性の問題が生じている。

そのような意味では、jsrsasignのKEYUTIL.getKey()メソッドでは入力は極力自動解析し最小のパラメータで動作するようになっていて、秘密鍵であろうが、公開鍵であろうが、JSON形式であろうが、鍵が暗号化されていようが、鍵アルゴリズムが何であろうが、許容範囲の広い実装となっています。

Web Crypto APIの困った所6：アルゴリズムサポート状況の不明瞭

前回紹介したCan I Use CryptographyのページでChrome等いろんなブラウザがフルサポートかのような記述になっていますが、W3Cの勧告候補でも特にどのアルゴリズムは実装必須となっているわけではないようで、ECDSA、RSA-PSSなどサポートしていないアルゴリズムはかなり多いです。(IE11+ではSHA-1未サポートのよう) この辺りについてスペックがどうなっているのかブラウザベンダーから正式な開示が無いようですし、仕様上も何をサポートしているかを知る術が特になく、動かしてみて動かなかったら未サポートのような状況になっています。そもそも、Java JCEやOpenSSLなどに比べたら、アルゴリズムの数が圧倒的に少ないのですから、全アルゴリズムを実装必須(MUST) としても良いぐらいではないかと思います。また、Java JCEではどのようなアルゴリズムをサポートしているかを知るためのAPIがあります。ブラウザ毎のアルゴリズムや機能のサポート状況の比較は、そのうち表などで比較できればと思っています。

Web Crypto APIの困った所7：サポートアルゴリズムの狭さと変なバランス感

W3C Web Crypto APIでは、 MD5、RSA暗号(RSAES-PKCS1-v1_5)など現時点で脆弱とされているアルゴリズムは除外されており、サポートされているアルゴリズムはかなり限定的で狭いものです。後方互換性や相互運用性のために使いたいというケースもあるでしょうから、暗号ライブラリとしては、サポートしても良いのかなと思ったりもします。その割には、例えばFirefoxではRSA鍵の鍵長が256bit～7168bitをサポートしており、むしろそちらの方を制限すべきなのでは？とも思ってしまいます。また、FirefoxではECDSAをサポートしていないのに、ECDHはサポートしているなど、同じECCの鍵生成なのに、このあたりのバランス感や優先順位も奇妙に思います。

Web Crypto APIの困った所8：鍵生成のパラメータ

例えばRSA鍵生成のパラメータですが、RSA署名やRSA暗号化のアルゴリズムを指定しなければならないのかわからず、公開指数の指定の仕方も面倒で、何故ハッシュを指定しなければならないのかわかりません。また、これらのパラメータは省略は一切許されていません。間違えるとエラーとなり、どこが間違っているのかに関するエラーメッセージはどの実装も非常に不親切です。


var paramKeyGen = {
  name: "RSASSA-PKCS1-v1_5", // RSA-PSS, RSA-OAEPなど指定する必要なくRSAで十分では？
  modulusLength: 2048,
  publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 整数65537でいいのでは？Uint8Array面倒
  hash: { name: "SHA-256" } // hashが必須な意味がわからない
};

高い相互運用性のために

一連のシリーズでは、最も汎用性が高くなるように、 window.crypto、window.crypto.subtleを使っており、 FirefoxやChromeでそのまま動く動作コードになっています。これらに加え、IEやSafariなどいろんなブラウザで動かそうとする場合には、以下のようなコード先頭に入れ、


var WC = null;
var WCS = null;
if (window.msCrypto) WC = window.msCrypto; // IE11+
if (window.crypto) WC = window.crypto;     // FF34+,CH37+ and others
if (WC.subtle) WCS = WC.subtle;            // IE11+,FF34+,CH37+ and others
if (WC.webkitSubtle) WCS = WC.webkitSubtle; // Safari 7.1+

window.cryptoの代わりにWCを、 window.crypto.subtleの代わりにWCSを使えば、どこでも動く可能性が高くなるかと思います。

おわりに

今回は、RSA鍵ペアの生成、署名生成、署名検証についてみてみました。今日はこんなとこで。

タグ：: #W3CWebCryptographyAPI; #W3C; #Cryptography; #API; #暗号ライブラリ; #署名; #インポート; #JavaScript; #RSA; #RSA署名

2015年01月02日07:01

カテゴリ: SSLTLS; JavaScript

W3C Web Cryptography APIとの果てしなき戦い(第1回)

あけましておめでとうござます。ウェブ関連技術の標準化を進めているW3Cから W3C Web Cryptography API という勧告候補が出てまして、このAPIを使えば公開鍵暗号、共通鍵暗号、鍵交換、鍵生成、暗号化、署名、ハッシュ関数、擬似乱数なんかが使えちゃうのだそう。 Twitterの私のリプライに「ほとんどのブラウザがサポートしてるから (jsrsasignでも) 使いなさいよ」と海外から何名かの方がコメントしてくださるので、重い腰を上げて勉強してみたんですが、「ムキ～～っ！！わけわからん！標準化って何なの？相互運用性著しく低いしっ。そもそも、このAPIってJavaScriptを書くプログラマにちっとも優しくないよね！」と怒り心頭なんですが、年も明けたことですし、そのあたりのことを愚痴っぽく、ぼちぼち書いてみたいと思います。

結論から言うと「今すぐ、これを使うとヤケドするので、実装がこなれてきたり、様々なラッパーやユーティリティが整備されるまで使うのは1、2年はお待ちなさい」という事かなと思います。

APIはどれくらい使えるの？

いろいろなウェブブラウザの機能のサポート状況を公開してくれているサイトにcaniuse.comというサイトがあるのですが、そこで W3C Web Cryptography API の主要なウェブブラウザ毎のサポート状況が公開されています。

fig1
(出典： Can I Use Web Cryptography)
グレーで囲まれているのが2015年1月時点で現行バージョンのブラウザで、緑はフルサポート、黄緑は一部サポートを示しているんですが、 IE、Firefox、Chrome、Safari、Operaやスマホなどのほとんどブラウザで APIをサポートしていると言っています。世界のブラウザシェアでは51.39%、日本では58.17%が APIをサポートしているのだそうです。この図だけを見たら、問題なく簡単に使えそうな気がしちゃいますよね。

ハッシュ関数の例

それでは早速、ハッシュ関数の例を見ていきましょう。文字列"aaa"のSHA-1ハッシュ値を計算するとします。細かい関数は後で紹介していくとして、ハッシュ計算の流れは以下の例のようになります。


var textBuf = asciitouint8a("aaa"); // ハッシュ対象文字列aaaをUint8Arrayに変換
window.crypto.subtle.digest({name: 'SHA-1'}, textBuf).then( // SHA1ハッシュを計算
  function(hashValue) { // 成功した場合に呼び出される関数
    console.log("sha1(aaa)=" + abtohex(hashValue)); // 結果ArrayBufferを16進数に
  },
  function(error) { // 失敗した場合に呼び出される関数
    console.log("sha1(aaa)エラー: " + error);
  }
);
#文末にasciitouint8a, abtohexのコードはつけておきます。

APIのハッシュ関数、暗号化、鍵生成などの関数は、乱数生成を除いて全て "window.crypto.subtle" の名前空間に入っており、ハッシュ関数は "digest" となっています。

ハッシュの入力はHTML5で導入されたバイナリデータを扱うクラスUint8Arrayなど、ハッシュの結果はArrayBufferクラスで帰ってきます。例では文字列から Uint8Array配列にしたり、ArrayBufferを16進数で表示できるようにユーティリティー関数を使っています。

APIの殆ど全ての暗号機能は非同期実行APIになっており、関数やメソッドが実行されても、すぐには結果が帰ってきません。ウェブブラウザで、ある処理を行っている間、表示が固まったりしないように非同期実行にしてあるのだそうです。(後日、突っ込みますw)

JavaScriptで非同期実行するには2通りの方法があるらしく、 windows.crypto.subtle.digest関数は非同期実行オブジェクトを返します。

Promiseパターンを使う方法(thenを使う。WebCryptでは主流?)
イベント(oncomplete,onerror)を使う方法(IE WebCryptで主流?)

Promiseパターンによる非同期実行

Promiseパターン、もしくはDeferredパターンと呼ばるデザインパターンは、非同期処理は遅延実行を扱うパターンなのだそうです。上の例ではdigest()関数により、非同期実行のためのPromiseオブジェクトが生成され、処理が終わった際にどんな関数を実行するか、エラーが起きた際にどんな関数を実行するかをthen()メソッドで定義しておきます。


var promiseObj = new Promise();
promiseObj.then(
  処理が終わった時に実行される関数,
  エラー発生時に実行される関数
);

Promiseパターンでは、非同期処理するオブジェクトをthenでチェーンすることにより、処理1、処理2・・・のようにシーケンシャルに実行させることも可能です。


var promiseObj1 = new Promise();
promiseObj1
.then(
  function(result) { // 処理1が成功したら実行される関数
    ...
    return new Promise(); // 新しい処理2の非同期処理オブジェクト
  }
  function(err) {...}
).then(
  function(result) { // 処理2が成功したら実行される関数
    ...
    return new Promise(); // 新しい処理3の非同期処理オブジェクト
  }
  function(err) {...}
).then(
  // 処理3
);

Promiseパターンの方が、後述のイベントによる非同期実行よりも、 thenチェーンなど使えて綺麗に書けるので Web Crypto APIでは、こちらの方が主流の使い方となるのだと思います。 Promiseパターンについて詳しく知りたい場合には、以下を参考にされると良いと思います。

イベントによる非同期実行

IEのWeb Crypto APIのサンプルでは、digest()で非同期実行オブジェクトを生成するところまでは一緒ですが、これに処理が完了した場合に実行される関数を参照するイベントプロパティ oncomplete と、エラーが発生した際に実行される関数を参照するイベントプロパティ onerror を定義することによりハッシュ計算を非同期実行しています。


var data = new Uint8Array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
var digestValue;
var crypto = window.msCrypto;
if (crypto.subtle) {
  var op = crypto.subtle.digest({ name: "SHA-256" }, data);
  op.onerror = function (evt) { console.log("op.onerror event handler fired."); }
  op.oncomplete = function (evt) {
    digestValue = evt.target.result;
    console.log("op.oncomplete event handler fired, digest computation complete.");
  };
}
else {
  console.log("Unable to create window.crypto object.");
}
(出典：MSDN: Web Cryptography: digest method)

IE 11+のW3C Web Cryptography APIでは、Promiseパターンではなく、イベントによる方法しかサポートされていないのだと思います。

Web Crypto APIの困った所1：非同期実行

ここから、なんだか愚痴や文句っぽくなってきますorz W3C Web Cryptography APIの困ったなぁと思うのは、 (処理が大して重くないのに)非同期実行しかサポートされていないところです。非同期実行は、それを使い始めてしまうと以降の全ての処理を非同期実行しなければならず、途中の一部だけを非同期実行することができません。
fig2

非同期実行は鍵生成して、鍵を保管して、署名するといった一連の処理をまとめて非同期実行させて、表示が固まらないようにしたいのであり、個々の暗号プリミティブレベルで非同期実行したいわけではないと思います。暗号プリミティブを非同期実行するかはプログラマに任せてほしく、暗号プリミティブは同期実行の方がよかったのではないかと思います。

IEと他のブラウザとで非同期実行の記述に一貫性が無いのも面倒だと思います。

Web Crypto APIの困った所2：名前空間が統一されてない

Can I useサイトやMSDNの例を見て「あれ？」と思った人もいると思いますが、Web Crypto APIの名前空間って実装によって統一されているというわけではないんです。

window.crypto.subtle - Firefox、Chromeなど
window.msCrypt.subtle - IE11+
window.crypto.webkitSubtle - Safari, iOS Safari

実装の中身がブラウザによっていろいろ違うので、名前で分かれていてもいいのかなとも思いますが、そもそもW3Cで「標準化」してるんですよねぇ？と。酷い話だなぁと思います。

Web Crypto APIの困った所3：ArrayBufferによるインタフェース

ハッシュや署名の入力はUint8ArrayといったArrayBufferViewのサブクラスでなければいけなかったり、出力はArrayBufferになっていたりと、文末のasciitouint8aやabtohexなど見てもらえれば判る通り、処理するのが結構面倒くさいです。ファイルなど大きなサイズのデータを扱う際にはわかりますが、ハッシュの結果となるハッシュ値なんか大した大きさでないのに ArrayBufferで戻されます。

Web Crypto APIの困った所4：多態性のなさ

ハッシュ関数の入力に関して、文字列でも、整数は配列でも、Uint8Arrayでも「ひとつよしなに」ハッシュを計算してくれてもよさそうなもんですが、そうした多態性(polymorphism)は無くて、入力はUint8ArrayのようなArrayBufferViewでなければなりません。多態性はJavaScriptの大きなメリットの一つだと思うんですが、 W3C Web Cryptography APIを使っていると、JavaScriptから Cで関数を呼び出ししているような気分になります。 (入力の融通のきかなさは次回他にも紹介します。)

Web Crypto APIの困った所5：ドキュメントやサンプルの少なさ

解説記事やサンプルを紹介しているサイトもあるのですが、そもそも、例が少ないですし、それが希望のブラウザで動作するかわからず、コードの相互運用性に本当に苦労させられます。また、ブラウザがどの機能をちゃんとサポートしているのか、よくわからず、公開ドキュメントもないので、それが自分のコードのバグなのか仕様なのかよくわからない事も問題です。

おわりに

というわけで、今回は導入として、W3C Web Cryptography APIの雰囲気とハッシュ関数の例について見てみました。不勉強なため、認識違いをしている所もあると思いますが、その際にはコメント等でご指摘いただければと思います。次回以降、鍵生成、署名、共通鍵暗号等を紹介したり、勉強になるサイトを紹介していこうと思います。ではでは。

(おまけ)例で使ったabtohex、asciitouint8aの定義


// ASCII文字列をUint8Arrayの配列に変換
function asciitouint8a(s) {
    var buf = new Uint8Array(s.length);
    for (var i = 0; i < s.length; i++) {
        buf[i] = s.charCodeAt(i);
    }
    return buf;
}
// ArrayBufferから16進数文字列に変換
function abtohex(arrayBuffer) {
  var s = "";
  var dataView = new DataView(arrayBuffer);
  for (var i = 0; i < arrayBuffer.byteLength; i++) {
    var hex = dataView.getUint8(i).toString(16);
    hex = "00".substr(0, 2 - hex.length) + hex;
    s += hex;
  }
  return s;
}

タグ：: #W3CWebCryptographyAPI; #W3C; #Cryptography; #API; #暗号ライブラリ; #暗号; #署名; #鍵生成; #ハッシュ関数; #JavaScript

2014年05月10日23:52

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

ロシアの方が開発したJavaScript PKIライブラリPKI.jsをさわってみたぞ

私はJavaScript実装の暗号ライブラリ jsrsasign(注：RSAだけじゃないよ!) を開発などして遊んでいるわけですが、そんな矢先、先週ぐらいですかねぇ、PKI.js(http://pkijs.org/) というJavaScript暗号ライブラリが公開されました。ぶったまげたのはpure JavaScriptなのにOCSPやCMS SignedDataやTimeStampなんかに対応しているのだそうです。さらに凄いのはNIST PKITSのテストも通すせるような認証パス検証(証明書のチェーンの検証)機能も実装されているのだそうです。先を越されて悔し～～～って感じ。ようやく時間ができたので、ちょっと動かしたりしてみたのでブログに書いておこうと思います。

WebCryptoを使っているのね

早速ダウンロードしてみて、サンプルには証明書の生成と、CMS SignedDataの生成があるんですがブラウザで動かしてみようとするも動かない。ちょっと調べてみると W3C Web Cryptography API を使っているんですよね。ええ？これってまともな実装あるんだっけ？と思ってTwitterでちょっと書いていたら作者のYury Strozhevskyさんから連絡が来てメールでいろいろ質問をしてしまいました。 GlobalSignのgithubリポジトリなのでGlobalSignの人かとおもったらフリーランスのプログラマなのだそうです。 YuryさんはCAdESに興味があってブログ記事書かれているみたいなのでそのうちPKI.jsがCAdESに対応する日も近いのではと、、、

さて、WebCryptoの実装なんですが、普通のほとんどのブラウザではだめで Chromeのnightly buildを使えって言われました。確認したところWebCryptoを今使うには方法は3つあるようで

Chromiumを使って環境設定する
Chrome nightly buildを使って環境設定する

(Safari)WebKit Nightly Buildを使う

Chrome nightly/Chromiumの環境設定は以下のようにやればいいようです。(Yuryさんあざます。)

アドレスバーでchrome://flagsを開く
次の4つを有効にする
1. #extension-apis
2. #enable-javascript-harmony
3. #enable-experimental-web-platform-features
4. #enable-devtools-experiments
フラグ設定画面の一番したのボタンで再起動する

ChromiumのWebCrypto実装に関するIssue Trackerはここを参照すればよさそう。

早速動かしてみるぞ

githubで落としただけでは簡単に動かず、まぁ以下のようにやります。

pkijs.orgからソースを落とす
asn1js.orgからソースを落とす
解凍しasn1jsのorg/pkijs/asn1.jsをpkijsのorg/pkijs/にコピーする
サンプルHTMLを解凍したpkijsの直下にコピーする(cd pkijs; cp examples/*/*.html .)

サンプルは以下があります。

CreateNewX509Certificate.html - RSA鍵ペア生成と証明書の生成
CreateCMSSignedData.html - RSA鍵ペア生成と証明書の生成とCMS SignedDataの生成

コピーしたHTMLをChromium等で開けば証明書のサンプルは動くんですが、 CMS SignedDataは生成されませんでした。コード追ってみると以下のようにコメントアウトしてやればとりあえず動きました。

// in CreateCMSSignedData.html (line 341) //result_string = result_string + formatPEM(hex_coded);

ほら、ちゃんとPKCS#7 (まぁだいたいCMS SignedDataと同じ)署名データができていますよね。中身のぞいてみるとちゃんと内包形式のCMS SignedDataができてます。証明書DNはBMPStringなんすよね～～。なんか、ロシアの人はBMPString好きですよね。

タイムスタンプを発行しようとするも

ちょっと格闘してタイムスタンプを発行しようとするも、 APIドキュメントがなかったり、タイムスタンプを発行するにも MessageImprintを作るのですら結構手間だったり、 TimeStampResponseに署名をしようとするようなちょっとメソッドがわかりにくかったりで一筋縄では発行できそうになく心が折れてしまいましたorz

おわりに

W3C WebCrypto APIが一般のブラウザで使われるようになれば、とても可能性が広がりそうなJavaScript PKIライブラリ PKI.js をさわってみました。とても悔しいのでjsrsasignでもCMS SignedData 対応をしようと思っています。

追記

PKI.jsのコードを眺めてみたりして気になった特徴をここにまとめておきます。

現時点ではSHA1,SHA2(256,384,512)の証明書しか対応していない
現時点ではRSA鍵しか扱えないようだ

(2014.05.11 23:14) 私がブログやTwitterで書いたことで、日本のプログラマの多くの方がYuryさんのPKI.js githubにLikeをしてくれたそうで、Yuryさんはとても喜んでくれました。ロシアからは何故かこのライブドアのブログが見えないそうで、どんな事が書かれているのか気になるので是非送ってほしいと言われてしまい、Google翻訳したページをメールで送ってあげました。YuryさんがCAdESの記事を書いていたのでETSIやECOMのCAdESの話を紹介してあげたら [1] [2] 喜んでくれました。

追記2(2014.05.12 23:49、2014.10.04更新)

簡単にPKI.jsとjsrsasignと比較をしてみましょう。

	PKI.js	jsrsasign
暗号計算	W3C WebCryptoAPIを使ったネイティブ処理なので速いはず	各暗号ライブラリに依存するがpure JavaScript実装のため遅い
対応暗号アルゴリズム	W3C WebCryptoAPIに依存しているが無いものも多い。現時点ではRSA, SHA1, SHA2のみ。	比較的豊富でRSA, DSA, ECDSA, SHA1, SHA2, MD5等幅広くサポート
APIドキュメント	現時点では無い	公開済
サンプル	公開されているが非常に少ない	公開済
テストコード	現時点では無い	公開済
対応ブラウザ・動作環境	WebCryptoAPIを有効にしたChromium, Chrome, WebKit(Safari)等開発用ブラウザのみ。スマートフォンは設定不能のため非サポート	ブラウザ、動作環境をあまり選ばない。スマートフォンブラウザでも動作
Node.js対応	基本的にWebCryptoAPIはブラウザ必須なのでNodeは対応していないはず。	鍵生成/乱数生成に一部問題があるもののNode.jsに対応
証明書チェーンの検証機能	あり	なし
RFC 3161デジタルタイムスタンプ	あり	あり(2014.05より)
CMS署名/暗号フォーマット	あり	署名のみ(2014.05より)
RFC5126CAdES長期署名	なし	BES/EPES/T(2014.06より)

2014.10.04: Node.jsについて追記

タグ：: #暗号ライブラリ; #PKIライブラリ; #cryptography; #library; #pki; #JavaScript; #WebCryptoAPI; #WebCrypto

2013年11月04日02:18

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

(小ネタ)Android 4.0.4と4.3.1とでJCEプロバイダはどう違うのか

新しいNexus 5がリリースされ新しいOSであるAndroid 4.4 KitKatもお目見えしたわけで、Nexus 7 2013を持っている私としては早くアップデートが出るのを心待ちにしています。

さて、アップデートが出てしまう前に、Android 4.0.4 (CUBE U20GT) と、Android 4.3.1 (Nexus 7 2013)とでJCEプロバイダがどう違うのかをみておきました。調べるのにはJCE Provider Checkerを使いました。

違いのまとめ

AndroidOpenSSLプロバイダ
- Mac: HmacSHA{1,256,384,512}の追加
- Cipher: AES,DES,3DES等追加
- Signature: {MD5,SHA{1,256,384,512}with{RSA,ECDSA}, SHA1withDSAの追加
- SecureRandom: SHA1RPNGの追加
- SSLContext: TLSv1.1, TLSv1.2の追加
BCプロバイダ
- バージョンが1.46から1.48へ
- 実装クラス名やAliasの変更がほとんどか？
AndroidKeyStoreプロバイダが新たに追加された

AndroidOpenSSLでTLSv1.1, v1.2がサポートされるようになったのは重要ですかね。 JCE Provider Checkerはデータのコピペが面倒だとわかったのでこれは改善しないといけません。

タグ：: #Java; #JCEプロバイダ; #JCE; #Android; #暗号ライブラリ

2009年07月15日19:51

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

RSA BSAFE Share for Java 1.1のリリース

フリーのJavaの暗号ライブラリRSA BSAFE Shareがバージョンアップされたそうです。

変更点は以下のようです。

- EC DRBGアルゴリズムの乱数生成器
- 乱数生成器の場合にHSMが使える
- JCE APIを使ったCSRの生成 (PKCS#10, Certificate Request Message Format)
- JCE APIを使ったCertificate Management Protocolの利用
- 外部セッションキャッシュにおけるセッション情報保持のサポート
- RFC 5430に準拠したSuite-Bのサポート

うぅ～～む、PKCS#10ぐらいですかね？

あまり、注目するところは他には無いかと、、、、

タグ：: #Java; #JCE; #JSSE; #RSA; #BSAFE; #暗号ライブラリ

2009年05月23日11:35

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

RSA BSAFE Shareを試してみました(その6)

忘れた頃にやってくるBSAFE Shareの連載ですが、前回に引き続き証明書のパス検証関連で、今回は「BSAFE Shareの事前生成されたOCSPを使ったパス検証機能」を試してみたいと思います。

Java JCEのパス検証に対応したプロバイダ

Java JCE の証明書のパス構築(CertPathBuilder)、パス検証(CertPathValidator)をサポートしている一般に入手やすそうなJCEプロバイダとして

・SUN (Sun Java J2SE 1.4以降に含まれる)
・RSA BSAFE Share
・BouncyCastle
・IBM Java

の3つがあります。(IAIKやEntrust Toolkitはパス構築・検証についてJCEとは別のAPIを提供しています。)

RSA BSAFE Shareには、フツーのPKIXパス検証のオプションとして、OCSPを使った検証にも対応しているんですが、他のプロバイダには無い機能として

事前に取得していたOCSPレスポンスのデータを使ってパス検証ができる

っていうのがあります。Windows Vista以降はやっていますがOCSPレスポンスをキャッシュしておき再利用して検証するなんていう芸当がJavaでもできるっていうわけです。

これは、特にCAdESやXAdES長期署名をやっている人は食付いてきますよね（－－；CAdESやXAdESでは署名者証明書の検証情報(ルートまでの証明書のチェーン、CRL、OCSPレスポンス)を一緒にいれておいて将来検証に使ったりするのでデータとして渡されたOCSPレスポンスを使ってパス検証する必要があるわけです。ところが、SUNのプロバイダはオンライン取得しかサポートしていないのでこれができなかったわけです。

OCSPに対応したCAdESやXAdESの実装をやってらっしゃる方は、OCSPレスポンスのデータを使ってパス検証する仕組みを(どれくらい真面目にやっているかは別にして)実装されているんじゃないかと思います。(私もそうです)

OCSP応答ファイルを使った検証サンプル

BSAFE Shareのサンプル(sample/src/jce/certpath/ValidatePathUsingOCSPResponse.java)というのがあります。サンプルでは

・サブCA証明書(CAphoenix.crt)
・EE証明書(janet.crt)
・EE証明書検証用のOCSPレスポンス(ocspResponse.rsp)

が使われています。例によって(Javaで書くよりも余計な飾りが無い分全体の動きが見やすいと思うので)Jythonでサックリ書いてみると、、、、

# (0) BSAFE Share JCEプロバイダ設定して...

Security.insertProviderAt(JsafeJCE(), 1)

# (1) ファイル読んで...

cf = CertificateFactory.getInstance("X.509", "JsafeJCE")

caCert = cf.generateCertificate(FileInputStream("CAphoenix.crt"))

eeCert = cf.generateCertificate(FileInputStream("janet.crt"))

ocspBytes = 何らかの方法でOCSP応答"ocspResponse.rsp"をbyte配列で読んで

# (2) CertPath作って...

chain = ArrayList()

chain.add(eeCert)

certPath = cf.generateCertPath(chain)

# (3) CertPathParameter作って...

#  (3.1) トラストアンカ作って...

ta = TrustAnchor(caCert, None)

trustAnchors = HashSet()

trustAnchors.add(ta)

pkixParams = PKIXParameters(trustAnchors)

#  (3.2) OCSPパラメータ作って..

ocspParams = OCSPWithResponseParameters(ocspBytes, caCert)

#  (3.3) CertPathパラメータ作って...

certPathParams = CertPathWithOCSPParameters(pkixParams, ocspParams)

# (4) 検証っと、、、、

certPathValidator = CertPathValidator.getInstance("PKIX", "JsafeJCE")

print  certPathValidator.validate(certPath, certPathParams)

こんな流れになります。

(1) 証明書やOCSPを読み込んで
(2) CertPathオブジェクトを生成
(3) 検証用のPKIXParameterとOCSPパラメータを生成
(4) 検証

検証に使うOCSPレスポンス

OCSPのデータを使って検証する場合に、OCSPResponseを使うのか、BasicOCSPResponseなのかというのは気になるところです。詳しくはRFC 2560を見てもらうとしてざっくりこんな違いがあります。

・OCSPResponse
　・BSAFE OCSPWithResponseParameters ではこれを用いる
　・OCSPで返されるメッセージの全体
　・中に成功したかどうかという状態情報(responseStatus)を含む
　・通常は中にBasicOCSPResponseを含む
　・XAdESではOCSP検証情報としてこれを用いる
　・OpenSSLでもファイルとして検証できる
・BasicOCSPResponse
　・単数または複数の証明書の有効状態
　・OCSPResponseに含まれる
　・CAdESではOCSP検証情報としてこれを用いる
　・OpenSSLではファイルとして検証できない

このように、書いてしまった通り、BSAFE Share で検証させる場合にはOCSPResponseを使わなければなりません。CAdESの検証に使う場合にはBasicOCSPResponseからresponseStatus: successful をくっつけてラップしてOCSPResponseを作ってやらないといけません。

OCSPResponseかBasicOCSPResponseかを見分けるには dumpasn1 で表示させたときに先頭の辺にENUMERATED 0とあればOCSPResponse

SEQUENCE { ← OCSPResponseの始まり

  ENUMERATED 0 ← responseStatus: successful

  [0] {

    SEQUENCE {

      OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)

      OCTET STRING, encapsulates {

        SEQUENCE { ← BasicOCSPResponseの始まり

          SEQUENCE {

            [1] { ← ResponderID.ByName

              SEQUENCE {

                SET {

                  SEQUENCE {

                    OBJECT IDENTIFIER countryName (2 5 4 6)

                    PrintableString 'FR'

　　：以下略

無ければ BasicOCSPResponse

SEQUENCE { ← BasicOCSPResponseの始まり

  SEQUENCE {

    [1] { ← ResponderID.ByName

      SEQUENCE {

        SET {

          SEQUENCE {

            OBJECT IDENTIFIER countryName (2 5 4 6)

            PrintableString 'FR'

            }

　　：以下略

ということになります。

ちょっと残念なところ

最初サンプルコードを見たときちょっと怪しいなぁ、、と思ったんですが、サンプルでは検証対象が

・SubCAがトラストアンカ
・SubCA→EEの一段のみ
・OCSPレスポンダ証明書はSubCA証明書と同じ

となっているんです。サンプルを見てみると

ocspParams = OCSPWithResponseParameters(ocspBytes, caCert)

つまり、パス中に入れられるOCSPレスポンスは高々一つだけって事です。Root→SubCA1→SubCA2→EEみたいな多段の証明書チェーンの場合にSubCA1、SubCA2の検証にはOCSPは使えないってことを意味しますし、OCSPレスポンダ証明書が事前にわかっているケースでしか使えないってことがわかります。

どうやら、証明書とOCSPレスポンスをごそっと投げて「検証お願いっっ！（はぁと）」というわけにはいかないようです。

途中までCRLでいいや、、、って場合にはPKIXParametersにCollectionStoreを追加してCRLをぶちこんでやれば検証できると思います。

まとめると

・OCSPレスポンダ証明書のパス検証はしない
・事前にOCSPレスポンダ証明書がわかっていなければいけない
・多段のOCSPは使えない

っていうことなんで前処理をしっかりやらないと汎用的なパス検証に使うのは面倒くさい感じですよね。

今、自前でもっているパス検証のやつは

・OCSPレスポンダ証明書を事前に知っておく必要はない
・OCSPレスポンダ証明書のトラストアンカからのパス検証を行う
・コレクションストアに入れていれば適切なOCSPレスポンスを選ぶ
・中間CAのOCSPレスポンスデータによる検証にも対応する
・OCSPのモデル(直接、委譲等)は問わない

というようになっているので、う～～～む、最初はよさげと思ったんですが、結局当面は自前のを使うことになりそう、、、

NIST PKITSと似たやつでOCSPを含むパス検証でまともなテストケースが欲しいなぁ、、、、、時間を見つけて作るかなぁ、、、、

タグ：: #RSA; #BSAFE; #share; #JCE; #Java; #JSSE; #暗号ライブラリ

2009年05月02日10:34

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

RSA BSAFE Shareを試してみました(その5)

前回からいい感じに回数が開きましたが、またRSA BSAFE Shareの話を、、、、

PKIX CertPathBuilderはかなり良い感じ

前回はNIST PKITSを使ってRSA BSAFE ShareのPKIX CertPathValidator(パス検証)を試してみましたが、今回はPKIX CertPathBuilder(パス構築)の方をためしてみました。

RSA BSAFE ShareのPKIX CertPathValidatorはSUNと比べてエラーの理由がわからんとダメ出しをしてしまい、同様にSUNのPKIX CertPathBuilderにも失敗の原因がさっぱりわからん！！！とダメ出しをしているですが今度はどうかな、、、、、

結果的に言うとBSAFEのPKIX CertPathBuilderは失敗の理由がバッチリわかるのでSUNなんかより良いです。

テストに使うパスは昔つかったスイカ型メッシュモデル風のパスです。

RSA BSAFEのCertPathBuilder、CertPathValidatorの困ったところは"-Djava.security.debug=cerpath"フラグを使ってもデバッグメッセージを全く吐かないところです。中の動きが見えにくいし、、、、、

一応デバッグフラグをつけておくと、SunのX509CertSelectorのログだけは出力されます。でデバッグ出力からパスの繋ぎ方を見る方法ですが、

certpath: X509CertSelector.match(SN: 証明書シリアル
Issuer: 発行者DN
Subject: 主体者DN)
certpath: X509CertSelector.match returning: true

の行があれば、この証明書がパス構築に使われたことを示します。それをログの上から順に見ていきます。

で、そのスイカ型モデルでパス検証をしてログを見てると、こんな感じの順序で証明書を使っているのがわかります。

cpb_rsa01

つまり、RSA BSAFE Share for JavaのPKIX CertPathBuilder実装は：
・SUNと同じエンドエンティティからルートに向けた構築
・SUNと同じ深さ優先探索
であることがわかります。

図のGGGから辿るパスは3通りあるわけですが、SUNの場合には2本辿ってダメで次に成功だったわけですが、RSAの場合には1回失敗した後で成功のパスを辿っています。

CollectionStoreの格納元にはArrayListを使っていたんですが、その格納順序で3本中のどれを選ぶかが変わるのかなと思って試してみましたが、どうもそうではないようです。

で、私の気になっているパス構築失敗時のエラーメッセージですが、ちゃんとエラーメッセージ出力するんですよ。当たり前だけど、それがSUNではできてないので、エライじゃないですか（＾＾ｖ先ほどのスイカモデルで途中の証明書をなくしておいて失敗するように設定してみると、、、、

■有効なパス中のROOT→CCCの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Sat May 02 10:26:08 JST 2009 is before Sun Jan 02 09:00:00 JST 2000
　　ちゃんと有効期限のエラーが表示されます。
■上からさらにROOT→AAAの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Expected a CA certificate.
　　基本制約cAフラグのエラーっぽい感じがしますよね。

■SUNの場合ならいずれも全く無意味な以下の例外（－－；
　sun.security.provider.certpath.SunCertPathBuilderException:
　　unable to find valid certification path to requested target
　　こりゃなんの事かさっぱりわからん

Java実装のSSLのクライアントで「繋がんね～～～」とか悩んでいる場合には、SUNのはやめてRSA BSAFEを使うよう優先して調べるといいんじゃないっすかね。

タグ：: #RSA; #BSAFE; #share; #JCE; #Java; #JSSE; #暗号ライブラリ

2009年04月29日12:00

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

RSA BSAFE Shareを試してみました(その4)

前回に引き続きRSA BSAFE Share for Javaのお話を、、、、

NIST PKITSをやってみると

BSAFE Shareには"JsafeJCE"という名前のJCE(Java Cryptography Extension)プロバイダがあって、その中で証明書が信頼するルート証明書から辿って有効であることを検証する認証パスの構築や検証の実装が含まれています。

証明書のパス検証については米国標準技術局(NIST)がPKITSというテストケースとデータのセットを公開していてSUNのJCEプロバイダだとどうなんだ？みたいな話は4月13日に書きました。

じゃぁ、JsafeJCEプロバイダのCertPathValidatorのPKIXアルゴリズムの実装はどうなんだろうって、、、、気になりますよねぇ、、、ならないか、、、、

個人的に気になったのでやってみました。で、結果は、、、、、、

：
：
：
（－－；

拍子抜けというか、期待が大きかっただけにがっかりというか、実装に問題があったとかそういうのではなく結果としてSUN JCEの実装と殆どサポート範囲も含めてうり二つなんです。(だから、ブログに書きにくい、、、、結果が違ってたのはDeltaCRLのテスト1つだけ)

NIST PKITSのテスト結果からSUNとJsafeJCEのJCEプロバイダには以下のような共通の特徴があります。
・あるCAが証明書とCRLの発行を別の鍵(と証明書)で行う事の非サポート
・NewWithOldのテストの不具合(詳細は見てない)
・IndirectCRLの非サポート
・DeltaCRLの非サポート
間違ったテストも全く同じなので同じ開発元が作ってるのかな？とさえ思えてしまいます。

SUNよりもJsafeJCEの方が例外のメッセージも不親切気味なので、エラーが起きたときの原因の究明には手間取るかもしれません。以下が同じテストケースにおける例外メッセージの例です。

SUN: signature check failed: Signature does not match.
JsafeJCE: Certificate verify failed!
SUN: timestamp check failed: NotBefore: Jan 01 2047
JsafeJCE: Apr 29 2009 is after Jan 01 2047 (これは互角)
SUN: CA key usage check failed: keyCertSign bit is not set
JsafeJCE: Certificate verify failed!

どうです？「Certificate verify failed!」の一言で片付けられちゃうケースが多くて微妙な感じですよね（＾＾；CertPathValidatorに関しては、積極的にこれを利用する理由がいまひとつ見えてきませんでした。

楕円暗号の鍵生成ができない？！

RSA BSAFE Share for Javaでは楕円暗号の署名や証明書の検証、鍵交換(ECDSAやECDH)なんかができるんですが、JCEのサポートアルゴリズムのリストを見た限りでは楕円の鍵生成機能を提供していないようです。

楕円の証明書発行要求もできないのでは？！と思うんですが、どうでしょう、、、、

今日は、休日なんでこの辺で、、、、（－－；

＜お詫びと訂正 2009.04.29 17:48＞
私がアルゴリズム名を集計した表に誤りがありJsafeJCEでもちゃんと楕円の鍵生成はできます。混乱させてしまい申し訳ありませんでした。

タグ：: #RSA; #BSAFE; #share; #JCE; #Java; #JSSE; #暗号ライブラリ

記事一覧(手作り)

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

暗号ライブラリ

jsrsasignとは

jsrsasignの歴史を振り返る

jsrsasignはどれだけ使われているか

ユーザが増えた悩みの始まり

そんな中おきたThe RegisterやUsenixの指摘

やっとMinerva脆弱性の修正

そしてまた別のMalleabilityに関する脆弱性指摘が3つも

そして寄付金を募ることにしました

今後、そのうちどうするか

ハッシュ関数

公開鍵ペアの生成

RSA鍵による署名と検証

サンプルの動作環境

おわりに

関連記事

データの準備

秘密鍵のインポートと署名の生成

公開鍵のインポートと署名の検証

RSA鍵ペアの生成

Web Crypto APIの困った所5：importKeyの融通の利かなさ

Web Crypto APIの困った所6：アルゴリズムサポート状況の不明瞭

Web Crypto APIの困った所7：サポートアルゴリズムの狭さと変なバランス感

Web Crypto APIの困った所8：鍵生成のパラメータ

高い相互運用性のために

おわりに

関連記事

APIはどれくらい使えるの？

ハッシュ関数の例

Promiseパターンによる非同期実行

イベントによる非同期実行

Web Crypto APIの困った所1：非同期実行

Web Crypto APIの困った所2：名前空間が統一されてない

Web Crypto APIの困った所3：ArrayBufferによるインタフェース

Web Crypto APIの困った所4：多態性のなさ

Web Crypto APIの困った所5：ドキュメントやサンプルの少なさ

おわりに

関連記事

(おまけ)例で使ったabtohex、asciitouint8aの定義

WebCryptoを使っているのね

早速動かしてみるぞ

タイムスタンプを発行しようとするも

おわりに

追記

追記2(2014.05.12 23:49、2014.10.04更新)

違いのまとめ

Java JCEのパス検証に対応したプロバイダ

OCSP応答ファイルを使った検証サンプル

検証に使うOCSPレスポンス

ちょっと残念なところ

PKIX CertPathBuilderはかなり良い感じ

NIST PKITSをやってみると

楕円暗号の鍵生成ができない？！