自堕落な技術者の日記

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

タイムスタンプ

RFC 3161の改訂のその後

PKIXの議論の結果、RFC 3161タイムスタンププロトコルの改訂について以下のような方向になりそうだとPKIX議長からETSI ESIメンバに紹介があった。

・RFC 3161の用語の定義を変えるべきではない
・ESSSigningCertificateV2については同意
・RFC 3161bis は出さない
・ESSSigningCertificateV2をオプションで使えるようにした
 別の短い関連RFCを出す

今月末の75th IETF Stockholmで決着をつける予定なのだそうだ。

OpenSSLで属性証明書

ITU X.509/RFC 3281 Attribute Certificate Toolkit for OpenSSL
ITU X.509/RFC 3281 Attribute Certificate Toolkit for OpenSSL


OpenSSLでは、標準ではX.509V2属性証明書を扱えないんですが、ちょっとググってみたところスペインのカルロスIII世大学にITU X.509/RFC 3281 Attribute Certificate Toolkit for OpenSSLというOpenSSLを使った属性証明書関連のライブラリがあるみたいで、ライセンスもOpenSSLと同じなんで、ちょっと試してみました。

とりあえず 0.2 beta for Windowsを試す



0.1ベータ版はLinuxとWindows用があるんですが、0.2ベータ版はWindows版のみです。0.2はドキュメントが未整備らしいんですが、こっちで行くことにしました。

Microsoft Visual C++ 2008 Express を入れて(MS SQLのインストールに失敗しましたが無視して(^^;)、AC Toolkitのプロジェクトを開いてみます。Visual Studio 2005用でしたが特に問題なく自動変換できたようです。

CryptoAPI対応のWindows版OpenSSL 0.9.8kを頂いたので、これを使うことにします。

プロジェクトのプロパティでインクルードとライブラリの場所をOpenSSLにあるやつに設定すれば、2つのプロジェクト"x509ac"と"x509actest"はまぁ大きな問題なくビルドできました。一点、ビルド後に生成されたライブラリをコピーしようとするんですが、そこでエラーになっており、パスは変更しなければいけません。

"x509actest"を動かしてみようとすると、エラーが出たんですが、

OPENSSL_Uplink(00639010,05): no OPENSSL_Applink


解決方法がこちらにあったので参考にさせて頂き"test.cpp"に以下を追加すれば無事動くようになりました。

#include <openssl/applink.c>
#pragma comment(lib, "libeay32.lib")
#pragma comment(lib, "ssleay32.lib")


テストプログラムを動かしてみるに、確かにV2属性証明書が発行できている模様、、、、

時刻監査証(TAC)は読める?



Thales(旧nCipher)製のタイムスタンプサーバーではV2属性証明書であるような時刻監査証というのがタイムスタンプトークンについてくるんですが、これをこのツールキットで見られないかな、、、、といろいろ試してみたんですが、未知の属性であるため落ちちゃうという、つれない状態、、、、

結構頑張ってみたり、このツールキットのサンプルとかいじってみたんですが、結局このツールキット自体をいじらないと無理そうなので、とりあえずこれで断念、、、、、

時間があるとき、また遊んでみたいと思います。

そういえば今日は、TBFフォーラムですがちょっと行かれそうにありませんでした。RSA BSAFEのことはちょっと記事を書いてみたい気もするんですが、ライセンス契約をちゃんと把握していない状態ではちょっと書きづらい、、、、(T_T)

OpenSSL 1.0.0 beta1 タイムスタンプ検証機能

前回、OpenSSL 1.0.0 beta1 ではOpenTSAプロジェクトで開発されたRFC 3161タイムスタンプに対応するOpenSSLの拡張機能が標準で組み込まれたってことを紹介しました。

この検証機能についてうまく動かなかったので紹介を先送りにしていたんですが、前回の記事でなひさんにコメント頂いた通り時刻監査証というRFC 3281 V2属性証明書をサポートしていないをのためにOpenSSLでは検証ができないようです。

今回はその辺りを入門的なところから、一挙にマニアックなところまで掘り下げて報告したいと思います。

"openssl ts -verify"コマンドによる検証方法



OpenSSL 1.0.0 から標準機能で "openssl ts -verify" コマンドを使えば、RFC 3161タイムスタンプ応答やトークンを検証することができます。

最も一般的なケースとして、タイムスタンプを付与した「対象ファイル」に対して「タイムスタンプトークン」を検証する場合にはこんな感じ、、、


% openssl ts -verify -data \
  -data {タイムスタンプ対象のファイル} \
  -in {バイナリ形式のタイムスタンプトークン} -token_in \
  -CApath {ルート、サブを含めPEM形式のCA証明書群が格納されるディレクトリ} \
  -CAfile {PEM形式の信頼するルート証明書(トラストアンカ)} \
  -untrusted {PEM形式のタイムスタンプ局(TSA)証明書}
(例)
% openssl ts -verify -data aaa.txt -in foo.tst -token_in \
-CApath ./certs -CAfile root.pem -untrusted tsa.pem


「PEM形式やCApathをどう作るの?」って方は文末の付録を見てください。

タイムスタンプ対象の指定方法は全部で3種類を使い分けられます。

・"-data タイムスタンプ対象ファイル"
  (例) % openssl ts -verify -data foo.txt ...後略...
・"-digest タイムスタンプ対象のハッシュ値(16進数)"
  (例) % openssl ts -verify -digest 7f2e143d... ...後略...
・"-queryfile バイナリ形式のタイムスタンプ要求ファイル"
  (例) % openssl ts -verify -queryfile ts.req.der ...後略...

対象ファイルから↑の二番目で使うハッシュ値を計算するには{md5|sha1|sha224|sha256|sha384|sha512}sum コマンドが使えます。(つい最近まで自前のハッシュ計算機を使っていたのでcygwinとかで標準でSHA2の*sumコマンドが提供されていたなんて知りませんでした(^^;)

タイムスタンプトークンを検証する(-in foo.tst -token_in)方が一般的だと思うんですが、タイムスタンプ応答を検証する場合にはこれの代わりに(-in foo.res)のように-token_in無しで応答ファイルを指定して検証します。

"openssl ts -verify"コマンドのサポート状況と時刻監査証



自前のTSAでちょっとテストしてみたところ"openssl ts -verify"の検証機能のサポート状況はこんな感じ、

・SHA1withRSAのTSA証明書: ○
・SHA512withRSAのTSA証明書: ○
・TSTInfo.messageImprintがSHA1: ○
・TSTInfo.messageImprintがSHA512: ○
・TSTのmessageDigest属性がSHA1: ○
・TSTのmessageDigest属性がSHA512: ○
・TSTのSignerInfoの署名アルゴリズムがSHA1withRSA: ○
・TSTのSignerInfoの署名アルゴリズムがSHA512withRSA: ○
・信頼モデルが基本モデル(Root→EE): ○
・信頼モデルが階層モデル(Root→Sub→EE): ○
・genTimeが小数点以下を含む: ○
・TSA証明書のextKeyUsage criticalのチェック: ○

どんなところにSHA2が使われようとも全く問題ありませんでした。(疑ってごめんよ OpenSSL m(_ _)m)

で、次に日本国内商用のTSAを使った場合なんですが、時刻監査証(TAC)を使っているかどうかで違ってきます。

・TACを含まない商用TSAのトークン(SHA1): ○
・TACを含む商用TSAのトークン: ×(パーズエラー)
・上記はV2属性証明書であるTACの格納場所がRFC 3852に
  準拠しないので、これを修正しCMSVersion 3→4にしたトークン: ×(パーズエラー)
・TACのみをcertificatesフィールドより
  外したトークン: ×(TACが無いことによるSigningCertificate不一致)

てな感じで、属性証明書であるTACの入れる位置が問題なのではなく、属性証明書がトークンに入っている場合に、これをサポートしていないようです。

パーズエラーのメッセージを見るとTACをX.509公開鍵証明書としてパーズしているようにも見え、任意の属性証明書がcertificatesフィールドに格納されている場合に必ずエラーになるようにも見えます。




付録1:バイナリ形式からPEMテキスト形式の証明書の変換


opensslで以下のように変換できます。
% openssl x509 -in cer.der -inform DER -out cer.pem -outform PEM


付録2:CApathの設定


OpenSSLにはWindowsのような証明書ストアみたいなものは無いので、ディレクトリにCA証明書を入れておいて、これを"-CApath"オプションで指定して使います。

この時、証明書のファイル名に注意が必要で証明書を以下のようなコマンドでコピーまたはシンボリックリンクしてください。


例えば"ca1"というディレクトリにCA証明書を格納することにする。
% mkdir ca1
% cd ca1
別の場所にあるCA証明書cert1.pemファイルここにコピーする場合
% cp ~/cert1.pem ./`openssl x509 -in ~/cert1.pem -hash -noout`.0
シンボリックリンクの場合
% ln -s ~/cert1.pem ./`openssl x509 -in ~/cert1.pem -hash -noout`.0


すると証明書が意味不明な8桁16進数のファイル名になっていると思います。これは、証明書主体者名のハッシュ値の一部なんだそうです。

これを検証の際に必要そうな全てのルート証明書、サブCA証明書などについて行ってください。

このようなハッシュ値をファイル名に含む証明書は、インストールされていれば"/usr/bin/c_rehash" Perlスクリプトでもできるそうです。(古いOpenSSLやプラットフォームによって無い場合もあるようです。)

使い方は、CApathに指定したいディレクトリに全てのCA証明書をPEM形式で置き、
% c_rehash [CApathで使いたいPEM CA証明書やCRLを置いたディレクトリ]


と実行すれば、全ての証明書、CRLについてシンボリックリンクかコピーが自動で生成されます。

Webページの存在証明サービスだそうです

存在証明サービス
「Webページの存在証明サービス」とは、あなたがWebで見た事実を証拠として残すことの出来るサービスです。


今日、こんなサービスを見つけてしまいました(^^;

実はこのサービス、本物の商用デジタルタイムスタンプを使っています。
素晴らしい、、、、デジタルタイムスタンプの応用事例としての可能性を感じさせます。

ただ、現状では、あるファイル(群)がその時刻にあったことの証明にしかなっておらず。

・閲覧したとする人が対象のウェブサイトを本当に閲覧したかどうかはわからない
・閲覧したのが誰かはわからない
・対象となるファイル(群)が本当に入力に使ったURLに存在したかはわからない

かな、、、と、

閲覧する側のためのサービスではなく、コンテンツ提供側のためのサービスに現状なっているかなと思います。

サービスのフォーム入力ページ例のDebianのOpenSSLの脆弱な鍵を使っているという警告が出てしまいます。

このサービス、任意のコンテンツに対して「タダ」で商用のトークンをゲットできるようになっているような気が、、、、ちょっとやってみると、、、、ん〜〜っ、スルッとCAdES-Tとか作れますね。

今は試験運用のため無償でサービス提供しているそうです。

<参考リンク>
KCS Corp. ニュースリリース 2009.04.06

RFC 3161の改訂ドラフト1

RFC 3161 タイムスタンププロトコルの改訂版のインターネットドラフトが2009年2月6日に出ていたようです。(見落としてました)

http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-01.txt

・SHA2対応のためESSSigningCertificateV2を使えるようにした
・用語定義を加えた

とPinkasさんがメールしていたような気がしますが確認してみます。

2009年の夏時間

ウォルマートに勤める友達の日記を見ていたら先週、アメリカ・カナダでは夏時間になったそうです。今年の夏時間はこんな感じらしい。とりあえず備忘録として、、、

■2009年の夏時間
現地時間2009.03.08 02:00〜現地時間2009.11.01 02:00 (US/Canada)
現地標準時間2009.03.29 01:00〜現地夏時間2009.10.25 02:00(欧州)

夏時間の期間って誰がどんな理由で決めてるんでしょうね。しかし、北米と欧州で期間が微妙に違うのは止めてほしい。面倒なので日本には絶対導入しないで欲しい、、、、、

南半球では8月は冬で寒かったりと北と南で夏冬違っても受け入れているので、みんな協定世界時(UTC)で生活して地域の運用に任せるみたいなのはダメですか?夏時間無しみたいな、、、、、最近、昼夜逆転しているような人や24時間戦っている人を身近で見かけたりするのでそれも良いかなと、、、、、

インターネットドラフトへのCAdES-TのRFC

RFC 5485 - Digital Signatures on Internet-Draft Documents
This document specifies the conventions for storing a digital signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) [CMS] is used to create a detached signature. The signature is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.


お世話になっているMさんの日記を見ていたらRFC 5485 Digital Signatures on Internet-DraftsというInformational RFCが大御所R.Housleyから出てきたそうです。

これは、インターネットドラフトにCMS detached署名をIETF事務局がつける方法に関するRFCだそうで、基本はCMSなんですが、RFC 3161タイムスタンプも付けられます。

署名属性には書かれていませんが必要と思われるものは適当に追加していいようでESSSigningCertificateV1/V2属性を追加しておけば、ばっちりCAdES-Tになります。

文中、新しいASN.1シンタックスの表記が使われちょります。

www.1234567890day.com

1234567890 Day
What is this all about anyway?
It's time to party like it's 1234567890 ? 'cause it is! On this Friday, Feb 13 at exactly 3:31:30 PM (PST), Unix time (WTF is Unix time?) will equal '1234567890'.


うぅむ、今日は飲みに行ってグダグダになりそうですが、朝はちゃんと起きてスクリーンキャプチャを取れるといいなぁ、、、と思います。

<追記 2009.02.14 10:00>
いやぁ〜〜、ひどく二日酔いですが、ちゃんと起きて待ち構えちゃいましたよ。

time1


新年カウントダウンみたいな気分になりますね、、、

time3



time2



うぉ〜〜〜、1234567890 だぁ〜〜、まぢで、、、、
HAPPY 1234567890!!!

Unixの時計が1234567890になるバレンタインの朝

UNIX time が「1234567890」になる - スラッシュドット・ジャパン
本家記事より、今週の13日の金曜日、UNIX Time(すなわち、1970年1月1日からの累積秒)が「1234567890」になる。と言っても、正確には「2009年2月13日11:31:30pm」はUTCでの表記であるので、日本時間では14日であることに注意してもらいたい。本家タレコミからリンクされているLinux Pro Magazineで紹介されているように、Perl Script「perl -e 'print scalar localtime(1234567890),"\n";' 」で自分の地方時における時間を知ることができる。


UNIX互換システムの標準Cでは時刻の表現としてtime_t型というUnix Epoch UTC時1970年1月1日0時0分0秒からの秒数で時刻を内部表現しているんですが、その内部表現の値がバレンタインデーの朝、日本時間2009年2月14日8時31分30秒に"1234567890"という連番になるんだそうです。Perlだと確認も簡単です。

% perl -e 'print scalar localtime(1234567890), "\n"'
Sat Feb 14 08:31:30 2009


Perlで簡単に昼間チラッとやってみたときには

1234238260


となって、刻一刻と近づいているのがよくわかります。

と、ちなみにJavaの内部表現は起算はUnix Epochで同じなんですが、ミリ秒単位で計算されていてDateクラスのgetTimeメソッドにより取得することができて、ミリ秒単位なんで余分に3桁つくことになります。


1234238260 // Unix
1234238260162 // Java


キリ番っぽくするために糸井重里七七七(スリーセブン)っぽく"777"を末尾につけるか、はたまた、"000"か"999"か悩むところです(・◇・)ゞ

うるう秒の実験君

このまえのデ協のWGで、昨年末あったうるう秒の話題になったんですが、日本の多くのタイムスタンプサービスや時刻配信局はうるう秒であるUTC時刻で2008年12月31日23時59分60秒、日本時間でいう2009年1月1日8時59分60秒は、利用者側で不具合がおきないようサービスを停止させておくという措置を取っていたそうです。

ASN.1プリミティブはITU-T X.680で規定されていてGeneralizedTimeは以下のように42章で以下のように定義されています。値はVisibleStringでありISO 8601で規定された時刻表現である限りは何でもよく

GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString


うるう秒でも表現して構わないようです。

GeneralizedTime: 20081231235960Z


一方、UTCTimeは同じく43章で規定されており秒は0..59の範囲しか使えないので、うるう秒を表現することはできません。

じゃぁ、うるう秒を含むような
・X.509証明書
・タイムスタンプトークン
・長期署名フォーマット
ってどうなるんだろうとう疑問が沸々沸いてきたので、まぁ、作ってみました。

ASN.1を扱うライブラリに完全に依存しているし、ANSIのCの時刻なんかは絶対アウトだろうな、、、と思うわけです。

うるう秒を含むX.509証明書



証明書の有効期限のnotBeforeが、昨年のうるう秒(GeneralizedTime 20081231235960Z)であるような証明書を作ってみて読めるか試してみました。

・OpenSSL
UTC時刻 2008年12月31日23時59分00秒 (と60秒戻ってしまった)
・Windows証明書ビューア
開こうとしても「このファイルは"セキュリティ証明書"として
使用することはできません」と表示されてしまいます。
・Windows PKCS#12のインポート
「インポート中のキーは正しくエンコードされていません。」
と表示され失敗
・Java 1.6 JCE SUN Provider(algorithm="X.509")
例外発生 java.security.cert.CertificateParsingException: Parse Generalized time, invalid format
・Java 1.6 JCE BC(BouncyCastle) Provider(algorithm="X.509")
読み込み成功。"200901010000Z"と同じ扱い。
・Java 1.6 JCE IAIK 3.142 Provider(algorithm="X.509")
読み込み成功。"200901010000Z"と同じ扱い。


テスト結果:
・WindowsやSun Javaなどはうるう秒証明書に対応していない
・暗号ライブラリ OpenSSL, BouncyCastle, IAIKはうるう秒証明書に(概ね)対応している


genTimeがうるう秒であるようなRFC 3161タイムスタンプトークン



とりあえず入手できた某RFC 3161タイムスタンプトークン検証ツールで試してみたところ、正しく"20081231235960Z"であるように表示されています。すばらしい。

うるう秒を含むCAdES長期署名フォーマット



署名タイムスタンプのgenTimeにうるう秒が含まれるようなCAdES長期署名ファイルを生成し、手持ちのツールやライブラリで検証してみました。

自前のCAdES実装では特に問題なく検証できました。時刻はうるう秒としてそのまま扱われていました。

うるう秒を含むXAdES長期署名フォーマット



署名タイムスタンプのgenTimeにうるう秒が含まれるようなXAdES長期署名ファイルを生成し、手持ちのツールやライブラリで検証してみました。

自前のXAdES実装では特に(大きな)問題なく検証できました。時刻はUTC時刻2009年1月1日0時0分0秒として扱われていました。

とある私のではない別の実装でXAdES-T署名を検証してみましたが、署名タイムスタンプのエラーになってしまいました。時刻がパーズできないせいなのか、どうかがちょっとわかりません。

今日は、こんなところで、、、、
最新記事
Categories
Archives
Twitter
記事Google検索

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