JP3959240B2 - 情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム - Google Patents
情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム Download PDFInfo
- Publication number
- JP3959240B2 JP3959240B2 JP2001072690A JP2001072690A JP3959240B2 JP 3959240 B2 JP3959240 B2 JP 3959240B2 JP 2001072690 A JP2001072690 A JP 2001072690A JP 2001072690 A JP2001072690 A JP 2001072690A JP 3959240 B2 JP3959240 B2 JP 3959240B2
- Authority
- JP
- Japan
- Prior art keywords
- key
- data
- information processing
- processing apparatus
- key data
- 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.)
- Expired - Fee Related
Links
- 230000005540 biological transmission Effects 0.000 title claims description 106
- 230000010365 information processing Effects 0.000 title claims description 82
- 238000000034 method Methods 0.000 title claims description 55
- 238000006243 chemical reaction Methods 0.000 description 111
- 238000010586 diagram Methods 0.000 description 13
- 238000012545 processing Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 6
- 230000004075 alteration Effects 0.000 description 3
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- KNMAVSAGTYIFJF-UHFFFAOYSA-N 1-[2-[(2-hydroxy-3-phenoxypropyl)amino]ethylamino]-3-phenoxypropan-2-ol;dihydrochloride Chemical compound Cl.Cl.C=1C=CC=CC=1OCC(O)CNCCNCC(O)COC1=CC=CC=C1 KNMAVSAGTYIFJF-UHFFFAOYSA-N 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、立場の異なる三者間を経由してデータの送受信をおこなうデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【０００２】
【従来の技術】
現在、送信者と受信者との間の通信を安全におこなうための暗号化技術としては、一般的に２つの方法、すなわち（１）共通秘密鍵方式と（２）公開鍵方式とが広く知られている。
【０００３】
（１）共通秘密鍵方式は、送信者Ａ・受信者Ｂの双方が同じ鍵を保持し、Ａがその鍵で暗号化したデータを、Ｂが同一の鍵で復号する方式である。ただし、この方式では上記鍵の取得者（Ｂのように正当に入手した者のほか、不正な手段で入手した者を含む）がデータを変造（改竄）、あるいは偽造（捏造）の上、上記鍵で暗号化をおこない、自己がＡであるように詐称して第三者などに送信するいわゆる「なりすまし」を防止することができない。
【０００４】
他方（２）公開鍵方式の代表的なものにＲＳＡがあるが、これは対になる２つの鍵を用意し、一つを秘密鍵として送信者Ａが、もう一つを公開鍵として受信者Ｂが、それぞれ保持する方式である。Ａはこの秘密鍵でデータを暗号化し、Ｂは当該データを、上記秘密鍵と対になる公開鍵で復号する。ＡＢ間で受け渡しされる公開鍵から、秘密鍵を特定することは現実的に不可能なので、秘密鍵が安全に管理されている限り当該鍵による暗号化をおこなえるのはＡのみとなり、上述の「なりすまし」の問題は発生しない。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記従来技術に共通することは、いずれも送信者Ａと受信者Ｂの二者しか考慮していないことである。これに対し、現実社会で発生する種々の取引、関係などはより複雑であって、立場の異なる二者以外に、さらに立場の異なる第三者が関与することもしばしばである。
【０００６】
たとえば、典型的にはクレジットカードによる決済がある。この取引にはカード会社、カード利用者および加盟店の三者が関与している。この決済取引をインターネットなどのネットワーク内において、たとえば上記（２）の公開鍵方式により安全におこなおうとすると、その手順は図１１に示すようなものとなる。
【０００７】
（ａ）鍵の受け渡し
事前に、カード会社Ａは自社用の一対の秘密鍵Ｋａと公開鍵Ｋａ’とを生成し（１）、この公開鍵Ｋａ’を各加盟店に送付しておく（２）。また、各加盟店はそれぞれ自店用の一対の秘密鍵Ｋｃと公開鍵Ｋｃ’とを生成しておく（３）。
【０００８】
（ｂ）カード情報の受け渡し
カードの利用を新規に申し込もうとする者は、まずその本人用の秘密鍵Ｋｂと公開鍵Ｋｂ’とを生成する（４）。そして、このうち公開鍵Ｋｂ’のみを、自己の氏名や住所などの必要事項とともに、カード会社Ａに送付する（５）。なお、この秘密鍵Ｋｂと公開鍵Ｋｂ’とは、上記のようにＢが生成してＫｂ’をＡに渡すのでなく、Ａが生成してＫｂをＢに渡すのであってもよい。
【０００９】
つぎに、カード会社Ａは上記の申し込みを受理すると、当該カード利用者Ｂのカード情報、具体的にはＢのカード番号やＢから受け取った公開鍵Ｋｂ’、その氏名や住所などを、Ａの秘密鍵Ｋａで暗号化（６）の上、Ｂに送付する（７）。
【００１０】
（ｃ）商品の発注／受注
そして、カード利用者Ｂは加盟店Ｃが開設するホームページなどで、希望の商品（有形の物品だけでなく、無形のサービスなども含むものとする）を注文する。具体的には、商品名や個数、金額などの注文内容を、Ｂの秘密鍵Ｋｂにより暗号化し（８）、さらにこれにＡから受け取ったカード情報を追加する（９）ことで、所定のフォーマットの注文書を作成する。そして、この注文書全体を上記ホームページからダウンロード（１０）した加盟店Ｃの公開鍵Ｋｃ’で暗号化（１１）の上、加盟店Ｃに送付する（１２）。
【００１１】
加盟店Ｃでは、カード利用者Ｂから受け取った注文書をＣの秘密鍵Ｋｃで復号し（１３）、さらに復号後の注文書内の、Ａの秘密鍵Ｋａで暗号化されたカード情報を、Ａから受け取った（２）Ａの公開鍵Ｋａ’で復号する（１４）。
【００１２】
この復号されたカード情報内には、上述のようにＢの公開鍵Ｋｂ’が含まれているので、これにより秘密鍵Ｋｂで暗号化された注文内容が復号できる（１５）。また、Ｋｂ’による復号が成功したことをもって、Ｃは上記注文内容がＫｂにより暗号化されていたこと、すなわち上記注文が秘密鍵Ｋｂを保持するＢ本人により発せられたことを確認することができる。
【００１３】
（ｄ）代金の請求・決済
この後、所定の締め日が到来すると、加盟店Ｃはカード会社Ａに対して、カード利用者Ｂの購入代金の支払いを請求する（１６）。カード会社Ａでは利用総額の明細書をカード利用者Ｂに送付して、その確認を得た後、カード利用者Ｂの口座からの代金引き落としと、加盟店Ｃの口座への代金振り込みをおこなう（１７）。
【００１４】
このように、従来技術では複数の鍵による暗号化と復号とを何度もおこなわなければならず、処理が複雑・煩雑である。また、カード利用者Ｂはカード会社Ａから送付されたカード情報（７）を、Ｋｃ’による暗号化のみ（１１）で加盟店Ｃに送付する（１２）ため、たとえば加盟店ＣがＫｃで復号したＢのカード情報（１３）を流用して注文書を偽造し、Ｂになりすまして他の加盟店に注文を出すことを防止できない。
【００１５】
Ｂに送付される利用明細により、事後的なチェックは可能であるものの、不正使用の発見が代金引き落とし後に遅れることも多く、その時点ではＣの行方が分からなくなっていることも多い。
【００１６】
そして、事前予防のためには結局、個々の加盟店が信用できるかどうかをカード会社Ａあるいはカード利用者Ｂが取引の都度調査するしかなくなるが、Ａがインターネット上の店舗を漏れなく調査することは現実的でなく、またＢからの個別の問い合わせ（Ｃが正規の加盟店であるかどうか、など）に逐一Ａが応じるのも負担が大きい。また、Ｂ個人の調査能力には限界があることから、クレジットカードを持っていても、Ｃによるカード番号の不正使用をおそれて電子決済を躊躇するユーザーも多い。
【００１７】
逆に、加盟店としても、受け付けた注文書の作成者がカード利用者本人であるか、あるいは加盟店を装うなどして当該利用者からカード情報を入手した不正取得者であるかの区別がつかないため、別途電子メールなどで本人の確認を取らざるを得ない。しかし、作業負担が大きいわりにたとえば確認メールの到着／不着で本人と押し問答になるケースもあり、必ずしも安全に代金が回収できるとは言えない。
【００１８】
なお、上記のほか一回しか使用できないカード番号を送付する方式、専用のプロバイダを介して取引をおこなうことで、カード番号の送付を避ける方式なども提案されているが、毎回発行の手間がかかり、受け取り相手も特定できない、プロバイダがマージンを取ることが多く、出店数が少ないなどの欠点がある。また、プリペイドカードにより利用額／損害額を一定限度に制限する方式などもあるが、購入の手間がかかる上に少しでも限度額を超えるものは購入できず、使いにくいといった問題がある。
【００１９】
このように、従来技術で安全なカード決済が難しいのは、従来の暗号化・復号化技術がもっぱら二者間の通信を念頭に置いており、三者間の安全な通信をおこなう用途には最適化されていないためである。
【００２０】
この発明は上記従来技術による問題点を解決するため、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけはデータの内容を容易に閲覧することが可能なデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２１】
【課題を解決するための手段】
上述した課題を解決し、目的を達成するため、この発明にかかるデータ送受信システムは、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置がデータを第１の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する第１の送信手段と、を備え、前記第２の情報処理装置が前記第１の送信手段から送信されてきたデータを受信する第１の受信手段と、前記第１の受信手段により受信されたデータを第２の鍵により変換する第２の変換手段と、前記第２の変換手段により変換されたデータを送信する第２の送信手段と、を備え、前記第３の情報処理装置が前記第２の送信手段から送信されてきたデータを受信する第２の受信手段と、前記第２の受信手段により受信されたデータを第３の鍵により変換する第３の変換手段と、を備えたことを特徴とする。
【００２２】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２３】
また、この発明にかかるデータ送受信システムは、第１および第２の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置が第１の鍵により変換されたデータをさらに第２の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する送信手段と、を備え、前記第２の情報処理装置が前記送信手段から送信されてきたデータを受信する受信手段と、前記受信手段により受信されたデータを第３の鍵により変換する第２の変換手段と、を備えたことを特徴とする。
【００２４】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２５】
また、この発明にかかるデータ送受信システムは、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなることを特徴とする。
【００２６】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができる。
【００２７】
また、この発明にかかるデータ送受信方法は、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信方法において、前記第１の情報処理装置で、データを第１の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する第１の送信工程と、前記第２の情報処理装置で、前記第１の送信工程で送信されてきたデータを第２の鍵により変換する第２の変換工程と、前記第２の変換工程で変換されたデータを、前記第２の情報処理装置から前記第３の情報処理装置に送信する第２の送信工程と、前記第３の情報処理装置で、前記第２の送信工程で送信されてきたデータを第３の鍵により変換する第３の変換工程と、を含んだことを特徴とする。
【００２８】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２９】
また、この発明にかかるデータ送受信方法は、第１および第２の情報処理装置間でデータを送受信するデータ送受信方法において、第１の鍵により変換されたデータを、前記第１の情報処理装置でさらに第２の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する送信工程と、前記送信工程で送信されてきたデータを、前記第２の情報処理装置で第３の鍵により変換する第２の変換工程と、を含んだことを特徴とする。
【００３０】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００３１】
また、この発明にかかるデータ送受信方法は、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなることを特徴とする。
【００３２】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができる。
【００３３】
また、この発明にかかるプログラムは、上記のいずれか一つに記載された方法をコンピュータによって実施させることが可能となる。
【００３４】
【発明の実施の形態】
以下に添付図面を参照して、この発明によるデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体の好適な実施の形態を詳細に説明する。
【００３５】
（実施の形態１）
まず、この発明の実施の形態１によるデータ送受信システムのシステム構成について説明する。図１は、実施の形態１によるデータ送受信システムのシステム構成を示す説明図である。図中、１０１はカード会社Ａの管理するコンピュータ、１０２はカード利用者Ｂの保持するコンピュータ、１０３は加盟店Ｃの管理するコンピュータであり、１００は上記の各コンピュータを相互に接続するネットワーク、具体的にはインターネットを示している。
【００３６】
つぎに、この発明の実施の形態１によるデータ送受信システムを構成する、個々のコンピュータのハードウエア構成について説明する。図２は、実施の形態１によるコンピュータ１０１〜１０３のハードウエア構成の一例を示す説明図である。なお、以下では説明の便宜上、各コンピュータは同一のハードウエア構成を有するものとする。
【００３７】
同図において、２０１は装置全体を制御するＣＰＵを、２０２は基本入出力プログラムを記憶したＲＯＭを、２０３はＣＰＵ２０１のワークエリアとして使用されるＲＡＭを、それぞれ示している。
【００３８】
また、２０４はＣＰＵ２０１の制御にしたがってＨＤ（ハードディスク）２０５に対するデータのリード／ライトを制御するＨＤＤ（ハードディスクドライブ）を、２０５はＨＤＤ２０４の制御にしたがって書き込まれたデータを記憶するＨＤを、それぞれ示している。また、２０６はＣＰＵ２０１の制御にしたがってＦＤ（フロッピーディスク）２０７に対するデータのリード／ライトを制御するＦＤＤ（フロッピーディスクドライブ）を、２０７はＦＤＤ２０６の制御にしたがって書き込まれたデータを記憶する着脱自在のＦＤを、それぞれ示している。
【００３９】
また、２０８はカーソル、メニュー、ウィンドウ、あるいは文字や画像などの各種データを表示するディスプレイを、２０９は通信回線２１０を介してインターネット１００への／からのデータの送受信をおこなうネットワークＩ／Ｆ（インターフェース）を、それぞれ示している。また、２１１は文字、数値、各種指示などの入力のための複数のキーを備えたキーボードを、２１２は各種指示の選択や実行、処理対象の選択、カーソルの移動などをおこなうマウスを、それぞれ示している。
【００４０】
また、２１３は文字や画像を光学的に読み取るスキャナを、２１４は文字や画像を用紙上に印刷するプリンタを、２１５は着脱可能な記録媒体であるＣＤ−ＲＯＭを、２１６はＣＤ−ＲＯＭ２１５に対するデータのリードを制御するＣＤ−ＲＯＭドライブを、２００は上記各部を接続するためのバスまたはケーブルを、それぞれ示している。
【００４１】
つぎに、この発明の実施の形態１によるデータ送受信システムの機能的構成について説明する。図３は、実施の形態１によるデータ送受信システムの構成を機能的に示す説明図である。
【００４２】
同図に示すように、カード会社Ａのコンピュータ１０１は鍵生成部３０１ａ、鍵記憶部３０１ｂ、鍵送信部３０１ｃ、カード情報記憶部３０１ｄ、カード情報暗号化部３０１ｅおよびカード情報送信部３０１ｆを含む構成である。
【００４３】
また、カード利用者Ｂのコンピュータ１０２はカード情報受信部３０２ａ、カード情報記憶部３０２ｂ、鍵受信部３０２ｃ、カード情報変換部３０２ｄ、注文書作成部３０２ｅおよび注文書送信部３０２ｆを含む構成である。
【００４４】
また、加盟店Ｃのコンピュータ１０３は鍵受信部３０３ａ、鍵記憶部３０３ｂ、鍵送信部３０３ｃ、注文書受信部３０３ｄ、カード情報記憶部３０３ｅおよびカード情報復号部３０３ｆを含む構成である。
【００４５】
なお、上記各部は各コンピュータのＨＤ２０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの各種記録媒体からＲＡＭ２０３に読み出されたプログラムの命令にしたがって、ＣＰＵ２０１などが命令処理を実行することにより、後述するそれぞれの機能を実現するものである。また、特にカード利用者Ｂのコンピュータ１０２内の上記各部は、具体的にはブラウザのプラグインにより実現される。
【００４６】
図４は、図６で後述する商品の発注／受注処理に先立って、上記各部によりおこなわれる鍵の受け渡し処理の手順を示すフローチャートである。以下このフローチャートに沿って、上記各部の機能を説明する。
【００４７】
ステップＳ４０１で、まずカード会社Ａのコンピュータ１０１は、その鍵生成部３０１ａにより以下で説明するＹ鍵・Ａ鍵・Ｕ鍵の３つの鍵を生成する。これらの鍵は、「Ｙ鍵で暗号化されたものはＡ鍵による変換後でなければＵ鍵で復号することはできず、Ａ鍵で暗号化されたものはＵ鍵による変換後でなければＹ鍵で復号することはできず、またどの鍵、あるいはどの２つの鍵の組み合わせによっても他の鍵を特定することは困難である」という条件を満たさなければならない。
【００４８】
このような３つの鍵はどのようにして求めてもよいが、ここでは従来技術の公開鍵方式の一種である、ＲＳＡ方式における鍵の導出方法を拡張・応用して求める方法を示す。
【００４９】
ＲＳＡで使用される秘密鍵と公開鍵の２つの鍵は、下記のようにして導出される。まず、２つの素数ＰおよびＱを選び、「Ｎ＝Ｐ＊Ｑ」と「Ｌ＝最小公倍数（Ｐ−１、Ｑ−１）」の２つの値を求める。そして、「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求め（ただしｎは任意の正の整数）、Ｄを秘密鍵、Ｍを公開鍵とする。
【００５０】
これらを使って、下記の計算式により暗号化と復号をおこなう。なお、「Ｄａｔａ ＾Ｄ」はＤａｔａのＤ乗を、また「ｍｏｄ Ｎ」はＮで割った余りを取るという剰余演算を、それぞれ示している。
暗号化：Ｃｏｄｅｄ＝（Ｄａｔａ ＾Ｄ）ｍｏｄ Ｎ
復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ ＾Ｍ）ｍｏｄ Ｎ
【００５１】
これに対して本発明では３つの鍵が必要なので、「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求める代わりに、「Ｙ＊Ａ＊Ｕ＝ｎ＊Ｌ＋１」が成立するＹ、ＡおよびＵを求める。ただしＹ、Ａ、Ｕはそれぞれｎ＊Ｌ＋１であってはならない。このようなＹ、ＡおよびＵの組は、「Ｄ（ｉ）＊Ｍ（ｉ）＝ｎ＊Ｌ＋１」を満足するＤとＭの組から、下記により求めることができる。
【００５２】
Ｙ ＝Ｄ（０）
Ａ（ｉ）＝Ｄ（ｉ）
Ｕ（ｉ）＝（Ｍ（０）＊Ｍ（ｉ）−１）ｍｏｄ Ｌ＋１
【００５３】
そして、これら３つの鍵をもちいて、暗号化と復号とを下記計算式によりおこなう。
暗号化：Ｃｏｄｅｄ ＝（Ｄａｔａ ＾Ｙ）ｍｏｄ Ｎ ・・・（１）
変換 ：Ｃｏｄｅｄ２＝（Ｃｏｄｅｄ ＾Ａ）ｍｏｄ Ｎ ・・・（２）
復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ２ ＾Ｕ）ｍｏｄ Ｎ ・・・（３）
【００５４】
なお、図６で後述するように（１）式による暗号化はカード会社Ａにおける処理、（２）式による変換はカード利用者Ｂにおける処理、また（３）式による復号は加盟店Ｃにおける処理となる。
【００５５】
なお、暗号化も復号も広義では変換に含まれ、ただ変換の目的や結果に着目してこのように呼ぶほうが分かりやすいので、以下では変換のうち特に変換前のデータが平文であるような変換を暗号化、逆に変換後のデータが平文であるような変換を復号と、それぞれ呼ぶことにする。
【００５６】
図４に戻り、つぎにステップＳ４０２でカード会社Ａのコンピュータ１０１は、上記で生成した３つの鍵をその鍵記憶部３０１ｂに格納する。また、ステップＳ４０３で上記のうちＡ鍵とＵ鍵とを、その鍵送信部３０１ｃから加盟店Ｃのコンピュータ１０３、具体的にはその鍵受信部３０３ａに送信する。そして、ステップＳ４０４で加盟店Ｃのコンピュータ１０３は、受信した２つの鍵をその鍵記憶部３０３ｂに格納する。
【００５７】
なお、鍵を導出する計算式からも分かるように、一つのＹ鍵に対応するＡ鍵とＵ鍵との組は複数存在する。そして、一つのカード会社Ａに対して複数存在する加盟店Ｃ以下の各加盟店には、カード会社Ａが保持する一つのＹ鍵に対応する、それぞれ異なるＡ鍵とＵ鍵との組が渡される。
【００５８】
つぎに、図５は図６で後述する商品の発注／受注処理に先立って、図３に示す各部によりおこなわれるカード情報の受け渡し処理の手順を示すフローチャートである。以下このフローチャートに沿って、上記各部の機能の説明を続ける。なお、このフローチャートによる処理は、カード会社Ａが申込者Ｂからのカード利用申し込みを受理した時点で開始される。
【００５９】
ステップＳ５０１で、まずカード会社Ａのコンピュータ１０１は、そのカード情報記憶部３０１ｄ内の顧客データベースに、当該申込者（カード利用者Ｂ）のカード情報、具体的にはそのカード番号、氏名、住所、電話番号などを登録する。
【００６０】
ステップＳ５０２で、カード会社Ａのコンピュータ１０１はそのカード情報暗号化部３０１ｅにおいて、カード情報記憶部３０１ｄから取り出したカード利用者Ｂのカード情報を、鍵記憶部３０１ｂから取り出したＹ鍵により暗号化する。すなわち、上述の（１）式にしたがって、「Ｄａｔａ」（ここでは平文のカード情報）から「Ｃｏｄｅｄ」（Ｙ鍵で暗号化後のカード情報）を作成する。
【００６１】
つぎに、ステップＳ５０３でカード会社Ａのコンピュータ１０１は、Ｙ鍵による変換後のカード情報を、そのカード情報送信部３０１ｆからカード利用者Ｂのコンピュータ１０２、具体的にはそのカード情報受信部３０２ａに送信する。そして、ステップＳ５０４でカード利用者Ｂのコンピュータ１０２は、上記で受信したカード情報をそのカード情報記憶部３０２ｂに格納する。
【００６２】
つぎに、図６はこの発明の実施の形態１によるデータ送受信システムにおける、商品の発注／受注処理の手順を示すフローチャートである。以下このフローチャートに沿って、図３に示す各部の機能の説明を続ける。なお、このフローチャートによる処理は、カード利用者Ｂが加盟店Ｃのホームページなどで商品を発注したとき、具体的には所定の注文フォームなどに必要事項を入力して、「ＯＫ」ボタンなどをクリックした時点で開始される。
【００６３】
ステップＳ６０１でカード利用者Ｂのコンピュータ１０２は、その鍵受信部３０２ｃにより、加盟店Ｃのコンピュータ１０３に対してそのＡ鍵を送信するよう要求する。そして、加盟店Ｃのコンピュータ１０３はその鍵送信部３０３ｃで上記要求を受信すると、鍵記憶部３０３ｂに格納されたＡ鍵を取り出して、要求元の鍵受信部３０２ｃに返信する。
【００６４】
つぎに、ステップＳ６０２でカード利用者Ｂのコンピュータ１０２は、そのカード情報変換部３０２ｄにおいて、カード情報記憶部３０２ｂから取り出したカード情報を上記で受信したＡ鍵により変換する。すなわち、上述の（２）式にしたがって、「Ｃｏｄｅｄ」（Ｙ鍵で暗号化後のカード情報）から「Ｃｏｄｅｄ２」（Ｙ鍵で暗号化後さらにＡ鍵で変換されたカード情報）を作成する。
【００６５】
そして、ステップＳ６０３でカード利用者Ｂのコンピュータ１０２は、その注文書作成部３０２ｅにより、商品名や個数などからなる平文の注文内容に上記で変換後のカード情報を付加することで、所定のフォーマットの注文書を作成する。この後、ステップＳ６０４でこの注文書を注文書送信部３０２ｆから送信し、これが加盟店Ｃのコンピュータ１０３の注文書受信部３０３ｄにより受信される。
【００６６】
つぎに、ステップＳ６０５で加盟店Ｃのコンピュータ１０３は、上記で受信した注文書内のカード情報をそのまま（すなわち、Ｙ鍵により暗号化されＡ鍵により変換された状態のまま）カード情報記憶部３０３ｅに格納する。他方、ステップＳ６０６でそのカード情報復号部３０３ｆにおいて、受信した注文書内のカード情報をＵ鍵により復号する。すなわち、上述の（３）式にしたがって、「Ｃｏｄｅｄ２」（Ｙ鍵で暗号化後さらにＡ鍵で変換されたカード情報）から元の「Ｄａｔａ」（平文のカード情報）を復元する。
【００６７】
つぎに図７は、この発明の実施の形態１によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【００６８】
（ａ）鍵の受け渡し
まず、事前にカード会社ＡにおいてＹ鍵・Ａ鍵・Ｕ鍵を生成し（１）、Ａ鍵とＵ鍵の複数の組み合わせの中から一つを選んで、各加盟店に送付しておく（２）。
【００６９】
（ｂ）カード情報の受け渡し
また、各カード利用者のカード情報をこのＹ鍵で暗号化の上（３）、各人に送付しておく（４）。
【００７０】
（ｃ）商品の発注／受注
商品の注文時には、カード利用者Ｂは加盟店ＣのホームページなどからそのＡ鍵をダウンロードして（５）、Ｙ鍵で暗号化後のカード情報をさらにこのＡ鍵で変換し（６）、これを平文の注文内容に追加（７）して注文書を作成し、加盟店Ｃに送付する（８）。なお、これらの処理はブラウザのプラグインにより、注文フォームの送信時に自動的に実行され、特段の操作は必要ない。そして、加盟店Ｃではカード利用者Ｂから受け取った注文書内のカード情報をバックアップするとともに、これをＵ鍵により復号する（９）。
【００７１】
（ｄ）代金の請求・決済
この後所定の締め日が到来すると、加盟店Ｃはカード会社Ａに対して、バックアップしておいたカード情報を請求書に添付して、各利用者の購入代金の支払いを請求する（１０）。
【００７２】
カード会社Ａでは利用総額の明細書を各利用者に送付するとともに、提出されたカード情報のバックアップがＵ鍵で正常に復号できない場合、加盟店Ｃによる偽造の疑いがあると判断し、注文主とされている利用者に別途購入有無の確認を求める。そして、この確認が得られた場合や、Ｕ鍵での復号に異常がなかった場合には、各利用者の口座からの代金引き落としと、各加盟店の口座への代金振り込みをおこなう（１１）。
【００７３】
図１１で示した従来技術に比較して、図７に示す本発明では鍵の個数が半分で、暗号化や復号の手続きも簡略化されていることが分かる。また、カード利用者Ｂから加盟店Ｃに渡る（８）カード情報は、カード会社Ａから送付されてきたカード情報（４）がさらにＡ鍵で変換された（６）ものであり、加盟店ＣではこれをＵ鍵で復号して平文に戻す（９）ことはできても、Ａ鍵による変換前の状態（すなわち、Ｙ鍵により暗号化されただけの状態）に戻すことはできない。
【００７４】
したがって、加盟店Ｃによる注文書の偽造は自店宛以外不可能である。なぜなら、他の加盟店Ｃ’に対する注文書の偽造には、必ずＹ鍵により暗号化されただけの状態の（すなわち、カード会社Ａから送付されたままの状態の）カード情報が必要だからである。
【００７５】
逆に、他の加盟店Ｃ’は、受け取った注文書内のカード情報部分が自己のＵ’鍵で復号できれば、当該カード情報はカード会社Ａから送付された状態のカード情報を保持するカード利用者Ｂ、すなわち正当な権利者によって自己のＡ’鍵で変換されたものと分かり、不正目的の加盟店Ｃがカード利用者Ｂになりすますなどして、注文書を偽造したものではないと判断できる。
【００７６】
以上説明したように実施の形態１によるデータ送受信システムでは、３つの鍵による単純な暗号化でありながら、カード情報の偽造が非常に困難なので、三者間でのカード決済を簡易かつ安全におこなうことができる。
【００７７】
なお、上記では混乱を避けるため説明を省略したが、鍵送信部３０１ｃから鍵受信部３０３ａへの鍵の送信（図７の（２））、カード情報送信部３０１ｆからカード情報受信部３０２ａへのカード情報の送信（同（４））、および注文書送信部３０２ｆから注文書受信部３０３ｄへの注文書の送信（同（８））時には、Ｙ鍵・Ａ鍵・Ｕ鍵とは別の通信用の鍵によって通信内容を暗号化する。ただ、特に前二者については厳重な秘密保持が必要なので、オンラインでなくオフライン、たとえば郵便などによって送付をおこなうようにしてもよい。
【００７８】
（実施の形態２）
さて、上述した実施の形態１は三者が実際に取引に関与する例であったが、現実社会には共通の知人や公的機関の発行した推薦状、紹介状、保証書、証明書などを信用して二者間で取り引きするケースなど、実質的に三者が関与しているとみることができる取引も存在する。そして、このような取引においても、各種書面の偽造や変造がしばしば問題となるので、以下で説明する実施の形態２のように、３つの鍵による暗号化や復号を各種の証書類に応用するのであってもよい。
【００７９】
図８は、実施の形態２によるデータ送受信システムのシステム構成を示す説明図である。図中、８０１は証明者Ａの保持するコンピュータ、８０２は被証明者Ｂの保持するコンピュータ、８０３は被証明者Ｂと取り引きする相手方Ｃの保持するコンピュータであり、８００は上記の各コンピュータを相互に接続するネットワーク、具体的にはインターネットを示している。なお、各コンピュータのハードウエア構成は、図２に示した実施の形態１のそれと同様であるものとする。
【００８０】
つぎに、図９は実施の形態２によるデータ送受信システムの構成を機能的に示す説明図である。同図に示すように、証明者Ａのコンピュータ８０１は鍵記憶部９０１ａ、鍵選択部９０１ｂ、鍵送信部９０１ｃ、証明事項記憶部９０１ｄ、証明書作成部９０１ｅ、証明書暗号化部９０１ｆおよび証明書送信部９０１ｇを含む構成である。
【００８１】
また、被証明者Ｂのコンピュータ８０２は証明書受信部９０２ａ、鍵受信部９０２ｂ、証明書変換部９０２ｃおよび証明書送信部９０２ｄを含む構成である。また、取引先Ｃのコンピュータ８０３は鍵受信部９０３ａ、鍵記憶部９０３ｂ、鍵送信部９０３ｃ、証明書受信部９０３ｄおよび証明書復号部９０３ｅを含む構成である。
【００８２】
なお、上記各部は各コンピュータのＨＤ２０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの各種記録媒体からＲＡＭ２０３に読み出されたプログラムの命令にしたがって、ＣＰＵ２０１などが命令処理を実行することにより、後述するそれぞれの機能を実現するものである。
【００８３】
つぎに、図１０は実施の形態２によるデータ送受信システムにおける、証明書発行・提出処理の手順を示すフローチャートである。以下このフローチャートに沿って、図９に示す各部の機能を説明する。
【００８４】
ステップＳ１００１で、まず取引先Ｃのコンピュータ８０３はその鍵受信部９０３ａから、証明者Ａのコンピュータ８０１に対してＡ鍵とＵ鍵とを送信するよう要求する。この要求をその鍵送信部９０１ｃにより受信した証明者Ａのコンピュータ８０１は、ステップＳ１００２でその鍵選択部９０１ｂにより、あらかじめ生成されて鍵記憶部９０１ａに格納されているＡ鍵とＵ鍵との対のうち、まだ他の個人などに使用されていないいずれかの一対を選択する。そして、ステップＳ１００３でこの選択されたＡ鍵とＵ鍵とを、鍵送信部９０１ｃから要求元の鍵受信部９０３ａに返信する。
【００８５】
取引先Ｃのコンピュータ８０３は、受信したＡ鍵とＵ鍵とを、ステップＳ１００４でその鍵記憶部９０３ｂに格納するとともに、ステップＳ１００５でその鍵送信部９０３ｃから、被証明者Ｂのコンピュータ８０２の鍵受信部９０２ｂに送信する。
【００８６】
また、ステップＳ１００６で被証明者Ｂのコンピュータ８０２は、その証明書受信部９０２ａから証明者Ａのコンピュータ８０１に対して、証明書の発行要求を送信する。この発行要求をその証明書送信部９０１ｇで受信した証明者Ａのコンピュータ８０１は、ステップＳ１００７でその証明書作成部９０１ｅにより、証明事項記憶部９０１ｄに蓄積された各種の証明事項、たとえば住所や生年月日などの中から、上記発行要求中で指定された事項を抽出して、所定のフォーマットの証明書を作成する。
【００８７】
そして、この証明書をステップＳ１００８で証明書暗号化部９０１ｆにより、Ｙ鍵で暗号化の上、ステップＳ１００９で証明書送信部９０１ｇから、要求元の証明書受信部９０２ａに返信する。なお、このＹ鍵で暗号化後の証明書を、以下では「証明書の原本」あるいは単に「原本」と呼ぶ。
【００８８】
そして、ステップＳ１０１０で被証明者Ｂのコンピュータ８０２は、その証明書変換部９０２ｃにより、証明者Ａから受信した証明書の原本を取引先Ｃから受信したＡ鍵で変換する。その後、ステップＳ１０１１でこの変換後の原本を、証明書送信部９０２ｄから取引先Ｃのコンピュータ８０３の証明書受信部９０３ｄに送信する。
【００８９】
そして、ステップＳ１０１２で取引先Ｃのコンピュータ８０３は、上記で受信した変換後の原本を、その証明書復号部９０３ｅでＵ鍵により復号する。
【００９０】
なお、被証明者Ｂは証明者ＡのＹ鍵が入手できない限り、架空の証明書をＹ鍵で暗号化して、あたかも証明者Ａから発行されたかのように見せかけたり（すなわち偽造）、あるいは証明者Ａから受け取った原本をＹ鍵で復号し、内容を改竄の上、再びＹ鍵で暗号化したりする（すなわち変造）ことはできない。また、取引先Ｃも被証明者Ｂから受け取った証明書を、その保持するＵ鍵により平文に戻せるだけで、証明者ＡのＹ鍵が入手できない以上、その偽造や変造は不可能である。無理にこれらをおこなえば、Ｕ鍵による復号が不能か異常となるので、不正行為の事実が発覚する。
【００９１】
したがって、Ｙ鍵の管理が万全である限り、証明書の受領者は逐一その証明者に照会しなくても、受け取った証明書がＵ鍵で正常に復号できたことをもって、当該証明書が真正なものであることを確認できる。
【００９２】
また、被証明者がある取引先用に変換した証明書は、他の取引先では復号できないので（取引先ごとにＡ鍵とＵ鍵とが異なるため）、紛失などの事故があっても意図しない相手に証明書を復号されてしまうことがない。被証明者が原本の変換の時点で、変換に使用する鍵により、当該証明書を閲覧できる相手を限定できると言ってもよい。
【００９３】
なお、上記の証明者としては政府などの公的機関、証明書としては戸籍謄本や住民票などの公的書類が代表的なものであるが、これに限らず証明者や証明書の記載事項はどのようなものであってもよい。
【００９４】
たとえば、あるソフトウエアの登録ユーザーであって、一定期間にわたって登録住所に製品案内などが届いているユーザーは、それだけで住所の安定した、比較的信用できる顧客とみることができる。そこで、ソフトウエアの開発元が証明機関となり、ユーザー登録日や登録製品名、最後に郵便物の送達が確認された日などの各種事項のうち、各登録ユーザーから指定された任意の事項について証明書を作成し、暗号化の上交付する。
【００９５】
インターネットの匿名性により、通信販売やオークションなどでは詐欺などのトラブルが多発しており、たとえば通販会社では据え置き電話のある個人・法人に顧客を絞ったり（携帯電話では信用が取れないため）、他の会社などから顧客リストを購入したりして、多くの費用と労力をかけて顧客の選別をおこなっている。また、オークションでは各人の取引履歴を公開しているものもあるが、信用できる参加者でも最初は信用０であり、逆に信用できない参加者でも別のＩＤを取得すれば容易に別人を装うことができてしまう。
【００９６】
この点、上述のように簡単に運用でき、しかも偽造・変造が困難なユーザー証明書であれば、通販会社やオークションの主催者は、前もって証明書を提出させるだけで、比較的信用できるユーザーに注文者や参加者を絞り込むことができる。
【００９７】
また、被証明者としても、登録ユーザーという従来評価されていなかった一種のステータスを、個人の評価に結びつけることができる。さらに、証明機関であるソフトウエア会社は、証明書の発行時やＡ鍵・Ｕ鍵の交付（あるいは貸与）時に手数料を徴収できるほか、登録ユーザーの地位が社会的に評価されることにともない、ユーザー登録率の向上を期待することができる。
【００９８】
そして、こうしたオープンな証明のシステムが広く運用されることで、従来おこなわれていた顧客リストの闇取引がなくなり、意図しない相手への個人情報の漏洩が低減してゆくことを期待できる。
【００９９】
なお、実施の形態２による取引先とは、必ずしも通信販売やオークションなどの売買取引の相手方に限らない。たとえば、参加者をあるソフトウエアの登録ユーザーに限定している掲示板などにおいて、その管理者にＵ鍵とＡ鍵を、また参加希望者にユーザー証明書を、当該ソフトウエアの開発元からそれぞれ交付するようにすれば、開発元への問い合わせや開発元からの回答を要せず、管理者限りで容易に各希望者の参加資格の有無を確認することができる。
【０１００】
また、上述の実施の形態２では、被証明者からその取引先に対して証明書を提出するようにしたが、被証明者が多数の取引先に同一の証明をおこなわなければならないときは、逆に取引先のほうから被証明者の証明書を取りにゆくようにしてもよい。
【０１０１】
たとえば、被証明者はその開設するホームページに、ソフトウエア会社から取得したユーザー証明書と当該ソフトウエアのロゴを貼り付け、ロゴがクリックされると専用のｃｇｉが起動するようにしておく。そして、このｃｇｉは起動時に閲覧者（すなわち取引先）の保持するＡ鍵を要求し、取得したＡ鍵で証明書の原本を変換の上、当該閲覧者に返信する。閲覧者は取得した証明書をその保持するＵ鍵で復号して、当該被証明者のユーザー登録の詳細を確認することができる。
【０１０２】
また、上述の実施の形態２では、一対のＡ鍵とＵ鍵を特定の個人・法人に限定的に交付することで、証明書の内容がそれ以外の部外者に閲覧されることを避けたが、逆に証明書の内容が世間にアピールしたいようなもの、一般への表示が義務づけられているもの、あるいは少なくとも誰に見られても差し支えないようなものであれば、これらの鍵を証明機関で公開するようにしてもよい。
【０１０３】
たとえば、被証明者は「徳島太郎は一太郎Ｖｅｒ．○の登録ユーザーです」という一文からなる証明書を、当該ソフトウエアの開発元に申し込んで発行してもらう（もちろんＹ鍵により暗号化されているのでこの平文が読めるわけではない）。そして、当該開発元のホームページからダウンロードした汎用のＡ鍵で、この証明書を変換し、このソフトウエアで作成した文書に埋め込んでおく。文書の閲覧者は、上記ホームページからダウンロードした汎用のＵ鍵で変換後の証明書を復号し、上記平文を得る。
【０１０４】
なお、Ａ鍵とＵ鍵とはホームページで公開するのでなく、ソフトウエア自体に組み込んでおき、たとえばメニューから「ユーザー証明書の埋め込み」を選択すると、指定されたデータがＡ鍵により変換されて文書に組み込まれ、また「ユーザー証明書の表示」を選択すると、文書に埋め込まれた変換後のデータがＵ鍵で復号されて表示されるようにしてもよい。
【０１０５】
また、交付された証明書に、当該証明書を埋め込む文書のハッシュキーを添付して、その全体をＡ鍵で変換した上で当該文書に埋め込むようにしてもよい。この文書の閲覧者は、Ｕ鍵で変換後のハッシュキーをＹ鍵を保持する開発元に送付し、Ｙ鍵で復号されたハッシュキーの返信を受けて、手元で計算したハッシュキーの値と一致するかどうかを確認する。そして、両者が一致していれば、当該文書には改竄がないものと判断することができる。
【０１０６】
なお、上述した実施の形態１および２では、データの授受に関与するのがカード会社・カード利用者・加盟店、あるいは証明者・被証明者・被証明者の相手方の三者であったために、Ｙ鍵・Ａ鍵・Ｕ鍵の三種類の鍵を生成するようにしたが、当事者数（厳密には、立場の異なる当事者数。当事者の種別、などと言ってもよい）がそれより多ければ、その数と同数の鍵を生成して本発明を応用することができるのは言うまでもない。
【０１０７】
【発明の効果】
以上説明したようにこの発明によれば、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置がデータを第１の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する第１の送信手段と、を備え、前記第２の情報処理装置が前記第１の送信手段から送信されてきたデータを受信する第１の受信手段と、前記第１の受信手段により受信されたデータを第２の鍵により変換する第２の変換手段と、前記第２の変換手段により変換されたデータを送信する第２の送信手段と、を備え、前記第３の情報処理装置が前記第２の送信手段から送信されてきたデータを受信する第２の受信手段と、前記第２の受信手段により受信されたデータを第３の鍵により変換する第３の変換手段と、を備えたので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信システムが得られるという効果を奏する。
【０１０８】
また、この発明によれば、第１および第２の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置が第１の鍵により変換されたデータをさらに第２の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する送信手段と、を備え、前記第２の情報処理装置が前記送信手段から送信されてきたデータを受信する受信手段と、前記受信手段により受信されたデータを第３の鍵により変換する第２の変換手段と、を備えたので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信システムが得られるという効果を奏する。
【０１０９】
また、この発明によれば、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなるので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができ、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけは当該データの内容を容易に閲覧することが可能なデータ送受信システムが得られるという効果を奏する。
【０１１０】
また、この発明によれば、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信方法において、前記第１の情報処理装置で、データを第１の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する第１の送信工程と、前記第２の情報処理装置で、前記第１の送信工程で送信されてきたデータを第２の鍵により変換する第２の変換工程と、前記第２の変換工程で変換されたデータを、前記第２の情報処理装置から前記第３の情報処理装置に送信する第２の送信工程と、前記第３の情報処理装置で、前記第２の送信工程で送信されてきたデータを第３の鍵により変換する第３の変換工程と、を含んだので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１１】
また、この発明によれば、第１および第２の情報処理装置間でデータを送受信するデータ送受信方法において、第１の鍵により変換されたデータを、前記第１の情報処理装置でさらに第２の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する送信工程と、前記送信工程で送信されてきたデータを、前記第２の情報処理装置で第３の鍵により変換する第２の変換工程と、を含んだので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１２】
また、この発明によれば、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなるので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができ、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけは当該データの内容を容易に閲覧することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１３】
また、この発明によれば、上記方法をコンピュータに実行させるプログラムを記録したことで、当該プログラムをコンピュータで読み取ることが可能となり、これによって、上記方法をコンピュータによって実施することが可能な記録媒体が得られるという効果を奏する。
【図面の簡単な説明】
【図１】 実施の形態１によるデータ送受信システムのシステム構成を示す説明図である。
【図２】 実施の形態１によるデータ送受信システムを構成する、個々のコンピュータのハードウエア構成の一例を示す説明図である。
【図３】 実施の形態１によるデータ送受信システムの構成を機能的に示す説明図である。
【図４】 実施の形態１によるデータ送受信システムにおける、鍵の受け渡し処理の手順を示すフローチャートである。
【図５】 実施の形態１によるデータ送受信システムにおける、カード情報の受け渡し処理の手順を示すフローチャートである。
【図６】 実施の形態１によるデータ送受信システムにおける、商品の発注／受注処理の手順を示すフローチャートである。
【図７】 実施の形態１によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【図８】 実施の形態２によるデータ送受信システムのシステム構成を示す説明図である。
【図９】 実施の形態２によるデータ送受信システムの構成を機能的に示す説明図である。
【図１０】 実施の形態２によるデータ送受信システムにおける、証明書発行・提出処理の手順を示すフローチャートである。
【図１１】 従来技術によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【符号の説明】
１００ インターネット
１０１ カード会社Ａのコンピュータ
１０２ カード利用者Ｂのコンピュータ
１０３ 加盟店Ｃのコンピュータ
２００ バスまたはケーブル
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＨＤＤ
２０５ ＨＤ
２０６ ＦＤＤ
２０７ ＦＤ
２０８ ディスプレイ
２０９ ネットワークＩ／Ｆ
２１０ 通信回線
２１１ キーボード
２１２ マウス
２１３ スキャナ
２１４ プリンタ
２１５ ＣＤ−ＲＯＭ
２１６ ＣＤ−ＲＯＭドライブ
３０１ａ 鍵生成部
３０１ｂ 鍵記憶部
３０１ｃ 鍵送信部
３０１ｄ カード情報記憶部
３０１ｅ カード情報暗号化部
３０１ｆ カード情報送信部
３０２ａ カード情報受信部
３０２ｂ カード情報記憶部
３０２ｃ 鍵受信部
３０２ｄ カード情報変換部
３０２ｅ 注文書作成部
３０２ｆ 注文書送信部
３０３ａ 鍵受信部
３０３ｂ 鍵記憶部
３０３ｃ 鍵送信部
３０３ｄ 注文書受信部
３０３ｅ カード情報記憶部
３０３ｆ カード情報復号部
８００ インターネット
８０１ 証明者Ａのコンピュータ
８０２ 被証明者Ｂのコンピュータ
８０３ 取引先Ｃのコンピュータ
９０１ａ 鍵記憶部
９０１ｂ 鍵選択部
９０１ｃ 鍵送信部
９０１ｄ 証明事項記憶部
９０１ｅ 証明書作成部
９０１ｆ 証明書暗号化部
９０１ｇ 証明書送信部
９０２ａ 証明書受信部
９０２ｂ 鍵受信部
９０２ｃ 証明書変換部
９０２ｄ 証明書送信部
９０３ａ 鍵受信部
９０３ｂ 鍵記憶部
９０３ｃ 鍵送信部
９０３ｄ 証明書受信部
９０３ｅ 証明書復号部
【発明の属する技術分野】
この発明は、立場の異なる三者間を経由してデータの送受信をおこなうデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【０００２】
【従来の技術】
現在、送信者と受信者との間の通信を安全におこなうための暗号化技術としては、一般的に２つの方法、すなわち（１）共通秘密鍵方式と（２）公開鍵方式とが広く知られている。
【０００３】
（１）共通秘密鍵方式は、送信者Ａ・受信者Ｂの双方が同じ鍵を保持し、Ａがその鍵で暗号化したデータを、Ｂが同一の鍵で復号する方式である。ただし、この方式では上記鍵の取得者（Ｂのように正当に入手した者のほか、不正な手段で入手した者を含む）がデータを変造（改竄）、あるいは偽造（捏造）の上、上記鍵で暗号化をおこない、自己がＡであるように詐称して第三者などに送信するいわゆる「なりすまし」を防止することができない。
【０００４】
他方（２）公開鍵方式の代表的なものにＲＳＡがあるが、これは対になる２つの鍵を用意し、一つを秘密鍵として送信者Ａが、もう一つを公開鍵として受信者Ｂが、それぞれ保持する方式である。Ａはこの秘密鍵でデータを暗号化し、Ｂは当該データを、上記秘密鍵と対になる公開鍵で復号する。ＡＢ間で受け渡しされる公開鍵から、秘密鍵を特定することは現実的に不可能なので、秘密鍵が安全に管理されている限り当該鍵による暗号化をおこなえるのはＡのみとなり、上述の「なりすまし」の問題は発生しない。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記従来技術に共通することは、いずれも送信者Ａと受信者Ｂの二者しか考慮していないことである。これに対し、現実社会で発生する種々の取引、関係などはより複雑であって、立場の異なる二者以外に、さらに立場の異なる第三者が関与することもしばしばである。
【０００６】
たとえば、典型的にはクレジットカードによる決済がある。この取引にはカード会社、カード利用者および加盟店の三者が関与している。この決済取引をインターネットなどのネットワーク内において、たとえば上記（２）の公開鍵方式により安全におこなおうとすると、その手順は図１１に示すようなものとなる。
【０００７】
（ａ）鍵の受け渡し
事前に、カード会社Ａは自社用の一対の秘密鍵Ｋａと公開鍵Ｋａ’とを生成し（１）、この公開鍵Ｋａ’を各加盟店に送付しておく（２）。また、各加盟店はそれぞれ自店用の一対の秘密鍵Ｋｃと公開鍵Ｋｃ’とを生成しておく（３）。
【０００８】
（ｂ）カード情報の受け渡し
カードの利用を新規に申し込もうとする者は、まずその本人用の秘密鍵Ｋｂと公開鍵Ｋｂ’とを生成する（４）。そして、このうち公開鍵Ｋｂ’のみを、自己の氏名や住所などの必要事項とともに、カード会社Ａに送付する（５）。なお、この秘密鍵Ｋｂと公開鍵Ｋｂ’とは、上記のようにＢが生成してＫｂ’をＡに渡すのでなく、Ａが生成してＫｂをＢに渡すのであってもよい。
【０００９】
つぎに、カード会社Ａは上記の申し込みを受理すると、当該カード利用者Ｂのカード情報、具体的にはＢのカード番号やＢから受け取った公開鍵Ｋｂ’、その氏名や住所などを、Ａの秘密鍵Ｋａで暗号化（６）の上、Ｂに送付する（７）。
【００１０】
（ｃ）商品の発注／受注
そして、カード利用者Ｂは加盟店Ｃが開設するホームページなどで、希望の商品（有形の物品だけでなく、無形のサービスなども含むものとする）を注文する。具体的には、商品名や個数、金額などの注文内容を、Ｂの秘密鍵Ｋｂにより暗号化し（８）、さらにこれにＡから受け取ったカード情報を追加する（９）ことで、所定のフォーマットの注文書を作成する。そして、この注文書全体を上記ホームページからダウンロード（１０）した加盟店Ｃの公開鍵Ｋｃ’で暗号化（１１）の上、加盟店Ｃに送付する（１２）。
【００１１】
加盟店Ｃでは、カード利用者Ｂから受け取った注文書をＣの秘密鍵Ｋｃで復号し（１３）、さらに復号後の注文書内の、Ａの秘密鍵Ｋａで暗号化されたカード情報を、Ａから受け取った（２）Ａの公開鍵Ｋａ’で復号する（１４）。
【００１２】
この復号されたカード情報内には、上述のようにＢの公開鍵Ｋｂ’が含まれているので、これにより秘密鍵Ｋｂで暗号化された注文内容が復号できる（１５）。また、Ｋｂ’による復号が成功したことをもって、Ｃは上記注文内容がＫｂにより暗号化されていたこと、すなわち上記注文が秘密鍵Ｋｂを保持するＢ本人により発せられたことを確認することができる。
【００１３】
（ｄ）代金の請求・決済
この後、所定の締め日が到来すると、加盟店Ｃはカード会社Ａに対して、カード利用者Ｂの購入代金の支払いを請求する（１６）。カード会社Ａでは利用総額の明細書をカード利用者Ｂに送付して、その確認を得た後、カード利用者Ｂの口座からの代金引き落としと、加盟店Ｃの口座への代金振り込みをおこなう（１７）。
【００１４】
このように、従来技術では複数の鍵による暗号化と復号とを何度もおこなわなければならず、処理が複雑・煩雑である。また、カード利用者Ｂはカード会社Ａから送付されたカード情報（７）を、Ｋｃ’による暗号化のみ（１１）で加盟店Ｃに送付する（１２）ため、たとえば加盟店ＣがＫｃで復号したＢのカード情報（１３）を流用して注文書を偽造し、Ｂになりすまして他の加盟店に注文を出すことを防止できない。
【００１５】
Ｂに送付される利用明細により、事後的なチェックは可能であるものの、不正使用の発見が代金引き落とし後に遅れることも多く、その時点ではＣの行方が分からなくなっていることも多い。
【００１６】
そして、事前予防のためには結局、個々の加盟店が信用できるかどうかをカード会社Ａあるいはカード利用者Ｂが取引の都度調査するしかなくなるが、Ａがインターネット上の店舗を漏れなく調査することは現実的でなく、またＢからの個別の問い合わせ（Ｃが正規の加盟店であるかどうか、など）に逐一Ａが応じるのも負担が大きい。また、Ｂ個人の調査能力には限界があることから、クレジットカードを持っていても、Ｃによるカード番号の不正使用をおそれて電子決済を躊躇するユーザーも多い。
【００１７】
逆に、加盟店としても、受け付けた注文書の作成者がカード利用者本人であるか、あるいは加盟店を装うなどして当該利用者からカード情報を入手した不正取得者であるかの区別がつかないため、別途電子メールなどで本人の確認を取らざるを得ない。しかし、作業負担が大きいわりにたとえば確認メールの到着／不着で本人と押し問答になるケースもあり、必ずしも安全に代金が回収できるとは言えない。
【００１８】
なお、上記のほか一回しか使用できないカード番号を送付する方式、専用のプロバイダを介して取引をおこなうことで、カード番号の送付を避ける方式なども提案されているが、毎回発行の手間がかかり、受け取り相手も特定できない、プロバイダがマージンを取ることが多く、出店数が少ないなどの欠点がある。また、プリペイドカードにより利用額／損害額を一定限度に制限する方式などもあるが、購入の手間がかかる上に少しでも限度額を超えるものは購入できず、使いにくいといった問題がある。
【００１９】
このように、従来技術で安全なカード決済が難しいのは、従来の暗号化・復号化技術がもっぱら二者間の通信を念頭に置いており、三者間の安全な通信をおこなう用途には最適化されていないためである。
【００２０】
この発明は上記従来技術による問題点を解決するため、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけはデータの内容を容易に閲覧することが可能なデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２１】
【課題を解決するための手段】
上述した課題を解決し、目的を達成するため、この発明にかかるデータ送受信システムは、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置がデータを第１の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する第１の送信手段と、を備え、前記第２の情報処理装置が前記第１の送信手段から送信されてきたデータを受信する第１の受信手段と、前記第１の受信手段により受信されたデータを第２の鍵により変換する第２の変換手段と、前記第２の変換手段により変換されたデータを送信する第２の送信手段と、を備え、前記第３の情報処理装置が前記第２の送信手段から送信されてきたデータを受信する第２の受信手段と、前記第２の受信手段により受信されたデータを第３の鍵により変換する第３の変換手段と、を備えたことを特徴とする。
【００２２】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２３】
また、この発明にかかるデータ送受信システムは、第１および第２の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置が第１の鍵により変換されたデータをさらに第２の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する送信手段と、を備え、前記第２の情報処理装置が前記送信手段から送信されてきたデータを受信する受信手段と、前記受信手段により受信されたデータを第３の鍵により変換する第２の変換手段と、を備えたことを特徴とする。
【００２４】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２５】
また、この発明にかかるデータ送受信システムは、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなることを特徴とする。
【００２６】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができる。
【００２７】
また、この発明にかかるデータ送受信方法は、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信方法において、前記第１の情報処理装置で、データを第１の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する第１の送信工程と、前記第２の情報処理装置で、前記第１の送信工程で送信されてきたデータを第２の鍵により変換する第２の変換工程と、前記第２の変換工程で変換されたデータを、前記第２の情報処理装置から前記第３の情報処理装置に送信する第２の送信工程と、前記第３の情報処理装置で、前記第２の送信工程で送信されてきたデータを第３の鍵により変換する第３の変換工程と、を含んだことを特徴とする。
【００２８】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００２９】
また、この発明にかかるデータ送受信方法は、第１および第２の情報処理装置間でデータを送受信するデータ送受信方法において、第１の鍵により変換されたデータを、前記第１の情報処理装置でさらに第２の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する送信工程と、前記送信工程で送信されてきたデータを、前記第２の情報処理装置で第３の鍵により変換する第２の変換工程と、を含んだことを特徴とする。
【００３０】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない。
【００３１】
また、この発明にかかるデータ送受信方法は、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなることを特徴とする。
【００３２】
この発明によれば、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができる。
【００３３】
また、この発明にかかるプログラムは、上記のいずれか一つに記載された方法をコンピュータによって実施させることが可能となる。
【００３４】
【発明の実施の形態】
以下に添付図面を参照して、この発明によるデータ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体の好適な実施の形態を詳細に説明する。
【００３５】
（実施の形態１）
まず、この発明の実施の形態１によるデータ送受信システムのシステム構成について説明する。図１は、実施の形態１によるデータ送受信システムのシステム構成を示す説明図である。図中、１０１はカード会社Ａの管理するコンピュータ、１０２はカード利用者Ｂの保持するコンピュータ、１０３は加盟店Ｃの管理するコンピュータであり、１００は上記の各コンピュータを相互に接続するネットワーク、具体的にはインターネットを示している。
【００３６】
つぎに、この発明の実施の形態１によるデータ送受信システムを構成する、個々のコンピュータのハードウエア構成について説明する。図２は、実施の形態１によるコンピュータ１０１〜１０３のハードウエア構成の一例を示す説明図である。なお、以下では説明の便宜上、各コンピュータは同一のハードウエア構成を有するものとする。
【００３７】
同図において、２０１は装置全体を制御するＣＰＵを、２０２は基本入出力プログラムを記憶したＲＯＭを、２０３はＣＰＵ２０１のワークエリアとして使用されるＲＡＭを、それぞれ示している。
【００３８】
また、２０４はＣＰＵ２０１の制御にしたがってＨＤ（ハードディスク）２０５に対するデータのリード／ライトを制御するＨＤＤ（ハードディスクドライブ）を、２０５はＨＤＤ２０４の制御にしたがって書き込まれたデータを記憶するＨＤを、それぞれ示している。また、２０６はＣＰＵ２０１の制御にしたがってＦＤ（フロッピーディスク）２０７に対するデータのリード／ライトを制御するＦＤＤ（フロッピーディスクドライブ）を、２０７はＦＤＤ２０６の制御にしたがって書き込まれたデータを記憶する着脱自在のＦＤを、それぞれ示している。
【００３９】
また、２０８はカーソル、メニュー、ウィンドウ、あるいは文字や画像などの各種データを表示するディスプレイを、２０９は通信回線２１０を介してインターネット１００への／からのデータの送受信をおこなうネットワークＩ／Ｆ（インターフェース）を、それぞれ示している。また、２１１は文字、数値、各種指示などの入力のための複数のキーを備えたキーボードを、２１２は各種指示の選択や実行、処理対象の選択、カーソルの移動などをおこなうマウスを、それぞれ示している。
【００４０】
また、２１３は文字や画像を光学的に読み取るスキャナを、２１４は文字や画像を用紙上に印刷するプリンタを、２１５は着脱可能な記録媒体であるＣＤ−ＲＯＭを、２１６はＣＤ−ＲＯＭ２１５に対するデータのリードを制御するＣＤ−ＲＯＭドライブを、２００は上記各部を接続するためのバスまたはケーブルを、それぞれ示している。
【００４１】
つぎに、この発明の実施の形態１によるデータ送受信システムの機能的構成について説明する。図３は、実施の形態１によるデータ送受信システムの構成を機能的に示す説明図である。
【００４２】
同図に示すように、カード会社Ａのコンピュータ１０１は鍵生成部３０１ａ、鍵記憶部３０１ｂ、鍵送信部３０１ｃ、カード情報記憶部３０１ｄ、カード情報暗号化部３０１ｅおよびカード情報送信部３０１ｆを含む構成である。
【００４３】
また、カード利用者Ｂのコンピュータ１０２はカード情報受信部３０２ａ、カード情報記憶部３０２ｂ、鍵受信部３０２ｃ、カード情報変換部３０２ｄ、注文書作成部３０２ｅおよび注文書送信部３０２ｆを含む構成である。
【００４４】
また、加盟店Ｃのコンピュータ１０３は鍵受信部３０３ａ、鍵記憶部３０３ｂ、鍵送信部３０３ｃ、注文書受信部３０３ｄ、カード情報記憶部３０３ｅおよびカード情報復号部３０３ｆを含む構成である。
【００４５】
なお、上記各部は各コンピュータのＨＤ２０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの各種記録媒体からＲＡＭ２０３に読み出されたプログラムの命令にしたがって、ＣＰＵ２０１などが命令処理を実行することにより、後述するそれぞれの機能を実現するものである。また、特にカード利用者Ｂのコンピュータ１０２内の上記各部は、具体的にはブラウザのプラグインにより実現される。
【００４６】
図４は、図６で後述する商品の発注／受注処理に先立って、上記各部によりおこなわれる鍵の受け渡し処理の手順を示すフローチャートである。以下このフローチャートに沿って、上記各部の機能を説明する。
【００４７】
ステップＳ４０１で、まずカード会社Ａのコンピュータ１０１は、その鍵生成部３０１ａにより以下で説明するＹ鍵・Ａ鍵・Ｕ鍵の３つの鍵を生成する。これらの鍵は、「Ｙ鍵で暗号化されたものはＡ鍵による変換後でなければＵ鍵で復号することはできず、Ａ鍵で暗号化されたものはＵ鍵による変換後でなければＹ鍵で復号することはできず、またどの鍵、あるいはどの２つの鍵の組み合わせによっても他の鍵を特定することは困難である」という条件を満たさなければならない。
【００４８】
このような３つの鍵はどのようにして求めてもよいが、ここでは従来技術の公開鍵方式の一種である、ＲＳＡ方式における鍵の導出方法を拡張・応用して求める方法を示す。
【００４９】
ＲＳＡで使用される秘密鍵と公開鍵の２つの鍵は、下記のようにして導出される。まず、２つの素数ＰおよびＱを選び、「Ｎ＝Ｐ＊Ｑ」と「Ｌ＝最小公倍数（Ｐ−１、Ｑ−１）」の２つの値を求める。そして、「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求め（ただしｎは任意の正の整数）、Ｄを秘密鍵、Ｍを公開鍵とする。
【００５０】
これらを使って、下記の計算式により暗号化と復号をおこなう。なお、「Ｄａｔａ ＾Ｄ」はＤａｔａのＤ乗を、また「ｍｏｄ Ｎ」はＮで割った余りを取るという剰余演算を、それぞれ示している。
暗号化：Ｃｏｄｅｄ＝（Ｄａｔａ ＾Ｄ）ｍｏｄ Ｎ
復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ ＾Ｍ）ｍｏｄ Ｎ
【００５１】
これに対して本発明では３つの鍵が必要なので、「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求める代わりに、「Ｙ＊Ａ＊Ｕ＝ｎ＊Ｌ＋１」が成立するＹ、ＡおよびＵを求める。ただしＹ、Ａ、Ｕはそれぞれｎ＊Ｌ＋１であってはならない。このようなＹ、ＡおよびＵの組は、「Ｄ（ｉ）＊Ｍ（ｉ）＝ｎ＊Ｌ＋１」を満足するＤとＭの組から、下記により求めることができる。
【００５２】
Ｙ ＝Ｄ（０）
Ａ（ｉ）＝Ｄ（ｉ）
Ｕ（ｉ）＝（Ｍ（０）＊Ｍ（ｉ）−１）ｍｏｄ Ｌ＋１
【００５３】
そして、これら３つの鍵をもちいて、暗号化と復号とを下記計算式によりおこなう。
暗号化：Ｃｏｄｅｄ ＝（Ｄａｔａ ＾Ｙ）ｍｏｄ Ｎ ・・・（１）
変換 ：Ｃｏｄｅｄ２＝（Ｃｏｄｅｄ ＾Ａ）ｍｏｄ Ｎ ・・・（２）
復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ２ ＾Ｕ）ｍｏｄ Ｎ ・・・（３）
【００５４】
なお、図６で後述するように（１）式による暗号化はカード会社Ａにおける処理、（２）式による変換はカード利用者Ｂにおける処理、また（３）式による復号は加盟店Ｃにおける処理となる。
【００５５】
なお、暗号化も復号も広義では変換に含まれ、ただ変換の目的や結果に着目してこのように呼ぶほうが分かりやすいので、以下では変換のうち特に変換前のデータが平文であるような変換を暗号化、逆に変換後のデータが平文であるような変換を復号と、それぞれ呼ぶことにする。
【００５６】
図４に戻り、つぎにステップＳ４０２でカード会社Ａのコンピュータ１０１は、上記で生成した３つの鍵をその鍵記憶部３０１ｂに格納する。また、ステップＳ４０３で上記のうちＡ鍵とＵ鍵とを、その鍵送信部３０１ｃから加盟店Ｃのコンピュータ１０３、具体的にはその鍵受信部３０３ａに送信する。そして、ステップＳ４０４で加盟店Ｃのコンピュータ１０３は、受信した２つの鍵をその鍵記憶部３０３ｂに格納する。
【００５７】
なお、鍵を導出する計算式からも分かるように、一つのＹ鍵に対応するＡ鍵とＵ鍵との組は複数存在する。そして、一つのカード会社Ａに対して複数存在する加盟店Ｃ以下の各加盟店には、カード会社Ａが保持する一つのＹ鍵に対応する、それぞれ異なるＡ鍵とＵ鍵との組が渡される。
【００５８】
つぎに、図５は図６で後述する商品の発注／受注処理に先立って、図３に示す各部によりおこなわれるカード情報の受け渡し処理の手順を示すフローチャートである。以下このフローチャートに沿って、上記各部の機能の説明を続ける。なお、このフローチャートによる処理は、カード会社Ａが申込者Ｂからのカード利用申し込みを受理した時点で開始される。
【００５９】
ステップＳ５０１で、まずカード会社Ａのコンピュータ１０１は、そのカード情報記憶部３０１ｄ内の顧客データベースに、当該申込者（カード利用者Ｂ）のカード情報、具体的にはそのカード番号、氏名、住所、電話番号などを登録する。
【００６０】
ステップＳ５０２で、カード会社Ａのコンピュータ１０１はそのカード情報暗号化部３０１ｅにおいて、カード情報記憶部３０１ｄから取り出したカード利用者Ｂのカード情報を、鍵記憶部３０１ｂから取り出したＹ鍵により暗号化する。すなわち、上述の（１）式にしたがって、「Ｄａｔａ」（ここでは平文のカード情報）から「Ｃｏｄｅｄ」（Ｙ鍵で暗号化後のカード情報）を作成する。
【００６１】
つぎに、ステップＳ５０３でカード会社Ａのコンピュータ１０１は、Ｙ鍵による変換後のカード情報を、そのカード情報送信部３０１ｆからカード利用者Ｂのコンピュータ１０２、具体的にはそのカード情報受信部３０２ａに送信する。そして、ステップＳ５０４でカード利用者Ｂのコンピュータ１０２は、上記で受信したカード情報をそのカード情報記憶部３０２ｂに格納する。
【００６２】
つぎに、図６はこの発明の実施の形態１によるデータ送受信システムにおける、商品の発注／受注処理の手順を示すフローチャートである。以下このフローチャートに沿って、図３に示す各部の機能の説明を続ける。なお、このフローチャートによる処理は、カード利用者Ｂが加盟店Ｃのホームページなどで商品を発注したとき、具体的には所定の注文フォームなどに必要事項を入力して、「ＯＫ」ボタンなどをクリックした時点で開始される。
【００６３】
ステップＳ６０１でカード利用者Ｂのコンピュータ１０２は、その鍵受信部３０２ｃにより、加盟店Ｃのコンピュータ１０３に対してそのＡ鍵を送信するよう要求する。そして、加盟店Ｃのコンピュータ１０３はその鍵送信部３０３ｃで上記要求を受信すると、鍵記憶部３０３ｂに格納されたＡ鍵を取り出して、要求元の鍵受信部３０２ｃに返信する。
【００６４】
つぎに、ステップＳ６０２でカード利用者Ｂのコンピュータ１０２は、そのカード情報変換部３０２ｄにおいて、カード情報記憶部３０２ｂから取り出したカード情報を上記で受信したＡ鍵により変換する。すなわち、上述の（２）式にしたがって、「Ｃｏｄｅｄ」（Ｙ鍵で暗号化後のカード情報）から「Ｃｏｄｅｄ２」（Ｙ鍵で暗号化後さらにＡ鍵で変換されたカード情報）を作成する。
【００６５】
そして、ステップＳ６０３でカード利用者Ｂのコンピュータ１０２は、その注文書作成部３０２ｅにより、商品名や個数などからなる平文の注文内容に上記で変換後のカード情報を付加することで、所定のフォーマットの注文書を作成する。この後、ステップＳ６０４でこの注文書を注文書送信部３０２ｆから送信し、これが加盟店Ｃのコンピュータ１０３の注文書受信部３０３ｄにより受信される。
【００６６】
つぎに、ステップＳ６０５で加盟店Ｃのコンピュータ１０３は、上記で受信した注文書内のカード情報をそのまま（すなわち、Ｙ鍵により暗号化されＡ鍵により変換された状態のまま）カード情報記憶部３０３ｅに格納する。他方、ステップＳ６０６でそのカード情報復号部３０３ｆにおいて、受信した注文書内のカード情報をＵ鍵により復号する。すなわち、上述の（３）式にしたがって、「Ｃｏｄｅｄ２」（Ｙ鍵で暗号化後さらにＡ鍵で変換されたカード情報）から元の「Ｄａｔａ」（平文のカード情報）を復元する。
【００６７】
つぎに図７は、この発明の実施の形態１によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【００６８】
（ａ）鍵の受け渡し
まず、事前にカード会社ＡにおいてＹ鍵・Ａ鍵・Ｕ鍵を生成し（１）、Ａ鍵とＵ鍵の複数の組み合わせの中から一つを選んで、各加盟店に送付しておく（２）。
【００６９】
（ｂ）カード情報の受け渡し
また、各カード利用者のカード情報をこのＹ鍵で暗号化の上（３）、各人に送付しておく（４）。
【００７０】
（ｃ）商品の発注／受注
商品の注文時には、カード利用者Ｂは加盟店ＣのホームページなどからそのＡ鍵をダウンロードして（５）、Ｙ鍵で暗号化後のカード情報をさらにこのＡ鍵で変換し（６）、これを平文の注文内容に追加（７）して注文書を作成し、加盟店Ｃに送付する（８）。なお、これらの処理はブラウザのプラグインにより、注文フォームの送信時に自動的に実行され、特段の操作は必要ない。そして、加盟店Ｃではカード利用者Ｂから受け取った注文書内のカード情報をバックアップするとともに、これをＵ鍵により復号する（９）。
【００７１】
（ｄ）代金の請求・決済
この後所定の締め日が到来すると、加盟店Ｃはカード会社Ａに対して、バックアップしておいたカード情報を請求書に添付して、各利用者の購入代金の支払いを請求する（１０）。
【００７２】
カード会社Ａでは利用総額の明細書を各利用者に送付するとともに、提出されたカード情報のバックアップがＵ鍵で正常に復号できない場合、加盟店Ｃによる偽造の疑いがあると判断し、注文主とされている利用者に別途購入有無の確認を求める。そして、この確認が得られた場合や、Ｕ鍵での復号に異常がなかった場合には、各利用者の口座からの代金引き落としと、各加盟店の口座への代金振り込みをおこなう（１１）。
【００７３】
図１１で示した従来技術に比較して、図７に示す本発明では鍵の個数が半分で、暗号化や復号の手続きも簡略化されていることが分かる。また、カード利用者Ｂから加盟店Ｃに渡る（８）カード情報は、カード会社Ａから送付されてきたカード情報（４）がさらにＡ鍵で変換された（６）ものであり、加盟店ＣではこれをＵ鍵で復号して平文に戻す（９）ことはできても、Ａ鍵による変換前の状態（すなわち、Ｙ鍵により暗号化されただけの状態）に戻すことはできない。
【００７４】
したがって、加盟店Ｃによる注文書の偽造は自店宛以外不可能である。なぜなら、他の加盟店Ｃ’に対する注文書の偽造には、必ずＹ鍵により暗号化されただけの状態の（すなわち、カード会社Ａから送付されたままの状態の）カード情報が必要だからである。
【００７５】
逆に、他の加盟店Ｃ’は、受け取った注文書内のカード情報部分が自己のＵ’鍵で復号できれば、当該カード情報はカード会社Ａから送付された状態のカード情報を保持するカード利用者Ｂ、すなわち正当な権利者によって自己のＡ’鍵で変換されたものと分かり、不正目的の加盟店Ｃがカード利用者Ｂになりすますなどして、注文書を偽造したものではないと判断できる。
【００７６】
以上説明したように実施の形態１によるデータ送受信システムでは、３つの鍵による単純な暗号化でありながら、カード情報の偽造が非常に困難なので、三者間でのカード決済を簡易かつ安全におこなうことができる。
【００７７】
なお、上記では混乱を避けるため説明を省略したが、鍵送信部３０１ｃから鍵受信部３０３ａへの鍵の送信（図７の（２））、カード情報送信部３０１ｆからカード情報受信部３０２ａへのカード情報の送信（同（４））、および注文書送信部３０２ｆから注文書受信部３０３ｄへの注文書の送信（同（８））時には、Ｙ鍵・Ａ鍵・Ｕ鍵とは別の通信用の鍵によって通信内容を暗号化する。ただ、特に前二者については厳重な秘密保持が必要なので、オンラインでなくオフライン、たとえば郵便などによって送付をおこなうようにしてもよい。
【００７８】
（実施の形態２）
さて、上述した実施の形態１は三者が実際に取引に関与する例であったが、現実社会には共通の知人や公的機関の発行した推薦状、紹介状、保証書、証明書などを信用して二者間で取り引きするケースなど、実質的に三者が関与しているとみることができる取引も存在する。そして、このような取引においても、各種書面の偽造や変造がしばしば問題となるので、以下で説明する実施の形態２のように、３つの鍵による暗号化や復号を各種の証書類に応用するのであってもよい。
【００７９】
図８は、実施の形態２によるデータ送受信システムのシステム構成を示す説明図である。図中、８０１は証明者Ａの保持するコンピュータ、８０２は被証明者Ｂの保持するコンピュータ、８０３は被証明者Ｂと取り引きする相手方Ｃの保持するコンピュータであり、８００は上記の各コンピュータを相互に接続するネットワーク、具体的にはインターネットを示している。なお、各コンピュータのハードウエア構成は、図２に示した実施の形態１のそれと同様であるものとする。
【００８０】
つぎに、図９は実施の形態２によるデータ送受信システムの構成を機能的に示す説明図である。同図に示すように、証明者Ａのコンピュータ８０１は鍵記憶部９０１ａ、鍵選択部９０１ｂ、鍵送信部９０１ｃ、証明事項記憶部９０１ｄ、証明書作成部９０１ｅ、証明書暗号化部９０１ｆおよび証明書送信部９０１ｇを含む構成である。
【００８１】
また、被証明者Ｂのコンピュータ８０２は証明書受信部９０２ａ、鍵受信部９０２ｂ、証明書変換部９０２ｃおよび証明書送信部９０２ｄを含む構成である。また、取引先Ｃのコンピュータ８０３は鍵受信部９０３ａ、鍵記憶部９０３ｂ、鍵送信部９０３ｃ、証明書受信部９０３ｄおよび証明書復号部９０３ｅを含む構成である。
【００８２】
なお、上記各部は各コンピュータのＨＤ２０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの各種記録媒体からＲＡＭ２０３に読み出されたプログラムの命令にしたがって、ＣＰＵ２０１などが命令処理を実行することにより、後述するそれぞれの機能を実現するものである。
【００８３】
つぎに、図１０は実施の形態２によるデータ送受信システムにおける、証明書発行・提出処理の手順を示すフローチャートである。以下このフローチャートに沿って、図９に示す各部の機能を説明する。
【００８４】
ステップＳ１００１で、まず取引先Ｃのコンピュータ８０３はその鍵受信部９０３ａから、証明者Ａのコンピュータ８０１に対してＡ鍵とＵ鍵とを送信するよう要求する。この要求をその鍵送信部９０１ｃにより受信した証明者Ａのコンピュータ８０１は、ステップＳ１００２でその鍵選択部９０１ｂにより、あらかじめ生成されて鍵記憶部９０１ａに格納されているＡ鍵とＵ鍵との対のうち、まだ他の個人などに使用されていないいずれかの一対を選択する。そして、ステップＳ１００３でこの選択されたＡ鍵とＵ鍵とを、鍵送信部９０１ｃから要求元の鍵受信部９０３ａに返信する。
【００８５】
取引先Ｃのコンピュータ８０３は、受信したＡ鍵とＵ鍵とを、ステップＳ１００４でその鍵記憶部９０３ｂに格納するとともに、ステップＳ１００５でその鍵送信部９０３ｃから、被証明者Ｂのコンピュータ８０２の鍵受信部９０２ｂに送信する。
【００８６】
また、ステップＳ１００６で被証明者Ｂのコンピュータ８０２は、その証明書受信部９０２ａから証明者Ａのコンピュータ８０１に対して、証明書の発行要求を送信する。この発行要求をその証明書送信部９０１ｇで受信した証明者Ａのコンピュータ８０１は、ステップＳ１００７でその証明書作成部９０１ｅにより、証明事項記憶部９０１ｄに蓄積された各種の証明事項、たとえば住所や生年月日などの中から、上記発行要求中で指定された事項を抽出して、所定のフォーマットの証明書を作成する。
【００８７】
そして、この証明書をステップＳ１００８で証明書暗号化部９０１ｆにより、Ｙ鍵で暗号化の上、ステップＳ１００９で証明書送信部９０１ｇから、要求元の証明書受信部９０２ａに返信する。なお、このＹ鍵で暗号化後の証明書を、以下では「証明書の原本」あるいは単に「原本」と呼ぶ。
【００８８】
そして、ステップＳ１０１０で被証明者Ｂのコンピュータ８０２は、その証明書変換部９０２ｃにより、証明者Ａから受信した証明書の原本を取引先Ｃから受信したＡ鍵で変換する。その後、ステップＳ１０１１でこの変換後の原本を、証明書送信部９０２ｄから取引先Ｃのコンピュータ８０３の証明書受信部９０３ｄに送信する。
【００８９】
そして、ステップＳ１０１２で取引先Ｃのコンピュータ８０３は、上記で受信した変換後の原本を、その証明書復号部９０３ｅでＵ鍵により復号する。
【００９０】
なお、被証明者Ｂは証明者ＡのＹ鍵が入手できない限り、架空の証明書をＹ鍵で暗号化して、あたかも証明者Ａから発行されたかのように見せかけたり（すなわち偽造）、あるいは証明者Ａから受け取った原本をＹ鍵で復号し、内容を改竄の上、再びＹ鍵で暗号化したりする（すなわち変造）ことはできない。また、取引先Ｃも被証明者Ｂから受け取った証明書を、その保持するＵ鍵により平文に戻せるだけで、証明者ＡのＹ鍵が入手できない以上、その偽造や変造は不可能である。無理にこれらをおこなえば、Ｕ鍵による復号が不能か異常となるので、不正行為の事実が発覚する。
【００９１】
したがって、Ｙ鍵の管理が万全である限り、証明書の受領者は逐一その証明者に照会しなくても、受け取った証明書がＵ鍵で正常に復号できたことをもって、当該証明書が真正なものであることを確認できる。
【００９２】
また、被証明者がある取引先用に変換した証明書は、他の取引先では復号できないので（取引先ごとにＡ鍵とＵ鍵とが異なるため）、紛失などの事故があっても意図しない相手に証明書を復号されてしまうことがない。被証明者が原本の変換の時点で、変換に使用する鍵により、当該証明書を閲覧できる相手を限定できると言ってもよい。
【００９３】
なお、上記の証明者としては政府などの公的機関、証明書としては戸籍謄本や住民票などの公的書類が代表的なものであるが、これに限らず証明者や証明書の記載事項はどのようなものであってもよい。
【００９４】
たとえば、あるソフトウエアの登録ユーザーであって、一定期間にわたって登録住所に製品案内などが届いているユーザーは、それだけで住所の安定した、比較的信用できる顧客とみることができる。そこで、ソフトウエアの開発元が証明機関となり、ユーザー登録日や登録製品名、最後に郵便物の送達が確認された日などの各種事項のうち、各登録ユーザーから指定された任意の事項について証明書を作成し、暗号化の上交付する。
【００９５】
インターネットの匿名性により、通信販売やオークションなどでは詐欺などのトラブルが多発しており、たとえば通販会社では据え置き電話のある個人・法人に顧客を絞ったり（携帯電話では信用が取れないため）、他の会社などから顧客リストを購入したりして、多くの費用と労力をかけて顧客の選別をおこなっている。また、オークションでは各人の取引履歴を公開しているものもあるが、信用できる参加者でも最初は信用０であり、逆に信用できない参加者でも別のＩＤを取得すれば容易に別人を装うことができてしまう。
【００９６】
この点、上述のように簡単に運用でき、しかも偽造・変造が困難なユーザー証明書であれば、通販会社やオークションの主催者は、前もって証明書を提出させるだけで、比較的信用できるユーザーに注文者や参加者を絞り込むことができる。
【００９７】
また、被証明者としても、登録ユーザーという従来評価されていなかった一種のステータスを、個人の評価に結びつけることができる。さらに、証明機関であるソフトウエア会社は、証明書の発行時やＡ鍵・Ｕ鍵の交付（あるいは貸与）時に手数料を徴収できるほか、登録ユーザーの地位が社会的に評価されることにともない、ユーザー登録率の向上を期待することができる。
【００９８】
そして、こうしたオープンな証明のシステムが広く運用されることで、従来おこなわれていた顧客リストの闇取引がなくなり、意図しない相手への個人情報の漏洩が低減してゆくことを期待できる。
【００９９】
なお、実施の形態２による取引先とは、必ずしも通信販売やオークションなどの売買取引の相手方に限らない。たとえば、参加者をあるソフトウエアの登録ユーザーに限定している掲示板などにおいて、その管理者にＵ鍵とＡ鍵を、また参加希望者にユーザー証明書を、当該ソフトウエアの開発元からそれぞれ交付するようにすれば、開発元への問い合わせや開発元からの回答を要せず、管理者限りで容易に各希望者の参加資格の有無を確認することができる。
【０１００】
また、上述の実施の形態２では、被証明者からその取引先に対して証明書を提出するようにしたが、被証明者が多数の取引先に同一の証明をおこなわなければならないときは、逆に取引先のほうから被証明者の証明書を取りにゆくようにしてもよい。
【０１０１】
たとえば、被証明者はその開設するホームページに、ソフトウエア会社から取得したユーザー証明書と当該ソフトウエアのロゴを貼り付け、ロゴがクリックされると専用のｃｇｉが起動するようにしておく。そして、このｃｇｉは起動時に閲覧者（すなわち取引先）の保持するＡ鍵を要求し、取得したＡ鍵で証明書の原本を変換の上、当該閲覧者に返信する。閲覧者は取得した証明書をその保持するＵ鍵で復号して、当該被証明者のユーザー登録の詳細を確認することができる。
【０１０２】
また、上述の実施の形態２では、一対のＡ鍵とＵ鍵を特定の個人・法人に限定的に交付することで、証明書の内容がそれ以外の部外者に閲覧されることを避けたが、逆に証明書の内容が世間にアピールしたいようなもの、一般への表示が義務づけられているもの、あるいは少なくとも誰に見られても差し支えないようなものであれば、これらの鍵を証明機関で公開するようにしてもよい。
【０１０３】
たとえば、被証明者は「徳島太郎は一太郎Ｖｅｒ．○の登録ユーザーです」という一文からなる証明書を、当該ソフトウエアの開発元に申し込んで発行してもらう（もちろんＹ鍵により暗号化されているのでこの平文が読めるわけではない）。そして、当該開発元のホームページからダウンロードした汎用のＡ鍵で、この証明書を変換し、このソフトウエアで作成した文書に埋め込んでおく。文書の閲覧者は、上記ホームページからダウンロードした汎用のＵ鍵で変換後の証明書を復号し、上記平文を得る。
【０１０４】
なお、Ａ鍵とＵ鍵とはホームページで公開するのでなく、ソフトウエア自体に組み込んでおき、たとえばメニューから「ユーザー証明書の埋め込み」を選択すると、指定されたデータがＡ鍵により変換されて文書に組み込まれ、また「ユーザー証明書の表示」を選択すると、文書に埋め込まれた変換後のデータがＵ鍵で復号されて表示されるようにしてもよい。
【０１０５】
また、交付された証明書に、当該証明書を埋め込む文書のハッシュキーを添付して、その全体をＡ鍵で変換した上で当該文書に埋め込むようにしてもよい。この文書の閲覧者は、Ｕ鍵で変換後のハッシュキーをＹ鍵を保持する開発元に送付し、Ｙ鍵で復号されたハッシュキーの返信を受けて、手元で計算したハッシュキーの値と一致するかどうかを確認する。そして、両者が一致していれば、当該文書には改竄がないものと判断することができる。
【０１０６】
なお、上述した実施の形態１および２では、データの授受に関与するのがカード会社・カード利用者・加盟店、あるいは証明者・被証明者・被証明者の相手方の三者であったために、Ｙ鍵・Ａ鍵・Ｕ鍵の三種類の鍵を生成するようにしたが、当事者数（厳密には、立場の異なる当事者数。当事者の種別、などと言ってもよい）がそれより多ければ、その数と同数の鍵を生成して本発明を応用することができるのは言うまでもない。
【０１０７】
【発明の効果】
以上説明したようにこの発明によれば、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置がデータを第１の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する第１の送信手段と、を備え、前記第２の情報処理装置が前記第１の送信手段から送信されてきたデータを受信する第１の受信手段と、前記第１の受信手段により受信されたデータを第２の鍵により変換する第２の変換手段と、前記第２の変換手段により変換されたデータを送信する第２の送信手段と、を備え、前記第３の情報処理装置が前記第２の送信手段から送信されてきたデータを受信する第２の受信手段と、前記第２の受信手段により受信されたデータを第３の鍵により変換する第３の変換手段と、を備えたので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信システムが得られるという効果を奏する。
【０１０８】
また、この発明によれば、第１および第２の情報処理装置間でデータを送受信するデータ送受信システムにおいて、前記第１の情報処理装置が第１の鍵により変換されたデータをさらに第２の鍵により変換する第１の変換手段と、前記第１の変換手段により変換されたデータを送信する送信手段と、を備え、前記第２の情報処理装置が前記送信手段から送信されてきたデータを受信する受信手段と、前記受信手段により受信されたデータを第３の鍵により変換する第２の変換手段と、を備えたので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信システムが得られるという効果を奏する。
【０１０９】
また、この発明によれば、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなるので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができ、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけは当該データの内容を容易に閲覧することが可能なデータ送受信システムが得られるという効果を奏する。
【０１１０】
また、この発明によれば、第１、第２および第３の情報処理装置間でデータを送受信するデータ送受信方法において、前記第１の情報処理装置で、データを第１の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する第１の送信工程と、前記第２の情報処理装置で、前記第１の送信工程で送信されてきたデータを第２の鍵により変換する第２の変換工程と、前記第２の変換工程で変換されたデータを、前記第２の情報処理装置から前記第３の情報処理装置に送信する第２の送信工程と、前記第３の情報処理装置で、前記第２の送信工程で送信されてきたデータを第３の鍵により変換する第３の変換工程と、を含んだので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１１】
また、この発明によれば、第１および第２の情報処理装置間でデータを送受信するデータ送受信方法において、第１の鍵により変換されたデータを、前記第１の情報処理装置でさらに第２の鍵により変換する第１の変換工程と、前記第１の変換工程で変換されたデータを、前記第１の情報処理装置から前記第２の情報処理装置に送信する送信工程と、前記送信工程で送信されてきたデータを、前記第２の情報処理装置で第３の鍵により変換する第２の変換工程と、を含んだので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできず、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１２】
また、この発明によれば、上記発明において、前記第１の鍵により変換されたデータは、前記第２の鍵により変換されさらに前記第３の鍵により変換されると前記第１の鍵による変換前の元のデータとなるので、変換後のデータの取得者はその直前の変換元による変換前のデータを捏造し、あるいは変換後のデータから復元した変換前のデータを改竄して、当該変換元と同一の変換を施すことはできない一方で、２つ前の変換元による変換前のデータは復元することができ、これによって、異なる三者間を経由するデータの送受信において、当該データの偽造・変造を防止するとともに、最初の送信者と最後の受信者だけは当該データの内容を容易に閲覧することが可能なデータ送受信方法が得られるという効果を奏する。
【０１１３】
また、この発明によれば、上記方法をコンピュータに実行させるプログラムを記録したことで、当該プログラムをコンピュータで読み取ることが可能となり、これによって、上記方法をコンピュータによって実施することが可能な記録媒体が得られるという効果を奏する。
【図面の簡単な説明】
【図１】 実施の形態１によるデータ送受信システムのシステム構成を示す説明図である。
【図２】 実施の形態１によるデータ送受信システムを構成する、個々のコンピュータのハードウエア構成の一例を示す説明図である。
【図３】 実施の形態１によるデータ送受信システムの構成を機能的に示す説明図である。
【図４】 実施の形態１によるデータ送受信システムにおける、鍵の受け渡し処理の手順を示すフローチャートである。
【図５】 実施の形態１によるデータ送受信システムにおける、カード情報の受け渡し処理の手順を示すフローチャートである。
【図６】 実施の形態１によるデータ送受信システムにおける、商品の発注／受注処理の手順を示すフローチャートである。
【図７】 実施の形態１によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【図８】 実施の形態２によるデータ送受信システムのシステム構成を示す説明図である。
【図９】 実施の形態２によるデータ送受信システムの構成を機能的に示す説明図である。
【図１０】 実施の形態２によるデータ送受信システムにおける、証明書発行・提出処理の手順を示すフローチャートである。
【図１１】 従来技術によるデータ送受信システムにおける、各コンピュータ間でのデータの流れを模式的に示す説明図である。
【符号の説明】
１００ インターネット
１０１ カード会社Ａのコンピュータ
１０２ カード利用者Ｂのコンピュータ
１０３ 加盟店Ｃのコンピュータ
２００ バスまたはケーブル
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＨＤＤ
２０５ ＨＤ
２０６ ＦＤＤ
２０７ ＦＤ
２０８ ディスプレイ
２０９ ネットワークＩ／Ｆ
２１０ 通信回線
２１１ キーボード
２１２ マウス
２１３ スキャナ
２１４ プリンタ
２１５ ＣＤ−ＲＯＭ
２１６ ＣＤ−ＲＯＭドライブ
３０１ａ 鍵生成部
３０１ｂ 鍵記憶部
３０１ｃ 鍵送信部
３０１ｄ カード情報記憶部
３０１ｅ カード情報暗号化部
３０１ｆ カード情報送信部
３０２ａ カード情報受信部
３０２ｂ カード情報記憶部
３０２ｃ 鍵受信部
３０２ｄ カード情報変換部
３０２ｅ 注文書作成部
３０２ｆ 注文書送信部
３０３ａ 鍵受信部
３０３ｂ 鍵記憶部
３０３ｃ 鍵送信部
３０３ｄ 注文書受信部
３０３ｅ カード情報記憶部
３０３ｆ カード情報復号部
８００ インターネット
８０１ 証明者Ａのコンピュータ
８０２ 被証明者Ｂのコンピュータ
８０３ 取引先Ｃのコンピュータ
９０１ａ 鍵記憶部
９０１ｂ 鍵選択部
９０１ｃ 鍵送信部
９０１ｄ 証明事項記憶部
９０１ｅ 証明書作成部
９０１ｆ 証明書暗号化部
９０１ｇ 証明書送信部
９０２ａ 証明書受信部
９０２ｂ 鍵受信部
９０２ｃ 証明書変換部
９０２ｄ 証明書送信部
９０３ａ 鍵受信部
９０３ｂ 鍵記憶部
９０３ｃ 鍵送信部
９０３ｄ 証明書受信部
９０３ｅ 証明書復号部
Claims (3)
- 少なくとも他の２つの情報処理装置（以下、２つの情報処理装置を、「第１の情報処理装置」と、「第２の情報処理装置」とする）とネットワークを介して接続される情報処理装置であって、
前記第１の情報処理装置によって生成された３つの鍵データ（「第１の鍵データ」、「第２の鍵データ」および「第３の鍵データ」）のうちの２つの鍵データ（「第１の鍵データ」および「第２の鍵データ」）を前記ネットワークを介して前記第１の情報処理装置から受信する鍵データ受信手段と、
前記鍵データ受信手段によって受信された２つの鍵データ（「第１の鍵データ」および「第２の鍵データ」）を記憶する記憶手段と、
前記第２の情報処置装置からの鍵データ要求情報を前記ネットワークを介して受信する要求情報受信手段と、
前記要求情報受信手段によって受信された鍵データ要求情報に応じて、前記記憶手段によって記憶された第１の鍵データを、前記第２の情報処理装置へ前記ネットワークを介して送信する送信手段と、
前記第１の情報処理装置において、前記第３の鍵データを用いて暗号化された後に前記第２の情報処理装置へ送信されたデータであって、前記第２の情報処理装置において、前記送信手段によって送信された第１の鍵データを用いてさらに暗号化されたデータを前記第２の情報処理装置から前記ネットワークを介して受信するデータ受信手段と、
前記データ受信手段によって受信されたデータを、前記記憶手段によって記憶された第２の鍵データを用いて復号する復号手段と、
を備え、
前記第３の鍵を用いて暗号化されたデータが、前記第１の鍵データを用いて暗号化された後に、前記第２の鍵を用いて復号化されると、前記第３の鍵による暗号化前の元のデータとなり、かつ、前記第１の鍵を用いて暗号化されたデータが、前記第２の鍵データを用いて暗号化された後に、前記第３の鍵を用いて復号化されると、前記第１の鍵による暗号化前の元のデータとなるように、前記３つの鍵データが生成されていることを特徴とする情報処理装置。 - 少なくとも他の２つの情報処理装置（以下、２つの情報処理装置を、「第１の情報処理装置」と、「第２の情報処理装置」とする）とネットワークを介して接続される情報処理装置におけるデータ送受信方法であって、
前記第１の情報処理装置によって生成された３つの鍵データ（「第１の鍵データ」、「第２の鍵データ」および「第３の鍵データ」）のうちの２つの鍵データ（「第１の鍵データ」および「第２の鍵データ」）を前記ネットワークを介して前記第１の情報処理装置から受信する鍵データ受信工程と、
前記第２の情報処置装置からの鍵データ要求情報を前記ネットワークを介して受信する要求情報受信工程と、
前記要求情報受信工程によって受信された鍵データ要求情報に応じて、前鍵データ受信工程よって受信された第１の鍵データを、前記第２の情報処理装置へ前記ネットワークを介して送信する送信工程と、
前記第１の情報処理装置において、前記第３の鍵データを用いて暗号化された後に前記第２の情報処理装置へ送信されたデータであって、前記第２の情報処理装置において、前記送信工程によって送信された第１の鍵データを用いてさらに暗号化されたデータを前記第２の情報処理装置から前記ネットワークを介して受信するデータ受信工程と、
前記データ受信工程によって受信されたデータを、前記鍵データ受信工程によって受信された第２の鍵データを用いて復号する復号工程と、
を含み、
前記第３の鍵を用いて暗号化されたデータが、前記第１の鍵データを用いて暗号化された後に、前記第２の鍵を用いて復号化されると、前記第３の鍵による暗号化前の元のデータとなり、かつ、前記第１の鍵を用いて暗号化されたデータが、前記第２の鍵データを用いて暗号化された後に、前記第３の鍵を用いて復号化されると、前記第１の鍵による暗号化前の元のデータとなるように、前記３つの鍵データが生成されていることを特徴とするデータ送受信方法。 - 少なくとも他の２つの情報処理装置（以下、２つの情報処理装置を、「第１の情報処理装置」と、「第２の情報処理装置」とする）とネットワークを介して接続される情報処理装置に実行させるデータ送受信プログラムであって、
前記第１の情報処理装置によって生成された３つの鍵データ（「第１の鍵データ」、「第２の鍵データ」および「第３の鍵データ」）のうちの２つの鍵データ（「第１の鍵デー
タ」および「第２の鍵データ」）を前記ネットワークを介して前記第１の情報処理装置から受信する鍵データ受信工程と、
前記第２の情報処置装置からの鍵データ要求情報を前記ネットワークを介して受信する要求情報受信工程と、
前記要求情報受信工程によって受信された鍵データ要求情報に応じて、前鍵データ受信工程よって受信された第１の鍵データを、前記第２の情報処理装置へ前記ネットワークを介して送信する送信工程と、
前記第１の情報処理装置において、前記第３の鍵データを用いて暗号化された後に前記第２の情報処理装置へ送信されたデータであって、前記第２の情報処理装置において、前記送信工程によって送信された第１の鍵データを用いてさらに暗号化されたデータを前記第２の情報処理装置から前記ネットワークを介して受信するデータ受信工程と、
前記データ受信工程によって受信されたデータを、前記鍵データ受信工程によって受信された第２の鍵データを用いて復号する復号工程と、
を前記情報処理装置に実行させ、
前記第３の鍵を用いて暗号化されたデータが、前記第１の鍵データを用いて暗号化された後に、前記第２の鍵を用いて復号化されると、前記第３の鍵による暗号化前の元のデータとなり、かつ、前記第１の鍵を用いて暗号化されたデータが、前記第２の鍵データを用いて暗号化された後に、前記第３の鍵を用いて復号化されると、前記第１の鍵による暗号化前の元のデータとなるように、前記３つの鍵データが生成されていることを特徴とするデータ送受信プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001072690A JP3959240B2 (ja) | 2001-03-14 | 2001-03-14 | 情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001072690A JP3959240B2 (ja) | 2001-03-14 | 2001-03-14 | 情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002281020A JP2002281020A (ja) | 2002-09-27 |
| JP3959240B2 true JP3959240B2 (ja) | 2007-08-15 |
Family
ID=18930237
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001072690A Expired - Fee Related JP3959240B2 (ja) | 2001-03-14 | 2001-03-14 | 情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3959240B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007011695A2 (en) * | 2005-07-15 | 2007-01-25 | Revolution Money, Inc. | System and method for user selection of fraud detection rules |
| CN112905945B (zh) * | 2019-11-19 | 2023-08-15 | 中移物联网有限公司 | 计费方法、装置及可读存储介质 |
-
2001
- 2001-03-14 JP JP2001072690A patent/JP3959240B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002281020A (ja) | 2002-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2494455C2 (ru) | Электронная сертификация, индентификация и передача информации с использованием кодированных графических изображений | |
| AU751404B2 (en) | Symmetrically-secured electronic communication system | |
| US6061792A (en) | System and method for fair exchange of time-independent information goods over a network | |
| JP2003308437A (ja) | 送金システム、送金方法および送金プログラム | |
| US11522719B2 (en) | Systems for producing and maintaining verified electronic signatures | |
| JP2010218440A (ja) | 決済システム、決済方法および情報処理装置 | |
| JP6800045B2 (ja) | 署名支援サーバ、中継サーバ、署名支援プログラム、及び中継プログラム | |
| EP3633574A2 (en) | Data structure, transmission device, receiving device, settlement device, method, and computer program | |
| JP6807734B2 (ja) | 中継サーバ、及び中継プログラム | |
| US12002019B2 (en) | Data structure, transmission device, receiving device, settlement device, method, and computer program | |
| US10984415B2 (en) | System and methods for using limit-use encrypted code to transfer values securely among users | |
| US20090037340A1 (en) | Digital certification method and apparatus | |
| KR100468031B1 (ko) | 자기앞 전자수표 발행 및 결제방법 | |
| JP3959240B2 (ja) | 情報処理装置、データ送受信システム、データ送受信方法およびデータ送受信プログラム | |
| JP2008502045A (ja) | 電子商取引の確保 | |
| JP2002117350A (ja) | サービス発行方法並びにサービス提供方法及びそのシステム | |
| JP3449894B2 (ja) | ネットワーク取引システム、そのプログラムを記録した記録媒体、端末装置および本人確認方法 | |
| US20130132726A1 (en) | Digital certification method and apparatus | |
| JP2005284327A (ja) | 領収書発行システム | |
| KR20180131728A (ko) | 간편일회용전자서명 방법 | |
| JP4639732B2 (ja) | 電子証明書の編集プログラム及び方法並びにｉｃカード | |
| TWI234976B (en) | Remote electronic seal system and method thereof | |
| KR20230082150A (ko) | 전자계약시스템 및 이를 위한 전자계약서 수발신 알고리즘 | |
| TWI229999B (en) | Online parallel shopping registration and certification application method with consistent security and device thereof | |
| CN117997560A (zh) | 企业身份验证方法及设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040219 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040224 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040426 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040601 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040802 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040806 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20040924 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070410 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070514 |
|
| 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: 20100518 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100518 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100518 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130518 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130518 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160518 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |