自堕落な技術者の日記

忘れた頃にやってくる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の話を、、、、

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

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

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





つまり、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 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でもちゃんと楕円の鍵生成はできます。混乱させてしまい申し訳ありませんでした。

今日は、その他雑多なわかった事、前に書き忘れていた事をつらつらと書いてみたいと思います。

サンプルのビルド

そういえば、サンプルプログラムのビルドについて説明してませんでしたね。

結構豊富なサンプルが用意されています。

サンプルのビルドはEclipseで行います。サンプルが使用するデータファイルのパスが絶対パスで"/data/..." だったりするようなので、Unix系でないとサンプルが動かないかもしれないです。(面倒なので試してない、、、)

Eclipseのメニューから「ファイル＞インポート」を選びウィザードで「一般＞既存プロジェクトをワークスペースへ」でできたと思います。

サンプルのビルドは同じくメニューから「プロジェクト＞プロジェクトのビルド」でビルドできたと思います。

なんでAntじゃないんだろう、、、プンプン、、、、

FIPS 140-2 Level1認定は無い

RSA BSAFE ShareはFIPS 140-2 Level1認定は無いそうで、これが必要ならば商用ライセンスが必要なんだそうです。RSA BSAFE ShareでもFIPSモードみたいなのはあるみたいなんですが、これを設定するとエラーになったりするんでしょうか。

時間がある時、調べてみたいと思います。

そもそもDevelopper's Guideは読め

さすが基本的にちゃんとした商用ライブラリなんでIAIKやBouncyCastleなんかと違ってドキュメントは充実してました。まずはDevelopper's Guide("doc/dev_guide/index.html")を読むべきでしたね。

SSLのCipherSuiteやサポートする暗号アルゴリズム、鍵長なんかもちゃんと記載されています。(JCEのアルゴリズム名はありませんが、、、)

TLSv1.2用のSuite-B AES-GCMを使ったCipherSuiteもちゃんとサポートされていました。(疑ってゴメンよ)

ちなみに、このガイドはdoxygenを使って書かれてるみたいです。

パス検証でEV証明書のチェッカーも付属

HTTPSで接続したときブラウザのアドレスバーが緑色になるEV(Extended Validation)証明書であるかどうかチェックするためのAPIもついていました。EV Guidelineで規定された証明書プロファイルに準拠しているか(アルゴリズム、鍵長も含めて)チェックしているみたいです。

ASN.1、CMS、PKCS#7なんかは無い

RSA BSAFE Share for Javaは

・暗号プリミティブ(暗号,署名,ハッシュ,メッセージ認証,乱数)
・SSL/TLS通信
・証明書検証

のためのライブラリであって

・CMS署名/暗号フォーマット
・PKCS#7署名/暗号フォーマット
・XML署名/暗号
・ASN.1
・証明書拡張の情報の取得

は守備範囲外みたいです。

CMS、PKCS#7はわかりますが、証明書ポリシのpolicyQualifierとか証明書の拡張を取り出して中身を見るには別のライブラリを使う必要があります。

JavaのJurisdiction Policyのチェック

ちょっとオモシロイと思ったので、これも紹介、、、、

Sun Javaは暗号ライブラリを含みワッセナー条約の輸出規制にかかるため、配布時点では管轄ポリシー(jurisdiction policy)ファイルで制限されています。

規制の対象外の殆どの国では、このポリシーファイル(jre/lib/security/{local,US_export}_policy.jar)を無制限強度(unlimited strength)のものに置き換えることで、鍵の長い強固な暗号を使えたりします。

BSAFEではこのポリシーのチェックのためのクラスがあって

# Jythonでスンマソン
from com.rsa.jsafe.crypto import *
print PolicyChecker.JurisdictionPolicyLevel.getJurisdictionPolicyLevel()

を実行してみると "UNLIMITED" と表示されたりします。

ちゃんとこれをプログラムでチェックできるのは本当にいいですよね。Java関係のいろんな製品のサポートとかでもJurisdiction Policyファイルを入れ替えてなかったせいでエラーや動かなかった報告はよく聞きますから、、、、

なんか、脈絡なくてごめんなさいね。今日は、この辺で、、、、、、

前回はRSA BSAFE Share for Javaを使えるように、プロバイダの設定や簡単なサンプルなんかを紹介しました。

前回、手持ちのJCEプロバイダで実装しているアルゴリズムの一覧表を作っていて、RSA BSAFE Shareについても加えてみたっていう話をしましたが、他のJCEプロバイダと比較してみて、各インタフェースクラスのRSA BSAFE Share for Java JCEプロバイダ実装の特徴をまとめるとこんな感じ、、、、

・署名/Signature: 代表的なものはカバー、SHA2、楕円もサポート
・暗号/Cipher: 代表的なものはカバー、珍しいとこではECIESwith*
・ハッシュ/MessageDigest: SHA2を含め代表的なものはカバー。RIPEMDは160のみ。
・安全な乱数生成器/SecureRandom: 他プロバイダと比較できない程種類が多い
・パス構築/CertPathBuilder: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・パス検証/CertPathValidator: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・メッセージ認証/Mac: HmacMD*, HmacSHA* などメジャーどこは全てカバー
・SSL通信内容/SSLContent: SSL*, TLSv1 など主要はサポート。TLSv1.2がある。
・SSL用トラストアンカ管理/TrustManagerFactory: PKIX-SuiteB*ある。

というわけで、暗号アルゴリズムはメジャーどこは全て押さえてあり、そつがない印象で幅広いケースで安心して使えるJCEライブラリになっています。

SecureRandomは種類が多いのはイイですが、優れたものが一つあれば十分で、交換したり、生成、検証したりしないので相互運用性が問題になることも無く、多かろうが少なかろうが、まぁ、あまり問題ではないかなと、、、、

やはり注目すべきなのは、他のJCEプロバイダにはない、パス構築・検証でのSuite-Bのサポートだと思います。

Suite-Bとは？

最近ちょっと話題になりつつある「Suite-B」とは、米国国家安全保障局(NSA)で定められた官民双方で利用できる一般的な機密保護のための仕様の公開された暗号アルゴリズムのセットです。さらに重要性の高い用途のためにNSAで開発された仕様非公開のアルゴリズムによる「Suite-A」というセットもあります。

・Suite-A
　・よりセンシティブな機密情報を扱うための暗号アルゴリズムのセット
　・NSAにより開発され仕様の公開されていない暗号アルゴリズムで構成される
　・ブロック暗号(Juniper)、非対称鍵暗号(MayFly)など
・Suite-B
　・一般的な機密情報を扱うための暗号アルゴリズムのセット
　・仕様の公開されている現在強度の高いとされる暗号アルゴリズムにより構成される

Suite-B は以下のパラメータの暗号アルゴリズムにより構成されています。

・共通鍵暗号: 鍵長128bitか256bitのAES-GCM暗号
・電子署名: ECDSA (楕円)
・鍵共有: ECDH (楕円Diffie-Hellman)
・ハッシュ関数: SHA-256とSHA-384

インターネットの標準であるRFCでは最近、IPsecでSuiteBを使うためにRFC 4969が出ていたり、S/MIME暗号メールでSuiteBを使うためのRFCが出ていたりします。

Windowsでは、Vista以降のCryptoAPIの後継であるCNGでSuiteBをサポートしていたり、Outlook2007でSuiteBしか使わないグループポリシにしたり、IPsecでSuiteBを使うようにしたり、認証局の証明書テンプレートでSuiteBを使うようにしたりできるようです。

BSAFE Shareのパス検証のSuiteB対応

指定された時刻に証明書のチェーンが正しく繋がっていて、失効しておらず、有効期限内であるかを確認するためにパス構築・検証を行います。

パス構築・検証でSuiteBの暗号しか使わないってことは、署名はSHA2と楕円暗号を使ったSHA256withECDSA or SHA384withECDSA署名アルゴリズムしか使えないってことになります。

鍵共有や共通鍵暗号についてはパス検証においては関係ありません。

ハッシュ関数については署名以外で直接的に使うところはあまり無いのですが、以下はSuiteBじゃなくてもいいんでしょうか、、、
・KeyIdentifierを生成する際、SHA-1のみしか使えないのは仕様なので仕方ない
・OCSPの識別名のハッシュを使う際SHA-1のみしか使えないのも仕方ない
・パス構築でCRLやOCSPを取得する際にHTTPS、LDAPSであった場合
　　TLSがSuiteBの暗号のみであることを必要とするのか？！
、、、んん〜〜っ、どうなんでしょうね、教えてエライ人（＾＾；


BSAFE Share for Javaではパス構築(CertPathBuilder)とパス検証(CertPathValidator)のために複数のアルゴリズムを提供しており、これは他のJCEプロバイダには無いところです。JCEアルゴリズム名の一覧は以下の通り。

・PKIX: RFC 3280に基づく証明書のパス構築・検証
・PKIX-SuiteB: 上記でSuiteBの暗号のみを使用
・PKIX-SuiteBTLS: TLS暗号化通信のパス構築・検証でSuiteBを使用
・X.509V1: X.509V1で規定されたパス構築・検証(証明書拡張が無い)

SuiteBかどうかは、パス検証後に署名アルゴリズムだけちゃちゃっとチェックすれば同じことのような気もしますが、JCEのアルゴリズムとして明示的に指定でき自動でやってくれちゃうっぽい、っていうのはスゴイところです。

SuiteBのTLSは？

暗号通信 TLS で SuiteB を使う時に、ハッシュやMacはまぁいいとして、共通鍵暗号として AES-GCM(Galois/Counter Mode)っていうのを使わなきゃいけないと思うんですが、BSAFEとか他のJCEプロバイダも含めてAES-GCMの対応ってどうなんでしょうか、、、単にAESのアルゴリズムパラメータで指定できるのかな、、、、

ここら辺は今後調査してみます。

BSAFE Share for Javaで足りないところ

BSAFE Share for Javaのサポートアルゴリズムの一覧をざっと見て思ったのは、RC2何とかやDES、TripleDESなんとかなど主要なものは一部ありますが、その派生のアルゴリズムでサポートしてないものが結構多いな、、、と感じました。後方互換性をバッサリ切っちゃうみたいなところはあるかと思います。

例えばこんなケースでサポートできなくて困らないかな、、、と心配します。

・PKCS#12形式の暗号化された秘密鍵
　　古い暗号アルゴリズムが使われており、鍵が取り出せないなんてことが
　　あるかもしれない。
・S/MIME暗号メールのメッセージ
　　古い暗号アルゴリズムが使われていて、メッセージを復号して見られない
　　なんてことがあるかも、、、

古いアルゴリズムのサポートに関してはIBMのJavaであるIBM J9に付いてくるJCEがかなり優秀だと思っていて古いものの扱いに困った時には、コレを使うといいと思います。S/MIMEは仕方ないですが、PKCS#12の方は、古いアルゴリズムが使われていたら新しい汎用的なアルゴリズムを使うように移行(マイグレーション)を考えておいた方がいいかもしれませんね。

というわけで、今回はBSAFE Share for JavaのSuiteB暗号スイート関連の話題を中心にサポートされている暗号アルゴリズムの紹介をしてみました。

ううむ、、、今回もマニアックな感じでしたね。すみません。

週末、RSA BSAFE Share for Javaをダウンロードしてみたので、いろいろ試してみました。

どんなアルゴリズムを実装しているか

JCEプロバイダの実装をゲットしたら、そのプロバイダがどんなアルゴリズムを実装しているのかを調べたくなるのが人情ってもの、、、、

製品紹介ページにアルゴリズムの一覧が書いてあったとしても、実際どうなの、、、とか、アルゴリズムの参照名がどうなっているの、、とかは気になりますし、それを知っとかないと後でアルゴリズム名が間違っているために障害起きたりして痛い目にあうので、日ごろからJCEプロバイダとアルゴリズム名の表はまめ手を入れて管理するようにしています。

現状手元にあるのが、
・IAIK JCE
・BouncyCastle
・Entrust Toolkit
・IBM J9 J2SE 1.6.0
そして新しく加わった
・RSA BSAFE Share

プロバイダ設定して、アルゴリズム一覧を出力するプログラムを使ってリストを出し、Excelで地味に表を更新します。

表を公開できればなぁ、、、とも思うんですが、26列×436行というHTMLでテーブル書くにはデカすぎるので、ちょっと出し方を考えておきます。

JCEプロバイダ毎にクセやら傾向があったりするんで、その辺りもいつかまとめて紹介したいと思います。

まず最初、プロバイダの設定

まず、2つのjarファイル、"lib/shareCrypto.jar"と"lib/shareTLS.jar"をJavaのクラスパスに入れてからRSA BSAFE ShareのJCEプロバイダを使えるようにするために方法が2つあります。

・設定ファイルに登録する方法
・動的に読み込む方法

利用できるJCEプロバイダは

$JAVA_HOME/jre/lib/security/java.security

のファイルの

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
　：以下略

に登録しておけば使えます。番号が小さいほど優先して使われるので、

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
　：以下略

のようにBSAFE Shareのものを先頭にもってきておき、他のは番号ずらしておけばBSAFEが優先して使われるようになります。

プログラムから動的にJCEプロバイダを使えるようにするにはプログラム中以下のような呼び出しをすれば、RSAのプロバイダが優先的に使えるようになります。

import java.security.Security;
import com.rsa.jsafe.provider.JsafeJCE;
import com.rsa.jsse.JsseProvider;

　：中略
try {
Security.insertProviderAt(new JsafeJCE(), 1);
Security.insertProviderAt(new JsseProvider(), 2);
} catch (Exception ex) { ex.printStackTrace(); }
　：中略

ここで注意しとかないといけないのが、JCEプロバイダ名とクラス名が合っていないところです。

・プロバイダ名："JsafeJCE" (こっちはクラス名と一致で安心。暗号関連の実装)
・プロバイダ名："RsaJsse" (こっちは違うので注意。SSLのためのプロバイダ)

例えばプロバイダを明示的に指定してSignatureオブジェクトをゲットしたい場合には、

import java.security.Signature;
Signature sig = Signature.getInstance("SHA1withRSA", "JsafeJCE");

先ほどRSA BSAFEを優先して登録したはずなので

Signature sig = Signature.getInstance("SHA1withRSA");

とプロバイダ指定しなくてもRSA BSAFEが使われます。

それでは、"JsafeJCE"プロバイダの"RIPEMD160"ハッシュアルゴリズムを使って文字列"aaa"に対するハッシュ値を計算してみましょう。

import java.math.*;

import java.security.*;

import com.rsa.jsafe.provider.*;

public class RipeTest1 {

  public static void main(String[] args) {

    try {

      MessageDigest md = MessageDigest.getInstance("RIPEMD160", "JsafeJCE");

      byte[] hash = md.digest("aaa".getBytes());

      System.out.println(new BigInteger(hash).toString(16));

    } catch (Exception ex) { ex.printStackTrace(); }

  }

}

ちなみにRSA BSAFE Share for Javaは JDK 1.4.x では使えないみたいで、

実行しようとすると

Exception in thread "main" java.lang.UnsupportedClassVersionError: RipeTest1 (Unsupported major.minor version 50.0)

コンパイルしようとすると

RipeTest1.java:7: com.rsa.jsafe.provider.JsafeJCE にアクセスできません。クラスファイル shareCrypto.jar(JsafeJCE.class) は不正です。
クラスファイルのバージョン 49.0 は不正です。48.0 であるべきです。
削除するか、クラスパスの正しいサブディレクトリにあるかを確認してください。

のようなエラーが出てしまいます。

今日は、初回なんでこの辺で、、、、

次回はRSA BSAFE Share for Javaの特徴みたいなところを紹介できれば、、、、と思っています。