(57)【要約】【課題】  鍵管理の手間が容易であり、短い暗号処理時間で高い堅牢度を確保し、送信者の認証と内容の秘匿性を確保した証明サーバ等の利用にも適した暗号化方法、データ送信システム、及び鍵セット生成装置を提供し、データ通信の安全性向上を図る。【解決手段】  暗号化方法として、所定条件を満たす３以上のコンビネーション鍵を用い、データに対して１つの前記コンビネーション鍵による暗号化処理を前記コンビネーション鍵の数だけ重畳して繰返し、最後の上記暗号化処理の実行により元のデータを取得する。【選択図】    図９
2005258188.tif 000002
【特許請求の範囲】
【請求項１】
所定条件を満たす３以上のコンビネーション鍵を用い、
データに対して前記コンビネーション鍵の１つを用いた暗号化処理を前記コンビネーション鍵の数だけ重畳して繰返し、
最後の上記暗号化処理の実行により元のデータを取得する
暗号化方法。
【請求項２】
前記所定条件を、全てのコンビネーション鍵を乗算して得た値を所定の除算用定数で除算した剰余が１となる条件とする
請求項１記載の暗号化方法。
【請求項３】
前記暗号化処理を、
暗号化対象のデータに１つのコンビネーション鍵を乗算し、該乗算により得た値を前記所定の除算用定数で除算し、該除算により得た剰余を暗号データとして出力する処理とする
請求項１又は２記載の暗号化方法。
【請求項４】
送信側装置から受信側装置へ直接又は間接にデータ送信するデータ送信システムであって、
所定条件を満たす３以上のコンビネーション鍵を用い、
前記コンビネーション鍵の１を前記送信側装置に格納し、
前記コンビネーション鍵の他の１を前記受信側装置に格納すると共に、
前記コンビネーション鍵の１つを用いた暗号化処理を実行する暗号化処理手段を、前記送信側装置及び受信側装置に備えた
データ送信システム。
【請求項５】
前記所定条件に、
全てのコンビネーション鍵を乗算して得た値を所定の除算用定数で除算した剰余が１となる条件を設定した
請求項４記載のデータ送信システム。
【請求項６】
前記暗号化処理手段で実行する暗号化処理を、
暗号化対象のデータに１つのコンビネーション鍵を乗算し、該乗算により得た値を前記所定の除算用定数で除算し、該除算により得た剰余を暗号データとして出力する処理に設定した
請求項４又は５記載のデータ送信システム。
【請求項７】
前記送信側装置と前記受信側装置の間でデータ送信を仲介する第三者機関の証明サーバを備え、
該証明サーバに、
前記コンビネーション鍵の残りの１を格納すると共に、
前記暗号化処理手段と、
前記受信側装置へ送信するデータとして所定の証明データを付加する証明データ付加手段とを備えた
請求項４、５又は６記載のデータ送信システム。
【請求項８】
所定条件を満たす３以上のコンビネーション鍵で構成する鍵セットを生成する手段として、
適宜求めた２以上の異なる素数をコンビネーション鍵として取得するコンビネーション鍵生成手段と、
生成した複数のコンビネーション鍵を全て乗算し、さらに所定素数を乗算した値を所定の除算用定数で除算した余りが１となる前記所定素数を算出して、該所定素数もコンビネーション鍵として取得するコンビネーション鍵算出手段とを備えた
鍵セット生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えばデータを暗号化して安全に送信し受信側で復号（暗号化処理）できるような暗号化方法、データ送信システム、及び鍵セット生成装置に関する。
【背景技術】
【０００２】
従来、データを暗号化して送信する方法として、様々な方法が提案されており、このような暗号化を利用するシステムとして例えば電子投票システムが提案されている（特許文献１参照）。
【０００３】
前記電子投票システムでは、投票情報を共通鍵ＫＡ１で暗号化し、さらに別の共通鍵ＫＡ２で暗号化して認証サーバに送信する。認証サーバは共通鍵ＫＡ２で復号化して集計サーバに送信し、集計サーバは共通鍵ＫＡ１で復号化して投票情報を取得する。また前記共通鍵ＫＡ１，ＫＡ２の送信は、公開鍵と秘密鍵の鍵ペアによって送信される。
【０００４】
この構成により、認証サーバは投票者を認証できるが投票内容を知ることはできないようにしている。
【０００５】
【特許文献１】特開２００２−２５９６２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、前記投票システムでは、投票者は共通鍵を２つ管理しなければならず、さらに暗号化処理も２回実行しなければならないため手間のかかるものである。  
また、投票者が鍵をかける順番を間違えると、認証サーバでは復号ができず、投票が正常に受理されないという問題がある。
【０００７】
この発明は、上述の問題に鑑み、鍵管理の手間が容易であり、短い暗号処理時間で高い堅牢度を確保し、送信者の認証と内容の秘匿性を確保した証明サーバ等の利用にも適した暗号化方法、データ送信システム、及び鍵セット生成装置を提供し、データ通信の安全性向上を図ることを目的とする。
【課題を解決するための手段】
【０００８】
この発明は、所定条件を満たす３以上のコンビネーション鍵を用い、データに対して前記コンビネーション鍵の１つを用いた暗号化処理を前記コンビネーション鍵の数だけ重畳して繰返し、最後の上記暗号化処理の実行により元のデータを取得する暗号化方法であることを特徴とする。
【０００９】
前記コンビネーション鍵は、それぞれ異なる素数で構成することを含む。  
前記データは、文字データ、画像データ、音声データ、又はこれらの組合せ等のデジタルデータで構成することを含む。
【００１０】
前記構成により、コンビネーション鍵を用いて１回暗号化した後は、セットとなる全てのコンビネーション鍵を用いて暗号化処理を行うまで元のデータが得られないため、その間の秘匿性を確保することができる。
【００１１】
従って、例えば送信者がコンビネーション鍵で暗号化処理し、認証サーバ等の他の装置が他のコンビネーション鍵で暗号化処理し、受信者が残ったコンビネーション鍵で暗号化処理して元のデータを取得するといったことが可能となる。  
この場合、認証サーバ等の他の装置は元のデータの内容を見ることはできないため、送信者の認証と内容の秘匿性確保といった利用が可能となる。
【００１２】
この発明の態様として、前記所定条件を、全てのコンビネーション鍵を乗算して得た値を所定の除算用定数で除算した剰余が１となる条件とすることができる。
【００１３】
前記所定の除算用定数は、暗号化対象となるデータの構成要素の種類数、又は該種類数以上の数等、予め定めた所定の定数（例えば正の整数）で構成することを含む。また、上記データの構成要素の種類数は、データが文字列データであれば使用可能な文字数とする、画像データであれば画素において判別可能な色数（例えばＲＧＢの３階調）とする等、データを構成する要素の種類数に設定することを含む。
【００１４】
また更に、ブロック暗号を行う場合については、データをブロック化（所定の要素数のブロック単位で分割）したブロック内のデータ個数をデータの構成要素の種類数で乗算した数、又はこれ以上の数で構成することを含む。  
従って、例えばＡからＺまでで種類数が２６となるアルファベットの１文字を構成要素とし、１０文字単位でブロック化した場合であれば、所定の除算用定数は２６１０又はそれ以上となる。
【００１５】
前記構成により、複数段階の暗号化処理を経て、最終的な暗号化処理者のみが元のデータを取得可能とするセットの鍵を使用することが可能となる。
【００１６】
またこの発明の態様として、前記暗号化処理を、暗号化対象のデータに１つのコンビネーション鍵を乗算し、該乗算により得た値を前記所定の除算用定数で除算し、該除算により得た剰余を暗号データとして出力する処理とすることができる。  
前記構成により、複数段階の暗号化処理を確実に実行し、最終的な暗号化処理者のみが元のデータを取得可能とすることができる。
【００１７】
またこの発明は、送信側装置から受信側装置へ直接又は間接にデータ送信するデータ送信システムであって、所定条件を満たす３以上のコンビネーション鍵を用い、前記コンビネーション鍵の１を前記送信側装置に格納し、前記コンビネーション鍵の他の１を前記受信側装置に格納すると共に、前記コンビネーション鍵の１つを用いた暗号化処理を実行する暗号化処理手段を、前記送信側装置及び受信側装置に備えたデータ送信システムとすることができる。
【００１８】
前記送信側装置は、パーソナルコンピュータや携帯情報端末等、データ送信が可能な装置で構成することを含む。  
前記受信側装置は、パーソナルコンピュータや携帯情報端末等、データ受信が可能な装置で構成することを含む。
【００１９】
前記コンビネーション鍵は、送信側装置に２以上格納して送信側装置で重畳して暗号化してから送信する、あるいは、送信側装置と受信側装置の通信を仲介する他の装置にコンビネーション鍵を格納し、該装置で重畳して暗号化する構成とすることを含む。
【００２０】
前記構成により、データを暗号化して安全に送信し、最終的な受信側でのみ復号可能なシステムを提供することができる。  
送信側端末に２以上のコンビネーション鍵を格納した場合には、２者間の直接データ通信を高い強度の暗号化データで行うことができる。
【００２１】
この発明の態様として、前記所定条件に、全てのコンビネーション鍵を乗算して得た値を所定の除算用定数で除算した剰余が１となる条件を設定することができる。
【００２２】
前記構成により、複数段階の暗号化処理を経て、最終的な暗号化処理者のみが元のデータを取得可能とするセットの鍵を使用することが可能となる。
【００２３】
またこの発明の態様として、前記暗号化処理手段で実行する暗号化処理を、暗号化対象のデータに１つのコンビネーション鍵を乗算し、該乗算により得た値を前記所定の除算用定数で除算し、該除算により得た剰余を暗号データとして出力する処理に設定することができる。
【００２４】
これにより、複数段階の暗号処理を経て、最終的な受信者が復号処理を行い、該受信者のみが元のデータを取得することができる。
【００２５】
またこの発明の態様として、前記送信側装置と前記受信側装置の間でデータ送信を仲介する第三者機関の証明サーバを備え、該証明サーバに、前記コンビネーション鍵の残りの１を格納すると共に、前記暗号化処理手段と、前記受信側装置へ送信するデータとして所定の証明データを付加する証明データ付加手段とを備えることができる。
【００２６】
前記第三者機関の認証サーバは、サーバとして利用可能なコンピュータで構成することを含む。  
前記証明データは、送信側装置から最初暗号データを受信した受信時刻、送信側装置のアドレス等の送信者側特定情報、送信側装置に入力させたＩＤとパスワードや生体情報（指紋データ、又は網膜データ等）等による認証を実行した認証結果情報等、証明が可能なデータで構成することを含む。
【００２７】
前記構成により、認証サーバで送信側装置(若しくは送信者)の認証を行うことができ、送信者が正当であることやデータの受信時刻等を証明することができる。  
また、認証サーバでは送信側装置から受信した暗号データを元のデータに復号するができないため、送信側と受信側の中間での秘匿性を確保することができる。
【００２８】
またこの発明は、所定条件を満たす３以上のコンビネーション鍵で構成する鍵セットを生成する手段として、適宜求めた２以上の異なる素数をコンビネーション鍵として取得するコンビネーション鍵生成手段と、生成した複数のコンビネーション鍵を全て乗算し、さらに所定素数を乗算した値を所定の除算用定数で除算した余りが１となる前記所定素数を算出して、該所定素数もコンビネーション鍵として取得するコンビネーション鍵算出手段とを備えた鍵セット生成装置とすることができる。
【００２９】
前記素数を求める方法としては、乱数生成によって求める等、適宜の方法で求めることができる。  
これにより、異なるコンビネーション鍵で複数回暗号化処理を実行し、最後のコンビネーション鍵で暗号化処理を実行すれば元のデータが得られるコンビネーション鍵のセットを生成することができる。
【発明の効果】
【００３０】
この発明により、各自の管理する鍵数を減らし、送信途中での秘匿性を保持し、最終的な受信者のみが復号したデータを取得可能とすることができる。
【発明を実施するための最良の形態】
【００３１】
この発明の一実施形態を以下図面と共に説明する。  
【実施例１】
【００３２】
送信者から証明サーバを介して受信者にデータ送信を行うデータ送信システムについて説明する。  
まず、図１に示すデータ送信システム１のシステム構成図、及び図２〜図５のブロック図と共に、データ送信システム１のシステム構成について説明する。
【００３３】
データ送信システム１は、インターネット３に接続した送信者端末１０、証明サーバ３０、及び受信者端末５０と、スタンドアローンで設置した鍵生成サーバ７０とで構成する。
【００３４】
前記送信者端末１０はコンピュータで構成しており、図２のブロック図に示すように、制御装置１１に接続して記録媒体処理装置１２、入力装置１３、表示装置１４、通信装置１５、及び記憶装置１６を備えている。
【００３５】
前記制御装置１１は、ＣＰＵ、ＲＯＭ、及びＲＡＭで構成し、記憶装置１６に格納したプログラム（ＰＧ）に従って各種制御処理を実行する。  
前記記録媒体処理装置１２は、ＣＤ−ＲＯＭやＣＤ−ＲＷやＤＶＤ−ＲＯＭ等の記録媒体に対してデータの読書きを実行する。
【００３６】
前記入力装置１３は、マウスやキーボードで構成して利用者による入力を受け付ける。  
前記表示装置１４は、液晶モニタ又はＣＲＴディスプレイ等で構成して各種情報を表示する。
【００３７】
前記通信装置１５は、ＬＡＮボード等の通信可能な装置で構成して、インターネット３を介したデータの送信や受信を実行する。  
前記記憶装置１６は、ハードディスク等の記憶装置で構成して、コンビネーション鍵（組み合わせ鍵）Ｋ１を含む各種データ、及び暗号化プログラムやデータ通信プログラムを含む各種プログラムを格納する。
【００３８】
前記証明サーバ３０は、公的第三者が管理するコンピュータで構成しており、図３のブロック図に示すように、制御装置３１に接続して記録媒体処理装置３２、入力装置３３、表示装置３４、通信装置３５、及び記憶装置３６を備えている。
【００３９】
前記記憶装置３６には、ハードディスク等の記憶装置で構成して、コンビネーション鍵Ｋ２を含む各種データ、及び暗号化プログラムやデータ通信プログラムを含む各種プログラムを格納する。
【００４０】
他の装置３１〜３５は、前述した送信者端末１０の各装置１１〜１５の対応する装置と同一であるので、その詳細な説明を省略する。
【００４１】
前記受信者端末５０はコンピュータで構成しており、図４のブロック図に示すように、制御装置５１に接続して記録媒体処理装置５２、入力装置５３、表示装置５４、通信装置５５、及び記憶装置５６を備えている。
【００４２】
前記記憶装置５６には、ハードディスク等の記憶装置で構成して、コンビネーション鍵Ｋ３を含む各種データ、及び復号化プログラムやデータ通信プログラムを含む各種プログラムを格納する。
【００４３】
他の装置５１〜５５は、前述した送信者端末１０の各装置１１〜１５の対応する装置と同一であるので、その詳細な説明を省略する。
【００４４】
前記鍵生成サーバ７０はコンピュータで構成しており、図５のブロック図に示すように、制御装置７１に接続して記録媒体処理装置７２、入力装置７３、表示装置７４、及び記憶装置７６を備えている。
【００４５】
前記記憶装置７６には、ハードディスク等の記憶装置で構成して、各種データ、及びコンビネーション鍵生成プログラムを含む各種プログラムを格納する。
【００４６】
他の装置７１〜７４は、前述した送信者端末１０の各装置１１〜１４の対応する装置と同一であるので、その詳細な説明を省略する。
【００４７】
なお、鍵生成サーバ７０は通信装置を備えずスタンドアロンで構成し、生成した鍵はフレキシブルディスクやＣＤ−ＲＯＭといった記憶媒体に格納し、送信者、証明サーバ運営機関、及び受信者にはそれぞれ書留郵便等により物理的に送付する構成としている。
【００４８】
この構成に替えて、鍵生成サーバ７０に通信装置を備えてインターネット３に接続し、一般的な公開鍵と秘密鍵による鍵ペアを用いてコンビネーション鍵を送信する等、コンビネーション鍵を他の方法で暗号化して送信することも可能であることは、周知のとおりである。
【００４９】
以上の構成により、鍵生成サーバ７０でコンビネーション鍵Ｋ１〜Ｋ３を生成し、送信者端末１０、証明サーバ３０、及び受信者端末５０にそれぞれのコンビネーション鍵Ｋ１〜Ｋ３を配布することができる。
【００５０】
送信者端末１０はデータをコンビネーション鍵Ｋ１で暗号化して証明サーバ３０へ送信し、証明サーバ３０はコンビネーション鍵Ｋ２で暗号化して受信者端末５０に送信し、受信者端末５０はコンビネーション鍵Ｋ３で復号して元のデータを取得することが可能となる。
【００５１】
次に、図６の説明図と共に、データ送信システム１で使用する暗号化方式で必須となるコンビネーション鍵の必要条件について説明する。
【００５２】
この実施形態では、（Ａ）に示すように３つのコンビネーション鍵Ｋ１，Ｋ２，Ｋ３を使用し、この３つのコンビネーション鍵で１つの鍵セットを構成している。
【００５３】
各コンビネーション鍵Ｋ１，Ｋ２，Ｋ３はいずれも素数であり、いずれも異なる数値（値）で構成している。
【００５４】
この実施形態では、文字列を暗号化するため、（Ｂ）に示すように、データの構成要素の種類数を文字種類数ｃとし、ブロック単位をｂとして、文字種類数ｃをブロック単位ｂでべき乗した値を除算用定数ｎに設定する。
【００５５】
また、（Ｃ）に示すように、各コンビネーション鍵Ｋ１，Ｋ２，Ｋ３は、全てを乗算した値を除算用定数ｎで割った余りが１となる関係の素数で構成している。
【００５６】
このようにして、鍵条件に整数と素数の直積集合上の剰余の性質を利用している。該性質について詳述すると、任意の非負整数ｘと、素数ｐの積に対する３以上の自然数を法とする剰余積×の結果は非負整数である。  
【数１】
2005258188.tif 000003
この剰余積演算に対して単位元１が存在する。  
【数２】
2005258188.tif 000004
整数集合の任意の元ｘに対して、素数ｐとｑの剰余積を適用すると、その結果が単位元１になる素数（逆元）ｒが存在する。  
【数３】
2005258188.tif 000005
以上の条件を満たすコンビネーション鍵Ｋ１，Ｋ２，Ｋ３を使用することで、送信者端末１０、及び証明サーバ３０で１回ずつ暗号化処理を行い、受信者端末５０で１回復号化処理をして原文データを取得することが可能となる。
【００５７】
これにより、（Ｄ）の概念図に示すように、平文Ｘをコンビネーション鍵Ｋ１で暗号化すると第１暗号文Ｙとなり、該第１暗号文Ｙをコンビネーション鍵Ｋ２で暗号化すると第２暗号文Ｚとなり、該第２暗号文Ｚをコンビネーション鍵Ｋ３で暗号化すると平文Ｘとなるセット鍵Ｋ１，Ｋ２，Ｋ３が得られる。
【００５８】
なお、コンビネーション鍵Ｋ１，Ｋ２，Ｋ３は、いずれも６４バイト以下（後述する暗号化処理でのブロック化単位以下）の素数とすることが望ましい。
【００５９】
次に、図７に示す鍵生成サーバ７０の制御装置７１の動作を示す処理フロー図と共に、上述したコンビネーション鍵Ｋ１，Ｋ２，Ｋ３を生成するコンビネーション鍵生成処理について説明する。
【００６０】
鍵生成サーバ７０の制御装置７１は、まず乱数生成処理を行い、該乱数から素数Ａを取得する（ステップｓ１）。
【００６１】
制御装置７１は、さらに乱数生成処理を行って、前記素数Ａとは異なる素数Ｂを取得する（ステップｓ２）。
【００６２】
制御装置７１は、前記素数Ａと素数Ｂとを乗算してさらにＣを乗算し、その計算値を除算用定数ｎで割った余りが１となる正の数Ｃを算出する（ステップｓ３）。
【００６３】
Ｃが素数でなかった場合は（ステップｓ４）、前記ステップｓ１にリターンして処理を繰返し、Ｃが素数であった場合は、素数Ａをコンビネーション鍵Ｋ１に、素数Ｂをコンビネーション鍵Ｋ２に、素数Ｃをコンビネーション鍵Ｋ３に設定し（ステップｓ５）、処理を終了する。
【００６４】
以上の動作により、データ送信システム１に必要なコンビネーション鍵Ｋ１〜Ｋ３を生成することができる。
【００６５】
具体的なコンビネーション鍵Ｋ１，Ｋ２，Ｋ３としては、図８の説明図に示すように簡易化したデータ例で説明すると、ＡからＺまでのアルファベットに０から２５までの数値を割り付け、文字数を２６とした場合、コンビネーション鍵Ｋ１＝３，コンビネーション鍵Ｋ２＝５，コンビネーション鍵Ｋ３＝７とすることができる。
【００６６】
各コンビネーション鍵Ｋ１，Ｋ２，Ｋ３をかけると、  
３×５×７＝１０５
となり、この値（１０５）を文字数である２６で割った余りは、  
ｍｏｄ（１０５，２６）＝１
となる。従って、前述したコンビネーション鍵の必要条件を満たす３つの組み合わせの鍵セットが得られる。
【００６７】
次に、図９に示す処理フロー図と共に、送信者端末１０から証明サーバ３０を介して受信者端末５０へデータを暗号化して送信するデータ送信処理について説明する。
【００６８】
まず、送信者により送信者端末１０が操作され、送信するデータが作成される（ステップｎ１）。この実施形態では、簡易例として「ＤＯＧ」の文字データを送信する場合について具体例を示しながら説明する。
【００６９】
送信者端末１０は、送信者の操作に基づいて暗号化プログラムを実行し、送信用のデータをコンビネーション鍵Ｋ１で暗号化する（ステップｎ２）。
【００７０】
ここで、図１０に示す処理フロー図と共に、暗号化処理について説明する。  
該暗号化処理ではブロック暗号を用いるため、まず送信用のデータを６４バイト（ブロック化単位）毎にブロック化する（ステップｐ１）。このときのブロック数をｍとし、ブロック単位（１ブロックに含める要素数）をｂとする。
【００７１】
カウンタ変数ｉに１を代入して初期化し（ステップｐ２）、乗算値（ｉ）にブロック（ｉ）とコンビネーション鍵を乗算した値を代入する（ステップｐ３）。  
算出した乗算値（ｉ）を除算用定数ｎで割った余りを剰余値（ｉ）に代入する（ステップｐ４）。
【００７２】
カウンタ変数ｉにｉ＋１を代入してカウントアップし（ステップｐ５）、カウンタ変数ｉがブロック数ｍを超えるまでステップｐ３〜ｐ５を繰り返す（ステップｐ６）。
【００７３】
カウンタ変数ｉがブロック数ｍを超えると、暗号化データとして剰余値（１）から剰余値（ｍ）を並べた数値を取得する（ステップｐ７）。
【００７４】
簡易例として送信用の文字データに「ＤＯＧ」を使用し、ブロック単位を１文字に設定した場合、図９のステップｎ２に陰線で示すように、「Ｄ」「Ｏ」「Ｇ」の各文字要素のコード値「０３」「１４」「０６」に対して、コンビネーション鍵Ｋ１の値「３」をそれぞれ乗算する。
【００７５】
乗算して得た各値を、除算用定数「２６」（文字種類数２６をブロック単位１でべき乗した値）でそれぞれ除算したそれぞれの剰余「０９」「１６」「１８」を第１暗号文「ＪＱＳ」として取得する。
【００７６】
このようにして取得した第１暗号化データ（上記１暗号文「ＪＱＳ」）を、送信者端末１０は認証サーバ３０に送信する（ステップｎ３）。
【００７７】
認証サーバ３０は、前記第１暗号化データを受信し（ステップｎ４）、コンビネーション鍵Ｋ２で第１暗号化データに重畳して暗号化を行う（ステップｎ５）。
【００７８】
具体例では、図のステップｎ５に陰線で示すように、「Ｊ」「Ｑ」「Ｓ」の各文字要素のコード値「０９」「１６」「１８」に対して、コンビネーション鍵Ｋ２の値「５」をそれぞれ乗算する。
【００７９】
乗算して得た各値を、除算用定数「２６」でそれぞれ除算したそれぞれの剰余「１９」「０２」「１２」を第２暗号文「ＴＣＭ」として取得する。
【００８０】
このようにして取得した第２暗号化データ（上記２暗号文「ＴＣＭ」）を、認証サーバ３０は受信者端末５０に送信する（ステップｎ６）。
【００８１】
受信者端末５０は、前記第２暗号化データを受信し（ステップｎ７）、コンビネーション鍵Ｋ３で第２暗号化データに対して復号化を行う（ステップｎ８）。
【００８２】
この復号化処理は前述した暗号化処理（図１０）と同一であり、図９のステップｎ８に陰線で示すように、「Ｔ」「Ｃ」「Ｍ」の各文字要素のコード値「１９」「０２」「１２」に対して、コンビネーション鍵Ｋ３の値「７」をそれぞれ乗算する。
【００８３】
乗算して得た各値を、除算用定数「２６」でそれぞれ除算したそれぞれの剰余「０３」「１４」「０６」を文字列として、元の平文データである「ＤＯＧ」を取得する（ステップｐ９）。
【００８４】
以上の動作により、送信者端末１０でコンビネーション鍵Ｋ１で暗号化処理し、第三者機関である認証サーバ３０がコンビネーション鍵Ｋ２で暗号化処理を行わないと、受信者端末５０では復号化できないため、証明サーバ３０による送信者の本人認証が可能となる。
【００８５】
すなわち、他人が認証サーバ３０を介して受信者端末５０にデータ送信しても、その元データがコンビネーション鍵Ｋ１で暗号化されていなければ受信者は正常な元のデータが得られないため、本人でないことがわかる。
【００８６】
また、利用方法が簡便で、直列的に重畳して暗号化してゆくため堅牢度が高く、暗号処理に要する時間も短いデータ送信システム１を提供することができる。
【００８７】
また、送信者が認証サーバ３０を介さず受信者端末５０にデータ送信しても、受信者は正常な元のデータが得られないため、正規のルートで送信されたデータではないことがわかる。
【００８８】
また、認証サーバ３０では元のデータを得ることが出来ないため、送信者端末１０からデータ送信されて受信者端末５０でデータ受信するまでの間で、データの内容の秘匿性を確保することが出来る。
【００８９】
また、送信者、証明サーバ管理機関、受信者はそれぞれ１つの鍵を管理するだけで、その鍵で各自が一度暗号化処理（若しくは復号化処理）を行うだけでデータ送信を安全に行うことができる。  
従って、鍵管理が容易であり、暗号化処理も全体として高速に行うことができる。
【００９０】
また、コンビネーション鍵Ｋ１，Ｋ２，Ｋ３には、各鍵を乗算した値を文字数である除算用定数ｎで割った余りが１となる素数、すなわち、
【数４】
2005258188.tif 000006
を満たすＡ，Ｂ，ＣをＫ１，Ｋ２，Ｋ３として使用しているため、一般に提供されているＲＳＡ暗号の２倍程度の堅牢度が得られ、データを安全に送信することができる。
【００９１】
なお、証明サーバ３０を備えず、送信者端末１０から受信者端末５０へ直接データ送信する構成としても良い。  
この場合、送信者端末１０でコンビネーション鍵Ｋ１とＫ２を用いて第２暗号化データを生成した上で送信し、受信側端末５０はコンビネーション鍵Ｋ３で復号化することができる。
【００９２】
これにより、堅牢度の高い暗号化処理を利用した直接データ送信を実行することができる。
【００９３】
また、コンビネーション鍵はＫ１，Ｋ２，Ｋ３の３つ組セットで構成したが、４つ組以上のセットで攻勢しても良い。  
この場合は、コンビネーション鍵には
【数５】
2005258188.tif 000007
を満たすＡ，Ｂ，Ｃ，Ｄ，…をＫ１，Ｋ２，Ｋ３，Ｋ４，…として使用すればよい。
【００９４】
これにより、送信者と受信者の間に複数の機関が介在するような場合でも、各機関で１度ずつ暗号化処理を実行し、正常ルートでのデータ送信であることを証明することができる。
【実施例２】
【００９５】
第２実施例として、コンビネーション鍵の必要条件として異なる条件を設定した場合について説明する。
【００９６】
この実施例では、鍵の長さである鍵長を例えば５１２ビットにそれぞれ設定したコンビネーション鍵Ｋ１，Ｋ２，Ｋ３に、各鍵を乗算してｍ乗した値を除算用定数ｎで割った余りが１となる素数、すなわち、
【数６】
2005258188.tif 000008
を満たすＡｍ，Ｂｍ，ＣｍをＫ１，Ｋ２，Ｋ３として使用する。  
このときのＡ，Ｂ，Ｃは、それぞれ２５６ビットとする。
【００９７】
この場合は、べき乗の数であるｍに、  
１０≦ｍ≦２０
となるｍを使用することが望ましく、特にｍ＝１３若しくはｍ＝１４を使用することが望ましい。
【００９８】
この場合の鍵生成アルゴリズムは、図１１の処理フロー図に示すように、鍵生成サーバ７０の制御装置７１が、まず乱数ｍを生成する（ステップｒ１）。このとき、乱数ｍは（１０≦ｍ≦２０）を満たすように生成する。
【００９９】
制御装置７１は、次に乱数生成処理を行い、該乱数から素数Ａを取得する（ステップｒ２）。
【０１００】
制御装置７１は、さらに乱数生成処理を行って、前記素数Ａとは異なる素数Ｂを取得する（ステップｒ３）。
【０１０１】
制御装置７１は、前記素数Ａと素数Ｂとを乗算してさらにＣを乗算し、その計算値をｍ乗した値を除算用定数ｎで割った余りが１となる正の数Ｃを算出する（ステップｒ４）。
【０１０２】
Ｃが素数でなかった場合は（ステップｒ５）、前記ステップｒ２にリターンして処理を繰返し、Ｃが素数であった場合は、素数Ａをコンビネーション鍵Ｋ１に、素数Ｂをコンビネーション鍵Ｋ２に、素数Ｃをコンビネーション鍵Ｋ３に設定し（ステップｒ６）、処理を終了する。
【０１０３】
以上の動作により、データ送信システム１に必要なコンビネーション鍵Ｋ１〜Ｋ３を生成することができる。
【０１０４】
他の構成及び動作は、前述した第１実施例と同一であるので、その詳細な説明を省略する。
【０１０５】
このように設定した場合であっても、一般に提供されているＲＳＡ暗号と同等の堅牢度であるため、十分な堅牢度の暗号化を行ってデータ送信することが可能である。
【０１０６】
なお、コンビネーション鍵Ｋ１，Ｋ２，Ｋ３の鍵長を１，０２４に設定し、ｍとしては２０≦ｍ≦５０となるｍを使用する等、Ａｍがコンビネーション鍵Ｋ１，Ｋ２，Ｋ３の鍵長を上回り、かつ、Ａｍがコンビネーション鍵Ｋ１，Ｋ２，Ｋ３の鍵長を大きくは上回らない関係となる他の設定を使用しても良い。
【０１０７】
また、上記条件を満たしつつ、Ａ，Ｂ，Ｃがなるべく大きな値となるようにｍを設定することが望ましい。  
なお、上述した実施例１は、この実施例２でｍ＝１とした場合に相当する。
【実施例３】
【０１０８】
第３実施例として、前述したデータ送信システム１の応用例の１つである電子入札システム１００について説明する。
【０１０９】
図１２のシステム構成図に示すように、電子入札システム１００は、供給者端末（送信者側）１１０、入札サーバ１３０、及び調達者端末（受信者側）１５０を、インターネット３に接続して構成する。
【０１１０】
前記供給者端末１１０は、入札者側である供給者が使用する端末であり、前述した第１実施例の送信者端末１０（図２）と同一構成のコンピュータである。ただし、記憶装置に記憶するデータとして、図１２に示すように供給者端末１１０の秘密鍵と入札サーバ１３０の公開鍵をさらに追加格納している。該公開鍵と秘密鍵は、一般的なＲＳＡ暗号方式等に使用するものである。
【０１１１】
前記入札サーバ１３０は、公的第三者が提供する入札用のサーバであり、証明機能を有している。  
該前記入札サーバ１３０の構成は、前述した第１実施例の証明サーバ３０（図３）と同様のコンピュータで構成しているが、図１３のブロック図に示すように、記憶装置１３６に記憶するものが異なっている。
【０１１２】
すなわち、記憶装置１３６には、コンビネーション鍵Ｋ２、暗号化プログラム、及びデータ通信プログラムに加えて、コンビネーション鍵生成プログラム、ＷＥＢサーバプログラム、サーバ１３０の秘密鍵、供給者端末１１０の公開鍵、及び調達者端末１５０の公開鍵を格納している。  
これにより、入札サーバ１３０は鍵生成サーバとして機能すると共に、ＷＥＢサーバとして機能する。
【０１１３】
前記調達者端末１５０は、入札募集を行う調達者が使用する端末であり、前述した第１実施例の受信者端末５０（図４）と同一構成のコンピュータである。ただし、記憶装置に記憶するデータとして、図１２に示すように調達者端末１５０の秘密鍵と入札サーバ１３０の公開鍵をさらに追加格納している。該公開鍵と秘密鍵は、一般的なＲＳＡ暗号方式等に使用するものである。
【０１１４】
以上の構成により、供給者は供給者端末１１０を使用して入札募集を行い、調達者は調達者端末１５０を使用して入札申し込みを行い、入札サーバ１３０が介在して公正な入札処理を実行することができる。
【０１１５】
次に、図１４に示す入札システム１００の全体動作を示す処理フロー図、及び図１５に示す動作イメージ図と共に、入札募集開始から入札完了までの入札処理について説明する。
【０１１６】
調達者端末１５０は、調達者によって作成された入札募集情報を入札サーバ１３０に送信するＲＦＱ送信を実行する（ステップｔ１）。
【０１１７】
入札サーバ１３０は、受信した入札募集情報を入札案件として公示し（ステップｔ２）、入札に参加可能な複数の供給者に対して入札案件の閲覧を許容する。このとき閲覧可能な入札案内データとしては、入札日（入札期限）、調達者名、及びＲＦＱ−ＩＤ（入札案件を特定するＩＤ）等を設定する。
【０１１８】
供給者端末１１０は、供給者の操作によって入札サーバ１３０でＷＥＢ公開されている入札案件から参加したい案件のデータを取得し（ステップｔ３）、入札意志の通知としてＭＯＩ情報を入札サーバ１３０へ送信する（ステップｔ４）。
【０１１９】
入札サーバ１３０は、ＭＯＩ情報を受信するとコンビネーション鍵生成処理（第１実施例の図７と同一）を実行してコンビネーション鍵Ｋ１，Ｋ２，Ｋ３を生成する（ステップｔ５）。
【０１２０】
生成したコンビネーション鍵のうち鍵Ｋ１を供給者端末１１０へ送信して該供給者端末１１０が受信し（ステップｔ７）、鍵Ｋ３を調達者端末１５０へ送信して該調達者端末１５０が受信する（ステップｔ８）。
【０１２１】
供給者端末１１０は、前記ステップｔ４でＭＯＩ情報を送信した後に、供給者に対して入札情報の作成を許容する（ステップｔ９）。  
該入札情報は、図１６のデータ説明図に示すように、入札を申し込む案件を特定する申込部と、入札金額等の詳細内容を格納する入札部とで構成する。
【０１２２】
前記申込部には、入札日（Date of Bidding）、申込時刻（Time of the day）、調達者名（Aquirer Name）、供給者名（Suppelior Name）、入札担当者名（Name of the pweson bidding）を格納する。
【０１２３】
前記入札部には、調達者ＩＤ（Acquirer id）、ＲＦＱ−ＩＤ（RFQ identiffer）、ビッドＩＤ（Bid indentiffer）、供給者ＩＤ（Supplier id）、通貨（Currency）、ビッド価格（Bidding price）を格納する。
【０１２４】
このように作成した入札情報を、供給者端末１１０はコンビネーション鍵Ｋ１で暗号化する（ステップｔ１０）。  
供給者端末１１０は、入札処理を実行して、前記暗号化による第１暗号化データを入札サーバ１３０へ送信する（ステップｔ１１）。
【０１２５】
このとき供給者端末１１０は、図１７の暗号化説明図の（Ｆ）に示すように、入札情報のハッシュ値を求め、該ハッシュ値を入札情報の申込部に付加して供給者の秘密鍵で暗号化する。そして、コンビネーション鍵Ｋ１で暗号化した入札情報（第１暗号化データ）と共に、入札サーバ１３０の公開鍵で暗号化し、これを入札サーバ１３０に送信する設定としている。
【０１２６】
入札サーバ１３０は、供給者端末１１０からデータを受信して入札受付処理を行う（ステップｔ１２）。該入札受付処理では、図１７の（Ｇ）に示すように、入札サーバ１３０の公開鍵でデータを復号化して保管する。
【０１２７】
このとき、さらに供給者端末１１０の公開鍵で復号化することで、申込部が閲覧可能となって入札対象の特定等を実行できると共に、ハッシュ値を利用して第１暗号化データが改ざん等されていないか確認することができる。
【０１２８】
入札サーバ１３０は、受付データに含まれていた第１暗号化データに対して、コンビネーション鍵Ｋ２で暗号化処理を実行して第２暗号化データを取得する（ステップｔ１３）。  
入札サーバ１３０は、入札期限がくるまで待機し（ステップｔ１４）、期限が来ると、受付データ開示処理を実行する（ステップｔ１５）。
【０１２９】
該受付データ開示処理では、図１７の（Ｈ）に示すように、入札情報の申込部に入札情報のハッシュ値を付加して供給者の秘密鍵で暗号化されたデータと、第２暗号化データ（Ｋ２×Ｋ１×入札情報）と、タイムスタンプ情報とを入札サーバ１３０の秘密鍵で暗号化し、この暗号化前のデータから求めたハッシュ値を付加して調達者端末１５０の公開鍵で暗号化したデータを調達者端末１５０へ開示データとして送信する。
【０１３０】
なお、前記タイムスタンプ情報は、入札サーバ１３０が供給者端末１１０から第１暗号化データを入札申込データとして受信したとき（ステップｔ１２）の日付、時刻等で構成する。
【０１３１】
調達者端末１５０は、開示データ受信処理を実行し、図１７の（Ｉ）に示すように、受信した開示データを調達者端末１５０の秘密鍵で復号し、さらに入札サーバ１３０の公開鍵で復号化することで、第２暗号化データとタイムスタンプ情報が得る（ステップｔ１６）。
【０１３２】
調達者端末１５０は、開示データから取得した第２暗号化データをコンビネーション鍵Ｋ３で復号化し（ステップｔ１７）、入札情報を取得する事ができる（ステップｔ１８）。
【０１３３】
なお、各暗号化処理（ステップｔ１０，ｔ１３）及び復号化処理（ステップｔ１）は、第１実施例の暗号化処理（図１０）と同一であるため詳細な説明を省略する。
【０１３４】
また、その他の構成、及び動作についても、前述した第１実施例と同一であるため、同一要素に同一名称を付してその詳細な説明を省略する。
【０１３５】
以上の構成及び動作により、適正な入札を行うことが可能となる。供給者が送信する入札情報のうち、入札部に格納されている入札金額等の機密データは、供給者端末１１０で第１暗号化処理がなされ、入札サーバ１３０で第２暗号化処理がなされる正規ルートを通過しなければ、調達者端末１５０で復号化処理をして正常データを得ることができないため、機密性を保持することができる。
【０１３６】
また、申込部については入札サーバ１３０で閲覧できるため、入札申込の受け付け等の処理は適正に行うことができ、複数の入札案件が同時進行するような場合でも問題なく処理することができる。
【０１３７】
なお、入札サーバ１３０にコンビネーション鍵生成プログラムを格納せず、第１実施例と同様に鍵生成サーバを備える構成としても良い。この場合は、鍵生成サーバに通信装置を備え、インターネット３に接続すると良い。
【０１３８】
動作としては、図１４のステップｔ５で入札サーバ１３０がＭＯＩ情報を受信すると、入札サーバ１３０が鍵生成サーバへ鍵生成依頼と鍵送付先（供給者端末１１０、入札サーバ１３０、調達者端末１５０）を通知する。
【０１３９】
鍵生成サーバは、上記通知を受けて鍵生成処理（図１４のステップｔ５に対応）と鍵送信処理（図１４のステップｔ６に対応）を実行する設定とする。  
鍵送信処理では、供給者端末１１０にコンビネーション鍵Ｋ１を送信し、入札サーバ１３０にコンビネーション鍵Ｋ２を送信し、調達者端末１５０にコンビネーション鍵Ｋ３を送信する設定とする。
【０１４０】
これにより、入札の管理を行う機関と鍵配布を行う機関を分けることができるため、情報漏洩に対する安全性を向上することができる。
【０１４１】
また、公開鍵と秘密鍵による一般的な暗号化処理を行わない構成としても良い。この場合は、入札情報の申込部やタイムスタンプが平文で通信回路を電送されることとなる。しかし、入札部を含む入札情報自体はコンビネーション鍵で強固に暗号化されているため、最も重要な部分の機密性は確保することができ、その上で管理する鍵の数を減少し、暗号化に要する時間を短縮することができる。
【実施例４】
【０１４２】
第４実施例として、第１、第２実施例で説明したデータ送信システム１の応用例の１つである電子通貨システム２００について説明する。
【０１４３】
図１８のシステム構成図に示すように、電子通貨システム２００は、支払者端末（送信者側）２１０、振替サーバ（金融機関）２３０、及び受領者端末（受信者側）２５０を、インターネット３に接続して構成する。
【０１４４】
前記支払者端末２１０は、料金を支払う側である支払者が使用する端末であり、前述した第１実施例の送信者端末１０（図２）と同一構成のコンピュータである。
【０１４５】
前記振替サーバ２３０は、金融機関が提供する振替用のサーバであり、証明機能及び更新機能（電子通貨の正当所持者を更新する機能）を有している。  
該前記振替サーバ２３０の構成は、前述した第３実施例の入札サーバ１３０（図３）と同一構成のコンピュータである。
【０１４６】
前記受領者端末２５０は、支払者が支払う料金を受領する受領者が使用する端末であり、前述した第１実施例の受信者端末５０（図４）と同一構成のコンピュータである。
【０１４７】
以上の構成により、支払者は支払者端末２１０を使用して電子通貨による料金の支払を行い、受領者は受領者端末２５０を使用して電子通貨による入金を受け、振替サーバ２３０が介在して公正な支払処理を実行することができる。
【０１４８】
次に、図１９に示す電子通貨システム２００の全体動作を示す処理フロー図、及び図２０に示す動作イメージ図と共に、支払要求から支払完了までの支払処理について説明する。
【０１４９】
受領者端末２５０は、支払者によって作成された支払要求情報を振替サーバ２３０に送信するＯＯＰ（Order of Payment）送信を実行する（ステップｕ１）。
【０１５０】
この支払要求情報は、図２１の説明図の（Ｐ）に示すように、支払者ＩＤ（Pauer ID）、受取人ＩＤ（Recipient ID）、支払額（Amount of Payment）、支払時刻（Time of Payment）、支払トークン金額（Payment Token Amount）、釣銭トークン金額（Change Token Amount）、及び通貨単位（Currency）の各項目で構成する。
【０１５１】
振替サーバ２３０は、支払要求情報を受信するとコンビネーション鍵生成処理（第１実施例の図７と同一）を実行してコンビネーション鍵Ｋ１，Ｋ２，Ｋ３を生成する（ステップｕ２）。
【０１５２】
生成したコンビネーション鍵のうち鍵Ｋ１を支払者端末２１０へ送信し、鍵Ｋ３を受領者端末２５０へ送信する（ステップｕ３）。
【０１５３】
支払者端末２１０は、鍵Ｋ１を受信し（ステップｕ４）、電子通貨（Money Token）をコンビネーション鍵Ｋ１で暗号化し（ステップｕ５）、この第１暗号化データを電子通貨の所持者データと共に振替サーバ２３０に送信する（ステップｕ６）。
【０１５４】
なお、前記電子通貨は、図２１の（Ｑ）に示すように、トークンＩＤ（Token ID）、金額（Amount of Money）、通貨（Currency）、発行元ＩＤ（Issuer’s ID）、発行時刻（Time of Issue）、及び発行者署名（Issuer’s Signature）の各項目で構成する。
【０１５５】
ここで、電子通貨のフォーマット（Money Token Format）は、図２２の説明図の（Ｒ）に示すように、振替日（Date of transfer）、発信者（sender’s identifier）、受取人（receiver’s identifier）、トークンＩＤ（token_id）、金額（amount）、通過単位（currency）、発行元ＩＤ（issuer_id）、発行日（issue_date）、発行時（issue_time）、及び発行者署名（signature）で構成する。
【０１５６】
また発行者署名（signature）については、図２２の（Ｓ）に示す条件により真偽判別を実行することができる構成としている。
【０１５７】
受領者端末２５０は、前記ステップｕ３で振替サーバ２３０から送信されたコンビネーション鍵Ｋ３を受信し（ステップｕ７）、電子通貨（釣銭金額分）をコンビネーション鍵Ｋ３で暗号化し（ステップｕ８）、この第１暗号化データを振替サーバ２３０に送信する（ステップｕ９）。
【０１５８】
振替サーバ２３０は、支払者端末２１０及び受領者端末２５０から受信した各電子通貨に対して、正当な持ち主を変更する更新処理を実行する（ステップｕ１０）。  
なお、この更新処理は、電子通貨の所持者データに対して実行すればよい構成としており、暗号化されている電子通貨部分が見れなくとも電子通貨の持ち主を変更可能としている。
【０１５９】
振替サーバ２３０は、支払者端末２１０及び受領者端末２５０から受信した各電子通貨に対して、コンビネーション鍵Ｋ２でさらに暗号化して、電子通貨に基づく第２暗号化データを作成する。（ステップｕ１１）。
【０１６０】
振替サーバ２３０は、振替期限がくるまで待機し（ステップｕ１２）、期限が来ると、更新した電子通貨を送信して振り替えを完了させる振替処理を実行する（ステップｕ１３）。
【０１６１】
該振替処理では、支払者端末２１０から受信した第１暗号化データ（支払い用電子通貨）を、所持者更新して鍵Ｋ２で重畳暗号化した状態で受領者端末２５０へ送信し、受領者端末２５０から受信した第１暗号化データ（釣銭用電子通貨）を、所持者更新して鍵Ｋ２で重畳暗号化した状態で支払者端末２１０へ送信する。
【０１６２】
支払者端末２１０は、受信した第２暗号化データに対して（ステップｕ１４）、コンビネーション鍵Ｋ１で復号化を行い（ステップｕ１５）、釣銭に該当する電子通貨を取得して支払を完了する（ステップｕ１６）。
【０１６３】
受領者端末２５０は、受信した第２暗号化データに対して（ステップｕ１７）、コンビネーション鍵Ｋ３で復号化を行い（ステップｕ１８）、支払金額に該当する電子通貨を取得して受領を完了する（ステップｕ１９）。
【０１６４】
以上の構成及び動作により、適正な電子通貨の交換を行うことが可能となる。支払者端末２１０及び受領者端末２５０から送信された各電子通貨の第１暗号化データは、振替サーバ２３０でコンビネーション鍵Ｋ２で暗号化されることで、互いに支払者端末２１０及び受領者端末２５０が受信した各第２暗号化データを復号することができる。
【０１６５】
振替サーバ２３０は、第１暗号化データを復号化できないため、金額の中身を知ることや改ざんすることができず、機密性を保持することができる。
【０１６６】
なお、振替サーバ２３０にコンビネーション鍵生成プログラムを格納せず、別途鍵生成サーバを備える構成としても良いことは、前述した第３実施例と同様である。
【０１６７】
また、コンビネーション鍵を用いて暗号化する電子通貨以外の部分、すなわち所持者等を表す部分については、公開鍵と秘密鍵による暗号化等、他の一般的な暗号化処理を適用しても良い。
【０１６８】
これにより、振替サーバ２３０と支払者端末２１０又は受領者端末２５０との２者間での暗号化データ通信と、第三者となる振替サーバ２３０が中継した支払者端末２１０と受領者端末２５０の暗号化データ通信とを実現することができる。
【０１６９】
なお、以上の各実施形態の他にも、電子投票システム等、送信者と受信者との間を仲介する第三者が存在するような他のシステムに対して、データ送信システム１を応用することもできる。  
これにより、様々なシステムで高度な機密性を保持して簡単な鍵管理でデータ送信を中継することができる。
【０１７０】
この発明の構成と、上述の実施形態との対応において、
この発明のデータ送信システムは、実施形態のデータ送信システム１、入札システム１００、及び電子通貨システム２００に対応し、
以下同様に、
送信側装置は、送信者端末１０、供給者端末１１０、支払者端末２１０、及び受領者端末２５０に対応し、
証明サーバは、証明サーバ３０、入札サーバ１３０、及び振替サーバ２３０に対応し、
受信側装置は、受信者端末５０、調達者端末１５０、支払者端末２１０、及び受領者端末２５０に対応し、
鍵セット生成装置は、鍵生成サーバ７０に対応し、
暗号化処理手段は、暗号化プログラムを実行する制御装置１１，３１，５１，１３１に対応し、
コンビネーション鍵生成手段は、ステップｓ１，ｓ２を実行する制御装置７１に対応し、
コンビネーション鍵算出手段は、ステップｓ３を実行する制御装置７１に対応し、
証明データ付加手段は、タイムスタンプ情報を付加する制御装置１３１に対応し、
コンビネーション鍵は、コンビネーション鍵Ｋ１，Ｋ２，Ｋ３に対応し、
データは、「ＤＯＧ」，入札情報，電子通貨に対応し、
暗号化処理は、ステップｐ１〜ｐ７に対応し、
証明データは、タイムスタンプ情報に対応し、
第三者機関は、公的第三者、金融機関に対応するも、
この発明は、上述の実施形態の構成のみに限定されるものではなく、多くの実施の形態を得ることができる。
【図面の簡単な説明】
【０１７１】
【図１】データ送信システムのシステム構成図。
【図２】送信者端末のブロック図。
【図３】証明サーバのブロック図。
【図４】受信者端末のブロック図。
【図５】鍵生成サーバのブロック図。
【図６】コンビネーション鍵の必要条件の説明図。
【図７】コンビネーション鍵生成処理の処理フロー図。
【図８】暗号化対象のデータ例の説明図。
【図９】データ送信処理の処理フロー図。
【図１０】暗号化処理の処理フロー図。
【図１１】第２実施例の鍵生成処理の処理フロー図。
【図１２】第３実施例の電子入札システムのシステム構成図。
【図１３】証明サーバのブロック図。
【図１４】入札処理の処理フロー図。
【図１５】入札処理の動作イメージ説明図。
【図１６】入札情報のデータ説明図。
【図１７】暗号化説明図。
【図１８】第４実施例の電子通貨システムのシステム構成図。
【図１９】支払処理の処理フロー図。
【図２０】支払処理の動作イメージ説明図。
【図２１】電子通貨のデータ説明図。
【図２２】電子通貨のデータ説明図。
【符号の説明】
【０１７２】
１…データ送信システム
１０…送信者端末
１１…制御装置
３０…証明サーバ
３１…制御装置
５０…受信者端末
５１…制御装置
７０…鍵生成サーバ
７１…制御装置
１００…入札システム
１１０…供給者端末
１３０…入札サーバ
１３１…制御装置
１５０…調達者端末
２００…電子通貨システム
２１０…支払者端末
２３０…振替サーバ
２５０…受領者端末
Ｋ１，Ｋ２，Ｋ３…コンビネーション鍵
【図１】
2005258188.tif 000009
【図２】
2005258188.tif 000010
【図３】
2005258188.tif 000011
【図４】
2005258188.tif 000012
【図５】
2005258188.tif 000013
【図６】
2005258188.tif 000014
【図７】
2005258188.tif 000015
【図８】
2005258188.tif 000016
【図９】
2005258188.tif 000017
【図１０】
2005258188.tif 000018
【図１１】
2005258188.tif 000019
【図１２】
2005258188.tif 000020
【図１３】
2005258188.tif 000021
【図１４】
2005258188.tif 000022
【図１５】
2005258188.tif 000023
【図１６】
2005258188.tif 000024
【図１７】
2005258188.tif 000025
【図１８】
2005258188.tif 000026
【図１９】
2005258188.tif 000027
【図２０】
2005258188.tif 000028
【図２１】
2005258188.tif 000029
【図２２】
2005258188.tif 000030