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)
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属性を用い署名者証明書の参照を入れることにより、署名者証明書が置換攻撃されないようにする。
- 信頼する第三者機関が発行する署名タイムスタンプを用い、証明書の失効、期限切れが無かったことを特定できる。
- 暗号アルゴリズムの危殆化、証明書の期限切れをアーカイブタイムスタンプを用いることにより長期に署名が有効であったことを保証できる。
問題点(2)失効情報の扱いに問題があるのではないか?
PAdES Basicでは、署名者証明書の有効性をオフラインなどの状態でも簡単に検証できるようにPDF署名のPKCS#7署名データ署名属性にadobeRevocationInfoArchival属性を加え、その中に検証用の証明書失効リスト(CRL)やOCSPレスポンスを含めなければなりません(should)。
ここで問題なのは、CRLやOCSPを取得した時刻です。PKCS#7の署名属性に含めるために、署名を行う直前に取得したCRLやOCSPを属性に含めることになります。これらを署名時刻における署名者証明書の検証に使うのは適切ではありません。それは、
- 例えば、署名用のICカードを紛失したことに気づいた場合、その証明書を失効する申請を認証局に対して行いますが、これがCRLやOCSPレスポンスに反映されるのは、通常は数事業日後になります。
- 上記は、CRLの発行周期にも依存していて、例えば月1回しかCRLを発行しない場合には、失効情報が記載されるまでかなりの日数を要するでしょう。
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これだけ、あからさまに間違えていると悪意すら感じます。PAdES署名に含まれる署名フォーマットPKCS#7もしくはCMSは、一般にはDERではなくBERでエンコードされています。にもかかわらず、PAdES Basicでは明示的にDERと書かれています。仕様の記述が正しいとするならAdobe AcrobatはPAdES Basicに対応していると公言しているのに、PAdES Basicには対応していないことになります。
c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of the signature dictionary.
おわりに
今回はPAdES Basicについて解説し、標準の問題点を指摘しました。一点、署名者と検証者の間で署名をどのように扱うかについての合意である署名ポリシに相当する情報Seed Valuesについては述べませんでした。長くなったので、これは次回にまわしたいと思います。
ではでは
早くまともな標準化がされて実装が世に普及すると良いですね。
iTextのようなOSSに搭載されると普及も促進されるかもしれません。
また、PDF内部のXML部分には、XAdESが使えると良いようにも思えます。
XAdESだとOSSはけっこう出てきています。
GNU DigiDoc - OpenXAdES利用
http://sourceforge.net/projects/gdigidoc
GDigiDoc is a GUI frontend built with GTKMM for DigiDoc (alias OpenXAdES)
OpenXAdES
http://www.openxades.org/
http://sourceforge.net/projects/gdigidoc/
http://www.sk.ee/pages.php/020207010103
OpenSignX - PKI X.509 certificates(www.openOCES.org) and XAdES enveloping sig.
http://sourceforge.net/projects/opensignx/
XAdES.PHP
http://sourceforge.net/projects/xades-php/
CAdESはぜんぜん出てきません。
qCAdES - まだコードが無い
http://sourceforge.net/projects/qcades/
こちらは誰もケアしていないみたいです。
ではがんばってください。