自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

Java暗号プログラミング

2014年04月19日12:01
カテゴリ
Java暗号プログラミング
SSL証明書

(小ネタ)HeartBleed影響で証明書の再発行とそれに使うRSA鍵の事前チェック

OpenSSL HeartBleed問題で証明書の再発行やら説明やらなんやらに追われてたわけですが、再発行に際してちょっと鍵も事前チェックしてみるかなぁ、、、と。

Debianで生成するRSA鍵の乱数が固定の値になってしまい生成される全てのケースの秘密鍵がわかってブラックリスト化されたり[0]、因数分解の片方がわかっていれば秘密鍵は簡単に復元できちゃう問題とかあったり[1][2][3]で、鍵がそのような弱い鍵でないか調べるサイトとして米ミシガン大学のチームのfactorable.netというサイトがあり、PEM形式の証明書を貼れば調べることができます。

でも、これって発行済の(他のサイトの)証明書を調べるツールなわけで、自分の証明書を発行してもらってから鍵がダメだったってわかっても、再発行にはお金もかかるし、なんで公開鍵や証明書発行要求(CSR,PKCS#10)でチェックしてくれないのかなぁと思ったわけす。証明書発行要求時点でわかれば鍵ペア生成し直せばいいだけですから。

factorable.netの管理している方へ「証明書発行要求に対応してくんない？事前にチェックできた方が便利だと思うんだよねぇ。」みたいなメールを送ってもみたんですが「ナイスな改善提案ありがと。でも他にもToDoがあっていつ直せるかっていうのは約束できない。対応したら連絡するね。」という旨のメールが来てやんわり断られました。とほほ。

OpenSSLで鍵生成したならこんな感じで秘密鍵から自己署名証明書をとりあえず作ってチェックすればいいんだけど、

% openssl req -new -key aaa.prv -x509 -subj /C=JP/O=TEST1 -set_serial 1 -days 3652 -out aaa.cer
＃できたaaa.cerをfactorable.netでチェックすればよいです。
WindowsやHSMなんか使っている場合には、やはり証明書発行要求で事前チェックをするのが王道かなと。

仕方ないので簡単なツールを作りました。

jsrsasign: CSR to certificate converter:
http://kjur.github.io/jsrsasign/tool_forfact.html
jsrsasignを使って証明書発行要求から公開鍵をひっこ抜いて、適当な公開鍵証明書の形にでっちあげて、証明書の署名値はいいかげんな値に設定したニセの証明書を作ってしまえば、factorable.net で公開鍵が弱くないかチェックできるようになります。

これから発行してもらおうとしている証明書発行要求をツールに貼付けて「Convert」ボタンを押せばニセ証明書ができます。 (署名値は0x0102030405060708です。適当すぎますか？(^^;)
CSR-Self Cert Converter
この生成されたニセ証明書をfactorable.netのチェッカーにかければ、証明書発行要求とそれに紐づく鍵が弱い鍵でないかチェックすることができます。めでたしめでたし。
factorable.net key checker

factorable.net keychecker result

というわけでひっそりとjsrsasign 4.2.2を昨晩リリースしました。AuthorityKeyIdentifier証明書拡張に対応してくんない？というリクエストもあったので追加しときました。

今日はこの辺で

タグ ：
#RSA
#factorable
#jsrsasign
#CSR
#PKCS#10
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
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
#暗号ライブラリ
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2012年10月24日21:54
カテゴリ
Android
Java暗号プログラミング

(小ネタ)JCE Provider Checker for Android(Free)の公開

TwitterやFacebookでは書いたんですが、Androidで自分向けにいくつかツールを作ったりなんかしており、Google Playでのアプリの公開の仕方をようやくマスターして「JCE Provider Checker (for Android)」なるツールを公開しました。

Androidの暗号機能は 前回のブログで説明した通りJava JCEを使っているわけですが、 使用可能なJCEプロバイダとサポートする(暗号)アルゴリズムの一覧を 表示したり、自分のメールアドレスに送ったりするJCE Provider Checkerという無料ツールを 公開しました。
bana_google_play
screen3

アルゴリズム名がわかれば、JCEの汎用のAPIを使って ハッシュ、デジタル署名、共通鍵暗号なんかが使えるわけです。 例えば、ツールで見ればSHA-512ハッシュアルゴリズムの名前は "SHA512"や別名の"SHA-512"が使えるので

MessageDigest md = MessageDigest.getInstance("SHA512");
md.init();
byte[] hashValue = md.digest(dataByteArray);
などと書けるわけです。

暗号好きな方や、開発者の方向けのツールですが、 よかったら使ってやってください。

  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2012年10月10日20:23
カテゴリ
Android
Java暗号プログラミング

Android 4.0.3 のJava JCEでどんな暗号アルゴリズムが使えるのか見てみたぞ

中華パッドを手に入れて以来、くだらないアプリを作ったりして遊んでてるんですが、Android 4.0.3 のJava JCEについて 調べたので書いてみたいと思います。

Java JCEとは

AndroidではアプリをJavaで作るわけですが、暗号やSSLや証明書なんかを使おうとする時には、 JCE(Java Cryptography Extension) という拡張を使えます。これは、暗号アルゴリズムの実装を自分やサードパーティの人が作ったものを組み込んで 同じインタフェースで使えるといったもので、Androidでもこれが使えます。
blog-fig-androidjce-20121010-f1

AndroidのJCE

「AndroidではBouncyCastleのサブセットが入ってるんだぜ!」とか 「Android 4.0からOpenSSL使ってるんだぜ!」とか、みんなしたり顔で言ったりしてます。 BouncyCastleは最も使われていると思うオープンソースのJCE対応のJava暗号ライブラリで 私も常日頃、大変お世話になっていますが、「サブセットっていうけど何が違うんだー」、 「OpenSSLとBouncyの棲み分けはどうなっとるんじゃー」という疑問について 詳しく説明してくれるページなどもなく悶々とした日々を送ってきたわけです。 JCE好きな私としては「これは自分で調べるしかないな」と思った次第です。

AndroidのCryptographic Provider

JCEではプロバイダという単位で暗号アルゴリズムのセットを提供しています。BouncyCastleもその一つです。 例えば Windows 版のOracle Java 1.6.0_20とかでは以下のような9つのプロバイダが標準で提供されています。

JCEプロバイダ名Ver.内容
SUN1.6証明書の検証、証明書ストア、証明書、DSA署名、ハッシュ、キーストア
SunRsaSign1.5RSA署名、RSA鍵
SunJSSE1.6SSL
SunJCE1.6RSA,DES,3DES,AES,BlowFish,ARCFOUR,RC2,PBE,DH,HMAC等
SunJGSS1.0GSS Api
SunSASL1.5SASL認証API
XMLDSig1.0XML署名
SunPCSC1.6スマートカード
SunMSCAPI1.6RSA,証明書ストア,RSA署名,セキュア乱数

(あれれ？楕円関係どこいった？？？)

早速、Android 4.0.3 のJCEプロバイダを見てみるとこんな感じ。

JCEプロバイダ名Ver.内容
AndroidOpenSSL1.0SSL,SHA系ハッシュ
DRLCertFactory1.0X509 CertificateFactoryのみ
BC
(BouncyCastle)		1.46 諸々の暗号アルゴリズム。実はオリジナルのBouncyCastleをいじっていて あまり使われないアルゴリズムを省き、OpenSSLの暗号アルゴリズムも使えるようにしている。
Crypto1.0Apache HarmonyのSHA1、DSAの実装のみ
HarmonyJSSE1.0Apache HarmonyのSSL、トラストアンカ、証明書対応

blog-fig-androidjce-20121010-f2
ざっくりと以下のことが言えるのかと思います。
  • Androidでは、Oracle Javaと同じく基本的な暗号、証明書の検証、証明書ストア、SSLの機能は備えている。
  • Androidは、Oracle Javaと違いXML署名、スマートカード用のプロバイダは無い。
  • AndroidのJCEによりSSLやルート証明書ストアや(ほんの)一部の暗号が透過的に利用できるようになっている。
OpenSSLの豊富な暗号アルゴリズムを活用できたり、OpenSSLのある意味厳格な証明書検証の機能を使えるのかと思ってましたが、そんな事はなくてルート証明書ストア、SSL、AES暗号のために部分的に利用できるようになっているに過ぎないってことなんですね。

AndroidのJCEからのOpenSSLの利用

OpenSSLで実装されたアルゴリズムをJCEから利用するためには2つの方法がありそうです。

  • AndroidOpenSSLプロバイダを用いてSSLやSHA系の実装を利用する。
  • Android用に変更されたBouncyCastleプロバイダからAES暗号を利用する。
BouncyCastleプロバイダから指定できるOpenSSL実装のアルゴリズムにはたった3つの 128ビット、192ビット、256ビットのAES暗号しかなくてアルゴリズム名は以下のようになっています。
  • PBEWITHMD5AND128BITAES-CBC-OPENSSL
  • PBEWITHMD5AND192BITAES-CBC-OPENSSL
  • PBEWITHMD5AND256BITAES-CBC-OPENSSL
末尾に"-OPENSSL"がついているのが特徴かと思います。

前回のブログでは、Androidの標準のルート証明書ストアはAndroidCAStoreとして利用することができ、 OpenSSLのルート証明書ストアを拡張したような証明書ストアになっていますが、 AndroidOpenSSLプロバイダではなくHarmonyJSSEプロバイダに入っています。 SSLに関してはAndroidOpenSSLとHarmonyJSSEの2つのプロバイダがありますが、 AndroidOpenSSLプロバイダのものを優先して使うようになっているようです。

Androidのスリム化しOpenSSL拡張されたBouncyCastle JCEプロバイダ

AndroidにバンドルされているBouncyCastleプロバイダは、 機能が制限されているという話を聞くんですが、アルゴリズムの一覧を眺めて Androidにバンドルされているものと、オリジナルのとでどのように違うのか まとめてみました。 Android 4.0.3にバンドルされているものは、 最新の1つ前のバージョンのBouncyCastle 1.46(2011年2月23日リリース)をベースにしているのでこれと比較してみたいと思います。

アルゴリズムタイプ、内容Android 4.0.3 BouncyCastleオリジナルBouncy Castle 1.46
プロパティ全数378個911個
暗号プリミティブ
Cipher数28個102個
Cipherの違い AES,ARC4,BLOWFISH,DES,3DES,AES,RC2,RC4,RSAがある。 アルゴリズム名*-OPENSSLによりOpenSSL実装のAES暗号が使える。 左に加えCamellia,SEED,GOST,CAST5,CAST5,ECIES,ELGAMAL,Grain,HC,IES, Noekeon,RC2,RC5,RC6,RSA,RSAOAEP,SALSA,SEED,Skipjack,Serpent,TEA,Twofish,VMPC,XTEA, などがある。 OpenSSL実装は使えない。
MessageDigest数7個15個
MessageDigestの違い MD5,SHA1,SHA256,SHA384,SHA512がある。 左に加えGOST,MD2,MD4,RIPEMD,SHA224,Tiger,WHIRLPOOLがある。
Signature数12個46個
Signatureの違い {MD5,SHA1,SHA256,SHA384,SHA512}with{RSA,DSA,ECDSA}がある。 左に加えて公開鍵系ではRSAPSS、ECDSA-CVC、ECNR、ECGOST、GOST、 ハッシュアルゴリズムとしてはMD2、MD4、MD5、RIPEMDがある。
Mac数7個35個
Macの違い {MD5,SHA1,SHA256,SHA384,SHA512}HMAC,PBEWITHHMACSHA1がある。 左に加えて{DES,AES}CMAC、{DES,GOST,RC2,RC5,Skipjack,VMPC}MAC、 {MD2,MD4,MD5,RIPEMD}HMACがある。
KeyAgreement数2個6個
KeyAgreementの違い DH,ECDH 左に加えてECDHC,ECMQVがある。
PKI関連
CertPathBuilder数1個3個
CertPathBuilder違い 通常のPKIX,RFC3280のパス構築 左に加えて属性証明書のパス構築ができる
CertPathValidator数1個3個
CertPathValidator違い 通常のPKIX,RFC3280のパス検証 左に加えて属性証明書のパス検証ができる
CertStore数1個3個
CertStoreの違い Collectionのみ 左に加えてLDAP,Multiがある
CertificateFactory数1個1個
CertificateFactoryの違い X.509のみ 左に同じ
KeyStore数3個9個
KeyStoreの違い BKS,BouncyCastle,PKCS12 左に加え BCPKCS12,PKCS12-{3DES,DEF,DEF-3DES-3DES,DEF-3DES-40RC2}
X509Store数なし8個
X509Storeの違い なし {CERTIFICATE,CRL}{COLLECTION,LDAP}、証明書ペア、属性証明書
X509StreamParser数なし4個
X509StreamParserの違い なし X.509証明書、証明書ペア、CRL、属性証明書
鍵、パラメータ等
AlgorithmParameters数8個34個
AlgorithmParametersの違い AES,BLOWFISH,DES,DH,DSA,RSAOAEP,PKCS12PBE 左に加え Camellia,CAST5,ELGAMAL,GOST,IES,NOEKEON,PSS,RC{2,5,6},SEED,SKIPJACK,Serpent,TEA,Twofish,XTEA
AlgorithmParameterGenerator数2個15個
AlgorithmParameterGeneratorの違い AES,BLOWFISH,DES,DH,DSA,RSAOAEP,PKCS12PBE 左に加え Camellia,CAST5,ELGAMAL,GOST,IES,NOEKEON,PSS,RC{2,5,6},SEED,SKIPJACK,Serpent,TEA,Twofish,XTEA
KeyFactory数4個13個
KeyFactoryの違い DH,DSA,EC,RSA 左に加え ECDH,ECDHC,ECDSA,ECGOST,ECMQV,ELGAMAL,GOST,X.509 がある。
KeyGenerator数10個63個
KeyGeneratorの違い AES,ARC4,BLOWFISH,DES,HMAC{MD5,SHA1,SHA256,SHA384,SHA512} 左に加え Camellia,CAST5,CAST6,GOST,Grain,HC,HMAC{MD2,MD4,SHA224,Tiger,RIPEMD}, Noekon,RC2,RC5,RC6,SALSA,SEED,Skipjack,TEA,Twofish,VMPC,XTEAがある。
KeyPairGenerator数10個63個
KeyPairGeneratorの違い DH,DSA,EC,RSA 左に加え ECDH,ECDHC,ECDSA,ECGOST,ECIES,ECMQV,ELGAMAL,GOST がある。
別名
alias数261個502個
あまり使われていないものを除いてメジャーなものを残して、OpenSSLのAES暗号を 使えるようにしたという感じでしょうか。

あと、パッケージ名についてBouncyCastleオリジナルはパッケージの 名前空間が "org.bouncycastle" になっていますが、 Androidにバンドルされているものは "com.android.org.bouncycastle" になっているので注意が必要です。 オンラインのリファレンスマニュアルにも一切の記述は無かったと思います。

AndroidにバンドルされたBouncyCastleで物足りない時には

AndroidにバンドルされたBouncyCastleは古いとか言われていますが、最新は1.47なので バンドルされた1.46は一年前ぐらいのものだし、それほど古いというわけでもないです。 ただ、BouncyCastleのフルスペックの機能が利用したいみたいな時には BouncyCastleを拡張して入れ替えることができないので、 SpongyCastleというのを 使えばよいそうです。随分昔にBouncyCastleベースで作ったプログラムが結構あるので 時間があるとき、Spongyへの移植を試してみたいと思います。

今回、AndroidのJCEプロバイダを調査するのに自作したツールは そのうち公開できると良いと思ってますが、 Google Playにアカウント登録しないといけないし、まだまだ公開まで先は長そうです。

ちょっと記事が長かったですかね。今日はこの辺で。

  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2011年09月27日23:01
カテゴリ
Java暗号プログラミング
SSLTLS

IBM Java SDK 7.0 のリリースとJCE

IBMのJava SDK 7.0(IBM SDK, Java Technology Edition, Version 7.0)が2011年9月19日に リリースされました。

私が食いつくのは暗号ライブラリ(Java Cryptography Extension(JCE))の部分しかありません。 先日Oracle(Sun) Java J2SE 7.0がリリースされたばかりですが、 IBMの方はどうちがうのか見ていきましょう。

早速IBM Java 6.0と比較

まずはIBM Java 6.0と比較してどうなのか調べていきましょう。 下に示す両者の間でどう違うのか見ていきます。

JavaIBM Java 6.0 WinIBM Java 7.0 Linux
Buildpwi3260sr1-20080416_01(SR1)pxi3270-20110827_01
ArchWindows XP x86-32Linux x86-32
IBM Java 7.0 に同梱されたJCEプロバイダの一覧は以下の通りです。 変更の概要についても簡単に書いておきました。
ProviderIBM Java 6.0 WinIBM Java 7.0 Linux
IBMJSSE21.61.7
TLSv1.1/v1.2サポートを追加
IBMJCE1.21.7
楕円(EC,ECDH)追加
SHA1/256/384/512withECDSAを追加
HmacSHA256/512を追加
IBMJGSSProvider1.67.0
IBMCertPath1.11.1
IBMSASL1.51.7
NTLM認証を追加
IBMXMLCRYPTO1.01.0
変更無
IBMXMLEnc1.01.0
変更無
IBMSPNEGO1.01.0
変更無
SUN1.7
新規追加
ポリシ対応のみでほぼ空

SSL/TLS CipherSuitesについて

次に、IBMJSSE2プロバイダがサポートするCipherSuitesを見てみようと思います。 簡単なTLSクライアントを実装して接続して試してみました。 以下のようなところが特徴的かと思います。

  • 28のCipherSuitesをサポートとSun Javaに比べ少なめ
  • 楕円系(ECDSA,ECDHをサポート)
  • MD5は1つのみで残り27はSHA1
  • NSA Suite-Bはサポートしない(GCM,SHA2がない)
  • 安全な再ネゴシエーション(RFC 5746に対応している
  • AESが基本でRC4、3DESがちょっと
  • Sun JavaでサポートするSHA2系のCipherSuitesが無い
サポートしているCipherSuitesは以下の通りです。
値(16進)曲線名
0004TLS_RSA_WITH_RC4_128_WITH_MD5
0005TLS_RSA_WITH_RC4_128_CBC_SHA
000aTLS_RSAWITH_3DES_EDE_CBC_SHA
0013TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
0016TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002fTLS_RSA_WITH_AES_128_CBC_SHA
0032TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0033TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0035TLS_RSA_WITH_AES_256_CBC_SHA
0038TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0039TLS_DHE_RSA_WITH_AES_256_CBC_SHA
00ffTLS_EMPTY_RENEGOTIATION_INFO_SCSV
c002TLS_ECDH_ECDSA_WITH_RC4_128_WITH_CBC_SHA
c003TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
c004TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
c005TLS_ECDH_ECDSA_WITH_AES_256_WITH_CBC_SHA
c007TLS_ECDHE_ECDSA_WITH_RC4_128_CBC_SHA
c008TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
c009TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
c00aTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
c00cTLS_ECDH_RSA_WITH_RC4_128_WITH_CBC_SHA
c00dTLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
c00eTLS_ECDH_RSA_WITH_AES_128_CBC_SHA
c00fTLS_ECDH_RSA_WITH_AES_256_CBC_SHA
c011TLS_ECDHE_RSA_WITH_RC4_128_CBC_SHA
c012TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
c013TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
c014TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

SSL/TLS 拡張について

同様にSSL/TLSネゴシエーションの際のSSL/TLS拡張について 見てみました。特徴的なところは次の2点です。

  • SNI(Server Name Indication)在り
  • 楕円曲線拡張 (25曲線)
サポートしている楕円曲線の数が多いですが、これはOracle(Sun) Java J2SE 7.0と 同じ数ですね。たぶん値も同じでしょう。下に一覧表を示します。
値(16進)曲線名
0001sect163k1
0002sect163r1
0003sect163r2
0004sect193r1
0005sect193r2
0006sect233k1
0007sect233r1
0008sect239k1
0009sect283k1
000bsect409k1
000csect409r1
000dsect571k1
000esect571r1
000fsecp160k1
0010secp160r1
0011secp160r2
0012secp192k1
0013secp192r1
0014secp224k1
0015secp224r1
0016secp256k1
0017secp256r1
0018secp384r1
0019secp521r1

今日はこの辺で

  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2011年08月01日00:30
カテゴリ
Java暗号プログラミング
Java

祝 Java SE 7 リリース記念(第2弾)「証明書検証の弱いアルゴリズムの制限機能」

Java SE 7のSecurity Enhancementsには

CertPath Algorithm Disabling
Weak cryptographic algorithms can now be disabled. For example, the MD2 digest algorithm is no longer considered secure. The Java SE 7 release provides a mechanism for denying the use of specific algorithms in certification path processing and TLS handshaking. See Appendix D: Disabling Cryptographic Algorithms in Java PKI Programmer's Guide and Disabled Cryptographic Algorithms in Java Secure Socket Extension (JSSE) Reference Guide for more information.
と書いてあります。なるなる。証明書の検証において弱い暗号アルゴリズムを使わないように設定することができ、これはSSL/TLSの場合でも同様に設定できるようです。今日はこのアルゴリズム無効化について説明したいと思います。

プロパティファイル java.security の違い

Java SE 6 と7では若干$JRE_HOME/lib/security/java.securityのファイルの内容が違うんですが、 大きく追加されているのは3点あります。

  • Policy for failed Kerberos KDC lookups - Kerberosの設定
  • Algorithm restrictions for certification path (CertPath) processing - (証明書の)認証パス検証処理のアルゴリズム制限
  • Algorithm restrictions for Secure Socket Layer/Transport Layer Security (SSL/TLS) processing - SSL/TLS処理のアルゴリズム制限
一般の証明書検証とSSL/TLSでの証明書検証とで分けてアルゴリズムに制限をかけることができるようです。 ちなみに一般の証明書検証ではデフォルトは
jdk.certpath.disabledAlgorithms=MD2
になっており、MD2アルゴリズムは無効になるよう設定されています。SSL/TLSでは
jdk.tls.disabledAlgorithms
のプロパティで設定するようになっていますが、SSL/TLSにおいては無効設定は無いようです。

アルゴリズムの無効化の指定方法

指定するのは署名アルゴリズムではなく、ハッシュアルゴリズムと公開鍵暗号のアルゴリズムで、 公開鍵暗号のアルゴリズムについては、鍵長を指定できます。以下に幾つか設定の例を示します。
# MD2を無効化(デフォルト)
jdk.certpath.disabledAlgorithms=MD2
# MD2, SHA1, DSA, ECDSAを無効化
jdk.certpath.disabledAlgorithms=MD2, SHA1, DSA, ECDSA
# MD2, SHA1 を無効とし、鍵長2048bit未満のRSAを無効
jdk.certpath.disabledAlgorithms=MD2, SHA1, RSA keySize < 2048
RIPEMD-160等のSun(Oracle)提供の暗号アルゴリズムにないものを指定できるのかは 気になるところです。時間が取れたら見てみます。

プログラムの中でアルゴリズム制限を指定する

上記のようにプロパティファイルで指定することもできますが、 プログラムの中でも動的に指定することも可能です。

import java.security.Security;
・・・
Security.setProperty("jdk.certpath.disabledAlgorithms", "MD2, MD5, DSA");

で、実際に使ってみた

試しにRSAの鍵長を可変にして、どうなるか試してみました。

# jdk.certpath.disabledAlgorithms=RSA keySize < 1024 -- RSA1024bit未満を禁止
→検証成功
# jdk.certpath.disabledAlgorithms=RSA keySize < 2048 -- RSA2048bit未満を禁止
→unable to find valid certification path to requested target
う〜ん、確かにプロパティの変更によって検証結果は変わりますが、 例外のメッセージは全くアルゴリズム理由でそうなったのか わからないようになっちゃってますね。

仕方ないのでデバックメッセージを表示するようにして (java -Djava.security.debug=all) メッセージを見てみるとアルゴリズムを禁止した場合と鍵長を制限した 場合とでメッセージが異なるみたいです。

# jdk.certpath.disabledAlgorithms=RSA -- RSAを禁止してみた場合
algorithm check failed: SHA1withRSA disabled
# jdk.certpath.disabledAlgorithms=RSA keySize < 2048 -- RSA2048bit未満を禁止
algorihtm constraints check failed

暗号アルゴリズムの危殆化情報の管理と自動処理

暗号アルゴリズムは時代の変遷とともに脆弱になり、推奨されない暗号の鍵長もまた 変わっていきます。特に過去の電子署名ファイルや暗号化されたファイルで 使われている暗号アルゴリズムが当時大丈夫だったのかは気になるところです。 「 RFC 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)」というデータフォーマットがありますが、これは、 は、 どの暗号アルゴリズムや鍵長が何時の時代に、どのくらいの期間までは安全とされていたかを規定することができるデータフォーマットです。

現在、DES、MD5、SHA1、鍵長の短いRSAなど暗号アルゴリズムの危殆化が話題になっていますが、どのアルゴリズムが何年から何年頃までは使い物になったのかをNIST、CRYPTRECなど暗号アルゴリズムの公的な評価機関がDSSCのような電子データの形式として公開、発行して頂けると、このデータを検証ポリシーとして使用し、過去のあるデータが「当時安全とされていた暗号アルゴリズム(や鍵長)」を使っていたかを自動的に判定できるようになります。

DSSCの内容により自動的にjdk.certpath.disabledAlgorithmsに反映させて検証するなんてこともできますね。

おわりに

今日はJava SE 7で新たに提供されることになった証明書検証における弱い暗号アルゴリズムの制限機能について紹介しました。 これまでに、暗号スイートのレベルで制限することはできましたが、ハッシュや公開鍵暗号アルゴリズム、鍵長のレベルでミドルウェアで制限が加えられる汎用の製品はJava SE 7が初めてなのではないかと思います。 SSL/TLSにも使えるので、そろそろ "jdk.tls.disabledAlgorithms=MD2" などとしてもいい頃ですよね。

やべやべ、会社は夏休みなんだけど明日から一週間休日出勤だ。風呂入って寝よう。ではでは。

関連記事>

  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2011年07月29日03:38
カテゴリ
Java
Java暗号プログラミング

祝 Java SE 7 リリース記念「JCEはどうなってんの？」

大変ご無沙汰しております。もはやセキュリティ技術者とはいえない状態でわけのわからない仕事に忙殺されております。さて、今日は Java の話題です。Java SE 6のリリースが2006年12月でしたから、かれこれ5年、ようやく2011年7月28日 Java SE 7 がリリースされました。今日は「祝 Java SE 7 リリース記念」ということで暗号、セキュリティ、SSL/TLSの部分を中心に変更点を見ていこうと思います。

早速ダウンロード

7月28日になって何度もダウンロードページを訪れていたんですが、日本時間で夜の10時か11時頃にようやくダウンロードできるようになっていたみたいです。バージョンを見るとこんな感じ、、、 

% java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)
一昨日、Java SE 7 Preview Release b147 というのを落としたんですが、内容的には同じもののようです。

サポートするJCEプロバイダの差分をみてみましょう

Java SE 7 で変更点のひとつの目玉は楕円暗号のサポートなんだそうです。 Java SE 6 と Java SE 7(b147) でJCE(Java Cryptographic Extension)プロバイダの提供物の違いをdiffを取ってつらつら眺めてみました。 全体的にsun実装の内部パッケージ名がcom.sun.net.ssl.internalからsun.securityに変更になっているようです。

Java SE 6Java SE 7(b147)
SUN 1.6SUN 1.7
CertStore.LDAPのパッケージ名が変更になっただけ
SunRsaSign 1.6SunRsaSign 1.7
バージョン変更のみ
なしSunEC 1.7
楕円暗号のプロバイダが新規提供
SunJSSE 1.6SunJSSE 1.7
TLSv1.1、TLSv1.2の新規提供。内部パッケージ名の変更
SunJCE 1.6SunJCE 1.7
KeyGeneratorでSunTls12Prfの新規提供
SunJGSS 1.0SunJGSS 1.7
バージョン変更のみ
SunSASL 1.5SunSASL 1.7
SASLプロバイダ。NTLM認証の新規提供
XMLDSig 1.6XMLDSig 1.7
XML署名。W3C Canonical XML 1.1の新規サポート
SunPCSC 1.6SunPCSC 1.7
バージョン変更のみ
SunMSCAPI 1.6SunMSCAPI 1.7
Windows版のみ提供のMS CAPIを使ったプロバイダ。 SignatureでNONEwithRSA、SHA256withRSA、SHA384withRSA、SHA512withRSAの 新規サポート
XML正規化1.1(Canonical XML 1.1)をサポートしたのは個人的にはちょっと嬉しいかもしんない。SunSASLのNTLM認証もいろいろ遊べそうですね。SunSASLについてはここにサポートアルゴリズムが書いてあるんですが、そこにはNTLMについて触れてません。しかしながらSunSASLプロバイダのinfoを見てみるとこんな感じになってます。
Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM)
どっちが正しいんでしょうね？時間のあるときみてみようと思います。

楕円暗号(Elliptic Curve Cryptography)のサポート

Java SE 7になってようやく楕円暗号のためのJCEプロバイダであるSunECが新たに提供されるようになりました。ECDH、ECDSAをサポートしておりSSL/TLSや署名なんかにちゃんと使えます。 署名アルゴリズムについては以下をサポートしています。

SunECでサポートする署名アルゴリズム
NONEwithECDSA
SHA1withECDSA
SHA256withECDSA
SHA384withECDSA
SHA512withECDSA
サポートしている楕円曲線の名前は以下の通りです。かなりの数サポートしていますね。カスタム定義した曲線の利用が可能なのかは時間があるとき調べてみたいと思います。
曲線名オブジェクト識別子
secp112r11.3.132.0.6
secp112r21.3.132.0.7
secp128r11.3.132.0.28
secp128r21.3.132.0.29
secp160k11.3.132.0.9
secp160r11.3.132.0.8
secp160r21.3.132.0.30
secp192k11.3.132.0.31
secp192r1,NIST P-192,X9.62 prime192v11.2.840.10045.3.1.1
secp224k11.3.132.0.32
secp224r1,NIST P-2241.3.132.0.33
secp256k11.3.132.0.10
secp256r1,NIST P-256,X9.62 prime256v11.2.840.10045.3.1.7
secp384r1,NIST P-3841.3.132.0.34
secp521r1,NIST P-5211.3.132.0.35
X9.62 prime192v21.2.840.10045.3.1.2
X9.62 prime192v31.2.840.10045.3.1.3
X9.62 prime239v11.2.840.10045.3.1.4
X9.62 prime239v21.2.840.10045.3.1.5
X9.62 prime239v31.2.840.10045.3.1.6
sect113r11.3.132.0.4
sect113r21.3.132.0.5
sect131r11.3.132.0.22
sect131r21.3.132.0.23
sect163k1,NIST K-1631.3.132.0.1
sect163r11.3.132.0.2
sect163r2,NIST B-1631.3.132.0.15
sect193r11.3.132.0.24
sect193r21.3.132.0.25
sect233k1,NIST K-2331.3.132.0.26
sect233r1,NIST B-2331.3.132.0.27
sect239k11.3.132.0.3
sect283k1,NIST K-2831.3.132.0.16
sect283r1,NIST B-2831.3.132.0.17
sect409k1,NIST K-4091.3.132.0.36
sect409r1,NIST B-4091.3.132.0.37
sect571k1,NIST K-5711.3.132.0.38
sect571r1,NIST B-5711.3.132.0.39
X9.62c2tnb191v11.2.840.10045.3.0.5
X9.62 c2tnb191v21.2.840.10045.3.0.6
X9.62 c2tnb191v31.2.840.10045.3.0.7
X9.62 c2tnb239v11.2.840.10045.3.0.11
X9.62 c2tnb239v21.2.840.10045.3.0.12
X9.62 c2tnb239v31.2.840.10045.3.0.13
X9.62 c2tnb359v11.2.840.10045.3.0.18
X9.62 c2tnb431r11.2.840.10045.3.0.20
Java SE 7のSunJSSEプロバイダでサポートしているCipherSuitesのリストはここにありますが、その中で楕円系のCipherSuitesはこんな感じ、、、かなりの数ですね。メンテしている環境別のCipherSuitesサポート状況のテーブルは、近いうちJava SE 7を含め歴代Javaのサポート状況を追記したいと思っています。
Java SE 7 SunJSSEプロバイダの提供する楕円系CipherSuites
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
次に簡単なHTTPSクライアントを書いてTLSのelliptic_curves extensionに何が設定されているか、パケットキャプチャして調べてみました所、下のような感じになっていました。げげっ25個もサポートされています。多すぎです。IEやFireFoxでは確か3つぐらいだったはず。
TLS elliptic_curves拡張にある曲線名
secp256r1
sect163k1
sect163r2
secp192r1
secp224r1
sect233k1
sect233r1
sect283k1
secp384r1
sect409k1
sect409r1
secp521r1
sect571k1
sect571r1
secp160k1
secp160r1
secp160r2
sect163r1
secp192k1
sect193r1
sect193r2
secp224k1
sect239k1
secp256k1

その他気になった変更点

セキュリティ関係の変更点はここにまとめらているんですが、その中で気になったところをかいつまんで紹介したいと思います。

JSSE(SSL/TLS), TLS 1.1, TLS 1.2
TLSv1.1, TLSv1.2 がサポートされるようになりました。
JSSE(SSL/TLS) Connection-sensitive trust management
SSL/TLSで使われるアルゴリズムを署名アルゴリズム等弱い物を使わない等指定できるようです。 証明書の中のアルゴリズムまで制限できるのか気になるところ。
JSSE(SSL/TLS) Endpoint verification
HostnameVerifier()を定義すれば、 SSL/TLSのホストの一致確認方法を実装側で 制御できるようです。逆にホスト名をチェックしないこともできたり、証明書のへんなところに入っている ホスト名であっても認証できるようにしたりできますね。
JSSE(SSL/TLS) TLS renegotiation
2009年3月に発表されたSSL rebindingやSSL renegotiationといわれるSSL/TLSの仕様の欠陥をついた攻撃を防ぐためのTLS renegotiation拡張をサポートしているそうだ。
JSSE(SSL/TLS) Server Name Indication (SNI) for JSSE client
SNI拡張がサポートされた。確かにパケットキャプチャするとClientHelloに入っている。一台のウェブサーバーで複数のバーチャルホストに対してちゃんとHTTPS接続することができるようになります。これはテスト目的で前から非常に欲しかった機能。

以上、Java SE 7 リリース記念ということで、JCE関連の機能の変更点をみてみました。やべやべ、もう寝ないとorz

参考リンク

関連記事>

変更履歴

  • 2011-07-31 参考リンクにおいてリンク切れを修正、JCA、PKIを追加
  • kjurk_urushima
  • コメント( 2 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
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
#暗号ライブラリ
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2009年05月25日23:52
カテゴリ
Java暗号プログラミング
Java

Sun JDK 7 Early Access (その1)

Sun JDK 1.5が2009年10月30日にサポート終了(EOL)となっちゃうために対応に追われている会社さんもあるかもしれませんが、そんな折、次のバージョンであるSun JDK 7のプレビュー版(Early Access)が公開されています。

各バージョンのサポート終了(EOL)のポリシーはここに書かれていますが、バージョンを追う毎に段々短命になってきてますね。リリースの頻度が短い分、メジャーリリースでの新しい機能追加も目新しさに欠けるような気がしています。

追加シンタックスの解説は他のサイトに譲るとして、Java SE 7 の暗号・セキュリティプログラミングの違いを見ていこうかなぁ、、と思っています。

早速、JDK 7 Early Access をダウンロードしてみました。

JDK 7 ea build b59 2009年5月14日版 (ea: early access)
% java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b59)
Java HotSpot(TM) Client VM (build 16.0-b03, mixed mode, sharing)


でした。

さて同梱されるJCEプロバイダの一覧とバージョンの違いをまとめるとこんな感じ、、、












Sun JDK 1.6Sun JDK 7
build b59		備考
SUN 1.6SUN 1.6変更無し？
SunRsaSign 1.5SunRsaSign 1.7バージョンが変わっただけ？
SunJSSE 1.6SunJSSE 1.6com.sun.net.ssl.internal.ssl→sun.security.ssl
SunJCE 1.6SunJCE 1.7バージョンが変わっただけ？
SunJGSS 1.0SunJGSS 1.0変更無し？
SunSASL 1.5SunSASL 1.5変更無し？
XMLDSig 1.0XMLDSig 1.0C14N 1.1が追加された
SunPCSC 1.6SunPCSC 1.6変更無し？
SunMSCAPI 1.6SunMSCAPI 1.7バージョンが変わっただけ？


アルゴリズム一覧で差分をとって比較もしてみたんですが、恐ろしく変わってないです。追加されたアルゴリズムはXML正規化以外ありません。

主要と思われる違いをまとめるとこんなとこ、、、

・XMLDSig
　・正規化 Canonical XML 1.1 (C14N 1.1)のサポート
・SunJSSE
　・実装の名前空間がsun.security.sslに変更された。

XMLDSigは新たにC14N 1.1のサポートが追加されたのでちゃんとJCEプロバイダのバージョンを1.0から上げてもらいたいもんです。

以上、JCEの上辺については変わってなくてガッカリってことで、、、、

次回以降、

・C14N 1.1
・パス検証に違いはあるのか？

など見ていこうと思っています(が、、違いが無いと書きにくい（−−；
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
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
#暗号ライブラリ
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
記事一覧(手作り)
カテゴリ | 酒 | 食 | 出張・旅行 | XAdES | SSL証明書 | OpenSSL | タイムスタンプ | コード署名 |
はてなブックマーク
された記事
最新記事
Mozilla FirefoxのCRLiteで遊ぶ (moz_crlite_queryの話)
(小ネタ)サンフランシスコに行った時のSIM(Lycammobile)の話(2018年7月版)
Google Open Source Peer Bonus Award受賞しちゃいました
jsrsasignの寄付金を募ることにしてみました(やりがいって何だっけ？)
最近の証明書の話題(3): デジタル証明書形式の電子委任状のプロファイルに関する考察
最近の証明書の話題(2): CloudFlare DNS 1.1.1.1サイトのIPv6証明書
最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行
(小ネタ) Chrome 60で証明書を表示させるフラグ設定
GmailアカウントでS/MIME 署名/暗号メールを使う(その1 iOS標準メーラー編)
Amazon AWSの認証局が少し怪しい件
追悼 Adobe CDS
HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える
X.509証明書の識別名などで使われるMulti-valued RDNとjsrsasignのサポートについて
バルセロナでプリペイドSIMの購入(2016年11月版)
ヨーロッパでPokemon Goに最適？なSIMフリースマホ
SSL Pulseの統計情報でみるSSL/TLSの引越しについて
SSL Pulseの統計情報で見るSSL/TLS (2015年12月版)
(小ネタ)Let's Encryptベータ証明書発行記念！11/5までの本番環境の証明書発行推移
SSL Pulseの統計情報で見るSSL/TLS (2015年10月版)
Deep Inside Certificate Transparency (その1)
(小ネタ)ソニーSENのChromeの警告
(小ネタ)スマホでS/MIME署名・暗号メール使うならdocomoはおやめなさい
Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行？？？
SSL Pulseの統計情報で見るSSL/TLS (2015年8月版)
SSL Pulseの統計情報で見るSSL/TLS (2015年6月版)
CRYPTREC/IPA「SSL/TLS暗号設定ガイドライン」の公開と非公式設定ファイル生成ツールの公開
SSL Pulseの統計情報で見るSSL/TLS (2015年5月版)
Windows信頼するルート認証機関コンプへの道(第一回)
「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項」の公開
Windowsルート証明書の更新プログラム(2014.09)と戯言など
I♡S/MIME(Mac、iPhone、Outlook 2013、Office 365のS/MIME署名暗号メールの設定与太話)
ISO/IEC 18014-4 Time-stamping services - Part 4: Traceability of time sourcesの制定について
(小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件
世の中のDSAやECDSA公開鍵のサーバー証明書の利用状況
ChromeのSHA1証明書対応計画の一部延期(2015年3月12日発表)
SSL Pulseの統計情報で見るSSL/TLS (2015年3月版)
go.jpドメインのHTTPSサイトの状況について私もみてみました(2015年3月4日時点)
(小ネタ)4月10日(金)のJNSA PKI Day 2015でSSL/TLSの話をさせてもらいます
SSL Pulseの統計情報で見るSSL/TLS (2015年1月版)
W3C Web Cryptography APIとの果てしなき戦い(第3回 動くサンプル1)
W3C Web Cryptography APIとの果てしなき戦い(第2回 RSA署名生成と検証)
W3C Web Cryptography APIとの果てしなき戦い(第1回)
Chrome 39安定版のリリースと、有効期限が2017年1月以降のSHA1証明書の警告表示
Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit
Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS
POODLE対策としてのApache TomcatのSSL/TLSプロトコルバージョンの設定方法の調査
(続き1)POODLE攻撃について本当にTLSv1.0なら安全なのか？(OpenSSLは安全)
POODLE攻撃について本当にTLSv1.0なら安全なのか？
様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3)
全くスマートじゃないスマートウォッチARES EC309を買ったぜっ！
自前管理サイトリンク
自堕落な技術者のヰキ(公開版)
Favotter (@kjur)
自堕落な技術者のためのヰキ避難所(限定)
自堕落な技術者のヰキ(公開版跡地)
FriendFeed (@urushima)
Twitter (@kjur)
Twilog (@kjur)
Ourdoings (@kjur)
Flickr (@kenji-urushima)
Flickr (@kenji-urushima2)
Googleプロフィール(kenji.urushima)
セキュリティ関連リンク
ウィルス・マルウェア関連
リンク集一覧
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor

Cities I've visited.
記事検索
タグクラウド
QRコード
QRコード
  • ライブドアブログ