JP2005033396A - 署名生成方法及びデータ交換システム - Google Patents
署名生成方法及びデータ交換システム Download PDFInfo
- Publication number
- JP2005033396A JP2005033396A JP2003194775A JP2003194775A JP2005033396A JP 2005033396 A JP2005033396 A JP 2005033396A JP 2003194775 A JP2003194775 A JP 2003194775A JP 2003194775 A JP2003194775 A JP 2003194775A JP 2005033396 A JP2005033396 A JP 2005033396A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- message
- computer
- signature
- format
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【解決手段】通信委託者計算機0112は、交換データの通信先計算機0113への転送を依頼するため、通信代行サーバ0111にデータ転送要求(MS1)を送信する。通信代行サーバはMS1のダイジェスト値を計算し、通信委託者計算機0112にダイジェスト値を含む署名要求(MS2)を返信する。通信委託者計算機はダイジェスト値を用いて通信委託者の電子署名値を計算し署名データ(MS3)を通信代行サーバへ返送する。通信代行サーバは電子署名値を送信メッセージに付与し、署名付き標準形式メッセージ(Mα)を通信先計算機へ転送する。署名要求には通信代行者の電子署名を付与する事で、署名要求事実を通信代行者が否認出来ないようにする。
【選択図】 図3
Description
【発明の属する技術分野】
本発明は、通信ネットワーク上に接続された計算機システム間でのデータ交換に関する。特に、特定の通信プロトコルに準拠したデータ交換を代行する通信代行サービスに関するもので、有効な適用分野として企業間電子商取引等が挙げられる。
【0002】
【従来の技術】
インターネット等のオープンな通信ネットワーク上に接続された計算機システム間でのデータ交換においては、通信データの機密保護や改竄防止、通信相手の認証、通信データの送受信に関する否認防止、等のセキュリティ上の要件が重要となる。
特に、企業間電子商取引の場合、受発注取引等の重要なデータ交換される場合、これらのセキュリティ要件は必須といえる。
こうしたセキュリティ上の課題を解決する技術として、一般に公開鍵暗号(PKI)技術が普及している。
例えば、電子署名において用いられる技術として、暗号アルゴリズムとしてはRSA暗号(例えば、非特許文献1参照)やDSA暗号等が、ダイジェスト値計算アルゴリズムとしてはMD5(例えば、非特許文献2参照)やSHA−1などが一般的に普及しており、本発明においてもこれらの技術を適用可能である。
【0003】
データ交換時のセキュリティ要件に対する公開鍵暗号の応用技術としては、TLS(例えば、非特許文献3参照)の様に通信路に対してセキュリティ機能を提供するものや、S/MIME(例えば、非特許文献4参照)や XML 電子署名(例えば、非特許文献5参照)の様に通信路を通して交換されるデータを格納したメッセージに対して電子署名や暗号化を行う技術がある。
また、メッセージをパッケージするための形式としてはMIME形式がある(例えば、非特許文献6参照)。
特に、メッセージに対する暗号化や電子署名は、データ交換時のみでなくその後も継続的にセキュリティの効果が得られるのが特長であり、例えば、後日取引文書の内容に関して取引相手が否認出来ない様にする事が可能である。
また近年、オープンなネットワーク環境であるインターネットを利用した企業間電子商取引(B2B)の実現が進んでおり、RosettaNet(例えば、非特許文献7参照)や ebXML(例えば、非特許文献8参照)等の標準仕様が策定されて来ている。
これらの標準仕様では、データ交換における標準交換プロトコル(メッセージ形式や通信プロトコル)の標準も規定しており、更に上述した様なメッセージに対する電子署名付与の形式に関しても規定されている。
こうした標準仕様の登場に伴い、標準仕様に準拠した通信代行サービスへの期待も高まってきている。
これは、標準仕様によってはデータ交換を行う為にサーバ計算機を運用する必要があったり、企業によっては複数の標準仕様に同時に対応する必要があり運用コストが高くつくなど、対応が困難な場合があることによる。
【0004】
図1に、標準仕様に準拠したデータ交換の通信代行を行う通信代行サービスのシステム形態の例を示す。
通信代行者0101、サービスの利用者である通信委託者0102(企業A)、通信先(0103、0104)(企業B、企業C)において、各企業の計算機が設置されるサイトが存在する。
これらのサイトに、通信代行サーバ0111(通信代行者計算機)、通信委託者計算機0112、通信先計算機(0113、0114)がそれぞれ設置されており、通信ネットワーク0131で接続されている。
通信委託企業と通信先企業は、通信代行者を介して、標準仕様に準拠した標準交換プロトコル(標準交換プロトコルα0122、及び標準交換プロトコルβ0123)に基きデータ交換を行う。
この際、通信委託者0102と通信代行者0101間は、通信代行者0101の規定する通信代行サーバ固有の交換プロトコル0121(以後、固有交換プロトコル)に従いデータ交換を行い、通信代行者0101が標準交換プロトコル(0122、0123)に変換することで、通信先(0103、0104)(企業B、企業C)は通信代行者0101を意識する事無く通信委託者0102(企業A)とのデータ交換を行う事が出来る。
また、この際、通信代行者0101は、通信先(0103、0104)(企業B、企業C)に応じて適切な標準交換プロトコルを選択し変換する為、通信委託者0102(企業A)は通信先毎に交換プロトコルの違いを意識する事無く、データ交換を行う事が出来る。
また、秘密鍵情報の委託問題に対する公知技術があり(例えば、特許文献1参照)、また、仲介者を介したデータ通信において、電子署名を用いて受信データの正当性を確認する公知技術(例えば、特許文献2参照)がある。
【非特許文献1】
RFC2437: ”PKCS #1: RSA Cryptography Specifications, Version 2.0” B.Kaliski 他, 1998
【非特許文献2】
RFC1321: ”The MD5 Message−Digest Algorithm”, R.Rivest, 1992
【非特許文献3】
RFC2246: ”The TLS Protocol Version 1.0”, T.Dierks 他, IETF Network Working Group, 1999
【非特許文献4】
RFC2311: ”S/MIME Version 2 Message Specification”, S.Dusse 他, IETF Network Working Group, 1998
【非特許文献5】
”XML−Signature Syntax and Processing”, W3C Recommendation, 2002
【非特許文献6】
RFC1521: ”MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies”, N. Borenstein 他, 1993
【非特許文献7】
”RosettaNet Implementation Framework: Core Specification, Version V02.00.01”, RosettaNet, 2002
【非特許文献8】
”ebXML Message Service Specification, Version 2.0”, OASIS ebXML Messaging Service Technical Committee, 2002
【特許文献1】
特願2002−311829号公報「ICカード」
【特許文献2】
特開2002−24176号公報「データ通信システム、送信者装置、仲介者装置、受信者装置および記録媒体」
【0005】
【発明が解決しようとする課題】
こうした通信代行サービスでは、次の様な課題が存在する。
即ち、通信先企業に対して送信する標準形式メッセージに電子署名を付与する場合、通信代行サーバにて電子署名値の計算を行うが、これには、通信委託企業の秘密鍵情報が必要となる。
メッセージに対する電子署名は、例えば取引内容に対する否認防止の目的で行うものである為、取引当事者である通信委託企業の秘密鍵情報を用いて生成し付与しなければならない為である。
しかしながら、秘密鍵情報はPKI技術においては企業の実印に相当するものであり、通信代行者に対して秘密鍵情報を委託した場合、サービス提供者、及びサービス利用者の何れにとってもリスクが伴う。
上記特許文献1では、委託する秘密鍵情報をICカード中に格納し、電子署名を行う際にはICカード中に格納された制限文により署名対象データのチェックを行っている。
しかしながら、署名対象データの制限条件が複雑な場合は実施が困難となる問題がある。
上記特許文献2では、仲介者を介したデータ通信において、電子署名を用いて受信データの正当性を確認している。
然しながら、特許文献2では受信者は仲介者の存在を意識する必要があり、標準仕様に準拠した交換プロトコルに基いて透過的にサービス利用者とデータ交換を行う様な場合には適用できない。
本発明の目的は、通信委託者の依頼により通信代行者が通信先へ転送する標準形式メッセージに対して、通信委託者が通信代行者へ秘密鍵を委託することなく通信委託者の電子署名を付与することが出来るようにすることにある。
【0006】
【課題を解決するための手段】
上記目的を達成するため、本発明は、通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行うデータ交換システムにおいて、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与する署名生成方法であり、
通信代行者計算機にて、該第二形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信し、通信委託者計算機にて、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求め、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信し、
通信代行者計算機にて、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与するようにしている。
また、通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行い、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与するデータ交換システムであり、
通信代行者計算機は、該第二形式のメッセージに対するダイジェスト値を求める手段と、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する手段を有し、
通信委託者計算機は、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める手段と、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手段を有し、
通信代行者計算機は、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する手段を有するようにしている。
【0007】
【発明の実施の形態】
初めに、一例を挙げて、本発明の概要を説明する。
図17は、上記一例の概略構成を示す。
通信代行者と通信先企業Bとの間のデータ交換は標準形式メッセージを用いて標準交換プロトコルにより行われ、通信代行者と通信委託者企業Aとの間のデータ交換は通信代行者固有のデータ交換プロトコルを用いて行われる。
通信委託者企業A(以下、Aと省略して記す)は、交換データを通信先企業B(以下、Bと省略して記す)に送信するとき、通信代行者を介して送信する。
まず、Aは、(1)送信する交換データを作成し、(2)データ転送要求を通信委託者に送る。
通信委託者は、Aからのデータ転送要求を受信して、(3)転送データを標準形式メッセージへパッケージングして、(4)交換データ、及び標準形式メッセージのダイジェスト値を計算し、このダイジェスト値を含む署名要求を生成し、更に署名要求に対して通信代行者の秘密鍵(Sc)で署名し、(5)ダイジェスト値と署名を含む署名要求をAに送信する。
Aは、署名要求を受信して、(6)通信代行者の署名の検証を通信代行者の公開鍵(Pc)を用いて行い、(7)オリジナルの交換データのダイジェスト値を計算し、送られてきた書名要求内の交換データのダイジェスト値と比較して検証し、
(8)通信代行者からの署名要求を保存し、(9)標準形式メッセージに対するAの署名値を計算し、即ち標準形式メッセージのダイジェスト値をAの秘密鍵(SA)で暗号化し、(10)通信代行者へ署名値の返信をする。即ち、標準形式メッセージに対するAの署名値を返信する。
通信代行者は、(11)標準形式メッセージにAの署名値を埋込み、(12)ヘッダ情報と交換データとAの署名値を含む標準形式メッセージをBに送信する。
Bでは、(13)受信した標準形式メッセージをAの公開鍵(PA)を用いて確認する。
以上のようにして、交換データはAからBに送信される。このように送信することにより、通信代行者ではAの秘密鍵を保持・管理する必要がなく、また、通信委託者企業Aは通信代行者にAの秘密鍵を渡さなくても済む。これにより、鍵情報の漏洩等のリスクを回避することができる。
例えば、本例を企業間電子商取引(B2B)におけるデータ交換に当てはめると、B2B標準交換プロトコルによるデータ交換をサポートしていない企業Aが、通信代行者に対してB2B標準交換プロトコルによる通信代行を委託することで、B2B標準交換プロトコルをサポートしている取引先の企業Bとビジネス文書等のデー交換を行うといつたケースが考えられる。
【0008】
以下、図を用いて本発明の実施の形態の一実施例を示す。
先ず、図1〜図2を用いて、本実施例におけるシステム構成を示す。
図1に示すように、通信委託者計算機0112、通信代行サーバ0111、通信先計算機(0113、0114)(企業B、企業C)の各計算機は、CPU0141、メモリ0142、通信装置0143、表示装置0144、入力装置0145、補助記憶装置0146とから構成される。
メモリ0142は後述する各プログラムを記憶し、CPU0141により各プログラムの処理は実行される。
また、各計算機は、通信装置0143により通信ネットワーク0131を介して相互に接続されている。
通信代行サーバ0111は、通信委託者計算機0112から受け取った交換データを、通信先計算機(0113、0114)(企業B、企業C)へ転送する。
また逆に、通信先計算機(0113、0114)(企業B、企業C)から転送されたデータを通信委託者計算機0112へ送信する。
この際、通信委託者計算機0112と通信代行サーバ0111間は通信代行サーバ固有の通信プロトコル(固有通信プロトコル0121)に従い通信を行い、通信代行サーバ0111と通信先計算機(0113、0114)(企業B、企業C)との間は通信先計算機に対応した適切な標準交換プロトコル(0122、0123)(α、またはβ)を選択して通信を行う。
【0009】
次に図2を用いて、本実施例における通信代行サーバ0111、及び通信委託者計算機0112の各計算機における処理プログラムの構成と概要を示す。
通信委託者計算機0112側の処理プログラムは、業務処理部0218、通信委託制御部0217、固有形式メッセージ処理部0213、署名生成・検証処理部0212、通信処理部0211の各処理プログラムから構成される。
業務処理部0218は、通信委託制御部0217に対して通信先への交換データの送信指示を行い、また、通信先から受信した交換データを受け取る。
通信処理部0211は、通信ネットワーク0131介して、他の計算機へメッセージの送受信処理を行う。
署名生成・検証処理部0212は、一般的な暗号アルゴリズムやダイジェスト値計算アルゴリズムに基づき、電子署名値の暗号化計算(ダイジェスト値の暗号化による電子署名値の生成、及びその逆変換である電子署名値の復号化によるダイジェスト値の復元)、及びバイナリデータに対するダイジェスト値計算を行う。
固有形式メッセージ処理部0213は、署名生成・検証処理部0212の処理結果を用い、固有交換プロトコルにおいて送受信する各種メッセージ形式の生成、解析、及び固有形式メッセージに対する電子署名の付与や検証とダイジェスト値計算を行う。
通信委託者計算機0112の補助記憶装置0146には、鍵情報0221、及び転送データ情報0223が格納される。
【0010】
通信代行サーバ0111側の処理プログラムは、メッセージ転送制御部0216、標準形式メッセージ処理部、固有形式メッセージ処理部0213、署名生成・検証処理部0212、通信処理部0211の各処理プログラムから構成される。
ここで、固有形式メッセージ処理部0213、署名生成・検証処理部0212、通信処理部0211の各処理プログラムは、通信委託者計算機0112側と同じである。
標準形式メッセージ処理部0214は、通信先計算機(0113、0114)(企業B、企業C)の各標準交換プロトコル(α、β)に対する交換形式メッセージの生成、解析、及び電子署名の付与は検証とダイジェスト値計算を行う。
標準形式メッセージ処理部0214は、α形式メッセージ処理部0215等の、標準形式メッセージ毎のサブ処理プログラムを含む。
メッセージ転送制御部0216は、通信委託者計算機0112から依頼された交換データの転送処理、及び通信先計算機(0113、0114)から受信した交換データの通信委託者計算機への転送処理の全体の制御を行う。
通信代行サーバ0111の補助記憶装置0146には、鍵情報0221、転送メッセージ情報0222、及び通信委託者管理情報0224が格納される。
【0011】
図5〜図8の各図に、補助記憶装置0146内に格納される管理情報の詳細を示す。
図5に、転送データ情報テーブル0501の構造を示す。
転送データ情報テーブル0501は、通信委託者計算機0112と通信代行サーバ0111間で行われる各データ転送処理に関する情報(転送データ情報0223)を保存するテーブルである。
転送識別子カラム0511は、実行された転送処理を一意に特定する転送識別子を格納する。
通信先識別子カラム0512は、各転送処理における通信先を一意に特定する企業識別子を格納する。
送受信種別カラム0513は、転送処理が通信先計算機(0113、0114)への送信処理か、通信先計算機からの受信処理かを示す。
送信処理か受信処理かに応じて、「送信」か「受信」かの何れかの値をとる。
転送要求メッセージカラム0514、署名要求メッセージカラム0515、署名データメッセージカラム0516は、通信委託者計算機0112が通信代行サーバ0111に対して交換データの送信を依頼する際に、両計算機間で交換されるデータ転送要求メッセージ0311、署名要求メッセージ0331、署名データメッセージ0341の各メッセージ(夫々図3参照)を夫々格納する。
最後に、受信データ転送メッセージカラム0517は、通信先計算機(0113、0114)からの交換データ受信時に、通信代行サーバ0111から転送されてきた受信データ転送メッセージ0411(図4参照)を格納する。
データ転送要求メッセージ0311、署名要求メッセージ0331、署名データメッセージ0341、受信データ転送メッセージ0411に関する詳細は、後述する。
【0012】
図6に、転送メッセージ情報テーブル0601の構造を示す。
転送メッセージ情報テーブルは、転送メッセージ情報0222を格納するテーブルであり、通信代行サーバ0111を介して通信先計算機(0113、0114)との間で交換された標準形式メッセージが保存される。
転送識別子カラム0611は、上述した転送データ情報テーブル0501と同様、各転送処理を一意に特定する転送識別子が格納される。
通信委託者識別子カラム0612は、通信委託者の企業識別子を格納するカラムであり、通信代行者が複数の通信委託者を有する場合、何れの通信委託者の転送メッセージかを特定する為に用いられる。
通信先識別子カラム0613は、通信先を一意に特定する企業識別子である。
送受信種別カラム0614は、転送メッセージが通信先へ送信されたものか、通信先から受信したものかを区別する値(「送信」または「受信」の何れか)を格納する。
最後に標準形式メッセージカラム0615は、通信先と交換した標準形式メッセージを格納する。
【0013】
図7に、通信委託者管理情報テーブル0701の構造を示す。
通信委託者管理情報テーブル0701は通信委託者管理情報0224を格納するテーブルである。
通信委託者識別子カラム0711は、通信委託者を一意に特定する通信委託者識別子を格納する。
通信先識別子カラム0713は、上記通信委託者と(通信代行者を介して)データ交換を行う通信先を示す通信先識別子を格納する。
交換プロトコルカラム0715は、上記通信先とデータ交換を行う際に使用する標準交換プロトコルを格納する。
通信先ネットワークアドレスカラム0714は、通信先計算機(0113、0114)が使用する通信ネットワーク上のアドレスを示す。
通信委託者ネットワークアドレス0712は、通信委託者計算機0112が使用するネットワークアドレスを示す。
通信委託者ネットワークアドレス0712は、例えば、通信代行サーバ0111と通信委託者計算機0112間での通信において、通信代行サーバ0111側から通信セッションを開始する必要がある場合に使用する。
【0014】
図8に、鍵情報テーブル0801の構造を示す。
鍵情報テーブルは、各企業の鍵情報0221を格納するテーブルである。
企業識別子カラム0811は、通信先、通信代行者、通信委託者の各企業を一意に識別する企業識別子である。
公開鍵カラム0812は、当該レコードの企業の公開鍵を格納する。
秘密鍵カラム0813は、当該レコードの企業の秘密鍵を格納する。
【0015】
次に、実際に通信代行サーバ0111にて通信代行処理を行う手順を、送信時と受信時に分けて説明する。
本手順の説明において、通信委託者の企業識別子を「A」、通信先の企業識別子を「B」、通信代行者の企業識別子を「Z」とする。
また、通信委託者Aの秘密鍵をSA0011、公開鍵をPA0012、通信先Bの秘密鍵をSB0032、公開鍵をPB0031、通信代行者Zの秘密鍵をSZ0001、公開鍵をPZ0002とする。
各鍵情報は、図3に示すとおり、各計算機における補助記憶装置0146内の鍵情報テーブル0801に格納されている。
【0016】
また、本明細書において、記号dig(y)はデータyのダイジェスト値を示す。
また、記号sgn(x,y)は、yへのxによる電子署名の値を表す。
即ち、yのダイジェスト値dig(y)に対し、xの秘密鍵Sxを用いて暗号化を行ったものである。
署名の検証は一般に、xの公開鍵Pxを用いて電子書名を復号化し、yのダイジェスト値dig(y)と比較することで行う。
こうしたダイジェスト値計算や暗号化処理には、一般的に知られるアルゴリズムを適用することが出来る。
また、メッセージMに対するダイジェスト値の計算方法は個々のメッセージ形式に依存するが、同様にdig(M)で記す。
また、メッセージMに対する電子署名の値はsgn(x,M)で表記し、上記と同様にメッセージのダイジェスト値dig(M)に対して、xの秘密鍵Sxを用いて暗号化を行うことで求められる。
メッセージに対するダイジェスト値の計算方法、及び電子署名の付与方法の一例を、後ほど詳細に説明する。
【0017】
先ず、図3、及び図14を用いて、通信委託者計算機0112から通信代行サーバ0111へ交換データの転送依頼を行う際の処理手順を示す。
図14は、各計算機における処理手順を示すフローチャートである。
左側の破線で囲まれた部分(1401)は通信代行サーバ0111で実行される処理ステップを、右側の破線で囲まれた部分(1402)は通信委託者計算機0112で実行される処理ステップを示している。
図3は、各計算機間でのデータの流れを示す、データフロー図である。
(ステップ1451)業務処理部0218から通信委託制御部0217へ交換データ(D)(0301)及び通信先識別子(通信先の企業識別子)を渡し、転送を依頼する。
通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出し、データ転送要求メッセージ0311を作成する。
【0018】
図9に、データ転送要求メッセージ(MS1)0311の構造を示す。
データ転送要求メッセージ0311は、メッセージヘッダ(HS1)0312、及び交換データ0301から構成される。
ここで、交換データ0301は、業務処理部0218から受け取った交換データである。
メッセージヘッダ(HS1)0312の各フィールドにおいて、メッセージ種別フィールド0901には固定値「データ転送要求」を、通信委託者識別子フィールド0902には通信委託者の企業識別子(この例では、「A」)を、転送識別子フィールド0903にはこの転送要求を一意に特定する転送識別子(この例では、「0001」)を、通信先識別子フィールド0904には業務処理部0218から受け取った通信先識別子(この例では、「B」)を、夫々設定する。
ここで、転送識別子は通信委託制御部0217にて採番する。
【0019】
(ステップ1452):通信委託制御部0217は、通信処理部0211を呼び出し、作成したデータ転送要求メッセージ0311を通信代行サーバ0111へ送信する。
(ステップ1411):通信代行サーバ0111にて、通信処理部0211はデータ転送要求メッセージ0311を受信し、メッセージ転送制御部0216へ渡す。
メッセージ転送制御部0216は、固有形式メッセージ処理部0213を呼び出して受信したデータ転送要求メッセージ0311を解析し、メッセージヘッダ(HS1)0312及び交換データ0301を取得する。
ここで、メッセージ転送制御部0216は、メッセージヘッダ(HS1)0312中のメッセージ種別フィールド0901からメッセージ種別を判定し「データ転送要求」である事を確認する。
メッセージ種別が後述の「署名データ」の場合、ステップ1418から実行する。
(ステップ1412):メッセージ転送制御部0216は、メッセージヘッダ(HS1)0312の通信委託者識別子フィールド0902、及び通信先識別子フィールド0904から、通信委託者、及び通信先を特定する。
更に、図7の通信委託者管理情報テーブル0701において、上記で取得した通信委託者の企業識別子と通信先の企業識別子との組み合わせから、交換プロトコルカラム0715と通信先ネットワークアドレスカラム0714を検索する。
(この例では、交換プロトコルとして「α」、通信先ネットワークアドレスとして「http://www.bbb.com/…」が取得される。
)
(ステップ1413):メッセージ転送制御部0216は、上記ステップ1412で特定した標準交換プロトコルの標準形式メッセージを処理する標準形式メッセージ処理部0214のサブ処理プログラム0215を呼び出し、標準形式メッセージ(Mα)0321を作成する(ここでは、α形式メッセージが生成される。)。
【0020】
図13に、標準形式メッセージ(Mα)0321(0351、0401も同様)の構造を示す。
標準形式メッセージ(Mα)は、メッセージヘッダ(Hα)1311、及び交換データ1312とから構成される。
メッセージヘッダ(Hα)1311の各フィールドにおいて、交換識別子フィールド1321には個々のメッセージを一意に特定する交換識別子を、送信者識別子フィールド1322には本メッセージの送信者の企業識別子を、受信者識別子フィールド1323には本メッセージの受信者の企業識別子を、夫々設定する。
また、送信者電子署名1313には、本メッセージに対する送信者の電子署名の値を計算して設定する(送信者電子署名値1314)。
標準形式メッセージ(Mα)0321のメッセージヘッダ(Hα)0322の各フィールドは、データ転送要求メッセージ(MS1)0311のメッセージヘッダ(HS1)0312の各フィールドの値に応じて、次の様に設定する。
先ず、送信者識別子フィールド1322には、通信委託者識別子フィールド0902から取得した通信委託者の企業識別子を設定する。
受信者識別子フィールド1323には、通信先識別子フィールド0904から取得した転送先の企業識別子を設定する。
最後に、交換識別子フィールド1321には、転送識別子フィールド0903から取得した値を設定する(交換識別子と転送識別子は、その内容は同じものであるが、通信代行サーバと通信先計算機の間でのメッセージの送信の場合には交換識別子と言い、通信代行サーバと通信委託者計算機の間でのメッセージの送信の場合には転送識別子と言う。)。
また、この時点では、標準形式メッセージ(Mα)0321には送信者電子署名1313はまだ付与されていない事に注意する。
本実施例では、固有形式メッセージと標準形式メッセージとのヘッダフィールドの対応付けを上記の様に単純に行ったが、必ずしも両交換プロトコル間で識別子のコード体系や表現形式が一致するとは限らないため、一般には通信代行サーバ0111にてこれらの変換処理や対応付け管理を行う必要がある場合がある。
しかしながら、これらの詳細は本発明の実施においてなんら影響を与えるものではなく、本発明の実施範囲を制限するものではない為、説明を割愛する。
【0021】
(ステップ1414):メッセージ転送制御部0216は、固有形式メッセージ処理部0213を呼び出し、ステップ1411で受信したデータ転送要求メッセージのダイジェスト値(dig(MS1))を計算する。
(ステップ1415):メッセージ転送制御部0216は、標準形式メッセージ処理部0214(α形式メッセージ処理部0215)を呼び出し、ステップ1413で生成した、標準形式メッセージ(Mα)1321のダイジェスト値(dig(Mα))を計算する。
(ステップ1416):メッセージ転送制御部0216は、固有形式メッセージ処理部0213を呼び出し、署名要求メッセージ(MS2)0331を作成し、通信代行者Zの電子署名(sgn(Z,MS2))を付与する。
この際、鍵管理テーブル0801に格納された通信代行者Zの秘密鍵SZ0001を使用する。
また、固有形式メッセージ処理部0213は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の計算は、署名生成・検証処理部0212を呼び出す事で行うことが出来る。
【0022】
図10に、署名要求メッセージ(MS2)0331の構造を示す。
署名要求メッセージ(MS2)0331は、メッセージヘッダ(HS2)0332、データ転送要求メッセージダイジェスト値0333、及び標準形式メッセージダイジェスト値0334から構成される。
また、署名要求メッセージ(MS2)0331には通信代行者電子署名0335が付与される。
データ転送要求メッセージダイジェスト値0333は、ステップ1414にて計算して得られたダイジェスト値(dig(MS1))を設定する。
標準形式メッセージダイジェスト値0334には、ステップ1415にて計算して得られたダイジェスト値(dig(Mα))を設定する。
メッセージヘッダ(HS2)0332の各フィールドにおいて、メッセージ種別フィールド1001には固定値「署名要求」を設定し、その他のフィールドに関してはステップ1411で受信したデータ転送要求メッセージ(MS1)0311のメッセージヘッダ(HS1)0312の対応する各フィールドと同一の値を設定する。
【0023】
(ステップ1417):メッセージ転送制御部0216は、通信処理部0211を呼び出し、署名要求メッセージ0331を通信委託者計算機0112へ送信する。
(ステップ1453):通信委託者計算機0112にて、通信処理部0211は署名要求メッセージ0331を受信し、通信委託制御部0217へ渡す。
通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出して受信した署名要求メッセージ(MS2)0331を解析し、メッセージヘッダ(HS2)0332、データ転送要求メッセージダイジェスト値0333、標準形式メッセージダイジェスト値0334を取得する。
ここで、通信依頼元計算機は、メッセージヘッダ(HS2)0332中のメッセージ種別フィールド1001からメッセージ種別を判定し「署名要求」である事を確認する。
(ステップ1454):通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出し、ステップ1453で受信した署名要求メッセージ(MS2)0331に付与された通信代行者電子署名0335を、通信代行者Zの公開鍵PZ0002を用いて検証する。
即ち、通信代行者電子署名値0336を通信代行者Zの公開鍵PZ0002で復号化し、通信委託者計算機側で再計算した署名要求メッセージ(MS2)0331のダイジェスト値と比較する。
この際、固有形式メッセージ処理部0213は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の復号化の計算は、署名生成・検証処理部0212を呼び出す事で行うことが出来る。
また、通信代行者Zの公開鍵PZ0002は、通信委託者計算機0112の鍵情報テーブル0801に格納しておく。
【0024】
(ステップ1455)通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出し、ステップ1452で送信したデータ転送要求メッセージ(MS1)0311のダイジェスト値を計算する。
更に、得られたダイジェスト値とステップ1453で受信した署名要求メッセージ(MS2)0331内に格納されたデータ転送要求メッセージダイジェスト値0333と比較する。
(ステップ1456):通信委託制御部0217は、署名生成・検証処理部0212を呼び出し、転送形式メッセージ(Mα)0321の電子署名値を計算する。
電子署名値は、ステップ1453で受信した署名要求メッセージ(MS2)0331内に格納された標準形式メッセージダイジェスト値0334を、通信委託者Aの秘密鍵SA0011で暗号化する事で得られる。
通信委託者Aの秘密鍵SA0011は、通信委託者計算機0112の鍵情報テーブル0801に格納しておく。
(ステップ1457):通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出し、署名データメッセージ(MS3)0341を生成する。
【0025】
図11に、署名データメッセージ(MS3)0341の構造を示す。
署名データメッセージ(MS3)0341は、メッセージヘッダ(HS3)0342、及び通信委託者電子署名値0343から構成される。
通信委託者電子署名値0343は、ステップ1456にて生成した、転送形式メッセージ(Mα)0321の電子署名値である。
また、メッセージヘッダ(HS3)0342の各フィールドにおいて、メッセージ種別フィールド1101には固定値「署名データ」を設定し、その他のフィールドに関してはステップ1453で受信した署名要求メッセージ(MS2)0331のメッセージヘッダ(HS2)0332の対応する各フィールドと同一の値を引き継ぐ。
【0026】
(ステップ1458):通信委託制御部0217は、データ転送要求メッセージ0311、署名要求メッセージ0331、署名データメッセージ0341の各固有形式メッセージを、転送データ情報テーブル0501の対応する各カラムへ格納する。
ここでは、併せて他の各カラムの値として転送識別子カラム0511に「0001」、通信先識別子カラム0512に「B」、送受信種別カラム0513に「送信」の各値が設定される。
(ステップ1459):通信委託制御部0217は、通信処理部0211を呼び出し、ステップ1457で作成した署名データメッセージ0341を通信代行サーバ0111へ送信する。
【0027】
(ステップ1418):通信代行サーバ0111にて、通信処理部0211は署名データメッセージ0341を受信し、メッセージ転送制御部0216へ渡す。
メッセージ転送制御部0216は、固有形式メッセージ処理部0213を呼び出して受信した署名データメッセージ0341を解析し、メッセージヘッダ(HS3)0342及び通信委託者電子署名値0343を取得する。
ここで、メッセージ転送制御部0216は、メッセージヘッダ(HS3)0342中のメッセージ種別フィールド1101からメッセージ種別を判定し「署名データ」である事を確認する。
(ステップ1419):メッセージ転送制御部0216は、標準形式メッセージ処理部0214(α形式メッセージ処理部0215)を呼び出し、ステップ1418で取得した通信委託者電子署名値0343を用いて、標準形式メッセージ(Mα)0321に送信者電子署名1313を付与する。
(ステップ1420):ステップ1419にて送信者電子署名を付与した、書名付き標準形式メッセージ(Mα)0351を、転送メッセージ情報テーブルの標準形式メッセージカラム0615へ保存する。
ここでは、併せて各カラムの値として転送識別子カラム0611に「0001」、通信委託者識別子カラム0612に「A」、通信先識別子カラム0613に「B」、送受信種別カラム0614に「送信」の各値が設定される。
(ステップ1421):最後に、メッセージ転送制御部0216は通信処理部0211を呼び出し、ステップ1419で作成した書名付き標準形式メッセージ(Mα)0351を、通信先計算機0113へ送信する。
【0028】
次に、図4、及び図15を用いて、通信代行サーバ0111から通信委託者計算機0112へ、通信先計算機から受信した交換データを転送する際の処理手順を示す。
図15は、各計算機における処理手順を示すフローチャートである。
左側の破線で囲まれた部分(1501)は通信代行サーバ0111で実行される処理ステップを、右側の破線で囲まれた部分(1502)は通信委託者計算機0112で実行される処理ステップを示している。
図4は、各計算機間でのデータの流れを示す、データフロー図である。
【0029】
(ステップ1511):通信代行サーバ0111にて、通信処理部0211は通信先計算機0113より標準形式メッセージ(Mα)0401を受信し、メッセージ転送制御部0216へ渡す。
メッセージ転送制御部0216は、標準形式メッセージ処理部0214(α形式メッセージ処理部0215)を呼び出し、受信した標準形式メッセージ(Mα)0401を解析し、メッセージヘッダ(Hα)0402及び交換データ(D)0403を取得する。
ここで、メッセージヘッダ(Hα)0402の各フィールドの値は、交換識別子1321が「0002」、送信者識別子1322が「B」、受信者識別子1323が「A」であったとし、以下説明を進める。
【0030】
(ステップ1512):メッセージ転送制御部0216は、メッセージヘッダ(Hα)0402中の送信者識別子1322から通信先の企業識別子を特定し(ここでは、「B」)、鍵情報テーブル0801の公開鍵カラム0812から通信先の公開鍵を取得する(ここでは、PB0031)。
更に、メッセージ転送制御部0216は、標準形式メッセージ処理部0214(α形式メッセージ処理部0215)を呼び出し、取得した公開鍵PB0031を用いて送信者電子署名0404(1313)を検証する。
(ステップ1513):メッセージ転送制御部0216は、固有形式メッセージ処理部0213を呼び出し、受信データ転送メッセージ(MS4)0411を作成する。
更に、通信代行者(ここでは、Z)の秘密鍵を用いて受信データ転送メッセージ(MS4)0411に対して通信代行者電子署名0413を付与する。
【0031】
図12に、受信データ転送メッセージ(MS4)0411の構造を示す。
受信データ転送メッセージ(MS4)0411は、メッセージヘッダ(HS4)0412、交換データ(D)0403、標準形式メッセージ(Mα)0401から構成される。
また、受信データ転送メッセージ(MS4)0411には通信代行者電子署名0413が付与される。
ここで、交換データ(D)0403は、ステップ1512にて取得した交換データである。
また、標準形式メッセージ(Mα)0401は、ステップ1511で受信した標準形式メッセージ(Mα)である。
また、メッセージヘッダ(HS4)0412の各フィールドにおいて、メッセージ種別フィールド1201には固定値「受信データ転送」を設定する。
また、その他のフィールドは標準形式メッセージ(Mα)0401のメッセージヘッダ(Hα)0402の各フィールドの値に応じて、次の様に設定する。
先ず、通信委託者識別子フィールド1202には、受信者識別子フィールド1323から取得した企業識別子を設定する。
通信先識別子フィールド1204には、送信者識別子フィールド1322から取得した企業識別子を設定する。
最後に、転送識別子フィールド1203には、交換識別子フィールド1321から取得した値を設定する。
ここでは、通信委託者識別子フィールド1202に「A」、通信先識別子フィールド1204に「B」、転送識別子フィールド1203に「0002」が設定される。
【0032】
(ステップ1514):ステップ1511で受信した標準形式メッセージ(Mα)0401を、転送メッセージ情報テーブル0601の標準形式メッセージカラム0615へ保存する。
ここでは、併せて各カラムの値として転送識別子カラム0611に「0002」、通信依頼元識別子カラム0612に「A」、通信先識別子カラム0613に「B」、送受信種別カラム0614に「受信」の各値が設定される。
(ステップ1515):メッセージ転送制御部0216は、通信処理部0211を用いて、受信データ転送メッセージ(MS4)0411を通信委託者計算機0112へ送信する。
【0033】
(ステップ1551):通信委託者計算機0112にて、通信処理部0211は受信データ転送メッセージ(MS4)0411を受信し、通信委託制御部0217へ渡す。
通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出して受信した受信データ転送メッセージ(MS4)0411を解析し、メッセージヘッダ(HS4)0412、交換データ(D)0403、及び標準形式メッセージ(Mα)0401を取得する。
ここで、通信委託者計算機0112は、メッセージヘッダ(HS4)0412中のメッセージ種別フィールド1201からメッセージ種別を取得し「受信データ転送」である事を確認する。
【0034】
(ステップ1552):通信委託制御部0217は、固有形式メッセージ処理部0213を呼び出し、ステップ1551で受信した受信データ転送メッセージ(MS4)0411に付与された通信代行者電子署名0413を、通信代行者Zの公開鍵PZ0002を用いて検証する。
即ち、通信代行者電子署名値0414を通信代行者Zの公開鍵PZ0002で復号化し、通信委託者計算機側で再計算した受信データ転送メッセージ(MS4)0411のダイジェスト値と比較する。
この際、固有形式メッセージ処理部0213は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の復号化の計算は、署名生成・検証処理部0212を呼び出す事で行うことが出来る。
また、通信代行者Zの公開鍵PZ0002は、通信委託者計算機0112の鍵情報テーブル0801に格納しておく。
【0035】
(ステップ1553):通信委託制御部0217は、受信データ転送メッセージ(MS4)0411を、転送データ情報テーブル0501の対応する各カラムへ格納する。ここで、格納された受信データ転送メッセージ(MS4)0411は、例えば、通信委託者と通信代行者との間で、何らかのトラブルが発生したような場合に、受信データ転送メッセージ(MS4)が通信委託者に受信されていることを証明するために使用される。
ここでは、併せて他の各カラムの値として転送識別子カラム0511に「0002」、通信先識別子カラム0512に「B」、送受信種別カラム0513に「送信」の各値が設定される。
(ステップ1554):通信委託制御部0217は、ステップ1551で取得した交換データ(D)0403を業務処理部へ受け渡す。
次に、図16を用いて、メッセージに対するダイジェスト値の計算方法、及び電子署名の付与方法の一例を説明する。
【0036】
図16は、例として標準形式メッセージ(Mα)1301を題材にその形式をより具体的に記述した例である。
本形式例では、標準形式メッセージ(Mα)1301は、その各構成要素をMIME形式(前述の非特許文献6参照)にてパッケージしている。
記号1621の示す行は、パッケージ全体が複数パートからなるMIME形式であり、各パートが境界文字列「−−boundary」で区切られることを示す。
記号1622の示す行は、各パートを区切る境界文字列を示す。
記号1623、及び1624の示す行は、各パートのヘッダ行で、行1623はパートの内容タイプ(Content−Type)を、行1624はパッケージ内で内容を一意に示す内容識別子(Content−ID)を示している。
例えば、メッセージヘッダ1311の内容タイプは「application/octet−stream」、内容識別子は「header」である。
最後のパートには、送信者電子署名1313がXML電子署名の形式で表現され、格納されている。
記号1631の示す行は、本XML文書がXML電子署名(Signature 要素)である事を表している。
【0037】
記号1614の示す枠線で囲まれた部分は電子署名情報を表し、署名対象に含める各パートに対する参照情報(Reference 要素)を含む。
各参照情報(記号1615、及び1616の示す枠線で囲まれた部分)には、参照先のデータに対するダイジェスト値が含まれる。
ちなみに、記号1615で示す枠線で囲まれた部分には、メッセージヘッダ1311に対するダイジェスト値が格納され、記号1616で示す枠線で囲まれた部分には、交換データ1312に対するダイジェスト値が格納される。
記号1633の示す行は、署名対象に含めるパートの内容識別子を指定する。
記号1634の示す行は、ダイジェスト値を計算する際に使用するアルゴリズムを指定する。
ここでは、SHA−1アルゴリズムが使用されている。
記号1635の示す行には、行1633により参照されるパートを対象に、行1644に示されるアルゴリズムで計算したダイジェスト値が格納される。
こうして、電子署名情報1614(記号1614の示す枠線で囲まれた部分)には、メッセージヘッダ1311と交換データ1312の夫々のダイジェスト値が含まれる事になる。
従って、更に電子署名情報1614に対するダイジェスト値を計算する事により、標準形式メッセージ(Mα)1301に対するダイジェスト値を計算した事になる。
【0038】
記号1632の示す行には、電子署名情報1614に対するダイジェスト値を計算するアルゴリズムと、得られたダイジェスト値に対する電子署名値を生成するための暗号化アルゴリズムの組が指定されている。
ここでは、ダイジェスト値の計算アルゴリズムとしてSHA−1が、暗号化アルゴリズムとしてDSAが指定されている。
即ち、電子署名情報1614に対してSHA−1アルゴリズムで計算したダイジェスト値が、標準形式メッセージ(Mα)1301に対するダイジェスト値(dig(Mα))となり、得られたダイジェスト値に対してDSAアルゴリズムを用いて暗号化して結果が標準形式メッセージ(Mα)1301に対する電子署名値(送信者電子署名値1314)(sgn(x,Mα)、xは送信者を示す)となる。
送信者電子署名値1314は、記号1636で示される行に格納される。
ここで、標準形式メッセージ(Mα)1301に対するダイジェスト値は、送信者電子署名1313が標準形式メッセージ(Mα)1301に設定されているか否かに関わらず、同じ値となる。
【0039】
以上に示してきた様に、本発明では以下が可能となる。
第一に、本発明によれば、通信委託者の依頼により通信代行者が通信先へ転送する標準形式メッセージに対して、通信委託者が通信代行者へ秘密鍵を委託する事無く通信委託者の電子署名を付与する事が出来る。
これにより、通信委託者は(自社の実印にあたる)秘密鍵を、第三者である通信代行者に委託するリスクを回避することが出来るとともに、通信代行者にとっても通信委託者の秘密鍵に対するセキュリティ上の管理リスクを回避する事が出来る。
また、通信先は通信代行者を意識する事無く、透過的に通信委託者とデータ交換が可能となる。
【0040】
第二に、署名要求メッセージに対して通信代行者の電子署名を付与する事により、不適切な内容の標準形式メッセージや任意のデータに対して通信委託者が電子署名を付与させられる事を防止し、転送する標準形式メッセージに対して安全に電子署名を付与する事が出来る。
例えば、問題発生時には通信代行者と通信委託者の間で以下のように責任範囲を明確にする事が出来る。
通信委託者の電子署名が付与された不適切な内容の標準形式メッセージが見つかった場合、通信委託者は転送データ管理テーブルに格納された過去の履歴データから対応する署名要求メッセージを探す。
これは、不適切な内容の標準形式メッセージに対するダイジェスト値を含む署名要求メッセージを検索すればよい。
もし、該当する署名要求メッセージが存在すれば、通信代行者が不正な署名要求をした事になり、署名要求メッセージには通信代行者の電子署名が付与されている為、通信代行者は否認する事が出来ない。
逆に、該当する署名要求メッセージが存在しなければ、通信代行者が不正な署名要求をした事実は存在せず、問題の電子署名を生成した秘密鍵を管理する通信依頼元側に責任があることとなる。
【0041】
第三に、署名要求メッセージ内にデータ転送要求メッセージのダイジェスト値を含めておくことで、通信代行者による署名要求が何れのデータ転送要求に対して行われたのかを確認する事ができる様になる。
転送委託元の電子署名の付与された不正な内容の標準形式メッセージが見つかる等の問題発生時には、転送委託元は自らの送信したデータ転送要求メッセージとそれに対する署名要求メッセージとの組を示す。
これにより、データ転送要求メッセージそのものに誤りがないか否かを後日確認できる。
更に、通信代行者が不正なデータ転送要求メッセージに対して誤って署名要求メッセージを送信してしまっても、不当に責任を負わせられることはない。
【0042】
第四に、通信先へ送信する標準形式メッセージに対して付与する電子署名の署名者を、通信委託者計算機にて動的且つ柔軟に変更可能となる。
例えば、企業間電子商取引においては、交換データの内容に応じて、電子署名を付与する必要のある担当者が異なる場合が考えられる。
これらの切り替えを通信代行サーバで行った場合、通信代行サーバの処理が煩雑になる事が考えられる。
【0043】
第五に、受信データ転送メッセージに対して通信代行者の電子署名を付与する事で、通信代行サーバにて受信した標準形式メッセージの通信委託者計算機への転送内容を保証する事が出来る。
即ち、標準形式メッセージに付与された通信先の電子署名に対する通信代行者での検証事実、及び転送された交換データの内容について、通信委託者では保証を得ることが出来る。
【0044】
最後に、本発明は企業間電子商取引における通信代行サービス事業のみでなく、通信代行サーバを介したデータ交換において、一般的に適用可能な技術である。
【0045】
【発明の効果】
以上に述べたように、本発明によれば、通信委託者は通信代行者に対し自らの秘密鍵を委託する事無く、通信代行者が転送する標準形式メッセージに対して安全に通信委託者の電子署名を付与する事が出来る。
【図面の簡単な説明】
【図1】本発明の一実施例におけるシステム構成を示す第一の図である。
【図2】本発明の一実施例におけるシステム構成を示す第二の図である。
【図3】本発明の一実施例において、交換データの送信時におけるデータフローを示す図である。
【図4】本発明の一実施例において、交換データの受信時におけるデータフローを示す図である。
【図5】本発明の一実施例における、転送データ情報テーブルの構造を示す図である。
【図6】本発明の一実施例における、転送メッセージ情報テーブルの構造を示す図である。
【図7】本発明の一実施例における、通信委託者管理情報テーブルの構造を示す図である。
【図8】本発明の一実施例における、鍵情報テーブルの構造を示す図である。
【図9】本発明の一実施例における、データ転送要求メッセージの構造を示す図である。
【図10】本発明の一実施例における、署名要求メッセージの構造を示す図である。
【図11】本発明の一実施例における、署名データメッセージの構造を示す図である。
【図12】本発明の一実施例における、受信データ転送メッセージの構造を示す図である。
【図13】本発明の一実施例における、標準形式メッセージの構造を示す図である。
【図14】本発明の一実施例において、交換データの送信時における処理のフローチャートを示す図である。
【図15】本発明の一実施例において、交換データの受信時における処理のフローチャートを示す図である。
【図16】本発明の一実施例における、標準形式メッセージへの電子署名付与の方法を示す図である。
【図17】本発明の概要を説明するために挙げた一例の概略構成を示す図である。
【符号の説明】
0101 通信代行者
0102 通信委託者
0103、0104 通信先
0111 通信代行サーバ(通信代行者計算機)
0112 通信委託者計算機
0113、0114 通信先計算機
0211 通信処理部
0212 署名生成・検証処理部
0213 固有形式メッセージ処理部
0214 標準形式メッセージ処理部
0216 メッセージ転送制御部
0217 通信委託制御部
0218 業務処理部
Claims (8)
- 通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行うデータ交換システムにおいて、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与する署名生成方法であって、
通信代行者計算機にて、該第二形式のメッセージに対するダイジェスト値を求める第1のステップと、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する第2のステップと、
通信委託者計算機にて、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める第3のステップと、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する第4のステップと、
通信代行者計算機にて、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する第5のステップと、を含むことを特徴とする署名生成方法。 - 請求項1記載の署名生成方法において、
前記第2のステップにおいて前記署名要求メッセージを通信委託者へ送信する前に、通信代行者の電子署名を該署名要求メッセージに付与することを特徴とする署名生成方法。 - 請求項2記載の署名生成方法において、
前記通信代行者計算機は、前記受信した第一形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を前記署名要求メッセージに含めることを特徴とする署名生成方法。 - 通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行い、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与するデータ交換システムであって、
通信代行者計算機は、該第二形式のメッセージに対するダイジェスト値を求める手段と、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する手段を有し、
通信委託者計算機は、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める手段と、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手段を有し、
通信代行者計算機は、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する手段を有することを特徴とするデータ交換システム。 - 請求項4記載のデータ交換システムにおいて、
通信代行者計算機は、前記署名要求メッセージを通信委託者へ送信する前に、通信代行者の電子署名を該署名要求メッセージに付与する手段を有することを特徴とするデータ交換システム。 - 請求項5記載のデータ交換システムにおいて、
前記通信代行者計算機は、前記受信した第一形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を前記署名要求メッセージに含める手段を有することを特徴とするデータ交換システム。 - 交換データを第一形式のメッセージとして通信代行者計算機へ送信する手順と、
通信代行者計算機から、第一形式のメッセージを変換した第二形式のメッセージのダイジェスト値を含む署名要求メッセージを受信する手順と、
該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する通信委託者の電子署名値を求める手順と、
該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手順をコンピュータに実行させるための通信委託者計算機用プログラムを記録したコンピュータ読み取り可能な記録媒体。 - 通信委託者計算機から交換データを第一形式のメッセージとして受信する手順と、
該受信した交換データを第二形式のメッセージに変換する手順と、
変換後の第二形式のメッセージに対するダイジェスト値を求める手順と、
該ダイジェスト値を含む署名要求メッセージを作成する手順と、
該作成した署名要求メッセージを通信委託者計算機に送信する手順と、
通信委託者計算機から、該署名要求メッセージに対する応答である電子署名値を受信する手順と、
該電子署名値を用いて前記第二形式のメッセージに通信委託者の電子署名を付与する手順をコンピュータに実行させるための通信代行者計算機用プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003194775A JP4167137B2 (ja) | 2003-07-10 | 2003-07-10 | 署名生成方法及びデータ交換システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003194775A JP4167137B2 (ja) | 2003-07-10 | 2003-07-10 | 署名生成方法及びデータ交換システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005033396A true JP2005033396A (ja) | 2005-02-03 |
JP4167137B2 JP4167137B2 (ja) | 2008-10-15 |
Family
ID=34205823
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003194775A Expired - Fee Related JP4167137B2 (ja) | 2003-07-10 | 2003-07-10 | 署名生成方法及びデータ交換システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4167137B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009004853A (ja) * | 2007-06-19 | 2009-01-08 | Nippon Telegr & Teleph Corp <Ntt> | 署名フォーマット変換装置と事前処理装置と署名検証装置、及び署名フォーマット変換方法とプログラムとその記憶媒体 |
EP2257046A2 (en) | 2009-05-27 | 2010-12-01 | Sony Corporation | Image pickup apparatus, electronic device, panoramic image recording method, and program |
JP2010538377A (ja) * | 2007-09-07 | 2010-12-09 | エヌイーシー ヨーロッパ リミテッド | 安全なウェブサービスデータ転送のための方法及びシステム |
-
2003
- 2003-07-10 JP JP2003194775A patent/JP4167137B2/ja not_active Expired - Fee Related
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009004853A (ja) * | 2007-06-19 | 2009-01-08 | Nippon Telegr & Teleph Corp <Ntt> | 署名フォーマット変換装置と事前処理装置と署名検証装置、及び署名フォーマット変換方法とプログラムとその記憶媒体 |
JP2010538377A (ja) * | 2007-09-07 | 2010-12-09 | エヌイーシー ヨーロッパ リミテッド | 安全なウェブサービスデータ転送のための方法及びシステム |
EP2257046A2 (en) | 2009-05-27 | 2010-12-01 | Sony Corporation | Image pickup apparatus, electronic device, panoramic image recording method, and program |
EP2852151A1 (en) | 2009-05-27 | 2015-03-25 | Sony Corporation | Image processing electronic device and method |
Also Published As
Publication number | Publication date |
---|---|
JP4167137B2 (ja) | 2008-10-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8370444B2 (en) | Generating PKI email accounts on a web-based email system | |
US7251728B2 (en) | Secure and reliable document delivery using routing lists | |
JP5204090B2 (ja) | 通信ネットワーク、電子メール登録サーバ、ネットワーク装置、方法、およびコンピュータプログラム | |
US7996673B2 (en) | System, method and computer product for sending encrypted messages to recipients where the sender does not possess the credentials of the recipient | |
AU2005279038B2 (en) | Data certification methods and apparatus | |
US8788811B2 (en) | Server-side key generation for non-token clients | |
US6952768B2 (en) | Security protocol | |
US9137017B2 (en) | Key recovery mechanism | |
US8145707B2 (en) | Sending digitally signed emails via a web-based email system | |
US20020044662A1 (en) | Service message management system and method | |
US20110296171A1 (en) | Key recovery mechanism | |
EP1145507A1 (en) | Web-based delivery of secure e-mail messages | |
JP2005517348A (ja) | 復号化鍵を引き出すための鍵検索を必要とする安全な電子メッセージングシステム | |
WO2001052473A1 (en) | Secure management of electronic documents in a networked environment | |
JP4235824B2 (ja) | 暗号化装置 | |
US8352742B2 (en) | Receiving encrypted emails via a web-based email system | |
Mitchell et al. | CCITT/ISO standards for secure message handling | |
US20030051160A1 (en) | Anti-piracy firmware update | |
JP4167137B2 (ja) | 署名生成方法及びデータ交換システム | |
JP2012181662A (ja) | アカウント情報連携システム | |
Bahreman | PEMToolKit: building a top-down certification hierarchy for PEM from the bottom up | |
Schadow et al. | Secure HL7 Transactions using Internet Mail | |
Narayandas et al. | Building a Universal Secure E-Mail System | |
Al-Hammadi | Certified exchange of electronic mail (CEEM): A nonrepudiation protocol to protect both originator and recipient | |
WO2002033891A2 (en) | Secure and reliable document delivery using routing lists |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050722 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080311 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080408 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080608 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080722 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080731 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110808 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130808 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |