自堕落な技術者の日記

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。

関連記事

• AcrobatのAdobe CDSについて書いてみる (2009.11.15)
• dumpasn1用のAdobe CDS関連の設定の追加 (2009.11.22)
• Adobe eSignaturesを試してみたんですが、、、 (2010.05.17)
• Adobe CDSについて書いてみた(その2) (2010.06.27)
• 連載:PAdES(PDF長期署名)について(第1回) (2009.11.21)
• 連載:PAdES(PDF長期署名)について(第2回) PDF署名とは (2009.11.27)
• 連載:PAdES(PDF長期署名)について(第3回) PAdES仕様の構成 (2009.12.11)
• 連載:PAdES(PDF長期署名)について(第4回) PAdES Basic (2010.01.17)
• 連載:PAdES(PDF長期署名)について(第5回) PAdES Basicと署名ポリシ (2010.01.18)

つい先日、MさんのTLで中国のタイムスタンプサービスのURLがあって、面白そうだからいろいろ調べてみました。UniTrust Time Stamp Authority(http://www.tsa.cn/)というのだそうです。

タイムスタンプサービスとは

例えば何か発明した時に、自分の発明の方が先だったとかテキストメモで書いたりしたとしても、パソコンの時間は自由に変更できますし、テキストメモの内容だって自由に変更できちゃいますから証明するの難しいですよね。そんな時、タイムスタンプサービスが発行してくれるデジタルタイムスタンプ使うと「ある時点にそのデータが存在してて、それ以降変更されてないこと」を証明することができます。

デジタル署名も証明書が有効だった「時」に署名された事がわからないと困るので、特にデータを保管する際には「デジタル署名にはデジタルタイムスタンプをつけましょう」というのが定石になっています。

日本ではタイムスタンプサービスをタイムビジネス協議会が普及促進をしていて、米国、欧州、アジアの幾つかの国でもこのようなサービスが始まっています。

で、tsa.cnはどうなの？

中国語は全く読めないんですが、

• 画像やデータをスマホからアップしてタイムスタンプをつけたりするAndroidアプリも充実
• Windows用デスクトップアプリも提供
• タイムスタンプつき文書をオンラインで検証できるページもある
• 値段は1タイムスタンプ10元(160円)?

となかなかサービスは充実しているようです。

タイムスタンプの取得方法ですが、http://timestamp.tsa.cn/tsa がRFC 3161 over HTTPで取得するためのURLになっているようでBasic認証で取得するみたいです。 Basic認証なのにHTTPSじゃなくていいのかな？tsa.cnではHTTPSのページは一切無いように見えます。

マニュアルなどのドキュメントは署名タイムスタンプつきPDF署名(PAdES-Tフォーマット)になっているようで 署名やタイムスタンプや証明書などを取り出して見てみました。

興味深いところはこんなとこです。

• タイムスタンプトークンについて
  • タイムスタンプ局のポリシが公開されていないようだ
  • トークンのTSA Policyは1.3.6.1.4.1.8291.1.1になっており米国Digistamp社の OIDになっている。OEMかもしれないし、単にOIDをパクってきただけなのかもしれない。
  • genTimeはミリ秒まで対応している
  • ordering=True
  • トークンへの署名アルゴリズムはSHA1withRSA
  • トークンのCMS SignedDataにはSigningTime属性が入っている。tSTInfoに時刻が含まれるのでSigningTimeは含めない方がよい
• TSA証明書について
  • ルートは"O=China Time-Stamp Authority, CN=China TSA Root"、2048bit RSA、SHA1withRSA
  • TSA証明書は"O=China Time-Stamp Authority, CN=China TSA"、2048bit RSA、SHA1withRSA
  • TSA署名書にはCRLDP拡張が無い
• PDF署名に使った署名者用証明書について
  • これは面白いところが満載
  • シリアル番号が負の値になっている。(RFC 5280的にNG)
  • 自己署名証明書
  • DNはCN=UniTrust, O=beijing unitrust, OU=, E=unitrust@unitrust.com.cn, C=<无
  • CNがUTF8の中国語になっている。本来なら"CN=cn" (RFC 5280的にNG)
  • OUの値が長さ0 (RFC 5280的にNG)
  • 不明の拡張がある1.2.840.113583.1.1.10。これ自体はAdobe社のOID
  • 普通はこのような証明書は発行できないので、独自のエンコーダーを使った CAアプリがあるのではと想像する。

アカウントを取っていろいろ調べて見ようともしているんですが、 アカウントの取り方がわかりそうになく断念してしまいました。今日はこの辺で。

20日ぐらい前、SignNow (https://signnow.com/)という電子署名をしてくれるらしいサービスが近日リリース予定というのを見つけまして、業界では楽しみにしていた方が何人かいたみたいですが(笑)どうやらようやく今日正式にサービス開始になったみたいなもんで早速試してみました。Adobe eSIGNATURESなんかと似た感じなんすかね？乞うご期待。

SignNowってどういうサービスなの？

SignNowは 米国のオンライン電子公証サービスNotaryNowの提供するウェブオンライン電子署名サービスでテキストやPDFなどのファイルを送信し、ウェブ画面上で手書き署名画像の場所を決めてやれば、サーバー側で電子署名してくれて署名済みPDFファイルをダウンロードできるようになっているというものです。サービスを利用するために事前/事後でアカウント作成をする必要はなくすぐに利用することができます。アプリケーションも一切必要なくウェブブラウザだけでできるそうです。

使ってみましょ

試しに、"aaa"という文字が入ったテキストファイルをアップロードして署名してみましょう。

1. SignNowのトップページをウェブブラウザで開き「Upload&Go」のボタンをクリックします。
   
   
2. 署名してもらうファイルを選択します。テキストファイルやPDFなど 多分、OpenOfficeで扱えるフォーマットなら何でもアップロード できるんだと思います。
   
   
3. アップロードしたファイルがPDFに変換されます。付箋など貼ることも できるようです。表示されているファイルをクリックすると 手書き署名入力ダイアログが表示されます。マウスじゃうまく 手書き署名はできないし、毎回同じように書けっこないから こりゃあくまでも飾りですね。
   
   
4. 手で書くのが面倒ならば自分の名前をタイプして手書き風フォントで 手書き署名風の画像を表示させることもできます。
   
   右側にメールアドレスを入力する箇所があります。 正しいアドレスを入れなきゃいけない風のことを書いてありますが、 別に嘘のアドレスでも問題はありません。
5. 次に手書き署名画像を表示させる場所をマウスで動かして設定します。 右にあるオレンジの「Complete」ボタンを押せば完成です。
   
   
6. 最後に署名完了の画面が表示されます。 画面中の「Click here to download」から署名済みPDFファイルを ダウンロードできます。
   
   

生成された電子署名付きPDFを開いてみよう

さて、生成されたPDFファイルを開いてみましょう。署名パネルボタンを開き、「すべてを検証」のリンクをクリックしてもAdobe Acrobat Reader のデフォルト設定では「文書の証明の完全性が不明です。 作成者を検証できませんでした。」と表示されます。 デフォルトではWindowsのルート証明書ストアを使わないよう 設定されているためです。

証明書の話は後でやりますが、これを検証できるようにするには メニュー「編集＞環境設定」を開き「セキュリティ」を選択します。 「詳細環境設定」のボタンを押します。

「電子署名の詳細環境設定」で「Windows統合」のタブを開き以下の2つにチェックを入れます。

• Windows証明書ストアからの証明書取り込みと使用を有効にする。
• 証明済み文書を検証

このように設定された状態で再度「すべてを検証」をすれば 下のように検証成功となります。

PDF署名をみてみると

証明書の話は後にして、PDF署名の署名ディクショナリはこんな感じ

/Type /Sig
/Filter /Adobe.PPKLite
/SubFilter /adbe.pkcs7.detached
/ByteRange [0 10060 21804 57036]
/Contents <308212....>

署名はフツーの署名タイムスタンプなしのPKCS#7署名で 署名属性もこれまた普通です。

• contentType
• signingTime
• messageDigest
• sMIMECapabilities

Reasonの値だけに特徴があってこんな感じ。 入力した本物とは限らないメールアドレスと 操作したIPアドレスがReasonに記載されています。

/Reason (
IP Address: 192.168.128.110
Email address of signer (unconfirmed): foo@foo.com
Date/Time: 1:08 EDT 4/7/2011
This document has not been modified.
This certificate was signed using SignNow.com
SignNow itself does not sign this document.
This is to be used only for data integrity, not identification.
)

さて署名者証明書とその証明書チェーンは？

PDF署名に使われた署名者証明書はドイツの認証サービス TC TrustCenterから発行されたもので以下のような 証明書チェーンになっています。

• ルートCA：TC TrustCenter Universal CA I
• 中間CA：TC TrustCenter Class 1 L1 CA IX
• 署名者証明書：SignNow Online

ルートCAは最近のWindowsの信頼されるルート認証機関に デフォルトで含まれているものです。(少なくとも2009年2月から は入っています。)

署名者証明書の主体者識別名はこんな感じ。 雑な感じですねぇ。

/C=US
/ST=CA
/L=Newport Beach
/OU=To verify, email: verified@signnow.com←ええ？？
/CN=SignNow Online
/SERIALNUMBER=online signing service←なんじゃこりゃ？

わりとまともなところが発行した証明書なんで 概ね問題ないんですが、拡張鍵使用目的の値はこんなの。

• クライアント認証 (1.3.6.1.5.5.7.3.2)
• S/MIME電子メールの保護 (1.3.6.1.5.5.7.3.4)
• IPsecVPNユーザー (1.3.6.1.5.5.7.3.7)
• スマートカードログオン (1.3.6.1.4.1.311.20.2.2)

この鍵使用目的じゃPDF署名に使っていいかは ちょっと微妙なところですねぇ。 電子メールの保護に入れちゃっていいんですかねぇ？ しっかし、Microsoftの証明書ビューアもヒドイ。 ipsecUser (1.3.6.1.5.5.7.3.7)を 「IPセキュリティユーザー」と訳すのはどうなんでしょうねぇ？

というわけでこれは何を証明してくれるのか？

これは、Adobe eSIGNATURESの時にも述べたように 文書の作成者、受領者、承認者でもない、 なんでもない人による自動的な署名なんですよね。 SignNowは署名対象に対して何の保証もしてくれません。 また、途中誰でも文書を改竄してから再署名するチャンスが いくらでもあるので文書の完全性についても怪しいです。 Adobe eSIGNATURESについてはアカウントを持っている人が 行っていることになるのでAdobeが公証人として信頼できる組織ならば 証明にもなるかもしれませんが、SignNowについては 何ら本人を認証するものではないので、 生成された署名には何の意味もありません。

これって優良誤認じゃないの？

サービスの 「Legal & Secure」のページに 「電子署名は手書き署名と同等の法的効力を持つ」とか 「電子政府でも使われている」とか 各国の電子署名法を参照してみるとかして SignNowのサービスによる電子署名が 法的効力を持っているかのように 「Don't worry! Even if your signature looks weird, It's still legally valid.」みたいな 事を書いていますがとんでもない話です。 EUの電子署名に係る指針であったり米国のESIGN Actなどで 電子署名が手書き署名と同等の法的効力を持つためには 「署名者(signatory)本人が電子署名を行ったと 特定できる場合にのみ電子署名が手書き署名と同等の法的効力を持つ」 としてます。 通常はスマートカードなどを用いて本人しか使用することができない 鍵がきちんと管理されており、その鍵と本人との関係が電子証明書により 紐づけられており、その鍵を使用して署名した場合に 法的効力を持つのです。 SignNowの場合は誰が署名したかなんて全くわからないわけですよね。 SignNowの署名が法的効力を持つかのような表現をしているのは いけない事です。JAROに訴えちゃいたくなります。

EUの電子署名に係る指針に基づいて欧州各国の電子署名法を定めていますが電子署名が手書き署名と同等の法的効力を持つためには適格電子署名(qualified electronic signature)である必要があるとしています。

・適格電子署名(qualified electronic signature)は以下が必要
　・署名者である自然人が特定できる適格証明書(qualified certificate)を用いて署名されている。
　・署名者本人がのみが利用可能なセキュアな署名デバイスにより署名されていること。
　・証明書と署名データとの関係をより厳密に特定できる高度電子署名(advanced electronic signature)が使われている事。

これと比較してみるとSignNowの署名はどれ一つ要件を満足していない事がわかります。 高度電子署名のフォーマットにはバイナリ形式のCAdES、XML形式のXAdES、PDF形式のPAdESがありフォーマットの雛型(プロファイル)は日本工業規格(JIS)化されています。

また、ホームページを見るとiPhoneからでも 署名ができるかのような表現になっていますけど、 現在 iPhone 用のアプリを提供しているわけでもないし、 ファイルアップロードボタンが表示されないので iPhoneのSafariから本サービスを利用することはできません。 これも優良誤認ですよね。 (もう一度iPhoneで開いて良く見てみたら mobile uploads coming soonとなってますね（＾＾；)

おわりに

というわけで、おもしろそうなサービスだし、 電子署名の新しい可能性を示してくれている感じもしますが 何の役にも立たない上に、優良誤認というか 詐欺まがいの代物だと思いますがどうでしょうか？ なんか、長くなっちゃいましたが、今日はこの辺で、、、

関連リンク

• Adobe eSignaturesを試してみたんですが、、、(2010.05.17)

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関連の設定の追加

みなさんも見たかもしれませんが、今日Tech Crunchでちょっとびっくりするニュースが出ていました。

電子署名界に革命勃発：Adobeが電子署名サービスのeSignatureを無料でベータ公開
Adobeが金曜日にeSignaturesをパブリックベータとして公開した。 eSignaturesというのは、オンラインドキュメントに簡単に電子署名を追加するクラウドサービスだ。ドキュメントをアップロードして、受信者のメールアドレスを記入し、日付と説明を記した後、当該ファイルに電子署名を付加する。電子署名を記載した文書は、署名後に改変されていないことが保証される。もし改変が行われた場合には証明書が表示されなくなる。手順は非常に簡単で（操作を初めてから完了するまで2分とかからなかった）、しかも無料で提供される。(Tech Crunch Japanの記事より引用)

無料でPDF署名してくれるクラウドサービスなんて、ちょっとワクワクしますよね。

最初はAdobeは電子署名について標準からややズレた事をやっている感じがしてたんですが、PDF署名のISO化や、ETSI ESIでのPAdES PDF長期署名や、Adobe CDSといった認証のスキームなどとても力を入れてまともな方向に注力しておられるようです。その、Adobeが署名をサービスでやってしまうとは、署名の普及に大きく寄与すると思いますし、どんな仕組みなのかとても興味あるところだったので実際に試してみました。

今日の午前中は時間にログインが全くできない状態だったりしたようですが、今日の午後あたりから落ち着いて使えていたみたいですね。

結局、どんなことをしてくれるのか

ユーザ個人に証明書や鍵なんか配ってくれて、ローミングで署名しちゃうのかとか、鍵預託なのかとか、期待しちゃうところですが、実際試してみたところこのようなサービスのようです。

1. 署名付きPDFを交換したいような人は全てAdobe eSIGNATURESのサービスに入っておく。メールだけで誰でもアカウントをもらえ、既存のAdobe IDも使える。
2. 基本は、あるPDF文書について、送り主と一人以上の受取人が全て承認したら署名付きPDFが生成されるというワークフローサービスである。
3. 送り主はPDFをアップロードし、PDFの内容について承認を得るように複数のAdobe eSIGNATURESのユーザに対してメールアドレスを指定することによりPDFを送信する。
4. PDFはサーバーに置かれるが、PDFファイルが各人のボックスに届いた旨、案内メールが届く。
5. 受取人はAdobe eSIGNATURESにアクセスし、自分のボックスを見る。
6. 自分のボックスに入っているPDF文書について、閲覧し(Flash使用、日本語可)、承認するか、しないかを(承認できない場合、内容に承認できない、自分宛に承認を求めるのは不適切、その他の理由など指定可能)入力する。
7. 送り主と受取人の全てが承認した場合は、オリジナルの文書の最後に送り主と全ての受取人の手書き署名ロゴ(画像指定可能)、メールアドレスが書かれた電子署名では無い署名シールと、文末にAdobeの免責事項が書かれたページが追加され、その上で、Adobe eSignaturesサービスのサーバーによるAdobe CDS PDF署名が付与される。
8. そしてPDFが全員により承認された旨メールが届き、各人のボックスには上述のPDF署名ファイルがダウンロードできるようになる。
9. 受取人の誰かが承認しなかった場合には、その旨のメールが全員に届き、ボックスには何も入らない。

と、サービスはこのようなものである。本人の署名ではなくサーバーによる署名なので少しがっかりしてしまった。また、必ず受取人が必要で、自分を受取人にして自分のために署名するようなことはできない。

PDF署名について

生成される署名はデジタルタイムスタンプ付きのPDF署名でPAdES Basic(「連載:PAdES(PDF長期署名)について(第4回) PAdES Basic」参照)に準拠しているようだ。ハッシュアルゴリズムはSHA256である。 署名に用いられている証明書はサービス利用者毎のものではなく、 本サービスのサーバー "esign-help@adobe.com" に GeoTrustから発行された共通の Adobe CDS 証明書が用いられている。、 GeoTrustのAdobe CDS認証サービス・タイムスタンプサービスについて執筆時点で4つほど疑問に感じていることがある。

• タイムスタンプサービスで精度(Accuracy)が60秒と他のタイムスタンプサービスに比較して極端に長いにも関わらずordering TRUE、即ち発行の時間的順序性が保証されているとベンダーは言っているので注意が必要である。技術的にはaccuracyとorderingをこの精度で正しく運用しているかは少し疑問で、NTPで調時してシステム時刻が巻き戻ることが無いと保証しているのか不安に思う。
• タイムスタンプトークンにおいて、TSAポリシが1.1.2になっている事が気にかかる。OID 1.1は廃止になったISO OID Registration Authorityのもので、このOIDを使う権限がなく適切でないのではないか？
• タイムスタンプ局運用規定(TSAポリシ)が公開されていない。
• Adobe CDSの証明書ポリシによると、発行されるCRLはX.509v2 CRLでAuthorityKeyIdentifierとCRLNumberが必要であると記されているが、GeoTrust CA for Adobeから発行されるCRLは、これに則していない。

何に対して署名しているのか？

このサービスで少し疑問に思ったのは、何に対してデジタル署名していて、何を証明してくれるのかという事だ。

• ユーザ各人について氏名•メールアドレス•手書き署名風のが画像が出てくるが、これらはデジタル署名ではなく、何も証明はしてくれない。
• ユーザ各人の本人確認は単にメールアドレスが届く人というだけで、氏名が本人かはわからない。単にメールアドレスの認証だ。
• Adobeの免責事項にもある通り、オリジナルのPDF文書の内容についてAdobeは何も保証するものではない。
• デジタルタイムスタンプが付与されて以降は、文書が改ざんされていないとは言える。

もし、Adobeが正しい運用しかせず、利用者も信頼できるならば、このPDF文書は

あるメールアドレスをもつユーザ全員が、あるPDF文書に対して承認したというワークフローが完了し、タイムスタンプが付与された時刻以降改ざんされていない

ことを認証するかもしれない。

ところが、もしAdobeが悪い会社だったり、悪い人がいて勝手にPDF文書を改ざんしたりでっちあげたりして、何人かのユーザに署名付きで正しいと主張するPDF文書を送りつけるかもしれない。誰かが承認しなかったとしても、それを承認したとしてワークフローを流すこともできる。

また、ユーザについても、メールにつけられるメッセージはPDF文書に反映されるわけではないので、メール本文に「この文章に反対ならば署名してください」などと書けば受取人は署名するかもしれず、Adobe eSIGNATURESのシステムではこれは文書に対して「承認」したことにされてしまう可能性だってあるのだ。

結局のところ、Adobe eSIGNATURESは、直前に改ざんしちゃう可能性もあるのでみんなが承認しようとした文書そのままの形であるかどうかは別にして、Adobe eSIGNATURESのシステムを通った文書であり、タイムスタンプの時刻以降、暗号が危殆化せず、TSA証明書が有効限りは改ざんされていないこと「だけ」を証明しているだけだと思う。

おわりに

「無料で署名できる」という言葉に踊らされてしまったが、 現状のサービスのままならば、ユーザら本人の署名ではなくAdobeの署名がつく事の意義や有り難みがわからず、Adobeが署名するよりも、単に署名無しで匿名でデジタルタイムスタンプを付与するので十分なような気がするし、効果も大きく変わらないように思う。

とはいえ、電子署名、PDF署名、PAdES長期署名、デジタルタイムスタンプの応用サービスとしてこのサービスは十分に野心的かつ革新的だと思うし、正直びっくりした。まだベータ版のサービスとの事なので、今後の改良にとても期待しています。

このブログは私の所属とは関係なく個人的な見解に基づいて書いています。勉強が足りないために間違っている点もあるかもしれませんが、その際にはコメント欄でご指摘頂ければ幸いです。

関連リンク

• Adobe eSIGNATURES - 無料、PDF署名サービスベータサイト
• Adobe Labs - Adobe eSignatures
• Adobe Featured Blog - Adobe launches new cloud-based eSignature service
• Tech Crunch Japan: 電子署名界に革命勃発：Adobeが電子署名サービスのeSignatureを無料でベータ公開

本ブログ内の関連記事

• AcrobatのAdobe CDSについて書いてみる
• dumpasn1用のAdobe CDS関連の設定の追加
• 連載:PAdES(PDF長期署名)について(第4回) PAdES Basic
• 連載:PAdES(PDF長期署名)について(第5回) PAdES Basicと署名ポリシ

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については述べませんでした。長くなったので、これは次回にまわしたいと思います。

ではでは

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形式のドキュメントがダウンロードできます。詳しく知りたい場合にはダウロードしてみてください。

今日は、この辺で、、、

前回に引き続き今回はPAdES(PDF長期署名)の解説の第二回目として「PDF署名の拡張であるPAdESを説明する前に、そもそもPDF署名とは」という事について説明してみたいと思います。

以降深堀していくPAdESについて理解できる程度に、なるべく簡単に(できればわかりやすく（＾＾；)説明していこうと思います。PDF署名については素人なので素人目線になると思いますが、間違いなどあったらコメントでご指摘いただければと思います。

Adobe Acrobat 9を使った署名の生成

PDFファイルの生成に最もよく使われているAdobe Acrobatを使えば、PDFファイルに電子署名をつけることができます。下の画面はAdobe Acrobat 9 Standardで署名される前のPDFファイルを開いてみた例です。ツールバーに署名のボタンがあるのがわかります。


この署名ボタンを押せば、自分用の証明書と鍵を使って電子署名をつけることができます。

PDFにつけられる署名には見た目で区別して以下の2つの種類の署名があります：
・可視署名：署名したというしるしが文書中に入れられ印刷される署名
・不可視署名：署名したというしるしが印刷上表示されない署名

不可視署名されたPDFファイルをAcrobat Reader 9で開いてみると、こんな感じ。ページの中には署名が付いていることの印はなくドキュメントの上に署名が正しければ水色のツールバーが表示されます。



可視署名の例はこんな感じ。ドキュメント上の水色のツールバーに加えて右側に署名したという印がついています。



署名されたPDFファイルが書き換えられていた場合、水色のバーの左側に赤いバツ印がつくので、「あぁ、これは改ざんされているな」とひと目でわかるようになっています。

PDFファイルの中身

PDFは実は中身はほとんどテキストファイルになっていて、ワードパットなどで見る事ができます。

PDF署名の仕組み

PDF署名をざっくりと簡単に説明している図が下です。テキストで構成されているPDFのデータの途中に署名を差し込み、これによりPDFの内容を署名で保護します。



PDFではページなどドキュメントオブジェクトとして扱いますが、署名もまた署名オブジェクトとして扱います。概ね以下のような形式のデータとなっており、署名に関する補足的な情報も含まれています。

18 0 obj <<
　/Type/Sig
　/Filter/Adobe.PPKLite
　/SubFilter/adobe.pkcs7.detached
　/Contents <署名値>
　/ByteRange [署名対象範囲(前開始 前長さ 後開始 後長さ)]
　/ContactInfo(電話連絡先)
　/Location(署名地)
　/M(署名日)
　/Name(署名者名)
　/Reason(署名理由)
　>>
　endobj

/Contentsの署名値の部分はPKCS#1署名(生の公開暗号による署名データ)もしくはS/MIMEメールなどで使われているPKCS#7署名またはCMSと呼ばれるASN.1バイナリ形式の署名データを16進数表現で格納します。

PDFの署名対象範囲(ByteRange)とPKCS#7署名値(Contents)の関係

署名ディクショナリの"/Contents"の値にPKCS#1かPKCS#7の署名フォーマットで署名が格納されているわけですが、どの部分を署名対象としているかを表しているのが"/ByteRange"のプロパティです。

PKCS#7の分離署名(detached署名)をContentsに入れるとして、PKCS#7署名データがどのように設定されるかを図で説明しましょう。


(1)ページデータの最後あたりに署名オブジェクト(/Type/Sig)を入れるとして
(2)事前にPKCS#7署名データのサイズより大きめに領域を確保しておき
(3)ByteRangeを計算し
(4)ByteRangeで指定された2つの範囲を署名対象としてPKCS#7署名を生成
(5)生成されたPKCS#7署名を16進数表現にして/Contentsに設定
という流れになります。

入れられるPKCS#1署名、PKCS#7署名にバリエーションありすぎ

上の図ではPKCS#7を想定して書きましたが、PKCS#1であっても同じようなものです。中に署名を格納する方法に様々なバリエーションがあります。RFC3161ベースのタイムスタンプトークンを格納することもできます。

・生の属性を含まないPKCS#1署名
・署名属性、非署名属性を持たないPKCS#7署名
・署名属性、非署名属性を持つPKCS#7署名orCMS
・署名属性、非署名属性を持つタイムスタンプ付きPKCS#7署名orCMS

署名者(の証明書)の特定がしにくいものもあったりするので、欧州電子署名指令に合うように、署名者の特定をなるべく厳密にできるようにPKCS#7、CMSもしくはCAdES長期署名のプロファイルを定めたのがPAdES(PDF長期署名)ということになります。

さて、今回はPDF署名の中身はPKCS#7もしくはCMS署名フォーマットで、どんなふうに埋められているのかってことが、なんとなくお分かりいただけたでしょうか。

PAdESの入り口に入って行きたいとおもいます。PDF署名で補足したほうがよさそうな事を思い出したら、また書いてみたいと思います。

ではでは、、、

う〜〜ん、ちょっと熱っぽい、、、

参考リンク

PDF署名で参考になりそうなリンクを記しておきます。
・Adobe Acrobat 9 Standard オンラインマニュアル
・アンテナハウス PDF電子署名入門(2008.08.24)
PDF 1.7の仕様は元々Adobe社が作成したものですが、これがISO 32000-1の国際標準にもなっています。Adobeのサイトでダウンロードできますので、仕様の詳しい部分を知りたい場合にはこちらもご覧ください。

前に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については正しい名称がわからないし、公開されないままなので、とりあえずで付けています。また何か情報得られたら、こちらで紹介したいと思います。