PDF電子署名入門

更新日: 2021/8/5

はじめに

この文書は、主にこれからPDF 電子署名をシステムに組み込んで使うことを検討されている方を対象に、PDF電子署名についての基礎的な情報を提供することを目的としています。

PDFの署名機能は、電子署名機能を元にしてPDF独自の機能を付け加えています。このためPDF電子署名を理解して使いこなすには、電子署名の機能とPDFの機能の両方について理解する必要があります。

そこで、この文書では、最初に電子署名全般を解説し、次にPDF電子署名について解説します。電子署名一般について詳しい方は、電子署名全般の部分を飛ばして、PDF電子署名の概要の説明にお進みください。

電子署名の概要

最初に、電子署名とはどういうものかについて簡単に整理します。

電子署名とは何か?

フリー百科事典『ウィキペディア(Wikipedia)』の「電子署名」は次のように記述しています。

  • 電子的な文書に付与する徴象であり、紙文書での印やサインに相当する機能を意図したものである。
  • 電子署名を実現する仕組みとしては、公開鍵暗号方式に基づくデジタル署名が有力である。日本では電子署名及び認証業務に関する法律(電子署名法)にて、RSA、DSA、ECDSA の3方式を指定している。いずれも公開鍵暗号方式に基づく方式である。

この文章からは次のことが分かります。

  • 電子署名には、「公開鍵暗号方式」に基づくものと、「そうでないもの」がある。
  • 公開鍵暗号方式が有力である。
  • 公開鍵暗号方式の中では、RSA、DSA、ECDSA の3種類が日本では法的に認められている。

PDF電子署名の標準仕様は、公開鍵暗号方式を採用しています。そこで、以下の説明では、「公開鍵暗号方式」のみを取り上げます。

公開鍵暗号方式による秘密情報通信

公開鍵暗号方式とは、公開鍵と秘密鍵というペアの鍵を使って暗号化した情報のやり取りを行う方式です。公開鍵で暗号化した情報は、それと対になる秘密鍵のみで解読ができるという特性があります。

この特性を使って、機密情報通信を次のように実現します。

  1. 機密情報を受信する人は、公開鍵と秘密鍵を生成するツールを使って、自分独自の公開鍵と秘密鍵を作ります。公開鍵は情報源となる相手に渡します。秘密鍵は他者に見せないように保持しておきます。
  2. 機密情報を送信する人(情報源となる人)は、送信したい相手の公開鍵を使って、送りたい機密情報を暗号化します。そして、暗号化された情報を送りたい相手に送信します。
  3. 機密情報を受信した人は、その情報を自分の秘密鍵を使って暗号解読します。

送り手とは別の人の公開鍵で間違って暗号化してしまえば、送りたい相手以外に情報が漏れてしまいますので、公開鍵が情報を送りたい相手のものであることを一意的に保証する仕組みが必須です。

以上は、署名ではなく暗号化で情報通信内容の秘匿を行なうための方式についての説明です。

電子署名での公開鍵暗号方式の使い方

電子署名では、情報通信内容の秘匿目的の使い方とは鍵の使用順を変えて、「秘密鍵」で署名をして、「公開鍵」を署名の確認に用います。

「秘密鍵」は、その署名した人だけが持っている鍵です。署名対象文書を、その署名者固有の「秘密鍵」で暗号化したデータ(署名データ)は、署名者のみにしか作成することができません。

署名データを受け取った受信者が、その「秘密鍵」と対になる「公開鍵」で署名データの暗号を解いて、署名対象文書に戻すことができることは、すなわち、その署名データは、「秘密鍵」の所有者によって作られたことを証明できるということになります。

また、署名データと署名対象文書を受信した人が、署名データから暗号を解いて作り出した署名対象文書のコピーと、受信した生の署名対象文書を比較して一致しているかどうか調べることで、受信した署名対象文書が改竄されていないかどうか確認できます。

このように、情報の秘密を守るための暗号化方式を、送信者を認識する署名とデータの改竄有無の検証にも使うことができます。

ハッシュ・アルゴリズム

公開鍵暗号方式は、暗号処理に時間がかかるため、署名対象文書を丸ごと処理すると署名・復元の計算時間が膨大になります。そこで、電子署名では署名対象文書から計算したハッシュ値という要約値を署名対象文書の代わりに暗号化します。

このハッシュ値の計算に使う算法をハッシュ・アルゴリズムと言います。署名対象文書をハッシュ関数(ハッシュ・アルゴリズムを実装した関数)に入力し、出力されたデータがハッシュ値です。ダイジェスト値、またはフィンガー・プリントと呼ぶこともあります。

ハッシュ値は署名対象文書に比べて非常に小さいのですが、特にハッシュ・アルゴリズムには次のような特性が要求されます。

要求条件:「ふたつの文書が異なっているなら、それから計算した二つのハッシュ値も異なっている。」

この要求条件が成立すれば、その対偶:「ふたつのハッシュ値が同じであれば、ふたつのもとの文書は同じ」が成立します。

但し、これを任意の文書について達成するのは不可能なことは明らかです。仮に元の文書が、1万文字(2バイト/文字)とすると2万バイトになります。2万バイトの情報の改竄パターンは、意味のある情報になるかどうかを別にすると、最大で2の8万乗-1だけあります。ハッシュ値を128バイトとしますと、ハッシュ値で表現できるパターンは2の(128×8)乗です。ですので1ハッシュ値あたり大体2の78乗回の衝突が起きるはずです。しかし、衝突が起きる確率は極めて小さい(2の78乗÷2の8万乗)のです。

ハッシュ・アルゴリズムで計算したハッシュ値は衝突が不可避と思いますが、ハッシュ値が同じになる(衝突が起きる)ような改竄方法を短時間で計算できなければ実用的と言えるでしょう。短時間で計算できるようになれば、そのハッシュ・アルゴリズムは脆弱となります。

暗号の専門家の会議では、ハッシュ・アルゴリズムの脆弱性がいろいろと報告されています。

ハッシュ・アルゴリズムにはMD2、MD4、MD5、SHAなどいろいろあります。SHAにはSHA-1、SHA-2(SHA-224、SHA-256、SHA-384、SHA-512)があります。現在のところ、電子署名ではハッシュ・アルゴリズムとしてSHA-1が普及しています。なお、電子署名でMD5を使用していることもありますが、MD5には脆弱性が報告されており、早期に使うのをやめる方が良いでしょう。

タイムスタンプのような新しい技術では、新しい技術を採用するのが比較的容易なため日本の商用タイムスタンプではハッシュ・アルゴリスムとしてより安全性の高いSHA-512を採用しています。

署名対象文書の署名作成・交換・検証

ここまでのまとめとして、公開鍵暗号方式による電子署名とその検証のあら筋は次のようになります。

  • 署名者(A)は署名対象文書からハッシュ値Aを計算し、A個人の秘密鍵を用いて暗号化し、署名データを作成します。
  • Aは、署名対象文書と署名データ、公開鍵などの情報を受取人(B)に送ります。交換用のファイル形式としては、PKCS#7またはCMS(Cryptgraphic Message Syntax)を使います。CMSはPKCS#7を拡張した標準です。
  • Bは署名データを公開鍵で暗号解除してハッシュ値Aを取り出します。また、署名対象文書から、Aと同じハッシュ・アルゴリズムを用いてハッシュ値Bを作成します。
  • ハッシュ値Aとハッシュ値Bが一致していれば、Bが受信した署名対象文書は、Aが署名したものと同じものと判断できます。
公開鍵暗号方式による電子署名とその検証の流れを表した図

電子証明書

Bの手元には、署名対象文書、署名データ、公開鍵があります。署名データを復元したハッシュ値Aが、入手した署名対象文書から計算したハッシュ値Bと一致すれば、署名対象文書は変更されてないことがわかりますが、署名者がAであるとは特定できません。別のCがAの名を騙って署名して、Cの公開鍵をAのものであると偽ってBに渡す、という事態が生じる可能性があるからです。

公開鍵の所有者を特定するために使うものが公開鍵の証明書(公開鍵証明書とも言います、ここでは「電子証明書」という用語を使用します。)です。上に述べましたように、秘密鍵-公開鍵のペアだけでは、署名者を本当に特定することはできません。電子署名での本人認証は電子証明書の役割です。

電子証明書を発行する機関を認証機関(厳密には登録機関と認証局)と言います。認証機関を通じて、電子証明書の信用を保証する社会的な仕組みを公開鍵暗号基盤(PKI:Public Key Infrastructure)と言います。

登録機関は、証明書の発行を希望する者が本人であることを充分な証拠に基づいて確認し、認証局(CA)が公開鍵を含む電子証明書を作成します。また、この証明書の信憑性を保証するために、電子証明書にはCAの秘密鍵で署名がなされます。このCAの署名があることで、証明書が改竄されていないことが保証されます。

電子証明書の形式としては、X.509標準形式が広く使われます。

PFX/PKCS#12ファイル

秘密鍵と電子証明書を一つのファイルとしてやり取りする形式として、Personal Information Exchange (PFX)形式とそれを元にしたPKCS#12ファイル形式があります。WindowsではPersonal Information Exchange - PKCS#12ファイル(拡張子はPFX)と表示しており、明確に区別していないようです。そこで、ここではPFX/PKCS#12ファイルと呼びます。

PFX/PKCS#12ファイルは秘密鍵を含んでいますので、パスワードで保護します。このパスワードは漏洩しないように充分な注意をもって管理しなければなりません。

ルート証明書

ある電子証明書の信用は、それを発行したCAの電子証明書(CA証明書)の信用に依存します。

X.509形式の電子証明書には、発行元(Issuer)と発行先(Subject)の項目があり、そこに、証明書を発行した機関と発行先の機関の名前が書かれています。

これにより、CAの信用の鎖を遡ることができます。最後まで遡るとルートCAにたどり着きます。ルートCAの証明書(ルート証明書)は、他のCAが署名したものでなく、自分自身で署名したものになります。

発行元と発行先が同じになっている電子証明書のことを、自己署名証明書と言います。

ルート証明書は、必ず自己署名証明書になります。なお、自分で公開鍵と秘密鍵を生成して、自分の公開鍵に自分の秘密鍵で署名したX.509形式の電子証明書を作れば、これも自己署名証明書になります。

ルート証明書は自己署名証明書ですので、その信用の確認は、別途、行なう必要があります。

ルート証明書の信用の確認の方法は、例えば、日本の政府認証基盤(GKPI)であれば、証明書のハッシュ値(フィンガープリント)が公開されていますので、それを確かめるという方法もあります。

海外では、ルートCAとして認定する審査基準のひとつに、米国公認会計士協会 (AICPA) が用意している「WebTrust for Certification Authorities」 プログラムがあります。

Microsoftの Windows XP、Microsoft Windows Server 2003 および Windows Vista では、Windows Update Web サイトにWebTrust、および同等の基準の審査を通ったCAのルート証明書を自動的にチェックしダウンロードする仕組み「Microsoft ルート証明書プログラム」が用意されています。

Microsoftルート証明書プログラムの認定メンバーは次にあります。
http://support.microsoft.com/kb/931125

Windows証明書ストア

Microsoft Windowsには、Windows証明書ストアという電子証明書を一括して管理する機能があります。

上述のようにマイクロソフトはルート証明書の更新プログラムを提供しており、これをインストールするとWindows証明書ストアに、マイクロソフトの基準で認められたCAのルート証明書が登録されます。

Windows証明書ストアでは登録されている証明書が幾つかの分類(タブ)に分かれています。主なものには次の種類があります。

  • 対応する秘密鍵をもつ証明書(個人の電子証明書)
  • 対応する秘密鍵を持たない証明書(他人の電子証明書)
  • 信用できるルート証明書

なお、Windows証明書ストアの信用できるルート証明書は、自分でも手動で追加・削除ができます。一部のCAやタイムスタンプ局では手動でルート証明書の追加を要求します。その際には、ルート証明書が充分に信用できるかの注意が必要です。

文書に電子署名をするには、対応する秘密鍵をもつ証明書が必要です。対応する秘密鍵を持たない証明書を指定して署名することはできません。

受け取った文書の電子署名についている署名者の電子証明書を発行したCAのルート証明書がWindows証明書ストアに登録されていればその電子証明書を信用することができます。

電子証明書の失効確認

電子証明書には有効期限があります。また、有効期限内であっても、秘匿するべき秘密鍵が漏洩してしまったり、証明書に登録された内容が変更になり、無効となることがあります。証明書が無効になった時、証明書所有者は、CAに証明書の失効申請を出さなければなりません。

CAは失効した証明書の情報を次のいづれかの方法で提供しており、インターネットを通じて、証明書の失効状態を確認することができます。

  • 証明書失効リスト(CRL) — CAのサーバで公開されている失効した証明書の一覧データ。CRLは、一定期間(通常は1日~2日間)で更新される。)
  • オンライン証明書状態プロトコル(OCSP: Online Certificate Status Protocol) — 証明書のシリアル番号を指定して、CAのOCSPサーバにその時点での証明書の有効・無効を問い合わせる方式

証明書の失効情報は、日本ではCRLで提供されていることが多く、OCSPで提供されていることは少ないようです。なお、CRLとOCSPの両方を提供しているCAもあります。

タイムスタンプとは何か?

電子データに電子署名をすると、それに付随する証明書により誰が署名したのかを確認することができるようになります。しかし、その署名がいつなされたのかは、電子署名だけでは確定することができません。

実際のビジネスでは、「いつ」、ということが非常に重要になるケースが多いでしょうから、電子書類にタイムスタンプをつけるサービスは重要です。

タイムスタンプ・プロトコルに関する技術調査によりますと、欧米では1990年代の中ごろからタイムスタンプサービスが立ち上がり、2000年前後にタイムスタンプの標準化が図られました。

2001年には電子署名に基づくタイムスタンプの標準であるRFC3161ができています。
RFC3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)

RFC3161のタイムスタンプ方式を簡単にまとめますと次のようになります。

  • タイムスタンプを付けたい文書のハッシュ値を計算する。
  • ハッシュ値を、信用できるTSA(タイムスタンプ・オーソリティ)に送信する。
  • TSAは、ハッシュ値に、TSAの秘密鍵で電子署名をして、電子署名した署名データを、要求元に送り返す。
  • 以上で、文書のタイムスタンプデータが出来上がります。これを文書と関係つけて保存したものがタイプスタンプ付き文書です。

日本において公的に認められるタイムスタンプ局は、(財)データ通信協会の認定を受けた業者となります。公的な認定を受けたタイムスタンプ局の利用は一般に有償であり、利用には別途でライセンスを取得する必要があります。

PDF電子署名の概要

PDF電子署名は、電子署名を利用して、更に様々なPDF独自の追加機能を標準として規定することで、PDF独自の便利さを実現したものです。

PDF電子署名は、PDFファイルを対象として署名とタイムスタンプ(オプション)を付けることができます。そして、署名対象PDFに加えて、署名データ、証明書などの一式を取り込んだ新しいPDFを作成します。

PDF電子署名の標準

PDF電子署名は、PDFの国際標準「ISO 32000-1:2008 Document management -- Portable document format -- Part 1: PDF 1.7」(ISO 32000-1)」に規定されているものが標準です。

主に以下の項に規定されています。

  • ISO 32000-1 12.7 Interactive Forms, 主に12.7.4.5 Signature Fields pp. 446~451(署名フィールド)
  • ISO 32000-1 12.8 Digital Signatures pp. 466~478(電子署名)

ご参考:
☞ 「アクロバットでなくてもPDFができるのはなぜ?」

ISO 32000-1には、PDFに署名した結果として、新しいPDFをどのように作成するかが規定されています。署名後のPDFをISO 32000-1標準に準拠するように作成すれば、同じ標準に準拠する様々なプログラムで、同一の署名済みPDFを相互運用できます。

仕様の変遷の項で見ますように、PDF電子署名の標準仕様が現在の形になりましたのは比較的最近です。

PDF電子署名の機能・特徴

次にPDF電子署名の主な機能とその特徴を簡単に紹介します。なお、以下の説明は、PDF電子署名の機能を全て網羅しているわけではありません。「アンテナハウス PDF 電子署名モジュール」が提供している機能を中心としています。

署名フィールドと署名の外観

署名は対話フォーム(AcroForm)の一種である「署名フィールド」として定義されており、署名フィールドを作って署名するという2段階の方式になります。例えば、「PDF電子署名モジュール」では、次のようにして署名フィールドを作成できます(コマンドラインでの利用例)。

>PdsCmd -sign -field
        -sf Field1 1 100 100 200 200 
        -sf Field2 1 210 210 310 310 
        -sf Field3 1 320 320 420 420 
        -in PDF-test.pdf
        -out PDF-test-field.pdf

これをAdobe Reader 9で表示しますと、次のようになります。

電子署名は、デジタルデータで眼に見えないものです。PDFでは署名に外観をつけることができます。この署名の外観は、署名フィールドに付随する注釈機能(Widget注釈)として実現されています。

未署名の署名フィールドに後から署名を追加することができます。上の例で作成した書名フィールド3(名称:Field3)に、署名を付ける例を示します。

>PdsCmd -sign -add Field3 
        -ap-type wgt 
        -sign-type nml 
        -finger-print 37C2C014D13B9BC113B01103FF6D1C25E96A7EFD 
        -graphic-type file 
        -file-path Tanaka.gif 
        -text-flag "name date reason location issuer label" 
        -in PDF-test-field.pdf 
        -out Field3-Signed.pdf

署名を付けたPDFをAdobe Reader 9で表示したのが次の図です。

こうした機能を使うことにより、署名したい位置に未署名署名フィールドのあるPDFを作成して相手に渡し、指定位置に、相手の署名をつけて戻して貰うこともできます。

外観を表示する領域をもたない署名(不可視署名)も可能です。

PDFに電子署名を付けると、PDF全体を署名対象としてハッシュ値を計算し、それを署名者の秘密鍵で暗号化します。暗号化後のデータや署名者の証明書などの情報は、PKCS#7として作成した上でHEX値に変換して署名済みPDFの内部に保存されます。

署名の種類:普通署名とMDP署名機能

PDF電子署名には普通署名とMDP署名(Acrobat の用語では証明用署名)という2種類があります。MDP署名は普通署名の機能に加えて、さらに次の特徴があります。

  • 文書に最大でも一つしか存在することができず、従って、MDP署名があるとしますと、必ず一番最初の署名となります。
  • 署名後のPDFに対する変更許可を次の3つのどれかに制限します。
    1. 変更を許可しない
    2. フォームフィールドの入力と署名フィールドに署名を許可
    3. 注釈の作成、フォームフィールドの入力と署名フィールドに署名を許可

例えば、配布するPDFにフォーム・フィールドと署名フィールドを予め作成しておき、MDP署名で「フォームフィールドの入力と署名フィールドに署名を許可」を設定すると、受け取った人はPDFのフォームフィールドにデータを入力することと署名フィールドに署名ができますが他の操作はできません。

次の例は、上記PDFの署名フィールド(Field3)にMDP署名(署名後変更不可に設定)を付けた例です。

>PdsCmd -sign -add Field3 
          -ap-type wgt 
          -sign-type mdp 
          -mdp-type chg 
          -finger-print 37C2C014D13B9BC113B01103FF6D1C25E96A7EFD 
          -graphic-type file  
          -file-path Tanaka.gif 
          -text-flag "name date reason location issuer label" 
          -in PDF-test-field.pdf 
          -out Field3-MDP-Signed-1.pdf

Adobe ReaderではPDFが「証明されています」と表示されます。このPDFは、MDP署名機能を実装した編集ソフトでは変更することができません。

署名フィールド(Field3)にMDP署名(署名後変更不可に設定)を付けたPDFを、Adobe Readerで表示した図

増分更新と署名

PDF電子署名はPDFの増分更新機能と深い関係があります。

PDFは適当なツールを使えば内容を編集(削除、追加、変更)したり、しおりをつけたりといった、様々な変更を施すことができます。そのような変更を行った結果をPDFファイルに保存するときの方法に「増分更新」という保存方法があります。

増分更新とは、変更前のPDFファイルの内容をそのままに維持して、変更前のファイルの最後に変更した内容を追加し、新しいPDFファイルを作る方法です。

Acrobat 8では、PDFを編集して「上書き保存」すると増分更新となります。「名前をつけて保存」すると増分更新ではなく、新しい内容(編集前のPDFの内容が維持されない)になるようです。増分更新では、編集前の古い世代のPDFがそのまま保持され、PDFファイルの最後を示していた%%EOFの後ろに、変更した内容が追加されます。

バイナリエディタで、%%EOFを区切りにして、増分更新で追加された部分を削除しますと、元のオリジナルPDFに戻ります。つまり、増分更新とは、変更前のPDFをそのまま保持して、ファイルの最後に変更後のオブジェクトを追記していく保存方法です。

PDFに署名をし、その後の変更を増分更新とすることで、署名済みの部分を変更することなく、新しい情報を追加していくことができます。

PDFに署名後に、署名対象部分を変更しますと、署名部分が改竄されたという状態になります。これに対して、増分更新すれば、署名部分は保護されます。この結果、電子署名したPDFについては、旧版のPDFを取り出すことができることになります。

署名バージョン

PDFに対して同時に複数の署名ができるかどうかという質問を時々頂きますが、PDF電子署名の仕様上、同時に複数の署名はできません。

PDFでは、増分更新の機能を使って文書に順番に複数の署名をすることになります。署名する毎にPDFが増分更新されますが、これを署名バージョンと言います。以下に簡単に実験してみます。

PDFを作成して、それに普通の電子署名をします。ついで、さらに二つ目の電子署名をします。次のようになります。

左から電子署名のないPDF、普通に電子署名をひとつしたPDF、2つ電子署名をしたPDFを並べた図

最初に署名をした段階での署名の検証状態は次のようになっています。

○最初の署名をした段階での電子署名の検証状態
登録した陰影と、緑色のペンマークが表示された電子署名の図
電子署名のプロパティ内のメッセージ内容が表示されています。「正当性の概要」として、「文書は、この署名が適用された後、変更されていません。」、「この文書は、現在のユーザによって署名されています。」
プロパティ
○二つ目の署名をした段階での電子署名の検証状態
一つ目の署名には、登録した陰影と注意喚起マーク、その隣に付与した当時の署名内容が表示され、2つ目の署名には陰影はなく、署名者の名前と緑色のペンマーク、署名内容が表示されている図
  • 一つ目の署名のプロパティ
    正当性の概要。2つのマークとそれぞれの詳細が記載されています。1、注意喚起マーク。内容。この文書は、この署名が適用されたバージョンについては変更されていませんが、その後変更が加えられています。2、緑ペンマーク。この文書は現在のユーザーによって署名されています。
  • 二つ目の署名のプロパティ
    正当性の概要。「文書は、この署名が適用された後、変更されていません。」、「この文書は、現在のユーザによって署名されています。」

二つ目の署名をした段階で、一つ目の署名は署名が適用された後に変更されたという状態に変わります。

PDFファイルの内部は次のようになっています。

PDFの増分更新のイメージ図

署名の対象範囲は、署名データ以外のPDF全体です。最初の署名をした段階で、署名前PDF全体に対する署名辞書が作成されて、その中に署名データが作られます。

次の署名は最初の署名辞書や署名データまでを含めた範囲を署名対象範囲としています。二つ目の署名辞書や署名データは増分更新として作成されます。

ちなみに増分更新部分(最初の%%EOFより後ろ)を削除してみます。

増分更新部分が選択された状態のイメージ図

そうして、PDFファイルに保存しますと、最初の署名がなされた状態に完全に元に戻ります。

署名の表示・検証

PDF電子署名の表示・検証には、Adobe Readerを使うと便利ですが、Adobe Readerでは署名の外観の機能を使って、署名の状態(未署名、署名済み、署名の種類、検証状態)を表示することができます。さらに署名の検証状態をアイコンで表しています。

「Digital Signature User Guide」やAdobe Readerのヘルプを見ますとアイコンには次のようなものがあります。

  • 20070514-1.PNG:未署名の署名フィールド
  • 20070514-2.PNG:PDF が証明済みであること、つまり有効な証明用署名を含んでいることを示します。
  • 20070514-3.PNG:署名が有効である。有効な証明書を使って署名されており、署名後に不正な変更がないことを示します。
  • 20070514-4.PNG:署名が無効である。証明書が不正か、それとも、文書に許可されない変更がなされていることを示します。
  • 20070514-5.PNG:署名後に文書が変更されている。証明書が検証できず、かつ、文書に予め許可された変更がなされているということを示します。
  • 20070514-6.PNG:信用できる証明書の一覧に署名者の証明書がないために署名が検証できなかった。証明書を検証することができないか、文書の検証を完了できなかったことを示します。
  • 20070514-7.PNG:証明書の信用を検証できず、かつ、文書が署名後に変更されていることを示します。
  • 20070514-8.PNG:証明書の信用を検証できず、かつ、文書は署名後に変更されていないことを示します。

署名ハンドラ

PDFに電子署名を付けるツールは署名時にPDF内に署名辞書と署名データを作成します。署名辞書のFilterキーには、その署名を検証するための望ましい署名ハンドラを登録します。また、署名辞書のSubFilterキーには、署名データなどの形式を登録します。

PDF電子署名を検証するツールは、PDFの署名辞書のFilterキーとSubFilterキーを使って、検証に用いる署名ハンドラを決定します。

ISO 32000-1では、SubFilterとしてadbe.pkcs7.detachedを設定することが推奨されています。Adobe Readerにはこれをサポートする署名ハンドラを内蔵していますので、PDF電子署名ツールが、FilterキーとSubFilterキーを適切に設定すれば、Adobe Readerで電子署名を検証することができます。

PDF電子署名は、広く普及しているAdobe Readerで表示しながら、同時に署名やタイムスタンプの検証ができることが大きなメリットと言えます。

PDF電子署名の仕組み

仕様の変遷

PDFの電子署名はPDF1.3より規定されました。しかし、PDFのバージョンが上がるに従って機能が追加されています。ISO 32000-1で規定されている署名関連機能のPDFのバージョンとの関係は次の表のようになってます。

PDF 1.6までは、標準で規定されている電子署名機能が不足していたため、サードパーティが独自仕様の署名ハンドラを作成して機能不足を補うことが必要でした。しかし、PDF 1.6(商用タイムスタンプを使うならPDF 1.7)からISO 32000-1に規定する標準仕様だけで実用的なレベルに達していると言えます。

項目 PDF 1.3 PDF 1.4 PDF 1.5 PDF 1.6 PDF 1.7
署名フィールド
署名の外観
署名辞書 普通署名
MDP署名 - -
互換性
署名アプリケーション情報
(Prop_Build)
- -
タイムスタンプ - - -
adbe.pkcs7.detached
ハッシュ・アルゴリズムサポート
SHA1 - - SHA256 SHA384 / SHA512 / RIPEMD160

互換性

PDF電子署名の仕様が上のように変遷してきたことにより、標準ツールが準拠するPDFバージョンによっては互換性の問題が発生する可能性があることを意味します。

電子署名のみの時はPDF1.6以降で現在の仕様と同等であり、日本商用タイムスタンプは、特別なプラグインを使わないならPDF 1.7以降で利用可能です。PDF 1.5以前のPDF電子署名はPDF 1.7と互換でない場合があります。

ちなみに、Acrobat 8/9でPDF 1.5 以前のPDFに電子署名を付けると、それが可能な場合は、自動的にPDFのバージョンを1.6に変更してしまっています。

MDP署名機能はPDF Reference 1.5で導入されていますが、PDF Reference 1.5で規定されたMDP署名の実現方法は、PDF Reference 1.6では変更になり、ISO 32000-1では削除されてしまいました。このため、事実上、MDP署名はPDF 1.6以降でないと使えません。

上の表に見るとおり、adbe.pkcs7.detachedの機能はPDFのバージョンと共に強化されており、これは、Adobe Readerに内蔵される標準署名ハンドラの機能に対応しています。Adobe Reader 8以降では、SHA2を使う日本の商用タイムスタンプの検証も可能になっています。Reader 7以前では、商用タイムスタンプの検証には、タイムスタンプ局が提供するプラグインが必要です。

スペース