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もあります。

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

署名は対話フォーム（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注釈）として実現されています。

未署名の署名フィールドに後から署名を追加することができます。上の例で作成した書名フィールド３（名称：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署名機能を実装した編集ソフトでは変更することができません。

増分更新と署名

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全体です。最初の署名をした段階で、署名前PDF全体に対する署名辞書が作成されて、その中に署名データが作られます。

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

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

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

署名の表示・検証

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

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

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

署名ハンドラ

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で表示しながら、同時に署名やタイムスタンプの検証ができることが大きなメリットと言えます。