自堕落な技術者の日記

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

NIST

今更ながらNIST PKITS

NIST PKITS(PKI Test Suite) Path Validation Testing Programとは米国標準技術局(NIST:National Institute of Standards and Technology)で2004年に開発された、RFC 3280で規定された証明書のパス検証を正しく実装されているか確認できるテストケースのセットです。

ドキュメント、テスト用の証明書・CRL・リポジトリ(LDAPサーバー)・CMS署名データが公開されているので、誰でもダウンロードして試すことができます。量的には、






テストケース数だいたい250
テスト可能な証明書チェーン数224
証明書の数405
CRLの数175


というなかなか、ものすごいもので、こんなの手で一つ一つやっていたら日が暮れちゃうぐらいやり甲斐がのあるテストです。

Java系の実装でApache Ant+JUnitベースでテストしたい



Apache Antは言わずと知れたmakeコマンドの代わりとなるコンパイルやビルドなどしてくれる有難いツールです。JUnitはJavaの単体テストのフレームワークですね。

Challenge PKI Test Suiteでは、テストをゴッソリ動かすようなPerlスクリプトを作って動かしていましたが、既存のNIST PKITSで使おうとすると証明書やCRLなどテストデータをいちいちデータベースに投入する必要があってかなり面倒でした。

パス検証クライアントがJavaベースの時にAnt+JUnitの組み合わせでもう少しシンプルに、PKITSのディレクトリ構成を生かしながらテストできないかな、、、と考えていました。前のChallenge PKIが古いNISTのテストケースを参照にしていたので、新しい(といっても2004年ですが)テストケース、ファイル構成に対応させたいと思っていました。

SunのCertPathValidatorでちょっと気になっていたこともあったりしたので、昨日ちょっと時間があったので作ってみました。

実現方法



基本は、「PKITSをAnt+JUnitでパパッとやってレポート作成もそちらにお任せしたい」ってことです。テストの実施は、以下のような感じのテストケースの設定ファイルをJavaのpropertiesファイルで作ってテストさせます。設定ファイルには検証対象の証明書のチェーンと、CRLのファイル名が設定されています。

# t040101_ValidSignaturesTest1.cfg
path.crt.1=TrustAnchorRootCertificate.crt
path.crt.2=GoodCACert.crt
path.crt.3=ValidCertificatePathTest1EE.crt
path.crl.1=TrustAnchorRootCRL.crl
path.crl.2=GoodCACRL.crl


検証パラメータも同じくデフォルトをプロパティファイルで与えます。テストケースファイルにも例外を書けるようにしておきます。

input.initial-policy-set=2.5.29.32.0
input.initial-explicit-policy=0
input.initial-policy-mapping-inhibit=0
input.initial-inhibit-any-policy=0


で、このテストケース設定ファイルを250近く手で作るのはえらく面倒なのでテストケース設計書のPDFから自動で作れないかと考えました。テストケース設定ファイルの自動抽出では以下のようなことをします。

・pdf2text を用い PKITS.pdf のテストケース部分(4章)をテキストにする
・改行の乱れなどスクリプトで自動修正する
・サブサブセクション名からテストケース名を取得
・その中の記述より検証対象の証明書・CRL名を取得
・テストケース設定ファイルを生成

テストケース設定ファイル群よりパス検証をJUnitテストにより行うJavaのコードを自動生成するようなスクリプトを作りました。

JUnit単体テストのクラス

package pkits.auto;

import java.util.*;
import junit.framework.TestCase;
import pkits.util.*;

↓4.1章 "Signature Verification Test"の節のテスト
public class T0401_SignatureVerificationTest extends PKITSTestCase {
 public T0401_SignatureVerificationTest(String name) { super(name); }

 protected void setUp() {}
 protected void tearDown() {}

 ↓4.1.1節 "Valid Signatures Test1" のテストを設定ファイルを指定し実行
 public void test_t040101_ValidSignaturesTest1() throws Exception {
  doPKITSTestCase("t040101_ValidSignaturesTest1");
 }
 ↑コレをテストケース数だけ
 :以下略
}


クラスの頭の部分を"T0401_"にしたり、テストメソッドを"test_t040101_"のように節番号を含むようにしておくと、テストケース結果のレポートが節の順にきれいに表示されるので良いと思います。

テストの期待値ですが、基本的にはテストケース設定ファイルの名前"*_Valid*"、"*_Invalid*" で有効、無効を判断します。但し、4.8節の証明書ポリシのテストなどでは、テストメソッドが"test_t04080101_AllCertificatesSamePolicyTest1"のようにValid/Invalidは書かれていなくて、一つのテストの中で1〜4のポリシ処理の条件を変えてテストするので書かれていないわけです。これは、面倒ですが手で設定ファイルを分けてテストケース中に期待値を書くようにしました。

# t040801_AllCertificatesSamePolicyTest1.cfg
expectValue=INVALID
input.initial-policy-set=2.16.840.1.101.3.2.1.48.2
input.initial-explicit-policy=1


でCertPathValidatorを実際に動かす全てのテストの抽象親クラスを作って作業は大体おしまいです。

実行してみると、、、、

ここまでお膳立てできれば後は "ant test" 一発で動かすだけ。

% ant test
Buildfile: build.xml
init:
prepare:
[echo] ----------- NIST PKITS Test Runner 0.9.1 [2009] --------
prepare-src:
prepare-resource:
compile:
test:
[junit] Running pkits.auto.T0401_SignatureVerificationTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 2.139 sec
:中略
[junit] Running pkits.auto.T0404_BasicCertificateRevocationTestsTest
[junit] Tests run: 21, Failures: 1, Errors: 0, Time elapsed: 1.921 sec
[junit] Test pkits.auto.T0404_BasicCertificateRevocationTestsTest FAILED
:中略
[junitreport] Processing reports\TESTS-TestSuites.xml to null507600500
[junitreport] Transform time: 2874ms
BUILD SUCCESSFUL
Total time: 45 seconds


pkits01pub



250のテストケースで11個失敗、つまり期待値と不一致となっています。

pkits02pub



失敗したのはどれもCRL関係のやつです。Sunの実装はIndirect CRLとかDelta CRLとかサポートしていないので、当然といえば当然、、、、

pkits03pub



サポートしていないDelta CRLのテスト結果のさらなる詳細はこんなの。
Invalidのテストケースで無効になった場合には大抵CertPathValidatorExceptionなんですが、期待値通り例外が発生した場合JUnitの単体テストとしては成功で、するとどういう理由で例外発生したからテスト成功だったのかを結果表で表示させることができないんですよね。これは、ちょっと困ったところ。

仕方なく、標準出力を見たりします。

以上、こんな感じでApache AntとJUnitでNIST PKITS Path Validation Testを動かすことができ、集計結果の表示についてもほぼ満足できるものが完成しました。パチパチ(^^v

いや〜〜、最初からXMLか何かでテストケース書いてくれれば苦労も少ないんすけどね、、、、

今回はJUnitはJUnit 3.8という古いのを使ったんですが、今はJUnitは4.5になっており、それよりもTestNGの方が注目されているそうです、、、、知らなかった、、、そろそろTestNGに切り替える時が来たのかも、、、、、

JUnit 4.xはテスト結果のErrorが無くなってSuccess/Failureだけになってしまったので、これはちょっと困ったもんです。TestNGもこれは同じっぽい???あとJUnit 4.xもTestNGもJava 1.5以降のアノテーション機能を使っているので、古いJava 1.4を使い続けなければならない場合にちょっと困っています。


NISTタイムスタンプ・署名SPドラフトパブコメ期限(2008.12.19)

SP 800-102 DRAFT Recommendation for Digital Signature Timelines
NIST requests comments on SP 800-102, Recommendation for Digital Signature Timeliness. This Recommendation provides methods for obtaining assurance about the time that a message was signed. The concepts in this Recommendation were presented in the original public comment draft of FIPS 186,3, The Digital Signature Standard. Please provide comments to ebarker@nist.gov by December 19, 2008, with “Comments on SP 800-102” in the subject line.


ぐっはぁ、、、、すっかり忘れていました。

米国NISTからデジタル署名とタイムスタンプに関するガイドライン(SP)のドラフトがそれぞれ出ており、タイムスタンプの方はパブコメ募集中で期限が12月19日になってます、、、、やばいっ、、、でもちょっと時差で稼げる、、、、、

署名の方は12月12日で終わってました(;´Д`)

コメントあれば関係の皆様も是非、、、、私も今日目を通します、、、、、

リンク:
NISTのSPドラフトパブコメ募集ページ
SP 800-102 DRAFT Recommendation for Digital Signature Timeliness (NISTタイムスタンプガイドラインのドラフト(PDF)
FIPS-186-3 DRAFT Digital Signature Standard (DSS) (NIST FIPS-186-3 デジタル署名に関する標準のドラフト(PDF)



SHA-3候補のOID

NISTのSHA-3 HASHコンペのメーリングリストでJeff JohnsonさんがSHA-3候補のハッシュアルゴリズムとRSA署名アルゴリズムのオブジェクト識別子(OID)をテンポラリでもいいから割り当ててという発言がありました。

同じような事を考えてくれる人がいてよかったですが、テンポラリはいただけない。混乱するだけだから、、、、、候補になった奴は正式にNISTでOID振っちゃっていいんじゃないですかね?

大御所Paul Hoffmanさんは、「評価も終わってないのに使うつもり?」みたいな話をしていますが、コンペで一等賞になろうがなるまいが一部のアルゴリズムは使う人(国)が出てくるでしょうから、多分お金のかからないNIST内の決め事だけの話だと思うので先に割り当てといていいのではと思います。

例えばRound1候補に "1.3.14.3.2.777.1" から "1.3.14.3.2.777.51" 割り当てて
その中の一つ "1.3.14.3.2.777.7" が優勝して他を殆ど捨てることになっても大した問題じゃない気がするんですが、どうですかね、、、、、「13」は嫌だ、とか、後になってこのOIDにしたせいで不具合が多いんじゃないかという都市伝説が生まれるとかそういうのはあるのかな?

実際に署名やMACなどハッシュアプリケーションとして使ってみないとわからない問題も出てくるんじゃないかと、、、、、

SHA-3まとめサイトでリンク追加

kurushima @ 自堕落な技術者のヰキ(公開版) - Hash/次世代SHA3ハッシュアルゴリズム
Engineering comparison of SHA-3 candidates / SHA3参加アルゴリズムの比較調査
http://www.skein-hash.info/sha3-engineering
Classification of the SHA-3 Candidates / SHA3参加アルゴリズム比較の論文
http://www.uni-weimar.de/cms/fileadmin/medien/medsicherheit/Research/SHA3/Classification_of_the_SHA-3_Candidates.pdf


SHA-3コンペまとめサイトでETSI ESI副議長のErnstさんに教わったリンクを追加しときました、、、、

クロックサイクルで少ない時間で速い方が良いみたいな話になっているようですが、、、少ない時間で処理できるほど、その分衝突が見つけやすくなったってことにならないんですかね???(素人ですみません、、、)

PDFとかも最新版ではパスワードによる暗号化機能でAESを使うようになって、前よりも解くスピードが速くなっちゃったからPDF password reminderみたいなブルートフォースによるパスワード解析ソフトでも(何も手を加えていないのに)従来手法のままで解析スピードが格段にアップしちゃったらしいですよね、、、、、

NIST第1回SHA3候補会議

NIST.gov - Computer Security Division - Computer Security Resource Center
The First SHA-3 Candidate Conference will be held at K.U. Leuven, Belgium, following the 16th International Workshop on Fast Software Encryption (FSE 2009) which is scheduled for February 22-25, 2009. The purpose of the SHA-3 Conference is to allow the submitters of the first round candidates to present their algorithms, and for NIST to discuss the way forward with the competition.


来年2009年2月22〜25日、ベルギーのルーヴェンでNISTのSHA3ハッシュアルゴリズムのコンペティションの候補の会議が行われるそうな、、、、、

ルーヴェン(Leuven)ってどこ?

<追記>
ほほ〜〜っ、ブリュッセルの東、大陸側ですな、、、距離的に電車で20〜30分ってとこでしょうか、、、、、


View Larger Map


最新記事
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor
記事検索
QRコード
QRコード
  • ライブドアブログ