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

図説

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月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年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; #証明書検証; #図説

記事一覧(手作り)

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