(57)【要約】【課題】  電子文書編集後に、元の電子署名を変更することなく、元の文書の真正性を確認可能であって、墨塗り箇所の長さを秘匿可能、および、複数箇所の墨塗りを同時に行うように条件付け可能な技術を提供する。【解決手段】  電子文書を構成要素に分割し、構成要素各々に対する署名と、これらの署名を一纏めにした署名とを付与する。構成要素各々に対する署名と一纏めにした署名は有限群の元であって、一纏めにした署名は、構成要素各々に対する署名の有限群の元としての総積である。署名付き電子文書から、構成要素Ａを削除する場合は、一纏めした署名に構成要素Ａへの署名の逆元を乗じて、構成要素Ａへの署名を削除し、構成要素Ａを開示し、かつ、後に削除可能にするときには、構成要素Ａへの署名を削除する。構成要素ＡとＢの削除を同時に行うときは、構成要素Ａへの署名と構成要素Ｂへの署名を削除し、代わりに、これらの署名を乗じて得られた署名を用いる。【選択図】図１
2006060722.tif 000002
【特許請求の範囲】
【請求項１】
電子文書の真正性保証方法であって、
電子文書を構成要素に分割し、
その構成要素それぞれに対する署名と、前記構成要素それぞれに対する署名をひとまとめにした署名とを付与する
ことを特徴とする電子文書の真正性保証方法。
【請求項２】
請求項１記載の電子文書の真正性保証方法であって、
さらに前記構成要素それぞれに対する署名と前記ひとまとめにした署名は有限群の元であって、前記ひとまとめにした署名は、前記構成要素それぞれに対する署名の有限群の元としての総積である
ことを特徴とする電子文書の真正性保証方法。
【請求項３】
請求項２記載の電子文書の真正性保証方法であって、
さらに、生成された署名付き電子文書を編集するときに、
前記電子文書の構成要素Ａを削除するときには、前記電子文書から構成要素Ａを削除し、前記ひとまとめした署名に前記構成要素Ａに対する署名の逆元を乗じ、前記構成要素Ａに対する署名を削除し、
前記電子文書の構成要素Ａを開示し、かつ、後に削除可能なように条件設定するときには、前記構成要素Ａに対する署名を削除する
ことを特徴とする電子文書の真正性保証方法。
【請求項４】
請求項３記載の電子文書の真正性保証方法であって、
さらに、前記電子文書の構成要素Ａと構成要素Ｂに対し、構成要素Ａと構成要素Ｂのどちらか一方だけを削除したときに、真正性が失われるように設定するときには、前記構成要素Ａに対する署名と、前記構成要素Ｂに対する署名の積を、前記構成要素Ａと前記構成要素Ｂとを結合して新たに生成された構成要素Ｃに対する署名とし、前記構成要素Ａと、前記構成要素Ｂと、前記構成要素Ａに対する署名と、前記構成要素Ｂに対する署名とを削除する、
ことを特徴とする電子文書の真正性保証方法。
【請求項５】
電子文書の真正性保証方法であって、
電子文書を構成要素に分割し、
前記構成要素の個数以上の葉ノードをもつ二分木を生成し、
前記二分木の葉ノードに対し、前記構成要素のハッシュ値を割り当て、
前記二分木の葉ノードのうち、前記構成要素のハッシュ値が割り当てられなかったノード乱数であるダミーデータを割り当て、
葉ノードのひとつ上（ルートノードに近い側）のノードに、左下の葉ノードのハッシュ値と、右下の葉ノードのハッシュ値を結合したデータを割り当て、これをルートノードに至るまで再帰的に繰り返し、
ルートノードに割り当てられた値に対し、電子署名を付与する、
ことを特徴とする電子文書の真正性保証方法。
【請求項６】
請求項５記載の電子文書の真正性保証方法であって、
さらに、生成された署名付き電子文書を編集するときに、
前記電子文書の構成要素を削除するときには、削除対象の構成要素またはダミーデータのみを葉ノードとして含む、ひとつまたは複数の部分木を検索し、
前記各部分木に対し、葉ノードのひとつ上（ルートノードに近い側）のノードに、左下の葉ノードのハッシュ値と、右下の葉ノードのハッシュ値を結合したデータを割り当て、これを前記各部分木のルートノードに至るまで再帰的に繰り返し、
二分木に含まれる前記各部分木を取り除きあらたな葉ノードで置き換え、各部分木のルートノードの値をあらたな葉ノードに割り当てる
ことを特徴とする電子文書の真正性保証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子データの真正性保証技術に関する。
【背景技術】
【０００２】
従来、電子文書等の電子データの真正性保証を行う技術として、電子署名（ディジタル署名ともいう）技術がある。（例えば、非特許文献１参照）。
【０００３】
また、電子署名技術における課題として、電子文書に対する１ビットの改変であっても検知できるように設計されているため、不正者による改ざんから電子文書を守るという意味では、非常に有用であるが、電子文書の有効活用という観点からは、一切の加工が許されなくなるため、逆に障害となりうるという点が指摘されており、これを解決する技術として電子文書墨塗り技術（Digital Document Sanitizing Scheme）という技術が知られている。（例えば、非特許文献２参照）。
【０００４】
また、電子署名の一技術として、複数の署名者がそれぞれの電子文書に対して施した署名を、ひとつにまとめることができるAggregate signatureと呼ばれる技術が知られている。（例えば、非特許文献３参照）
【非特許文献１】Bruce Schneier著「Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition」 John Wiley & Sons、(October 18, 1995)
【非特許文献２】宮崎邦彦、岩村充、松本勉、佐々木良一、吉浦裕、手塚悟、今井秀樹著「開示条件を制御可能な電子文書墨塗り技術」 2004年暗号と情報セキュリティシンポジウム予稿集，（2004年1月27日）
【非特許文献３】Don Boneh、Craig Gentry、Ben Lynn、Hovav Shacham著「Aggregate and Verifiably Encrypted Signatures from Bilinear Maps」Advances in Cryptology EUROCRYPT 2003、LNCS2656、Springer Verlag （May 4、2003）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
電子文書の安全性を支える重要な技術である現在の電子署名技術は、電子文書に対する１ビットの改変であっても検知できるように設計されている。この性質は、不正者による改ざんから電子文書を守るという意味では、非常に有用であるが、電子文書の有効活用という観点からは、一切の加工が許されなくなるため、逆に障害となりうる。
【０００６】
この問題を端的に示す利用場面としては、行政機関等における情報公開が挙げられる。たとえば，次のような電子署名の利用形態が想定される。
【０００７】
すなわち、行政機関において、職員が職務上作成した文書（行政文書）は、作成者を明らかにし、また、改ざんを防止するために、電子署名を付された上で保管される。この文書が情報公開法に基づき開示されるときに、そこに記述された個人情報や国家安全情報が削除された上で開示される。
【０００８】
非特許文献１に挙げた従来の電子署名技術では、上記の一連の手続きに従って開示された文書の真正性、すなわち、文書作成者が誰であるか、また開示された文書はもともと作成された文書と同一であるか、を確認することができない。なぜなら、情報公開の過程で、文書の一部が削除されているからである。悪意による改ざんであろうと、プライバシー情報の保護のための個人情報削除であろうと、署名対象文書に対し、なんらかの改変が加えられた、という点では変わらない。結果として、従来の電子署名技術の利用では、「公開された文書の真正性保証」と、「プライバシー情報の保護」という２つの重要なセキュリティ要件を両立できず、どちらかをあきらめざるをえない。非特許文献３に挙げたAggregate Signatureは、複数の署名者がそれぞれの電子文書に対して施した署名を、ひとつにまとめることができるという特徴を持つが、文書の一部が削除されたときに、署名が正しく検証できなくなる点は、非特許文献１に挙げた従来の電子署名技術と同様である。
【０００９】
情報公開制度が、行政機関のアカウンタビリティ（説明責任）を果たすための制度であるということを考えると、個人情報等が削除された後の開示用の文書からでも、元々の行政文書との同一性を検証できることが望ましい。
【００１０】
非特許文献２に記載された技術では、一部が削除（墨塗り）されたあとの文書であってもその真正性を確認できる技術として、電子文書墨塗り技術が開示されている。しかし、非特許文献２に記載された技術では、
１．墨塗り後の文書から墨塗り箇所の長さが推定可能であり、これを隠すことが困難である、
２．文書に含まれる各構成要素それぞれが独立に墨塗り可能であり、複数の構成要素を同時に墨塗りするように条件付けることが困難である、
という課題がある。上記1の点は、たとえばプライバシー保護の観点から個人名を墨塗りした場合に、非特許文献２に記載された従来技術では、墨塗りされた人物の名前の文字数が推定できてしまう可能性を示唆しており、改良が望まれる点である。また、上記２の点は、たとえば一つの文書内に、墨塗りされるべき同一人物の名前が複数箇所に現れている場合に、意図的にあるいは意図せず、ある部分だけを墨塗りし、他の部分は墨塗りされないという状態をもたらす可能性を示唆しており、改良が望まれる点である。
【００１１】
したがって、真正性保証対象文書に対する適切な改変を許容する電子文書の真正性保証技術、言い換えると電子文書編集後に、元の電子署名を変更することなく、元の文書の真正性を確認可能な技術であって、墨塗り箇所の長さを秘匿可能な技術、および、複数箇所の墨塗りを同時に行うように条件付け可能な技術、が望まれている。
【課題を解決するための手段】
【００１２】
本発明は、真正性保証対象文書に対する適切な改変を許容する電子文書の真正性保証技術と文書管理システムを提供する。
【００１３】
本発明は、その一態様において、電子文書を構成要素に分割し、その構成要素全体からなる集合の任意の部分集合に対し電子署名を付与する電子署名方法を提供する。
【００１４】
本発明の電子文書の真正性保証方法は、その一態様によれば、電子文書を構成要素に分割し、その構成要素それぞれに対する署名と、上記構成要素それぞれに対する署名をひとまとめにした署名とを付与することを特徴とするものである。
【００１５】
さらに、上記態様において、上記構成要素それぞれに対する署名と上記ひとまとめにした署名は有限群の元であって、上記ひとまとめにした署名は、上記構成要素それぞれに対する署名の有限群の元としての総積であることを特徴とするものである。
【００１６】
上記態様は、さらに、生成された署名付き電子文書を編集するときに、上記電子文書の構成要素Ａを削除するときには、上記電子文書から構成要素Ａを削除し、上記ひとまとめした署名に上記構成要素Ａに対する署名の逆元を乗じ、上記構成要素Ａに対する署名を削除し、上記電子文書の構成要素Ａを開示し、かつ、後に削除可能なように条件設定するときには、上記構成要素Ａに対する署名を削除することを特徴とするものである。
【００１７】
上記態様は、さらに、上記電子文書の構成要素Ａと構成要素Ｂに対し、構成要素Ａと構成要素Ｂのどちらか一方だけを削除したときに、真正性が失われるように設定するときには、上記構成要素Ａに対する署名と、上記構成要素Ｂに対する署名を積を、上記構成要素Ａと上記構成要素Ｂとを結合して新たに生成された構成要素Ｃに対する署名とし、上記構成要素Ａと、上記構成要素Ｂと、上記構成要素Ａに対する署名と、上記構成要素Ｂに対する署名とを削除することを特徴とするものである。
【００１８】
また、本発明の電子文書の真正性保証方法は、他の一態様によれば、電子文書を構成要素に分割し、上記構成要素の個数以上の葉ノードをもつ二分木を生成し、上記二分木の葉ノードに対し、上記構成要素のハッシュ値を割り当て、上記二分木の葉ノードのうち、上記構成要素のハッシュ値が割り当てられなかったノード乱数であるダミーデータを割り当て、
葉ノードのひとつ上（ルートノードに近い側）のノードに、左下の葉ノードのハッシュ値と、右下の葉ノードのハッシュ値を結合したデータを割り当て、これをルートノードに至るまで再帰的に繰り返し、ルートノードに割り当てられた値に対し、電子署名を付与することを特徴とするものである。
【００１９】
上記態様は、さらに、生成された署名付き電子文書を編集するときに、上記電子文書の構成要素を削除するときには、削除対象の構成要素またはダミーデータのみを葉ノードとして含む、ひとつまたは複数の部分木を検索し、上記各部分木に対し、葉ノードのひとつ上（ルートノードに近い側）のノードに、左下の葉ノードのハッシュ値と、右下の葉ノードのハッシュ値を結合したデータを割り当て、これを上記各部分木のルートノードに至るまで再帰的に繰り返し、二分木に含まれる上記各部分木を取り除きあらたな葉ノードで置き換え、各部分木のルートノードの値をあらたな葉ノードに割り当てることを特徴とするものである。
【発明の効果】
【００２０】
本発明によれば、部分情報を削除後であっても電子文書の真正性が検証可能で削除箇所の長さを秘匿可能な電子文書の真正性保証技術が提供される。また、個人情報等の重要情報の機密性と開示文書の真正性を保証可能な情報公開システムが提供される。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施形態を説明する。
【実施例１】
【００２２】
図１は、本発明を、情報公開システムに適用した複数の実施形態におけるシステムの概略構成図である。なお、以下では、行政機関の情報公開システムを例に挙げているが、行政機関以外の組織や個人における情報公開システムであっても同様に適用可能である。
【００２３】
図示するように、本システムは、ネットワーク１０１を介して、情報公開側である行政機関の職員が利用する、オリジナル文書作成者装置１０２、文書管理装置１０３、開示文書作成者装置１０４の各装置と、情報公開の請求側と検証側である一般市民が利用する受信者装置１０５が接続されている。
【００２４】
なお、以下の各実施形態では、行政機関の職員が利用する、オリジナル文書作成者装置１０２、文書管理装置１０３、開示文書作成者装置１０４の各装置と、一般市民が利用する受信者装置１０５が、同一のネットワーク１０１に接続されている例を説明しているが、これとは異なる接続形態であってもよい。たとえば、行政機関の職員が利用する、オリジナル文書作成者装置１０２、文書管理装置１０３、開示文書作成者装置１０４の各装置が、当該行政機関のLAN(Local Area Network)に接続されており、当該LANが、ゲートウェイサーバを介して、一般市民が利用する受信者装置１０５が接続されているネットワーク１０１に接続されるようになっていてもよい。このような接続形態をとった場合、行政機関のLANは、ゲートウェイサーバにより、外部ネットワーク１０１からの不正アクセス等の攻撃から防御できることになるため、情報セキュリティの観点からは好ましい。
【００２５】
オリジナル文書作成者装置１０２は、行政機関の職員であるオリジナル文書作成者が、電子データとして行政文書（職務上作成する文書）を作成し、作成した行政文書に対し、電子署名を付与したのち、文書管理装置１０３に署名付き行政文書を要求するために利用される。以下の各形態の説明では、以降、オリジナル文書作成者が署名を付す対象とした行政文書のことを、オリジナル文書１０６と呼ぶ。なお、以下の各形態では、オリジナル文書の作成と、オリジナル文書１０６への署名の付与を、ともにオリジナル文書作成者装置において行う例を示すが、これとは異なり、オリジナル文書の作成とオリジナル文書への署名を行う装置とを分け、ネットワーク１０１や可搬な記憶媒体を用いて、これらの装置間でオリジナル文書１０６の受け渡しを行うようにしてもよい。
【００２６】
文書管理装置１０３は、オリジナル文書作成者装置１０２から要求を受けて、オリジナル文書作成者装置１０２で作成された署名付きオリジナル文書１０７を保管する。また、開示文書作成者装置１０４からの要求を受けて、あらかじめ保管していた開示対象となる署名付きオリジナル文書１０７を、開示文書作成者装置１０２に送信する。なお、オリジナル文書作成者装置１０２からの保管要求受付時と、開示文書作成者装置１０４からの開示対象文書送信要求受付時には、適切なユーザ認証処理等を行うことによって、アクセス制御を行うことが、情報セキュリティの観点からは好ましい。
【００２７】
開示文書作成者装置１０４は、受信者装置１０５の利用者である一般市民などの操作による情報公開請求を受けて、当該情報公開請求に応じた開示対象文書を検索し、当該開示対象文書である署名付きオリジナル文書１０７の送信を文書管理装置１０３に要求する。次に、開示文書作成者装置１０４の操作者の操作により、文書管理装置１０３から受信した署名付きオリジナル文書１０７に含まれる情報のうち、個人情報保護や、国家機密にかかわる情報の保護の観点から、公開に不適切な情報を取り除いた（i.e.墨塗りした）開示文書１０８を作成し、作成した開示文書を受信者装置１０５に対し公開する。
【００２８】
このとき、オリジナル文書１０６に付された署名が、従来の電子署名技術によって生成された署名である場合、「公開に不適切な情報の削除」であっても、オリジナル文書１０６に対する不正な改ざんがあった場合と同様に、署名検証の際に検証に失敗するという結果になってしまう。また、従来の電子文書墨塗り技術では、署名検証は成功するが、墨塗り部分の長さを秘匿することについては配慮されていなかった。各実施形態では、不適切な情報削除後であっても検証可能で、墨塗り部分の長さを秘匿可能な、あらたな電子署名技術を適用する。
【００２９】
公開する方法は、たとえば、電子メールで送信する、行政機関または他の機関が運用するWebサーバにアップロードするなど、任意に設計すればよい。Webサーバにアップロードする方法の場合は、情報公開請求を行った受信者装置１０５の利用者以外の一般市民であっても、公開された情報を閲覧できるというメリットがある。
【００３０】
なお、各実施形態では、一般市民からの情報公開請求受付、開示対象文書の検索、開示対象文書の文書管理装置１０３への要求、開示文書１０８の作成、開示文書１０８の公開を、同一の開示文書作成者装置１０５において行う例を示すが、これとは異なっていてもよい。たとえば、一般市民からの情報公開請求受付、開示対象文書の検索、開示対象文書の文書管理装置１０３への要求、を開示文書作成者装置１０５とは異なる、別の装置において行い、開示文書１０８の作成と開示文書１０８の公開を開示文書作成者装置１０５で行うようにしてもよい。
【００３１】
受信者装置１０５は、利用者である一般市民が、行政機関に対し情報公開請求を行い、その結果公開された開示文書１０８の真正性を検証するために利用される。受信者装置１０５は、開示文書作成装置１０４に対し、開示対象文書を特定するのに必要な情報を送信し、情報公開を請求する。また、公開された開示文書１０８とオリジナル文書１０６の内容とが、情報の保護の観点から取り除かれた部分を除き、同一であるかどうかを検証する。
【００３２】
また、受信者装置１０５は、公開された開示文書１０８を、利用者が閲覧できるように、墨塗りされた状態で表示または印刷を行う。
【００３３】
なお各実施形態では、情報公開請求と、開示文書１０８の真正性検証を、同一の受信者装置１０５で行う例を示すが、これとは異なっていてもよい。たとえば、情報公開請求を、受信者装置１０５とは別の装置で行い、その結果公開された開示文書１０８の真正性検証を、受信者装置１０５で行うようにしてもよい。
【００３４】
図２は、以下の各形態におけるオリジナル文書作成者装置１０２の概略構成を示した図である。
【００３５】
オリジナル文書作成者装置１０２は、CPU２０１と、CPU２０１のワークエリアとして機能するRAM２０２と、ハードディスク装置などの外部記憶装置２０３と、CD-ROMやFDなどの可搬性を有する記憶媒体２０５からデータを読取る読取り装置２０４と、キーボードやマウスなどの入力装置２０６と、ディスプレイなどの表示装置２０７と、ネットワークを介して他の装置と通信を行うための通信装置２０８と、上述した各構成要素間のデータ送受を司るインターフェイス２０９を備えた、一般的な構成を有する電子計算機２１０で構築することができる。
【００３６】
オリジナル文書作成者装置１０２の外部記憶装置２０３に格納されるのは、オリジナル文書作成PG（プログラム）２２１と署名生成PG（プログラム）２２２と文書保管要求PG（プログラム）２２３である。これらのプログラムは、RAM２０２上にロードされ、CPU２０１により、それぞれオリジナル文書作成処理部２４１、署名生成処理部２４２、文書保管要求処理部２４３というプロセスとして具現化される。そのほか、これらの各処理部の入出力となるデータ（オリジナル文書１０６、署名つきオリジナル文書１０７、署名用秘密鍵２１１）などが格納される。なお、署名用秘密鍵２１１はセキュリティの観点から特に厳重な管理が求められる。そのため、他のデータが格納された外部記憶装置とは異なる耐タンパ性のある装置内に格納してもよい。
【００３７】
文書管理装置１０３、開示文書作成者装置１０４、受信者装置１０５も、オリジナル文書作成者装置１０２と同様の構成を備える。ただし、文書管理装置１０３の外部記憶装置には、文書保管PG（プログラム）２２４と、開示対象文書送信PG（プログラム）２２５が格納され、また保管を要求された署名つきオリジナル文書が格納される。また、開示文書作成者装置１０４の外部記憶装置には、情報公開請求受付PG（プログラム）２２６、開示対象文書検索PG（プログラム）２２７、開示対象文書要求PG（プログラム）２２８、開示箇所決定PG（プログラム）２２９、開示文書作成PG（プログラム）２３０、開示文書公開PG（プログラム）２３１が格納される。また、受信者装置１０５の外部記憶装置には、情報公開請求PG（プログラム）２３２、開示文書検証PG（プログラム）２３３が格納される。
【００３８】
なお、以下の各形態の説明では、各プログラムは、あらかじめ、外部記憶装置２０３に格納されているものとしたが、必要なときに、FD、CDROMなどの他の記憶媒体または通信媒体であるインターネットなどのネットワークまたはネットワークを伝搬するディジタル信号や搬送波を介して、上記外部インターフェイスを介して外部記憶装置２０３またはRAM２０２に導入されてもよい。
【００３９】
図３は、以下の各形態において、オリジナル文書である行政文書を作成し、文書管理装置に保管するときの概要を示したフロー図である。なお、オリジナル文書を作成し保管する段階においては、将来的に情報公開請求を受けたときに、文書管理装置に保管された文書のうち、どの部分が公開されるべき情報であり、どの部分が公開されるべきでない情報であるかを、決定できるとは限らない。一般には、決定できないことが多いと考えられる。なお、各ステップ中の括弧内に、当該ステップの処理を行うプログラム名を示す。
【００４０】
オリジナル文書作成・保管フロー：
（オリジナル文書作成者装置１０２の処理）
３０１：はじめ
３０２：オリジナル文書を作成（オリジナル文書作成PG２２１）
３０３：作成したオリジナル文書に対し署名を生成（署名生成PG２２２）
３０４：署名つきオリジナル文書を文書管理装置１０３に送信し登録を要求（文書保管要求PG２２３）
（文書管理装置１０３の処理）
３０５：受信した署名付きオリジナル文書を登録（文書保管PG２２４）
３０６：おわり
図４は、以下の各形態において、一般市民からの情報公開請求を受けて、情報公開されるときの概要を示したフロー図である。なお、各ステップ中の括弧内に、当該ステップの処理を行うプログラム名を示す。
【００４１】
情報公開フロー：
（受信者装置１０５の処理）
４０１：はじめ。
４０２：開示文書作成者装置１０４に対し、情報公開を要求するために、公開を希望する情報の範囲を特定可能な情報を送信（情報公開請求PG２３２）。
（開示文書作成者装置１０４の処理）
４０３：公開を希望する情報の範囲を特定する情報を受信し（情報公開請求受付PG２２６）、その範囲を特定する情報に基づき開示すべき文書を検索し（開示対象文書検索PG２２７）、文書管理装置１０３に当該文書を要求（開示対象文書要求PG２２８）。
（文書管理装置１０３の処理）
４０４：要求された開示すべき署名つきオリジナル文書を開示文書作成装置１０４に送信（開示対象文書送信PG２２５）。
（開示文書作成者装置１０４の処理）
４０５：受信した署名つきオリジナル文書の内容を、あらかじめ定められた情報開示ポリシーに照らして確認し、開示適当な箇所を決定し（開示箇所決定PG２２９）、個人情報や国家機密にかかわる情報などの開示不適当な情報が漏洩しないようにするための非開示処理を施した開示文書を作成し（開示文書作成PG２３０）、当該開示文書を受信者装置１０５に送信（開示文書公開PG２３１）。
（受信者装置１０５の処理）
４０６：受信した開示文書の真正性を検証（開示文書検証PG２３３）。
４０７：おわり。
【００４２】
以上に概要を示した情報公開システムにおいて、特に注意すべきなのは、開示文書の真正性の保証と、開示不適当な情報の削除の両立である。
【００４３】
開示文書がオリジナル文書と必ず同一であるような運用形態であれば、オリジナル文書作成者が、公知の電子署名技術を適用し、オリジナル文書にあらかじめ署名を付与しておけば、受信者は、開示文書（この場合はオリジナル文書と同一データ）の真正性を、公知の電子署名検証技術を適用することによって確認可能である。
【００４４】
しかし、本実施形態で述べるような情報公開システムにおいては、オリジナル文書と、開示文書が同一とは限らない。なぜなら、オリジナル文書には、情報公開時点では、開示することが不適当な情報（例：個人のプライバシーにかかわる情報、国家安全保障上公開すべきでない情報など）が含まれている可能性があるため、これらの情報は開示文書からは取り除かれる（i.e.墨塗りされる）必要があるからである。この場合の墨塗りのような情報公開の観点からは、適切あるいは必須と考えられるオリジナル文書に対する変更であっても、公知の電子署名技術では、悪意をもった第三者による改ざんを受けた場合と同様に、「検証できない」という結果しか得られない。
【００４５】
したがって、開示文書の真正性の保証と、開示不適当な情報の削除の両立可能な、新たな電子文書の真正性保証技術が求められる。
【００４６】
本実施形態における電子文書の真正性保証技術に望まれる性質は、以下の２つに要約される。
（性質１）墨塗りされた文書の墨塗り部分にもともと含まれていた情報が漏れないこと
（性質２）墨塗り以外の許されていない改変が施された、正当に検証される署名つき電子文書を偽造できないこと
なお、性質１は、単に墨塗り部分の情報が推定困難であることのほかに、たとえ墨塗り部分の情報が推定された場合であっても、その推定結果が正しいことの判定材料として利用できないこと、も含めるものとする。また、性質２は、墨塗りという改変であれば一律に許されるということを意味するわけではないことに注意する。後述するように、本実施形態における電子文書の真正性保証技術では、許可される墨塗りと、許可されない墨塗りを設定可能である。
【００４７】
本実施形態においては、上記の各性質を満たす電子文書の真正性保証技術として適用しうる方法を複数開示する。
【００４８】
はじめに第１の実施形態について述べる。どのように実現するかを説明するために、オリジナル文書作成者装置１０２で動作する署名生成PG２２２と、開示文書作成者装置１０４で動作する開示文書作成PG２３０と、受信者装置１０５で動作する開示文書検証PG２３３の詳細について述べる。
【００４９】
第１の実施形態では、Aggregate signatureと呼ばれる署名技術を利用して電子文書の真正性保証技術を構成する。そこで第１の実施形態を説明するために、まずAggregate Signatureについて説明する。
【００５０】
Aggregate signatureは、複数の署名者がそれぞれの電子文書に対して施した署名を、ひとつにまとめることができるという特徴を持つ電子署名技術である。Aggregate signatureにおける鍵生成、署名生成、Aggregation、署名検証の各処理の概要は、以下の通りである。以下、G_1, G_2,G_Tを素数位数pの巡回群(cyclic group)とする。またG_1, G_2の生成元(generator)をg_1,g_2とする。phiをG_1からG_2への計算可能な同型写像(isomorphism)で、phi(g_1)=g_2なるものとする。また、eをG_1×G_2からG_Tへの計算可能で非退化な(non-degenerate)双線形写像(bilinear map)とする。このような性質を満たすと考えられている群、双線形写像の例としては、楕円曲線上の有理点が生成する群およびそこで定義されるWeilペアリング、Tateペアリングなどと呼ばれる写像が知られている。
【００５１】
（鍵生成）各署名者U_iは、0からp-1までの乱数x_iを生成し、v_i=g_1^x_i を計算する。x_iがU_iの秘密鍵となり、v_iが公開鍵となる。ただし、ここでa^bはaのb乗をあらわす。
【００５２】
（署名生成）各署名者U_iが、メッセージM_iに対して署名を生成するときは、まずh_i=h(M_i)を計算し、次に、Sig_i=h_i^x_iを計算する。Sig_iが署名者U_iのメッセージM_iに対する署名となる。ただし、ここでhは、任意長のメッセージを入力とし、G_2の元を出力するハッシュ関数とする。
【００５３】
（Aggregation）メッセージSig_{j_1},,,Sig_{j_k}をaggregateするときは、Sig=Sig_{j_1}×・・・×Sig_{j_k}を計算する。SigがSig_{j_1},,,Sig_{j_k}をaggregateした署名となる。
【００５４】
（署名検証）メッセージM_{j_1},,,M_{j_k}に対する（aggregateされた）署名Sigを検証するときには、e(g_1,Sig) = e(v_{j_1},h_{j_1})×・・・×e(v_{j_k},h_{j_k})であることを確認する。ただし、ここでh_i=h(M_i)である。
【００５５】
図５は、第１の実施形態に従った署名生成PG２２２の処理フローを示した図である。
５０１：はじめ。
５０２：オリジナル文書を構成要素（以降、ブロックと呼ぶ）に分割する。構成要素をどのように定めるかについては、たとえばオリジナル文書の先頭から１バイトごとにひとつの構成要素として定めてもよいし、あるいは、XML(eXtensible Markup Language)を使って記述された文書のようにあらかじめ構造化された文書であれば、その最小構成要素を利用してもよい。以下、オリジナル文書をＮブロックの列とみなし、これをM_1,,,M_Nとあらわす。
５０３：オリジナル文書であるＮブロックそれぞれに対し、aggregate signatureの署名生成方法に従って、オリジナル文書作成者の秘密鍵xを用いて署名を生成する（Ｎ個の署名Sig_1,,,Sig_Nが生成されることになる）。
５０４：オリジナル文書作成者が生成したＮ個の署名をaggregateする。これをSigとあらわす。オリジナル文書M_1,,,M_Nと、署名Sig_1,,,Sig_Nと、aggregateされた署名Sigからなるデータを、署名付きオリジナル文書とする。
５０５：おわり。
【００５６】
図６は、第１の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。
６０１：はじめ。
６０２：開示対象である署名付きオリジナル文書の中から、開示不適切な情報を含むブロックを検索。これをM_{j_1},,,M_{j_k}とする。
６０３：Sig = Sig/(Sig_{j_1}×・・・×Sig_{j_k})とする。（更新された後のSigが、M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックに対する署名をaggregateしたものになっていることに注意）
６０４：M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックと、前記部分列に対応するaggregateされた署名であるSigからなるデータを、開示文書とする。
６０５：おわり
図７は、第１の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
７０１：はじめ。
７０２：開示文書（M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックと、前記部分列に対応するaggregateされた署名であるSigからなるデータ）を、オリジナル文書作成者の公開鍵vを用いて、aggregate signatureの検証手順にしたがって検証し、検証結果を出力する。なお、検証に利用するオリジナル文書作成者の公開鍵は、たとえば、開示文書とともに開示文書作成者装置１０４から送られてくるようにしてもよいし、オリジナル文書作成者装置１０２から、必要に応じて入手可能であるようにしておいてもよい。公開鍵は、公知のPKI(Public-key infrastructure)技術を適用して発行された、確かにオリジナル文書作成者であることを確認可能な公開鍵証明書つきで利用可能であることが望ましい。
７０３：おわり
以上に述べた電子文書の真正性保証技術（第１の実施形態）が、上記の（性質１）（性質２）を満たしていることを説明する。
【００５７】
第１の実施形態では、開示文書は、オリジナル文書の部分列と、その部分列に対するオリジナル文書作成者の署名とから構成され、非開示とされた(i.e.墨塗りされた)部分のデータは含まない。したがって、（性質１）を満たす。また、aggregate signatureの安全性(改ざん困難性)から（性質２）も満たす。
【００５８】
さらに、第１の実施形態に従えば、墨塗り後の文書から墨塗り箇所の長さが推定が困難である。なぜなら、開示文書は、オリジナル文書の中の非開示とされた(i.e.墨塗りされた)部分のデータは含まないからである。したがって、開示文書からではオリジナル文書を、何ブロック墨塗りした可能性も否定できないため、何ブロック墨塗りしたか分からない。
【実施例２】
【００５９】
ところで、以上に述べた第１の実施形態にしたがって構成された開示文書は、さらに追加的に墨塗りすることはできない。これを追加的な墨塗りの許可／不許可が設定可能となるように改良した第２の実施形態について説明する。
【００６０】
第２の実施形態では、開示文書作成処理を以下のように変更することにより、追加的な墨塗りの許可／不許可を設定することを可能としている。
【００６１】
このような追加的な墨塗りの許可／不許可を制御可能な技術によれば、たとえば開示文書作成者が複数いて、それぞれの責任範囲が異なる場合などに効果的である。たとえば、はじめの開示文書作成者が、自身の責任範囲について開示判断を行った上で追加的な不許可とし、自身の責任範囲以外については、開示かつ追加的な墨塗りを許可する、ように設定しておけば、２人目以降の開示文書作成者が、各々の責任範囲について同様に開示判断を行うことができる。
【００６２】
図８は、第２の実施形態に従った署名生成PG２２２の処理フローを示した図である。
８０１：はじめ。
８０２：署名対象文書を識別する文書IDとして乱数DIDを生成し、DIDを含む文書情報ブロックM_0を生成する。M_0にはさらに文書名、作成者名、利用条件などの当該文書に対するメタ情報を含んでもよい。ただし、将来的に非開示とされる情報は含むべきではない。
８０３：オリジナル文書を構成要素（以降、ブロックと呼ぶ）に分割する。構成要素をどのように定めるかについては、たとえばオリジナル文書の先頭から１バイトごとにひとつの構成要素として定めてもよいし、あるいは、XML(eXtensible Markup Language)を使って記述された文書のようにあらかじめ構造化された文書であれば、その最小構成要素を利用してもよい。以下、オリジナル文書をＮブロックの列とみなし、各ブロックと文書IDであるDIDを連結したデータをM_1,,,M_Nとあらわす。
８０４：文書情報ブロックとオリジナル文書であるＮブロックそれぞれに対し、aggregate signatureの署名生成方法に従って、オリジナル文書作成者の秘密鍵xを用いて署名を生成する（Ｎ＋１個の署名Sig_0,Sig_1,,,Sig_Nが生成されることになる）。
８０５：オリジナル文書作成者が生成したＮ＋１個の署名をaggregateする。これをSigとあらわす。文書情報ブロックM_0と、オリジナル文書M_1,,,M_Nと、署名Sig_1,,,Sig_Nと、aggregateされた署名Sigからなるデータを、署名付きオリジナル文書とする。
８０６：おわり。
【００６３】
図９は、第２の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。第２の実施形態では、複数の開示文書作成者がいてもよい。その場合、各開示文書作成者が、順次、開示文書作成PGを実行すればよい。このとき、後に実行する開示文書作成者は、一つ前までの開示文書作成者が設定した条件の範囲内で、墨塗り可能となる。
９０１：はじめ。
９０２：開示対象である署名付きオリジナル文書（または他の開示文書作成者によって作成された開示文書中の追加的な墨塗りが許可されたブロック）の中から、開示不適切な情報を含むブロックを検索。これをM_{j_1},,,M_{j_k}とする。
９０３：開示するブロックのうち、追加的な墨塗りを許可するブロックを検索する。これをM_{i_1},,,M_{i_n}とする。ただし集合{j_1,,,j_k}と集合{i_1,,,i_k}は互いに共通部分を持たないものとする。
９０４：Sig = Sig/(Sig_{j_1}×・・・×Sig_{j_k})とする。（更新された後のSigが、M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックに対する署名をaggregateしたものになっていることに注意）
９０５：M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックと、前記部分列に対応するaggregateされた署名であるSigと、追加的な墨塗りを許可するブロックに対する署名であるSig_{i_1},,,Sig_{i_n}からなるデータを、開示文書とする。
９０６：おわり
なお、図９に示した開示文書作成PG２３０の処理を行う前に、開示文書作成者装置において、以下に示す開示文書検証PG２３３の処理を行って、開示文書作成者が、他の開示文書作成者によって作成された開示文書を検証し、検証が成功した場合に、開示文書作成PG２３０の処理を行ったほうが望ましい。
【００６４】
図１０は、第２の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
１００１：はじめ。
１００２：開示文書に文書情報ブロックM_0が含まれていることを確認する。含まれていなければ検証失敗と出力し終了する。
１００３：文書情報ブロックM_0に含まれるDIDが、開示文書にふくまれるすべてのオリジナル文書ブロック（M_{j_1},,,M_{j_k}以外のオリジナル文書のブロック）にも含まれていることを確認する。含まれていなければ検証失敗と出力し終了する。
１００４：開示文書に、各オリジナル文書ブロックに対する署名Sig_iが含まれている場合には、オリジナル文書作成者の公開鍵vを用いて、Sig_iがM_iに対する正当な署名であることを検証する。ひとつでも検証に失敗したときは、検証失敗と出力して終了する。
１００５：開示文書に対するaggregate signature Sigを、オリジナル文書作成者の公開鍵vを用いて、aggregate signatureの検証手順にしたがって検証し、検証結果を出力する。なお、検証に利用するオリジナル文書作成者の公開鍵は、たとえば、開示文書とともに開示文書作成者装置１０４から送られてくるようにしてもよいし、オリジナル文書作成者装置１０２から、必要に応じて入手可能であるようにしておいてもよい。公開鍵は、確かにオリジナル文書作成者のものであることを確認可能であることが望ましい。例えば、公知のPKI(Public-key infrastructure)技術を適用して発行された、確かにオリジナル文書作成者であることを確認可能な公開鍵証明書つきで利用可能であることが望ましい。
１００６：おわり。
【００６５】
以上に述べた第２の実施形態によれば、開示文書作成者（墨塗り者）が、各ブロックに対して、(1)墨塗りする、(2)開示し追加的な墨塗りの許可する、(3)開示し追加的な墨塗りを不許可とする、の３つの開示条件が設定できるようになる。さらに、この開示条件付けられた開示文書を受け取った、他の開示文書作成者（墨塗り者）は、当該開示文書に含まれるブロックのうち、「(2)開示し追加的な墨塗りの許可する」という条件が設定されたブロックに対し、さらに上記の３つの開示条件を設定可能である。これを再帰的に繰り返し、最終的な開示文書作成者が、各ブロックに対し、「(1)墨塗りする」または「(3)開示し追加的な墨塗りを不許可とする」のいずれかの条件を設定するようにすれば、この一連の操作によって得られた最終的な開示文書は、開示不適切な部分を非開示（墨塗り）としつつも真正性が確認可能であり、さらに最終的な開示文書作成後になされた改変（墨塗りを含む）を検知可能となる。これは行政文書の情報公開にとっては望ましい。
【実施例３】
【００６６】
ところで、第２の実施形態では、各ブロックに対して３つの開示条件が設定可能であるが、その条件設定はブロックごとに独立であった。これに対し、複数のブロックを関連付けて条件付けたい場合もある。たとえば、同一文書内の異なるブロックに同じ文字列（人名など）が含まれている場合には、それらのブロックに対する開示／非開示の判断は同一であることが望ましい。しかし、条件設定を独立になされる場合には、たとえば、一方のブロックのみを非開示にして、他方を開示とすることができてしまう。そこで、複数のブロックを関連付けて条件付け可能となるように改良した第３の実施形態について説明する。
【００６７】
第３の実施形態では、開示文書作成処理を以下のように変更することにより、複数のブロックを関連付けて条件付け可能としている。
【００６８】
図１１は、第３の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。第３の実施形態では、第２の実施形態同様、複数の開示文書作成者がいてもよい。その場合、各開示文書作成者が、順次、開示文書作成PGを実行すればよい。このとき、後に実行する開示文書作成者は、一つ前までの開示文書作成者が設定した条件の範囲内で、墨塗り可能となる。
１１０１：はじめ。
１１０２：開示対象である署名付きオリジナル文書（または他の開示文書作成者によって作成された開示文書中の追加的な墨塗りが許可されたブロック）の中から、開示不適切な情報を含むブロックを検索。これをM_{j_1},,,M_{j_k}とする。
１１０３：開示するブロックのうち、追加的な墨塗りを許可するブロックを検索する。これをM_{i_1},,,M_{i_n}とする。ただし集合{j_1,,,j_k}と集合{i_1,,,i_k}は互いに共通部分を持たないものとする。
１１０４：Sig = Sig/(Sig_{j_1}×・・・×Sig_{j_k})とする。（更新された後のSigが、M_{j_1},,,M_{j_k}以外のオリジナル文書のブロックに対する署名をaggregateしたものになっていることに注意）
１１０５：M_{i_1},,,M_{i_n}の中から、互いに関連付けたいブロックの集合{M_{s_1},,,M_{s_t}}を検索する。Sig_{s_1,,,s_t} = Sig_{s_1}×・・・×Sig_{j_k}とし、以降、ブロックの集合{M_{s_1},,,M_{s_t}}をひとまとめにして新たなひとつのブロックM_{s_1,,,s_t}とみなし、Sig_{s_1,,,s_t}をブロックM_{s_1,,,s_t}に対する署名として用いる。なお、互いに関連付けたいブロックの集合が複数ある場合は、各集合に対し、同じ処理を繰り返す。
１１０６：開示するブロック全体と、開示するブロック全体に対応するaggregateされた署名であるSigと、開示するブロックのうちの追加的な墨塗りを許可するブロックに対する署名であるSig_{i_1},,,Sig_{i_n}からなるデータを、開示文書とする。
１１０７：おわり。
【００６９】
図１２は、図１１に示した開示文書作成PGの実行によって得られた開示文書の様子を、模式的に示した図である。オリジナル文書作成者１２０１が作成したオリジナル文書には、ブロックM_0〜M_6（１２１０〜１２１６）と各ブロックに対する署名Sig_1〜Sig_6（１２２１〜１２２６）とそれらの署名をaggregateした署名Sig（１２３０）が含まれている。これをもとに、第３の実施形態にしたがって作成された開示文書には、関連付けられたブロック各々，すなわちM_1（１２１１）とM_4（１２１４）に対する署名Sig_1（１２２１）,Sig_4（１２２４）は含まれないが、関連付けられたブロックの集合に対する署名Sig_{1,4}（１２４０）は含まれる。したがって、この開示文書を受け取った、他の開示文書作成者は、関連付けられたブロックの集合全体を墨塗りすることは可能であるが、関連付けられたブロックの集合に含まれる各ブロックを個別に墨塗りすることはできない（i.e. 個別に墨塗りしてしまうと、正しく検証される(aggregateされた)署名を構成することができなくなる)。
【００７０】
以上に述べた第３の実施形態によって、署名付き電子文書の一部を墨塗り後に、元の電子署名を変更することなく、元の文書の真正性を確認可能な技術であって、墨塗り箇所の長さを秘匿可能で、複数箇所の墨塗りを同時に行うように条件付け可能な技術が提供される。
【００７１】
なお、上記各実施形態では、オリジナル文書作成者（署名者）が一人の場合を例に挙げて説明していたが、これに限らず、複数の署名者が存在する場合にも適用可能である。
【００７２】
図１３は、第３の実施形態に示した署名付き電子文書の一部を墨塗り後に、元の電子署名を変更することなく、元の文書の真正性を確認可能な技術であって、墨塗り箇所の長さを秘匿可能で、複数箇所の墨塗りを同時に行うように条件付け可能な技術を、複数の署名者が存在する場合に適用した場合におけるオリジナル文書および開示文書の様子を模式的に説明した図である。
【００７３】
なお、上記各実施形態では行政文書を対象として説明していたが、ここでは医療情報を例に示している。具体的には、複数のオリジナル文書作成者（署名者）をそれぞれ、医師１３０１と看護士１３０２とし、医師１３０１が作成した電子カルテ１３１０と、看護士が作成した検温表１３１１のそれぞれに含まれる「患者名」を関連付ける第１の開示文書作成者と、第１の開示文書作成者１３０３が作成した第１の開示文書をもとに、患者１３０５に対しては「病名」を墨塗りした開示文書を作成して開示し、製薬会社１３０６に対しては「患者名」を墨塗りした開示文書を作成して開示する、第２の開示文書作成者１３０４が存在する場合を例に挙げている。第３の実施形態に示した方法によれば、複数のブロックを関連付けられるので、たとえば第２の開示文書作成者１３０４が、製薬会社１３０６に対して、医師１３０１の作成した電子カルテ１３１０に記された患者名は墨塗りするが、看護士１３０２の作成した検温表１３１１に記された患者名は墨塗りしないで開示する、という望ましくない開示を防止可能となる。
【実施例４】
【００７４】
以上に述べた各実施形態では、Aggregate signatureを用いて構成した電子文書の真正性保証方法について述べたが、これ以外の方法によっても、電子文書墨塗り後に、元の電子署名を変更することなく、元の文書の真正性を確認可能な技術であって、墨塗り箇所の長さを秘匿可能な技術を構成可能である。
【００７５】
図１４は、第４の実施形態に従った署名生成PG２２２の処理フローを示した図である。
１４０１：はじめ。
１４０２：ステップ５０２と同様。
１４０３：葉ノード数がＮ以上ある二分木をランダムに生成する。
１４０４：Ｎ個のブロックそれぞれに対し、ブロックのデータとそのブロックに対して生成された乱数を結合したデータ（これを乱数つきブロックと呼ぶ）を生成する。
１４０５：乱数付きブロックのハッシュ値を、二分木の各葉ノードにランダムに割り当てる。乱数付きブロックが割り当てられなかった葉ノードには、ダミーデータ（乱数）を割り当てる。
１４０６：葉ノードのひとつ上（ルートノードに近い側）のノードに、左下の葉ノードのハッシュ値と、右下の葉ノードのハッシュ値を結合したデータを割り当てる。これをルートノードに至るまで再帰的に繰り返す。
１４０７：ルートノードに割り当てられた値に対し、署名を生成する（署名は公知の電子署名技術を用いればよい）。
１４０８：二分木の構造を定義するデータと、各葉ノードの値（乱数ブロックまたはダミーデータ）と、ステップ１４０７で生成された署名値とを、署名つきのオリジナル文書として出力する。
１４０９：おわり。
【００７６】
図１５は、第４の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。
１５０１：はじめ。
１５０２：開示対象である署名付きオリジナル文書の中から、開示不適切な情報を含むブロックを検索する。
１５０３：これら開示不適当なブロックまたはダミーブロックのみを葉ノードとして含む部分木（複数あってもよい）を検索し、各部分木のルートノードの値を、ステップ１４０６と同様にして計算する。
１５０４：オリジナル文書に含まれる二分木の構造を定義するデータから、ステップ１５０３で検索された部分木の部分を取り除き、あらたな二分木の構造を定義するデータを作る。また、計算された部分木のルートノードの値を部分木が取り除かれた二分木の葉ノードの値とする（あらたなダミーデータとみなす）。
１５０５：新たに作られた二分木の構造を定義するデータと、各葉ノードの値（乱数ブロックまたはダミーデータ）と、署名付きオリジナル文書に含まれる署名値とを、開示文書として出力する。
１５０６：おわり。
【００７７】
図１６は、第４の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
１６０１：はじめ。
１６０２：ステップ１４０６と同様にしてルートノードの値を計算する。
１６０３：与えられた署名値が、ルートノードの値に対する署名として正しいか否かを検証する（ステップ１４０７で用いた署名生成方法に対応した公知の署名検証技術を用いればよい）。
１６０４：おわり。
【００７８】
本実施形態に従えば、あらかじめ用意されたダミーデータ（ステップ１４０５）と、開示文書作成PG２３０の処理の過程で計算されたダミーデータ（ステップ１５０４）とが区別つかないため、何ブロック墨塗りしたか、が分からなくすることができるという効果が得られる。
【００７９】
なお、上記各実施形態では、非開示部分は墨塗り、すなわち、黒く塗りつぶした状態で開示する、と述べたが、このほかの方法により非開示処理を行っても良い。
【００８０】
なお、上記各実施形態は主として行政文書を対象として説明したが、これに限定されるものではなく、署名付与後に署名対象部分の適切な改変が望まれることがあるさまざま電子文書に適用可能である。
【００８１】
また、電子文書に限らず、より一般に、画像データ、動画データ、音楽データなどのディジタルデータに対しても適用可能である。この場合のブロックの設定は、それぞれのディジタルデータの構造に合わせて、適切に設定すればよい。
【図面の簡単な説明】
【００８２】
【図１】第１の実施形態を実現するネットワークシステムの概略構成図である。
【図２】第１の実施形態におけるオリジナル文書作成者装置１０２を実現する計算機の概略構成図である。
【図３】第１の実施形態におけるオリジナル文書作成・保管時のフローを説明する図である。
【図４】第１の実施形態における情報公開時のフローを説明する図である。
【図５】第１の第１の実施形態に従った署名生成PG２２２の処理フローを示した図である。
【図６】第１の第１の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。
【図７】第１の第１の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
【図８】第２の実施形態に従った署名生成PG２２２の処理フローを示した図である。
【図９】第２の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。
【図１０】第２の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
【図１１】第３の実施形態に従った開示文書作成PG２２２の処理フローを示した図である。
【図１２】第３の実施形態に従って作成された開示文書の様子を模式的に説明した図である。
【図１３】複数の署名者がいる場合に第３の実施形態に従って作成された開示文書の様子を模式的に説明した図である。
【図１４】第４の実施形態に従った署名生成PG２２２の処理フローを示した図である。
【図１５】第４の実施形態に従った開示文書作成PG２３０の処理フローを示した図である。
【図１６】第４の実施形態に従った開示文書検証PG２３３の処理フローを示した図である。
【符号の説明】
【００８３】
１０１：ネットワーク、１０２：オリジナル文書作成者装置、１０３：文書管理装置、１０４：開示文書作成者装置、１０５：受信者装置、１０６：オリジナル文書、１０７：署名つきオリジナル文書、１０８：開示文書。
【図１】
2006060722.tif 000003
【図２】
2006060722.tif 000004
【図３】
2006060722.tif 000005
【図４】
2006060722.tif 000006
【図５】
2006060722.tif 000007
【図６】
2006060722.tif 000008
【図７】
2006060722.tif 000009
【図８】
2006060722.tif 000010
【図９】
2006060722.tif 000011
【図１０】
2006060722.tif 000012
【図１１】
2006060722.tif 000013
【図１２】
2006060722.tif 000014
【図１３】
2006060722.tif 000015
【図１４】
2006060722.tif 000016
【図１５】
2006060722.tif 000017
【図１６】
2006060722.tif 000018