電子署名をシステムに組み込んで使うことを検討されている方を対象に、PDF電子署名についての基礎的な情報を提供することを目的としています。PDFの署名機能は、電子署名機能を元にしてPDF独自の機能を付け加えています。このためPDF電子署名を理解して使いこなすには、電子署名の機能とPDFの機能の両方について理解する必要があります。そこで、この文書では、最初に電子署名全般を解説し、次にPDF電子署名について解説します。電子署名一般について詳しい方は、電子署名全般の部分を飛ばして、PDF電子署名の概要の説明にお進みください。最初に、電子署名とはどういうものかについて簡単に整理します。電子署名とは何か?フリー百科事典『ウィキペディア(Wikipedia)』の「電子署名」は次のように記述しています。電子的な文書に付与する徴象であり、紙文書での印やサインに相当する機能を意図したものである。電子署名を実現する仕組みとしては、公開鍵暗号方式に基づくデジタル署名が有力である。3方式を指定している。いずれも公開鍵暗号方式に基づく方式である。この文章からは次のことが分かります。基づくものと、「そうでないもの」がある。公開鍵暗号方式が有力である。3種類が日本では法的に認められている。PDF電子署名の標準仕様は、公開鍵暗号方式を採用しています。公開鍵と秘密鍵というペアの鍵を使って暗号化した情報のやり取りを行う方式です。公開鍵で暗号化した情報は、それと対になる秘密鍵のみで解読ができるという特性があります。この特性を使って、機密情報通信を次のように実現します。機密情報を受信する人は、公開鍵と秘密鍵を生成するツールを使って、自分独自の公開鍵と秘密鍵を作ります。公開鍵は情報源となる相手に渡します。秘密鍵は他者に見せないように保持しておきます。機密情報を送信する人(情報源となる人)は、送信したい相手の公開鍵を使って、送りたい機密情報を暗号化します。暗号化された情報を送りたい相手に送信します。機密情報を受信した人は、その情報を自分の秘密鍵を使って暗号解読します。送り手とは別の人の公開鍵で間違って暗号化してしまえば、送りたい相手以外に情報が漏れてしまいますので、公開鍵が情報を送りたい相手のものであることを一意的に保証する仕組みが必須です。以上は、署名ではなく暗号化で情報通信内容の秘匿を行なうための方式についての説明です。電子署名での公開鍵暗号方式の使い方電子署名では、情報通信内容の秘匿目的の使い方とは鍵の使用順を変えて、「秘密鍵」で署名をして、「公開鍵」を署名の確認に用います。「秘密鍵」は、その署名した人だけが持っている鍵です。署名対象文書を、その署名者固有の「秘密鍵」で暗号化したデータ(署名データ)は、署名者のみにしか作成することができません。署名データを受け取った受信者が、その「秘密鍵」と対になる「公開鍵」で署名データの暗号を解いて、署名対象文書に戻すことができることは、すなわち、その署名データは、「秘密鍵」の所有者によって作られたことを証明できるということになります。署名データと署名対象文書を受信した人が、署名データから暗号を解いて作り出した署名対象文書のコピーと、受信した生の署名対象文書を比較して一致しているかどうか調べることで、受信した署名対象文書が改竄されていないかどうか確認できます。このように、情報の秘密を守るための暗号化方式を、送信者を認識する署名とデータの改竄有無の検証にも使うことができます。ハッシュ・アルゴリズム公開鍵暗号方式は、暗号処理に時間がかかるため、署名対象文書を丸ごと処理すると署名・復元の計算時間が膨大になります。そこで、電子署名では署名対象文書から計算したハッシュ値という要約値を署名対象文書の代わりに暗号化します。このハッシュ値の計算に使う算法をハッシュ・アルゴリズムと言います。署名対象文書をハッシュ関数(ハッシュ・アルゴリズムを実装した関数)に入力し、出力されたデータがハッシュ値です。ダイジェスト値、またはフィンガー・プリントと呼ぶこともあります。ハッシュ値は署名対象文書に比べて非常に小さいのですが、特にハッシュ・アルゴリズムには次のような特性が要求されます。要求条件:「ふたつの文書が異なっているなら、それから計算した二つのハッシュ値も異なっている。」この要求条件が成立すれば、その対偶:「ふたつのハッシュ値が同じであれば、ふたつのもとの文書は同じ」が成立します。これを任意の文書について達成するのは不可能なことは明らかです。仮に元の文書が、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)に送ります。Syntax)を使います。CMSはPKCS#7を拡張した標準です。Bは署名データを公開鍵で暗号解除してハッシュ値Aを取り出します。署名対象文書から、Aと同じハッシュ・アルゴリズムを用いてハッシュ値Bを作成します。ハッシュ値Aとハッシュ値Bが一致していれば、Bが受信した署名対象文書は、Aが署名したものと同じものと判断できます。データ、公開鍵があります。署名データを復元したハッシュ値Aが、入手した署名対象文書から計算したハッシュ値Bと一致すれば、署名対象文書は変更されてないことがわかりますが、署名者がAであるとは特定できません。別のCがAの名を騙って署名して、Cの公開鍵をAのものであると偽ってBに渡す、という事態が生じる可能性があるからです。公開鍵の所有者を特定するために使うものが公開鍵の証明書(公開鍵証明書とも言います、ここでは「電子証明書」という用語を使用します。上に述べましたように、秘密鍵-公開鍵のペアだけでは、署名者を本当に特定することはできません。電子署名での本人認証は電子証明書の役割です。電子証明書を発行する機関を認証機関(厳密には登録機関と認証局)と言います。Infrastructure)と言います。登録機関は、証明書の発行を希望する者が本人であることを充分な証拠に基づいて確認し、認証局(CA)が公開鍵を含む電子証明書を作成します。この証明書の信憑性を保証するために、電子証明書にはCAの秘密鍵で署名がなされます。このCAの署名があることで、証明書が改竄されていないことが保証されます。電子証明書の形式としては、X.509標準形式が広く使われます。(PFX)形式とそれを元にしたPKCS#12ファイル形式があります。PKCS#12ファイル(拡張子はPFX)と表示しており、明確に区別していないようです。そこで、ここではPFX/PKCS#12ファイルと呼びます。PFX/PKCS#12ファイルは秘密鍵を含んでいますので、パスワードで保護します。このパスワードは漏洩しないように充分な注意をもって管理しなければなりません。ルート証明書ある電子証明書の信用は、それを発行したCAの電子証明書(CA証明書)の信用に依存します。X.509形式の電子証明書には、発行元(Issuer)と発行先(Subject)の項目があり、そこに、証明書を発行した機関と発行先の機関の名前が書かれています。これにより、CAの信用の鎖を遡ることができます。最後まで遡るとルートCAにたどり着きます。ルートCAの証明書(ルート証明書)は、他のCAが署名したものでなく、自分自身で署名したものになります。発行元と発行先が同じになっている電子証明書のことを、自己署名証明書と言います。ルート証明書は、必ず自己署名証明書になります。自分で公開鍵と秘密鍵を生成して、自分の公開鍵に自分の秘密鍵で署名したX.509形式の電子証明書を作れば、これも自己署名証明書になります。ルート証明書は自己署名証明書ですので、その信用の確認は、別途、行なう必要があります。ルート証明書の信用の確認の方法は、例えば、日本の政府認証基盤(GKPI)であれば、証明書のハッシュ値(フィンガープリント)が公開されていますので、それを確かめるという方法もあります。プログラムがあります。ルート証明書プログラム」が用意されています。Microsoftルート証明書プログラムの認定メンバーは次にあります。Windowsには、Windows証明書ストアという電子証明書を一括して管理する機能があります。上述のようにマイクロソフトはルート証明書の更新プログラムを提供しており、これをインストールするとWindows証明書ストアに、マイクロソフトの基準で認められたCAのルート証明書が登録されます。Windows証明書ストアでは登録されている証明書が幾つかの分類(タブ)に分かれています。主なものには次の種類があります。対応する秘密鍵をもつ証明書(個人の電子証明書)対応する秘密鍵を持たない証明書(他人の電子証明書)信用できるルート証明書なお、Windows証明書ストアの信用できるルート証明書は、自分でも手動で追加・削除ができます。一部のCAやタイムスタンプ局では手動でルート証明書の追加を要求します。その際には、ルート証明書が充分に信用できるかの注意が必要です。文書に電子署名をするには、対応する秘密鍵をもつ証明書が必要です。対応する秘密鍵を持たない証明書を指定して署名することはできません。受け取った文書の電子署名についている署名者の電子証明書を発行したCAのルート証明書がWindows証明書ストアに登録されていればその電子証明書を信用することができます。有効期限内であっても、秘匿するべき秘密鍵が漏洩してしまったり、証明書に登録された内容が変更になり、無効となることがあります。証明書が無効になった時、証明書所有者は、CAに証明書の失効申請を出さなければなりません。CAは失効した証明書の情報を次のいづれかの方法で提供しており、インターネットを通じて、証明書の失効状態を確認することができます。CAのサーバで公開されている失効した証明書の一覧データ。CRLは、一定期間(通常は1日~2日間)で更新される。証明書の失効情報は、日本ではCRLで提供されていることが多く、OCSPで提供されていることは少ないようです。CRLとOCSPの両方を提供しているCAもあります。タイムスタンプとは何か?電子データに電子署名をすると、それに付随する証明書により誰が署名したのかを確認することができるようになります。その署名がいつなされたのかは、電子署名だけでは確定することができません。実際のビジネスでは、「いつ」、ということが非常に重要になるケースが多いでしょうから、電子書類にタイムスタンプをつけるサービスは重要です。タイムスタンプ・プロトコルに関する技術調査によりますと、欧米では1990年代の中ごろからタイムスタンプサービスが立ち上がり、2000年前後にタイムスタンプの標準化が図られました。2001年には電子署名に基づくタイムスタンプの標準であるRFC3161ができています。(TSP)RFC3161のタイムスタンプ方式を簡単にまとめますと次のようになります。タイムスタンプを付けたい文書のハッシュ値を計算する。ハッシュ値を、信用できるTSA(タイムスタンプ・オーソリティ)に送信する。TSAは、ハッシュ値に、TSAの秘密鍵で電子署名をして、電子署名した署名データを、要求元に送り返す。以上で、文書のタイムスタンプデータが出来上がります。これを文書と関係つけて保存したものがタイプスタンプ付き文書です。日本において公的に認められるタイムスタンプ局は、(財)データ通信協会の認定を受けた業者となります。公的な認定を受けたタイムスタンプ局の利用は一般に有償であり、利用には別途でライセンスを取得する必要があります。PDF電子署名の概要PDF電子署名は、電子署名を利用して、更に様々なPDF独自の追加機能を標準として規定することで、PDF独自の便利さを実現したものです。PDF電子署名は、PDFファイルを対象として署名とタイムスタンプ(オプション)を付けることができます。署名対象PDFに加えて、署名データ、証明書などの一式を取り込んだ新しいPDFを作成します。32000-1)」に規定されているものが標準です。以下の項に規定されています。32000-1には、PDFに署名した結果として、新しいPDFをどのように作成するかが規定されています。32000-1標準に準拠するように作成すれば、同じ標準に準拠する様々なプログラムで、同一の署名済みPDFを相互運用できます。仕様の変遷の項で見ますように、PDF電子署名の標準仕様が現在の形になりましたのは比較的最近です。次にPDF電子署名の主な機能とその特徴を簡単に紹介します。以下の説明は、PDF電子署名の機能を全て網羅しているわけではありません。電子署名モジュール」が提供している機能を中心としています。署名は対話フォーム(AcroForm)の一種である「署名フィールド」として定義されており、署名フィールドを作って署名するという2段階の方式になります。「PDF電子署名モジュール」では、次のようにして署名フィールドを作成できます(コマンドラインでの利用例)。9で表示しますと、次のようになります。電子署名は、デジタルデータで眼に見えないものです。PDFでは署名に外観をつけることができます。この署名の外観は、署名フィールドに付随する注釈機能(Widget注釈)として実現されています。未署名の署名フィールドに後から署名を追加することができます。上の例で作成した書名フィールド3(名称:Field3)に、署名を付ける例を示します。9で表示したのが次の図です。した機能を使うことにより、署名したい位置に未署名署名フィールドのあるPDFを作成して相手に渡し、指定位置に、相手の署名をつけて戻して貰うこともできます。外観を表示する領域をもたない署名(不可視署名)も可能です。PDFに電子署名を付けると、PDF全体を署名対象としてハッシュ値を計算し、それを署名者の秘密鍵で暗号化します。暗号化後のデータや署名者の証明書などの情報は、PKCS#7として作成した上でHEX値に変換して署名済みPDFの内部に保存されます。用語では証明用署名)という2種類があります。MDP署名は普通署名の機能に加えて、さらに次の特徴があります。文書に最大でも一つしか存在することができず、従って、MDP署名があるとしますと、必ず一番最初の署名となります。署名後のPDFに対する変更許可を次の3つのどれかに制限します。配布するPDFにフォーム・フィールドと署名フィールドを予め作成しておき、MDP署名で「フォームフィールドの入力と署名フィールドに署名を許可」を設定すると、受け取った人はPDFのフォームフィールドにデータを入力することと署名フィールドに署名ができますが他の操作はできません。次の例は、上記PDFの署名フィールド(Field3)にMDP署名(署名後変更不可に設定)を付けた例です。ReaderではPDFが「証明されています」と表示されます。このPDFは、MDP署名機能を実装した編集ソフトでは変更することができません。増分更新と署名PDF電子署名はPDFの増分更新機能と深い関係があります。PDFは適当なツールを使えば内容を編集(削除、追加、変更)したり、しおりをつけたりといった、様々な変更を施すことができます。そのような変更を行った結果をPDFファイルに保存するときの方法に「増分更新」という保存方法があります。増分更新とは、変更前のPDFファイルの内容をそのままに維持して、変更前のファイルの最後に変更した内容を追加し、新しいPDFファイルを作る方法です。8では、PDFを編集して「上書き保存」すると増分更新となります。「名前をつけて保存」すると増分更新ではなく、新しい内容(編集前のPDFの内容が維持されない)になるようです。増分更新では、編集前の古い世代のPDFがそのまま保持され、PDFファイルの最後を示していた%%EOFの後ろに、変更した内容が追加されます。バイナリエディタで、%%EOFを区切りにして、増分更新で追加された部分を削除しますと、元のオリジナルPDFに戻ります。増分更新とは、変更前のPDFをそのまま保持して、ファイルの最後に変更後のオブジェクトを追記していく保存方法です。PDFに署名をし、その後の変更を増分更新とすることで、署名済みの部分を変更することなく、新しい情報を追加していくことができます。PDFに署名後に、署名対象部分を変更しますと、署名部分が改竄されたという状態になります。これに対して、増分更新すれば、署名部分は保護されます。この結果、電子署名したPDFについては、旧版のPDFを取り出すことができることになります。署名バージョンPDFに対して同時に複数の署名ができるかどうかという質問を時々頂きますが、PDF電子署名の仕様上、同時に複数の署名はできません。PDFでは、増分更新の機能を使って文書に順番に複数の署名をすることになります。署名する毎にPDFが増分更新されますが、これを署名バージョンと言います。以下に簡単に実験してみます。PDFを作成して、それに普通の電子署名をします。二つ目の電子署名をします。最初に署名をした段階での署名の検証状態は次のようになっています。・一つ目の署名のプロパティ・二つ目の署名のプロパティ二つ目の署名をした段階で、一つ目の署名は署名が適用された後に変更されたという状態に変わります。PDFファイルの内部は次のようになっています。署名の対象範囲は、署名データ以外のPDF全体です。最初の署名をした段階で、署名前PDF全体に対する署名辞書が作成されて、その中に署名データが作られます。次の署名は最初の署名辞書や署名データまでを含めた範囲を署名対象範囲としています。二つ目の署名辞書や署名データは増分更新として作成されます。ちなみに増分更新部分(最初の%%EOFより後ろ)を削除してみます。して、PDFファイルに保存しますと、最初の署名がなされた状態に完全に元に戻ります。Readerでは署名の外観の機能を使って、署名の状態(未署名、署名済み、署名の種類、検証状態)を表示することができます。署名の検証状態をアイコンで表しています。Readerのヘルプを見ますとアイコンには次のようなものがあります。証明済みであること、つまり有効な証明用署名を含んでいることを示します。有効な証明書を使って署名されており、署名後に不正な変更がないことを示します。証明書が不正か、それとも、文書に許可されない変更がなされていることを示します。:署名後に文書が変更されている。証明書が検証できず、かつ、文書に予め許可された変更がなされているということを示します。:信用できる証明書の一覧に署名者の証明書がないために署名が検証できなかった。証明書を検証することができないか、文書の検証を完了できなかったことを示します。:証明書の信用を検証できず、かつ、文書が署名後に変更されていることを示します。:証明書の信用を検証できず、かつ、文書は署名後に変更されていないことを示します。署名ハンドラPDFに電子署名を付けるツールは署名時にPDF内に署名辞書と署名データを作成します。署名辞書のFilterキーには、その署名を検証するための望ましい署名ハンドラを登録します。署名辞書のSubFilterキーには、署名データなどの形式を登録します。PDF電子署名を検証するツールは、PDFの署名辞書のFilterキーとSubFilterキーを使って、検証に用いる署名ハンドラを決定します。32000-1では、SubFilterとしてadbe.pkcs7.detachedを設定することが推奨されています。Readerで電子署名を検証することができます。Readerで表示しながら、同時に署名やタイムスタンプの検証ができることが大きなメリットと言えます。PDF電子署名の仕組み仕様の変遷PDFの電子署名はPDF1.3より規定されました。PDFのバージョンが上がるに従って機能が追加されています。32000-1で規定されている署名関連機能のPDFのバージョンとの関係は次の表のようになってます。1.6までは、標準で規定されている電子署名機能が不足していたため、サードパーティが独自仕様の署名ハンドラを作成して機能不足を補うことが必要でした。32000-1に規定する標準仕様だけで実用的なレベルに達していると言えます。○SHA384SHA512RIPEMD160互換性PDF電子署名の仕様が上のように変遷してきたことにより、標準ツールが準拠するPDFバージョンによっては互換性の問題が発生する可能性があることを意味します。1.7以降で利用可能です。1.7と互換でない場合があります。以前のPDFに電子署名を付けると、それが可能な場合は、自動的にPDFのバージョンを1.6に変更してしまっています。32000-1では削除されてしまいました。1.6以降でないと使えません。Readerに内蔵される標準署名ハンドラの機能に対応しています。8以降では、SHA2を使う日本の商用タイムスタンプの検証も可能になっています。7以前では、商用タイムスタンプの検証には、タイムスタンプ局が提供するプラグインが必要です。