(57)【要約】【課題】  署名の付与されたデータに変更が加えられた場合，変更後のデータが変更前のデータと同じ意味を持つ場合でも，データの記述方法が異なるために署名値が無効になってしまう場合がある。【解決手段】  署名検証に失敗した場合，所定の変換パターンに従い署名対象を含むデータの変換を行ない，その後，変換された後のデータを利用して署名検証を行なう。具体的には、本発明の署名検証装置は，署名対象のデータに所定の変換パターンを適用する変換パターン適用部と，変換パターンを適用した後のデータを利用して署名検証を行なう署名検証部とを有する。【選択図】図２
2006094080.tif 000002
【特許請求の範囲】
【請求項１】
電子署名の検証を行なう署名検証装置であって，予め記憶された変換パターンに従い署名対象のデータに対してCPUによって変換を行なう変換パターン適用部と，変換パターンが適用された後のデータを利用して署名検証を行なう署名検証部，とを有することを特徴とする署名検証装置。
【請求項２】
請求項１記載の署名検証装置であって，変換パターンを適用した後に署名検証に成功した場合，適用した変換パターンもしくは変換パターンを適用した後のデータを出力すること，を特徴とする署名検証装置。
【請求項３】
請求項１記載の署名検証装置であって，前記変換パターン適用部は、署名検証が成功するまで複数種類の変換パターンに基づく変換処理を行なうことを特徴とする署名検証装置。
【請求項４】
請求項１もしくは請求項２に記載の署名検証装置であって，変換パターンの登録を行なう変換パターン登録部を有することを特徴とする署名検証装置。
【請求項５】
請求項４に記載の署名検証装置であって，前記変換パターン登録部は、過去に処理を行なったデータから，所定の頻度を超えて使用された変換パターンを抽出し，変換パターンとして登録することを特徴とする署名検証装置。
【請求項６】
電子署名の検証を行なう署名検証方法であって，
予め記憶された変換パターンに従い署名対象のデータに対してCPUによって変換を行なう変換パターン適用ステップと、
変換パターンが適用された後のデータを利用して署名検証を行なう署名検証ステップと、
を有することを特徴とする署名検証方法。
【請求項７】
請求項６に記載の署名検証方法であって，
変換パターンを適用した後に署名検証に成功した場合，適用した変換パターンもしくは変換パターンを適用した後のデータを出力するステップを有することを特徴とする署名検証方法。
【請求項８】
請求項６に記載の署名検証方法であって，
前記変換パターン適用ステップは、署名検証が成功するまで複数種類の変換パターンに基づく変換処理を行なうことを特徴とする署名検証方法。
【請求項９】
請求項６もしくは請求項７に記載の署名検証方法であって，
変換パターンの登録を行なう変換パターン登録ステップを有することを特徴とする署名検証方法。
【請求項１０】
請求項９に記載の署名検証方法であって，
前記変換パターン登録ステップは、過去に処理を行なったデータから，所定の頻度を超えて使用された変換パターンを抽出し，変換パターンとして登録することを特徴とする署名検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報セキュリティに関するものであり，特に電子署名を検証するための技術に関する。
【背景技術】
【０００２】
電子データの正当性を保証するための技術として電子署名がある。電子署名は，署名対象データの作成者を特定すること，及び，署名が付与された後の署名対象データに対する改ざんを検出すること，を可能とするような電子データであり，例えば公開鍵暗号技術を利用することで実現される。
【０００３】
また，近年XML (Extensible Markup Language)と呼ばれるデータ形式が注目を集めている。XMLは，標準化団体W3C (World Wide Web Consortium)によって仕様が公開されているマークアップ言語の１つであり，各種データを保存する際のフォーマットや，異なる計算機間でデータを交換する際のフォーマットとして利用されている。
【０００４】
特に，Webサービスと呼ばれるシステム連携技術では，データ交換のフォーマットとしてSOAP（Simple Object Access Protocol）と呼ばれるXML形式のメッセージ（以下，SOAPメッセージと記す）を利用することで，異なる環境の計算機間でのシステム連携を実現する。XMLは様々な場面での利用が進められており，XMLデータのセキュリティを確保することは非常に重要な課題である。
【０００５】
XMLのセキュリティに関する仕様として，「XML-Signature Syntax and Processing （〔非特許文献１〕。以下，XML署名と記す。〕〕がある。XML署名は，電子署名に関する情報をXMLで記述するための構文と処理方法を規定した仕様であり，W3Cによって仕様が公開されている。XML署名では，XMLデータに対する署名や，その他任意の電子データに対する署名の方法について規定している。
【０００６】
XMLの記述方法にはある程度の自由度があるため，同じ内容を意味するデータであってもその表現方法が異なることがある。例えば，XMLでは空要素を省略して記述することができる。「<element></element>」と「<element />」は，文字列としては異なるデータであるが，XMLとしては同じ内容を意味している。
【０００７】
電子署名の計算はバイト列に対して行なわれるため，「<element></element>」から計算される署名値と「<element />」から計算される署名値は異なる。しかし「<element></element>」と「<element />」は，XMLとしては同じ内容を意味するため，署名値も同じであることが望ましい。そこでXML署名では，署名値を計算する前に署名対象のXMLデータに対して正規化処理を行なうことになっている。XML署名で利用される正規化処理のアルゴリズムとしては，例えば「Canonical XML（〔非特許文献２〕）」などがある。
【０００８】
Canonical XMLにより正規化を行なうと，空要素の記述は全て省略されていない形に統一される。すなわち，「<element />」という要素に対してCanonical XMLを用いて正規化を行なうと「<element></element>」という要素が結果として得られる。このように，署名を付与する計算機と署名の検証を行なう計算機において，署名値を計算する前に署名対象データに対して正規化処理を行うことで，記述方法が異なっていても同じ内容を意味するデータに対しては同じ署名値を得ることが可能になる。
【０００９】
【非特許文献１】Donald Eastlake 他，”XML-Signature Syntax and Processing”，[online]，2002年2月12日，W3C，[2004年7月12日検索]，インターネット＜URL：http://www.w3.org/TR/xmldsig-core/＞
【非特許文献２】John Boyer 他，”Canonical XML”，[online]，2001年3月15日，W3C，[2004年7月26日検索]，インターネット＜URL：http://www.w3.org/TR/xml-c14n＞
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし，一般にある２つのXMLデータが同じ意味であるかどうかを判断することは難しく，あらゆるケースに最適である正規化アルゴリズムを規定することは困難である。
【００１１】
例として，下記の２つのデータについて考える。
(1) <a:elem xmlns:a=派ttp://example.org  />
(2) <b:elem xmlns:b=派ttp://exapmle.org  />
(1)では名前空間プレフィックスの値として「a」を使用しており，(2)では名前空間プレフィックスの値として「b」を使用している。その他の点については，２つのデータは全く同じである。「a」や「b」という名前空間プレフィックスの値が意味を持つと考えた場合には２つのデータの意味は異なるが，名前空間プレフィックスの値は意味を持たないと考えた場合には２つのデータの意味は同じである。名前空間プレフィックスの値が意味を持つかどうかは個々のシステムによって異なるため，一般的に決めることはできない。Canonical XMLでは，名前空間プレフィックスの値が意味を持つとし，上記の２つのデータは意味が異なるとしている。よって，名前空間プレフィックスの値が意味を持たないようなシステムではCanonical XMLは最適な正規化アルゴリズムではない。
【００１２】
また，次の例として以下の２つのデータについて考える。
(3) <PhoneNumber>03-1234-56xx</PhoneNumber>
(4) <PhoneNumber>03123456xx</PhoneNumber>
(3)と(4)のデータは，それぞれ電話番号を表わしている。(3)は電話番号の数値をハイフンで区切って記述しているが，(4)では電話番号を区切らずに記述している。(3)と(4)の電話番号は文字列としては異なるデータであるが，同じ電話番号を表わしている。このような個々のシステムに依存した正規化の処理は，Canonical XMLでは対応できない。
【００１３】
上記の２つの問題について，これらの記述方法を統一するような正規化アルゴリズムを規定することは可能である。しかし，その場合，署名を付与する計算機と，署名を検証する計算機において正規化アルゴリズムについて事前に合意を得ておく必要があり，かつ署名を付与する計算機と署名を検証する計算機が，事前に該正規化アルゴリズムを正確に実装したプログラムを有している必要がある。
ある２つのデータを同じ意味であると判断するための条件は，個々のシステムごとに異なるため，全てのシステムにおいて最適であるような汎用的な正規化アルゴリズムを規定することは難しい。個々のシステムごとに，最適な正規化アルゴリズムを規定することもできるが，その場合，署名を付与する側と署名を検証する側において，予め正規化アルゴリズムについて合意を取り，双方の計算機において正規化アルゴリズムを正確に実装したプログラムを有しておく必要がある。個々のシステムについて，このような正規化アルゴリズムを規定し，実装する方法は，非常に手間がかかるため現実的ではない。
【００１４】
本発明は，上記の課題を解決するための技術を提供することを目的としている。すなわち本発明は，署名を付与する計算機と署名を検証する計算機との間で，事前に正規化アルゴリズムについて取り決めをすることなく，意味の変更を伴わないデータの形式のみの変更を検出することを可能とするものである。
【課題を解決するための手段】
【００１５】
本発明の署名検証装置は，署名対象のデータに所定の変換パターンを適用する変換パターン適用部と，変換パターンを適用した後のデータを利用して署名検証を行なう署名検証部とを有する。
【００１６】
本発明の署名検証装置では，署名検証部において署名の付与されたデータに対し，通常の方法を用いて署名の検証を行なう。署名検証に失敗した場合，変換パターン適用部において，予め記憶された変換パターンに従い署名対象のデータの変換を行なう。変換を行った後，署名検証部によって再び署名の検証を行なう。
【発明の効果】
【００１７】
本発明により，意味の変更を伴わないデータ形式だけの変更を検出することが可能になる。また，本発明は署名を付与する計算機と署名を検証する計算機との間で，事前に取り決めをする必要がなく，容易に利用することが可能である。
【発明を実施するための最良の形態】
【００１８】
以下では，XML署名で規定された方法に従って付与された電子署名の検証を行なう場合を例に取り，本発明の実施例の説明を行なう。しかし，本発明は，XML署名によって付与された電子署名の検証を行なう場合だけでなく，他の方法によって付与された電子署名の検証を行なう場合にも適用することができる。以下では，単に「署名」と書く場合は，XML署名で規定された方法に従って付与された電子署名のことを指すものとする。
【実施例１】
【００１９】
本発明の実施例として説明する署名検証装置１０１のハードウェア構成の例を図１に示す。署名検証装置１０１は，CPU１０２と，メモリ１０３と，ハードディスクなどの記憶装置１０４と，キーボードやマウスなどの入力装置１０６と，ディスプレイなどの出力装置１０７と，ネットワークに接続するための通信装置１０５とを備える。署名検証装置１０１は，通信装置１０５を介してインターネットなどのネットワーク１０８に接続されている。本実施例では，ネットワーク１０８を介して署名の付与されたデータを受信する場合を例に取り説明するが，ネットワークを介さずに他の方法によって署名の付与されたデータを取得する場合でも，本発明を適用することは可能である。
【００２０】
署名検証装置１０１において実現される機能及び記憶されているデータを図２に示す。通信処理部２０１は，署名の付与されたデータの受信を行なう。署名検証部２０２は，データに付与されている署名の検証を行なう。署名検証の際には，キーストア２０４に予め記憶された公開鍵を使用する。CPU１０２で実行される署名検証部２０２によって行なわれる署名検証処理は，従来の方法と同様のものである。変換パターン適用部２０３は，署名検証部２０２による署名検証に失敗した場合に呼び出され，変換パターン集２０５に従い，CPU１０２の演算処理によって署名の付与されたデータに対して変換を行なう。変換パターン登録部２０６は，署名検証装置１０１の利用者が変換パターンを変換パターン集２０５に登録する際に利用する。署名検証装置１０１では，CPU１０２がメモリ１０３上に呼び出された所定のプログラムを実行することにより，これらの機能が実現される。
【００２１】
図３に署名の付与されたデータの例を示す。図３に示すデータでは，説明を容易にするために各行の先頭に２桁の行番号を付与しているが，実際のデータに行番号は含まれない。図３の例では，データ交換のプロトコルとしてSOAPを利用しているが，本発明はSOAPを利用するシステムに限定されるものではない。
【００２２】
<soap:Envelope>要素（01行目〜25行目）は，SOAPで決められた要素であり，SOAPメッセージの一番外側に位置する要素である。<soap:Header>要素（02行目〜17行目）は，同じくSOAPで決められた要素であり，例えばセキュリティに関する情報など，SOAPメッセージの管理のための情報を記述する。<ds:Signature>要素（03〜16行目）は，XML署名で規定された方法に従って記述された電子署名に関する情報である。該<ds:Signature>要素には，署名を付与する際に使用した署名アルゴリズム，署名対象のデータに関する情報，署名値などの情報が含まれている。<ds:Reference>要素（09〜13行目）には，署名対象のデータに関する情報が含まれている。該<ds:Reference>要素に付与されているURI属性（09行目）の値は，署名対象に含めるデータを表わす識別子である。該URI属性の値が「#SoapBody」となっていることから，同一XML内のID属性値が「SoapBody」である要素が署名対象に含まれていることが分かる。
【００２３】
図３に示すデータでは，<soap:Body>要素（18〜24行目）がID属性「#SoapBody」を持つものとする。該<soap:Body>要素は署名対象に含まれているため，署名が付与された後に該<soap:Body>要素内のデータに変更が加えられると署名値が無効になる。なお，説明を簡単にするため，本実施例では署名検証に使う公開鍵について予め合意が取れており，署名検証装置１０１において署名検証に利用する公開鍵が予め分かっているものとする。署名検証に使う公開鍵は予め分かっていない場合には，<ds:Signature>要素内に公開鍵に関する情報を記述することもできる。
【００２４】
以下では，図３に示したデータの署名検証を行なう場合を例に取り，署名検証装置１０１における署名検証処理の流れを説明する。
【００２５】
図４に，署名検証装置１０１における署名検証処理の流れを示す。まず，通信処理部２０１によって署名の付与されたデータを受信する（S４０１）。続いて，署名検証部２０２によって，該データに付与された署名の検証を行なう（S４０２）。署名検証の際には，キーストア２０４に記憶されている公開鍵を使用する。署名検証部２０２による署名検証処理は，従来の署名検証方法と同様である。 S４０２において署名検証に成功した場合，署名検証装置１０１は署名検証処理を終了する（S４０３）。この場合，署名対象に含まれるデータが，確かに意図する相手によって作成されたものであり，署名が付与された後にデータが改ざんされていないことが分かる。S４０３によって処理が終了した場合，署名検証装置１０１は出力装置１０７やファイルなどのログに，署名検証に成功したことが分かるデータを出力してもよい。署名検証装置１０１が，他のプログラムによって呼び出されている場合，署名検証装置１０１は，該プログラムに対して署名検証に成功したことを通知してもよい。
【００２６】
S４０２において署名検証に失敗した場合，変換パターン適用部２０３が呼び出される。変換パターン適用部２０３は，変換パターン集２０５に未適用の変換パターンが存在するかどうかを判別する（S４０４）。S４０４において，未適用の変換パターンが存在する場合，受信したデータに対して該変換パターンを適用する（S４０６）。その後，再び署名検証部２０２が呼び出される。署名検証部２０２は，変換された後のデータを用いて再び署名検証処理を行なう（S４０７）。
S４０７において署名検証処理に成功した場合，署名検証装置１０１は署名検証処理を終了する（S４０８）。この場合，通信処理部２０１によって受信したデータについては署名値が無効であるが，変換パターンを適用した後のデータについては署名値が有効である。すなわち，変換パターンを適用した後のデータが，意図する相手によって作成されたものであり，署名が付与された時点から改ざんされていないことが分かる。
【００２７】
S４０８により署名検証処理が終了した場合，署名検証装置１０１は，S４０６において適用した変換パターンに関する情報や，変換パターンを適用した後のデータを出力装置１０７やファイルなどのログに出力してもよい。通常，何らかの原因で署名対象に含まれるデータが変更され署名値が無効になった場合，その原因を特定するのは容易ではない。本実施例を利用し，S４０８によって処理が終了した際に適用した変換パターンに関する情報や変換パターンを適用した後のデータを出力装置１０７やファイルなどのログに出力することで，署名検証装置１０１の利用者は署名値が無効になった原因を容易に特定することができる。
また，変換パターン集２０５に記憶されている変換パターンは，意味の変更を伴わない変換であるとし，変換パターン適用後に署名検証に成功した場合（S４０８）でも，通常の署名検証処理が成功した場合（S４０３）と同様に扱ってもよい。例えば，署名検証装置１０１が，他のプログラムによって呼び出されている場合，該プログラムに対して署名検証に成功したとして通知してもよい。このような処理を行なうことで，意味は変更されていないにもかかわらずデータの形式が変更したために署名検証に失敗するといった，不要な署名検証のエラーを減らすことができる。
【００２８】
S４０７において署名検証処理に失敗した場合，再度変換パターン集２０５に未適用の変換パターンが存在するかどうかの判別がされる（S４０４）。S４０４，S４０６，S４０７の処理は，変換パターン集２０５に記憶された全ての変換パターンを適用するまで繰り返される。
【００２９】
S４０４において，未適用の変換パターンが存在しないと判断された場合，署名検証装置１０１は署名検証処理を終了する（S４０８）。この場合，署名が付与された後に署名対象に含まれるデータに変更が加えられており，その変更によりデータの意味が変わってしまった可能性があることが分かる。
【００３０】
S４０８によって処理が終了した場合，署名検証装置１０１は出力装置１０７やファイルなどのログに，署名検証に失敗したことが分かるデータを出力してもよい。署名検証装置１０１が，他のプログラムによって呼び出されている場合，署名検証装置１０１は，該プログラムに対して署名検証失敗としてエラーを返してもよい。
【００３１】
次に，変換パターン適用部２０３の処理の詳細を説明する。
【００３２】
図５に変換パターン集２０５に記憶された変換パターンの例を示す。図５では，５０４，５０５がそれぞれ１つの変換パターンを表わしている。図５に示した変換パターンは，受信したデータ内に含まれる任意の名前空間について，該名前空間に関連付いたプレフィックスを指定した値に変更するものである。
図５において，No.５０１は各変換パターンに付与された一意の整数であるとする。名前空間URI５０２は，変換しようとするプレフィックスが関連付いている名前空間URIを表わす。プレフィックス５０３は，該変換パターンを適用後に用いられるプレフィックスの値を表わす。
【００３３】
例えば，変換パターン５０４は，No.が「1」であり，受信したデータ内に含まれる名前空間URI「http://www.w3.org/2003/05/soap-envelope」に関連付いているプレフィックスを「S」に変更する，という変換のパターンをあらわす。該変更パターンを図３に示したデータに対して適用した結果のデータを図６に示す。図３のデータでは，名前空間URI「http://www.w3.org/2003/05/soap-envelope」のプレフィックスとして「soap」という値を使用している（01行目，02行目，17行目，18行目，24行目，25行目）。変換後のデータである図６では，これらの「soap」という値が「S」という値に変換されている。
【００３４】
変換パターン適用部２０３は，S４０４において未適用の変換パターンが存在すると判断された場合，未適用の変換パターンのうち，もっともNo.の値が小さい変換パターンを呼び出し，S４０６において該変換パターンを適応するものとする。
以下では，図５に示した変換パターン集を例に取り，変換パターン適用部２０３と署名検証部２０２の処理について説明する。まず，S４０２において署名検証処理に失敗した場合，変換パターン適用部２０３が呼び出される。変換パターン集２０５には，変換パターン５０４と変換パターン５０５の２つの未適用の変換パターンが存在するため，S４０３では未適用の変換パターンが存在すると判断される。変換パターン５０４のNo.は「1」であり，変換パターン５０５のNo.は「2」であるため，より番号の小さい変換パターンである５０４が呼び出され，受信されたデータに対して適用される（S４０６）。その後，変換された後のデータに対して署名検証処理が行なわれる（S４０７）。S４０７において署名検証処理に失敗した場合，再び署名検証部２０３が呼び出される。変換パターン集２０５に記憶された変換パターンのうち，変換パターン５０５はまだ未適用であるため，S４０３では未適用の変換パターンが存在すると判断される。今回は，変換パターンが５０５の１つした存在しないため，該変換パターンが受信したデータに対して適用される（S４０６）。その後，変換された後のデータに対して再び署名検証処理が行なわれる（S４０７）。
【００３５】
次に変換パターン登録部２０６の処理について説明する。
【００３６】
署名検証装置１０１の利用者は，想定される変換パターンを，予め署名検証処理を行なう前に変換パターン集２０５に登録しておく。変換パターンの登録には変換パターン登録部２０６を利用する。
【００３７】
図７に，変換パターン登録部２０６における変換パターン登録処理の流れを示す。変換パターン登録部２０６は，例えば図８に示すような変換パターン登録画面８０１を出力装置１０７に表示する（S７０２）。変換パターン登録画面には，No.入力用のテキストボックス８０２と，名前空間URI入力用のテキストボックス８０３と，プレフィックス入力用のテキストボックス８０４とが表示されている。署名検証装置１０１の利用者は，予め想定される変換パターンに関する情報を，変換パターン登録画面から入力する（S７０３）。図８に示した変換パターン登録画面を例に取ると，変換パターンのNo.をテキストボックス８０２に入力し，変換しようとするプレフィックスが関連付いている名前空間URIをテキストボックス８０３に入力し，該変換パターンを適用後に用いられるプレフィックスの値をテキストボックス８０４に入力する。
【００３８】
変換パターン登録部２０６は，S７０２において入力された情報を元に変換パターン集２０５の内容を更新する（S７０３）。すなわち，テキストボックス８０２に入力された内容を変換パターン集２０５のNo.５０１に，テキストボックス８０３に入力された内容を変換パターン集２０５の名前空間URI５０２に，テキストボックス８０４に入力された内容を変換パターン集２０５のプレフィックス５０３に登録する。
【００３９】
署名検証装置１０１利用者は，変換パターン登録画面８０１を利用することで，例えば一般的によく使われる名前空間URIと名前空間プレフィックスの組み合わせを，変換パターンとして登録しておくことができる。
上記の例では，利用者が変換パターン登録画面８０１を用いて変換パターンを登録する場合を例にとり説明したが，他の方法を用いて変換パターンの登録を行なってもよい。例えば，署名検証装置１０１が過去に受信したデータで利用されていた名前空間URIとプレフィックスの組み合わせを記憶しておき，所定の頻度を超えてよく使われる名前空間URIとプレフィックスの組み合わせや，最近使われた名前空間URIとプレフィックスの組み合わせを変換パターンとして登録してもよい。
上記では，名前空間プレフィックスの値を書き換えるような変換パターンを例にとり説明したが，その他の処理を行なう変換パターンを利用することもできる。
【００４０】
図９は，別の変換パターン集２０５に記憶された別の変換パターンの例である。図９では，９０４，９０５がそれぞれ１つの変換パターンを表わしている。図９に示した変換パターンは，受信したデータ内の任意の要素や属性の値を，指定した値に置換するものである。
【００４１】
図９において，図５の場合と同様にNo.５０１は各変換パターンに付与された一意の整数であるとする。変換対象ノード９０１は，変換対象の要素や属性を特定するための文字列である。変換対象ノード９０１の記述で，「/」は変換対象が要素であることを表わし，その後に続く文字列が要素名を表わすものとする。すなわち「/po:PhoneNumber」は，要素名が「po:PhoneNumber」であるような要素を示す。また，変換対象ノード９０１の記述で，「@」は変換対象が属性であることを表わし，その後に続く文字列が属性名を表わすものとする。すなわち，「@po:immediacy」は，属性名が「po:immediacy」であるような属性を表わす。図９に示した変換パターンは，変換対象ノード９０１で指定した要素や属性の値が，変換前９０２に指定した文字列を含む場合，該文字列を変換後９０３で指定した文字列に置換するものである。変換対象ノード９０１は，他の方法を用いて指定してもよい。
【００４２】
変換パターン９０４は，属性名が「po:immediacy」である属性の値に「0」という文字が含まれる場合，該文字を「false」に置換し，「1」という文字が含まれる場合は該文字を「true」に置換するものである。変換パターン９０４を図３に示すデータに適用した場合，19行目のpo:immediacy属性の値が「true」から「1」に置換される。
【００４３】
変換パターン９０５は，変換後の文字列が指定されていない。これは，要素名が「po:PhoneNumber」である要素の値に「-（ハイフン）」が含まれる場合，該文字を削除することを表わすものとする。変換パターン９０５を図３に示すデータに適用した場合，22行面の「po:PhoneNumber」の値が「03-1234-56xx」から「03123456xx」に置換される。
【００４４】
この他にも，例えばXSLTのような汎用的な変換記述言語を利用して変換パターンを記述してもよい。
【図面の簡単な説明】
【００４５】
【図１】署名検証装置１０１のハードウェア構成を示す図
【図２】署名検証装置１０１によって実現される機能及び署名検証装置１０１に記憶されているデータを示す図
【図３】署名の付与されたメッセージの例を示す図
【図４】署名検証装置１０１における署名検証処理の流れを示す図
【図５】変換パターン集２０５に記憶された変換パターンの例を示す図
【図６】変換パターンを適用した結果のデータの例を示す図
【図７】変換パターン登録部２０６における変換パターン登録処理の流れを示す図
【図８】変換パターン登録画面の例を示す図
【図９】変換パターン集２０５に記憶された変換パターンの例を示す図
【符号の説明】
【００４６】
１０１  署名検証装置
１０８  ネットワーク
２０１  通信処理部
２０２  署名検証部
２０３  変換パターン適用部
２０４  キーストア
２０５  変換パターン集
２０６  変換パターン登録部
８０１  変換パターン登録画面
【図１】
2006094080.tif 000003
【図２】
2006094080.tif 000004
【図３】
2006094080.tif 000005
【図４】
2006094080.tif 000006
【図５】
2006094080.tif 000007
【図６】
2006094080.tif 000008
【図７】
2006094080.tif 000009
【図８】
2006094080.tif 000010
【図９】
2006094080.tif 000011