自堕落な技術者の日記

はじめに

米国政府で使用する暗号を2010年までに強固なアルゴリズムに移行することを決定し、政府以外の様々な分野でも同様に暗号の移行の実施が迫られており、これを「暗号の2010年問題」呼んでいます。

タイムスタンプについては、現時点で作成したデータが今後10年といった長いスパンで利用できることが求められるため、他の暗号の応用よりもかなり強固なアルゴリズムに早急に移行する必要があります。国内のタイムスタンプ局事業者では、すでにトークン内の一部分においてSHA2への移行が完了していますが、タイムスタンプトークンは様々な部分で暗号アルゴリズムが使われているので、移行できていない箇所が幾つか存在しています。

タイムビジネス協議会でも、暗号アルゴリズム移行のワーキンググループを立ち上げ、移行計画と移行内容の策定を進めています。

そのような状況の中、セイコーインスツルさんやセイコープレシジョンさんが共同で、開発者なら誰でも無償でRFC 3161デジタルタイムスタンプのSHA2アルゴリズムへの移行を試すことができる体験サイトを公開して頂けるようになりました。 いつもお世話になっているUさんから案内頂き、ようやく時間も取れたのでいろいろ試してみたので、レポートしたいと思います。

体験サイトで試せるSHA2のパターン

RFC 3161タイムスタンプトークンは、ざっくりと以下の場所で暗号アルゴリズムの移行を進めていかなければいけません。

• タイムスタンプトークンの主構造となる暗号メッセージ構文の署名データ(CMS SignedData)でのSHA2、SHA2withRSAの使用。
• タイムスタンプトークン情報(TSTInfo)でのSHA2の利用。
• タイムスタンプトークン内で使われるTSA証明書(=X.509公開鍵証明書)や時刻監査証(=X.509 属性証明書v2)のSHA2withRSAの使用。

どの場所で移行が必要になるか、体験サイトのトークンで違いがあるかを下図に示します。

体験サイトでのタイムスタンプの取得

体験サイトでは使い方を解説したPDFに記載されているタイムスタンプサービスのURLに対して、認証なしでタイムスタンプ要求を送ることにより取得できます。Adobe AcrobatやMicrosoft Office 2010やその他のCAdESやXAdESなどのタイムスタンプを利用するアプリケーションから利用することも可能です。私は自前開発のJavaベースのクライアントで試してみました。

タイムスタンプ要求でreqPolicyという値をいろいろ切り替えることによりタイムスタンプトークンのどの部分をSHA2対応にしたのか切り替えられるようになっています。reqPolicyと、取得できるタイムスタンプトークンのパターンを示したのが下表になります。

タイムスタンプトークンフォーマットにおける2つの課題

タイムスタンプトークンのフォーマットはRFC 3161で規定されていますが、2つの課題があります。

1. 国内の多くのタイムスタンプ局が発行するタイムスタンプトークンには時刻監査証と呼ばれる上流の時計との時間差を示す証明書がX.509属性証明書v2の形式で発行され、これがトークンに含まれます。現行のトークンではv1AttrCertというV1の属性証明書を格納する領域にV2の属性証明書を入れてしまっています。ASN.1を厳密にパースするアプリだとエラーになってしまうケースもあるようです。これを正しくv2AttrCertに格納し、その結果CMS SignedDataのバージョンをv4にしたものが体験サイトで試せるようになっています。
2. タイムスタンプトークンでTSA証明書の置換攻撃を防ぐためにESSSigningCertificate(V1)という属性を使いますが、これはSHA1しか使えない仕様になっています。これをSHA2でも使えるようにESSSigningCertificateV2を規定しタイムスタンプでも使えるように新しいRFC(RFC 5816)が公開されました。体験サイトではこれも試せるようになっています。体験サイトで公開されているESSSigningCertificateV2は、ちょっとおかしいような気がするので確認してみます。

おわりに

自前開発のCAdESやXAdESのフル実装では既にSHA2の対応は終わっていて、そのようなテストをするためにパラメーターをいろいろいじれるテスト用タイムスタンプ局を実装したんですが、そのような実装がなくても自分の実装がSHA2タイムスタンプに対応しているのか簡単に確認できるので、このような体験サイトの存在はとてもありがたいんじゃないかと思います。

ちなみに、セイコーさんのタイムスタンプはマイクロ秒単位でトークンが出てくるので、これについてはちょっとハマる実装もあるかもしれませんね。一般的なコンピュータではミリ秒単位までしか時刻を扱えないのと、ASN.1の時刻表現を秒単位までしか扱えないような実装も多いため注意が必要です。

最近、セキュリティ関係のニュースを見逃すことが多くて申し訳ないんですが、2010年6月10日にIETF SMIME Working Groupのメーリングリストでインターネットドラフト「Additional CMS Revocation Information Choices」がIESGに承認されProposed Standardになったとアナウンスがありました。

CMS署名データのcrlsフィールドには、元々X.509かデータ型を表すOIDの規定された失効情報が格納できるようになっていたんですが、そのOIDが他で全く規定されていないためにOCSPレスポンスやSCVPのデータが格納できないようになっていました。

特にOCSPレスポンスを標準で格納できるようになったことは、タイムスタンプ付きのCAdES/XAdESを長期保存することを考えている方々には朗報なんじゃないかと思います。

CMS署名における失効情報の格納

CMS署名データには失効情報を格納するためにcrlsフィールドというものがあり、ここに格納できるASN.1シンタックスの定義は以下のようになっています。

RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
　　　crl CertificateList,
　　　other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
　　　otherRevInfoFormat OBJECT IDENTIFIER,
　　　otherRevInfo ANY DEFINED BY otherRevInfoFormat }


格納できるデータはcrlかotherがあってX.509 CRLか他のデータが格納できます。 OCSPレスポンスなどは他のデータということになりますが、 otherの中にどんな種類のデータを格納するかはotherRevInfoFormatというオブジェクト 識別子(OID)で区別することになっていて、このOIDを定めた標準がこれまで何年も 無かったためにOCSPレスポンスなどを格納できずにいました。

OCSPレスポンスの格納

今回、このProposed Standardができたことにより、OCSPレスポンスを格納する場合には otherRevInfoFormatにid-ri-ocsp-response "1.3.6.1.5.5.7.16.2" を指定すればotherRevInfoにOCSPレスポンスを入れられるようになったのです。

CAdES、XAdESおよびタイムスタンプの長期保存に与える影響

今回のProposed Standard化の意義を深く考えている人はそう多くないんじゃないかと 思うんですが、自分としては心待ちにしていた標準化だったりします。 それは、

• アーカイビングの際、タイムスタンプ検証用の失効情報にOCSPが使いやすくなる。
• XAdES用のタイムスタンプ検証情報の格納にcrlsフィールドが使えるようになる。

タイムスタンプ検証情報にOCSPが使える事の意義

長期署名において署名やタイムスタンプを検証するためにCRLを使った場合、 そのCRLが検証するのに十分な猶予期間を持って取得されていることを考慮する必要があります。 簡単に言っちゃうと、署名をしたまさにその時刻にCRLを取得して含めたのではダメで、 署名時刻に失効申請たとしてそれが次のCRLに反映されるまでの十分な時間待ってから 取得したCRLを使わなければいけません。 毎日発行されるCRLならば割と話は簡単で数営業日待てばいいんですが、 CRLの発行周期が1ヶ月とか失効申請の都度CRLを発行するようなケースだと 適切なCRLかどうかを判断するのはすごく難しいです。 特に、サブCAやタイムスタンプ局証明書用のの失効情報については局によって例えば1ヶ月や 1年といった周期のところが多いので、次のアーカイビングを行うための待ち時間は 尋常ではなく、一般的な実装ではあきらめてしまっているケースが多いのではないでしょうか。 CRLでは、いつ取得したCRLであるかを第三者に示す仕掛けが無いために苦労するわけです。 OCSPレスポンスを使えば、所詮CRLを元にOCSPレスポンスを発行するので情報の新鮮さ は同じだったとしても、失効情報を取得した時間は明らかにできるので 猶予期間をまともに扱う事ができるようになるわけです。

XAdES中のタイムスタンプの失効情報にOCSPレスポンスが使える

タイムスタンプ局証明書がOCSPでしか失効情報を提供していない、または敢えて OCSPを使わなければならないってことが相互運用テストの場合にはあったりします。 XAdESの数世代のアーカイブタイムスタンプを行う場合には少し厄介で、 アーカイブタイムスタンプの検証情報はXAdES 1.4.1だったとしても タイムスタンプトークンの中に含めるしかなく、今回のProposed Standardが 出てくる前はcrlsフィールドには格納できなかったので、 CAdESと同等の非署名属性を用いてタイムスタンプトークンに格納する しかありませんでした。 XAdESを実装したいのにタイムスタンプのためのCMS実装だけでは 不十分でCAdESの属性まで扱える必要があったのです。 今回のProposed Standardを使えば、XAdESのアーカイブタイムスタンプの OCSPレスポンスによる失効情報をCMSの標準の範囲内で含めることができるわけです。

夏休みの宿題で自前のライブラリでOCSPレスポンスの格納に対応させようかなぁ。 早くこれがDraft Standard、Standardと進んで行くといいなぁ、と思っています。

Adobe Acrobatで使うと便利な証明書とタイムスタンプサービスのセットである Adobe CDSに関する前回の記事を書いてから半年すこし立ちましたが、それまで5つあった証明書発行サービスがもう一つ増えて6つになっていました。 今日はちょっと補足情報を書いてみようと思います。

Adobe CDSサービスの価格比較

Adobe CDS対応の証明書発行サービスには、個人向けと企業(組織)向けがありまして、 発行サービスによって署名可能回数が無制限のものや回数制限を設けているものがあります。 以前、自腹で証明書買おうと思って、最初にあった国内1社を含む6社で価格を比較したメモを作っていました。 これに、新たに加わった1社を入れて表にまとめてみました。

結構価格差ありますよね。購入の際の参考にしてみてください。 個人的には署名回数に制限無いものの方が、心置きなくテストで使えるのでいいかなとも思うんですが、 たまにしか使わない個人の人ならTC TrustCenterの500署名2万円弱/年っていうのでも十分なのかもしれません。

署名回数制限の方法について想像してみる

証明書発行サービスによっては署名回数に上限を設けて価格設定している所があります。この署名回数の制限をどのように行うのか、上限を超えると本当にできなくなるのか、単なる紳士協定なのか、システムエラーなどで失敗した場合に回数のカウントはどうなるのかずっと疑問に思っていました。以下のようなこともあって署名回数のカウント方法がよくわからなかったのです。

• USBトークン自体には秘密鍵を使用する回数に制限を設けられているといった話を聞いたことがない。
• Adobe CDSで使用するタイムスタンプサービスはどこも認証無であるし、Adobe Acrobatで タイムスタンプサービスの認証設定の画面などは無い。

署名回数制限があるサービスの中で、タイムスタンプ署名の回数として制限をしているところがありました。Adobe CDS署名に使われた証明書にはスタンプサービスのURLが拡張領域に書かれていますがそれを見てみると

http://TSPのホスト/TSPアプリ/乱数のような長い値

となっていました。おそらくこのURL中の乱数のような長い値を以てユーザの認証をしているのかな、と思いました。

タイムスタンプURLによる認証の問題

タイムスタンプ要求の差異のURLへのアクセスにより認証していて、その回数がAdobe CDSの署名回数と同等だったとすると少し困った問題が起きると思います。

• タイムスタンプ付き署名されたPDF文書はコピーされて不特定多数に渡ったりするので、渡した先は必ずしも悪い事をしない人とは限りません。
• Adobe CDSのPDF署名文書から、この署名に利用したタイムスタンプサービスのURLは誰でも知る事ができます。署名者の証明書に記載されています。
• 記載されているタイムスタンプサービスは特にIDパスワードなどの認証も無いので、URLさえ知っていればアクセスすることができます。接続元IPなどを制限している風でもありません。
• すると、Adobe CDS署名されたPDF文書を受け取った誰か意地悪な人が何人かいたとして、署名に回数制限があるサービスだったとすると、そのURL誰かが何回もアクセスして、Adobe CDSの証明書を持っている人(サブスクライバ)の残り署名可能回数を0にしてしまう事ができるかもしれません。

どんな運用になってるのかは、開示されている情報も無いのでよくわかりませんが、実際のところどうなんでしょうね。自分のやつは回数制限の無いタイプにしたので、とりあえずこんな不安は無くて良かったなぁと思います。

ではでは、今朝はこんなところで。

関連記事

• 2009.11.15 AcrobatのAdobe CDSについて書いてみる
• 2009.11.22 dumpasn1用のAdobe CDS関連の設定の追加

いつもXAdES関係でお世話になっているmiyachiさんのところでMicrosoft Office 2010でXAdES署名をするためのレジストリ設定ツールが公開されました。 そういえば、タイムスタンプの扱いについて「ある疑念」があったので、「そうそう試してみよう」とツールを使ってレジストリ設定をしてみたところちょっとうまくいかずに、報告したらソッコーで直して頂いちゃいました。すみませんでした。ありがとうございます。

で、「ある疑念」というのは

Office 2010では、タイムスタンプなんか検証してないし、解釈しようとすらしていないのでは？

ということなんです。今日は、これについて実際に試してみました。

検証内容

以下の内容で試してみました。

• テスト１：正常系：信頼するルートを辿って発行された署名タイムスタンプを付与した場合
• テスト２：異常系：信頼するルートを辿れないプライベートCAを辿って発行された署名タイムスタンプ
• テスト３：異常系：時刻が署名時刻と近くないgenTime=2001.01.01であるような署名タイムスタンプ

本当は他もやろうとおもったんですが、それについては後で、、、

テスト１、テスト２について

Office 2010の可視署名の機能をつかってパブリックルートの署名者証明書で、Officeに署名してみました。


署名してみると、タイムスタンプ局の証明書(TSA証明書)を発行するCAを信頼していようが、いまいが結果は同じで正しい署名であるかのように表示されます。ついでにタイムスタンプトークンの署名値を改ざんしたりもしてみましたが、やはり結果は同じです。

つまりOffice 2010 betaでは、タイムスタンプトークンの検証は一切行っておらず、不正なタイムスタンプが付与されていたとしても、表示は変わらず有効であるかのように見えてしまうようです。

テスト３

次に、TSA証明書のルートCAを信頼しているテスト用タイムスタンプ局から、genTimeがUTC 2001年1月1日正午であるようなタイムスタンプを発行しこれを署名タイムスタンプとして付与してみました。 付与したタイムスタンプのgenTimeは確かに

GeneralizedTime 01/01/2001 12:00:00 GMT

と異常に古い時刻に署名したことになっているはずなのですが、ご覧のように表示上は以下のようになっています。


つまり、タイムスタンプ局の発行する第三者から信頼される署名時刻が署名時刻として表示されるのではなく、PCのローカルの時計を元にした署名時刻のみが表示されるという事になります。また、Officeではどのタイムスタンプ局から発行されたトークンであるのかを知る術がありません。

Office 2010のXAdES機能の問題点

以上の実験からMicrosoft Office 2010のXAdES機能は、以下のような問題があることがわかりました。

• 署名タイムスタンプにより示される信頼できる署名時刻があるにもかかわらず、これは決して表示されることはない。
• それにも関わらずMicrosoft Office 2010の正式版では、署名タイムスタンプが付与されている場合、XAdES-TかXAdES-XかXAdES-XLであると表示されてしまう。XAdESを理解してる利用者は、表示された時刻が信頼できる署名時刻であるかのように誤解してしまうだろう。

上記の2つ目は、容易に誤解されることによりタイムスタンプ局、長期署名、XAdESの信頼を大きく揺るがす問題だと思いますし、このような状況でMicrosoft Office 2010がXAdESに対応していると呼ぶのは問題だと思います。

関連記事

• 2010.04.01 Microsoft Office 2010 BetaのXAdES機能

関連リンク

• MS technet: Digital Signatures in Office 2010
• LangEdge Blog:MS-Office2010の長期署名仕様解析 2010-06-11

先日、師匠のMさんに教えてもらったんですが、ベルギーの認証サービスChemberSignの出している欧州の電子署名や信頼点リストなどの標準化動向に関するホワイトペーパー"Electronic Signature Interoperability - Where we do stand in Europe"においてECOMの事が触れられていると教えてもらった。

確かに欧州通信規格協会(ETSI)の活動について述べられた3.3節の中の"Interoperability plugtests"においてETSI ESIが主催した3回の長期署名フォーマット CAdES/XAdES のリモートプラグテストイベントについて紹介しているが、

3.3.1 Interoperability plugtests

。。。中略。。。

The third plugtest was organised in February 2009 in close cooperation with the Japanese organisation ECOM. The success rate wasn’t great, showing the need of clarification and simplification of the standards themselves, even though most of the error cases were about features which were probably seldom used.

と記されている。3回目のプラグテストだけではなく3回の全てのプラグテストについてETSI STF 351のメンバとしてテストケース設計、テスト方法などボランティア協力をさせてもらった。特に3回目のテストではETSI初のCAdESのテストのため日本から多くの協力をさせてもらった。

ChemberSignの長身で男前の方は、確かイスタンブールでのETSI ESI会議にも欧州の信頼するルート認証局のリスト(TSL)の相互運用実験のために説明に来ておられたと思う。その会議ではSTF 351リーダーのカルロスさんに、何回も何回も「3回目のテストは日本のECOMの大きな貢献のおかげで成功できた」と言ってくれたので、その事をChemberSignの方は覚えてくれたんだと思う。昼休みに名刺交換をしたりCAdESテストについて質問をしてくれたりもした。

ともあれ、ECOMの活動がこのような形で紹介してもらえるのは、本当に有難い話だなぁ、、、と、思いました。

2010年6月にリリースが予定されているMicorosoft Office 2010で、XML形式の長期署名フォーマットXAdESがサポートされるという記事をUさんから紹介頂いた。

ブラジル政府はタイムスタンプ付き署名に熱心でECOMのサイトを見て、ブラジルの方が長期署名フォーマットについて問い合わせをしてきたりしてました。この記事を見るにブラジル政府の文書管理のためにXAdESに対応したような感じもしますね。

Microsoft Office 2010のRTM版(初期版)とベータ版のXAdESの各フォーマットの対応

現在、Microsoft Office 2010のベータ版が試せるようになっていますが、RTM版の機能はXAdES-X-Longまでに対応しているのに対し、ベータ版ではXAdES-Tまでしか対応していないんだそうです。

Office 10ベータ版のXAdES機能を試す

誰でも登録すればダウンロードできるOffice 10のベータ版を使って、XAdES-EPES、XAdES-Tの機能を試してみた。本当はC、X、X-Longも見てみたかったんだけど、正式版を待つことにしましょう。

Office文書にXAdES-EPES、XAdES-Tで署名するにはレジストリの変更をするそうです。

XAdES-EPESにするには

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000001
"MinXAdESLevel"=dword:00000001

XAdES-Tにするには

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000002
"MinXAdESLevel"=dword:00000002
"TSALocation"="HTTPタイムスタンプサービスのURL"

のように設定すればよいようです。実際に

• レジストリ設定なし (XML-Dsig署名)
• レジストリ設定でLevel=1 (XAdES-EPES署名)
• レジストリ設定でLevel=2 (XAdES-T署名)

のように設定して署名を行ってみました。

Office 10ベータ版のXAdES署名を見る

ご存じのとおりMicrosoft Office 2007以降の.docx、.xlsxなどのドキュメントフォーマットはいろんなファイルをZIPアーカイブで固めたもののになっていて "_xmlsignature" フォルダに署名データが入ります。

Office 2010の生成するXAdES署名データの特徴

実際にレジストリ設定をしてXAdES-TとXAdES-EPESで署名されたWordファイルを生成して、そのXAdES署名データを見てみました。以下のような特徴がありました。

• XAdES v1.3.2 フォーマット
• ハッシュアルゴリズムはSHA1を使用
• 署名アルゴリズムはSHA1withRSAを使用
• XAdES-Tは、XAdES-T over EPES
• XAdES-EPES対応といってもSignaturePolicyImpliedがついているだけ

XAdES-EPESに対応しているというので、かなり期待していたんですが、実はSignaturePolicyImpliedがついているだけで、これは署名者と検証者で署名ポリシに対して暗黙の合意があることを意味しています。これって、Office文書の署名ポリシに対して何らかの暗黙の合意があるとはとても思えないのに勝手につけてしまうのはどうかと思うのと、SignaturePolicyImpliedをつけるぐらいなら、いっそ無くしてXAdES-BESでいいんじゃないかなぁと思いました。

生成されたXAdESフォーマットのプロファイル

XAdESのXML要素のプロファイルはこんな感じでした。

あと、スキーマチェッカにはまだかけてないんですが、XAdES-EPESにした時に空要素のUnsignedSignaturePropertiesがあるのはスキーマ違反だと思います。

タイムスタンプサーバーについてはHTTPで認証無しのRFC 3161タイムスタンププロトコルに対応してないといけないので、国内の認証有のタイムスタンプサービスでは(仕掛けを入れないと)使えないこともあるかもしれません。

問題点は？

Microsoft Office 2010のXAdES署名の機能を見て、いくつか気になった点が他にもあります。

署名日時の表示

Offce 2010の署名の表示において署名を行った時刻は日単位で表示されています。国内のタイムスタンプサービスが500ミリ秒から1秒の精度を持っているのに日単位でしか表示されないのはもったいない話です。

猶予期間の問題

自分がICカードを落としたとき、その失効申請がCRLに反映されるまで数営業日かかるというのが普通だと思います。失効情報はリアルタイムに反映されるとは限らないので長期署名では署名してからある時間経過した後に取得した失効情報を用います。これを猶予期間(Grace Period)と呼んでいます。おそらくMicrosoft Office 2010のXAdES-C以降では失効情報として署名時刻に取得した失効情報を使うと思われますが、これは適切な失効情報ではありません。

XAdES-C、XAdES-X、XAdES-X-Longを流通させていいのか？

XAdES-CやXAdES-Xでは後になって必要となる当時の失効情報が取得できないかもしれませんし、XAdES-X-Longの中の検証情報へのタイムスタンプは機能として中途半端です。そこで、JIS X 5093:2008ではドキュメント交換にふさわしい署名はXAdES-TもしくはXAdES-Aだと位置づけました。XAdES-C、XAdES-X、XAdES-X-Longは不完全な中間データにすぎず、何らかの仕組みでこれを補ってやる必要があるのです。

タイムスタンプ検証してないんじゃ？

タイムスタンプ局の証明書(TSA証明書)をどうも検証していないっぽいんです。TSA証明書用のルート証明書を信頼していなくても、なんら警告やエラーが表示されませんし、ドキュメントで表示される(署名時刻でなく(T_T))署名日も署名タイムスタンプではなくSigningTimeプロパティの値を表示しているんじゃないかという気がしています。タイムスタンプの無効系のテストは時間があればやってみたいと思います。

おわりに

レジストリをいじらないとXAdESにならないというのは、ちょっとトホホな感じですが、ともあれMicrosoft Officeが標準でXAdESに対応してきたというのは、すごい事だなぁ、、、と思います。少しずつ普及が進むといいんですけどね。

今日はこの辺で、、、

PDF長期署名の仕様であるPAdESを解説する連載で、今回は第5回目となります。前回はPAdES Basicついて解説しましたが、その際宿題となっていたPAdES Basic用の署名ポリシに相当するSeed Valuesについて解説しようと思います。

電子契約や電子商取引において、デジタル署名付きの文書を作成した署名者と、文書を受け取ってその文書が正しいか検証する検証者との間で、どんな署名文書を交換するのか、署名の形式を事前に取り決めておくと良いケースがあります。

例えば、使ってよいハッシュアルゴリズムをSHA256、SHA512に限定したり、署名者証明書を発行してよい認証局を定めたりしたり、医師や弁護士などの資格情報を署名に含めたりするなどです。これを署名者と検証者の双方が合意して文書化、データ化したものを「署名ポリシ」と呼んでいます。

CAdESやXAdESの長期署名フォーマットでは、署名ポリシをASN.1バイナリ形式もしくはXML形式でデータ化するために以下のような仕様があります。

• RFC 3125 Electronic Signature Policies
• ETSI TR 102 272 ASN.1 format for signature policies
• ETSI TR 102 038 XML format for signature policies

Seed Values

PAdES Basicでは、ISO 32000-1との完全な互換性のために、CAdESの署名ポリシを使わずにこれと同様な機能を同じくISO 32000-1で規定されたSeed Valuesを使うとしてます。

引用：ETSI TS 102 778-2: 4.5 Seed Values and Signature Policies
A seed value dictionary (ISO 32000-1 [1], clause 12.7.4.5, table 234) contains information that conveys a set of rules (or policies) that the form's author wishes the conforming signature handler to enforce at the time the signature is applied. These wishes can be specified either as requirements or recommendations. These seed values perform a similar function as the signature policies specified in TS 101 733 [i.2].

Seed Valuesの定義はISO 32000-1 12.7.4.5 Signature Fieldsの節のTable 234(p447)で定義されています。

Seed Valuesはディクショナリ(名前とキーのペアの組)で表現されるようになっています。どのようなキーが使えるか主要な要素を表にしてみると以下のようになります。

ざっと読んだところETSIの署名ポリシの簡易版みたいな位置づけになりそうです。

Seed ValuesとETSI署名ポリシとの違い

Seed ValuesとETSIの署名ポリシとを比較して、できる事、できない事をまとめてみましょう。

ETSIの署名ポリシしかできない事

• 個々の署名ポリシに対してポリシIDかポリシURIが必須となっていて、そのIDで参照する。署名には署名ポリシ自体は含まれず、ポリシの参照だけが含まれる。
• 署名者と検証者の要件を分けて記述できる。
• 署名を行った理由、例えば文書作成者、承認者、配信者であることの表明に応じて必要な属性や証明書の種類の受け入れ要件を記述できる。
• タイムスタンプ局の詳細な情報(証明書、TSAポリシ、時刻精度、受け入れ誤差範囲)などが記述できる。
• 署名理由、属性の種類、暗号アルゴリズムが識別子で表現されるので ユニークに識別できる。
• 署名ポリシを単体でリポジトリに置いておき、これを署名者・検証者で参照できる。

Seed Valuesにしかできない事

• 法的証明(Legal Content Attestation)を文字列で記述できる。
• 多くの情報がシンボルでなくフリーフォーマットの文字列で記述できる。(比較がし辛いなどのデメリットもある。)

Seed Valuesは、基本的にはAdobeのDocument Lifecycle Managementと関係しているようで、Acrobat製品単体では利用しにくいもののようにも思えます。また、署名者が(勝手に作って)署名文書に含めて渡すという設計のようで、署名者・検証者が合意の下で利用するようなものではないのかもしれません。

おわりに

以上、今回はETSI署名ポリシと似た機能を持ち、Adobe Acrobatの標準機能で使えるPAdES Basic用の署名ポリシとも言えるSeed Valuesについて解説しました。

ではでは

PDF長期署名の仕様であるPAdESを解説する連載で、今回は第4回目となります。前回はPAdESが5つのパートにわかれているという話をしましたが、今回はその中の最も基本的な形式であり、現行のAdobe AcrobatやAcrobat Readerの8.x、9.xで標準でプラグイン無しにサポートしているPDF署名であるPAdES Basicについてお話します。

PAdES Basicの仕様は、Part2の部分「ETSI TS 102 778-2 V1.2.1 Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 2: PAdES Basic - Profile based on ISO 32000-1」で規定されています。PAdES Basicは、簡単に言うと「Adobe Acrobat 8以降で標準サポートしているCAdES-Tに相当するタイムスタンプ付きPDF署名」ということになるかと思います。(厳密に言うとCAdES-TというよりはCAdES v1.8.1のCMS-BES with TもしくはCMS-EPES with Tに近いかもしれません。)

ISO 32000-1 PDF 1.7とPAdES Basicとの関係

Adobe Acrobat (Reader) 8.xや9.xでサポートしているPDFフォーマット 1.7の仕様は国際標準「ISO 32000-1:2008 Document management - Portable document format - Part1: PDF 1.7」になっています。ISOのドキュメントは一般に有償ですが、そのコピーをAdobe社のサイトで無償で公開しています。ISO 32000-1は750ページ近くある大作ですが、PDF署名に関しては以下の節で規定されています。

• 12.7.4.5 Signature Fields (p446)
• 12.8 Digital Signatures (p466)

ISO 32000-1ではPDF署名のために数多くのオプション要素を規定していますが、これに新しい要素を規定することなく完全に互換性を保ちながらCAdES-T署名タイムスアンプとほぼ同等の機能を持たせるために、各要素の必須/オプションを規定したプロファイルがPAdES Basicです。

CAdESやCMSの拡張として規定された署名/非署名属性は一切使うことなくCAdES-Tとほぼ同等の機能を持つように設計されています。

ISO 32000-1 PDF署名とPAdES Basicとの比較

ISO 32000-1で規定されたPDF署名とPAdES Basicの違いについて、とりあえず表にまとめてみました。

表の細かい部分については後ほど説明しますが、ざっくりとISO 32000-1では単にオプションとなっていたものが、一部必須になったり、一部使っちゃいけないようになっていたりという違いがあるだけです。

【やらなければいけない事】

• PDF署名はISO 32000-1 PDf 1.7に従う。
• 署名フォーマットはPKCS#7(RFC 2315)を使う。従って、SignedDataのバージョンは1に限定され、certificatesには属性証明書は入れられず、SignerInfoにはIssuerAndSerialNameしか使えない。
• 署名タイムスタンプを入れる(should)。タイムスタンプのフォーマットはRFC 3161。
• 署名属性にadobeRevocationInfoArchival属性を入れ、ここに署名者証明書のCRLやOCSPレスポンスなどの失効情報を入れる(should)。
• PKCS#7署名はDERでContentフィールドに入れる。(本当にDER?)
• SubFilterフィールドはadbe.pkcs7.detachedかadbe.pkcs7.sha1のいずれか(shall)
• PKCS#7のcertificatesフィールドに署名者証明書を入れる(shall)。
• 署名者証明書に紐付くRFC 3281属性証明書を入れてはならない(shall)。
• 署名ポリシに相当するものはSeed Valuesを用いることができる(may)。
• シリアル署名(直列署名)にすることができる(may)。

【やってはいけない事】

• 署名フォーマットにPKCS#1を使ってはいけない。
• SignerInfoは二つ以上入れてはならない。(shall)

問題点(1)これをAdESと呼んでいいのか？

欧州各国の電子署名法の要件になっている高度電子署名(AdES: Advanced Electronic Signature)は、「署名者(signatory)が署名を行ったことを特定できる」という機能が必要でなんですが、CAdESやXAdESなどETSIで作成された長期書名フォーマットでは以下の方法により署名者が署名を行ったことの特定を実現しています。

• SigningCertificate属性を用い署名者証明書の参照を入れることにより、署名者証明書が置換攻撃されないようにする。
• 信頼する第三者機関が発行する署名タイムスタンプを用い、証明書の失効、期限切れが無かったことを特定できる。
• 暗号アルゴリズムの危殆化、証明書の期限切れをアーカイブタイムスタンプを用いることにより長期に署名が有効であったことを保証できる。

しかしながら、PAdES BasicではSigningCertificate属性が含まれていないため署名者証明書の置換攻撃に対して弱いままであり、先日、改訂されたと紹介したCAdES v1.8.1では、SigningCertificateを持たないものをCMS-T/C/XL/Aと呼びAdESではないとし区別しています。そのような意味でPAdES BasicをAdESであるとすることには、個人的には反対です。

問題点(2)失効情報の扱いに問題があるのではないか？

PAdES Basicでは、署名者証明書の有効性をオフラインなどの状態でも簡単に検証できるようにPDF署名のPKCS#7署名データ署名属性にadobeRevocationInfoArchival属性を加え、その中に検証用の証明書失効リスト(CRL)やOCSPレスポンスを含めなければなりません(should)。

ここで問題なのは、CRLやOCSPを取得した時刻です。PKCS#7の署名属性に含めるために、署名を行う直前に取得したCRLやOCSPを属性に含めることになります。これらを署名時刻における署名者証明書の検証に使うのは適切ではありません。それは、

• 例えば、署名用のICカードを紛失したことに気づいた場合、その証明書を失効する申請を認証局に対して行いますが、これがCRLやOCSPレスポンスに反映されるのは、通常は数事業日後になります。
• 上記は、CRLの発行周期にも依存していて、例えば月1回しかCRLを発行しない場合には、失効情報が記載されるまでかなりの日数を要するでしょう。

つまり、署名者証明書の有効性を後日検証する場合は、失効申請が反映されるのに十分な期間を経た後にCRLやOCSPレスポンスを取得し、これらを用いて証明書を検証しなければなりません。この期間のことを猶予期間(grace period)と呼んでおり、CAdESやXAdESの仕様中でも解説されていま す。PAdES Basicでは猶予期間を無視した仕様になっているのです。

PAdES Basicでは、失効情報の利用の優先順位について追記する必要があると思います。PAdES Basicの署名者証明書の検証において

• (優先度1)PAdES LTVに失効情報含まれており、これが猶予期間を超えるものであるならば、この失効情報を用いる。
• (優先度2)オンラインでCRLやOCSPレスポンスを取得できるならば、現時点でのCRLやOCSPを取得し、これを失効検証に用いる。
• (優先度3)オンラインで取得できない場合には、adobeRevocationInfoArchival属性に含まれるCRLやOCSPを用いて失効検証する。その場合には、あくまで検証結果が一時的なもので失効情報が十分ではなくオンラインで再度検証を促すような警告を表示させる必要がある。

といった記述が必要であると思います。

PAdES BasicでadobeRevocationInfoArchivalを入れるべきである(should)としたのは、個人的には混乱の元となるだけで、便利にもならないのでプロファイルに含めるべきではなかったと思っています。

問題点(3)PKCS#7は実際DERでなくBERじゃないのか？

ここにもASN.1 BERとDERの区別ができていない仕様がありました。常識的に考えて、ETSI TS 101 778-2 PAdES BasicでもBERとDERを間違えてると思います。なぜなら、世間一般に流通しているPKCS#7やCMS SignedDataを扱うライブラリはデフォルトでBERエンコードするからです。

引用 ETSI TS 102778-2 PAdES Basic: 3.1 Definitions
PDF signature: DER-encoded PKCS#7 binary data object containing a digital signature and other information necessary to verify the digital signature such as the signer's certificate along with any supplied revocation information

引用 ETSI TS 102778-2 PAdES Basic: 5.1 Requirements on PDF Signatures
c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of the signature dictionary.

これだけ、あからさまに間違えていると悪意すら感じます。PAdES署名に含まれる署名フォーマットPKCS#7もしくはCMSは、一般にはDERではなくBERでエンコードされています。にもかかわらず、PAdES Basicでは明示的にDERと書かれています。仕様の記述が正しいとするならAdobe AcrobatはPAdES Basicに対応していると公言しているのに、PAdES Basicには対応していないことになります。

おわりに

今回はPAdES Basicについて解説し、標準の問題点を指摘しました。一点、署名者と検証者の間で署名をどのように扱うかについての合意である署名ポリシに相当する情報Seed Valuesについては述べませんでした。長くなったので、これは次回にまわしたいと思います。

ではでは

PKCS#7やCMSなどの一般的な署名フォーマットと互換性を持ちながら、署名者の特定を厳密に行い長期に保存することが可能なバイナリ形式の署名フォーマットETSI TS 101 733 CAdES(CMS Advanced Electronic Signature)の仕様が2009年11月に改訂されていたようです。(全く気づきませんでした。おかしいなぁ、、、実際に公開されたのは1月に入ってじゃないのかなぁ、、、クリスマス休暇だしなぁ、、、)

前のバージョンはv1.7.4からv1.8.1へとなったわけですが、あまり重要な更新も無いのでv1.7.5でもよかったんじゃないかなと、思えるような更新です。

改訂作業は欧州通信規格協会(ETSI)の技術専門家タスクフォース(STF)で行われるので、個別の変更点は漏れ聞こえてきますが、改訂レビューの期間もすごく短くて何が変更されるのかETSIの電子署名基盤技術委員会(TC ESI)でも報告されるわけではないので、改訂の全体像っていうのがわかりにくいんですよね。

どの辺りが改訂されているのか少し調べてみました。

ワードで差分の抽出

差分を目で追うのも大変なので、Acrobat 9 Standardで比較しようとおもったら、比較機能はProだけなんですね。仕方なくMicrosoft Wordの比較機能を使いました。

(1) Microsoft Word 2003でv1.8.1を開く。
(2) メニューのツール＞文書の比較と反映を選ぶ。
(3) ファイル選択ダイアログでv1.7.4を選択する。
　　設定はデフォルトのままでモードは「反映」でよいようだ。

これで、変更部分が青字で表示されるようになります。

変更点のまとめの記述

「Annex L.2 Changes between 1.7.4 and 1.8.1」には変更点がまとめられています。ドラフトでは変更点は過去と一緒くたになっていたので、1.7.4と1.8.1の差分を明記して欲しいとMLやESI会議でお願いして、その場ではドラフト最終段階だから分けないという結論だったんですが、結局は分けてくれたようです。よかった。

主要な変更点次のようなんだそうです。

(a) ContentTimeStampの計算方法の明確化

具体的な計算方法の記述を無くし、CMSの計算方法を参照するように修正されました。

(b) タイムスタンプのハッシュアルゴリズム危殆化に関する記述

RFC 3161のタイムスタンプトークンのTSA証明書を特定するためにESSCertID(v1)とSHA2も使えるRFC 5035 ESSCertIDv2をサポートするものとする(shall)とされた。CAdESのRFC 3161タイムスタンプトークンはETS TS 101 861のプロファイルに準拠しなければならないそうだ。(見落としてた)

署名者証明書の特定にSHA256をデフォルトとするRFC 5035の「ESSCertIDv2もサポートする(shall)」という記述が加わった。

(c) OCSPを使う場合のCompleteCertificateRefsの利用ガイド

ocspRefHashは後方互換性のためオプションのままだが、置換攻撃に対応するために、これを含めることを強く推奨(strongly recommended)するとされた。

(d) CAdES-BES/EPESでなく一般的なCMSに対するCAdES属性の利用ガイド

(e) タイムスタンプのハッシュ計算についての追記

(f) CAdES-AでのB.3節の記述がオプションになるよう修正

(a) ContentTimeStampの計算方法の明確化について

ContentTimeStampは画像や文書などの署名対象データに対して署名を行う前に直接付与されるタイムスタンプです。v1.7.4までは、ContentTimeStampのmessageImprintの計算方法をencapContentInfoを使って具体的に記述していましたが、変に具体的だったため
・encapContentInfoのeContentがASN.1 BERやDERで違うときどうするのか
・内包署名(eContentに署名対象がある)や分離署名(署名対象データを署名フォーマットに入れない)の場合に計算はどうするのか
という問い合わせや議論が頻繁に起こっていたので、「CMSのmessage digestの計算方法と同じ方法を使う」という記述に変更されたようです。参照の仕方が大まかなので、かえって混乱するような気がします。「ContentTimeStampのmessageImprintのハッシュ値の計算方法はCMSのmessage digestの計算方法と同じで、eContentの構造に依存せず署名対象データそのものに対してハッシュ計算をする」というように何らかの補足は必要だったのかなと思います。

(d)一般的なCMSに対するCAdES属性の利用ガイドについて

CAdESのタイムスタンプ等を含まない基本的なフォーマットであるCAdES-BES、CAdES-EPESでは必須要件として署名者証明書を特定するためのESSSigningCertificateV1/V2属性を必須としていました。しかしながら、一般的なPKCS#7やCMS、PDF署名など、これら属性を最初から含まない署名データが数多く存在し、これらを長期保存するよう移行することができずに困っていました。

そこで、SigningCertificate属性を含まないものをCMS-BES/EPES/T/C/X/XL/Aと呼ぶことにより、CAdESの属性を使ってもよこととし、PKCS#7やCMSを長期保存できるようにしました。

欧州電子署名指令では高度電子署名(AdES)の要件として「署名者が特定できること」を挙げており、SigingCertificate属性は署名者証明書を特定でき置換攻撃ができないようにするための重要な要素なので、この属性もしくはこれと同等の機能を含まないものをAdESとは呼ばず、CMS-*としたことはとても意義があることだと思います。(この問題でPAdESについては言いたいことがあるんですが、また別の機会に、、、)

(f) CAdES-AでのB.3節の記述がオプションになるような修正について

v1.7.4のAnnex B.3 の CAdES-A の説明では、「少なくとも一つのTimestampedCertsCRLsかCAdES-C TimeStampが必須である」という記述だったんですが、元々過去のバージョン(v1.5.1以前？)ではオプションでした。ESI会議でこの点を日本とトルコが指摘し無事修正されることとなりました。

タイムスタンプのハッシュ計算についての追記について

v1.8.1 Annex Kに(informative)Time-stamp hash calculationという章が追加され、タイムスタンプトークンのmessageImprintの計算方法について表を用いた解説が追加されました。

個人的にはこの表の追加には反対だったし、そのようにコメントもしました。そもそも表自体がわかり辛いし、仕様本体(normative)と齟齬があるように誤解され得る箇所があり、一貫性を持ちながらこの表を今後メンテナンスしいく事が難しいように思えたからです。

全体的には仕様が緩められた

細かい所は説明しませんが、全体的にmustやshallと記述されていたところが緩い表現に変更されているのがわかります。現実の実装に則した仕様に近づいたかなと思います。

ArchiveTimeStampの計算方法について

ArchiveTimeStampの計算方法については、v1.5.1以降、曖昧な点があり続け、これを明確化するように日本からもコメントをし続けてきましたが、v1.7.4からv1.8.1への変更では大きく変更されることはありませんでした。依然としてASN.1 BERとDERのエンコーディングの違いによる問題は残されたままになっています。

署名対象のデータ表現について

CAdESや元のCMS(PKCS#7)で使われる署名対象のデータを署名フォーマットのeContentフィールドの中に格納することができるんですが、恐らくCAdES v1.6.3あたりから「こっそり」以下のような記述が追加されていました。

引用 ETSI TS 101 733 v1.8.1 5.2 Data Content Type
NOTE: If the content type is id- data, it is recommended that the content be encoded using MIME, and that the MIME type is used to identify the presentation format of the data. See clause F.1 for an example of using MIME to identify the encoding type.

コンテントがid-dataで示されるデータの場合には、S/MIMEのオペイク署名のようにMIMEでエンコードすることを推奨(recommended)するという記述が加わっています。個人的にはCAdESで制限する必要の無い事だと思っています。

おわりに

以上、少し時間が取れたので2009年11月に公開されたCAdES v1.8.1の改訂について解説してみました。この先、署名やPKI関係の仕事ができなそうな気もしているので、時間がとれ次第ため込んでいることを書き残していきたいと思っています。

ではでは

PDF長期署名の仕様であるPAdESを解説する連載で、今回は第3回目となります。前回はPDF署名の仕組みについてざっくりと解説しましたが、今回はPAdESの入り口として仕様の構成についてお話したいと思います。

PAdESは正式にはETSI TS 102 778 Electronic Signatures and Infrastractures (ESI); PDF Advanced Electronic Signature Profilesとして参照されるんですが、5つのパートに分かれた大作になっています。

・Part 1: PAdES Overview - a framework document for PAdES
・Part 2: PAdES Basic - Profile based on ISO 32000-1
・Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles
・Part 4: PAdES Long Term - PAdES-LTV Profile
・Part 5: PAdES for XML Content Profiles for XAdES signatures

各パートを簡単に説明してみると

各パートを簡単に説明してみるとこんな感じ、、、

◆Part 1 - PAdES概要
PDF署名の仕組みの簡単な説明。PAdESの概要と各パートの概要。
◆Part 2 - PAdES-Basic
ISO 32000-1 (PDF 1.7)のPKCS#7(やや古いCMS)に基づいたデジタルタイムスタンプ付きPDF署名をPAdES Basicと呼べるようにするためのプロファイル。つまり、どの要素が必須でどれがオプションかの説明。現行のAcrobat 9でもPAdES Basicには対応している。
◆Part 3 - PAdES-BES, PAdES-EPES
上記のPKCS#7署名の代わりに、署名に関する補足情報をいろいろ記述できるようににしたCMSの拡張であるCAdES-BESとCAdES-EPESにデジタルタイムスタンプをつけたものをPAdES-BES、PAdES-EPESであるとし、そのプロファイルを規定したもの。
◆Part 4 - PAdES-LTV (Long Term Validation)
PAdES-Basic、PAdES-BES、PAdES-EPESを、署名した証明書の期限切れや失効に関係なく、数十年といった長期にわたり検証できるように、PDF署名に加えられた仕組みについて。CAdES-C、CAdES-X、CAdES-Aは使わずに、PDFにとって扱いやすくした仕組みとなっており、PDFのドキュメントオブジェクトとして証明書、CRL、OCSPレスポンスなどの検証情報、PDF署名の仕組みと全く同じのドキュメントタイムスタンプと呼ばれるアーカイブタイムスタンプ方式を規定している。
◆Part 5
Part 2〜4とは独立に、PDFで扱われる2つのXMLデータ、すなわちXML文書の添付ファイルと、XML形式の入力フォーム(XFA)の長期署名に関する規定。XML添付ファイルについてはXML長期署名あるXAdESを用い、入力フォームについてはPart 3のようにタイムスタンプ付きのXAdES-BESかXAdES-EPESについて、Part 4で規定したPAdES-LTVの仕組みを用いて長期保存する。

PDF(署名)を長期保存するための3つのパス

まずはPart2からPart4までの関係を説明するために図を描いてみました。


PDF文書を、欧州の電子署名法に基づいて手書きと署名と同等であるとみなされる署名にしたかったり、署名データを長期間保存しなければいけなかったりする場合にはPAdES-Basic、PAdES-BES、PAdES-EPESの3つの方法があって、どの方法でも長期署名はできるようになっています。
証明書、CRL、OCSPレスポンスなどの検証情報や、ドキュメントタイムスタンプをつけるにはPAdES-LTVの方法を使うわけです。

PDFの中で使われるXML文書の長期署名

Part 5だけは、他とは毛色がちょっと違っていて、PDFの中に含まれるXML文書の部分をどうやって長期署名するかが規定されています。


PDFの中のXMLは大きく2つあって
・XMLファイルを添付ファイルとして付与した場合
・入力フォームデータをXML Form Architecture(XFA)データとして持っている場合
があります。

添付ファイルの場合には、単にXAdESで長期署名してやれば良いわけですが、XFAのフォームデータの場合には、XAdES-BES、XAdES-EPES、XAdES-TまではXAdESでやりますが、検証情報の追加やドキュメントタイムスタンプなどXAdES-X Long、XAdES-Aに対応するところは、先ほど説明したPart 4のPAdES-LTVの仕組みを使うようになっています。

ETSI PAdESの仕様のダウンロード

ETSIの技術標準(TS: Technical Standard)や技術レポート(TR: Technical Report)は、ユーザ登録さえすれば誰でも無償でダウンロードできます。
ダウンロードページを開き


Search forで「PAdES」と入力し、「Search」ボタンを押すとデフォルトでPAdES仕様の最新のものの一覧が出てきます。


右側のフロッピーディスクのアイコンをクリックするとアカウント入力の画面です。初めてならば「Uesrs without an ETSI account」の下の「Click here to register」をクリックし、氏名やメールアドレスを登録します。

前に登録していれば単にメールアドレスを入力するだけでPDF形式のドキュメントがダウンロードできます。詳しく知りたい場合にはダウロードしてみてください。

今日は、この辺で、、、