JP2005065315A - 電子商取引用の暗号化方法 - Google Patents

電子商取引用の暗号化方法 Download PDF

Info

Publication number
JP2005065315A
JP2005065315A JP2004270384A JP2004270384A JP2005065315A JP 2005065315 A JP2005065315 A JP 2005065315A JP 2004270384 A JP2004270384 A JP 2004270384A JP 2004270384 A JP2004270384 A JP 2004270384A JP 2005065315 A JP2005065315 A JP 2005065315A
Authority
JP
Japan
Prior art keywords
location
cardholder
transaction
message
key
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.)
Pending
Application number
JP2004270384A
Other languages
English (en)
Inventor
Jay C Chen
シー． チェン，ジェイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of JP2005065315A publication Critical patent/JP2005065315A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4093—Monitoring of device authentication
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】 電子商取引のシステムであって、該システムはカード保持者（20）、商人（70）およびサービスプロバイダ（SP)(60）を包含する複数の当事者の間での安全保障された電子商取引を容易にする。
【解決手段】 システムはスマートカードとして普通に知られている電子カードおよびそれと等価のコンピュータソフトウェアのパッケージを必然に伴う。取引きはハイブリッドキイの暗号のシステムにより保護され、通常は公衆回線網例えばインターネット上で実行される。デジタルの署名およびランダム数が使用され統合性および認証性が確保される。カードは秘密キイ例えばサービスプロバイダ（SPS)により割当てられるセッションキイを使用し各取引の秘密性を確保する。SPは各加入者を有効化し、セッションキイを割当てることにのみ責任をもつ。取引きで必要である唯一の信用関係は、個別の加入者とSPの間に存在するものである。
【選択図】 図１

Description

本発明は、一般に安全な電子商取引（electronic transactions）のための暗号システムおよび暗号法に関するもので、詳記すれば、"スマートカード"および／またはこれと等価のソフトウェアの形を取る電子カード（electronic card)に関するものである。
属名"スマートカード"は一般に集積回路（IC）カード、すなわちマイクロチップを埋め込んだクレジットカード大のプラスチック片である。スマートカード上のICチップは、一般にマイクロプロセッサ（CPU）、リード・オンリー・メモリ（ROM）、ランダム・アクセス・メモリ（RAM）、入出力装置およびいくらか持続性のあるメモリ、例えば電気的消去可能なプログラマブル・リード・オンリー・メモリ（EEPROM）からなるが、必ずしもそうであるとは限らない。チップは、算術計算、論理処理、データ管理およびデータ通信を実行することができる。
スマートカードは主に2つのタイプがある。接触型と非接触型である。国際標準化機構（ISO）は、このような電子カードの仕様をISOシリーズのもとで確立した。特にISO 7816は集積回路カードに適用される。その計算能力のために、スマートカードは、認証、機密読み書き、対称／非対称型鍵暗号化／暗号解読など多数のセキュリティ特徴をサポートすることができる。これらのセキュリティ特徴により、スマートカードは、データ機密保護や認証が最重要項目である電子商取引に好適とされる。
スマートカードは、大量輸送、健康保険、パーキング、キャンパス、ガソリンスタンドなど多くの特化された分野で使われてきた。また、電子商取引および他の金融分野においてその潜在用途を急速に広げつつある。1996年5月28日付でRobert S. Powerに付与された「不正使用を防止する多重記憶メモリを有する電子財布カードとそのための方法」と題する米国特許第5,521,362号は、電子財布の用途について述べている。Powerの発明は、単なる記憶デバイスとしてでなく、安全な金融証券として使用できるスマートカードの能力を示威している。
技術の進歩がスマートカードチップ計算の高速化と記憶容量の大型化を急き立てるにつれて、"多用途"スマートカードのコンセプトは経済性と物理的な実現の可能性の点で重要度を増しつつある。1996年6月25日付でDouglas C. Taylorに付与された「多用途データカード」と題する米国特許第5,530,232号は、現在ある多数の単用途カードに取って代わり、金融目的の要件と非金融目的の要件の両方を満たすことのできる多用途カードについて述べている。多用途カードは、スマートカードとリモート・サービス・プロバイダの間の接続に従来のデータリンクを使用する。Tylorの発明である多用途カードは、いかなる種類のオープン・ネットワークにも暗号法にも関係していない。
1996年8月5日付でMandelhaum他に付与された「多数のサービス・プロバイダとそのリモート・インストレーションに適したスマートカード」と題する米国特許第5,544,246号は、相異なるサービス・プロバイダが同一のスマートカードの上に共存できるようにするスマートカードについて述べている。各サービス・プロバイダはスマートカードの1ユーザーとみなされ、スマートカードの発行者／所有者によってカード上にインストールされる。各ユーザーは、ツリー状のファイル構造を作らされ、パスワードファイルで保護させられる。Mandelhaumの発明は、多用途の創出と消去を考慮に入れたスマートカードについて述べている。Mandelhaumのスマートカードは、適当なパスワードファイルの使用によって各用途へのアクセスを制御する。
1997年9月23日付でTaher Elgamalに付与された「安全な急送システムを使用する電子商取引」と題する米国特許第5,671,279号は、公開／専有鍵暗号技術を使用する公共ネットワークを介して電子商取引を行うためのシステムについて述べている。Elgamalの特許は、電子商取引を行う中でスマートカードを道具として使用することに言及していなかったし、ディジタル証明方式の使用を通してそれが正しいと認められていた。安全な急送システムは、インターネットなどのオープン・ネットワークを介しての取引の当事者の間にセキュア・ソケット・レイヤ（SSL）などの機密保護されたチャンネルを要求している。
1. 1998年8月4日付でFox他に付与された「安全な電子商取引のためのシステムおよび方法」と題する米国特許第5,790,677号は、後に取引プロセスが続く登録システムをを有するシステムおよび方法について述べている。登録段階の間に、取引関係者は各々、信託された信用状結合サーバーに登録パケットを送ることによってそのサーバーに登録する。サーバーは、受け取ったリクエストに基づいて独自の信用状を作成し、これをリクエスト発信人に送る。取引段階の間に、取引リクエストの発信人は、商業文書および／または証券の受取人と目される人全員の信用状を受け取り、照合確認し、個々の受取人の公開鍵を使って文書および／または証券を暗号化する。こうして、受取側は各々、自分だけに向けられた情報を解読し、アクセスすることができる。Foxの特許が述べているのは、大手の金融会社とソフトウェア会社数社が、ディジタル証明書と認証局をベースとした電子商取引システムを確立すべく努力した目下の成果であるいわゆる"セキュア・エレクトロニック・トランザクション"（SET）規格のテーマを反映するプロセスである。
1998年8月18日付でDerek L. Davisに付与された「機密保護された通信を提供するための装置および方法」と題する米国特許第5,796,840号は、後続のメッセージ認証とデータ通信に使用すべきデバイス特定の鍵対を作成できる半導体デバイスについて述べている。半導体デバイスは、2つの通信側の認証を確実にするために公開／専有鍵暗号方式を使用する。
1996年7月9日付でSimon G. LaingおよびP. Bowcockに付与された「スマートカードの安全な分散個人化のための方法およびシステム」と題する米国特許第5,534,857号は、スマートカードの発行者が遠隔地にいる顧客のスマートカードに機密データを安全に書き込むための方法および装置について述べている。安全な端末と安全なコンピュータの間の暗号化データ伝送のための相互セッション鍵が、安全なコンピュータと小売り側スマートカードの中に保存された共通鍵を使用することによって作成される。
上に挙げた発明から、安全な電子商取引システムのアーキテクチャは、公開鍵インフラストラクチャおよびこれと結び付いたディジタル証明書認証局を包含することが明らかである。
オープン・ネットワークでは、秘密鍵ベースのシステムは、鍵分配および鍵管理の点で融通性を欠き、不正な攻撃を受けやすい。他方、公開／専有鍵ベースのシステムは、取引当事者を互いに認証し合う独自の予防的なタスクを有し、あらゆる点で秘密鍵ベースのシステムより有利である。本発明が提示するのは、これらのシステムおよび方法に取って代わる、認証局やディジタル証明書を必要としない別のシステムおよび方法である。本発明は、電子取引のためのハイブリッドシステムである。ハイブリッドシステムは、公開／専有鍵を鍵交換段階の間に使用し、セッション鍵を取引段階の間に秘密鍵として使用する。
本発明は、スマートカードまたは等価のソフトウェアの形の電子カード（EC）の使用と、通信網を介しての通信によって電子商取引を行うための暗号システムおよび暗号法に関するものである。
本発明の優先実施例は、インターネットなどのオープン・ネットワークを使用する。本発明の別の実施例は、別の種類のネットワークを使用してよい。本発明の一実施例は、物理的なスマートカード（smart card)を使用しても、あるいは、コンピュータソフトウェアパッケージとして実現させられ、パーソナルコンピュータ（PC）などの計算デバイスの上を走るスマートカードを使用してもよい。同様に、取引に関与したマーチャントが、ポイントオブセールス端末であるマーチャント・デバイスを使用しても、ECおよびサービス・プロバイダと通信するのにホストコンピュータ上のソフトウェアを使用するデバイスを使用してもよい。スマートカードを使用する時は、カードをホストデバイス、例えばネットワーク・レディ・マーチャント端末、PC、またはスマートカード取引をサポートできる他の何らかの電子デバイスと通信させるのにスマートカード・リーダーも必要となる。
公開鍵とディジタル証明書をベースとしたシステムでは、取引関係者が、認証局（certificate authority)（CA）または信用状結合サーバーによって発行、証明されるディジタル証明書または他の電子信用状の使用を通じて公開情報を交換する。CAまたはサーバーと各取引関係者の間の通信は安全でなければならない。関係者の間で転送されたメッセージの正当性と有効性を確実にするために乱数とディジタル署名が使用される。
本発明の優先実施例の暗号システムと暗号法も、公開（public)／専有（private)鍵暗号を使用するが、働き方は多少異なる。暗号システムと暗号法は、ディジタル証明書の保有者と認証局の間に存在するのと別の種類の信託関係を作ろうとはしない。それが特に標的としているのは、会員制をベースとした金融機関、例えば大手クレジットカード会社とそのすべてのカード保有者、または大銀行とその潜在利用者であるATMカード保有者などである。非金融機関も、この暗号システムと暗号法を使って、ネットワーク経由で商取引または非金融取引を行うことができる。
サービスプロバイダ（SP）は、何らかのサービスをその会員に提供する。金融機関は、まさしく一種のサービスプロバイダである。サービスプロバイダは、性格において非金融ということもあり得る。サービスプロバイダが金融機関であるか非金融機関であるかに関係なく、本質的に同じプロセスが進行する。金融機関の関わる取引と非金融機関の関わる取引の間の唯一の違いは、メッセージに含まれる可能性のあるデータフィールドが異なるということである。
EC保有者がサービスプロバイダのひとつと契約すると、サービスプロバイダは、EC上に専用エントリを作成する。各エントリは、サービスプロバイダに関する取引勘定情報、SP公開鍵、アクセス制御情報およびその他の関連データを包含する。各ECは、このようなエントリを所定の個数（例えば10個）サポートすることができ、その各々のエントリが1つのサービスプロバイダを表す。
公開／専有鍵暗号方式を使用することにより、鍵分配プロセスは大いに単純化される。EC保有者自身または信託された第三者、例えば銀行支店、または郵便局さえ、タスクを実行することができる。SP公開鍵は、SPとカード保有者の間の最初の鍵交換にしか使用されない。最初の鍵交換の後、SPは、その先のカード保有者とSPの間またはカード保有者相互間のメッセージ交換を保護するセッション鍵を割り当てる。
この公開／専有鍵暗号方式と秘密鍵（すなわちセッション（session)鍵）暗号方式の両方を使用するハイブリッドシステムは、他の秘密鍵システムと対照的である。ハイブリッドシステムでは、秘密鍵（すなわちセッション鍵）は単一のセッションに対して有効であり、他のセッションには適用できない。セッションは特定の時間的長さを有する。セッションは、時間周期に基づいて終わっても、満たされている条件に基づいて終わってもよい。
マーチャントが取引に関わった場合、マーチャントは、本質的にSPと通信するEC保有者と同じ手順を踏む。マーチャントは、先ずSPと鍵交換を行い、セッション鍵を受け取ることになる。セッション鍵は、マーチャントによってその後のSPとに通信に使用されることになる。カード保有者とマーチャントは、SPに向かう各メッセージにディジタルで署名し、SPも同様に、カード保有者とマーチャントに戻る応答メッセージに署名する。
取引が別の証明書ベースのシステムとの対話を要求する場合、SPは、最初の鍵交換に続く情報交換に基づいてカード保有者とマーチャントを認証した後、カード保有者とマーチャントのための代理証明者として働くことができる。最も極端な場合、SPは、単にこの代理の役割だけを果たし、証明書ベースのシステムのためのゲートウェイ（gateway)になる。この階層のタイプは、多重システムの中で取引を行うのに必要とされる信託関係の数を減らすので、大いに望ましい。加えて、これは、ユーザーが証明書を携える必要性を無くす。
詳細な説明
本発明は、スマートカードまたは等価のソフトウェアの形の電子カード（EC）の使用と、通信網を介しての通信によって電子商取引を行うための暗号システムおよび暗号法に関するものである。
本発明の優先実施例では、ネットワークはインターネットなどのオープン・ネットワークである。本発明の別の実施例では、サービスプロバイダとその会員の間の通信を確立するのに別のオープン・ネットワークおよび／またはクローズド・ネットワークを使用してよい。例えば、サービスプロバイダは、その会員との通信に独自の所有権を主張できる金融ネットワークを使用してよい。
インターネット接続には、どんなインターネット・プロトコルも使用してよい。使用できるプロトコルは、例えばTCP/IP、UDP、HTTP等々である。
通信は、通信網トランスポートサービス、例えば、伝統的なアナログ音声電話サービス（プレイン・オールド・テレフォン・サービスまたはPOTSとして知られている通りの）またはT-1、E1、DS-3データ回路などのディジタル通信サービスを使用する加入電話回線（PSTN）、ディジタル総合サービス網（ISDN）、ディジタル加入者回線（DSL）サービス、または無線サービスさえ使用するディジタル加入者回線等々を経由してよい。このようなサービスを使用すれば、本発明の実施例は、通信プロトコルに関係なく（すなわち電気インタフェース層において）実現できる。
通信はまた、ローカル・エリア・ネットワーク（LAN）またはワイド・エリア・ネットワーク（WAN）、例えばイーサネット、トークン・リング、FDDI、ATM等々を経由してもよい。使用できるプロトコルは、例えばTCP/IP、IPX、OSI等々である。
他の通信リンクとして考えられるのは、光接続、無線RFモデム接続、セルラ・モデム接続、サテライト接続等々である。
本発明は、サービスプロバイダとその会員の間に通信パスは確立できる限り、採用してよい。上の例は、本発明が実践できるさまざまな通信環境のいくつかの例を示す目的で挙げたものである。当業者には明らかな通り、本発明は、上に挙げた環境に制限されるものでない。
電子カード（EC）は、パーソナルコンピュータ（PC）などのコンピュータシステムの上を走るスマートカードデバイスまたはソフトウェアパッケージの形を取ることができる。ECがスマートカード上で実現した場合、これは、PCなどのネットワーク・レディ・コンピュータシステムにおいて別の会員および／または選択されたサービスプロバイダとの取引に使用することができる。コンピュータシステムやインターネット・ブラウザなどのアプリケーション・ソフトウェアと通信し、カード保有者やネットワークとのインタフェースを作るためには、読み書きインタフェースデバイスが必要となる。ECがコンピュータシステムにロードされたソフトウェア・パッケージである場合には、読み書きインタフェースが必要とされない。本発明の実施例は、ECが現実の財布と同様の機能を果たす電子ウォレット（またはサイバー・ウォレット）として働くことを見込んでいる。現実の財布は、クレジットカード、デビットカード、ATMカード、診察カード、会員カード、現金などを入れることができる。ECは、上に挙げた金融機関と非金融機関のすべてのディジタル等価物を有し、インターネットを介して安全な取引を実行できるようにする。
サービスプロバイダの会員は、マーチャントおよび／またはECカード保有者であり得る。マーチャントは、取引の結果としてサービスプロバイダから支払いを受ける会員である。会員は、マーチャントとEカード保有者の両方であり得る。マーチャントは、他のカード保有者との取引に加わってよく、その結果、サービスプロバイダから支払いを受けるマーチャントとなる。マーチャントはまた、ECカード保有者であってよく、例えばマーチャントサプライヤからの供給品を購入してよい。
暗号システムは、サービスプロバイダとその会員（どれだけの人数であっても）の間の通信に関わってよい。従って、ECとSPの間、マーチャントとSPの間、第1のECと第2のECとSPの間、第1のマーチャントと第2のマーチャントとSPの間等々で通信が可能である。ECは、例えば取引勘定残高について照会するためにサービスプロバイダと直接通信してよい。マーチャントがサービスプロバイダと通してしてよいのは、彼自身のためだけに限られ、ECに代わってしてはならない。なぜなら、マーチャントが知りたいのは、彼自身のサービスプロバイダとの取引の勘定残高だからである。SPとその会員の間の通信は、SPとその会員のどんな変更にも従ってよい。SPとその会員の間の通信リンクの編成は、順次編成であっても階層編成であってもよい。SPとその会員の間の通信はまた、SPとその会員の間のメッセージのルートを決めるルータを経由してもよい。
暗号法は、2段階式の鍵交換取引の一モデルである。第1段階が鍵交換段階である。第2段階が取引段階である。鍵交換段階において、会員はサービスプロバイダと鍵を交換する。会員は自分の鍵をサービスプロバイダに送り、サービスプロバイダは、その鍵を使ってセッション鍵を会員に送る。セッション鍵は、その先のカード保有者とSPの間またはカード保有者相互間のメッセージ交換を保護する働きをする。取引段階では、SPが取引を指導するか、カード保有者が自ら取引を行うか、どちらかができる。
図1は、本発明の実施例による、カード保有者、マーチャントおよびサービスプロバイダを含むシステムのコンポーネント相互間の関係を示すブロック図である。
ECカード保有者20は、ネットワーク50を介して取引を行い、発信コンピュータ84に取り付けられたEC読み書きデバイス82か、発信コンピュータユニット90の上を走るEC等価ソフトウェア92かどちらかを使用することによってマーチャントと通信することができる。
マーチャントは、インターネットなどのネットワーク50を介して、ネットワーク・レディ・ポイントオブセールス（POS）端末40か、マーチャントデバイス70の上を走るEC等価ソフトウェア92かどちらかを使用することによって、選択されたサービスプロバイダ60と電子取引を行うことができる。
カードへのアクセス条件が満たされたならば、カード保有者は、ネットワーク50を介してシステムの他の関係者と金融機関または非金融機関を行うことができる。図1には、ネットワークを介して取引を行うことのできる三通りのシナリオが示してある。
（1）POS取引（図1の左上側）において、カード保有者20は、ECをマーチャント店内でマーチャントのEC読み書き装置30に通す／差し込む。EC読み書き装置30は、ネットワーク・レディ・マーチャントPOS端末40に接続してある。ネットワーク・レディ・マーチャントPOS端末40は、キーボードなどの入力装置、ディスプレイ装置、処理装置およびEC読み書き装置30（ECインタフェースデバイス）からなる安全な、不正使用のできないプログラマブルデバイスである。その代表的なのが、オープン・ネットワークへの通信リンクを備えたPCなどの小型コンピュータユニットである。POS端末は、ネットワーク50経由でSPと通信する。
（2）（図1の右側）カード保有者は、発信コンピュータであるカード保有者のパーソナルコンピュータ84に接続された読み書き装置82にEC20を差し込むことによってシステムの他の関係者と取引を行うことができる。発信コンピュータは、ネットワーク50につながって、ECをマーチャント・コンピュータユニット70と通信できるようにする。マーチャント・コンピュータユニット70は、マーチャントがECの発信したメッセージを受け取り、EC情報とマーチャント情報を組み合わせるメッセージを発信できるようにするEC等価ソフトウェア72を有する。
（3）（図1の下側）カード保有者は、自分のコンピュータユニット90においてEC等価ソフトウェア92を使用することによってシステムの他の関係者と取引を行うことができる。取引は、発信コンピュータユニット90、すなわちカード保有者のパーソナルコンピュータのところで始まる。カード保有者は、ネットワーク50を介して取引を行い、マーチャント・コンピュータユニット70と通信し、マーチャント・コンピュータユニット70の方は、ネットワーク50を介してSP60と通信する。
本発明の優先実施例では、EC等価ソフトウェアを保持するのにパーソナルコンピュータを使用しているが、本発明の別の実施例では、EC等価ソフトウェアを保持するのに別の電子装置を使用することができる。
本発明の優先実施例では、ECをマーチャントと通信できるようにするのに使用されたネットワークは、マーチャントをSPと通信できるようにするのに使用されたのと同じネットワークである。別の実施例では、ECをマーチャントと通信できるようにするのに使用されたネットワークは、マーチャントをSPと通信できるようにするのに使用されたのと同じネットワークであってはならない。さらに別の実施例では、あるマーチャントをSPと通信できるようにするのに使用されたネットワークは、別のマーチャントをSPと通信できるようにするのに使用されたネットワークと同じであってはならない。さらにまた別の実施例では、あるECをマーチャントと通信できるようにするのに使用されたネットワークは、別のECを別のマーチャントと通信できるようにするのに使用されたネットワークと同じであってはならない。一実施例として、ネットワークが多重構造をなし、それで関係者が相異なる経路で通信できるようになっていてよい。
本発明の優先実施例では、取引が2つの段階に分割してある。鍵交換段階と取引段階である。図2は特殊なケースで、SPが取引段階を指導する2段階式の鍵交換取引のモデルを示す。SPが取引段階を指導する時、関係者間で感知可能な情報の直接交換は行われない。
鍵交換段階は、取引段階がカード保有者同士の間で行われる場合も、SPが取引段階を指導する場合も、同じである。取引段階がカード保有者同士の間で行われる場合、カード保有者は、SPセッション鍵を使って互いに通信し、取引を行う。
図2は、SPが取引段階を指導する場合の金融取引を示す。ここに示す取引には三者が関わる。EC（取引発信者）102、マーチャント104、そして、サービスプロバイダ（SP）106である。発信者は、消費者であるECカード保有者で、コンピュータユニット102によって表される。コンピュータユニット104はマーチャントを表す。コンピュータユニット106はサービスプロバイダを表す。SPは、ECとマーチャントの両方によって選択される。
図2は、プロセスフローがECからマーチャント、SPに向かう金融取引を示す。暗号法のプロセスフローは、マーチャントとECカード保有者の間のどんな特別な順序にも制限されない。図2は、プロセスがECからマーチャント、サービスプロバイダに向かう特別な取引の単なる一例にすぎない。プロセスはまた、マーチャントからEC、サービスプロバイダに向かうこともあり得る。図2は、サービスプロバイダの会員（この場合にはECカード保有者とマーチャント）がどのようにメッセージを作成し、添付し、サービスプロバイダに送るかを示す。
図2において番号1〜10を付けた10の矢印は、メッセージが2つの取引段階の間に三者の間をどのように流れるかを示す。ステップ1〜4は鍵交換段階に属し、ステップ5〜10は取引段階に属する。図2において、マーチャントは、ECとSPの間の仲介役として働く。ステップ1において、鍵交換リクエストは、ECによってフォーマットされ、マーチャントに送られる。ステップ2において、マーチャントは、自身の鍵交換メッセージをECの鍵交換メッセージと組み合わせ、この組み合わせた鍵交換メッセージをSPに送る。ステップ3において、SPは、マーチャントのための鍵交換応答をフォーマットし、ECのための鍵交換応答をフォーマットし、両方の鍵交換応答を組み合わせて1つの複合的な鍵交換応答を形成し、この組み合わせた鍵交換応答をマーチャントに送る。ステップ4において、マーチャントは、マーチャントのための鍵交換応答をECのための鍵交換応答から切り離し、ECの鍵交換応答メッセージをECに転送する。ステップ4が、鍵交換段階における主要活動を締めくくる。
取引段階はステップ5で始まる。ステップ5において、ECは、その取引リクエストメッセージをフォーマットし、これをマーチャントに送る。ステップ6において、マーチャントは、受け取った取引リクエストメッセージを自身の取引リクエストメッセージと組み合わせ、この組み合わせた取引リクエストメッセージをSPに送る。ステップ7において、SPは、マーチャントのための取引応答メッセージをフォーマットし、ECのための取引応答メッセージをフォーマットし、両方の取引応答メッセージを組み合わせ、この組み合わせた取引応答メッセージをマーチャントに送り返す。ステップ8において、マーチャントは、マーチャントのための取引応答メッセージをECのための取引応答メッセージから切り離し、ECの取引応答メッセージをECに転送する。ステップ9において、ECは確認メッセージをフォーマットし、これをマーチャントに送る。ステップ10において、マーチャントは、受け取った確認メッセージを自身の確認メッセージと組み合わせ、この組み合わせた確認メッセージをSPに送る。ステップ10が、1つの取引の取引段階を締めくくる。
図2が示すのは単純な取引であるが、取引によっては多重メッセージを伴うものがいくつかある。取引の間、各段階を完成させるのに2つ以上のメッセージが要求されるケースもあり、その場合、かかるメッセージは同じルールに従って組み合わされ、送られることになる。例えば取引段階の間、ECとマーチャントが先ず最初に取引勘定情報を送ることをSPは要求してよい。取引勘定情報が有効であることが照合確認されると、SPは、取引勘定情報確認の旨を応答メッセージにして送る。マーチャントとECは、この応答メッセージを受け取ると、取引額およびその他の取引関連情報を、SPに行く次のメッセージにして送る。SPは、そこで当該の取引を許可し、または不許可とする。図2に示すステップは、取引勘定メッセージと取引メッセージの両方に当てはまる。
取引の完成が何らかの外部システム、例えば公開鍵／ディジタル証明書ベースのシステム108などとのインタラクションを要求する場合、SPは、ECとマーチャントのための代理証明者として働き、ECとマーチャントの代理として外部システムと対話することになる。本発明の望む結果は、取引の関係者のすべてを外部システムから遮蔽し、それで、取引を完成させるのに必要な信託関係の数を減らすことである。取引の関係者が本システムと外部システムの両方の会員である場合、彼は、本システムの会員として働くか、外部システムの会員として働くか、選択することができる。後者の場合、SPは、外部システムのルールに従って関係者とのインタフェースを作ることになる。例えば、公開鍵／ディジタル証明書または信用状をベースとした外部システムと対話するために、SPは、外部システムから要求される信託関係を満足させる証明書または信用状のすべてを持っている。このような信用状がSPおよび外部システムにとって必要となるのは、ECおよびマーチャントによって始められた取引を完成させるためである。この場合、SPが外部システムと信託関係を持つだけで足りる。この信託関係に基づいて、個々のECとマーチャントは、仮の外部システムとの取引を完成させることができる。
図3は、ECの優先実施例の図表的表現である。本発明の優先実施例では、EC内部が、図3に示すソフトウェア／ハードウェアコンポーネントから構成されている。このECは、ISO 7816をベースとしており、ISO 7816に定めるのと同じ種類の通信プロトコルおよび通信コマンドをサポートする。
ECは、ECの内部リソースを管理するカード・オペレーティングシステム550を有する。オンカード暗号サービス650は、ソフトウェアで実現させることも、暗号コプロセッサ（図3には示していない）、他のハードウェア解決、またはソフトウェアとハードウェアのハイブリッドによって提供することもできる。
ECの特異な特徴のひとつがECメモリ内部のサービスプロバイダ・データ領域（SPDA）で、これは、サービスプロバイダの取引勘定情報と鍵情報を包含する。サービスプロバイダ・データ領域（SPDA）700は、多数のスロットを包含する。優先実施例において、SPDAは、所定の個数（例えば10個）のスロットを包含する。各サービスプロバイダの記録を空のスロットに入れることができる。各記録は、特定のサービスプロバイダに関する取引勘定番号、公開鍵、およびその他の関連情報を包含する。
ECの設計次第で、SPDAは、任意に各SPに、それ独自のオンカードデータを管理し、SPカードデータとホストアプリケーションの間のインタフェースを提供する何らかのソフトウェア（JAVAの"アプレット"のような）を含ませることができる。換言すれば、SPDAは、まさしく単純なデータより多くのものを包含することができ、各SPに、それ独自のユニークなサービスをカード保有者に提供する独立言語型アプリケーションソフトウェア（アプレットのような）をEC上に置かせることができる。この種の設計の利点は、EC自体が、提供することのできる種類のサービスから今やはずされることである。別のSPがオンカードSPに取って代わるならば、ECプラットフォームに変更を加える必要は無くなろう。新しいSPアプレットは、カードに単純にロードされ、そうするように設計されたことを実行することになろう。
SPDAにおいて、各サービスプロバイダは、公開鍵のためのスペースは割り当てられている。多くの取引において鍵は1対しか使用されないが、いくつかのオンライン取引には2対以上の鍵が必要とされる。SPが、入力メッセージと出力メッセージの両方の署名に同じ対の公開／専有鍵を使用する場合には、1個の公開鍵で足りる。SPが両メッセージの署名に異なる対の鍵を使用する場合には、両方のSP公開鍵（入力メッセージのために１個、出力メッセージのために1個）がSPDAにおいて必要とされる。
本発明の優先実施例では、1対の公開／専有鍵よりむしろ2対の公開／専有鍵が、ネットワーク経由の他のアプリケーションとの通信に使用される。それは、1対の公開／専有鍵よりむしろ2対の公開／専有鍵の方が大きいセキュリティをもたらすからである。一方の対が入力メッセージの解読に使用される。すなわち、送り手が受け手の公開鍵を使ってメッセージを暗号化し、受け手が相応の専有鍵を使ってそのメッセージを解読する。他方の対は、送り手が自身の送るメッセージにディジタル署名し、受け手が相応の送り手の公開鍵を使ってディジタル署名を照合確認するのに使用される。
各サービスプロバイダは、サービスプロバイダによって使用される公開鍵の数に対してスペースが割り当てられる。SPが、入力メッセージと出力メッセージの両方の署名に同じ対の公開／専有鍵を使用する場合には、1個の公開鍵で足りる。SPが両メッセージの受け取りと署名に異なる対の鍵を使用する場合には、両方のSP公開鍵がSPDAにおいて必要とされる。
本発明の別の実施例では、2対以上の公開／専有鍵が、大きいセキュリティを得るためにサービスプロバイダによって要求、使用される。
ECカードが新しい金融機関または非金融機関から発行される時、発行機関または信託された第三者は、記録からなる必要な情報を使用可能なスロットにロードすることになる。スロットの中の情報は、サービスプロバイダの取引勘定が閉じられる時に消去することができる。スロットの中の情報のいくつか、例えば取引勘定残高は、取引の間に読み出し、修正することができる。取引勘定番号などいくつかの情報は、書き込み禁止となっているが、読み出すことはできる。専有鍵などいくつかの情報は、読み出し書き込み両方とも禁止となっている。アクセス条件600は、ECユーザーがカードを使用にあたってオープンにするために、またはカードに保存された情報にアクセスするために提示しなければならないPIN、バイオメトリックデータなどのセキュリティ情報を包含する。
伝統的な個人識別番号（PIN）またはバイオメトリックデータなど他のセキュリティ情報が、ECを保護するのに使用される。バイオメトリックデータには、カード保有者の生物学的特徴、身体的特徴、行動的特徴などが含まれる。バイオメトリックシステムで測定できるのは、個々人の指紋、手の大きさ、手書き文字、顔面の外見、話し方、身体動作、キーボードのタイピングのリズム、眼の特徴、息づかい、体臭、DNA、または他の身体的属性などである。ECによってもたらされ機能は、アクセス条件が満たされた後でしか活動化できない。カード上に存する各サービスプロバイダは、任意に他のアクセス条件を実現させることができる。
図4は、本発明の優先実施例のサービスプロバイダ・データ領域のフォーマットを示す。サービスプロバイダ情報の各々にエントリが割り当てられており、それぞれ、追加のアクセス条件によって保護することができる。PIN 712および雑データフィールド714は、サービスプロバイダが、そのサポートする機関に特別な保護を付ける時に役立つ。ネームフィールド702は、サービスプロバイダの名前を入れるところで、これをカード保有者は、オンライン取引の始めに、その取引に適用できるサービスプロバイダを最初に選択するのに使用することができる。鍵種類フィールド704は、秘密鍵、公開鍵などを使用する時にサービスプロバイダが選択する鍵の種類を指定する。鍵値フィールド706および取引勘定情報フィールド708は、各サービスプロバイダに特異な情報を入れる。カード種類フィールド710は、サービスプロバイダがサポートする機関の種類を指定する。
本発明の優先実施例では、オンカード・オペレーティングシステム（COS）は、カード保有者のためにいくつかの基本的サービスを提供する。以下は、COSによって実行することのできる一般機能のリストである。
（1）メモリ管理、タスク管理など伝統的なOS機能
（2）ユーザーデータの外部通信／読み書き機能および通信プロトコルハンドリング
（3）オンカードのカード保有者情報のローディングおよび更新
（4）ユーザーPIN変更
（5）サービスプロバイダ・データ領域の管理 − 個々のサービスプロバイダ情報のローディングおよび更新、SPDAアクセス制御など。
COSはまた、取引のさまざまなステップの間にサポートを提供することになる。例えば、COSは取引の始めにSP選択を処理し、取引が完成した時に取引データをログファイルに記録する。本発明の一実施例では、下記のCOSへの2つの設計アプローチの一方または2つの設計アプローチのハイブリッドを実現させてよい。
（1）知能のほとんどをCOSの中に入れ、それで、COSがEC機能のほとんどをサポートできるようにする。その結果、オンカード・サービスプロバイダの各領域がCOSの上にでき、マーチャントおよびSPとの取引を実行するようになる。このアプローチでは、COSは、すべてのオンカードSPについて外側世界との均一なインタフェースをもたらし、SPが選択され次第、取引を効率よく実行することができる。
（2）あるいは、COSは、各オンカードSPが利用できる一般サービスのプールであり得る。各SPデータ領域に、マーチャントおよびSPとの取引を実行する知能を有するアプレットを入れることができる。このアプローチの方が、SPは、取引を行う時に自身の特異な特徴を実現させる機会を多く有する。
図5は、本発明の優先実施例においてディジタル署名がどのように使用されるかを示す。先ず、メッセージの送り手がメッセージM900のデータ部分を準備し、一方向ハッシュ・アルゴリズム、H(*)902を経由して送る。ハッシュ・アルゴリズムからの出力は、メッセージM903のメッセージダイジェストMDと呼ばれる。MDは次に暗号化され、E(*)904となる。すなわち、送り手の公開鍵（Pri）を使ってディジタル署名される。その結果は、メッセージMのディジタル署名DSと呼ばれる。DSは、次にオリジナルメッセージM900と組み合わされ、ネットワーク50を経由して受け手に伝送できる状態の完全なメッセージ906を形成する。
公開鍵暗号化／解読機能は、多数の暗号化／解読機能のどれかであり得る。RSAというのは、RSAの開発者の姓（Ronald Rivest、Adi Shamir、Len Adelman）の頭文字から取った名であるが、これこそ、本発明の実施例において使用できる公開鍵暗号化／解読機能の一例である。
受け手と目された者がネットワーク50からメッセージを受け取ると、彼は先ず、メッセージM900のデータ部分を、これと組み合わされたディジタル署名912から切り離す。受け手は次に、メッセージM900のデータ部分を、このメッセージM900のデータ部分の暗号化に使用された同じハッシュ・アルゴリズム910の中に通し、MのメッセージダイジェストMD^911を得る。受け手は次に、ECの公開鍵を使ってD(*)908を解読し、オリジナルメッセージに含まれたディジタル署名912を、送り手の公開鍵を使って解読し、オリジナルメッセージダイジェスト（ここではMD909で示してある）を回収する。MD909は、修正のために新たに計算されたMD^911と比較される。両方が一致しない場合、オリジナルメッセージは、改変されたものとみなされ、はねられる。
以下は、図5〜27において使用された記号および略号のリストである。
Acknowledgement DataEC＝ECによってSPに送り返されたメッセージの一部。これはSPに、先のメッセージが首尾良く受け取られ、処理されたことを知らせるものである。
Acknowledgement DataM＝マーチャントによってSPに送り返されたメッセージの一部。これはSPに、先のメッセージが首尾良く受け取られ、処理されたことを知らせるものである。
AIEC＝EC保有者の取引勘定情報。
AIM＝マーチャントの取引勘定情報。
CRYPTO＝暗号文。
D＝解読機能。
DSP-Private-Key＝SP専有鍵を使った解読。
DS＝ディジタル署名機能。
DSEC-Private-Key＝メッセージ上のECによるディジタル署名。
DSM-Private-Key＝メッセージ上のマーチャントによるディジタル署名。
DSSP-Private-Key＝メッセージ上のSPによるディジタル署名。
E＝暗号化機能。
E(Data)＝データ暗号鍵によるデータの暗号化。
ESP-PK，ESP-Public-Key＝SP公開鍵によって暗号化されたデータ。
ESkey-EC，DSkey-EC＝SPがECのために作成したセッション鍵を使った暗号化／解読。
ESkey-M，DSkey-M＝SPがマーチャントのために作成したセッション鍵を使った暗号化／解読。
EC＝電子カード、または電子カードと等価のソフトウェア。
H(M)＝一方向ハッシュ・アルゴリズムをMに適用する。これで、Mのメッセージダイジェスト(MD)が作成される。
KE＝鍵交換段階。
M＝マーチャント。
MD＝メッセージダイジェスト。
MD^＝メッセージの受け手が、入力データとして受け取ったばかりのメッセージを使って作成したメッセージダイジェスト。
MDEC＝ECからSPに向かうメッセージのメッセージダイジェスト。
MDM＝マーチャントからSPに向かうメッセージのメッセージダイジェスト。
MDSP-M＝SPからマーチャントに向かうメッセージのメッセージダイジェスト。
MDSP-EC＝SPからマーチャントを通ってECに向かうメッセージのメッセージダイジェスト。
PLAIN TEXT＝暗号化なしで伝送できる取引データ。平文は、メッセージごと、取引当事者ごとに異なることがあり得る。
PLAIN TEXTEC＝ECが自らの出力メッセージの中に設けた取引データ部分。平文データフィールドは、セキュリティ感知可能でない。それゆえ、これは暗号化なしで伝送される。
この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
PLAIN TEXTM＝マーチャントが自らの出力メッセージの中に設けた取引データ部分。平文データフィールドは、セキュリティ感知可能でない。それゆえ、これは暗号化なしで伝送される。この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
PLAIN TEXTSP-EC＝SPがECのために自らの出力メッセージの中だけに設けた取引データ部分。平文データフィールドは、セキュリティ感知可能でない。それゆえ、これは暗号化なしで伝送される。この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
PLAIN TEXTSP-M＝SPがマーチャントのために自らの出力メッセージの中だけに設けた取引データ部分。平文データフィールドは、セキュリティ感知可能でない。それゆえ、これは暗号化なしで伝送される。この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
STD＝データ伝送中の暗号化を要求する感知可能な取引データ。
STDEC＝ECが自らの出力メッセージの中に設けた感知可能な取引ディジタルデータ。この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
STDM＝マーチャントが自らの出力メッセージの中に設けた感知可能な取引ディジタルデータ。この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得る。
PK＝公開鍵。
EC-PK，PKEC＝電子カードの公開鍵。
M-PK，PKM＝マーチャントの公開鍵。
SP-PK，PKSP＝選択されたサービスプロバイダの公開鍵。
Response DataSP-EC＝一取引の取引段階の間にSPによってECに送り返されたメッセージ部分。これは、許可／不許可データおよび／または他の何らかの関連データを含むことがあり得る。
Response DataSP-M＝一取引の取引段階の間にSPによってマーチャントに送り返されたメッセージ部分。これは、許可／不許可データおよび／または他の何らかの関連データを含むことがあり得る。
RN＝乱数。
RNEC＝ECによって作成された、SPに送られる乱数。
RNSP-EC＝SPによって作成された、ECに送られる乱数。
RNM＝マーチャントによって作成された乱数。
RNSP-M＝SPによって作成された、Mに送られる乱数。
SP＝金融組織または非金融組織のサービスプロバイダ。
TA＝取引（通過）勘定。
Transaction Identification NumberSP-EC，TIDSP-EC(Transaction IDSP-EC)＝一取引の鍵交換段階の間にSPによって値が割り当てられるデータフィールド。ECは、この値を使って、同じ取引の間にSPと通信することになる。
Transaction Identification NumberSP-M，TIDSP-M(Transaction IDSP-M)＝一取引の鍵交換段階の間にSPによって値が割り当てられるデータフィールド。ECは、この値を使って、同じ取引の間にSPと通信することになる。
*＝暗号化Eまたは解読Dの範囲内のデータの組み合わせまたは連鎖。
図6〜22は、本発明の優先実施例による暗号システムと暗号法のフローチャートを示す。図6〜22において使用される記号および説明を簡素化する目的のため、フローチャートでは、取引に関わる関係者の各々が1対の鍵を使用すると仮定する。本発明の別の実施例では、2対の公開鍵を使用してよく、その場合には、両方の公開鍵を交換する必要がある。
本発明の優先実施例は、2つの別個の段階からなる。鍵交換段階と取引段階である。
段階Ｉ：鍵交換段階（ハンドシェイク段階）
ECカード保有者は、ECをカード読み書きデバイスに差し込むか、EC等価ソフトウェアを起動させるかし、PIN番号を入力し、および／またはECカード使用のためのアクセス条件 110 を満足させる。入力されたセキュリティ情報は、オンカード情報 114 と比較され 112、そこで、ユーザーにEC使用の許可を与えることが照合確認される。セキュリティ情報がカードセキュリティ情報と一致しない場合、カード使用のリクエストははねられる 116。一致する場合、カードはロック解除され 118、使用できることになる。カードがロック解除されたら、ユーザーは、サービスプロバイダ選択のためにオンカードSPのリストをリクエストし、SP選択コマンドをECに向けて発することによって選択 120 を行うことができる。SPが選択されると、ECは、SPと鍵交換（KE）を始める。選択されたSPの公開鍵（記号 SP-PK および PKSP によって表された）は、ECのSPDAから得られ、SPに送られることになるメッセージの暗号化に使用される。
KEの主な目的は、カード保有者の公開鍵 PKEC 126 およびEC乱数 RNEC 124 をSPに確実に送ることである。ECに対するSPの応答は、セッション鍵および取引IDをECに割り当てることで、ECはこれを使って、取引の残りについてSPと通信することになる。KEメッセージをフォーマットするため、ECは乱数 RNEC 124 を作成し、これをEC公開鍵 PKEC 126 および取引関連の感知可能な取引データ STDEC 128 および／またはSPによってリクエストされた取引データとつなぎ合わせる。ECは、これらのデータ 122 を、SPDA 120から回収されたSP公開鍵 PKSP を使って暗号化する。こうして出来上がったEC暗号文 EES-PK(RNEC*PKEC*STDEC) は、次にメッセージの平文部分 PLAIN TEXTEC 132 と組み合わされ、EC複合メッセージPLAIN TEXTEC*ESP-PK(RNEC*PKEC*STDEC) を形成する。ECの公開鍵 PKEC 126 は、EC複合メッセージを形成する時に暗号化される代わりに平文 PLAIN TEXTEC の中に置かれてよい。
感知可能なデータだけが暗号化される。感知可能でない応答データは、平文の中に含まれる。SPだけが、感知可能なデータを読み出すことができる。関係者多数の取引では、SPは、すべての関係者の感知可能な情報にフルにアクセスすることができる。
出来上がったEC複合メッセージは、ハッシュ・アルゴリズム 134 を通して送られ、そこでハッシュ・メッセージを形成する。これがECメッセージダイジェスト MDEC である。ECメッセージダイジェスト MDEC には、EC 136 がEC専有鍵 138 を使ってディジタル署名する。これにより、ディジタル署名されたメッセージDSEC-Private-Key が形成される。ディジタル署名されたメッセージ DSEC-Private-Key は、次にEC複合メッセージと組み合わされる 140 。平文 PLAIN TEXTECと暗号文 CRYPTOEC とディジタル署名 DSEC-Private-Keyとの組み合わせは、ECからのKEメッセージであり、ネットワークを通してマーチャント 158 に送られる。平文は、性質的に感知可能でない取引データフィールドをすべて含んでおり、それゆえ、明瞭な見分けられる形で伝送することができる。従って、暗号化する必要がない。これらのデータフィールドは、メッセージごとに異なり、取引関係者によって限定される。
SPと通信するため、マーチャントは、本質的にECが自身のKEメッセージを形成する時に踏むのと同じステップを踏んで自身のKEメッセージを形成する。カード保有者とマーチャントは、個別にSPと通信しないが、組み合わされたメッセージを通して通信する。その結果、カード保有者とマーチャントの間で何らかの機密金融情報を交換する必要は無くなる。マーチャントは、取引 142 のために自身のデバイスを準備し、専有のデバイスの中にある自身のSPDAから、ECカード保有者が取引 144 のために選択したのと同じSPを選択する。SPの公開鍵（記号 SP-PK および PKSP によって表された）は、SPのSPDAから得られ、SPに送られることになるメッセージの暗号化に使用される。
自身のKEメッセージをフォーマットするため、マーチャントは乱数 RNM 148 を作成し、これをマーチャント公開鍵 PKM 150 およびマーチャントの感知可能な取引データ STDM とつなぎ合わせる。感知可能な取引データとは、取引に関連するデータおよび／またはSP 152 によってリクエストされたデータのことである。マーチャントは、組み合わされたデータを、サービスプロバイダの公開鍵 PKSP を使って暗号化する 146 。こうして出来上がった暗号文は、次に平文部分 PLAIN TEXTM 156 と組み合わされ 154 、マーチャント複合メッセージを形成する。マーチャントの公開鍵 PKM 150 は、マーチャント複合メッセージPLAIN TEXTM*ESP-PK(RNM*PKM*STDM)を形成する時に暗号化される代わりに平文 PLAIN TEXTM の中に置かれてよい。
マーチャント複合メッセージ [PLAIN TEXTM*ESP-PK(RNM*PKM*STDM)] は、さらにECのKEメッセージ [[PLAIN TEXTEC*ESP-PK(RNEC*PKEC*STDEC)]*DSEC-Private-Key] と組み合わされ、そこで、マーチャントとECの両方のためのKEメッセージのデータ部分を形成する。すなわち、EC／マーチャント複合メッセージ[[PLAIN TEXTEC*ESP-PK(RNEC*PKEC*STDEC)]*DSEC-Private-Key]*[PLAIN TEXTM*ESP-PK(RNM*PKM*STDM)] である。このEC／マーチャント複合メッセージは、ハッシュ・アルゴリズム 160 を通して送られ、そこでハッシュ・メッセージを形成する。これがマーチャントメッセージダイジェスト MDM である。マーチャントメッセージダイジェスト MDM には、マーチャントがマーチャント専有鍵 164 を使ってディジタル署名する 162 。これにより、ディジタル署名されたマーチャントメッセージ DSM-Private-Key が形成される。ディジタル署名されたマーチャントメッセージ DSM-Private-Key は、次にメッセージ、すなわちEC／マーチャント複合メッセージのデータ部分と組み合わされ 166 、そこで、マーチャントとEC両方のための鍵交換リクエストメッセージ<<[[PLAIN TEXTEC*ESP-PK(RNEC*PKEC*STDEC)]*DSEC-Private-Key]*[PLAIN TEXTM*ESP-PK(RNM*PKM*STDM)]>>*DSM-Private-Key を形成する。この最終メッセージが、ネットワークを通してSPに送られる。図23は、マーチャントからSPに送られる鍵交換リクエストメッセージの最終のフォーマットと内容を示す。
本発明の優先実施例では、ECが自身の公開鍵を暗号化するので、マーチャントは、ECのリクエストメッセージMDECのMDをチェックしない。それでも、本発明の別の実施例では、ECが自身の公開鍵を暗号化しない場合、マーチャントは任意にECのMDを、SPに行き着く前にチェックすることができる。ECが自身の公開鍵を暗号化する場合でも、ECが自身の公開鍵を暗号化しない場合でも、セキュリティを高め、マーチャントによる処理ミスを避けるためであれば、SPはなおECのMDをチェックすることができる。マーチャントは、自身とECの両方のためにSPから複合応答を受け取る時、ECのためにMDをチェックするには及ばない。なぜなら、そのMDが、単独に発信者であるSPによって形成された全体メッセージの一部だからである。マーチャントは、自身がSPから受け取る全体メッセージのMDをチェックしさえすればよい。
SPは、KEリクエストメッセージを受け取ると、先ずKEリクエストメッセージのデータ部分をDSから切り離し、KEリクエストメッセージのデータ部分を一方向ハッシュ・アルゴリズムに送り込み、そこでメッセージダイジェストを再計算する。これが MDM となる。SPは次に、マーチャントの平文 PLAIN TEXTM 、暗号文 CRYPTOM 、ディジタル署名 DSM-Private-Key およびECのKEリクエストメッセージPLAIN TEXTEC*CRYPTOEC*DSEC-Private-Key を切り離す。自身の専有鍵を使って、SPは、マーチャント暗号文 170 を解読し、他の情報の中から、マーチャント乱数 RNM 148 とマーチャント公開鍵 PKM 150 を回収する。SPは次に、回収されたPKM 150 を使ってマーチャントのディジタル署名 DSM-Private-Key を解読し、マーチャントのKEメッセージについて MDM を回収する。SPは、新たに集められた MD^M 168 を、オリジナルKEメッセージからのDSの解読によって回収されたMDM 170 と比較する 172 。MD^M とMDM の間に不一致が見つかった場合、KEメッセージは、改変されたものとみなされ、はねられる 174 。
MD^M とMDM が一致すれば、SPは、ECのKEリクエストメッセージのデータ部分をDSから切り離し、KEリクエストメッセージのデータ部分を一方向ハッシュ・アルゴリズムに送り込み、そこでメッセージダイジェスト(MD^EC)を再計算する。SPは次に、ECのKEリクエストメッセージ 176の中の平文 PLAIN TEXTEC 、暗号文 CRYPTOEC およびディジタル署名 DSEC-Private-Key を切り離す。自身の専有鍵を使って、SPは、EC暗号文を解読し、他の情報の中から、EC乱数 RNEC とEC公開鍵 PKEC を回収する。SPは次に、回収されたPKEC を使ってECのディジタル署名 DSEC-Private-Key を解読し、ECのKEメッセージについて MDEC を回収する。ステップ178において、SPは、新たに集められた MD^EC 176 を、オリジナルKEメッセージからのDSの解読によって回収されたMDEC と比較する。何らかの不一致が見つかった場合、KEメッセージは、改変されたものとみなされ、はねられる 180。一致する場合、SPはすぐにでも、KE応答メッセージをマーチャントとECに送り返すことができる。
ECのためのKE応答メッセージをフォーマットするため、SPは、乱数 RNSP-EC 184 およびECのためのセッション鍵SkeyEC 186 を作成し、これらをECの乱数 RNEC 188、サービスプロバイダの感知可能な取引データ STDSP-EC 190 と組み合わせ、これらのデータ 192 を、ECの公開鍵 PKEC を使って暗号化する。こうして出来上がった暗号文 EEC-PK(RNEC* RNSP-EC*SkeyEC*STDSP-EC) は、次に、SPによってECに割り当てられた取引識別番号 TIDSP-EC 194 および平文 PLAIN TEXT SP-EC 195 と組み合わされ、そこでECのための応答メッセージのデータ部分を形成する。SPは、このデータをハッシュ・アルゴリズムに通し、そこでメッセージダイジェスト MDSP-EC 198 を計算する。自身の専有鍵 202 を使って、SPは、メッセージダイジェスト MDSP-EC のディジタル署名によって応答メッセージのためのディジタル署名 DSSP-Private-Key 200 を作成する。メッセージのデータ部分を新たに計算されたディジタル署名 DSSP-Private-Key と組み合わせた後 204、ECのためのSPのKE応答メッセージは完成する。すなわち、[TIDSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDEC)]*DSSP-Private-Key である。
マーチャントのためのKE応答メッセージをフォーマットするため、SPは、乱数RNSP-M 208 およびマーチャントのためのセッション鍵SkeyM 210 を作成し、これらをマーチャントの乱数 RNM 212、感知可能な取引データ STDSP-EC214 と組み合わせ、これらのデータ 206 を、170において回収されたマーチャントの公開鍵 PKM を使って暗号化する。こうして出来上がった暗号文は、次に、SPによってマーチャントに割り当てられた取引識別番号 TIDSP-M 218 および平文 PLAIN TEXT SP-M 220 と組み合わされ、そこでマーチャントのための応答メッセージのデータ部分を形成する。出来上がった複合メッセージ TIDSP-M*PLAIN TEXTSP-M*EM-PK(RNSP-M*RNM*SkeyM*STDSP-M) は、さらにECのためのKE応答メッセージ [TIDSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDEC)]*DSSP-Private-Keyと組み合わされ 222 、そこで、SPの最終のKE応答メッセージのデータ部分 [TIDSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDEC)]*DSEC-Private-Key]*[TIDSP-M*PLAIN TEXTSP-M*EM-PK(RNSP-M*RNM*SkeyM*STDSP-M)]を形成する。
SPはこのデータ部分をハッシュ・アルゴリズムに通し、そこでメッセージダイジェスト 224 を計算する。自身の専有鍵 228 を使って、SPは、メッセージダイジェストのディジタル署名によって応答メッセージのためのディジタル署名 DSSP-Private-Key 226 を作成する。メッセージのデータ部分を新たに計算された DS 226 と組み合わせた後 230 、ECとマーチャント両方のためのKE応答メッセージは完成する。この応答メッセージ <<[[TIDSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDSP-EC)]*DSSP-Private-Key]*[TIDSP-M*PLAIN TEXTSP-M*EM-PK(RNSP-M*RNM*SkeyM*STDSP-M)]>>DSSP-Private-Key は、ネットワークを通してマーチャントに送り返される。図24は、SPからマーチャントに送り返される複合KE応答メッセージの最終のフォーマットと内容を示す。
マーチャントは、KE応答メッセージを受け取ると、先ず、SPのディジタル署名DSSP-Private-Key を切り離し、次に、複合KE応答メッセージのデータ部分を一方向ハッシュ・アルゴリズムに送り込み、そこでメッセージダイジェストMD^ SP-Mを再計算する。マーチャントは次に、SPのKE応答メッセージのデータ部分、すなわち TIDSP-M 、PLAIN TEXTSP-M 、CRYPTOSP-M 、[(TIDSP-EC*PLAIN TEXTSP-EC*CRYPTO SP-EC)]*DSSP-Private-Key を切り離す。マーチャントは、SPの公開鍵（144から選択された）を使ってディジタル署名 DSSP-Private-Keyを解読し、メッセージダイジェストMDSP-M を回収する。マーチャントは、新たに集められた MD^SP-M をMDECと比較する 234 。MD^ SP-M とMDSP-M の間に何らかの不一致があった場合、KE応答メッセージは、改変されたものとみなされ、はねられる 236。
MD^ SP-M とMDSP-M が一致すれば、マーチャントは、自身に宛てられた応答メッセージ部分を識別し、自身の専有鍵を使って暗号文 CRYPTOSP-M 238 を解読する。これで、マーチャントは、自分がEC応答メッセージの中でSPに送ったオリジナル乱数RNM（148の）を回収できるはずである。マーチャントは、回収された乱数RNM（ステップ238の）をオリジナル乱数RNMと比較する。両方が等しくなければ、メッセージは改変されたものとみなされ、はねられる 242 。乱数RNMは、SPが正しいSP専有鍵を使ってしない限り回収できないのだから、選択されたSPが本当にメッセージの送り手であることは確実である。マーチャントは、そこでECのKE応答メッセージ [(TIDSP-EC*PLAIN TEXTSP-EC*CRYPTOSP-EC)]*DSSP-Private-Key をECに送り、取引の取引段階の準備をする。
ECは、KE応答メッセージ 260 を受け取ると、先ず、SPのディジタル署名 DSSP-Private-Key を切り離し、次に、ECのためのKE応答メッセージのデータ部分を一方向ハッシュ・アルゴリズムに送り込み、そこでメッセージダイジェストMD^ SP-ECを作る。ECは次に、メッセージのデータ部分、すなわち TIDSP-EC 、PLAIN TEXTSP-EC 、CRYPTOSP-EC 、DSSP-Private-Key を切り離す。ECは、SPの公開鍵（120で選択された）を使ってディジタル署名 DSSP-Private-Key のメッセージを解読し、メッセージダイジェストMDSP-EC を回収する。マECは、新たに集められた MD^SP-EC （260で）を、ECのためのKE応答メッセージからのDSSP-Private-Key の解読によって回収された MDSP-EC と比較する 262 。MD^ SP-ECとMDSP-ECの間に何らかの不一致が見つかった場合、ECのためのKE応答メッセージは、改変されたものとみなされ、はねられる 264 。MD^ SP-MとMDSP-M が一致すれば、ECは、自身に宛てられた応答メッセージ部分を識別し、メッセージに含まれている暗号文 CRYPTOSP-EC を自身の専有鍵を使って解読する 266 。これで、ECは、自分がEC応答メッセージの中で送ったオリジナル乱数RNEC（124の）を回収できるはずである。
ECは、回収された乱数RNEC（266の）をオリジナル乱数RNEC（124の）と比較する。両方の乱数が等しくなければ、メッセージは改変されたものとみなされ、はねられる 270 。SPが正しいSP専有鍵を使ってしない限り、乱数RNECは回収できないのだから、選択されたSPが本当にメッセージの送り手であることは確かである。ECは、取引の取引段階の準備をする。
ここで、ECとマーチャントで設定された所定のタイムアウト期間に入る。取引の間、タイムアウト期間中に応答メッセージを受け取らなかった場合、ECとマーチャントは、取引が打ち切られたものとみなし、回収プロセスを再開するか新たに始めるかすることになる。
KEメッセージ交換が首尾良く完了した後、SPの手元にあるのは、ECの公開鍵とマーチャントの公開鍵である。この時点でECとマーチャント両者の手元にあるのは、乱数、取引ID、そして、SPからのセッション鍵である。ECとマーチャントは、取引の鍵交換段階を完成させるために、KE応答メッセージから回収された2つの乱数をSPに送り返さなければならない。これは二通りの方法でできる。すなわち、乱数は、ECとマーチャントの両方から乱数を確認メッセージの中に入れて送り返すことができる。あるいは、ECとマーチャントからSPに向かう次回メッセージ、例えば取引メッセージなどの一部として送り返すこともできる。二番目の方が簡単である。この方法を以下の段階IIの中で説明する。乱数が使用されるのは1回だけで、SPとマーチャントの間、そしてSPとECの間の鍵交換において正確を期すためである。セッション鍵と取引識別番号がひとたび確立されたなら、乱数はもはや不用となる。
段階II：トランザクション段階
トランザクション段階では、販売業者とＥＣは各々アカウント番号のような固有のアカウント情報と、トランザクション金額、承認または他の処理の要求といった他のトランザクション関連データをＳＰに送信する。ここでも、ＥＣと販売業者はＳＰに個別にではあるが結合されたメッセージを通じて通信し、販売業者はメッセージを結合しそれらを１つのメッセージとしてＳＰに送信する責任を負う。
ＥＣはまず、ＳＰからの乱数ＲＮSP-EC２７４と、選択されたＳＰとのＥＣのアカウント情報、ＡＩEC２７６、及びトランザクション金額ＴＡ２８０及びトランザクションに関連し、かつ／またはＳＰによって要求される何らかの他の機密データ２７８を連結することでトランザクション・メッセージを形成する。ＥＣはＳＰによって割り当てられたセッション鍵ＳｋｅｙECを使用してそれを暗号化２７２する。ＳｋｅｙECは秘密鍵であり、公開鍵暗号化で使用される暗号化アルゴリズムと異なった暗号化アルゴリズムを使用する。結果として得られる暗号ＣＲＹＰＴＯEC、すなわち、ＳｋｅｙEC（ＲＮSP-EC＊ＳＴＤEC＊ＡＩEC＊ＴＡ）は次に、トランザクションＩＤ ＴＩＤSP-EC２８４及び、もしあればプレーンテキストＰＬＡＩＮ ＴＥＸＴEC２８６と結合２８２され、ＥＣのトランザクション・メッセージのデータ部分、ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＣＲＹＰＴＯECを形成する。
データ部分２８２はメッセージ・ダイジェストＭＤECを計算する一方向ハッシュ・アルゴリズム２８８に供給され、ＭＤECは次にＥＣのプライベート鍵２９２によってデジタル署名２９０される。結果として得られるデジタル署名２９０は（２８２からの）メッセージのデータ部分２９４と結合され、ＥＣのトランザクション要求メッセージを形成し、その後販売業者に送信される、［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（ＲＮSP-EC＊ＳＴＤEC＊ＡＩEC＊ＴＡ）］ＤＳEC-Private-Key。
販売業者は本質的に同じステップを経て自らのトランザクション・メッセージを形成する。販売業者は、ＳＰからのＲＮSP-Mと、選択されたＳＰとの販売業者のアカウント情報、ＡＩM２４８、トランザクション金額ＴＡ２５２、及びトランザクションに関連しかつ／またはＳＰによって要求される何らかの他の機密データＳＴＤMを連結２４６することで自らのトランザクション・メッセージを形成する。販売業者はＳＰによって割り当てられたセッション鍵ＳｋｅｙMを使用してそれを暗号化２４４する。セッション鍵ＳｋｅｙMは秘密鍵であり、ＤＥＳのような公開鍵暗号化で使用される暗号化アルゴリズムと異なった暗号化アルゴリズムを使用して生成される。セッション鍵ＳｋｅｙMが使用され、この時点で暗号化が行われ、暗号ＣＲＹＰＴＯMが生成される。結果として得られる暗号ＣＲＹＰＴＯM、すなわち、ＳｋｅｙM（ＲＮSP-M＊ＳＴＤM＊ＡＩM＊ＴＡ）は次にトランザクションＩＤ ＴＩＤSP-M２５６及び、もしあればプレーンテキストＰＬＡＩＮ ＴＥＸＴM２５８と結合２５４され、販売業者のトランザクション・メッセージのデータ部分、ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＣＲＹＰＴＯMを形成する。このデータはＥＣのトランザクション要求と結合２９６され、ＳＰに関する最終トランザクション要求メッセージのデータ部分、［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（ＲＮSP-EC＊ＳＴＤEC＊ＡＩEC＊ＴＡ）］＊ＤＳEC-Private-Key＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（ＲＮSP-M＊ＳＴＤM＊ＡＩM＊ＴＡ）］を形成する。
前と同様、販売業者はメッセージ・ダイジェストＭＤMを計算する一方向ハッシュ・アルゴリズム２９８を通じて自らの結合データを供給し、ＭＤMは次に販売業者のプライベート鍵３０２によってデジタル署名３００される。結果として得られるデジタル署名ＤＳM-Private-Key３００は（２９６からの）メッセージのデータ部分と結合され、最終トランザクション要求メッセージを形成し、その後ＳＰに送信される、｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（ＲＮSP-EC＊ＳＴＤEC＊ＡＩEC＊ＴＡ）］＊ＤＳEC-Private-Key＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（ＲＮSP-M＊ＳＴＤM＊ＡＩM＊ＴＡ）］｝＊ＤＳM-Private-Key。図25はトランザクション要求メッセージの最終フォーマットを示す。
ＳＰがトランザクション要求メッセージを受信すると、ＳＰはまず２つのトランザクション識別番号、すなわちＥＣと販売業者によって送信されたＴＩＤSP-ECとＴＩＤSP-Mを検査し、それらが有効であるかを確認する。（２１０の）ＴＩＤSP-Mと（１８６の）ＴＩＤSP-ECの何れかが無効であることが判明した場合、メッセージは拒否３０８される。トランザクション識別番号が両方とも有効である場合、ＳＰは先に進んでメッセージのデータ部分からＤＳM-Private-Keyを分離し、メッセージのデータ部分、｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（ＲＮSP-EC＊ＳＴＤEC＊ＡＩEC＊ＴＡ）］＊ＤＳEC-Private-Key＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（ＲＮSP-M＊ＳＴＤM＊ＡＩM＊ＴＡ）］｝を、このメッセージのメッセージ・ダイジェストＭＤ∧Mを計算する一方向ハッシュ・アルゴリズムに供給する。ＳＰはメッセージのデータ部分、すなわち、ＴＩＤSP-M、ＰＬＡＩＮ ＴＥＸＴM、ＣＲＹＰＴＯM、ＤＳM-Private-Key、（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＣＲＹＰＴＯEC）＊ＤＳEC-Private-Keyを分離する。
ＳＰは販売業者の公開鍵を使用してＤＳM-Private-Keyを解読３１０し、新しく回復されたメッセージ・ダイジェストＭＤMを計算されたばかりの（３０６からの）メッセージ・ダイジェストＭＤ∧Mと比較する。ＭＤ∧MとＭＤMが等しくない場合、メッセージは破損しており拒否３１４される。ＭＤ∧MとＭＤMが一致する場合、ＳＰは、ＫＥ段階でＳＰが販売業者に割り当てた（２１０の）セッション鍵ＳｋｅｙMを使用してメッセージの暗号化部分を解読３１６し、暗号化部分に含まれるデータ・フィールドを回復する。ＳＰはメッセージ中の販売業者が返送した乱数ＲＮSP-Mを、当初ＳＰが販売業者に送信したメッセージ、（２０８からの）ＲＮSP-Mと比較３１８する。乱数が等しくない場合、販売業者は相互認証試験に失敗しておりメッセージは拒否３２０される。
さらに、ＳＰはＥＣのアカウント情報ＡＩECとトランザクション金額ＴＡのようなトランザクション・データを検証する。ＡＩが有効でない場合メッセージは拒否３２０される。ＥＣからのＴＡと販売業者からのＴＡが一致しない場合もメッセージは拒否される。メッセージを無効にする他の条件もありうる。アカウント情報ＡＩECとトランザクションが有効な場合、ＳＰは続いてメッセージのＥＣ部分を検証する。
販売業者のメッセージの場合と同様、ＳＰはまずＥＣのメッセージからＤＳEC-Private-Keyを分離３２２し、ＥＣのメッセージのデータ部分、（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＣＲＹＰＴＯEC）を、ＥＣメッセージのメッセージ・ダイジェストＭＤ∧ECを計算する一方向ハッシュ・アルゴリズムに供給する。ＳＰはＥＣのトランザクション要求のデータ部分、ＴＩＤSP-EC、ＰＬＡＩＮ ＴＥＸＴEC、ＣＲＹＰＴＯEC、ＤＳEC-Private-Keyを分離する。ＳＰはＥＣの公開鍵ＰＫECを使用してＤＳEC-Private-Keyを解読３２４し、ＭＤECを回復する。ＳＰは回復されたＭＤECをＭＤ∧ECと比較３２６する。ＭＤECとＭＤ∧ECが等しくない場合、メッセージは破損しており拒否３２８される。ＭＤECとＭＤ∧ECが一致する場合、ＳＰは、ＫＥ段階でＳＰがＥＣに割り当てた（１８６の）セッション鍵ＳｋｅｙECを使用してＥＣメッセージの暗号化部分を解読３３０し、それに含まれるデータ・フィールドを回復する。
ＳＰはメッセージ中のＥＣが返送した乱数ＲＮSP-ECを、当初ＳＰがＥＣに送信した（１８４の）乱数ＲＮSP-ECと比較３３２する。乱数が等しくない場合、ＥＣは相互認証試験に失敗しておりメッセージは拒否３３４される。ＳＰは販売業者のアカウント情報ＡＩMと、トランザクション金額ＴＡのようなトランザクション・データを検証し、アカウント情報が無効の場合またはトランザクション・データがＳＰの基準３３４を満たさない場合メッセージを拒否する。メッセージ全体の完全性と信頼性が確立されると、ＳＰはメッセージ中に含まれるデータを処理し、応答メッセージを返送することができる。このメッセージ中で返送される乱数によってＳＰと販売業者間、及びＳＰとＥＣ間の相互認証が完了する。このメッセージの後、乱数の交換は必要ない。ＳＰは、販売業者とＥＣがＳＰに送信するその後のすべてのメッセージ中で使用するトランザクション識別番号として乱数を使用することを選択することができる。
前と同様、応答メッセージはＥＣ及び販売業者両方に関する情報を含んでいる。ＥＣに関するトランザクション応答メッセージをフォーマットするために、ＳＰはＥＣに関する応答データ、Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC３３８を生成し、ＥＣに割り当てられたセッション鍵ＳｋｅｙECを使用してそれを暗号化３３６する。機密データだけが暗号化される。プレーンテキストには機密応答データは含まれない。暗号ＣＲＹＰＴＯSP-EC、すなわち、ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）は、ＳＰが（１９４からの）ＥＣに割り当てたトランザクション識別番号ＴＩＤSP-EC、及び、もしあればＳＰがＥＣについて有するプレーンテキスト３４４と結合３４０され、ＥＣに関する応答メッセージのデータ部分、すなわち、ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）を形成する。メッセージのデータ部分は、ハッシュ・アルゴリズム３４６に供給され、ＳＰのプライベート鍵３５０を使用してＳＰによってデジタル署名されるＭＤSP-ECを生成する。ＤＳSP-Private-Keyは（３４０からの）応答メッセージのデータ部分と結合３５２され、ＥＣについての完全な応答メッセージ、［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）］＊ＤＳSP-Private-Keyを形成する。
販売業者に関するトランザクション応答メッセージをフォーマットするために、ＳＰは販売業者に関する応答データ、Ｒｅｓｐｏｎｓｅ ＤａｔａSP-M３５６を生成し、販売業者に割り当てられた（２１０からの）セッション鍵ＳｋｅｙMを使用してそれを暗号化３５４する。暗号ＣＲＹＰＴＯSP-Mは、販売業者３６０に割り当てられた（２１８からの）トランザクション識別番号ＴＩＤSP-M、及び、もしあればＳＰが販売業者３６２について有するプレーンテキストＰＬＡＩＮ ＴＥＸＴSP-Mと結合３５８され、販売業者に関する応答メッセージのデータ部分、ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴSP-M＊ＣＲＹＰＴＯSP-Mを形成する。データは次にＥＣに関する完全な応答メッセージと結合３６４され、ＥＣと販売業者両方に関する応答メッセージのデータ部分、［（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）］＊ＤＳSP-Private-Key＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴSP-M＊ＥSkey-M（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-M）］を形成する。
データは次にハッシュ・アルゴリズム３６６に供給され、ＳＰのプライベート鍵３７０を使用してＳＰによってデジタル署名３６８されるＭＤSP-Mを生成する。ＤＳSP-Private-KeyはＥＣと販売業者の両方に関する応答メッセージのデータ部分と結合３７２され、ＥＣ及び販売業者両方に関する完全な応答メッセージ、＜＜｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）］＊ＤＳSP-Private-Key｝＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴSP-M＊ＥSkey-M（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-M）］＞＞ＤＳSP-Private-Keyを形成する。図１０はトランザクション応答メッセージの最終フォーマットを示す。
販売業者はメッセージを受信すると、まずメッセージ中のトランザクション識別番号、ＴＩＤSP-Mを検査し、それが有効かを確認する。トランザクション識別番号が無効である場合、メッセージは拒否３７６される。ＴＩＤSP-Mが有効であれば、販売業者はメッセージのデータ部分からＳＰによって署名されたＤＳSP-Private-Keyを分離し、次にトランザクション応答メッセージのデータ部分、＜＜｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）］＊ＤＳSP-Private-Key｝＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴSP-M＊ＥSkey-M（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-M）］＞＞を一方向ハッシュ・アルゴリズムに供給しＭＤSP-Mを生じる。販売業者はメッセージのデータ部分を別々の部分、ＴＩＤSP-M、ＰＬＡＩＮ ＴＥＸＴSP-M、ＣＲＹＰＴＯSP-M、ＤＳSP-Private-Key（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＣＲＹＰＴＯSP-EC＊ＤＳSP-Private-Key）に分離し、ＳＰのトランザクション応答メッセージをＥＣに転送する準備をする。販売業者はＫＥ段階でＳＰによって割り当てられたセッション鍵ＳｋｅｙMを使用してＳＰのメッセージの暗号化部分を解読３７８し、その中に含まれるデータ・フィールドを回復する。
販売業者は次に（１４４からの）ＳＰの公開鍵、ＰＫSPを使用してデジタル署名ＤＳSP-Private-Keyを解読し、ＭＤSP-Mを回復する。販売業者は新たにハッシュされた（３７４からの）ＭＤ∧Mを回復されたＭＤSP-Mと比較する。ＭＤ∧MとＭＤSP-Mが一致しない場合、トランザクション応答メッセージは破損しているので拒否３８２される。メッセージ・ダイジェストが一致する場合、販売業者はメッセージの処理を開始する。通常通り、トランザクション応答メッセージのＥＣ部分（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＣＲＹＰＴＯSP-EC＊ＤＳSP-Private-Key）がＥＣに伝えられる。
ＥＣがトランザクション応答メッセージを受信すると、ＥＣはまず、メッセージ中のトランザクション識別番号、ＴＩＤSP-ECを検査し、それが有効であるかを確認する。トランザクション識別番号が無効である場合、メッセージは拒否３９６される。トランザクション識別番号が有効であれば、販売業者はトランザクション応答メッセージのデータ部分からＳＰによって署名されたＤＳSP-Private-Keyを分離し、次にＥＣトランザクション応答メッセージのデータ部分ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴSP-EC＊ＥSkey-EC（Ｒｅｓｐｏｎｓｅ ＤａｔａSP-EC）を一方向ハッシュ・アルゴリズムに供給しＭＤ∧SP-ECを生じる。ＥＣはメッセージを別々の部分、ＴＩＤSP-EC、ＰＬＡＩＮＴSP-EC、ＣＲＹＰＴＯSP-EC、ＤＳSP-Private-Keyに分離する。
ＥＣはＫＥ段階でＳＰによって割り当てられたセッション鍵Ｓｋｅｙを使用してＳＰのメッセージの暗号化部分を解読３９８し、その中に含まれるデータ・フィールドを回復する。ＥＣは（１２０からの）ＳＰの公開鍵を使用してデジタル署名ＤＳSP-Private-Keyを解読し、メッセージ・ダイジェストＭＤSP-ECを回復する。販売業者は新たにハッシュされたＭＤ∧SP-ECを回復されたＭＤSP-ECと比較４００する。ＭＤ∧SP-ECとＭＤSP-ECが一致しない場合、トランザクション応答メッセージは破損しているので拒否４０２される。メッセージ・ダイジェストが一致する場合、ＥＣはメッセージの処理を開始する。
トランザクションの終了時、ＥＣと販売業者は、ＳＰによって要求される場合、肯定応答メッセージをＳＰに送信し、応答メッセージが正しく受信され処理されたことを知らせることができる。トランザクションの終了前にＳＰと販売業者及びＥＣの間でさらに交換されるメッセージがある場合、この肯定応答データはＳＰに送信される次のメッセージの一部として含まれることがある。また、肯定応答データ自体がメッセージであることもある。
肯定応答メッセージをフォーマットするために、ＥＣはまずセッション鍵、ＳｋｅｙECを使用して、もしあれば、肯定応答データＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａECの機密部分、４０６を暗号化４０４し、ＳｋｅｙEC（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）を生成する。ＥＣは結果として得られる暗号を、ＳＰによって割り当てられたトランザクション識別番号ＴＩＤSP-EC４１０、及び、もしあればプレーンテキストＰＬＡＩＮ ＴＥＸＴEC４１２と結合４０８する。これによってＥＣの肯定応答メッセージのデータ部分、ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）が形成される。
この結合されたデータは次にＭＤECを生成する一方向ハッシュ・アルゴリズム４１４に供給される。結果として得られるＭＤECは次に、ＥＣのプライベート鍵４１８を使用してＥＣによってデジタル署名４１６され、ＤＳEC-Private-Keyが生成される。ＤＳEC-Private-Keyは（４０８からの）メッセージのデータ部分と結合４２０され、ＥＣに関する完全な肯定応答メッセージ、［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）］＊ＤＳEC-Private-Keyを形成する。肯定応答メッセージは次に販売業者に送信される。
販売業者は同じステップを通じて自らの固有の肯定応答メッセージを形成する。肯定応答メッセージをフォーマットするために、販売業者はまず、ＳＰによって販売業者に割り当てられたセッション鍵ＳｋｅｙMを使用して、もしあれば肯定応答データＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａMを暗号化し、ＳｋｅｙM（ＲＮSP-M＊Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａM）を生成する。販売業者は結果として得られる暗号を、ＳＰによって割り当てられたトランザクション識別番号ＴＩＤSP-M３９０、及び、もしあれば、（３９２からの）プレーンテキストＰＬＡＩＮ ＴＥＸＴMと結合３８８する。これによって販売業者の肯定応答メッセージのデータ部分、ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（ＲＮSP-M＊Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａM）が形成される。このデータ部分はさらにＥＣから受信された肯定応答メッセージと結合４２２され、ＳＰに関する結合肯定応答メッセージのデータ部分、｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）］＊ＤＳEC-Private-Key｝＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａM）］を形成する。
販売業者はＳＰに関する結合肯定応答メッセージのデータ部分を一方向ハッシュ・アルゴリズムに供給し、メッセージ・ダイジェストＭＤMを生成する。結果として得られるＭＤMは次に販売業者のプライベート鍵４２８を使用して販売業者によってデジタル署名され、ＤＳM-Private-Key４２６を生成する。ＤＳM-Private-Keyは（４２２からの）メッセージのデータ部分と結合４３０され、ＳＰについて指定されたＥＣと販売業者の最終結合肯定応答メッセージ、＜＜｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）］＊ＤＳEC-Private-Key｝＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａM）］＞＞＊ＤＳM-Private-Keyを形成する。このメッセージは次にＳＰに送信される。図１１はトランザクション肯定応答メッセージの最終フォーマットを示す。
ＴＩＤSP-MはＳＰによって販売業者に割り当てられた（２１８からの）トランザクション識別番号であり、ＴＩＤSP-ECはＳＰによってＥＣに割り当てられた（１９４からの）トランザクション識別番号である。トランザクション肯定応答メッセージを受信すると、ＳＰはＥＣ及び販売業者によって送信された２つのトランザクション識別番号ＴＩＤSP-M及びＴＩＤSP-ECを検査し、それらが有効であるかを確認する。ＴＩＤSP-MまたはＴＩＤSP-ECの何れかが無効であることが判明すると、メッセージは拒否４３４される。トランザクション識別番号が両方とも有効である場合、ＳＰは先に進んで結合肯定応答メッセージからＤＳM-Private-Keyを分離し、結合肯定応答メッセージのデータ部分＜＜｛［ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＳｋｅｙEC（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａEC）］＊ＤＳEC-Private-Key｝＊［ＴＩＤSP-M＊ＰＬＡＩＮ ＴＥＸＴM＊ＳｋｅｙM（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＤａｔａM）］＞＞を、このメッセージのメッセージ・ダイジェストＭＤ∧Mを計算する一方向ハッシュ・アルゴリズムに供給する。
ＳＰはメッセージのデータ部分ＴＩＤSP-M、ＰＬＡＩＮ ＴＥＸＴM、ＣＲＹＰＴＯM、ＤＳM-Private-Key、（ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＣＲＹＰＴＯEC）＊ＤＳEC-Private-Keyを分離する。ＳＰは販売業者の公開鍵ＰＫMを使用してＤＳM-Private-Keyを解読４３６し、回復されたメッセージ・ダイジェストＭＤM４３２を計算されたばかりのＭＤ∧M４３６と比較する。ＭＤ∧MとＭＤMが等しくない場合、メッセージは破損しており拒否４４０される。ＭＤ∧MとＭＤMが一致する場合、ＳＰはＫＥ段階で販売業者に割り当てられた（２１０からの）セッション鍵ＳｋｅｙMを使用して販売業者の肯定応答メッセージの暗号化部分を解読４４２し、それに含まれる肯定応答データを回復する。
ＳＰはＥＣの肯定応答メッセージからＤＳEC-Private-Keyを分離４４４し、ＥＣの肯定応答メッセージのデータ部分、ＴＩＤSP-EC＊ＰＬＡＩＮ ＴＥＸＴEC＊ＣＲＹＰＴＯECを、このメッセージのメッセージ・ダイジェストＭＤ∧ECを計算する一方向ハッシュ・アルゴリズムに供給する。ＳＰは、ＥＣの肯定応答メッセージのデータ部分ＴＩＤSP-EC、ＰＬＡＩＮ ＴＥＸＴEC、ＣＲＹＰＴＯEC、ＤＳEC-Private-Keyを分離する。ＳＰはＥＣの公開鍵ＰＫECを使用してＤＳEC-Private-Keyを解読４４６し、回復されたＭＤECを計算されたばかりのＭＤ∧EC４４４と比較４４８する。メッセージ・ダイジェストが等しくない場合、メッセージは破損しており拒否４５０される。ＭＤ∧ECとＭＤECが一致する場合、ＳＰはＫＥ段階でＥＣに割り当てられた（１８６からの）セッション鍵ＳｋｅｙECを使用してメッセージの暗号化部分を解読４５２し、その中に含まれる肯定応答データを回復する。これによってトランザクション４５４のトランザクション段階の処理が完了する。
トランザクションを通じて、好適実施形態では、ＥＣはマイクロソフト・エクスプローラー（Ｍｉｃｒｏｓｏｆｔ Ｅｘｐｌｏｒｅｒ）またはネットスケープ・ナビゲーター（Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ）といったインターネット・ブラウザ・ソフトウェアによって提供されるインタフェース・ソフトウェアと共に動作する。通常のセッションでは、カード保有者は自らのブラウザを販売業者のＵＲＬに向け、販売業者に商品またはサービスを注文する。支払いの時点で、ブラウザはＥＣインタフェース・ソフトウェアを起動するが、これはブラウザに組み込まれるか、またはプラグインまたはアドオンとして含まれ、トランザクションを先に進めることを可能にする。カード保有者は自らのブラウザを任意のＳＰメンバーのＵＲＬに向ける。
上記の図6〜図22で説明された２段階トランザクションは２段階鍵交換トランザクション・モデルを利用する特定の場合にすぎない。図6〜図22で説明される２段階トランザクションでは、トランザクションに関与する当事者の数は３、すなわち、ＥＣ、販売業者及びＳＰである。２段階鍵交換トランザクション・モデルは関与する当事者の数が２から多数にまで異なる場合にも同様に適用可能である。３より多い当事者が関与するトランザクションでは、ＳＰの役目を果たす当事者は１つだけである。他の全ての当事者は選択されたＳＰの公開鍵を使用して初期鍵交換を行い、ＳＰによって割り当てられたセッション鍵とトランザクションＩＤを使用してトランザクションを実行する。
２段階鍵交換トランザクション・モデルは、（１）参加者がサービス・プロバイダと直列の可能なルータによって配置される、または（２）参加者が階層的編成の可能なルータによって配置される、編成スキームに適用可能である。こうした追加編成スキームは、メッセージを次のレベルのルーティングするルータを必要とする。階層のレベルは任意の数の参加者及び／またはルータから構成される。次のレベルは、順序または階層中次にある次の参加者またはルータである。階層的編成スキームでは、次のレベルには全ての可能な次の参加者及びルータが含まれる。階層的編成スキームの場合、ＳＰはメッセージの送信先となる次の参加者またはルータを決定する基準を確立する。
ルータはゲートウェイ／コンジットであり、前のレベルからメッセージを収集し、ＳＰの要求によってメッセージを結合するといったメッセージに対する処理を行い、メッセージをＳＰに転送する。各参加者は自らの固有のメッセージ（データとデジタル署名）を形成し、それを次のレベルに送信することだけが必要である。参加者は自分が受信した全てのメッセージを自らの固有のメッセージと結合し、次のレベルに送信する前に結合メッセージにデジタル署名する。階層的編成の最も単純な形態では、全ての他の参加者からメッセージを収集し結合メッセージをＳＰに送信する１つだけのルータが存在する。
直列編成では、トランザクションの発信者は、サービス・プロバイダ６０と直列のルータ及び／または参加者と直列である。本発明の好適実施形態では、図１２に示される各要素は参加者である。本発明の代替実施形態では、発信者とＳＰの間に中間要素がある場合それはルータのことがある。
図１２に示されるように、発信者は、参加者１１００、１１２０、１１４０及び１１６０、及び直列に配置されたサービス・プロバイダとトランザクションを行う。これは、図6〜図22で説明された３当事者シナリオと同様であるが、ここではさらに多くの当事者が関与するという点が異なっている。直列に配置された参加者３、４、５、６．．．ｎ−２に注意されたい１１８０。各参加者は自らの固有のメッセージを準備し、前の参加者から自分が受信したメッセージがある場合それと組み合わせ、メッセージにデジタル署名を添付し、それを回線中の次の参加者に送信する。結合メッセージは最終的にＳＰに送信され、ＳＰはそれに応じて応答を形成し、元のメッセージが伝えられたのと同じ経路を通じてそれを返送する。
図１３は階層的編成スキームで配置された要素を示すが、そこでは各要素、Ｘ1,1〜Ｘ1,n（ｎ＝１、２、３、．．．）１２００はトランザクションの参加者であってメッセージ・ルータではなく、各要素、Ｘj,k（ｊ＝２、３、４、．．．；ｋ＝１、２、３、．．．ｍ；ｍは種類ｎの変数であり、ｍは異なったレベルの階層について異なった値であることがある）１２１０は参加者またはルータの何れかである。上向き太字矢印は要求メッセージ１２２０の送信を表し、下向き矢印は応答メッセージ１２３０の送信を表す。
各参加者は自分が責任を負う多数の参加者からのメッセージを収集し、メッセージを自らの固有のメッセージと結合し新しいメッセージを形成した後、新しいメッセージを次のレベルに送信する。階層的編成スキームには１つだけの参加者から必要に応じた多数の参加者が含まれる（階層的スキームの最も小規模な事例は１つの参加者と１つのサービス・プロバイダである）。最終的には、サービス・プロバイダの前の最後の要素、Ｘσ,1（σは種類ｎのものである）で、全てのメッセージは１つのメッセージ１２４０に結合され、それがＳＰ６０に送信される。ここでも、ＳＰは応答メッセージを形成しそれを同じ経路を通じて返送する。
ＳＰがトランザクションを管理しない場合、メンバーはＳＰによって生成されたセッション鍵を使用して相互間でトランザクションを行う。トランザクションは２つかそれ以上のメンバー間で行われる。トランザクションに関与する２つより多いメンバーが存在する場合、メッセージはメンバーからメンバーへ任意の順序で流れる。メンバーはトランザクション要求メッセージを送信し、トランザクション応答メッセージを受信する。メンバーは必ずしも自分がトランザクション要求メッセージを送信した同じメンバーからトランザクション応答メッセージを受信する必要はない。例えば、トランザクション中の３つのメンバーがリングに編成され、リングを巡ってメッセージが送信されることがある。第１メンバーが第２メンバーにトランザクション要求メッセージを送信し、次に第２メンバーがトランザクション要求メッセージとトランザクション応答メッセージを第３メンバーに送信する。第３メンバーはトランザクション要求メッセージとトランザクション応答メッセージを第１メンバーに送信し、第１メンバーはトランザクション応答メッセージを第２メンバーに送信する。トランザクション要求メッセージを受信したメンバーはトランザクション応答メッセージを作成し、それが最終的にはトランザクション要求メッセージを送信したメンバーに送信される。
鍵交換段階では、ＳＰは全てのトランザクション参加メンバーの公開鍵を得る。参加メンバーが相互間のトランザクションを行う前に、ＳＰは各参加メンバーに他のメンバーの公開鍵を送信する。トランザクション要求メッセージとトランザクション応答メッセージには、もしあればプレーンテキスト、暗号、及び送信側のデジタル署名が含まれる。
ＳＰが、証明ベース外部システムを処理するためＥＣ及び／または販売業者に関するサロゲート証明の役目を果たす必要がある場合、ＳＰは外部インタフェースの動作からＥＣ及び／または販売業者を保護する。ＳＰはＥＣ及び／または販売業者とのトランザクションを完了するために必要な情報をＥＣ及び／または販売業者に戻すのみとなる。
本発明の好適及び例示的実施形態と考えられるものが本明細書で説明されたが、本発明の他の修正も当業者には明らかであろう。従って、そうした全ての修正及び拡張は本発明の真の精神及び範囲内にあるものとして添付の請求項で保証されることが望ましい。本発明は添付の請求の範囲内にある全ての実施形態を含むものと考えられ、本発明は以下の添付の請求項によってのみ制限される。さらに、本発明の精神と範囲から離れることなく他の適用業務が本明細書で示されたものに置換されることを当業者は容易に認識するであろう。
図1は、本発明の実施例によるシステムのコンポーネント相互間の関係を示すブロック図である。 図2は、ネットワーク経由の2つの取引段階の流れを示す。 図3は、電子カード（EC）の図表的表現である。 図4は、サービスプロバイダのデータ領域のフォーマットを示す。サービスプロバイダの情報は各々、表の中の1つのエントリに割り当てられ、アクセス条件によって保護される。 図5は、本発明の実施例においてディジタル署名がどのように使用されているかを示す。 図6は、本発明の実施例においてインターネットなどのオープン通信網を経由して電子取引を行うのに使用される暗号システムと暗号法の概略的フローチャートを示す。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図6と同様の図。 図23は、鍵交換段階と取引段階における複合的なリクエストメッセージと応答メッセージの最終のフォーマットと内容を示す。 図23と同様の図。 図23と同様の図。 図23と同様の図。 図23と同様の図。 図28は、直列に配置された関係者と取引を行うサービスプロバイダを示す。 図29は、階層構造で配置された関係者とのネットワーク上でのサービスプロバイダ取引を示す。

Claims (25)

  1. サービスプロバイダの公開鍵を有する電子カードを使用して電子商取引を行う方法であって、
    カード所有者の公開鍵を有しその少なくとも一部は該電子カードからのサービスプロバイダの公開鍵を使って暗号化されている鍵交換要求メッセージをカード所有者の位置においてフォーマットし、
    該鍵交換要求メッセージをカード所有者の位置からサービスプロバイダの位置へ送り、
    該鍵交換要求メッセージに応答してサービスプロバイダの位置においてセッション鍵を生成し、
    サービスプロバイダの位置において該セッション鍵を有する鍵交換応答メッセージをフォーマットし、
    該鍵交換応答メッセージをカード所有者の位置へ送り、
    該セッション鍵を用いてカード所有者とサービスプロバイダの間のトランザクションを完遂することを具備する方法。
  2. 前記鍵交換要求メッセージはサービスプロバイダに対するカード所有者のチャレンジをさらに具備し、
    鍵交換応答メッセージは該カード所有者のチャレンジへの応答およびカード所有者に対するサービスプロバイダのチャレンジをさらに具備し、
    カード所有者の位置において該サービスプロバイダのチャレンジに対する応答をフォーマットしそれをサービスプロバイダの位置へ送ることをさらに含む請求項１記載の方法。
  3. 前記セッション鍵を用いてトランザクションを完遂することは、
    カード所有者の位置においてセッション鍵を用いてトランザクション要求メッセージをフォーマットし、
    カード所有者の位置において該トランザクション要求メッセージをディジタル署名し、
    カード所有者の位置からサービスプロバイダの位置へ該トランザクション要求メッセージを送り、
    サービスプロバイダの位置において該セッション鍵を用いてカード所有者に対するトランザクション応答メッセージをフォーマットし、
    サービスプロバイダの位置において該トランザクション応答メッセージをディジタル署名し、
    カード所有者の位置へ該トランザクション応答メッセージを送ることを具備する請求項１または２記載の方法。
  4. 前記トランザクション要求メッセージは各々が該セッション鍵で暗号化されたアカウント情報、トランザクション量及びトランザクションデータを含む請求項３記載の方法。
  5. 前記トランザクション要求メッセージは平文を含む請求項３記載の方法。
  6. 前記トランザクション要求メッセージはサービスプロバイダによってカード所有者に割り当てられたトランザクション識別子を含む請求項３記載の方法。
  7. 前記トランザクション応答メッセージは平文を含む請求項３記載の方法。
  8. 前記トランザクション応答メッセージはサービスプロバイダによってカード所有者に割り当てられたトランザクション識別子を含む請求項３記載の方法。
  9. 前記セッション鍵を用いてトランザクションを完遂することは、
    カード所有者の位置において該セッション鍵を用いてトランザクション肯定応答メッセージをフォーマットし、
    カード所有者の位置において該トランザクション肯定応答メッセージをディジタル署名し、
    該トランザクション肯定応答メッセージをサービスプロバイダの位置へ送ることを具備する請求項３記載の方法。
  10. 前記トランザクション肯定応答メッセージは前記セッション鍵で暗号化された肯定応答データを具備する請求項９記載の方法。
  11. 前記トランザクション肯定応答メッセージは平文を具備する請求項９記載の方法。
  12. 前記トランザクション肯定応答メッセージはサービスプロバイダによってカード所有者に割り当てられたトランザクション識別子を具備する請求項９記載の方法。
  13. 前記鍵交換要求メッセージは電子カードからのサービスプロバイダの公開鍵で暗号化されたカード所有者のチャレンジを有する第１の暗号文をさらに具備し、前記方法はカード所有者の位置において鍵交換要求メッセージをディジタル署名することをさらに具備し、前記鍵交換応答メッセージはサービスプロバイダのチャレンジおよびカード所有者のチャレンジに対する応答を具備する第２の暗号文を具備し、該第２の暗号文はセッション鍵とともにカード所有者の公開鍵で暗号化されており、前記方法はさらに、
    サービスプロバイダの位置において前記鍵交換応答メッセージをディジタル署名し、
    カード所有者の位置においてセッション鍵で暗号化されたサービスプロバイダのチャレンジ応答を具備する第３の暗号文を生成し、
    メッセージに該第３の暗号文を添付し、
    カード所有者の位置において該メッセージおよび該第３の暗号文の双方を一緒にディジタル署名してそれらをサービスプロバイダの位置へ送ることを具備する請求項１記載の方法。
  14. 前記鍵交換要求メッセージおよび鍵交換応答メッセージの各々は平文を具備する請求項１３記載の方法。
  15. 前記鍵交換要求メッセージはサービスプロバイダの公開鍵で暗号化されたカード所有者の公開鍵を具備する請求項１３記載の方法。
  16. 前記第２の暗号文はカード所有者の公開鍵で暗号化されたカード所有者のチャレンジ応答をさらに具備する請求項１３記載の方法。
  17. 前記第２の暗号文の生成はカード所有者の公開鍵で暗号化されたトランザクション識別子をさらに具備する請求項１３記載の方法。
  18. 前記鍵交換応答メッセージは平文を具備するトランザクション識別子をさらに含む請求項１３記載の方法。
  19. カード所有者の位置からサービスプロバイダの位置へ向かうメッセージに続く第２のメッセージを伴うトランザクション識別子を使用することをさらに具備する請求項１８記載の方法。
  20. 前記鍵交換要求メッセージを送ることは該鍵交換要求メッセージをカード所有者の位置から第２のカード所有者への位置へ送ることと第２のカード所有者の位置からサービスプロバイダの位置へ送ることを具備し、前記方法は、
    第２のカード所有者の位置においてカード所有者の位置からの鍵交換要求メッセージを第２のカード所有者の位置において生成された第２の鍵交換要求メッセージと結合して第２のカード所有者位置において署名された該結合鍵交換要求メッセージをサービスプロバイダの位置へ送り、
    サービスプロバイダの位置において鍵交換応答メッセージをディジタル署名し、
    サービスプロバイダの位置において該第２のカード所有者の位置に対する第２のセッション鍵を含む第２の鍵交換応答メッセージをフォーマットし、
    サービスプロバイダの位置において該鍵交換応答メッセージと該第２の鍵交換応答メッセージを結合して結合鍵交換応答メッセージとし、
    サービスプロバイダの位置において該結合鍵交換応答メッセージを署名することをさらに具備し、
    該鍵交換応答メッセージをカード所有者の位置へ送ることは、該結合鍵交換応答メッセージをサービスプロバイダの位置から該第２のカード所有者の位置へ送り、該第２のカード所有者の位置において第２のカード所有者の位置に対する第２の鍵交換応答メッセージをカード所有者の位置に対する鍵交換応答メッセージから分離し、カード所有者に対する鍵交換応答メッセージをカード所有者の位置へ転送することを具備する請求項１記載の方法。
  21. 前記カード所有者の位置においてカード所有者の位置に対するセッション鍵を使ってトランザクション要求メッセージをフォーマットしてトランザクション要求メッセージをディジタル署名し、
    該トランザクション要求メッセージをカード所有者の位置から第２のカード所有者の位置へ送り、
    第２のカード所有者の位置において第２のカード所有者に対するセッション鍵を使ってトランザクション要求メッセージをフォーマットし、
    第２のカード所有者の位置において２つのトランザクション要求メッセージを１つの結合トランザクション要求メッセージに結合して該結合トランザクション要求メッセージをディジタル署名し、
    該結合トランザクション要求メッセージを第２のカード所有者の位置からサービスプロバイダの位置へ送り、
    サービスプロバイダの位置においてカード所有者の位置に対するセッション鍵を使ってトランザクション応答メッセージをフォーマットして該トランザクション応答メッセージをディジタル署名し、
    サービスプロバイダの位置において第２のカード所有者の位置に対するセッション鍵を使ってトランザクション応答メッセージをフォーマットし、
    サービスプロバイダの位置において２つのトランザクション応答メッセージを１つの結合トランザクション応答メッセージに結合して該結合トランザクション応答メッセージをディジタル署名し、
    結合トランザクション応答メッセージを第２のカード所有者の位置へ送り、
    第２のカード所有者の位置において該結合トランザクション応答メッセージをカード所有者の位置に対するトランザクション応答メッセージと第２のカード所有者の位置に対するトランザクション応答メッセージに分離し、
    カード所有者の位置に対するトランザクション応答メッセージを第２のカード所有者の位置からカード所有者の位置へ転送することをさらに具備する請求項２０記載の方法。
  22. カード所有者の位置においてカード所有者の位置に対するセッション鍵を使って肯定応答メッセージをフォーマットして該肯定応答メッセージをディジタル署名し、
    該肯定応答メッセージをカード所有者の位置から第２のカード所有者の位置へ送り、
    第２のカード所有者の位置において第２のカード所有者の位置に対するセッション鍵を使って肯定応答メッセージをフォーマットし２つの肯定応答メッセージを１つの結合肯定応答メッセージに結合して第２のカード所有者の位置において該結合肯定応答メッセージをディジタル署名し、
    結合肯定応答メッセージを第２のカード所有者の位置からサービスプロバイダの位置へ送ることをさらに具備する請求項２１記載の方法。
  23. 前記２つのセッション鍵は同一である請求項２２記載の方法。
  24. 前記２つのセッション鍵は異なっている請求項２２記載の方法。
  25. 前記第２のカード所有者の位置に対する鍵交換応答メッセージはサービスプロバイダの位置に対する公開鍵を含み、前記カード所有者の位置に対する鍵交換応答メッセージは第２のカード所有者の位置の公開鍵を含む請求項２２記載の方法。
JP2004270384A 1998-05-05 2004-09-16 電子商取引用の暗号化方法 Pending JP2005065315A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US8425798P 1998-05-05 1998-05-05

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2000547720A Division JP2002514839A (ja) 1998-05-05 1999-05-05 電子商取引用の暗号のシステムおよび方法

Publications (1)

Publication Number Publication Date
JP2005065315A true JP2005065315A (ja) 2005-03-10

Family

ID=22183802

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2000547720A Pending JP2002514839A (ja) 1998-05-05 1999-05-05 電子商取引用の暗号のシステムおよび方法
JP2004270384A Pending JP2005065315A (ja) 1998-05-05 2004-09-16 電子商取引用の暗号化方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2000547720A Pending JP2002514839A (ja) 1998-05-05 1999-05-05 電子商取引用の暗号のシステムおよび方法

Country Status (8)

Country Link
JP (2) JP2002514839A (ja)
CN (2) CN101087189A (ja)
AU (1) AU762708B2 (ja)
CA (1) CA2329032C (ja)
GB (1) GB2353623B (ja)
HK (1) HK1038657A1 (ja)
TW (1) TW476202B (ja)
WO (1) WO1999057835A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015233315A (ja) * 2006-11-09 2015-12-24 エーサー・クラウド・テクノロジイ・インコーポレイテッド サーバ

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7249097B2 (en) 1999-06-18 2007-07-24 Echarge Corporation Method for ordering goods, services, and content over an internetwork using a virtual payment account
CA2377706A1 (en) 1999-06-18 2000-12-28 Echarge Corporation Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
AUPQ556600A0 (en) 2000-02-14 2000-03-02 Ong, Yong Kin (Michael) Electronic funds transfers-zipfund
AU3348401A (en) * 2000-02-14 2001-08-20 Yong Kin Michael Ong Electronic funds transfers - zipfund
AU2005203599B2 (en) * 2000-02-14 2007-03-08 Yong Kin Ong (Michael) Electronic funds transfer
FR2805913B1 (fr) * 2000-03-01 2002-08-09 Ingenico Sa Terminal de paiement sur reseau local
FR2807552B1 (fr) * 2000-04-11 2004-01-09 France Telecom Terminal horodateur de paiement su stationnement payant d'un vehicule automobile
US7024395B1 (en) 2000-06-16 2006-04-04 Storage Technology Corporation Method and system for secure credit card transactions
WO2002013435A1 (en) * 2000-08-04 2002-02-14 First Data Corporation Method and system for using electronic communications for an electronic contact
JP2002158650A (ja) * 2000-11-21 2002-05-31 Fujitsu Ltd 認証・暗号化処理代行用のサーバ、アクセスカード、プログラム記録媒体及び携帯端末
AU2001268548A1 (en) * 2001-06-19 2003-01-02 Storage Technology Corporation Method and system for secure credit card transactions
US20030056111A1 (en) * 2001-09-19 2003-03-20 Brizek John P. Dynamically variable security protocol
GB2384096A (en) * 2001-12-01 2003-07-16 Grass Roots Group Uk Ltd Payment system and related methods
JP3979195B2 (ja) 2002-06-25 2007-09-19 ソニー株式会社 情報記憶装置、およびメモリアクセス制御方法、並びにコンピュータ・プログラム
JP2004171416A (ja) * 2002-11-21 2004-06-17 Ntt Docomo Inc 通信端末、価値実体提供サーバ、アプリケーション配信サーバ、電子購買支援システム、電子購買支援方法、及び電子購買支援プログラム
ES2244283B1 (es) * 2003-05-23 2007-02-16 Fco. Manuel Cansino Fernandez Sistema de transaccion electronica.
EP1998279A1 (en) * 2007-05-29 2008-12-03 First Data Corporation Secure payment transaction in multi-host environment
US10558961B2 (en) 2007-10-18 2020-02-11 Wayne Fueling Systems Llc System and method for secure communication in a retail environment
CN102103651B (zh) * 2009-12-21 2012-11-14 中国移动通信集团公司 一种一卡通系统的实现方法和系统以及一种智能卡
CN102568097B (zh) * 2010-12-08 2017-02-22 邵通 一种增强电子钱包安全的方法和系统
CN103108245B (zh) * 2011-11-15 2016-09-28 中国银联股份有限公司 一种智能电视支付密钥系统以及基于智能电视的支付方法
US12072989B2 (en) 2011-12-09 2024-08-27 Sertainty Corporation System and methods for using cipher objects to protect data
US9792451B2 (en) 2011-12-09 2017-10-17 Echarge2 Corporation System and methods for using cipher objects to protect data
US9264413B2 (en) * 2012-12-06 2016-02-16 Qualcomm Incorporated Management of network devices utilizing an authorization token
CN103942688A (zh) * 2014-04-25 2014-07-23 天地融科技股份有限公司 数据安全交互系统
CN104243171A (zh) * 2014-10-15 2014-12-24 北京奇虎科技有限公司 反馈数据的全文保护、校验方法和装置
US11386409B2 (en) 2016-03-04 2022-07-12 Sertintyone Corporation Systems and methods for media codecs and containers
EP3779753A3 (en) * 2016-03-15 2021-05-12 Visa International Service Association Validation cryptogram for interaction
WO2017175926A1 (ko) * 2016-04-05 2017-10-12 삼성전자 주식회사 Id 기반 공개 키 암호화를 이용한 전자 지불 방법 및 전자 디바이스
GB2549118B (en) 2016-04-05 2020-12-16 Samsung Electronics Co Ltd Electronic payment system using identity-based public key cryptography

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07152837A (ja) * 1993-09-17 1995-06-16 At & T Corp スマートカード
JPH0818552A (ja) * 1994-04-28 1996-01-19 Nippon Telegr & Teleph Corp <Ntt> 暗号鍵配送システムおよび方法
JPH0884141A (ja) * 1994-09-14 1996-03-26 Nippon Telegr & Teleph Corp <Ntt> 文書通信管理方法
JPH09503895A (ja) * 1994-07-29 1997-04-15 モトローラ・インコーポレーテッド 通信システムにおける真正証明のための方法および装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5396558A (en) * 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
US5590197A (en) * 1995-04-04 1996-12-31 V-One Corporation Electronic payment system and method
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07152837A (ja) * 1993-09-17 1995-06-16 At & T Corp スマートカード
JPH0818552A (ja) * 1994-04-28 1996-01-19 Nippon Telegr & Teleph Corp <Ntt> 暗号鍵配送システムおよび方法
JPH09503895A (ja) * 1994-07-29 1997-04-15 モトローラ・インコーポレーテッド 通信システムにおける真正証明のための方法および装置
JPH0884141A (ja) * 1994-09-14 1996-03-26 Nippon Telegr & Teleph Corp <Ntt> 文書通信管理方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015233315A (ja) * 2006-11-09 2015-12-24 エーサー・クラウド・テクノロジイ・インコーポレイテッド サーバ
US9589154B2 (en) 2006-11-09 2017-03-07 Acer Cloud Technology Inc. Programming on-chip non-volatile memory in a secure processor using a sequence number
JP2017139793A (ja) * 2006-11-09 2017-08-10 エーサー・クラウド・テクノロジイ・インコーポレイテッド サーバ
US9881182B2 (en) 2006-11-09 2018-01-30 Acer Cloud Technology, Inc. Programming on-chip non-volatile memory in a secure processor using a sequence number

Also Published As

Publication number Publication date
HK1038657A1 (en) 2002-03-22
AU4307599A (en) 1999-11-23
CN1307818C (zh) 2007-03-28
CN101087189A (zh) 2007-12-12
TW476202B (en) 2002-02-11
GB2353623B (en) 2003-01-08
JP2002514839A (ja) 2002-05-21
CA2329032C (en) 2004-04-13
WO1999057835A9 (en) 2000-02-03
CA2329032A1 (en) 1999-11-11
GB0026755D0 (en) 2000-12-20
CN1304602A (zh) 2001-07-18
GB2353623A (en) 2001-02-28
WO1999057835A1 (en) 1999-11-11
AU762708B2 (en) 2003-07-03

Similar Documents

Publication Publication Date Title
US7096494B1 (en) Cryptographic system and method for electronic transactions
CA2329032C (en) A cryptographic system and method for electronic transactions
Asokan et al. The state of the art in electronic payment systems
Bellare et al. Design, implementation, and deployment of the iKP secure electronic payment system
Bellare et al. iKP-A Family of Secure Electronic Payment Protocols.
US8438116B2 (en) Token based new digital cash protocols
US8352378B2 (en) Virtual account based new digital cash protocols with combined blind digital signature and pseudonym authentication
US6061791A (en) Initial secret key establishment including facilities for verification of identity
US6560581B1 (en) System and method for secure electronic commerce transaction
JP4116971B2 (ja) グループ署名のための暗号システム
US8442919B2 (en) Token based new digital cash protocols with combined blind digital signature and pseudonym authentication
US20070277013A1 (en) Method for transmitting protected information to a plurality of recipients
US20020073045A1 (en) Off-line generation of limited-use credit card numbers
Rubin et al. Off-line generation of limited-use credit card numbers
Asokan et al. State of the art in electronic payment systems
Jacobson et al. Mix-based electronic payments
Lee et al. Traceability of double spending in secure electronic cash system
EP1171849B1 (en) Communication system and method for efficiently implementing electronic transactions in mobile communication networks
Djuric IPS-secure Internet payment system
Asokan et al. Electronic payment systems
Fan et al. Fair transaction protocols based on electronic cash
GB2376337A (en) A cryptographic method
Lee et al. Smart card based off-line micropayment framework using mutual authentication scheme
Bellare et al. Design, Implementation and Deployment of IKP: A Secure Account-based Electronic Payment System
Waidner Electronic Payment Systems

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060425

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090908

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091202

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091207

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100511