自堕落な技術者の日記 : タイムスタンプ

タイムスタンプ

2017年03月07日23:20

カテゴリ: PDF署名; ルート認証局リスト

追悼 Adobe CDS

PDF署名の利用拡大につながると、密かに期待していた、とても先進的なサービスだったAdobe CDSが、いよいよサービスを終了し、AATL (Adobe Approved Trust List)に移行すると知りました。まぁ、移行とは言えず、いろいろなものを捨て去っているわけですが、、、かつて自分も人柱としてAdobe CDS対応の証明書とトークンを購入し、使ってみたりもし、幾つかブログで書かせてもらい、良いサービスだったのですがとても残念です。悲しすぎるので追悼記事のようなもの書いてみたいと思います。

Adobe CDSとは何か

Adobe Acrobat には誰が署名をしたか、それが改ざんされていないかを示すためのPDF署名機能があり、Adobe Acrobat ReaderにはPDF署名の検証機能がついています。PDF署名の運用を厳格化し、Adobe Acrobat Readerのデフォルトであっても、ちゃんと本人確認をした証明書とハードウェアデバイスをつかって署名したPDF署名が検証できるようにするサービスがAdobe CDSでした。Adobe CDSには

HSMを使った組織によるサーバー向けPDF署名
USBトークンを使った個人によるPDF署名

の2種類に対応していました。ただのPDF署名とはどう違うのか、比較表にまとめてみました。

一般的なPDF署名	Adobe CDS PDF署名
証明書発行の際、本人確認をしようがしまいが構わない	証明書発行の本人確認はかなり厳格。例えば、パスポートのコピー、メールアドレスの送付と電話による(英語での)本人の意思確認など
秘密鍵の管理はなんでもよい	秘密鍵は必ずサーバー型ならHSM、個人型ならUSBトークンに格納され、エクスポート不可。(スマートカード対応の認証ベンダーはなかったはず。)
証明書はデジタル署名が可能ならなんでも良い。例えば、SSLサーバー証明書と秘密鍵でもよい	Adobe CDS署名専用の証明書であり、拡張領域に専用の拡張がある。証明書ポリシもCDS対応のものでないとAdobe CDSに登録できるCAとはならない。
PAdESタイムスタンプつきPDF署名である必要はなく、普通のPDF署名でもよい	署名するとPAdES署名タイムスタンプ付きのPDF署名となる
タイムスタンプをつけようとする場合、日本では一般に別途、タイムスタンプ事業者との利用契約が必要	Adobe CDS対応の認証局では、証明書を購入すればタイムスタンプサービスが合わせて提供される。Adobe CDSでは、認証サービスごとに、どのタイムスタンプサービスを使用するかが、証明書拡張に記載されており、固定である。認証サービス自体がタイムスタンプサービスを提供しているケースが多い。
信頼するルート証明書のリストはAdobe独自のものだった。この度これが、Adobe Approved Trust List(AATL)というルート証明書プログラムとして定義され、現時点で58のルート証明書が登録されている。WindowsやMac OS Xなどのルート証明書の数は400程度とこれよりかなり多いが、OSの持つルート証明書はAcrobat Readerのデフォルトでは信頼しておらず、これを信頼するようにするには設定変更の必要がある。	Adobe CDSのルート認証局はAdobeのルート一つであり、中間認証局としてAdobe CDS対応の認証ベンダー6つ程度があり、そこからユーザ用の証明書が発行される。Adobe CDS用の専用の運用ポリシ(CP/CPS)で運用されている。どのようなOSのAcrobat ReaderでもOSのトラストリストに関係なく同じ検証結果となる

Adobe CDSサービスのポイントは以下のようになると思います。

確かに本人が署名したと見なせる印鑑で言えば実印レベルのPDF署名ができる
(最近いろんな認証局が問題起こしていますが)運用のしっかりしていない認証局が紛れ込む可能性が比較的低い(けど、この中にも問題起こしたところありましたよね)
Adobe CDS専用の証明書で署名する
電子署名では、証明書が有効だった時刻に署名されたことを示すために、タイムスタンプが必須とされるが、Adobe CDSではデフォルトで署名タイムスタンプつきPDF署名となる
USBトークンなどのハードウェアデバイスを持っているはずの本人署名できず、他人がなりすまして署名をされる可能性は極めて低い

Adobe CDSのナイスなところ

タイムスタンプ付きPDF署名をしようとした場合に、日本では一般に署名用のクライアント証明書と、タイムスタンプサービスの利用がそれぞれ必要になります。これって、それぞれお金がかかるし、煩わしいですよね。日本でタイムスタンプ付き署名が流行らない理由の一つなのではとも思ってたりもします。海外の署名用証明書発行サービスでは、タイムスタンプサービスとセットで提供するものが多いですし、Adobe CDSもセット提供で、とても使いやすいです。

コード署名用証明書なんかも、RFC 3161タイムスタンプとは違いますが、似たようなカウンタ署名によるタイムスタンプの仕組みがセットで提供されるので、デフォルトでコード署名にはタイムスタンプがつきます。

Adobe CDSの何がいけなかったのか

Adobe CDSを使っているかどうかで、PDF署名に対する信頼の度合いは全く異なると思うのですが、Acrobat Readerでは、普通のPDF署名とAdobe CDS PDF署名との違いはありません。違いもないのなら、高いお金を払ってまでAdobe CDSを使うメリットも薄いですよね。

また、認証局にとっても、独立した中間CAを運用しなければならない。特別な証明書プロファイルも必要で、認証局にとってもとても負担となるプログラムだったと思います。相当利用が伸びないとサービスを維持するのは難しいと思います。

Adobe CDSのようにUSBトークンを使ったり、マイナンバーカードのようにスマートカードを使ったり、ハードウェアデバイスを使用して、厳格な本人確認のもと発行された証明書に関しては、共通の専用の証明書拡張を持たせるようにし、普通の署名とは区別し、EV証明書の緑のアドレスバーのような表示上の区別をしないと、ハードウェアデバイスを使った署名がなかなか普及しないのかなとも思います。

最近では、クラウド上で秘密鍵の管理をし、リモートで署名を行うような運用形態も増えており、ハードデバイスを本人が管理して署名するというのは、だんだん時代にも合わなくなってきたのかもしれません。

おわりに

Adobe CDSは、維持費用も結構かかるので、結局持ち続けることはできませんでしたが、「実印レベルのちゃんとした」PDF署名であるAdobe CDSは、なくなって欲しくはなかったです。ホントさびしい。バイバイ Adobe CDS。

タグ：: #Adobe; #CDS; #タイムスタンプ; #ルート認証局リスト; #トラストリスト; #USBトークン; #PDF署名; #PDF; #Acrobat; #AdobeCDS

2015年04月16日21:44

カテゴリ: ISO/IEC規格; タイムスタンプ

ISO/IEC 18014-4 Time-stamping services - Part 4: Traceability of time sourcesの制定について

苦節7年(といっても本当は自分の貢献なんか大したこと無いんですがorz)、自分も携わらせて頂いたタイムスタンプに関する日本発のISO/IEC国際標準が、ようやく制定されました。

ISO/IEC 18014-4 Information technology - Security techniques - Time-stamping services - Part 4: Traceability of time sources

マジ、うれしいっす。ちょっと泣きそう。ISO/IEC国際標準を制定するためのプロセスはここに解説があるんですが、本当に長い道のりです。

デジタルタイムスタンプとは

国際標準時って昔はイギリスのグリニッジ天文台の時間を使ってたんだけど、今は幾つかの国の原子時計の時間を比べながら、地球の回転(正しくは公転周期)なんかも考慮しながら協定世界時(UTC)という標準時間を作っています。

パソコンの時間って、NTPとかで自動的に合わせている人も多いけど、無理やり設定することもできますよね。例えば、同じような発明を2人がほぼ同時した時に、パソコンで時間戻して、ワードで発明資料を保存して、「オレの方が先に発明してた～～！！ファイルの更新日時見ろ～～っ！！」とかね。パソコンの時間って全くあてにならないから、データの存在時刻もあてにならないわけです。

医療、裁判、株取引、銀行業務、特許など、いろんな業務の電子化が進んでいるんですけど、デジタルデータはコピーや変更が簡単という性質があって、そのデータが本物かどうか、本当にその時間にあったかどうかが大切になるんですが、時間を証明するのって難しいんですよね。

これを解決するのがデジタルタイムスタンプという技術です。あるデータがある時刻に存在していて、それ以降変更されていない事を示すために、データを区別するための拇印のような情報であるデータのハッシュ値をタイムスタンプサービスに送ると、そのデータの存在証明、つまりデジタルタイムスタンプを作って送ってくれるというものです。日本でもこのようなデータの存在時刻を証明する時刻認証事業者、日本標準時からの誤差を保証しながら時刻を配信する時刻配信事業者が生まれサービスが開始されました。

各国国際標準時とのトレーサビリティーの必要性

こうした中、デジタルタイムスタンプのフォーマットについては、ISO国際標準があるので問題ないのですが、発行されるタイムスタンプが、各国の国際標準時と比較してどれくらいの精度で発行されているのかを保証する仕組みがありませんでした。タイムスタンプ局は、自分の持つ時計を元に、タイムスタンプを発行することができますが、これが無いと、各国の国際標準時と連携しているのか、どれくらいの誤差範囲で提供されるか保証や監査ができないものは、お互いの国で信用ができないからです。

そのようなわけで、各国の標準時を起源として、時刻の精度のトレーサビリティが保証および監査できないと、その国のタイムスタンプは信頼できないという話になるため、まず日本でJIS規格を制定し、うまくいけば、これをISO国際標準にしましょうという話になりました。

私の個人的な時刻トレーサビリティーの興味と今回の策定の関わり

私はその頃、タイムスタンプ付きの署名フォーマットである長期署名に興味があり、PKI方式タイムスタンプを採用する事業者が、タイムスタンプトークンに含んでいる、時刻監査証もしくは時刻監査記録と呼んでいる、時刻のトレーサビリティーを示すX.509v2属性証明書に着目していました。当時懸念に思っていたのは以下の事柄でした。

この時刻監査証(TAC: Time Audit Certificate)という属性証明書とその証明内容は利用者が検証する必要があるのか、無いのかが明らかになっていなかった。そもそもデータ・フォーマットや検証に必要な情報は公開されていなかった。
この時刻監査証はASN.1として誤ったエンコーディングをされていた。
時刻監査証に誤りがあった時に、利用者はそのタイムスタンプトークンを無効とすべきか否かが規定されていない。

認定基準を定め監督管理する団体、タイムスタンプ関係の事業者の専門家方、電子署名の専門家、国際標準の専門家の方と議論させて頂き、 2009年、日本データ通信協会で「タイムスタンプ局に対するUTCトレーサビリティ保証のTA技術要件に関する検討中間報告書」にまとめて頂きました。私は4.3節「TACの課題と結論」を執筆させて頂いております。

当時の私の疑問に対する識者コンセンサスは、

デジタルタイムスタンプの利用者は時刻監査証を検証する必要はない。
時刻監査証のASN.1エンコーディングはASN.1に準ずるようサービスを修正する。
時刻監査証に誤りがあった際に、利用者はそのタイムスタンプトークンを無効とする必要はない。

ということで納得しました。

ただ結局、タイムスタンプ事業者のTP/TPSタイムスタンプポリシ/運用規定では、時刻監査証のASN.1シンタックスが公開されず、時刻監査証は検証不要であることが明記する所、しない所があったりといった状況です。(ちょっと残念)

JIS X 5094:2011という時刻トレーサビリティに関するJIS規格の制定

その後、その中間報告書をベースに、日本国内で日本標準時からのタイムスタンプのタイムスタンプのトレーサビリティーを保証するためのJIS規格が2011年に制定されました。(これは、これで結構大変だった。)

JIS X 5094:2011 UTCトレーサビリティ保証のためのタイムアセスメント機関(TAA)の技術要件

中間報告書をベースにこれがJIS規格になり、日本データ通信協会で認定を受けている、時刻配信事業者や時刻認証事業者が当たり前のように行っていたことが、JIS規格として後ろ盾を持つことができるようになりました。

日本標準時とのトレーサビリティーの標準化で面倒だったのが、タイムスタンプサービスの標準がISOにはあるのにJISには無かったことです。このことで、タイムスタンプサービスを参照せずに、JIS化する必要があり、用語など手間がかかりました。

そして、今回のJISからISO/IEC規格へ

そして、世界各国のタイムスタンプが互いに信頼できるようにするために、言い換えると、世界各国の標準時とのトレーサビリティを持つ時刻配信が信頼できるようにするために、標準時からのトレーサビリティを持つ時刻配信のJIS標準をISOに持って行くことになり、ISOのドラフト版を作成しました。

関係者いろいろな伝をあたって頂き、暗号セキュリティ関係のISO/IEC SC27でお世話になることになり、SC27会議で正式に受理されました。

丁度、ISO/IEC 18014シリーズのタイムスタンプサービスのISO/IEC標準を見直す時期に来ていたそうで、これ幸いと、持っていったら追加でPart 4として標準化良いのでは？という事でワーキンググループが立ち上がりました。

その後、表現や細かい文言の修正など関係者の協力のおかげで、数多く対応してきましたが、私に関係するところとしては、当時nCipher製品でサポートされていた、PKI方式で電子署名された時刻監査証について参考情報として掲載したのですが、米国ではXML形式の電子署名されないデータを監査証として使っていました。先行するサービスの監査情報に適用できないのはまずいということで、これも比較できるよう掲載し、各項目の対応関係の補足説明を追加させていただきました。

後は、本当に長い時間のかかる、表現や文言の調整で、単に英語表現の問題だけではなくて、ISO/IECにふさわしい英語表現というのがあるようで、本当にWGの英国の方には細かく見ていただけました。

もうすぐ、承認されるかも、されるかもと、言っては、国際会議で流れ、また手直しをし、2014年10月のSC27メキシコ総会でPublishしてよいとの承認を頂いたそうです。それで、みな1月頃にはでるんじゃないの？と心待ちにしていたんですが、結局は4月になっちゃいました。

今後のISO/IEC規格からJISへ

JIS規格からISO/IEC規格にする際に、何点か国際間の整合を取れるような改正をしています。ISO/IEC規格は、翻訳さえすればそのままJIS規格にすることができるルールになっているそうです。ただ、関係省庁にお伺いをたてたところ、このUターンのJIS化は、今年は実施せずに、来年がJIS X 5094:2011が制定後、ちょうど5年になり見直しの年になるので、来年にやりましょうという話になったそうです。

盛大に祝杯をあげねばっ！！！

参考リンク

メキシコの会議報告が見つからないなぁ。しかし、会議報告の置き場所がバラバラだったり、一覧になってないのは何でなんですかねぇ。

標準ドラフト、NBコメント等一覧

年月日	番号	文書名
2011.05.31	N 10047	Call for contributions to the proposed new project
2011.06.16	N 9659	Text for ISO/IEC 1st WD
2011.09.05	N 10225	Summary of NB comments on document SC 27 N9659
2011.09.20	N 10388	UK NB comments on document SC 27 N9659
2011.10.03	N 10328	Draft disposition of NB comments on document SC 27 N9659
2011.12.12	N 10425	Text for ISO/IEC 2nd WD
2011.12.12	N 10426	Disposition of NB comments received on SC 27 N9659 - 1st WD
2012.04.13	N 10851	Summary of NB comments on document SC 27 N10425 2nd WD
2012.04.27	N 11060	Draft disposition of NB comments on document SC 27 N10425 - 2nd WD
2012.06.06	N 11173	ISO/IEC 1st CD
2012.06.06	N 11174	Disposition of NB comments received on document SC 27 N10425
2012.09.12	N 11485	Summary of voting on document SC 27 N11173
2012.10.05	N 11613	Draft disposition of comments received on document SC 27 N11173 1st CD
2012.12.14	N 11808	ISO/IEC 2nd CD
2012.12.14	N 11809	Dispositions of NB comments received on document SC 27 N11173 1st CD
2013.03.26	N 12185	Summary of voting on document SC 27 N11808 2nd CD
2013.04.08	N 12341	Draft disposition of comments received on SC 27 N11808 2nd CD
2013.06.10	N 12567	Text for ISO/IEC DIS
2013.06.10	N 12568	Disposition of comments received in SC 27 N12185 on document SC 27 N11808 2nd CD
2013.07.02		ISO/IEC DIS

DIS以降も改変があった記憶があるんですが、それはN番号つかないのかな？

タグ：: #ISO; #IEC; #ISOIEC; #JIS; #18014; #タイムスタンプ; #時刻認証; #時刻監査; #トレーサビリティ; #SC27

2009年11月22日12:45

カテゴリ: PDF署名; タイムスタンプ

dumpasn1用のAdobe CDS関連の設定の追加

前にAdobe CDSのPDF署名について書きましたが、証明書や署名データなどをdumpasn1というASN.1ダンプツールで表示させると不明の(説明されない)OID(オブジェクト識別子)のように表示されてしまいます。

オフィシャルなものでもありませんが、とりあえず dumpasn1.cfg ファイルに以下を追加してみました。

# Adobe

OID = 06 09 2A 86 48 86 F7 2F 01 01 08
Comment = Adobe AdobeRevocationInfoArchival CMS attribute for PDF
Description = adobeRevocationInfoArchival (1 2 840 113 583 1 1 8)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 01
Comment = Adobe CDS timestamp information extension (unofficial name)
Description = adobeCDSTimeStampInfo (1 2 840 113583 1 1 9 1)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 02
Comment = Adobe CDS certificate verification information extension (unofficial name)
Description = adobeCDSCertVerifyInfo (1 2 840 113583 1 1 9 2)

OID = 06 09 2A 86 48 86 F7 2F 01 02 01
Comment = Adobe CDS certificate policy
Description = adobeCDSCertificatePolicy (1 2 840 113583 1 2 1)

これを入れておけば、Adobe CDS証明書やPDF署名のPKCS#7署名データを見たときに役に立つかもしれません。

adobeCDSTimeStampInfo、adobeCDSCertVerifyInfoについては正しい名称がわからないし、公開されないままなので、とりあえずで付けています。また何か情報得られたら、こちらで紹介したいと思います。

タグ：: #Adobe; #CDS; #AdobeCDS; #PDF署名; #X509証明書; #タイムスタンプ; #dumpasn1

2009年01月21日20:01

カテゴリ: 長期署名; タイムスタンプ

うるう秒の実験君

このまえのデ協の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署名を検証してみましたが、署名タイムスタンプのエラーになってしまいました。時刻がパーズできないせいなのか、どうかがちょっとわかりません。

今日は、こんなところで、、、、

タグ：: #うるう秒; #タイムスタンプ; #証明書; #XAdES; #CAdES

2008年12月30日00:15

カテゴリ: タイムスタンプ; 電子署名

Microsoft Authenticodeのタイムスタンプについてお勉強(第3回：最終回)

自堕落な技術者の日記 : Microsoft Authenticodeのタイムスタンプについてお勉強(第2回) - livedoor Blog（ブログ）

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

年末バタバタしていたいので、間が空いてしまってすみません。

このシリーズではMicrosoft Authenticodeのコード署名に付与されるタイムスタンプが何であるのかについて書いています。結局、ここまでSigningTime属性のついた単なるカウンタ署名でるということがわかりました。

前回の説明でもう気付いちゃった人はいるかもしれませんが、Microsoft Authenticode用のタイムスタンプ要求には署名値というわけのわからない構造化もされていないオクテットに対して勝手に署名してくれるので、ぶっちゃけちゃうと中身は何でもいいわけです。

今回、最終回はこのあたりのぶっちゃけちゃった話をしたいと思います。

一般的な署名フォーマットとしての話

PKCS#7やCMS SignedDataでは、「あるデータに対して署名しましたよ～～～」と示すものなので、例えばPDFファイルや適当なデータに対してAuthenticode用タイムスタンプ要求を送信したとしても、内容の如何にかかわらず詐欺や偽の文書であろうがちゃんとPKCS#7あるいはCMSの署名の型で返してくれます。それも、Windows証明書ストアの信頼するルートから辿れる証明書(の鍵)で署名されたドキュメントになってしまうわけです。

Windows証明書ストアの信頼するルートを盲目的に信頼してしまっている署名検証アプリケーションはとってもヤバイことになってしまうのでは、、、と心配になってしまいます。

汎用の署名アプリケーションでは、PKCS#7やCMS SigneDataのフォーマットを使うことがよくありますが、署名者証明書のルートがそのアプリケーションで限定されたものにしておき、Windows証明書ストアのルートだからといって署名を有効としドキュメントが有効な署名に基づいているとしてしまうような事は避けないといけません。

偽RFC 3161タイムスタンプトークン(その１：失敗編)

Authenticodeタイムスタンプサービスには、任意のデータに対して署名要求を投げられるわけですから、例えば騙したい時刻のオレオレTSTInfoを作っておき、RFC 3161風味のトークンも作れてしまうのでは、、、と思ったわけです。

RFC 3161のタイムスタンプトークンはCMS SignedDataの形になっているわけですが、署名対象のデータとしてTSTInfo(OID 1.2.840.113549.1.9.16.1.4)の型のデータを持っているわけですが、通常Authenticode用タイムスタンプの取得でdata型()となっているところをTSTInfo型にして送信してみますと、、、、、まぁ、当然といいましょうか、、、、「TSTInfo型は知らない！」ということで要求は失敗します。

まずは、一安心です、、、、、

偽RFC 3161タイムスタンプトークン(その２）

では、data型というのはあきらめるものの、署名対象のデータとしてASN.1 TSTInfo型のデータとして送信してみると、、、、、

う～～～む、無事にというか、RFC 3161タイムスタンプトークン風味のものを取得できてしまいます。

これがヤバメだと思うのは、、、、

・Windows証明書ストアやSun Javaの信頼されるルートから辿れる署名である
・タイムスタンプ風味のデータは拡張鍵使用目的(extendedKeyUsage)拡張で
　timeStampingを持つ証明書に紐付く署名である
・TSTInfoの時刻は全くオレオレであり、(拾った鍵、危殆化した鍵が
　有効だった時刻に)時刻を詐称することが可能である
・本物のRFC 3161タイムスタンプトークンとの違いは、CMS SignedDataの
　　署名対象のデータ型がdataになっていることぐらいである。
・PKCS#7やCMS SignedDataはASN.1 BERかDERエンコードできるが、
　　Authenticode用タイムスタンプは正しくDERになっている。
　　(RFC 3161 TSP over HTTPではDERであることが生成要件になっている)

仕様を改定すべきと思う点

RFC 3161ベースのタイムスタンプトークンを発行するタイムスタンプ局(TSA)の証明書には拡張鍵使用目的(extendedKeyUsage)拡張でコード署名用タイムスタンプなどの汎用のタイムスタンプ局をあらわすtimeStampingの値ではなく、何か別の値を持たせて厳密に区別したほうがいいのではないかと思います。

Authenticode用タイムスタンプサーバーがエラーとなりdata型の値しか受けられなかったのは「たまたま」であり、TSTInfo型の要求を受けられるようになっていたら問題はとても深刻です。

そのためにもRFC 3161用のTSA証明書には専用のOIDを付けておく必要があるのではないかと思います。

また、署名を行った場合、対象となるデータを「承認した」とか「作成した」とか「表明する」とか何らかの署名意図があるわけですが、EKUでtimeStampingがある証明書で署名した場合、「署名対象のデータが、SigningTimeがある場合にはその時刻、SigningTimeがなくTSTInfoがある場合にはTSTInfoの時刻がに存在した」ことのみを表明するものであり、内容の正当性」については保証しないことを仕様で言及しておく必要があるのではないかと思います。

署名サーバーで注意すべき点

プロプライエタリな署名サーバーや、今回のAuthenticode用タイムスタンプサーバー、RFC 3161タイムスタンプサーバーなど、何らかの署名サービスを提供するサーバーは署名の目的を表明しておくか、署名する内容について広義の検証をしておく必要があります。

当面、検証側の実装が注意すべき点

今手元にRFC 3161タイムスタンプを扱うCAdESやXAdESなどの長期署名フォーマットの実装では、Authenticode用サーバーから出てきた偽のRFC 3161タイムスタンプ風のタイムスタンプトークンデータを扱う際に、ASN.1のパージングでエラーになる実装があったり、そのまま受け入れてしまったり、、、といろいろでした。

現状、このようななんちゃってタイムスタンプトークン受け入れないための検証ソフトウェアのベストカレントプラクティスを考えてみましょう。

・＜ベストプラクティス＞
　　・信頼するTSA証明書用のルートを限定しておく
　　・Windows証明書ストアの信頼するルートをTSA証明書のルートとして信頼しない
・＜仕方なく＞
　　・RFC 3161タイムスタンプトークンの署名対象のcontentTypeがTSTInfo型
　　　　であることを厳密に確認する。
　　・RFC 3161タイムスタンプトークンにSigningTime属性が入っていたら
　　　　まず疑ってみる。警告を出す。

タグ：: #コード署名; #タイムスタンプ; #Authenticode; #Microsoft

2008年12月20日01:09

カテゴリ: 電子署名; タイムスタンプ

Microsoft Authenticodeのタイムスタンプについてお勉強(第2回)

自堕落な技術者の日記 : Microsoft Authenticodeのタイムスタンプについてお勉強(第1回) - livedoor Blog（ブログ）

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

今回は第二回目ってことで、コード署名の中身を見てみましょう。

1. Microsoft Authenticodeコード署名の構造

コード署名は実行プログラムやDLLの末尾についています。正しい取り出し方というのはよくわかんないんですが、それほど大きくない実行ファイルならばバイナリエディタ等で開いてみて末尾３～４キロバイトあたりで"00"が並んでいる後で、きりのいいアドレスで

?0 0? 00 00 00 02 02 00-30 82 ...

のようになってたら30 82から最後までがPKCS#7のコード署名部分になります。

図02 コード署名の検索

取り出してASN.1構造を見てみるとこんな感じになっていました。

図01 コード署名の場所と構造

つまるところ、コード署名のタイムスタンプっていうのはRFC 3161のようなタイムスタンプではなくて、Authenticode用のタイムスタンプサービスによるSigningTime属性のついた単なるカウンタ署名(副署名)だったってことがわかりました。だから、プロパティダイアログでもタイムスタンプが副署名のところに出てくるわけです。

2. Authenticode署名用タイムスタンプのプロトコル

タイムスタンプがRFC 3161タイムスタンプでないことがわかったので、当然タイムスタンプを取得するためのプロトコルも独自のものになっています。タイムスタンプの要求と応答はHTTP(S)を用いて行われます。

3. Authenticode署名用タイムスタンプの要求

Authenticode用タイムスタンプの要求メッセージはASN.1 DERエンコーディングになっており構造は以下のようになっています。

カウンタ署名の対象となる、コード署名者の署名値をラップしているだけの構造です。

SEQUENCE {

  OBJECT IDENTIFIER

    timestampCountersignature (1 3 6 1 4 1 311 3 2 1)

  SEQUENCE {

    OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)

    [0] {

      OCTET STRING

        ... (コード署名の署名値) ...

      }

    }

  }

これをBase64エンコーディングしたものをContent-Typeをapplication/octet-streamにしてPOSTで送っているだけです。

4. Authenticode署名用タイムスタンプの応答

Authenticode署名用のタイムスタンプ応答は、署名対象として要求で指定されたバイト列に対して署名を施したPKCS#7署名データをBase64エンコードしたものです。

5. コード署名にタイムスタンプを付与するフロー

Authenticodeコード署名にタイムスタンプを付与するフローを示します。手順はざっくりこんな感じ。

① フツーに(タイムスタンプ無し)コード署名を行う
② コード署名の署名値のバイト列を取り出す
③ 上記、署名値よりタイムスタンプ要求を生成する
④ タイムスタンプサーバーに要求を送信する
⑤ タイムスタンプサーバーより応答(PKCS#7署名データ)を取得する
⑥ 上記署名データからSignerInfoの構造の部分を取り出す
⑦ コード署名の非署名属性群フィールドに上記SignerInfoをカウンタ署名属性
　　として格納する

図03 タイムスタンプの付与

というわけで、今日はMicrosoft Authenticodeコード署名のタイムスタンプについて以下のことがわかりました。

・RFC 3161 タイムスタンプ(トークン)ではない
・ただのカウンタ署名のSigningTimeを署名時刻としている
・タイムスタンプ取得のプロトコル

次回は最終回になるかな、、、、、嵐を呼ぶ最終回になったらごめんなさい。

ではでは

タグ：: #Microsoft; #Authenticode; #コード署名; #タイムスタンプ

2008年12月18日19:20

カテゴリ: 電子署名; タイムスタンプ

Microsoft Authenticodeのタイムスタンプについてお勉強(第1回)

今日は、Microsoft Authticodeコード署名のタイムスタンプについてお勉強したことを書いてみようと思います。これはやや長くなりそう、、、

1. はじめに

Microsoft AuthenticodeはMicrosoft Windowsの実行プログラム(.exe)やライブラリ(DLL)、オフィスのマクロなどに対して、配布の過程でプログラムの不正な改ざんが行われていないかをプログラムにデジタル署名を施して保証する仕組みで、一般にコード署名と言われているものです。

Microsoft Authenticodeにはタイムスタンプをつけることができ、コード署名用のデジタル証明書が有効であった第三者機関が保証する時刻に署名行われたことを示すためのものです。

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。

Outlookのプロパティの署名タブ

ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

2. コード署名を行うには？

自分が作ったWindowsプログラムにMicrosoft Authenticodeコード署名を付けるには "signtool.exe" や "signcode.exe" といったMicrosoftから提供されているツールを使います。例えば Microsoft .NET 2.0 SDK ならば、"C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\signtool.exe" にあるので探してみてください。

signtool自体はいろんな使い方があるんですが、一番簡単なのはウィザード形式で実行する方法です。コマンドラインで起動するのも面倒なので"signtool.exe"のショートカットを作っておいて、プロパティを開きリンク先のところで "signwizard" のコマンドラインオプションを付けて起動するようにしてやれば良いと思います。

signtool signwizard

あと、準備としては秘密鍵を持っているコード署名に使えそうな証明書を適当にみつくろってください。どんな条件ならコード署名に使えるのかは詳しく見てないのですが汎用なところではkeyUsage拡張にdigitalSignatureがありExtended Key Usage拡張がなければオッケーなようです。

先ほど作ったショートカットよりウィザードを起動して、「次へ」進むと最初にコード署名をする対象のEXEやDLLのファイルを選択して、、、

wizard basic 01

ここは面倒なので「通常」でよいでしょう、、、、

wizard basic 02

コード署名の署名に使う証明書を選択して、、、

wizard basic 03

このあたりはデータとしては入ってますが、表示はされないので適当に埋めといて、、、、

wizard basic 04

ここで、もしコード署名にタイムスタンプをつけるならチェックをオンにしてタイムスタンプサービスのURLを入力します。うちはコード署名証明書出してないんですがSignToolのマニュアルの例にある http://timestamp.verisign.com/scripts/timestamp.dll なんかが使えると思います。これは、お使いのコード署名証明書の発行サービスに確認してみてください。

wizard basic 05

サマリを確認しておしまいです。

wizard basic 06

簡単ですよね、、、、（＾＾；

今日はまったく本題に入れませんでしたが、長かったのでこの辺で、、、、、

3. 参考リンク

・MSDN: SignTool Tool コマンドマニュアル

タグ：: #Microsoft; #Authenticode; #コード署名; #タイムスタンプ

2008年12月17日07:45

カテゴリ: 電子署名; タイムスタンプ

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)

タグ：: #NIST; #デジタル署名; #タイムスタンプ; #ドラフト

2008年11月30日07:25

カテゴリ: タイムスタンプ; セキュリティ

RFC 3161Time Stamp Protocolの改訂ドラフト

11月25日、26日にスペイン・ビルバオ(Bilbao)で行われた欧州電子通信規格協会(ETSI)電子署名基盤技術委員会(TC ESI)の資料を見ていたら、これまでESIで議論していたRFC 3161の問題点に対する改訂のドラフトについてPinkasさんが3161の主エディタとしてIETF 73回ミネアポリス会議で発表したことを報告していたみたいです。

スライド資料「RFC 3161 bis Time Stamp Protocol, Denis Pinkas, Nov 2008」

変更の主要ポイントは以下、、、

・現行のESSCertIDはSHA1だけなので汎用のESSCertIDv2を使えるようにする
・Time Stamping Service(TSS)という用語を新たに定義しTime Stamping Authority(TSA)と区別させる
　(複数TSUとTSSの関係)
・ASN.1 モジュールの更新
・米Suretyの特許(#7,047,404)に関する記述
　(ETSI ES 201 733 が先に2000年に公開されている)
・ISOのタイムスタンプ(ISO 18014)の参照の追加

ESSCertIDv2については、SHA2などのために元々CAdESでETSI定義のOtherCertIDを使おうとしていたのを、ESSCertIDv2を使うように変更するようECOMからESIに提言しました。これを受けRFC 3161についてもハッシュ危殆化の問題からESSCertIDv2を使えるようにすべきだとESI副議長がコメントしていたことに対する修正となります。Surety特許問題もECOMからＫさんがESIにインプットしてくれたものです。

RFC 2634のESSCertIDだとSHA1しか使えなかったのが

ESSCertID ::=  SEQUENCE {

     certHash                 Hash,

     issuerSerial             IssuerSerial OPTIONAL }

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

RFC2634 5.4.1節より

RFC 5035では任意のハッシュアルゴリズムが使えデフォルトではSHA-256となります。

ESSCertIDv2 ::=  SEQUENCE {

    hashAlgorithm           AlgorithmIdentifier

           DEFAULT {algorithm id-sha256},

    certHash                 Hash,

    issuerSerial             IssuerSerial OPTIONAL }

Hash ::= OCTET STRING

RFC5035 5.4.1.1節より

日本の時刻認証局も様々な箇所でハッシュ危殆化対応のために既にSHA2へ移行していますが、ESSCertIDだけは仕様に縛られるため移行できず片手落ちみたいなところがあったかと思うのですが、RFC 3161 bisが出てくればこの部分も含め完全な移行が完了できるのではと期待しています。

今週あるデ協のTA-WGでも報告できるように資料作っておこう、、、、、

ちなみに、スペインのビルバオですがＭさんによれば、元々鉄鋼の町だったものを新しい工場団地を誘致しているような所で基本的には観光するようなところでは無いとの事でした。ピッツバーグやデトロイトに行くようなもんなんですかね、、、、、

＜追記＞
TSP over HTTPの際のMIME Typeについて不整合があったはずなので、これもインプットしておかないといけません。

タグ：: #タイムスタンプ; #TSA; #RFC3161

2008年07月16日21:39

カテゴリ: XAdES; CAdES

ECOM-ETSI Advanced Electronic Signature Workshop 2008

ECOM-ETSIワークショップ

8月18日月曜日に長期署名に関するワークショップをETSIとECOMと初のジョイントで開催します。お盆明けで暑いとは思いますが、よかったらご参加ください。（無料です）

その際にETSIで2008年9月と2009年2月に行われるCAdES、XAdESのリモートプラグテストの日本からの参加方法、実験内容などについても説明します。

ECOM-ETSI Advanced Electronic Signature Workshop 2008
Tokyo, Japan
18 August, 2008

■セミナー概要

CAdES/XAdES長期署名フォーマットの普及と欧州European Telecommunication
Standardization Institute(ETSI)で主催されるCAdES/XAdESリモートプラグテ
ストの日本から参加を呼びかけるためにECOMとETSIの共催によるワークショッ
プを開催する運びとなりました。

XAdESおよびXML署名分野におけるキーパーソンであるJuan Carlos Cruellas教
授にXAdESに関する今後方向性を伺ったり、各国における長期署名の普及の現
状や、また日本であまり紹介されることのないOASIS DSS(Digital Signature
Services)についてエディタの方から直接話を伺える貴重な機会であると思い
ます。

電子署名およびその各国動向についてご興味をお持ちの皆様の多数の参加をお
待ち申し上げます。

■日　時
平成２０年８月１８（月）１３：３０～１７：００
■場　所
機械振興会館　６階　６７会議室
(東京都港区芝公園3丁目５番８号)
http://www.ecom.jp/map/access.html

＝＝＝プログラム＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１３：３０～１３：４０

オープニング：ワークショップ開催の経緯と講演者の紹介
ECOM 主席研究員前田陽一

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１３：４０～１４：２５
講演１：XAdES/CAdES present and future. XAdES/CAdES and related standards in Spain

Universitat Politecnica de Catalunya, Spain
Juan Carlos Cruellas Ibarz 教授

ETSI XAdES、OASIS DSSなどの標準の主エディタである同氏にXAdESおよび関連
する標準の現状および今後中長期の方向性についてお話頂くと共に、スペイン
における長期署名をサポートする法制度、実運用されているシステム、関連す
る標準や他の国内イニシアチブについてご紹介頂きます。

質疑応答：５分間

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１４：３０～１５：１５
講演２：XMLDSIG Status and new Developments, relation to XAdES and the OASIS-DSS AdES-Profile

A-SIT, IAIK, Technische Universitat Graz, Austria
Konrad Lanz 氏

オーストリア政府の情報セキュリティを推進するA-SITに席を置かれOASIS DSS
のエディタである同氏には、最初にオーストリア政府の情報セキュリティを推
進するA-SITの電子署名関連の活動を紹介頂き、W3CやOASISにおける仕様改訂
の取り組みについてご紹介頂きます。W3Cでは2008年7月にW3CのXML署名の改訂
のためのワーキンググループが発足しますが、この改訂がXAdESやOASIS DSS
AdES Profileに与える影響について解説頂きます。

質疑応答：５分間

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１０分間休憩

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
１５：３０～１５：５５

講演３：PKI and Time Stamping Services in Macau and global communities

マカオ郵政局 (マカオ)
孫君煬(Gregory Sun) 氏

日本の旧郵政省に相当するマカオ郵政局において市民向けの認証局を担当して
おられる同氏にマカオ国内および世界的なコミュニティの中でPKIおよびタイ
ムスタンプサービスの現在の実施状況を紹介頂くと共に万国郵便連合
(Universal Postal Union)で仕様策定された電子サービスの標準に準拠したマ
カオのタイムスタンプサービスの実現について解説頂きます。

質疑応答：５分間

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１６：００～１６：４５

講演４：ETSI XAdES/CAdES リモートプラグテストの参加方法 (*)

エントラストジャパン株式会社
漆嶌賢二氏

本年度ETSIでは長期署名フォーマットであるCAdESおよびXAdESのプラグテスト
を2008年9月と2009年2月の2回の実施を計画しており、2008年4月よりECOMと共
同でテスト内容の策定を行っています。

本講演では日本からの参加方法、費用、テスト環境、テスト方法、結果報告方
法、コミュニケーション方法にについて説明すると共に、今年3月に行われた
ETSI初のリモートテストの概要と、ECOMで過去2回実施されたリモートテスト
との違いについて説明します。

ECOMでは、ETSIプラグテストのためのボランティアによる日本語ヘルプデスク
を設置し日本からより多くの企業が参加頂けるような体制を提供します。

質疑応答１０分

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

クロージング
ECOM 主席研究員前田陽一

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

尚、(*)印の講演を除き講演は英語で行われ、
通訳はございません。予めご了承下さい。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

参加費：ECOM会員かかわらず無料
申し込み：ECOMウェブサイトよりお申し込み下さい。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■本件に関する問い合わせは下記までお願いします

次世代電子商取引推進協議会（ECOM）
電子署名普及ワーキンググループ
主席研究員　前田　陽二

〒105-0011　東京都港区芝公園3丁目5番8号　機械振興会館3階
Tel：(03)3436-7541　
問い合わせ：http://www.ecom.jp/toiawase.html

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

ワークショップ実行委員会

委員長漆嶌賢二エントラストジャパン株式会社
委員木村道弘日本電気株式会社
委員宮崎一哉三菱電機株式会社
委員佐藤雅史セコム株式会社
委員ファン・カルロス・クルエラスカタルーニャ工科大学(スペイン)
委員ピーター・クレマー欧州電気通信標準化機構(ETSI)
委員コンラッド・ランス A-SIT(オーストリア)
事務局前田陽二次世代電子商取引推進協議会(ECOM)

タグ：: #CAdES; #XAdES; #タイムスタンプ; #ECOM; #ETSI

記事一覧(手作り)

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