JP2002514839A - Cryptographic system and method for electronic commerce - Google Patents
Cryptographic system and method for electronic commerceInfo
- Publication number
- JP2002514839A JP2002514839A JP2000547720A JP2000547720A JP2002514839A JP 2002514839 A JP2002514839 A JP 2002514839A JP 2000547720 A JP2000547720 A JP 2000547720A JP 2000547720 A JP2000547720 A JP 2000547720A JP 2002514839 A JP2002514839 A JP 2002514839A
- Authority
- JP
- Japan
- Prior art keywords
- message
- transaction
- key
- merchant
- electronic card
- 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
Links
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)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (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
(57)【要約】 電子商取引のシステムであって、該システムはカード保持者(20)、商人(70)およびサービスプロバイダ(SP)(60)を包含する複数の当事者の間での安全保障された電子商取引を容易にする。該システムはスマートカードとして普通に知られている電子カードおよびそれと等価のコンピュータソフトウエアのパッケージを必然に伴う。カードは本物の札入れを模擬し、普通に見られる財務的または非財務的な装置例えばクレジットカード、小切手帳、または運転免許証等を包含する。取引きはハイブリッドキイの暗号のシステムにより保護され、正常には公衆回線網例えばインターネット上で実行される。デジタルの署名およびランダム数が使用され統合性および認証性が確保される。カードは秘密キイ例えばサービスプロバイダ(SPs)により割当てられるセッションキイを使用し各取引の秘密性を確保する。SPは各加入者を有効化し、セッションキイを割当てることにのみ責任をもつ。取引で必要である唯一の信用関係は、個別の加入者とSPの間に存在するものである。 (57) Abstract: An electronic commerce system, wherein the system is secured between a plurality of parties including a cardholder (20), a merchant (70) and a service provider (SP) (60). Facilitate e-commerce. The system entails an electronic card commonly known as a smart card and an equivalent package of computer software. The card simulates a real wallet and includes commonly found financial or non-financial devices such as a credit card, checkbook, or driver's license. Transactions are protected by a hybrid key cryptosystem and are normally executed over a public network, such as the Internet. Digital signatures and random numbers are used to ensure integrity and authenticity. The card uses a secret key, such as a session key assigned by a service provider (SPs), to ensure the confidentiality of each transaction. The SP is only responsible for activating each subscriber and assigning a session key. The only credit relationship required in a transaction is that which exists between the individual subscriber and the SP.
Description
【0001】 発明の分野 本発明は、一般に安全な電子商取引(electronic transactions)のための暗
号システムおよび暗号法に関するもので、詳記すれば、"スマートカード"および
/またはこれと等価のソフトウェアの形を取る電子カード(electronic card)に
関するものである。FIELD OF THE INVENTION The present invention relates generally to cryptographic systems and cryptography for secure electronic transactions, and more particularly to "smart cards" and / or software equivalents. Electronic card.
【0002】 発明の背景 属名"スマートカード"は一般に集積回路(IC)カード、すなわちマイクロチッ
プを埋め込んだクレジットカード大のプラスチック片である。スマートカード上
のICチップは、一般にマイクロプロセッサ(CPU)、リード・オンリー・メモリ
(ROM)、ランダム・アクセス・メモリ(RAM)、入出力装置およびいくらか持続
性のあるメモリ、例えば電気的消去可能なプログラマブル・リード・オンリー・
メモリ(EEPROM)からなるが、必ずしもそうであるとは限らない。チップは、算
術計算、論理処理、データ管理およびデータ通信を実行することができる。BACKGROUND OF THE INVENTION The generic name "smart card" is generally an integrated circuit (IC) card, a credit card-sized piece of plastic with a microchip embedded therein. IC chips on smart cards are generally microprocessor (CPU), read only memory (ROM), random access memory (RAM), I / O devices and some persistent memory, such as electrically erasable Programmable read-only
It consists of memory (EEPROM), but not always. The chip can perform arithmetic calculations, logical operations, data management and data communication.
【0003】 スマートカードは主に2つのタイプがある。接触型と非接触型である。国際標
準化機構(ISO)は、このような電子カードの仕様をISOシリーズのもとで確立し
た。特にISO 7816は集積回路カードに適用される。その計算能力のために、スマ
ートカードは、認証、機密読み書き、対称/非対称型鍵暗号化/暗号解読など多
数のセキュリティ特徴をサポートすることができる。これらのセキュリティ特徴
により、スマートカードは、データ機密保護や認証が最重要項目である電子商取
引に好適とされる。[0003] There are two main types of smart cards. Contact type and non-contact type. The International Organization for Standardization (ISO) has established specifications for such electronic cards under the ISO series. In particular, ISO 7816 applies to integrated circuit cards. Due to its computing power, smart cards can support a number of security features, such as authentication, secret read / write, symmetric / asymmetric key encryption / decryption. These security features make smart cards suitable for electronic commerce where data security and authentication are paramount.
【0004】 スマートカードは、大量輸送、健康保険、パーキング、キャンパス、ガソリン
スタンドなど多くの特化された分野で使われてきた。また、電子商取引および他
の金融分野においてその潜在用途を急速に広げつつある。1996年5月28日付でRob
ert S. Powerに付与された「不正使用を防止する多重記憶メモリを有する電子財
布カードとそのための方法」と題する米国特許第5,521,362号は、電子財布の用
途について述べている。Powerの発明は、単なる記憶デバイスとしてでなく、安
全な金融証券として使用できるスマートカードの能力を示威している。[0004] Smart cards have been used in many specialized areas such as mass transit, health insurance, parking, campuses, and gas stations. It is also rapidly expanding its potential uses in e-commerce and other financial fields. Rob on May 28, 1996
U.S. Pat. No. 5,521,362, issued to ert S. Power, entitled "Electronic Wallet Card with Multiple Storage Memory to Prevent Unauthorized Use and Method Therefor," describes the use of electronic wallets. Power's invention demonstrates the ability of smart cards to be used as secure financial instruments, not just as storage devices.
【0005】 技術の進歩がスマートカードチップ計算の高速化と記憶容量の大型化を急き立
てるにつれて、"多用途"スマートカードのコンセプトは経済性と物理的な実現の
可能性の点で重要度を増しつつある。1996年6月25日付でDouglas C. Taylorに付
与された「多用途データカード」と題する米国特許第5,530,232号は、現在ある
多数の単用途カードに取って代わり、金融目的の要件と非金融目的の要件の両方
を満たすことのできる多用途カードについて述べている。多用途カードは、スマ
ートカードとリモート・サービス・プロバイダの間の接続に従来のデータリンク
を使用する。Tylorの発明である多用途カードは、いかなる種類のオープン・ネ
ットワークにも暗号法にも関係していない。[0005] As technological advances have driven faster smart card chip computations and larger storage capacities, the concept of "versatile" smart cards has gained importance in terms of economics and physical feasibility. Increasing. U.S. Pat. No. 5,530,232, entitled "Multi-Use Data Card", issued to Douglas C. Taylor on June 25, 1996, replaces many existing single-use cards and replaces the requirements for financial purposes and non-financial purposes. Describes a versatile card that can meet both of the requirements of Versatile cards use a conventional data link for the connection between the smart card and the remote service provider. The versatile card invented by Tylor is not involved in any kind of open network or cryptography.
【0006】 1996年8月5日付でMandelhaum他に付与された「多数のサービス・プロバイダと
そのリモート・インストレーションに適したスマートカード」と題する米国特許
第5,544,246号は、相異なるサービス・プロバイダが同一のスマートカードの上
に共存できるようにするスマートカードについて述べている。各サービス・プロ
バイダはスマートカードの1ユーザーとみなされ、スマートカードの発行者/所
有者によってカード上にインストールされる。各ユーザーは、ツリー状のファイ
ル構造を作らされ、パスワードファイルで保護させられる。Mandelhaumの発明は
、多用途の創出と消去を考慮に入れたスマートカードについて述べている。Mand
elhaumのスマートカードは、適当なパスワードファイルの使用によって各用途へ
のアクセスを制御する。US Pat. No. 5,544,246, issued Aug. 5, 1996 to Mandelhaum et al. Entitled "Multiple Service Providers and Smart Cards Suitable for Their Remote Installation", discloses that different service providers may have the same service provider. Describes smart cards that allow them to coexist on top of smart cards. Each service provider is considered a smart card user and is installed on the card by the smart card issuer / owner. Each user is created with a tree-like file structure and protected with a password file. The Mandelhaum invention describes a smart card that allows for versatile creation and erasure. Mand
elhaum's smart card controls access to each application through the use of an appropriate password file.
【0007】 1997年9月23日付でTaher Elgamalに付与された「安全な急送システムを使用す
る電子商取引」と題する米国特許第5,671,279号は、公開/専有鍵暗号技術を使
用する公共ネットワークを介して電子商取引を行うためのシステムについて述べ
ている。Elgamalの特許は、電子商取引を行う中でスマートカードを道具として
使用することに言及していなかったし、ディジタル証明方式の使用を通してそれ
が正しいと認められていた。安全な急送システムは、インターネットなどのオー
プン・ネットワークを介しての取引の当事者の間にセキュア・ソケット・レイヤ
(SSL)などの機密保護されたチャンネルを要求している。[0007] US Patent No. 5,671,279, issued September 23, 1997 to Taher Elgamal entitled "E-Commerce Using Secure Expedited Systems," is disclosed via a public network using public / proprietary key cryptography. Describes a system for conducting electronic commerce. Elgamal's patent did not mention the use of smart cards as a tool in conducting e-commerce, and was found to be correct through the use of digital certification schemes. Secure dispatch systems require a secure channel, such as the Secure Sockets Layer (SSL), between parties to a transaction over an open network, such as the Internet.
【0008】 1. 1998年8月4日付でFox他に付与された「安全な電子商取引のためのシステム
および方法」と題する米国特許第5,790,677号は、後に取引プロセスが続く登録
システムをを有するシステムおよび方法について述べている。登録段階の間に、
取引関係者は各々、信託された信用状結合サーバーに登録パケットを送ることに
よってそのサーバーに登録する。サーバーは、受け取ったリクエストに基づいて
独自の信用状を作成し、これをリクエスト発信人に送る。取引段階の間に、取引
リクエストの発信人は、商業文書および/または証券の受取人と目される人全員
の信用状を受け取り、照合確認し、個々の受取人の公開鍵を使って文書および/
または証券を暗号化する。こうして、受取側は各々、自分だけに向けられた情報
を解読し、アクセスすることができる。Foxの特許が述べているのは、大手の金
融会社とソフトウェア会社数社が、ディジタル証明書と認証局をベースとした電
子商取引システムを確立すべく努力した目下の成果であるいわゆる"セキュア・
エレクトロニック・トランザクション"(SET)規格のテーマを反映するプロセス
である。1. US Pat. No. 5,790,677, issued to Fox et al. On Aug. 4, 1998, entitled "Systems and Methods for Secure Electronic Commerce," describes a system having a registration system followed by a transaction process. And methods. During the registration phase,
Each of the business associates registers with the trusted letter of credit by sending a registration packet to that server. The server creates its own letter of credit based on the received request and sends it to the requestor. During the transaction phase, the originator of the transaction request receives and verifies the letters of credit of all prospective recipients of the commercial document and / or securities and uses the individual recipient's public key to send the document and /
Or encrypt the security. In this way, each of the recipients can decrypt and access information intended only for them. Fox's patent states that the so-called "secure" is the result of a major financial and software company's recent efforts to establish an e-commerce system based on digital certificates and certificate authorities.
It is a process that reflects the theme of the Electronic Transactions (SET) standard.
【0009】 1998年8月18日付でDerek L. Davisに付与された「機密保護された通信を提供
するための装置および方法」と題する米国特許第5,796,840号は、後続のメッセ
ージ認証とデータ通信に使用すべきデバイス特定の鍵対を作成できる半導体デバ
イスについて述べている。半導体デバイスは、2つの通信側の認証を確実にする
ために公開/専有鍵暗号方式を使用する。US Pat. No. 5,796,840, issued to Derek L. Davis on Aug. 18, 1998, entitled "Apparatus and Method for Providing Secure Communication", describes a method for subsequent message authentication and data communication. Describes a semiconductor device capable of creating a device-specific key pair to be used. Semiconductor devices use public / proprietary key cryptography to ensure authentication of the two communicating parties.
【0010】 1996年7月9日付でSimon G. LaingおよびP. Bowcockに付与された「スマートカ
ードの安全な分散個人化のための方法およびシステム」と題する米国特許第5,53
4,857号は、スマートカードの発行者が遠隔地にいる顧客のスマートカードに機
密データを安全に書き込むための方法および装置について述べている。安全な端
末と安全なコンピュータの間の暗号化データ伝送のための相互セッション鍵が、
安全なコンピュータと小売り側スマートカードの中に保存された共通鍵を使用す
ることによって作成される。[0010] US Patent No. 5,53, issued July 9, 1996 to Simon G. Laing and P. Bowcock, entitled "Method and System for Secure Distributed Personalization of Smart Cards".
No. 4,857 describes a method and apparatus for a smart card issuer to securely write sensitive data to a remote customer's smart card. A mutual session key for encrypted data transmission between the secure terminal and the secure computer,
Created by using a secret key stored on a secure computer and a retail smart card.
【0011】 上に挙げた発明から、安全な電子商取引システムのアーキテクチャは、公開鍵
インフラストラクチャおよびこれと結び付いたディジタル証明書認証局を包含す
ることが明らかである。From the above-listed inventions, it is clear that the architecture of a secure e-commerce system includes a public key infrastructure and an associated digital certificate authority.
【0012】 オープン・ネットワークでは、秘密鍵ベースのシステムは、鍵分配および鍵管
理の点で融通性を欠き、不正な攻撃を受けやすい。他方、公開/専有鍵ベースの
システムは、取引当事者を互いに認証し合う独自の予防的なタスクを有し、あら
ゆる点で秘密鍵ベースのシステムより有利である。本発明が提示するのは、これ
らのシステムおよび方法に取って代わる、認証局やディジタル証明書を必要とし
ない別のシステムおよび方法である。本発明は、電子取引のためのハイブリッド
システムである。ハイブリッドシステムは、公開/専有鍵を鍵交換段階の間に使
用し、セッション鍵を取引段階の間に秘密鍵として使用する。In open networks, private key based systems lack versatility in key distribution and key management, and are susceptible to fraudulent attacks. Public / private key-based systems, on the other hand, have their own preventive tasks of authenticating trading parties to one another, and are in every way advantageous over private key-based systems. The present invention provides another system and method that replaces these systems and methods and does not require a certificate authority or digital certificate. The present invention is a hybrid system for electronic trading. Hybrid systems use public / private keys during the key exchange phase and use session keys as secret keys during the transaction phase.
【0013】 発明の概要 本発明は、スマートカードまたは等価のソフトウェアの形の電子カード(EC)
の使用と、通信網を介しての通信によって電子商取引を行うための暗号システム
および暗号法に関するものである。SUMMARY OF THE INVENTION The present invention relates to an electronic card (EC) in the form of a smart card or equivalent software.
And a cryptographic system and cryptography for conducting electronic commerce by communication over a communication network.
【0014】 本発明の優先実施例は、インターネットなどのオープン・ネットワークを使用
する。本発明の別の実施例は、別の種類のネットワークを使用してよい。本発明
の一実施例は、物理的なスマートカード(smart card)を使用しても、あるいは
、コンピュータソフトウェアパッケージとして実現させられ、パーソナルコンピ
ュータ(PC)などの計算デバイスの上を走るスマートカードを使用してもよい。
同様に、取引に関与したマーチャントが、ポイントオブセールス端末であるマー
チャント・デバイスを使用しても、ECおよびサービス・プロバイダと通信するの
にホストコンピュータ上のソフトウェアを使用するデバイスを使用してもよい。
スマートカードを使用する時は、カードをホストデバイス、例えばネットワーク
・レディ・マーチャント端末、PC、またはスマートカード取引をサポートできる
他の何らかの電子デバイスと通信させるのにスマートカード・リーダーも必要と
なる。A preferred embodiment of the present invention uses an open network such as the Internet. Other embodiments of the present invention may use other types of networks. One embodiment of the present invention uses a physical smart card or uses a smart card implemented on a computing device, such as a personal computer (PC), implemented as a computer software package. May be.
Similarly, the merchant involved in the transaction may use a merchant device that is a point-of-sale terminal or may use a device that uses software on the host computer to communicate with the EC and service provider .
When using a smart card, a smart card reader is also required to communicate the card with a host device, such as a network ready merchant terminal, a PC, or some other electronic device capable of supporting smart card transactions.
【0015】 公開鍵とディジタル証明書をベースとしたシステムでは、取引関係者が、認証
局(certificate authority)(CA)または信用状結合サーバーによって発行、証
明されるディジタル証明書または他の電子信用状の使用を通じて公開情報を交換
する。CAまたはサーバーと各取引関係者の間の通信は安全でなければならない。
関係者の間で転送されたメッセージの正当性と有効性を確実にするために乱数と
ディジタル署名が使用される。[0015] In systems based on public keys and digital certificates, the parties involved are issued a digital certificate or other electronic credential issued and certified by a certificate authority (CA) or certificate binding server. Exchange public information through the use of. Communication between the CA or server and each trading partner must be secure.
Random numbers and digital signatures are used to ensure the legitimacy and validity of messages transferred between parties.
【0016】 本発明の優先実施例の暗号システムと暗号法も、公開(public)/専有(priva
te)鍵暗号を使用するが、働き方は多少異なる。暗号システムと暗号法は、ディ
ジタル証明書の保有者と認証局の間に存在するのと別の種類の信託関係を作ろう
とはしない。それが特に標的としているのは、会員制をベースとした金融機関、
例えば大手クレジットカード会社とそのすべてのカード保有者、または大銀行と
その潜在利用者であるATMカード保有者などである。非金融機関も、この暗号シ
ステムと暗号法を使って、ネットワーク経由で商取引または非金融取引を行うこ
とができる。The encryption system and encryption method of the preferred embodiment of the present invention are also public / private.
te) Key encryption is used, but the working style is slightly different. Cryptographic systems and cryptography do not seek to create another kind of trust relationship than exists between a digital certificate holder and a certificate authority. It specifically targets financial institutions based on membership,
For example, a major credit card company and all its cardholders, or a large bank and its potential users, ATM cardholders. Non-financial institutions can also use this cryptosystem and cryptography to conduct commercial or non-financial transactions over a network.
【0017】 サービスプロバイダ(SP)は、何らかのサービスをその会員に提供する。金融
機関は、まさしく一種のサービスプロバイダである。サービスプロバイダは、性
格において非金融ということもあり得る。サービスプロバイダが金融機関である
か非金融機関であるかに関係なく、本質的に同じプロセスが進行する。金融機関
の関わる取引と非金融機関の関わる取引の間の唯一の違いは、メッセージに含ま
れる可能性のあるデータフィールドが異なるということである。A service provider (SP) provides some service to its members. Financial institutions are just a kind of service provider. Service providers can be non-financial in nature. Essentially the same process proceeds whether the service provider is a financial or non-financial institution. The only difference between a transaction involving a financial institution and a transaction involving a non-financial institution is that the data fields that may be included in the message are different.
【0018】 EC保有者がサービスプロバイダのひとつと契約すると、サービスプロバイダは
、EC上に専用エントリを作成する。各エントリは、サービスプロバイダに関する
取引勘定情報、SP公開鍵、アクセス制御情報およびその他の関連データを包含す
る。各ECは、このようなエントリを所定の個数(例えば10個)サポートすること
ができ、その各々のエントリが1つのサービスプロバイダを表す。When an EC holder contracts with one of the service providers, the service provider creates a dedicated entry on the EC. Each entry contains transaction account information, SP public key, access control information and other relevant data for the service provider. Each EC can support a predetermined number (eg, 10) of such entries, each of which represents one service provider.
【0019】 公開/専有鍵暗号方式を使用することにより、鍵分配プロセスは大いに単純化
される。EC保有者自身または信託された第三者、例えば銀行支店、または郵便局
さえ、タスクを実行することができる。SP公開鍵は、SPとカード保有者の間の最
初の鍵交換にしか使用されない。最初の鍵交換の後、SPは、その先のカード保有
者とSPの間またはカード保有者相互間のメッセージ交換を保護するセッション鍵
を割り当てる。By using public / private key cryptography, the key distribution process is greatly simplified. The EC holder itself or a trusted third party, such as a bank branch, or even a post office, can perform the task. The SP public key is used only for the initial key exchange between the SP and the cardholder. After the initial key exchange, the SP assigns a session key that protects the message exchange between the subsequent cardholder and the SP or between the cardholders.
【0020】 この公開/専有鍵暗号方式と秘密鍵(すなわちセッション(session)鍵)暗号
方式の両方を使用するハイブリッドシステムは、他の秘密鍵システムと対照的で
ある。ハイブリッドシステムでは、秘密鍵(すなわちセッション鍵)は単一のセ
ッションに対して有効であり、他のセッションには適用できない。セッションは
特定の時間的長さを有する。セッションは、時間周期に基づいて終わっても、満
たされている条件に基づいて終わってもよい。A hybrid system that uses both public / private key cryptography and a secret key (or session key) cryptography is in contrast to other private key systems. In a hybrid system, the secret key (ie, session key) is valid for a single session and cannot be applied to other sessions. A session has a specific length of time. A session may end based on a time period or based on a condition being met.
【0021】 マーチャントが取引に関わった場合、マーチャントは、本質的にSPと通信する
EC保有者と同じ手順を踏む。マーチャントは、先ずSPと鍵交換を行い、セッショ
ン鍵を受け取ることになる。セッション鍵は、マーチャントによってその後のSP
とに通信に使用されることになる。カード保有者とマーチャントは、SPに向かう
各メッセージにディジタルで署名し、SPも同様に、カード保有者とマーチャント
に戻る応答メッセージに署名する。When a merchant is involved in a transaction, the merchant essentially communicates with the SP
Follow the same steps as EC holders. The merchant first exchanges keys with the SP and receives a session key. The session key is used by the merchant for subsequent SP
And will be used for communication. The cardholder and the merchant digitally sign each message destined for the SP, and the SP similarly signs a response message back to the cardholder and the merchant.
【0022】 取引が別の証明書ベースのシステムとの対話を要求する場合、SPは、最初の鍵
交換に続く情報交換に基づいてカード保有者とマーチャントを認証した後、カー
ド保有者とマーチャントのための代理証明者として働くことができる。最も極端
な場合、SPは、単にこの代理の役割だけを果たし、証明書ベースのシステムのた
めのゲートウェイ(gateway)になる。この階層のタイプは、多重システムの中で
取引を行うのに必要とされる信託関係の数を減らすので、大いに望ましい。加え
て、これは、ユーザーが証明書を携える必要性を無くす。If the transaction requires interaction with another certificate-based system, the SP authenticates the cardholder and the merchant based on the information exchange following the initial key exchange, and then Can work as a proxy certifier for In the most extreme case, the SP simply plays this role and becomes a gateway for certificate-based systems. This type of hierarchy is highly desirable because it reduces the number of trust relationships required to conduct transactions in a multiplex system. In addition, this eliminates the need for the user to carry the certificate.
【0023】 詳細な説明 本発明は、スマートカードまたは等価のソフトウェアの形の電子カード(EC)
の使用と、通信網を介しての通信によって電子商取引を行うための暗号システム
および暗号法に関するものである。DETAILED DESCRIPTION The present invention relates to an electronic card (EC) in the form of a smart card or equivalent software.
And a cryptographic system and cryptography for conducting electronic commerce by communication over a communication network.
【0024】 本発明の優先実施例では、ネットワークはインターネットなどのオープン・ネ
ットワークである。本発明の別の実施例では、サービスプロバイダとその会員の
間の通信を確立するのに別のオープン・ネットワークおよび/またはクローズド
・ネットワークを使用してよい。例えば、サービスプロバイダは、その会員との
通信に独自の所有権を主張できる金融ネットワークを使用してよい。In a preferred embodiment of the invention, the network is an open network such as the Internet. In another embodiment of the invention, another open and / or closed network may be used to establish communication between the service provider and its members. For example, a service provider may use a financial network that can claim its own ownership of communications with its members.
【0025】 インターネット接続には、どんなインターネット・プロトコルも使用してよい
。使用できるプロトコルは、例えばTCP/IP、UDP、HTTP等々である。[0025] The Internet connection may use any Internet protocol. Protocols that can be used are, for example, TCP / IP, UDP, HTTP and the like.
【0026】 通信は、通信網トランスポートサービス、例えば、伝統的なアナログ音声電話
サービス(プレイン・オールド・テレフォン・サービスまたはPOTSとして知られ
ている通りの)またはT-1、E1、DS-3データ回路などのディジタル通信サービス
を使用する加入電話回線(PSTN)、ディジタル総合サービス網(ISDN)、ディジ
タル加入者回線(DSL)サービス、または無線サービスさえ使用するディジタル
加入者回線等々を経由してよい。このようなサービスを使用すれば、本発明の実
施例は、通信プロトコルに関係なく(すなわち電気インタフェース層において)
実現できる。The communication may be over a network transport service, such as a traditional analog voice telephone service (as known as a plain old telephone service or POTS) or T-1, E1, DS-3 data. It may be via a subscriber telephone line (PSTN) using digital communication services such as circuits, an integrated services digital network (ISDN), a digital subscriber line (DSL) service, or even a digital subscriber line using even wireless services. With such a service, embodiments of the present invention can operate independently of the communication protocol (ie, at the electrical interface layer).
realizable.
【0027】 通信はまた、ローカル・エリア・ネットワーク(LAN)またはワイド・エリア
・ネットワーク(WAN)、例えばイーサネット、トークン・リング、FDDI、ATM等
々を経由してもよい。使用できるプロトコルは、例えばTCP/IP、IPX、OSI等々で
ある。Communication may also be over a local area network (LAN) or wide area network (WAN), such as Ethernet, Token Ring, FDDI, ATM, and so on. Protocols that can be used are, for example, TCP / IP, IPX, OSI, and the like.
【0028】 他の通信リンクとして考えられるのは、光接続、無線RFモデム接続、セルラ・
モデム接続、サテライト接続等々である。Other possible communication links include optical connections, wireless RF modem connections, cellular
Modem connection, satellite connection, etc.
【0029】 本発明は、サービスプロバイダとその会員の間に通信パスは確立できる限り、
採用してよい。上の例は、本発明が実践できるさまざまな通信環境のいくつかの
例を示す目的で挙げたものである。当業者には明らかな通り、本発明は、上に挙
げた環境に制限されるものでない。According to the present invention, as long as a communication path can be established between a service provider and its members,
May be adopted. The above examples are provided to illustrate some of the various communication environments in which the invention may be practiced. As will be apparent to those skilled in the art, the present invention is not limited to the environments listed above.
【0030】 電子カード(EC)は、パーソナルコンピュータ(PC)などのコンピュータシス
テムの上を走るスマートカードデバイスまたはソフトウェアパッケージの形を取
ることができる。ECがスマートカード上で実現した場合、これは、PCなどのネッ
トワーク・レディ・コンピュータシステムにおいて別の会員および/または選択
されたサービスプロバイダとの取引に使用することができる。コンピュータシス
テムやインターネット・ブラウザなどのアプリケーション・ソフトウェアと通信
し、カード保有者やネットワークとのインタフェースを作るためには、読み書き
インタフェースデバイスが必要となる。ECがコンピュータシステムにロードされ
たソフトウェア・パッケージである場合には、読み書きインタフェースが必要と
されない。本発明の実施例は、ECが現実の財布と同様の機能を果たす電子ウォレ
ット(またはサイバー・ウォレット)として働くことを見込んでいる。現実の財
布は、クレジットカード、デビットカード、ATMカード、診察カード、会員カー
ド、現金などを入れることができる。ECは、上に挙げた金融機関と非金融機関の
すべてのディジタル等価物を有し、インターネットを介して安全な取引を実行で
きるようにする。An electronic card (EC) can take the form of a smart card device or a software package running on a computer system such as a personal computer (PC). If the EC is implemented on a smart card, it can be used for transactions with another member and / or a selected service provider on a network ready computer system such as a PC. A read / write interface device is needed to communicate with application software such as computer systems and Internet browsers and to interface with cardholders and networks. If the EC is a software package loaded on a computer system, no read / write interface is required. Embodiments of the present invention contemplate that the EC acts as an electronic wallet (or cyber wallet) that performs similar functions as a real wallet. Real wallets can hold credit cards, debit cards, ATM cards, consultation cards, membership cards, cash, etc. The EC has all the digital equivalents of the financial institutions and non-financial institutions listed above, enabling it to conduct secure transactions over the Internet.
【0031】 サービスプロバイダの会員は、マーチャントおよび/またはECカード保有者で
あり得る。マーチャントは、取引の結果としてサービスプロバイダから支払いを
受ける会員である。会員は、マーチャントとEカード保有者の両方であり得る。
マーチャントは、他のカード保有者との取引に加わってよく、その結果、サービ
スプロバイダから支払いを受けるマーチャントとなる。マーチャントはまた、EC
カード保有者であってよく、例えばマーチャントサプライヤからの供給品を購入
してよい。The service provider member may be a merchant and / or an EC card holder. A merchant is a member that receives payment from a service provider as a result of a transaction. Members can be both merchants and e-card holders.
The merchant may participate in transactions with other cardholders, resulting in the merchant being paid by the service provider. Merchants are also EC
It may be a cardholder, for example, purchasing supplies from a merchant supplier.
【0032】 暗号システムは、サービスプロバイダとその会員(どれだけの人数であっても
)の間の通信に関わってよい。従って、ECとSPの間、マーチャントとSPの間、第
1のECと第2のECとSPの間、第1のマーチャントと第2のマーチャントとSPの間等々
で通信が可能である。ECは、例えば取引勘定残高について照会するためにサービ
スプロバイダと直接通信してよい。マーチャントがサービスプロバイダと通して
してよいのは、彼自身のためだけに限られ、ECに代わってしてはならない。なぜ
なら、マーチャントが知りたいのは、彼自身のサービスプロバイダとの取引の勘
定残高だからである。SPとその会員の間の通信は、SPとその会員のどんな変更に
も従ってよい。SPとその会員の間の通信リンクの編成は、順次編成であっても階
層編成であってもよい。SPとその会員の間の通信はまた、SPとその会員の間のメ
ッセージのルートを決めるルータを経由してもよい。A cryptographic system may involve communication between a service provider and its members (no matter how many). Therefore, between EC and SP, between merchant and SP,
Communication is possible between the first EC and the second EC and the SP, between the first merchant and the second merchant and the SP, and so on. The EC may, for example, communicate directly with the service provider to query for transaction account balances. The merchant may communicate with the service provider only for himself and not on behalf of the EC. That's because the merchant wants to know his account balance with the service provider. Communication between the SP and its members may follow any changes in SP and its members. The organization of the communication links between the SP and its members may be sequential or hierarchical. Communication between the SP and its members may also be via a router that routes messages between the SP and its members.
【0033】 暗号法は、2段階式の鍵交換取引の一モデルである。第1段階が鍵交換段階であ
る。第2段階が取引段階である。鍵交換段階において、会員はサービスプロバイ
ダと鍵を交換する。会員は自分の鍵をサービスプロバイダに送り、サービスプロ
バイダは、その鍵を使ってセッション鍵を会員に送る。セッション鍵は、その先
のカード保有者とSPの間またはカード保有者相互間のメッセージ交換を保護する
働きをする。取引段階では、SPが取引を指導するか、カード保有者が自ら取引を
行うか、どちらかができる。Cryptography is a model of a two-stage key exchange transaction. The first stage is the key exchange stage. The second stage is the trading stage. In the key exchange phase, the member exchanges keys with the service provider. The member sends his key to the service provider, and the service provider uses the key to send a session key to the member. The session key serves to protect the message exchange between the subsequent cardholder and the SP or between the cardholders. At the transaction stage, the SP can guide the transaction, or the cardholder can do the transaction himself.
【0034】 図1は、本発明の実施例による、カード保有者、マーチャントおよびサービス
プロバイダを含むシステムのコンポーネント相互間の関係を示すブロック図であ
る。FIG. 1 is a block diagram illustrating the relationships between components of a system including a cardholder, a merchant, and a service provider, according to an embodiment of the present invention.
【0035】 ECカード保有者20は、ネットワーク50を介して取引を行い、発信コンピュータ
84に取り付けられたEC読み書きデバイス82か、発信コンピュータユニット90の上
を走るEC等価ソフトウェア92かどちらかを使用することによってマーチャントと
通信することができる。The EC card holder 20 makes a transaction via the network 50 and
Communicating with the merchant can be accomplished by using either an EC read / write device 82 attached to 84 or an EC equivalent software 92 running on the originating computer unit 90.
【0036】 マーチャントは、インターネットなどのネットワーク50を介して、ネットワー
ク・レディ・ポイントオブセールス(POS)端末40か、マーチャントデバイス70
の上を走るEC等価ソフトウェア92かどちらかを使用することによって、選択され
たサービスプロバイダ60と電子取引を行うことができる。The merchant can access the network ready point of sales (POS) terminal 40 or the merchant device 70 via a network 50 such as the Internet.
Electronic transactions can be made with the selected service provider 60 by using either EC-equivalent software 92 running on the Internet.
【0037】 カードへのアクセス条件が満たされたならば、カード保有者は、ネットワーク
50を介してシステムの他の関係者と金融機関または非金融機関を行うことができ
る。図1には、ネットワークを介して取引を行うことのできる三通りのシナリオ
が示してある。 (1)POS取引(図1の左上側)において、カード保有者20は、ECをマーチャン
ト店内でマーチャントのEC読み書き装置30に通す/差し込む。EC読み書き装置30
は、ネットワーク・レディ・マーチャントPOS端末40に接続してある。ネットワ
ーク・レディ・マーチャントPOS端末40は、キーボードなどの入力装置、ディス
プレイ装置、処理装置およびEC読み書き装置30(ECインタフェースデバイス)か
らなる安全な、不正使用のできないプログラマブルデバイスである。その代表的
なのが、オープン・ネットワークへの通信リンクを備えたPCなどの小型コンピュ
ータユニットである。POS端末は、ネットワーク50経由でSPと通信する。Once the conditions for accessing the card have been met, the cardholder may
A financial institution or a non-financial institution with 50 other parties in the system can be made. FIG. 1 shows three scenarios in which transactions can be performed via a network. (1) In a POS transaction (upper left of FIG. 1), the cardholder 20 passes / inserts the EC into the merchant's EC reading / writing device 30 in the merchant store. EC read / write device 30
Is connected to the network ready merchant POS terminal 40. The network ready merchant POS terminal 40 is a secure, non-illegal programmable device including an input device such as a keyboard, a display device, a processing device, and an EC read / write device 30 (EC interface device). A typical example is a small computer unit such as a PC having a communication link to an open network. The POS terminal communicates with the SP via the network 50.
【0038】 (2)(図1の右側)カード保有者は、発信コンピュータであるカード保有者の
パーソナルコンピュータ84に接続された読み書き装置82にEC20を差し込むことに
よってシステムの他の関係者と取引を行うことができる。発信コンピュータは、
ネットワーク50につながって、ECをマーチャント・コンピュータユニット70と通
信できるようにする。マーチャント・コンピュータユニット70は、マーチャント
がECの発信したメッセージを受け取り、EC情報とマーチャント情報を組み合わせ
るメッセージを発信できるようにするEC等価ソフトウェア72を有する。(2) (right side of FIG. 1) The cardholder engages in transactions with other parties in the system by inserting the EC20 into a read / write device 82 connected to the cardholder's personal computer 84 which is the originating computer. It can be carried out. The originating computer is
Connect to the network 50 to allow the EC to communicate with the merchant computer unit 70. The merchant computer unit 70 has EC equivalent software 72 that allows the merchant to receive messages sent by the EC and send messages that combine the EC information with the merchant information.
【0039】 (3)(図1の下側)カード保有者は、自分のコンピュータユニット90において
EC等価ソフトウェア92を使用することによってシステムの他の関係者と取引を行
うことができる。取引は、発信コンピュータユニット90、すなわちカード保有者
のパーソナルコンピュータのところで始まる。カード保有者は、ネットワーク50
を介して取引を行い、マーチャント・コンピュータユニット70と通信し、マーチ
ャント・コンピュータユニット70の方は、ネットワーク50を介してSP60と通信す
る。(3) (Lower side of FIG. 1) The card holder uses his / her computer unit 90
By using the EC equivalent software 92, transactions with other parties in the system can be made. The transaction begins at the originating computer unit 90, the cardholder's personal computer. Cardholders need network 50
And communicates with the merchant computer unit 70, which communicates with the SP 60 via the network 50.
【0040】 本発明の優先実施例では、EC等価ソフトウェアを保持するのにパーソナルコン
ピュータを使用しているが、本発明の別の実施例では、EC等価ソフトウェアを保
持するのに別の電子装置を使用することができる。Although the preferred embodiment of the present invention uses a personal computer to hold the EC equivalent software, another embodiment of the present invention uses another electronic device to hold the EC equivalent software. Can be used.
【0041】 本発明の優先実施例では、ECをマーチャントと通信できるようにするのに使用
されたネットワークは、マーチャントをSPと通信できるようにするのに使用され
たのと同じネットワークである。別の実施例では、ECをマーチャントと通信でき
るようにするのに使用されたネットワークは、マーチャントをSPと通信できるよ
うにするのに使用されたのと同じネットワークであってはならない。さらに別の
実施例では、あるマーチャントをSPと通信できるようにするのに使用されたネッ
トワークは、別のマーチャントをSPと通信できるようにするのに使用されたネッ
トワークと同じであってはならない。さらにまた別の実施例では、あるECをマー
チャントと通信できるようにするのに使用されたネットワークは、別のECを別の
マーチャントと通信できるようにするのに使用されたネットワークと同じであっ
てはならない。一実施例として、ネットワークが多重構造をなし、それで関係者
が相異なる経路で通信できるようになっていてよい。In a preferred embodiment of the present invention, the network used to enable the EC to communicate with the merchant is the same network used to enable the merchant to communicate with the SP. In another embodiment, the network used to enable the EC to communicate with the merchant must not be the same network used to enable the merchant to communicate with the SP. In yet another embodiment, the network used to enable one merchant to communicate with the SP must not be the same network used to enable another merchant to communicate with the SP. In yet another embodiment, the network used to enable one EC to communicate with a merchant is the same network used to enable another EC to communicate with another merchant. Must not. In one embodiment, the network may have a multiplex structure so that parties can communicate over different paths.
【0042】 本発明の優先実施例では、取引が2つの段階に分割してある。鍵交換段階と取
引段階である。図2は特殊なケースで、SPが取引段階を指導する2段階式の鍵交換
取引のモデルを示す。SPが取引段階を指導する時、関係者間で感知可能な情報の
直接交換は行われない。In a preferred embodiment of the invention, the transaction is divided into two stages. The key exchange phase and the transaction phase. Figure 2 shows a special case, a two-step key exchange model where the SP guides the transaction stages. When the SP guides the trading stage, there is no direct exchange of perceptible information between the parties.
【0043】 鍵交換段階は、取引段階がカード保有者同士の間で行われる場合も、SPが取引
段階を指導する場合も、同じである。取引段階がカード保有者同士の間で行われ
る場合、カード保有者は、SPセッション鍵を使って互いに通信し、取引を行う。The key exchange step is the same whether the transaction step is performed between cardholders or the SP guides the transaction step. If the transaction phase occurs between cardholders, the cardholders communicate with each other using the SP session key to conduct the transaction.
【0044】 図2は、SPが取引段階を指導する場合の金融取引を示す。ここに示す取引には
三者が関わる。EC(取引発信者)102、マーチャント104、そして、サービスプロ
バイダ(SP)106である。発信者は、消費者であるECカード保有者で、コンピュ
ータユニット102によって表される。コンピュータユニット104はマーチャントを
表す。コンピュータユニット106はサービスプロバイダを表す。SPは、ECとマー
チャントの両方によって選択される。FIG. 2 shows a financial transaction when the SP guides the transaction phase. The transaction shown here involves three parties. An EC (transaction sender) 102, a merchant 104, and a service provider (SP) 106. The originator is the consumer, the EC cardholder, represented by computer unit 102. Computer unit 104 represents a merchant. Computer unit 106 represents a service provider. SPs are selected by both ECs and merchants.
【0045】 図2は、プロセスフローがECからマーチャント、SPに向かう金融取引を示す。
暗号法のプロセスフローは、マーチャントとECカード保有者の間のどんな特別な
順序にも制限されない。図2は、プロセスがECからマーチャント、サービスプロ
バイダに向かう特別な取引の単なる一例にすぎない。プロセスはまた、マーチャ
ントからEC、サービスプロバイダに向かうこともあり得る。図2は、サービスプ
ロバイダの会員(この場合にはECカード保有者とマーチャント)がどのようにメ
ッセージを作成し、添付し、サービスプロバイダに送るかを示す。FIG. 2 shows a financial transaction in which the process flow goes from EC to merchant, SP.
The cryptographic process flow is not restricted to any special order between the merchant and the EC cardholder. Figure 2 is just one example of a special transaction where the process goes from EC to merchant and service provider. The process could also go from merchant to EC, service provider. FIG. 2 shows how service provider members (in this case, EC cardholders and merchants) create, attach, and send messages to the service provider.
【0046】 図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が、鍵交換段階における主
要活動を締めくくる。In FIG. 2, the ten arrows numbered 1 to 10 indicate how the message flows between the three parties during the two trading phases. Steps 1-4 belong to the key exchange phase, and steps 5-10 belong to the transaction phase. In FIG. 2, the merchant acts as an intermediary between EC and SP. In step 1, the key exchange request is formatted by the EC and sent to the merchant. In step 2, the merchant combines his key exchange message with the EC key exchange message and sends the combined key exchange message to the SP. In step 3, the SP formats the key exchange response for the merchant, formats the key exchange response for the EC,
The two key exchange responses are combined to form one composite key exchange response, and the combined key exchange response is sent to the merchant. In step 4, the merchant separates the key exchange response for the merchant from the key exchange response for the EC,
The key exchange response message of EC to EC. Step 4 concludes the key activities in the key exchange phase.
【0047】 取引段階はステップ5で始まる。ステップ5において、ECは、その取引リクエス
トメッセージをフォーマットし、これをマーチャントに送る。ステップ6におい
て、マーチャントは、受け取った取引リクエストメッセージを自身の取引リクエ
ストメッセージと組み合わせ、この組み合わせた取引リクエストメッセージをSP
に送る。ステップ7において、SPは、マーチャントのための取引応答メッセージ
をフォーマットし、ECのための取引応答メッセージをフォーマットし、両方の取
引応答メッセージを組み合わせ、この組み合わせた取引応答メッセージをマーチ
ャントに送り返す。ステップ8において、マーチャントは、マーチャントのため
の取引応答メッセージをECのための取引応答メッセージから切り離し、ECの取引
応答メッセージをECに転送する。ステップ9において、ECは確認メッセージをフ
ォーマットし、これをマーチャントに送る。ステップ10において、マーチャント
は、受け取った確認メッセージを自身の確認メッセージと組み合わせ、この組み
合わせた確認メッセージをSPに送る。ステップ10が、1つの取引の取引段階を締
めくくる。The trading phase begins with step 5. In step 5, the EC formats the trade request message and sends it to the merchant. In step 6, the merchant combines the received trade request message with his own trade request message and sends the combined trade request message to the SP.
Send to In step 7, the SP formats the transaction response message for the merchant, formats the transaction response message for the EC, combines both transaction response messages, and sends the combined transaction response message back to the merchant. In step 8, the merchant disconnects the transaction response message for the merchant from the transaction response message for the EC, and forwards the transaction response message of the EC to the EC. In step 9, the EC formats the confirmation message and sends it to the merchant. In step 10, the merchant combines the received confirmation message with his own confirmation message and sends the combined confirmation message to the SP. Step 10 concludes the transaction phase of one transaction.
【0048】 図2が示すのは単純な取引であるが、取引によっては多重メッセージを伴うも
のがいくつかある。取引の間、各段階を完成させるのに2つ以上のメッセージが
要求されるケースもあり、その場合、かかるメッセージは同じルールに従って組
み合わされ、送られることになる。例えば取引段階の間、ECとマーチャントが先
ず最初に取引勘定情報を送ることをSPは要求してよい。取引勘定情報が有効であ
ることが照合確認されると、SPは、取引勘定情報確認の旨を応答メッセージにし
て送る。マーチャントとECは、この応答メッセージを受け取ると、取引額および
その他の取引関連情報を、SPに行く次のメッセージにして送る。SPは、そこで当
該の取引を許可し、または不許可とする。図2に示すステップは、取引勘定メッ
セージと取引メッセージの両方に当てはまる。FIG. 2 shows a simple transaction, but some transactions involve multiple messages. During a transaction, more than one message may be required to complete each step, in which case such messages will be combined and sent according to the same rules. For example, during the trading phase, the SP may require that the EC and merchant send trading account information first. If the transaction account information is confirmed to be valid, the SP sends a response message stating that the transaction account information has been confirmed. When the merchant and the EC receive this response message, they send the transaction amount and other transaction-related information as the next message to go to the SP. The SP will then allow or disallow the transaction. The steps shown in FIG. 2 apply to both transaction account messages and transaction messages.
【0049】 取引の完成が何らかの外部システム、例えば公開鍵/ディジタル証明書ベース
のシステム108などとのインタラクションを要求する場合、SPは、ECとマーチャ
ントのための代理証明者として働き、ECとマーチャントの代理として外部システ
ムと対話することになる。本発明の望む結果は、取引の関係者のすべてを外部シ
ステムから遮蔽し、それで、取引を完成させるのに必要な信託関係の数を減らす
ことである。取引の関係者が本システムと外部システムの両方の会員である場合
、彼は、本システムの会員として働くか、外部システムの会員として働くか、選
択することができる。後者の場合、SPは、外部システムのルールに従って関係者
とのインタフェースを作ることになる。例えば、公開鍵/ディジタル証明書また
は信用状をベースとした外部システムと対話するために、SPは、外部システムか
ら要求される信託関係を満足させる証明書または信用状のすべてを持っている。
このような信用状がSPおよび外部システムにとって必要となるのは、ECおよびマ
ーチャントによって始められた取引を完成させるためである。この場合、SPが外
部システムと信託関係を持つだけで足りる。この信託関係に基づいて、個々のEC
とマーチャントは、仮の外部システムとの取引を完成させることができる。If completing the transaction requires interaction with some external system, such as a public key / digital certificate based system 108, the SP acts as a proxy certifier for the EC and the merchant, and You will interact with external systems on your behalf. The desired result of the present invention is to shield all of the parties to the transaction from external systems, thus reducing the number of trust relationships required to complete the transaction. If the party involved in the transaction is a member of both the system and the external system, he can choose to work as a member of the system or as a member of the external system. In the latter case, the SP will create an interface with the stakeholders according to the rules of the external system. For example, to interact with an external system based on a public key / digital certificate or letter of credit, the SP has all the certificates or letters of credit that satisfy the trust relationships required from the external system.
Such letters of credit are needed for SPs and external systems to complete transactions initiated by ECs and merchants. In this case, it is sufficient that the SP has a trust relationship with the external system. Based on this trust relationship, individual ECs
And the merchant can complete a transaction with a temporary external system.
【0050】 図3は、ECの優先実施例の図表的表現である。本発明の優先実施例では、EC内
部が、図3に示すソフトウェア/ハードウェアコンポーネントから構成されてい
る。このECは、ISO 7816をベースとしており、ISO 7816に定めるのと同じ種類の
通信プロトコルおよび通信コマンドをサポートする。FIG. 3 is a diagrammatic representation of a preferred embodiment of the EC. In the preferred embodiment of the present invention, the inside of the EC is composed of the software / hardware components shown in FIG. This EC is based on ISO 7816 and supports the same types of communication protocols and commands as specified in ISO 7816.
【0051】 ECは、ECの内部リソースを管理するカード・オペレーティングシステム550を
有する。オンカード暗号サービス650は、ソフトウェアで実現させることも、暗
号コプロセッサ(図3には示していない)、他のハードウェア解決、またはソフ
トウェアとハードウェアのハイブリッドによって提供することもできる。The EC has a card operating system 550 that manages the internal resources of the EC. The on-card cryptographic service 650 may be implemented in software, or provided by a cryptographic coprocessor (not shown in FIG. 3), another hardware solution, or a hybrid software and hardware.
【0052】 ECの特異な特徴のひとつがECメモリ内部のサービスプロバイダ・データ領域(
SPDA)で、これは、サービスプロバイダの取引勘定情報と鍵情報を包含する。サ
ービスプロバイダ・データ領域(SPDA)700は、多数のスロットを包含する。優
先実施例において、SPDAは、所定の個数(例えば10個)のスロットを包含する。
各サービスプロバイダの記録を空のスロットに入れることができる。各記録は、
特定のサービスプロバイダに関する取引勘定番号、公開鍵、およびその他の関連
情報を包含する。One of the unique features of EC is that the service provider data area (
In SPDA), this includes service provider transaction account information and key information. The service provider data area (SPDA) 700 contains a number of slots. In a preferred embodiment, the SPDA includes a predetermined number (eg, 10) of slots.
Records of each service provider can be placed in empty slots. Each record is
Includes transaction account numbers, public keys, and other relevant information for a particular service provider.
【0053】 ECの設計次第で、SPDAは、任意に各SPに、それ独自のオンカードデータを管理
し、SPカードデータとホストアプリケーションの間のインタフェースを提供する
何らかのソフトウェア(JAVAの"アプレット"のような)を含ませることができる
。換言すれば、SPDAは、まさしく単純なデータより多くのものを包含することが
でき、各SPに、それ独自のユニークなサービスをカード保有者に提供する独立言
語型アプリケーションソフトウェア(アプレットのような)をEC上に置かせるこ
とができる。この種の設計の利点は、EC自体が、提供することのできる種類のサ
ービスから今やはずされることである。別のSPがオンカードSPに取って代わるな
らば、ECプラットフォームに変更を加える必要は無くなろう。新しいSPアプレッ
トは、カードに単純にロードされ、そうするように設計されたことを実行するこ
とになろう。Depending on the design of the EC, SPDA may optionally manage each SP with some software (JAVA “applet”) that manages its own on-card data and provides an interface between the SP card data and the host application. Such as). In other words, SPDA can encompass more than just simple data, and each SP has independent language application software (such as an applet) that provides cardholders with their own unique services. Can be placed on EC. The advantage of this type of design is that the EC itself is now out of the kind of services it can offer. If another SP replaces the on-card SP, there will be no need to change the EC platform. The new SP applet would simply load onto the card and perform what it was designed to do.
【0054】 SPDAにおいて、各サービスプロバイダは、公開鍵のためのスペースは割り当て
られている。多くの取引において鍵は1対しか使用されないが、いくつかのオン
ライン取引には2対以上の鍵が必要とされる。SPが、入力メッセージと出力メッ
セージの両方の署名に同じ対の公開/専有鍵を使用する場合には、1個の公開鍵
で足りる。SPが両メッセージの署名に異なる対の鍵を使用する場合には、両方の
SP公開鍵(入力メッセージのために1個、出力メッセージのために1個)がSPDA
において必要とされる。In SPDA, each service provider has been allocated space for a public key. While many transactions use only one pair of keys, some online transactions require more than one pair of keys. If the SP uses the same pair of public / private keys for both input and output message signatures, one public key is sufficient. If the SP uses a different pair of keys to sign both messages, both
SP public key (one for input message, one for output message) is SPDA
Is required in
【0055】 本発明の優先実施例では、1対の公開/専有鍵よりむしろ2対の公開/専有鍵が
、ネットワーク経由の他のアプリケーションとの通信に使用される。それは、1
対の公開/専有鍵よりむしろ2対の公開/専有鍵の方が大きいセキュリティをも
たらすからである。一方の対が入力メッセージの解読に使用される。すなわち、
送り手が受け手の公開鍵を使ってメッセージを暗号化し、受け手が相応の専有鍵
を使ってそのメッセージを解読する。他方の対は、送り手が自身の送るメッセー
ジにディジタル署名し、受け手が相応の送り手の公開鍵を使ってディジタル署名
を照合確認するのに使用される。In a preferred embodiment of the invention, two pairs of public / private keys, rather than a pair of public / private keys, are used for communication with other applications over the network. It is 1
This is because two pairs of public / private keys provide greater security than a pair of public / private keys. One pair is used to decrypt the input message. That is,
The sender encrypts the message using the recipient's public key, and the recipient decrypts the message using the appropriate private key. The other pair is used by the sender to digitally sign the message he sends and the receiver to verify the digital signature using the corresponding sender's public key.
【0056】 各サービスプロバイダは、サービスプロバイダによって使用される公開鍵の数
に対してスペースが割り当てられる。SPが、入力メッセージと出力メッセージの
両方の署名に同じ対の公開/専有鍵を使用する場合には、1個の公開鍵で足りる
。SPが両メッセージの受け取りと署名に異なる対の鍵を使用する場合には、両方
のSP公開鍵がSPDAにおいて必要とされる。Each service provider is allocated space for the number of public keys used by the service provider. If the SP uses the same pair of public / private keys for both input and output message signatures, one public key is sufficient. If the SP uses a different pair of keys for receiving and signing both messages, both SP public keys are required in SPDA.
【0057】 本発明の別の実施例では、2対以上の公開/専有鍵が、大きいセキュリティを
得るためにサービスプロバイダによって要求、使用される。In another embodiment of the present invention, two or more pairs of public / private keys are requested and used by the service provider for greater security.
【0058】 ECカードが新しい金融機関または非金融機関から発行される時、発行機関また
は信託された第三者は、記録からなる必要な情報を使用可能なスロットにロード
することになる。スロットの中の情報は、サービスプロバイダの取引勘定が閉じ
られる時に消去することができる。スロットの中の情報のいくつか、例えば取引
勘定残高は、取引の間に読み出し、修正することができる。取引勘定番号などい
くつかの情報は、書き込み禁止となっているが、読み出すことはできる。専有鍵
などいくつかの情報は、読み出し書き込み両方とも禁止となっている。アクセス
条件600は、ECユーザーがカードを使用にあたってオープンにするために、また
はカードに保存された情報にアクセスするために提示しなければならないPIN、
バイオメトリックデータなどのセキュリティ情報を包含する。When an EC card is issued from a new financial or non-financial institution, the issuing institution or a trusted third party will load the necessary information, consisting of records, into available slots. The information in the slot can be deleted when the service provider's transaction account is closed. Some of the information in the slots, such as the transaction account balance, can be read out and modified during the transaction. Some information, such as transaction account numbers, is write-protected but can be read. Some information such as a private key is prohibited from both reading and writing. The access condition 600 is a PIN that must be presented by the EC user to open the card for use or to access the information stored on the card,
Includes security information such as biometric data.
【0059】 伝統的な個人識別番号(PIN)またはバイオメトリックデータなど他のセキュ
リティ情報が、ECを保護するのに使用される。バイオメトリックデータには、カ
ード保有者の生物学的特徴、身体的特徴、行動的特徴などが含まれる。バイオメ
トリックシステムで測定できるのは、個々人の指紋、手の大きさ、手書き文字、
顔面の外見、話し方、身体動作、キーボードのタイピングのリズム、眼の特徴、
息づかい、体臭、DNA、または他の身体的属性などである。ECによってもたらさ
れ機能は、アクセス条件が満たされた後でしか活動化できない。カード上に存す
る各サービスプロバイダは、任意に他のアクセス条件を実現させることができる
。[0059] Other security information, such as traditional personal identification numbers (PINs) or biometric data, are used to secure ECs. The biometric data includes the cardholder's biological characteristics, physical characteristics, and behavioral characteristics. The biometric system can measure individual fingerprints, hand size, handwriting,
Facial appearance, speaking style, physical activity, keyboard typing rhythm, eye characteristics,
Such as breathing, body odor, DNA, or other physical attributes. The functions provided by the EC can only be activated after the access conditions have been met. Each service provider on the card can optionally implement other access conditions.
【0060】 図4は、本発明の優先実施例のサービスプロバイダ・データ領域のフォーマッ
トを示す。サービスプロバイダ情報の各々にエントリが割り当てられており、そ
れぞれ、追加のアクセス条件によって保護することができる。PIN 712および雑
データフィールド714は、サービスプロバイダが、そのサポートする機関に特別
な保護を付ける時に役立つ。ネームフィールド702は、サービスプロバイダの名
前を入れるところで、これをカード保有者は、オンライン取引の始めに、その取
引に適用できるサービスプロバイダを最初に選択するのに使用することができる
。鍵種類フィールド704は、秘密鍵、公開鍵などを使用する時にサービスプロバ
イダが選択する鍵の種類を指定する。鍵値フィールド706および取引勘定情報フ
ィールド708は、各サービスプロバイダに特異な情報を入れる。カード種類フィ
ールド710は、サービスプロバイダがサポートする機関の種類を指定する。FIG. 4 shows the format of the service provider data area according to the preferred embodiment of the present invention. An entry is assigned to each of the service provider information, each of which can be protected by additional access conditions. The PIN 712 and miscellaneous data fields 714 help the service provider add extra protection to its supporting institution. Name field 702 contains the name of the service provider, which can be used by the cardholder at the beginning of an online transaction to first select a service provider applicable to the transaction. The key type field 704 specifies the type of key selected by the service provider when using a private key, a public key, or the like. Key value field 706 and transaction account information field 708 contain information specific to each service provider. Card type field 710 specifies the type of institution supported by the service provider.
【0061】 本発明の優先実施例では、オンカード・オペレーティングシステム(COS)は
、カード保有者のためにいくつかの基本的サービスを提供する。以下は、COSに
よって実行することのできる一般機能のリストである。 (1)メモリ管理、タスク管理など伝統的なOS機能 (2)ユーザーデータの外部通信/読み書き機能および通信プロトコルハンド
リング (3)オンカードのカード保有者情報のローディングおよび更新 (4)ユーザーPIN変更 (5)サービスプロバイダ・データ領域の管理 − 個々のサービスプロバイダ
情報のローディングおよび更新、SPDAアクセス制御など。In a preferred embodiment of the present invention, an on-card operating system (COS) provides several basic services for cardholders. The following is a list of general functions that can be performed by the COS. (1) Traditional OS functions such as memory management and task management (2) External communication / read / write function of user data and handling of communication protocol (3) Loading and updating of card holder information of on-card (4) User PIN change ( 5) Service provider data area management-loading and updating of individual service provider information, SPDA access control, etc.
【0062】 COSはまた、取引のさまざまなステップの間にサポートを提供することになる
。例えば、COSは取引の始めにSP選択を処理し、取引が完成した時に取引データ
をログファイルに記録する。本発明の一実施例では、下記のCOSへの2つの設計ア
プローチの一方または2つの設計アプローチのハイブリッドを実現させてよい。 (1)知能のほとんどをCOSの中に入れ、それで、COSがEC機能のほとんどをサ
ポートできるようにする。その結果、オンカード・サービスプロバイダの各領域
がCOSの上にでき、マーチャントおよびSPとの取引を実行するようになる。この
アプローチでは、COSは、すべてのオンカードSPについて外側世界との均一なイ
ンタフェースをもたらし、SPが選択され次第、取引を効率よく実行することがで
きる。The COS will also provide support during various steps of the transaction. For example, the COS processes the SP selection at the beginning of the transaction and records the transaction data in a log file when the transaction is completed. In one embodiment of the present invention, a hybrid of one or two of the following two design approaches to COS may be implemented. (1) Put most of the intelligence into the COS, so that the COS can support most of the EC features. As a result, each area of the on-card service provider will be on top of the COS and will execute transactions with merchants and SPs. In this approach, the COS provides a uniform interface with the outside world for all on-card SPs, and can execute transactions efficiently once the SP is selected.
【0063】 (2)あるいは、COSは、各オンカードSPが利用できる一般サービスのプールで
あり得る。各SPデータ領域に、マーチャントおよびSPとの取引を実行する知能を
有するアプレットを入れることができる。このアプローチの方が、SPは、取引を
行う時に自身の特異な特徴を実現させる機会を多く有する。(2) Alternatively, the COS may be a pool of general services available to each on-card SP. Each SP data area may contain an applet with the intelligence to execute transactions with merchants and SPs. With this approach, SPs have more opportunities to realize their unique characteristics when conducting transactions.
【0064】 図5は、本発明の優先実施例においてディジタル署名がどのように使用される
かを示す。先ず、メッセージの送り手がメッセージM900のデータ部分を準備し、
一方向ハッシュ・アルゴリズム、H(*)902を経由して送る。ハッシュ・アルゴリ
ズムからの出力は、メッセージM903のメッセージダイジェストMDと呼ばれる。MD
は次に暗号化され、E(*)904となる。すなわち、送り手の公開鍵(Pri)を使って
ディジタル署名される。その結果は、メッセージMのディジタル署名DSと呼ばれ
る。DSは、次にオリジナルメッセージM900と組み合わされ、ネットワーク50を経
由して受け手に伝送できる状態の完全なメッセージ906を形成する。FIG. 5 shows how a digital signature is used in a preferred embodiment of the present invention. First, the message sender prepares the data part of the message M900,
Sent via a one-way hash algorithm, H (*) 902. The output from the hash algorithm is called the message digest MD of message M903. MD
Is then encrypted to E (*) 904. That is, a digital signature is performed using the sender's public key (Pri). The result is called the digital signature DS of the message M. The DS is then combined with the original message M900 to form a complete message 906 ready for transmission via network 50 to the recipient.
【0065】 公開鍵暗号化/解読機能は、多数の暗号化/解読機能のどれかであり得る。RS
Aというのは、RSAの開発者の姓(Ronald Rivest、Adi Shamir、Len Adelman)の
頭文字から取った名であるが、これこそ、本発明の実施例において使用できる公
開鍵暗号化/解読機能の一例である。The public key encryption / decryption function can be any of a number of encryption / decryption functions. RS
A is the first name of the RSA developer's last name (Ronald Rivest, Adi Shamir, Len Adelman), which is the public key encryption / decryption function that can be used in embodiments of the present invention. This is an example.
【0066】 受け手と目された者がネットワーク50からメッセージを受け取ると、彼は先ず
、メッセージM900のデータ部分を、これと組み合わされたディジタル署名912か
ら切り離す。受け手は次に、メッセージM900のデータ部分を、このメッセージM9
00のデータ部分の暗号化に使用された同じハッシュ・アルゴリズム910の中に通
し、MのメッセージダイジェストMD^911を得る。受け手は次に、ECの公開鍵を使
ってD(*)908を解読し、オリジナルメッセージに含まれたディジタル署名912を、
送り手の公開鍵を使って解読し、オリジナルメッセージダイジェスト(ここでは
MD909で示してある)を回収する。MD909は、修正のために新たに計算されたMD^9
11と比較される。両方が一致しない場合、オリジナルメッセージは、改変された
ものとみなされ、はねられる。When the prospective recipient receives the message from the network 50, he first separates the data portion of the message M900 from the digital signature 912 associated therewith. The recipient then writes the data part of message M900 to this message M9
Pass through the same hash algorithm 910 used to encrypt the data portion of 00 to get M message digest MD ^ 911. The recipient then decrypts D (*) 908 using the EC's public key, and replaces the digital signature 912 contained in the original message with
The message is decrypted using the sender's public key, and the original message digest (here,
(Indicated by MD909). MD909 is the newly calculated MD ^ 9 for correction
Compared to 11. If they do not match, the original message is considered tampered and will be rejected.
【0067】 以下は、図5〜11において使用された記号および略号のリストである。 Acknowledgement DataEC=ECによってSPに送り返されたメッセージの一部。これ
はSPに、先のメッセージが首尾良く受け取られ、処理されたことを知らせるもの
である。 Acknowledgement DataM=マーチャントによってSPに送り返されたメッセージの
一部。これはSPに、先のメッセージが首尾良く受け取られ、処理されたことを知
らせるものである。 AIEC=EC保有者の取引勘定情報。 AIM=マーチャントの取引勘定情報。 CRYPTO=暗号文。The following is a list of symbols and abbreviations used in FIGS. Acknowledgment Data EC = Part of the message sent back to the SP by the EC . This informs the SP that the previous message was successfully received and processed. Acknowledgement Data M = part of the message sent back to the SP by the merchant. This informs the SP that the previous message was successfully received and processed. AI EC = transaction account information of EC holder. AI M = merchant transaction account information. CRYPTO = Ciphertext.
【0068】 D=解読機能。 DSP-Private-Key=SP専有鍵を使った解読。 DS=ディジタル署名機能。 DSEC-Private-Key=メッセージ上のECによるディジタル署名。 DSM-Private-Key=メッセージ上のマーチャントによるディジタル署名。D = Decryption function. D SP-Private-Key = Decryption using SP private key. DS = digital signature function. DS EC-Private-Key = Digital signature by EC on message. DS M-Private-Key = Digital signature by merchant on message.
【0069】 DSSP-Private-Key=メッセージ上のSPによるディジタル署名。 E=暗号化機能。 E(Data)=データ暗号鍵によるデータの暗号化。 ESP-PK,ESP-Public-Key=SP公開鍵によって暗号化されたデータ。 ESkey-EC,DSkey-EC=SPがECのために作成したセッション鍵を使った暗号化/解
読。DS SP-Private-Key = Digital signature by SP on message. E = encryption function. E (Data) = Data encryption using a data encryption key. E SP-PK , E SP-Public-Key = Data encrypted with the SP public key. E Skey-EC , D Skey-EC = Encryption / decryption using the session key created by the SP for EC.
【0070】 ESkey-M,DSkey-M=SPがマーチャントのために作成したセッション鍵を使った暗
号化/解読。 EC=電子カード、または電子カードと等価のソフトウェア。 H(M)=一方向ハッシュ・アルゴリズムをMに適用する。これで、Mのメッセージダ
イジェスト(MD)が作成される。 KE=鍵交換段階。 M=マーチャント。E Skey-M , D Skey-M = Encryption / Decryption using session key created by SP for merchant. EC = Electronic card or software equivalent to electronic card. H (M) = Apply one-way hash algorithm to M As a result, a message digest (MD) of M is created. KE = key exchange phase. M = Merchant.
【0071】 MD=メッセージダイジェスト。 MD^=メッセージの受け手が、入力データとして受け取ったばかりのメッセージ
を使って作成したメッセージダイジェスト。 MDEC=ECからSPに向かうメッセージのメッセージダイジェスト。 MDM=マーチャントからSPに向かうメッセージのメッセージダイジェスト。 MDSP-M=SPからマーチャントに向かうメッセージのメッセージダイジェスト。MD = message digest. MD ^ = Message digest created by the message recipient using the message just received as input data. MD EC = Message digest of the message from EC to SP. MD M = Message digest of the message going from the merchant to the SP. MD SP-M = Message digest of the message from the SP to the merchant.
【0072】 MDSP-EC=SPからマーチャントを通ってECに向かうメッセージのメッセージダイ
ジェスト。 PLAIN TEXT=暗号化なしで伝送できる取引データ。平文は、メッセージごと、取
引当事者ごとに異なることがあり得る。 PLAIN TEXTEC=ECが自らの出力メッセージの中に設けた取引データ部分。平文デ
ータフィールドは、セキュリティ感知可能でない。それゆえ、これは暗号化なし
で伝送される。 この記号の内容は、異なるメッセージの中で使用される時、異なることがあり得
る。 PLAIN TEXTM=マーチャントが自らの出力メッセージの中に設けた取引データ部
分。平文データフィールドは、セキュリティ感知可能でない。それゆえ、これは
暗号化なしで伝送される。この記号の内容は、異なるメッセージの中で使用され
る時、異なることがあり得る。 PLAIN TEXTSP-EC=SPがECのために自らの出力メッセージの中だけに設けた取引
データ部分。平文データフィールドは、セキュリティ感知可能でない。それゆえ
、これは暗号化なしで伝送される。この記号の内容は、異なるメッセージの中で
使用される時、異なることがあり得る。MD SP-EC = Message digest of message going from SP to EC through merchant. PLAIN TEXT = transaction data that can be transmitted without encryption. The plaintext can be different for each message, each trading party. PLAIN TEXT EC = Transaction data part provided by EC in its own output message. Plaintext data fields are not security sensitive. Therefore, it is transmitted without encryption. The content of this symbol can be different when used in different messages. PLAIN TEXT M = The transaction data part provided by the merchant in its own output message. Plaintext data fields are not security sensitive. Therefore, it is transmitted without encryption. The content of this symbol can be different when used in different messages. PLAIN TEXT SP-EC = Transaction data part that SP has provided only in its own output message for EC. Plaintext data fields are not security sensitive. Therefore, it is transmitted without encryption. The content of this symbol can be different when used in different messages.
【0073】 PLAIN TEXTSP-M=SPがマーチャントのために自らの出力メッセージの中だけに設
けた取引データ部分。平文データフィールドは、セキュリティ感知可能でない。
それゆえ、これは暗号化なしで伝送される。この記号の内容は、異なるメッセー
ジの中で使用される時、異なることがあり得る。 STD=データ伝送中の暗号化を要求する感知可能な取引データ。 STDEC=ECが自らの出力メッセージの中に設けた感知可能な取引ディジタルデー
タ。この記号の内容は、異なるメッセージの中で使用される時、異なることがあ
り得る。 STDM=マーチャントが自らの出力メッセージの中に設けた感知可能な取引ディジ
タルデータ。この記号の内容は、異なるメッセージの中で使用される時、異なる
ことがあり得る。 PK=公開鍵。PLAIN TEXT SP-M = Transaction data part provided by SP only in its own output message for merchant. Plaintext data fields are not security sensitive.
Therefore, it is transmitted without encryption. The content of this symbol can be different when used in different messages. STD = Sensitive transaction data requiring encryption during data transmission. STD EC = Sensitive transaction digital data provided by the EC in its own output message. The content of this symbol can be different when used in different messages. STD M = sensible transaction digital data provided by the merchant in its outgoing message. The content of this symbol can be different when used in different messages. PK = public key.
【0074】 EC-PK,PKEC=電子カードの公開鍵。 M-PK,PKM=マーチャントの公開鍵。 SP-PK,PKSP=選択されたサービスプロバイダの公開鍵。 Response DataSP-EC=一取引の取引段階の間にSPによってECに送り返されたメッ
セージ部分。これは、許可/不許可データおよび/または他の何らかの関連デー
タを含むことがあり得る。 Response DataSP-M=一取引の取引段階の間にSPによってマーチャントに送り返
されたメッセージ部分。これは、許可/不許可データおよび/または他の何らか
の関連データを含むことがあり得る。EC-PK, PK EC = public key of electronic card. M-PK, PK M = Merchant's public key. SP-PK, PK SP = Public key of the selected service provider. Response Data SP-EC = Message part sent back to EC by SP during the trading phase of one transaction. This may include permission / disapproval data and / or some other relevant data. Response Data SP-M = Message part sent back to merchant by SP during the trading phase of one transaction. This may include permission / disapproval data and / or some other relevant data.
【0075】 RN=乱数。 RNEC=ECによって作成された、SPに送られる乱数。 RNSP-EC=SPによって作成された、ECに送られる乱数。 RNM=マーチャントによって作成された乱数。 RNSP-M=SPによって作成された、Mに送られる乱数。RN = random number. RN EC = random number generated by the EC and sent to the SP. RN SP-EC = random number sent to EC, created by SP. RN M = random number generated by the merchant. RN SP-M = random number sent to M, created by SP.
【0076】 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の範囲内のデータの組み合わせまたは連鎖。SP = Financial or non-financial organization service provider. TA = transaction (transit) account. Transaction Identification Number SP-EC , TID SP-EC (Transaction ID SP-EC ) =
A data field that is assigned a value by the SP during the key exchange phase of a transaction. EC
Will use this value to communicate with the SP during the same transaction. Transaction Identification Number SP-M , TID SP-M (Transaction ID SP-M ) = Data field that is assigned a value by the SP during the key exchange phase of a transaction. EC is
This value will be used to communicate with the SP during the same transaction. * = Combination or chaining of data within encryption E or decryption D.
【0077】 図6A〜6Qは、本発明の優先実施例による暗号システムと暗号法のフローチャー
トを示す。図6A〜6Qにおいて使用される記号および説明を簡素化する目的のため
、フローチャートでは、取引に関わる関係者の各々が1対の鍵を使用すると仮定
する。本発明の別の実施例では、2対の公開鍵を使用してよく、その場合には、
両方の公開鍵を交換する必要がある。FIGS. 6A to 6Q show flowcharts of a cryptographic system and a cryptographic method according to a preferred embodiment of the present invention. For purposes of simplifying the symbols and descriptions used in FIGS. 6A-6Q, the flowchart assumes that each of the parties involved in the transaction uses a pair of keys. In another embodiment of the invention, two pairs of public keys may be used, in which case:
Both public keys need to be exchanged.
【0078】 本発明の優先実施例は、2つの別個の段階からなる。鍵交換段階と取引段階で
ある。 段階I:鍵交換段階(ハンドシェイク段階) ECカード保有者は、ECをカード読み書きデバイスに差し込むか、EC等価ソフト
ウェアを起動させるかし、PIN番号を入力し、および/またはECカード使用のた
めのアクセス条件 110 を満足させる。入力されたセキュリティ情報は、オンカ
ード情報 114 と比較され 112、そこで、ユーザーにEC使用の許可を与えること
が照合確認される。セキュリティ情報がカードセキュリティ情報と一致しない場
合、カード使用のリクエストははねられる 116。一致する場合、カードはロック
解除され 118、使用できることになる。カードがロック解除されたら、ユーザー
は、サービスプロバイダ選択のためにオンカードSPのリストをリクエストし、SP
選択コマンドをECに向けて発することによって選択 120 を行うことができる。S
Pが選択されると、ECは、SPと鍵交換(KE)を始める。選択されたSPの公開鍵(
記号 SP-PK および PKSP によって表された)は、ECのSPDAから得られ、SPに送
られることになるメッセージの暗号化に使用される。A preferred embodiment of the present invention consists of two distinct steps. The key exchange phase and the transaction phase. Phase I: Key exchange phase (handshake phase) The EC card holder inserts the EC into the card read / write device, activates the EC equivalent software, enters the PIN number, and / or uses the EC card Satisfies access condition 110. The entered security information is compared 112 with the on-card information 114 where it is verified that the user is authorized to use EC. If the security information does not match the card security information, the request to use the card is rejected 116. If they match, the card is unlocked 118 and can be used. Once the card is unlocked, the user requests a list of on-card SPs for service provider selection and the SP
Selection 120 can be made by issuing a selection command to the EC. S
When P is selected, the EC starts key exchange (KE) with the SP. The public key of the selected SP (
(Represented by the symbols SP-PK and PK SP ) are used to encrypt messages that are obtained from the EC's SPDA and will be sent to the SP.
【0079】 KEの主な目的は、カード保有者の公開鍵 PKEC 126 およびEC乱数 RNEC 124 を
SPに確実に送ることである。ECに対するSPの応答は、セッション鍵および取引ID
をECに割り当てることで、ECはこれを使って、取引の残りについてSPと通信する
ことになる。KEメッセージをフォーマットするため、ECは乱数 RNEC 124 を作成
し、これをEC公開鍵 PKEC 126 および取引関連の感知可能な取引データ STDEC 1
28 および/またはSPによってリクエストされた取引データとつなぎ合わせる。E
Cは、これらのデータ 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 の
中に置かれてよい。The main purpose of KE is to obtain the cardholder's public key PK EC 126 and EC random number RN EC 124
It is sure to send to SP. SP's response to EC is session key and transaction ID
By assigning to the EC, the EC will use it to communicate with the SP for the rest of the transaction. To format the KE message, the EC generates a random number RN EC 124, which it uses as the EC public key PK EC 126 and transaction-related sensitive transaction data STD EC 1
28 with the transaction data requested by the SP. E
C encrypts these data 122 using the SP public key PK SP recovered from SPDA 120. The EC ciphertext E ES-PK (RN EC * PK EC * STD EC ) thus completed is then combined with the plain text part PLAIN TEXT EC 132 of the message to form the EC composite message PLAIN TEXT EC * E SP-PK (RN EC * PK EC * STD EC ). The EC public key PK EC 126 may be placed in the plaintext PLAIN TEXT EC instead of being encrypted when forming the EC composite message.
【0080】 感知可能なデータだけが暗号化される。感知可能でない応答データは、平文の
中に含まれる。SPだけが、感知可能なデータを読み出すことができる。関係者多
数の取引では、SPは、すべての関係者の感知可能な情報にフルにアクセスするこ
とができる。Only the sensitive data is encrypted. Non-sensitive response data is included in the plaintext. Only the SP can read the sensible data. In multi-party transactions, the SP has full access to the perceived information of all parties.
【0081】 出来上がったEC複合メッセージは、ハッシュ・アルゴリズム 134 を通して送
られ、そこでハッシュ・メッセージを形成する。これがECメッセージダイジェス
ト MDEC である。ECメッセージダイジェスト MDEC には、EC 136 がEC専有鍵 13
8 を使ってディジタル署名する。これにより、ディジタル署名されたメッセージ DSEC-Private-Key が形成される。ディジタル署名されたメッセージ DSEC-Priv ate-Key は、次にEC複合メッセージと組み合わされる 140 。平文 PLAIN TEXTEC と暗号文 CRYPTOEC とディジタル署名 DSEC-Private-Keyとの組み合わせは、EC
からのKEメッセージであり、ネットワークを通してマーチャント 158 に送られ
る。平文は、性質的に感知可能でない取引データフィールドをすべて含んでおり
、それゆえ、明瞭な見分けられる形で伝送することができる。従って、暗号化す
る必要がない。これらのデータフィールドは、メッセージごとに異なり、取引関
係者によって限定される。The resulting EC composite message is sent through a hash algorithm 134 where it forms a hash message. This is the EC message digest MD EC . EC Message Digest MD EC has EC 136 as EC proprietary key 13
Digitally sign using 8. Thus, a digitally signed message DS EC-Private-Key is formed. The digitally signed message DS EC-Private -Key is then combined 140 with the EC composite message. Plain text PLAIN TEXT EC , ciphertext CRYPTO EC and digital signature DS EC-Private-Key combined with EC
KE message sent to the merchant 158 through the network. The plaintext contains all the transaction data fields that are not perceptually sensitive and can therefore be transmitted in a clearly discernable manner. Therefore, there is no need for encryption. These data fields vary from message to message and are defined by the parties involved.
【0082】 SPと通信するため、マーチャントは、本質的にECが自身のKEメッセージを形成
する時に踏むのと同じステップを踏んで自身のKEメッセージを形成する。カード
保有者とマーチャントは、個別にSPと通信しないが、組み合わされたメッセージ
を通して通信する。その結果、カード保有者とマーチャントの間で何らかの機密
金融情報を交換する必要は無くなる。マーチャントは、取引 142 のために自身
のデバイスを準備し、専有のデバイスの中にある自身のSPDAから、ECカード保有
者が取引 144 のために選択したのと同じSPを選択する。SPの公開鍵(記号 SP-P
K および PKSP によって表された)は、SPのSPDAから得られ、SPに送られること
になるメッセージの暗号化に使用される。To communicate with the SP, the merchant forms his own KE message following essentially the same steps that the EC takes when forming his own KE message. Cardholders and merchants do not communicate with the SP individually, but do communicate through combined messages. As a result, there is no need to exchange any sensitive financial information between the cardholder and the merchant. The merchant prepares his device for the transaction 142 and selects from his SPDA in the proprietary device the same SP that the EC cardholder has selected for the transaction 144. SP's public key (symbol SP-P
Represented by K and PK SP) is obtained from the SPDA the SP, is used to encrypt the message to be sent to the SP.
【0083】 自身のKEメッセージをフォーマットするため、マーチャントは乱数 RNM 148
を作成し、これをマーチャント公開鍵 PKM 150 およびマーチャントの感知可能
な取引データ STDM とつなぎ合わせる。感知可能な取引データとは、取引に関連
するデータおよび/またはSP 152 によってリクエストされたデータのことであ
る。マーチャントは、組み合わされたデータを、サービスプロバイダの公開鍵 P
KSP を使って暗号化する 146 。こうして出来上がった暗号文は、次に平文部分
PLAIN TEXTM 156 と組み合わされ 154 、マーチャント複合メッセージを形成す
る。マーチャントの公開鍵 PKM 150 は、マーチャント複合メッセージPLAIN TEX
TM*ESP-PK(RNM*PKM*STDM)を形成する時に暗号化される代わりに平文 PLAIN TEXT M の中に置かれてよい。To format its own KE message, the merchant uses a random number RNM 148
And create this as the merchant public key PKM 150 and merchant sensitive
Transaction data STDM And join it. Sensitive transaction data is related to the transaction
And / or data requested by SP 152.
You. The merchant sends the combined data to the service provider's public key P
KSP Encrypt using 146. The ciphertext thus completed is the plaintext part
PLAIN TEXTM 154 to form a merchant composite message.
You. Merchant's public key PKM 150 is the merchant compound message PLAIN TEX
TM* ESP-PK(RNM* PKM* STDM) Instead of being encrypted when forming PLAIN TEXT M May be placed inside.
【0084】 マーチャント複合メッセージ [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(RN M *PKM*STDM)] である。このEC/マーチャント複合メッセージは、ハッシュ・ア
ルゴリズム 160 を通して送られ、そこでハッシュ・メッセージを形成する。こ
れがマーチャントメッセージダイジェスト MDM である。マーチャントメッセー
ジダイジェスト MDM には、マーチャントがマーチャント専有鍵 164 を使ってデ
ィジタル署名する 162 。これにより、ディジタル署名されたマーチャントメッ
セージ DSM-Private-Key が形成される。ディジタル署名されたマーチャントメ
ッセージ DSM-Private-Key は、次にメッセージ、すなわちEC/マーチャント複
合メッセージのデータ部分と組み合わされ 166 、そこで、マーチャントとEC両
方のための鍵交換リクエストメッセージ<<[[PLAIN TEXTEC*ESP-PK(RNEC*PKEC*ST
DEC)]*DSEC-Private-Key]*[PLAIN TEXTM*ESP-PK(RNM*PKM*STDM)]>>*DSM-Private -Key を形成する。この最終メッセージが、ネットワークを通してSPに送られる
。図7は、マーチャントからSPに送られる鍵交換リクエストメッセージの最終の
フォーマットと内容を示す。Merchant Compound Message [PLAIN TEXTM* ESP-PK(RNM* PKM* STDM)]
EC KE message [[PLAIN TEXTEC* ESP-PK(RNEC* PKEC* STDEC)] * DSEC-Private- Key ], Where there are KE messages for both merchants and EC
Is formed. That is, the EC / merchant composite message [[PLAIN
TEXTEC* ESP-PK(RNEC* PKEC* STDEC)] * DSEC-Private-Key] * [PLAIN TEXTM* ESP-PK(RN M * PKM* STDM)]. This combined EC / merchant message is
Sent through algorithm 160, where it forms a hash message. This
Rega Merchant Message Digest MDM It is. Merchant message
Digest MDM The merchant uses the merchant's proprietary key 164
162 digitally signed. This allows digitally signed merchant messages
Sage DSM-Private-Key Is formed. Digitally signed merchant
Sage DSM-Private-Key Is the next message, the EC / merchant
166, where the merchant and EC
Exchange message <<< [PLAIN TEXTEC* ESP-PK(RNEC* PKEC* ST
DEC)] * DSEC-Private-Key] * [PLAIN TEXTM* ESP-PK(RNM* PKM* STDM)] >> * DSM-Private -Key To form This final message is sent to the SP over the network
. Figure 7 shows the final key exchange request message sent by the merchant to the SP.
Show format and content.
【0085】 本発明の優先実施例では、ECが自身の公開鍵を暗号化するので、マーチャント
は、ECのリクエストメッセージMDECのMDをチェックしない。それでも、本発明の
別の条例では、ECが自身の公開鍵を暗号化しない場合、マーチャントは任意にEC
のMDを、SPに行き着く前にチェックすることができる。ECが自身の公開鍵を暗号
化する場合でも、ECが自身の公開鍵を暗号化しない場合でも、セキュリティを高
め、マーチャントによる処理ミスを避けるためであれば、SPはなおECのMDをチェ
ックすることができる。マーチャントは、自身とECの両方のためにSPから複合応
答を受け取る時、ECのためにMDをチェックするには及ばない。なぜなら、そのMD
が、単独に発信者であるSPによって形成された全体メッセージの一部だからであ
る。マーチャントは、自身がSPから受け取る全体メッセージのMDをチェックしさ
えすればよい。In a preferred embodiment of the invention, the merchant does not check the MD of the EC's request message MD EC , since the EC encrypts its own public key. Nevertheless, another ordinance of the present invention states that if the EC does not encrypt its own public key,
You can check the MD before arriving at the SP. Regardless of whether the EC encrypts its own public key or the EC does not encrypt its own public key, the SP still checks the EC's MD to increase security and avoid processing errors by merchants. be able to. When a merchant receives a composite response from the SP for both itself and the EC, it is far from checking the MD for the EC. Because that MD
Is part of the entire message formed by the SP, which is the sole sender. The merchant only has to check the MD of the whole message that he receives from the SP.
【0086】 SPは、KEリクエストメッセージを受け取ると、先ずKEリクエストメッセージの
データ部分をDSから切り離し、KEリクエストメッセージのデータ部分を一方向ハ
ッシュ・アルゴリズムに送り込み、そこでメッセージダイジェストを再計算する
。これが MDM となる。SPは次に、マーチャントの平文 PLAIN TEXTM 、暗号文 C
RYPTOM 、ディジタル署名 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 。When the SP receives the KE request message, it first separates the data part of the KE request message from the DS, sends the data part of the KE request message to the one-way hash algorithm, and recalculates the message digest there. This is the MD M. The SP then enters the merchant's plaintext PLAIN TEXT M , the ciphertext C
RYPTO M , digital signature DS M-Private-Key and EC KE request message
PLAIN TEXT EC * CRYPTO EC * DS Separate EC -Private-Key . Using its own private key, the SP decrypts the merchant ciphertext 170 and recovers the merchant random number RN M 148 and the merchant public key PK M 150 from other information. SP then uses the recovered PK M 0.99 to decrypt the digital signature DS M-Private-Key merchant, recovering MD M for merchant KE message. SP recovers newly collected MD ^ M 168 by decrypting DS from original KE message
172 compared to MD M 170. If a mismatch is found between MD ^ M and MD M, KE message is deemed to have been altered, hit by 174.
【0087】 MD^M とMDM が一致すれば、SPは、ECのKEリクエストメッセージのデータ部分
をDSから切り離し、KEリクエストメッセージのデータ部分を一方向ハッシュ・ア
ルゴリズムに送り込み、そこでメッセージダイジェスト(MD^EC)を再計算する。S
Pは次に、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に送
り返すことができる。[0087] If a match is MD ^ M and MD M, SP, disconnect the data portion of the KE request message of EC from DS, it feeds the data portion of the KE request message to a one-way hash algorithm, where the message digest (MD ^ EC ) is recalculated. S
P then enters the plaintext PLAIN TEXT EC in the KE request message 176 of the EC ,
Separate CRYPTO EC and digital signature DS EC-Private-Key . Using its own private key, the SP decrypts the EC ciphertext and recovers the EC random number RN EC and EC public key PK EC from other information. SP then uses the recovered PK EC to digitally sign the EC
Decrypt DS EC-Private-Key and recover MD EC for EC KE message. In step 178, the SP compares the newly collected MD ^ EC 176 with the MD EC recovered by decrypting the DS from the original KE message. If any inconsistencies are found, the KE message is considered tampered with and will be rejected.
. If there is a match, the SP can immediately send a KE response message back to the merchant and EC.
【0088】 ECのためのKE応答メッセージをフォーマットするため、SPは、乱数 RNSP-EC 1
84 およびECのためのセッション鍵SkeyEC 186 を作成し、これらをECの乱数 RNE C 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 T
EXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDEC)]*DSSP-Private-Key である。To format the KE response message for the EC, the SP uses a random number RNSP-EC 1
84 and Session Key Skey for ECEC 186, and these are used as EC random numbers RNE C 188, service provider's detectable transaction data STDSP-EC Combined with 190
The data 192 to the public key PK of the EC.EC Encrypt using. In this way
Completed ciphertext EEC-PK(RNEC* RNSP-EC* SkeyEC* STDSP-EC), Then to the SP
Therefore, transaction identification number TID assigned to ECSP-EC 194 and plain text PLAIN TEXT SP-EC 195, where it forms the data part of the response message for EC.
To achieve. The SP passes this data through a hash algorithm, where the message
Digest MDSP-EC Calculate 198. Using his own private key 202, the SP
Sage digest MDSP-EC Response message by digital signature of
Digital signature DSSP-Private-Key Create 200. Data part of message
Digital signature DS with newly calculated minutesSP-Private-Key After combining with 204
The KE response message of the SP for the EC is completed. That is, [TIDSP-EC* PLAIN T
EXTSP-EC* EEC-PK(RNSP-EC* RNEC* SkeyEC* STDEC)] * DSSP-Private-Key It is.
【0089】 マーチャントのための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応答メッセージ [TI
DSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNSP-EC*RNEC*SkeyEC*STDEC)]*DSSP-Private-K ey と組み合わされ 222 、そこで、SPの最終のKE応答メッセージのデータ部分 [T
IDSP-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)]を形成する
。In order to format the KE response message for the merchant, the SP creates a random number RN SP-M 208 and a session key Skey M 210 for the merchant, and uses these to detect the merchant's random number RN M 212 combined with transaction data STD SP-EC 214, these data 206 and encrypted with the public key PK M merchant recovered in 170. The resulting ciphertext is then the transaction identification number TID SP- M218 assigned to the merchant by the SP and the plaintext PLAIN
Combined with the TEXT SP-M 220, where it forms the data portion of the response message for the merchant. Completed composite message TID SP-M * PLAIN TEXT SP-M *
E M-PK (RN SP-M * RN M * Skey M * STD SP-M ) further includes a KE response message [EC
D SP-EC * PLAIN TEXT SP-EC * E EC-PK (RN SP-EC * RN EC * Skey EC * STD EC )] * DS SP-Private-K ey 222 where the final SP Data part of KE response message [T
ID SP-EC * PLAIN TEXT SP-EC * E EC-PK (RN SP-EC * RN EC * Skey EC * STD EC )] * DS EC-Private- Key ] * [TID SP-M * PLAIN TEXT SP- M * E M-PK (RN SP-M * RN M * Skey M * STD SP-M )].
【0090】 SPはこのデータ部分をハッシュ・アルゴリズムに通し、そこでメッセージダイ
ジェスト 224 を計算する。自身の専有鍵 228 を使って、SPは、メッセージダイ
ジェストのディジタル署名によって応答メッセージのためのディジタル署名 DSS P-Private-Key 226 を作成する。メッセージのデータ部分を新たに計算された D
S 226 と組み合わせた後 230 、ECとマーチャント両方のためのKE応答メッセー
ジは完成する。この応答メッセージ <<[[TIDSP-EC*PLAIN TEXTSP-EC*EEC-PK(RNS P-EC *RNEC*SkeyEC*STDSP-EC)]*DSSP-Private-Key]*[TIDSP-M*PLAIN TEXTSP-M*EM -PK (RNSP-M*RNM*SkeyM*STDSP-M)]>>DSSP-Private-Key は、ネットワークを通し
てマーチャントに送り返される。図8は、SPからマーチャントに送り返される複
合KE応答メッセージの最終のフォーマットと内容を示す。The SP passes this data portion through a hash algorithm, where it calculates a message digest 224. Using its own proprietary key 228, SP creates a digital signature DS S P-Private-Key 226 for the response message by digitally signing the message digest. The newly calculated D for the data part of the message
After combining 230 with 226, the KE response message for both EC and merchant is complete. This response message << [[TID SP-EC * PLAIN TEXT SP-EC * E EC-PK (RN S P-EC * RN EC * Skey EC * STD SP-EC )]] * DS SP-Private-Key ] * [TID SP-M * PLAIN TEXT SP-M * E M -PK (RN SP-M * RN M * Skey M * STD SP-M )] >>>> DS SP-Private-Key is sent back to the merchant through the network . FIG. 8 shows the final format and content of the composite KE response message sent back from the SP to the merchant.
【0091】 マーチャントは、KE応答メッセージを受け取ると、先ず、SPのディジタル署名 DSSP-Private-Key を切り離し、次に、複合KE応答メッセージのデータ部分を一
方向ハッシュ・アルゴリズムに送り込み、そこでメッセージダイジェストMD^ SP -M を再計算する。マーチャントは次に、SPのKE応答メッセージのデータ部分、す
なわち TIDSP-M 、PLAIN TEXTSP-M 、CRYPTOSP-M 、[(TIDSP-EC*PLAIN TEXTSP-E C *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
。When the merchant receives the KE response message, it first detaches the digital signature DS SP-Private-Key of the SP , and then sends the data portion of the composite KE response message to the one-way hash algorithm, where the message digest is sent. Recalculate MD ^ SP -M . The merchant then the data portion of the KE response message SP, i.e. TID SP-M, PLAIN TEXT SP -M, CRYPTO SP-M, [(TID SP-EC * PLAIN TEXT SP-E C * CRYPTO SP-EC) ] * Disconnect DS -Private-Key . The merchant decrypts the digital signature DS SP-Private-Key using the SP's public key (selected from 144) and retrieves the message digest MD SP-M . Merchants are newly gathered
234 the MD ^ SP-M compared with the MD EC. If there is any discrepancy between MD ^ SP-M and MD SP-M , the KE response message is deemed to have been tampered with and will be rejected.
.
【0092】 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-K ey をECに送り、取引の取引段階の準備をする。If the MD ^ SP-M and the MD SP-M match, the merchant identifies the response message portion addressed to itself, and decrypts the ciphertext CRYPTO SP-M 238 using its own private key. . This merchant should it be recovered the original (148) a random number RN M sent to the SP in the EC response message. The merchant compares the recovered random number RN M a (step 238) and the original random number RN M. If they are not equal, the message is considered tampered with and rejected. Random number RN M is, SP
Since it cannot be recovered without using the correct SP proprietary key, it is certain that the selected SP is really the sender of the message. The merchant is there for the EC
KE response message [(TID SP-EC * PLAIN TEXT SP-EC * CRYPTO SP-EC )] * DS Sends the SP-Private- Key to the EC to prepare for the transaction stage of the transaction.
【0093】 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の)を回収でき
るはずである。When the EC receives the KE response message 260, it first sets the digital signature DS of the SP.SP -Private-Key And then replace the data part of the KE response message for EC
Feeds a one-way hash algorithm where the message digest MD ^ SP-EC make. The EC is then the data part of the message, the TIDSP-EC , PLAIN
TEXTSP-EC , CRYPTOSP-EC , DSSP-Private-Key Disconnect. EC is the public key of the SP
Digital signature DS (selected at 120)SP-Private-Key s message
Decrypt the message digest MDSP-EC Collect. Ma EC newly collected
MD ^SP-EC DS (at 260) from the KE response message for ECSP-Private- Key MD recovered by decryption ofSP-EC Compare with 262. MD ^SP-ECAnd MDSP-EC If any inconsistencies are found during the
It is deemed to have been altered and rejected. MD ^SP-MAnd MDSP-M If
The EC identifies the part of the response message addressed to it and includes it in the message.
CRYPTOSP-EC Using its own private key 266. Now the EC
Original random number RN sent in EC response messageEC(124) can be collected
Should be.
【0094】 ECは、回収された乱数RNEC(266の)をオリジナル乱数RNEC(124の)と比較す
る。両方の乱数が等しくなければ、メッセージは改変されたものとみなされ、は
ねられる 270 。SPが正しいSP専有鍵を使ってしない限り、乱数RNECは回収でき
ないのだから、選択されたSPが本当にメッセージの送り手であることは確かであ
る。ECは、取引の取引段階の準備をする。The EC compares the recovered random number RN EC (of 266) with the original random number RN EC (of). If both random numbers are not equal, the message is considered tampered with and is rejected. As long as the SP is not using the correct SP proprietary key, the random number RN EC since he can not be recovered, it is certain that the selected SP is really the sender of the message. The EC prepares for the transaction phase of the transaction.
【0095】 ここで、ECとマーチャントで設定された所定のタイムアウト期間に入る。取引
の間、タイムアウト期間中に応答メッセージを受け取らなかった場合、ECとマー
チャントは、取引が打ち切られたものとみなし、回収プロセスを再開するか新た
に始めるかすることになる。Here, a predetermined timeout period set by the EC and the merchant is entered. If no response message is received during the timeout period during the transaction, the EC and merchant will consider the transaction aborted and will either restart the collection process or start anew.
【0096】 KEメッセージ交換が首尾良く完了した後、SPの手元にあるのは、ECの公開鍵と
マーチャントの公開鍵である。この時点でECとマーチャント両者の手元にあるの
は、乱数、取引ID、そして、SPからのセッション鍵である。ECとマーチャントは
、取引の鍵交換段階を完成させるために、KE応答メッセージから回収された2つ
の乱数をSPに送り返さなければならない。これは二通りの方法でできる。すなわ
ち、乱数は、ECとマーチャントの両方から乱数を確認メッセージの中に入れて送
り返すことができる。あるいは、ECとマーチャントからSPに向かう次回メッセー
ジ、例えば取引メッセージなどの一部として送り返すこともできる。二番目の方
が簡単である。この方法を以下の段階IIの中で説明する。乱数が使用されるのは
1回だけで、SPとマーチャントの間、そしてSPとECの間の鍵交換において正確を
期すためである。セッション鍵と取引識別番号がひとたび確立されたなら、乱数
はもはや不用となる。After the successful completion of the KE message exchange, the SP has the public key of the EC and the public key of the merchant. At this point, both the EC and the merchant have the random number, the transaction ID, and the session key from the SP. The EC and merchant must send the two random numbers recovered from the KE response message back to the SP to complete the key exchange phase of the transaction. This can be done in two ways. That is, the random number can be sent back from both the EC and the merchant in the confirmation message. Alternatively, it can be sent back as part of the next message from the EC and merchant to the SP, such as a trading message. The second is easier. This method is described in Stage II below. The random numbers are used
Only once, to be accurate in key exchange between SP and merchant, and between SP and EC. Once the session key and transaction identification number have been established, the random number is no longer needed.
【0097】 段階II:トランザクション段階 トランザクション段階では、販売業者とECは各々アカウント番号のような固
有のアカウント情報と、トランザクション金額、承認または他の処理の要求とい
った他のトランザクション関連データをSPに送信する。ここでも、ECと販売
業者はSPに個別にではあるが結合されたメッセージを通じて通信し、販売業者
はメッセージを結合しそれらを1つのメッセージとしてSPに送信する責任を負
う。Phase II: Transaction Phase In the transaction phase, the merchant and the EC each send unique account information, such as an account number, and other transaction-related data, such as transaction amounts, approvals or other processing requests to the SP. . Again, the EC and the merchant communicate through messages individually but coupled to the SP, and the merchant is responsible for merging the messages and sending them as one message to the SP.
【0098】 ECはまず、SPからの乱数RNSP-EC274と、選択されたSPとのECの
アカウント情報、AIEC276、及びトランザクション金額TA280及びトラ
ンザクションに関連し、かつ/またはSPによって要求される何らかの他の機密
データ278を連結することでトランザクション・メッセージを形成する。EC
はSPによって割り当てられたセッション鍵SkeyECを使用してそれを暗号化
272する。SkeyECは秘密鍵であり、公開鍵暗号化で使用される暗号化アル
ゴリズムと異なった暗号化アルゴリズムを使用する。結果として得られる暗号C
RYPTOEC、すなわち、SkeyEC(RNSP-EC*STDEC*AIEC*TA)
は次に、トランザクションID TIDSP-EC284及び、もしあればプレーン
テキストPLAIN TEXTEC286と結合282され、ECのトランザクシ
ョン・メッセージのデータ部分、TIDSP-EC*PLAIN TEXTEC*CR
YPTOECを形成する。The EC is first associated with a random number RN SP-EC 274 from the SP and the account information of the EC with the selected SP, the AI EC 276, and the transaction amount TA 280 and the transaction, and / or is requested by the SP. The concatenation of some other sensitive data 278 forms a transaction message. EC
Encrypts 272 it using the session key Skey EC assigned by the SP. Skey EC is a secret key and uses an encryption algorithm different from the encryption algorithm used in public key encryption. The resulting cipher C
RYPTO EC , that is, Skey EC (RN SP-EC * STD EC * AI EC * TA)
Is then combined 282 with the transaction ID TID SP-EC 284 and the plain text PLAIN TEXT EC 286, if any, and the data portion of the EC transaction message, TID SP-EC * PLAIN TEXT EC * CR
Form YPTO EC .
【0099】 データ部分282はメッセージ・ダイジェストMDECを計算する一方向ハッシ
ュ・アルゴリズム288に供給され、MDECは次にECのプライベート鍵292
によってデジタル署名290される。結果として得られるデジタル署名290は
(282からの)メッセージのデータ部分294と結合され、ECのトランザク
ション要求メッセージを形成し、その後販売業者に送信される、[TIDSP-EC
*PLAIN TEXTEC*SkeyEC(RNSP-EC*STDEC*AIEC*TA
)]DSEC-Private-Key。[0099] The data portion 282 is supplied to a one-way hash algorithm 288 to calculate the message digest MD EC, MD EC is the next EC private key 292
Digital signature 290. The resulting digital signature 290 is combined with the data portion 294 of the message (from 282) to form an EC transaction request message, which is then sent to the merchant, [TID SP-EC
* PLAIN TEXT EC * Skey EC (RN SP-EC * STD EC * AI EC * TA
)] DS EC-Private-Key .
【0100】 販売業者は本質的に同じステップを経て自らのトランザクション・メッセージ
を形成する。販売業者は、SPからのRNSP-Mと、選択されたSPとの販売業者
のアカウント情報、AIM248、トランザクション金額TA252、及びトラ
ンザクションに関連しかつ/またはSPによって要求される何らかの他の機密デ
ータSTDMを連結246することで自らのトランザクション・メッセージを形
成する。販売業者はSPによって割り当てられたセッション鍵SkeyMを使用
してそれを暗号化244する。セッション鍵SkeyMは秘密鍵であり、DES
のような公開鍵暗号化で使用される暗号化アルゴリズムと異なった暗号化アルゴ
リズムを使用して生成される。セッション鍵SkeyMが使用され、この時点で
暗号化が行われ、暗号CRYPTOMが生成される。結果として得られる暗号C
RYPTOM、すなわち、SkeyM(RNSP-M*STDM*AIM*TA)は次に
トランザクションID TIDSP-M256及び、もしあればプレーンテキストP
LAIN TEXTM258と結合254され、販売業者のトランザクション・
メッセージのデータ部分、TIDSP-M*PLAIN TEXTM*CRYPTOM を形成する。このデータはECのトランザクション要求と結合296され、SP
に関する最終トランザクション要求メッセージのデータ部分、[TIDSP-EC*
PLAIN TEXTEC*SkeyEC(RNSP-EC*STDEC*AIEC*TA)
]*DSEC-Private-Key*[TIDSP-M*PLAIN TEXTM*SkeyM(
RNSP-M*STDM*AIM*TA)]を形成する。The merchant goes through essentially the same steps to form his transaction message. The merchant has the RN SP-M from the SP and the merchant's account information with the selected SP, the AI M 248, the transaction amount TA252, and any other confidentiality associated with the transaction and / or required by the SP. form their own transaction message data STD M coupling 246 to be. The merchant encrypts 244 it using the session key Skey M assigned by the SP. The session key SKey M is a secret key, and DES
Is generated using an encryption algorithm different from the encryption algorithm used in public key encryption. The session key SKey M is used, encryption is performed at this point, and an encrypted CRYPTO M is generated. The resulting cipher C
RYPTO M, i.e., Skey M (RN SP-M * STD M * AI M * TA) then the transaction ID TID SP-M 256 and, plaintext P, if any
Combined with LINE TEXT M 258, the seller transaction
Form the data part of the message, TID SP-M * PLAIN TEXT M * CRYPTO M. This data is combined 296 with the EC transaction request and SP
Data part of final transaction request message related to [TID SP-EC *
PLAIN TEXT EC * Skey EC (RN SP-EC * STD EC * AI EC * TA)
] * DS EC-Private-Key * [TID SP-M * PLAIN TEXT M * Skey M (
RN SP-M * STD M * AI M * TA)] to form a.
【0101】 前と同様、販売業者はメッセージ・ダイジェストMDMを計算する一方向ハッ
シュ・アルゴリズム298を通じて自らの結合データを供給し、MDMは次に販
売業者のプライベート鍵302によってデジタル署名300される。結果として
得られるデジタル署名DSM-Private-Key300は(296からの)メッセージ
のデータ部分と結合され、最終トランザクション要求メッセージを形成し、その
後SPに送信される、{[TIDSP-EC*PLAIN TEXTEC*SkeyEC
(RNSP-EC*STDEC*AIEC*TA)]*DSEC-Private-Key*[TIDSP- M *PLAIN TEXTM*SkeyM(RNSP-M*STDM*AIM*TA)]
}*DSM-Private-Key。図9はトランザクション要求メッセージの最終フォー
マットを示す。[0102] As before, the merchant supplies his combined data through a one-way hash algorithm 298 to calculate the message digest MD M, MD M is digitally signed 300 by the merchant's private key 302 and then . The resulting digital signature DS M-Private-Key 300 is combined with the data portion of the message (from 296) to form the final transaction request message, which is then sent to the SP, {[TID SP-EC * PLAIN TEXT EC * Skey EC
(RN SP-EC * STD EC * AI EC * TA)] * DS EC-Private-Key * [TID SP- M * PLAIN TEXT M * Skey M (RN SP-M * STD M * AI M * TA)]
} * DS M-Private-Key . FIG. 9 shows the final format of the transaction request message.
【0102】 SPがトランザクション要求メッセージを受信すると、SPはまず2つのトラ
ンザクション識別番号、すなわちECと販売業者によって送信されたTIDSP-E C とTIDSP-Mを検査し、それらが有効であるかを確認する。(210の)TI
DSP-Mと(186の)TIDSP-ECの何れかが無効であることが判明した場合、
メッセージは拒否308される。トランザクション識別番号が両方とも有効であ
る場合、SPは先に進んでメッセージのデータ部分からDSM-Private-Keyを分
離し、メッセージのデータ部分、{[TIDSP-EC*PLAIN TEXTEC*
SkeyEC(RNSP-EC*STDEC*AIEC*TA)]*DSEC-Private-Key*
[TIDSP-M*PLAIN TEXTM*SkeyM(RNSP-M*STDM*AIM *TA)]}を、このメッセージのメッセージ・ダイジェストMD∧Mを計算す
る一方向ハッシュ・アルゴリズムに供給する。SPはメッセージのデータ部分、
すなわち、TIDSP-M、PLAIN TEXTM、CRYPTOM、DSM-Privat e-Key 、(TIDSP-EC*PLAIN TEXTEC*CRYPTOEC)*DSEC-P rivate-Key を分離する。When the SP receives the transaction request message, it first checks the two transaction identification numbers, the EC and the TID SP-E C and TID SP-M sent by the merchant, and checks if they are valid. Check. TI (of 210)
If either D SP-M or (186) TID SP-EC is found to be invalid,
The message is rejected 308. If both transaction identification numbers are valid, the SP proceeds and separates the DSM-Private-Key from the data portion of the message, and the data portion of the message, [[TID SP-EC * PLAIN TEXT EC *
Skey EC (RN SP-EC * STD EC * AI EC * TA)] * DS EC-Private-Key *
The [TID SP-M * PLAIN TEXT M * Skey M (RN SP-M * STD M * AI M * TA)]}, and supplies the one-way hash algorithm to calculate the message digest MD∧ M of this message . SP is the data part of the message,
In other words, to separate the TID SP-M, PLAIN TEXT M , CRYPTO M, DS M-Privat e-Key, (TID SP-EC * PLAIN TEXT EC * CRYPTO EC) * DS EC-P rivate-Key.
【0103】 SPは販売業者の公開鍵を使用してDSM-Private-Keyを解読310し、新し
く回復されたメッセージ・ダイジェストMDMを計算されたばかりの(306か
らの)メッセージ・ダイジェストMD∧Mと比較する。MD∧MとMDMが等しく
ない場合、メッセージは破損しており拒否314される。MD∧MとMDMが一致
する場合、SPは、KE段階でSPが販売業者に割り当てた(210の)セッシ
ョン鍵SkeyMを使用してメッセージの暗号化部分を解読316し、暗号化部
分に含まれるデータ・フィールドを回復する。SPはメッセージ中の販売業者が
返送した乱数RNSP-Mを、当初SPが販売業者に送信したメッセージ、(208
からの)RNSP-Mと比較318する。乱数が等しくない場合、販売業者は相互認
証試験に失敗しておりメッセージは拒否320される。The SP decrypts 310 the DS M-Private-Key using the merchant's public key and computes the newly recovered message digest MD M from the just-calculated message digest MD @ M (from 306). Compare with If MD∧ M and MD M are not equal, the message is rejected and damaged 314. If MD∧ M and MD M match, SP is the encrypted portion of the message using SP assigned to the merchant by KE stage (210) the session key Skey M decrypts 316, the encrypted portion Recover contained data fields. The SP transmits the random number RN SP-M returned by the seller in the message to the message that the SP originally transmitted to the seller, (208
318 with RN SP-M ). If the random numbers are not equal, the merchant has failed the cross-certification test and the message is rejected 320.
【0104】 さらに、SPはECのアカウント情報AIECとトランザクション金額TAのよ
うなトランザクション・データを検証する。AIが有効でない場合メッセージは
拒否320される。ECからのTAと販売業者からのTAが一致しない場合もメ
ッセージは拒否される。メッセージを無効にする他の条件もありうる。アカウン
ト情報AIECとトランザクションが有効な場合、SPは続いてメッセージのEC
部分を検証する。Further, the SP verifies transaction data such as the account information AIEC of the EC and the transaction amount TA. If the AI is not valid, the message is rejected 320. The message is also rejected if the TA from the EC and the TA from the merchant do not match. There may be other conditions that invalidate the message. If the account information AI EC and the transaction are valid, the SP will continue to the message EC
Verify the part.
【0105】 販売業者のメッセージの場合と同様、SPはまずECのメッセージからDSEC -Private-Key を分離322し、ECのメッセージのデータ部分、(TIDSP-EC
*PLAIN TEXTEC*CRYPTOEC)を、ECメッセージのメッセージ
・ダイジェストMD∧ECを計算する一方向ハッシュ・アルゴリズムに供給する。
SPはECのトランザクション要求のデータ部分、TIDSP-EC、PLAIN
TEXTEC、CRYPTOEC、DSEC-Private-Keyを分離する。SPはECの公
開鍵PKECを使用してDSEC-Private-Keyを解読324し、MDECを回復する。
SPは回復されたMDECをMD∧ECと比較326する。MDECとMD∧ECが等し
くない場合、メッセージは破損しており拒否328される。MDECとMD∧ECが
一致する場合、SPは、KE段階でSPがECに割り当てた(186の)セッシ
ョン鍵SkeyECを使用してECメッセージの暗号化部分を解読330し、それ
に含まれるデータ・フィールドを回復する。As in the case of the seller's message, the SP first separates 322 the DS EC- Private-Key from the EC message, and the data part of the EC message (TID SP-EC
* PLAIN TEXT EC * CRYPTO EC ) to the one-way hash algorithm that computes the message digest MD @ EC of the EC message.
SP is the data part of the transaction request of EC , TID SP-EC , PLAIN
TEXT EC , CRYPTO EC , and DS EC-Private-Key are separated. SP is the DS EC-Private-Key to decrypt 324 using the public key PK EC of the EC, to recover the MD EC.
The SP compares 326 the recovered MD EC to the MD @ EC . If MD EC and MD @ EC are not equal, the message is corrupted and rejected 328. If MD EC and MD∧ EC match, SP, the data SP in KE stage the encrypted portion of the EC message decrypts 330 using the session key Skey EC (186) assigned to the EC, it contains・ Recover the field.
【0106】 SPはメッセージ中のECが返送した乱数RNSP-ECを、当初SPがECに送
信した(184の)乱数RNSP-ECと比較332する。乱数が等しくない場合、
ECは相互認証試験に失敗しておりメッセージは拒否334される。SPは販売
業者のアカウント情報AIMと、トランザクション金額TAのようなトランザク
ション・データを検証し、アカウント情報が無効の場合またはトランザクション
・データがSPの基準334を満たさない場合メッセージを拒否する。メッセー
ジ全体の完全性と信頼性が確立されると、SPはメッセージ中に含まれるデータ
を処理し、応答メッセージを返送することができる。このメッセージ中で返送さ
れる乱数によってSPと販売業者間、及びSPとEC間の相互認証が完了する。
このメッセージの後、乱数の交換は必要ない。SPは、販売業者とECがSPに
送信するその後のすべてのメッセージ中で使用するトランザクション識別番号と
して乱数を使用することを選択することができる。The SP compares 332 the random number RN SP-EC returned by the EC in the message with the random number RN SP-EC (at 184) that the SP originally transmitted to the EC . If the random numbers are not equal,
The EC has failed the cross-certification test and the message is rejected 334. The SP verifies the merchant's account information AI M and transaction data, such as the transaction amount TA, and rejects the message if the account information is invalid or if the transaction data does not meet the SP's criteria 334. Once the integrity and authenticity of the entire message has been established, the SP can process the data contained in the message and return a response message. The mutual authentication between the SP and the seller and between the SP and the EC is completed by the random number returned in this message.
No exchange of random numbers is necessary after this message. The SP may choose to use the random number as the transaction identification number to use in all subsequent messages that the merchant and the EC send to the SP.
【0107】 前と同様、応答メッセージはEC及び販売業者両方に関する情報を含んでいる
。ECに関するトランザクション応答メッセージをフォーマットするために、S
PはECに関する応答データ、Response DataSP-EC338を生成
し、ECに割り当てられたセッション鍵SkeyECを使用してそれを暗号化33
6する。機密データだけが暗号化される。プレーンテキストには機密応答データ
は含まれない。暗号CRYPTOSP-EC、すなわち、ESkey-EC(Respons
e DataSP-EC)は、SPが(194からの)ECに割り当てたトランザク
ション識別番号TIDSP-EC、及び、もしあればSPがECについて有するプレ
ーンテキスト344と結合340され、ECに関する応答メッセージのデータ部
分、すなわち、TIDSP-EC*PLAIN TEXTSP-EC*ESkey-EC(Res
ponse DataSP-EC)を形成する。メッセージのデータ部分は、ハッシ
ュ・アルゴリズム346に供給され、SPのプライベート鍵350を使用してS
Pによってデジタル署名されるMDSP-ECを生成する。DSSP-Private-Keyは(
340からの)応答メッセージのデータ部分と結合352され、ECについての
完全な応答メッセージ、[TIDSP-EC*PLAIN TEXTSP-EC*ESkey-E C (Response DataSP-EC)]*DSSP-Private-Keyを形成する。As before, the response message contains information about both the EC and the merchant. S to format the transaction response message for EC
P generates response data SP-EC 338 related to the EC, and encrypts it using the session key Skey EC assigned to the EC.
6 Only sensitive data is encrypted. Plain text does not include confidential response data. The cryptographic CRYPTO SP-EC , that is, E Skey-EC (Respons
e Data SP-EC ) is combined 340 with the transaction identification number TID SP-EC that the SP has assigned to the EC (from 194) and the plain text 344 that the SP has for the EC, if any, and the response message for the EC The data portion, ie, TID SP-EC * PLAIN TEXT SP-EC * E Skey-EC (Res
Pose Data SP-EC ). The data portion of the message is supplied to a hash algorithm 346, which uses the SP's private key 350
Generate MD SP-EC digitally signed by P. DS SP-Private-Key is (
340 is the data portion and the coupling 352) of the response message from the complete response message for EC, [TID SP-EC * PLAIN TEXT SP-EC * E Skey-E C (Response Data SP-EC)] * DS SP -Form a Private-Key .
【0108】 販売業者に関するトランザクション応答メッセージをフォーマットするために
、SPは販売業者に関する応答データ、Response DataSP-M356
を生成し、販売業者に割り当てられた(210からの)セッション鍵SkeyM
を使用してそれを暗号化354する。暗号CRYPTOSP-Mは、販売業者360
に割り当てられた(218からの)トランザクション識別番号TIDSP-M、及び
、もしあればSPが販売業者362について有するプレーンテキストPLAIN TEXTSP-Mと結合358され、販売業者に関する応答メッセージのデータ部
分、TIDSP-M*PLAIN TEXTSP-M*CRYPTOSP-Mを形成する。デ
ータは次にECに関する完全な応答メッセージと結合364され、ECと販売業
者両方に関する応答メッセージのデータ部分、[(TIDSP-EC*PLAIN
TEXTSP-EC*ESkey-EC(Response DataSP-EC)]*DSSP-Pr ivate-Key *[TIDSP-M*PLAIN TEXTSP-M*ESkey-M(Respo
nse DataSP-M)]を形成する。To format the transaction response message for the merchant, the SP responds to the merchant, Response Data SP-M 356.
And the session key Skey M (from 210) assigned to the merchant
To encrypt 354 it. Crypto CRYPTO SP-M is a distributor 360
The transaction identification number TID SP-M (from 218) assigned to, and the data portion of the response message about the merchant, combined 358 with the plain text PLAIN TEXT SP-M that the SP has for merchant 362, Form TID SP-M * PLAIN TEXT SP-M * CRYPTO SP-M . The data is then combined 364 with the complete response message for the EC, and the data portion of the response message for both the EC and the seller, [(TID SP-EC * PLAIN
TEXT SP-EC * E Skey-EC (Response Data SP-EC )] * DS SP- Private-Key * [TID SP-M * PLAIN TEXT SP-M * E Skey-M (Respo
ns Data SP-M )].
【0109】 データは次にハッシュ・アルゴリズム366に供給され、SPのプライベート
鍵370を使用してSPによってデジタル署名368されるMDSP-Mを生成する
。DSSP-Private-KeyはECと販売業者の両方に関する応答メッセージのデータ
部分と結合372され、EC及び販売業者両方に関する完全な応答メッセージ、
<<{[TIDSP-EC*PLAIN TEXTSP-EC*ESkey-EC(Respon
se DataSP-EC)]*DSSP-Private-Key}*[TIDSP-M*PLAIN TEXTSP-M*ESkey-M(Response DataSP-M)]>>DSSP-P rivate-Key を形成する。図10はトランザクション応答メッセージの最終フォー
マットを示す。The data is then fed to a hash algorithm 366, which uses the SP's private key 370 to generate an MD SP-M that is digitally signed 368 by the SP . The DS SP-Private-Key is combined 372 with the data portion of the response message for both EC and merchant, and a complete response message for both EC and merchant,
<< {[TID SP-EC * PLAIN TEXT SP-EC * E Skey-EC (Respon
se Data SP-EC )] * DS SP-Private-Key } * [TID SP-M * PLAIN TEXT SP-M * E Skey-M (Response Data SP-M )] >>>> DS SP- Private-Key Form. FIG. 10 shows the final format of the transaction response message.
【0110】 販売業者はメッセージを受信すると、まずメッセージ中のトランザクション識
別番号、TIDSP-Mを検査し、それが有効かを確認する。トランザクション識別
番号が無効である場合、メッセージは拒否376される。TIDSP-Mが有効であ
れば、販売業者はメッセージのデータ部分からSPによって署名されたDSSP-P rivate-Key を分離し、次にトランザクション応答メッセージのデータ部分、<<
{[TIDSP-EC*PLAIN TEXTSP-EC*ESkey-EC(Response DataSP-EC)]*DSSP-Private-Key}*[TIDSP-M*PLAIN T
EXTSP-M*ESkey-M(Response DataSP-M)]>>を一方向ハッ
シュ・アルゴリズムに供給しMDSP-Mを生じる。販売業者はメッセージのデータ
部分を別々の部分、TIDSP-M、PLAIN TEXTSP-M、CRYPTOSP-M 、DSSP-Private-Key(TIDSP-EC*PLAIN TEXTSP-EC*CRYPT
OSP-EC*DSSP-Private-Key)に分離し、SPのトランザクション応答メッセ
ージをECに転送する準備をする。販売業者はKE段階でSPによって割り当て
られたセッション鍵SkeyMを使用してSPのメッセージの暗号化部分を解読
378し、その中に含まれるデータ・フィールドを回復する。When the seller receives the message, it first checks the transaction identification number, TID SP-M , in the message to confirm whether it is valid. If the transaction identification number is invalid, the message is rejected 376. If the TID SP-M is valid, the merchant separates the DS SP- Private-Key signed by the SP from the data part of the message and then the data part of the transaction response message, <<
{[TID SP-EC * PLAIN TEXT SP-EC * E Skey-EC (Response Data SP-EC )] * DS SP-Private-Key } * [TID SP-M * PLAIN T
EXT SP-M * E Skey-M (Response Data SP-M )] >> is supplied to the one-way hash algorithm to generate MD SP-M . The merchant may separate the data portion of the message into separate portions, TID SP-M , PLAIN TEXT SP-M , CRYPTO SP-M , DS SP-Private-Key (TID SP-EC * PLAIN TEXT SP-EC * CRYPT
O SP-EC * DS SP-Private-Key ) and prepare to transfer the SP transaction response message to the EC. The merchant uses the session key SKey M assigned by the SP during the KE phase to decrypt 378 the encrypted portion of the SP's message and recover the data fields contained therein.
【0111】 販売業者は次に(144からの)SPの公開鍵、PKSPを使用してデジタル署
名DSSP-Private-Keyを解読し、MDSP-Mを回復する。販売業者は新たにハッシ
ュされた(374からの)MD∧Mを回復されたMDSP-Mと比較する。MD∧Mと
MDSP-Mが一致しない場合、トランザクション応答メッセージは破損しているの
で拒否382される。メッセージ・ダイジェストが一致する場合、販売業者はメ
ッセージの処理を開始する。通常通り、トランザクション応答メッセージのEC
部分(TIDSP-EC*PLAIN TEXTSP-EC*CRYPTOSP-EC*DSSP- Private-Key )がECに伝えられる。The seller then decrypts the digital signature DS SP-Private-Key using the SP's public key (from 144), PK SP , and recovers the MD SP-M . The merchant compares the newly hashed MD @ M (from 374) with the recovered MD SP-M . If MD @ M does not match MD SP-M , the transaction response message is rejected 382 because it is corrupted. If the message digests match, the merchant begins processing the message. EC of transaction response message as usual
The part (TID SP-EC * PLAIN TEXT SP-EC * CRYPTO SP-EC * DS SP- Private-Key ) is transmitted to the EC.
【0112】 ECがトランザクション応答メッセージを受信すると、ECはまず、メッセー
ジ中のトランザクション識別番号、TIDSP-ECを検査し、それが有効であるか
を確認する。トランザクション識別番号が無効である場合、メッセージは拒否3
96される。トランザクション識別番号が有効であれば、販売業者はトランザク
ション応答メッセージのデータ部分からSPによって署名されたDSSP-Private -Key を分離し、次にECトランザクション応答メッセージのデータ部分TIDSP -EC *PLAIN TEXTSP-EC*ESkey-EC(Response DataSP- EC )を一方向ハッシュ・アルゴリズムに供給しMD∧SP-ECを生じる。ECはメ
ッセージを別々の部分、TIDSP-EC、PLAINTSP-EC、CRYPTOSP-EC
、DSSP-Private-Keyに分離する。When the EC receives the transaction response message, the EC first checks the transaction identification number, TID SP-EC , in the message to confirm that it is valid. If the transaction identification number is invalid, the message is rejected 3
96. If the transaction identification number is valid, the merchant separates the DS SP-Private- Key signed by the SP from the data part of the transaction response message and then the data part TID SP -EC * PLAIN TEXT of the EC transaction response message. SP-EC * E Supply Skey-EC (Response Data SP- EC ) to the one-way hash algorithm to generate MD @ SP-EC . The EC separates the message into separate parts, TID SP-EC , PLAINT SP-EC , CRYPTO SP-EC
, DS SP-Private-Key .
【0113】 ECはKE段階でSPによって割り当てられたセッション鍵Skeyを使用し
てSPのメッセージの暗号化部分を解読398し、その中に含まれるデータ・フ
ィールドを回復する。ECは(120からの)SPの公開鍵を使用してデジタル
署名DSSP-Private-Keyを解読し、メッセージ・ダイジェストMDSP-ECを回復
する。販売業者は新たにハッシュされたMD∧SP-ECを回復されたMDSP-ECと比
較400する。MD∧SP-ECとMDSP-ECが一致しない場合、トランザクション応
答メッセージは破損しているので拒否402される。メッセージ・ダイジェスト
が一致する場合、ECはメッセージの処理を開始する。The EC uses the session key Skey assigned by the SP in the KE phase to decrypt 398 the encrypted portion of the SP's message and recover the data fields contained therein. The EC decrypts the digital signature DS SP-Private-Key using the SP's public key (from 120) and recovers the message digest MD SP-EC . The merchant compares 400 the newly hashed MD @ SP-EC with the recovered MD SP-EC . If the MD @ SP-EC does not match the MD SP-EC , the transaction response message is rejected 402 because it is corrupted. If the message digests match, the EC starts processing the message.
【0114】 トランザクションの終了時、ECと販売業者は、SPによって要求される場合
、肯定応答メッセージをSPに送信し、応答メッセージが正しく受信され処理さ
れたことを知らせることができる。トランザクションの終了前にSPと販売業者
及びECの間でさらに交換されるメッセージがある場合、この肯定応答データは
SPに送信される次のメッセージの一部として含まれることがある。また、肯定
応答データ自体がメッセージであることもある。At the end of the transaction, the EC and the merchant can send an acknowledgment message to the SP, if required by the SP, to indicate that the response message was received and processed correctly. If there are further messages exchanged between the SP and the merchant and EC before the end of the transaction, this acknowledgment data may be included as part of the next message sent to the SP. Also, the acknowledgment data itself may be a message.
【0115】 肯定応答メッセージをフォーマットするために、ECはまずセッション鍵、S
keyECを使用して、もしあれば、肯定応答データAcknowledgeme
nt DataECの機密部分、406を暗号化404し、SkeyEC(Ackn
owledgement DataEC)を生成する。ECは結果として得られる
暗号を、SPによって割り当てられたトランザクション識別番号TIDSP-EC4
10、及び、もしあればプレーンテキストPLAIN TEXTEC412と結合
408する。これによってECの肯定応答メッセージのデータ部分、TIDSP-E C *PLAIN TEXTEC*SkeyEC(Acknowledgement
DataEC)が形成される。To format the acknowledgment message, the EC first sets the session key, S
Using key EC , acknowledgment data Acknowledgeme, if any
The confidential part of the nt Data EC , 406, is encrypted 404, and the Skey EC (Ackn
Owlagement Data EC ). The EC converts the resulting cipher to a transaction identification number TID SP-EC 4 assigned by the SP.
10 and 408 in combination with plain text PLAIN TEXT EC 412, if any. This data portion of the acknowledgment message EC, TID SP-E C * PLAIN TEXT EC * Skey EC (Acknowledgement
Data EC ) is formed.
【0116】 この結合されたデータは次にMDECを生成する一方向ハッシュ・アルゴリズム
414に供給される。結果として得られるMDECは次に、ECのプライベート鍵
418を使用してECによってデジタル署名416され、DSEC-Private-Keyが
生成される。DSEC-Private-Keyは(408からの)メッセージのデータ部分と
結合420され、ECに関する完全な肯定応答メッセージ、[TIDSP-EC*P
LAIN TEXTEC*(Acknowledgement DataEC)]*
DSEC-Private-Keyを形成する。肯定応答メッセージは次に販売業者に送信され
る。[0116] The combined data is then fed into a one-way hash algorithm 414 to generate an MD EC. The resulting MD EC is then digitally signed 416 by the EC using the EC's private key 418 to generate a DS EC-Private-Key . The DS EC-Private-Key is combined 420 with the data portion of the message (from 408) to provide a complete acknowledgment message for the EC , [TID SP-EC * P
LAIN TEXT EC * (Acknowledgement Data EC )] *
Form DS EC-Private-Key . The acknowledgment message is then sent to the merchant.
【0117】 販売業者は同じステップを通じて自らの固有の肯定応答メッセージを形成する
。肯定応答メッセージをフォーマットするために、販売業者はまず、SPによっ
て販売業者に割り当てられたセッション鍵SkeyMを使用して、もしあれば肯
定応答データAcknowledgement DataMを暗号化し、Ske
yM(RNSP-M*Acknowledgement DataM)を生成する。販
売業者は結果として得られる暗号を、SPによって割り当てられたトランザクシ
ョン識別番号TIDSP-M390、及び、もしあれば、(392からの)プレーン
テキストPLAIN TEXTMと結合388する。これによって販売業者の肯
定応答メッセージのデータ部分、TIDSP-M*PLAIN TEXTM*Ske
yM(RNSP-M*Acknowledgement DataM)が形成される。
このデータ部分はさらにECから受信された肯定応答メッセージと結合422さ
れ、SPに関する結合肯定応答メッセージのデータ部分、{[TIDSP-EC*P
LAIN TEXTEC*SkeyEC(Acknowledgement Dat
aEC)]*DSEC-Private-Key}*[TIDSP-M*PLAIN TEXTM*S
keyM(Acknowledgement DataM)]を形成する。The merchant forms his own unique acknowledgment message through the same steps. To format the acknowledgment message, the merchant first encrypts the acknowledgment data Acknowledgment Data M , if any, using the session key SKey M assigned to the merchant by the SP, and
Generate y M (RN SP-M * Acknowledgment Data M ). The merchant combines 388 the resulting cipher with the transaction identification number TID SP-M 390 assigned by the SP , and the plaintext PLAIN TEXT M (from 392), if any. Thereby, the data part of the acknowledgment message of the seller, TID SP-M * PLAIN TEXT M * Ske
y M (RN SP-M * Acknowledgment Data M ) is formed.
This data portion is further combined 422 with the acknowledgment message received from the EC, and the data portion of the combined acknowledgment message for the SP , {[TID SP-EC * P
LAIN TEXT EC * Skey EC (Acknowledgment Dat
a EC )] * DS EC-Private-Key } * [TID SP-M * PLAIN TEXT M * S
key M (Acknowledgment Data M )].
【0118】 販売業者はSPに関する結合肯定応答メッセージのデータ部分を一方向ハッシ
ュ・アルゴリズムに供給し、メッセージ・ダイジェストMDMを生成する。結果
として得られるMDMは次に販売業者のプライベート鍵428を使用して販売業
者によってデジタル署名され、DSM-Private-Key426を生成する。DSM-Pri vate-Key は(422からの)メッセージのデータ部分と結合430され、SPに
ついて指定されたECと販売業者の最終結合肯定応答メッセージ、<<{[TI
DSP-EC*PLAIN TEXTEC*SkeyEC(Acknowledgeme
nt DataEC)]*DSEC-Private-Key}*[TIDSP-M*PLAIN T
EXTM*SkeyM(Acknowledgement DataM)]>>*
DSM-Private-Keyを形成する。このメッセージは次にSPに送信される。図1
1はトランザクション肯定応答メッセージの最終フォーマットを示す。[0118] seller supplies the data portion of the binding acknowledgment message on the SP to a one-way hash algorithm to generate a message digest MD M. The resulting MD M is digitally signed by the merchant and then using the merchant's private key 428, generates a DS M-Private-Key 426. The DS M- Private-Key is combined 430 with the data portion of the message (from 422) and the final combined acknowledgment message of the EC and merchant specified for the SP, << {[TI
D SP-EC * PLAIN TEXT EC * Skey EC (Acknowledgeme
nt Data EC )] * DS EC-Private-Key } * [TID SP-M * PLAIN T
EXT M * Skey M (Acknowledgement Data M )] >>>>
Form DS M-Private-Key . This message is then sent to the SP. FIG.
1 indicates the final format of the transaction acknowledgment message.
【0119】 TIDSP-MはSPによって販売業者に割り当てられた(218からの)トラン
ザクション識別番号であり、TIDSP-ECはSPによってECに割り当てられた
(194からの)トランザクション識別番号である。トランザクション肯定応答
メッセージを受信すると、SPはEC及び販売業者によって送信された2つのト
ランザクション識別番号TIDSP-M及びTIDSP-ECを検査し、それらが有効で
あるかを確認する。TIDSP-MまたはTIDSP-ECの何れかが無効であることが
判明すると、メッセージは拒否434される。トランザクション識別番号が両方
とも有効である場合、SPは先に進んで結合肯定応答メッセージからDSM-Priv ate-Key を分離し、結合肯定応答メッセージのデータ部分<<{[TIDSP-EC*
PLAIN TEXTEC*SkeyEC(Acknowledgement Da
taEC)]*DSEC-Private-Key}*[TIDSP-M*PLAIN TEXTM*
SkeyM(Acknowledgement DataM)]>>を、このメッ
セージのメッセージ・ダイジェストMD∧Mを計算する一方向ハッシュ・アルゴ
リズムに供給する。TID SP-M is the transaction identification number (from 218) assigned to the merchant by the SP, and TID SP-EC is the transaction identification number (from 194) assigned to the EC by the SP. Upon receiving the transaction acknowledgment message, the SP checks the two transaction identification numbers TID SP-M and TID SP-EC sent by the EC and the merchant to make sure they are valid. If either TID SP-M or TID SP-EC is found to be invalid, the message is rejected 434. If both transaction identification numbers are valid, the SP proceeds to separate the DS M-Private -Key from the binding acknowledgment message, and the data portion of the binding acknowledgment message <<<< [TID SP-EC *
PLAIN TEXT EC * Skey EC (Acknowledgment Da
ta EC )] * DS EC-Private-Key } * [TID SP-M * PLAIN TEXT M *
SKey M (Acknowledgment Data M )] >> is supplied to the one-way hash algorithm that computes the message digest MD @ M of this message.
【0120】 SPはメッセージのデータ部分TIDSP-M、PLAIN TEXTM、CRY
PTOM、DSM-Private-Key、(TIDSP-EC*PLAIN TEXTEC*CR
YPTOEC)*DSEC-Private-Keyを分離する。SPは販売業者の公開鍵PKM
を使用してDSM-Private-Keyを解読436し、回復されたメッセージ・ダイジ
ェストMDM432を計算されたばかりのMD∧M436と比較する。MD∧Mと
MDMが等しくない場合、メッセージは破損しており拒否440される。MD∧M とMDMが一致する場合、SPはKE段階で販売業者に割り当てられた(210
からの)セッション鍵SkeyMを使用して販売業者の肯定応答メッセージの暗
号化部分を解読442し、それに含まれる肯定応答データを回復する。The SP is the data part TID SP-M , PLAIN TEXT M , CRY of the message.
PTO M , DS M-Private-Key , (TID SP-EC * PLAIN TEXT EC * CR
YPTO EC ) * DS EC-Private-Key is separated. SP is the seller's public key PK M
To decrypt 436 the DS M-Private-Key and compare the recovered message digest MD M 432 with the MD @ M 436 just calculated. If MD∧ M and MD M are not equal, the message is rejected and damaged 440. If MD∧ M and MD M match, SP is assigned to the merchant by KE stage (210
Decrypts 442 the encrypted portion of the merchant's acknowledgment message using the session key Skey M ).
【0121】 SPはECの肯定応答メッセージからDSEC-Private-Keyを分離444し、E
Cの肯定応答メッセージのデータ部分、TIDSP-EC*PLAIN TEXTEC
*CRYPTOECを、このメッセージのメッセージ・ダイジェストMD∧ECを計
算する一方向ハッシュ・アルゴリズムに供給する。SPは、ECの肯定応答メッ
セージのデータ部分TIDSP-EC、PLAIN TEXTEC、CRYPTOEC、
DSEC-Private-Keyを分離する。SPはECの公開鍵PKECを使用してDSEC-P rivate-Key を解読446し、回復されたMDECを計算されたばかりのMD∧EC4
44と比較448する。メッセージ・ダイジェストが等しくない場合、メッセー
ジは破損しており拒否450される。MD∧ECとMDECが一致する場合、SPは
KE段階でECに割り当てられた(186からの)セッション鍵SkeyECを使
用してメッセージの暗号化部分を解読452し、その中に含まれる肯定応答デー
タを回復する。これによってトランザクション454のトランザクション段階の
処理が完了する。The SP separates 444 the DS EC-Private-Key from the EC acknowledgment message,
Data part of C acknowledgment message, TID SP-EC * PLAIN TEXT EC
Provide CRYPTO EC to a one-way hash algorithm that calculates the message digest MD @ EC of this message. The SP sends the data part TID SP-EC , PLAIN TEXT EC , CRYPTO EC ,
Separate DS EC-Private-Key . The SP decrypts 446 the DS EC- Private-Key using the EC's public key PK EC and returns the recovered MD EC to the just-calculated MD @ EC 4
Compare with 448. If the message digests are not equal, the message is corrupted and rejected 450. If the MD @ EC and MD EC match, the SP decrypts 452 the encrypted portion of the message using the session key Skey EC (from 186) assigned to the EC in the KE phase, and includes the acknowledgment contained therein. Recover response data. This completes the transaction phase of the transaction 454.
【0122】 トランザクションを通じて、好適実施形態では、ECはマイクロソフト・エク
スプローラー(Microsoft Explorer)またはネットスケープ
・ナビゲーター(Netscape Navigator)といったインターネ
ット・ブラウザ・ソフトウェアによって提供されるインタフェース・ソフトウェ
アと共に動作する。通常のセッションでは、カード保有者は自らのブラウザを販
売業者のURLに向け、販売業者に商品またはサービスを注文する。支払いの時
点で、ブラウザはECインタフェース・ソフトウェアを起動するが、これはブラ
ウザに組み込まれるか、またはプラグインまたはアドオンとして含まれ、トラン
ザクションを先に進めることを可能にする。カード保有者は自らのブラウザを任
意のSPメンバーのURLに向ける。Through transactions, in a preferred embodiment, the EC works with interface software provided by Internet browser software such as Microsoft Explorer or Netscape Navigator. In a typical session, the cardholder points his browser to the merchant's URL and orders the merchant for goods or services. At the time of payment, the browser launches the EC interface software, which is embedded in the browser or included as a plug-in or add-on, allowing the transaction to proceed. The cardholder points his browser to the URL of any SP member.
【0123】 上記の図6A〜図6Qで説明された2段階トランザクションは2段階鍵交換ト
ランザクション・モデルを利用する特定の場合にすぎない。図6A〜図6Qで説
明される2段階トランザクションでは、トランザクションに関与する当事者の数
は3、すなわち、EC、販売業者及びSPである。2段階鍵交換トランザクショ
ン・モデルは関与する当事者の数が2から多数にまで異なる場合にも同様に適用
可能である。3より多い当事者が関与するトランザクションでは、SPの役目を
果たす当事者は1つだけである。他の全ての当事者は選択されたSPの公開鍵を
使用して初期鍵交換を行い、SPによって割り当てられたセッション鍵とトラン
ザクションIDを使用してトランザクションを実行する。The two-stage transaction described in FIGS. 6A-6Q above is only a specific case utilizing a two-stage key exchange transaction model. 6A-6Q, the number of parties involved in the transaction is three: EC, Merchant and SP. The two-stage key exchange transaction model is equally applicable when the number of parties involved varies from two to many. In transactions involving more than three parties, only one party plays the role of SP. All other parties perform an initial key exchange using the selected SP's public key and execute the transaction using the session key and transaction ID assigned by the SP.
【0124】 2段階鍵交換トランザクション・モデルは、(1)参加者がサービス・プロバ
イダと直列の可能なルータによって配置される、または(2)参加者が階層的編
成の可能なルータによって配置される、編成スキームに適用可能である。こうし
た追加編成スキームは、メッセージを次のレベルのルーティングするルータを必
要とする。階層のレベルは任意の数の参加者及び/またはルータから構成される
。次のレベルは、順序または階層中次にある次の参加者またはルータである。階
層的編成スキームでは、次のレベルには全ての可能な次の参加者及びルータが含
まれる。階層的編成スキームの場合、SPはメッセージの送信先となる次の参加
者またはルータを決定する基準を確立する。The two-stage key exchange transaction model is: (1) participants are arranged by possible routers in series with the service provider, or (2) participants are arranged by possible routers in a hierarchical organization. , Is applicable to knitting schemes. Such additional organization schemes require routers to route messages to the next level. The levels of the hierarchy are composed of any number of participants and / or routers. The next level is the next participant or router next in the order or hierarchy. In a hierarchical organization scheme, the next level includes all possible next participants and routers. In the case of a hierarchical organization scheme, the SP establishes criteria for determining the next participant or router to which the message will be sent.
【0125】 ルータはゲートウェイ/コンジットであり、前のレベルからメッセージを収集
し、SPの要求によってメッセージを結合するといったメッセージに対する処理
を行い、メッセージをSPに転送する。各参加者は自らの固有のメッセージ(デ
ータとデジタル署名)を形成し、それを次のレベルに送信することだけが必要で
ある。参加者は自分が受信した全てのメッセージを自らの固有のメッセージと結
合し、次のレベルに送信する前に結合メッセージにデジタル署名する。階層的編
成の最も単純な形態では、全ての他の参加者からメッセージを収集し結合メッセ
ージをSPに送信する1つだけのルータが存在する。The router is a gateway / conduit, collects messages from the previous level, processes messages such as combining messages at the request of the SP, and forwards the messages to the SP. Each participant need only form their own message (data and digital signature) and send it to the next level. Participants combine every message they receive with their own unique message and digitally sign the combined message before sending it to the next level. In the simplest form of hierarchical organization, there is only one router that collects messages from all other participants and sends a combined message to the SP.
【0126】 直列編成では、トランザクションの発信者は、サービス・プロバイダ60と直
列のルータ及び/または参加者と直列である。本発明の好適実施形態では、図1
2に示される各要素は参加者である。本発明の代替実施形態では、発信者とSP
の間に中間要素がある場合それはルータのことがある。In a serial organization, the originator of the transaction is in series with a router and / or a participant in series with the service provider 60. In a preferred embodiment of the present invention, FIG.
Each element shown in 2 is a participant. In an alternative embodiment of the invention, the caller and SP
If there is an intermediate element in between, it may be a router.
【0127】 図12に示されるように、発信者は、参加者1100、1120、1140及
び1160、及び直列に配置されたサービス・プロバイダとトランザクションを
行う。これは、図6A〜図6Qで説明された3当事者シナリオと同様であるが、
ここではさらに多くの当事者が関与するという点が異なっている。直列に配置さ
れた参加者3、4、5、6...n−2に注意されたい1180。各参加者は自
らの固有のメッセージを準備し、前の参加者から自分が受信したメッセージがあ
る場合それと組み合わせ、メッセージにデジタル署名を添付し、それを回線中の
次の参加者に送信する。結合メッセージは最終的にSPに送信され、SPはそれ
に応じて応答を形成し、元のメッセージが伝えられたのと同じ経路を通じてそれ
を返送する。As shown in FIG. 12, a caller conducts a transaction with participants 1100, 1120, 1140 and 1160 and a service provider arranged in series. This is similar to the three-party scenario described in FIGS.
The difference here is that more parties are involved. Participants 3, 4, 5, 6, 5. arranged in series. . . Note 1180 to n-2. Each participant prepares his or her own message, combines it with any messages he has received from previous participants, attaches a digital signature to the message, and sends it to the next participant on the line. The combined message is finally sent to the SP, which forms a response accordingly and returns it over the same path as the original message was delivered.
【0128】 図13は階層的編成スキームで配置された要素を示すが、そこでは各要素、X 1,1 〜X1,n(n=1、2、3、...)1200はトランザクションの参加者で
あってメッセージ・ルータではなく、各要素、Xj,k(j=2、3、4、...
;k=1、2、3、...m;mは種類nの変数であり、mは異なったレベルの
階層について異なった値であることがある)1210は参加者またはルータの何
れかである。上向き太字矢印は要求メッセージ1220の送信を表し、下向き矢
印は応答メッセージ1230の送信を表す。FIG. 13 shows the elements arranged in a hierarchical organization scheme, where each element, X 1,1 ~ X1, n(N = 1, 2, 3,...) 1200 are the participants of the transaction
There is not a message router, but each element, Xj, k(J = 2, 3, 4,...
K = 1, 2, 3,. . . m; m is a variable of type n, m being different levels of
1210 is the value of the participant or router
That's it. An upward bold arrow indicates transmission of the request message 1220, and a downward arrow
The mark indicates transmission of the response message 1230.
【0129】 各参加者は自分が責任を負う多数の参加者からのメッセージを収集し、メッセ
ージを自らの固有のメッセージと結合し新しいメッセージを形成した後、新しい
メッセージを次のレベルに送信する。階層的編成スキームには1つだけの参加者
から必要に応じた多数の参加者が含まれる(階層的スキームの最も小規模な事例
は1つの参加者と1つのサービス・プロバイダである)。最終的には、サービス
・プロバイダの前の最後の要素、Xσ,1(σは種類nのものである)で、全ての
メッセージは1つのメッセージ1240に結合され、それがSP60に送信され
る。ここでも、SPは応答メッセージを形成しそれを同じ経路を通じて返送する
。Each participant collects messages from a number of participants for whom it is responsible, combines the message with its own unique message to form a new message, and sends the new message to the next level. A hierarchical organization scheme includes as many participants as needed from only one participant (the smallest case of a hierarchical scheme is one participant and one service provider). Eventually, with the last element before the service provider, Xσ , 1 (σ is of type n), all messages are combined into one message 1240, which is sent to SP60. Again, the SP forms a response message and sends it back over the same path.
【0130】 SPがトランザクションを管理しない場合、メンバーはSPによって生成され
たセッション鍵を使用して相互間でトランザクションを行う。トランザクション
は2つかそれ以上のメンバー間で行われる。トランザクションに関与する2つよ
り多いメンバーが存在する場合、メッセージはメンバーからメンバーへ任意の順
序で流れる。メンバーはトランザクション要求メッセージを送信し、トランザク
ション応答メッセージを受信する。メンバーは必ずしも自分がトランザクション
要求メッセージを送信した同じメンバーからトランザクション応答メッセージを
受信する必要はない。例えば、トランザクション中の3つのメンバーがリングに
編成され、リングを巡ってメッセージが送信されることがある。第1メンバーが
第2メンバーにトランザクション要求メッセージを送信し、次に第2メンバーが
トランザクション要求メッセージとトランザクション応答メッセージを第3メン
バーに送信する。第3メンバーはトランザクション要求メッセージとトランザク
ション応答メッセージを第1メンバーに送信し、第1メンバーはトランザクショ
ン応答メッセージを第2メンバーに送信する。トランザクション要求メッセージ
を受信したメンバーはトランザクション応答メッセージを作成し、それが最終的
にはトランザクション要求メッセージを送信したメンバーに送信される。If the SP does not manage the transaction, the members transact with each other using the session key generated by the SP. Transactions take place between two or more members. If there are more than two members involved in the transaction, the messages flow from member to member in any order. The member sends a transaction request message and receives a transaction response message. A member does not necessarily need to receive a transaction response message from the same member that sent the transaction request message. For example, three members in a transaction may be organized into a ring and messages may be sent around the ring. The first member sends a transaction request message to the second member, and then the second member sends a transaction request message and a transaction response message to the third member. The third member sends a transaction request message and a transaction response message to the first member, and the first member sends a transaction response message to the second member. The member receiving the transaction request message creates a transaction response message, which is ultimately sent to the member that sent the transaction request message.
【0131】 鍵交換段階では、SPは全てのトランザクション参加メンバーの公開鍵を得る
。参加メンバーが相互間のトランザクションを行う前に、SPは各参加メンバー
に他のメンバーの公開鍵を送信する。トランザクション要求メッセージとトラン
ザクション応答メッセージには、もしあればプレーンテキスト、暗号、及び送信
側のデジタル署名が含まれる。In the key exchange phase, the SP obtains the public keys of all transaction participants. Before the participating members conduct a transaction between each other, the SP sends each participating member the public key of the other member. The transaction request message and the transaction response message include the plaintext, encryption, if any, and the sender's digital signature.
【0132】 SPが、証明ベース外部システムを処理するためEC及び/または販売業者に
関するサロゲート証明の役目を果たす必要がある場合、SPは外部インタフェー
スの動作からEC及び/または販売業者を保護する。SPはEC及び/または販
売業者とのトランザクションを完了するために必要な情報をEC及び/または販
売業者に戻すのみとなる。If the SP needs to act as a surrogate certificate for the EC and / or merchant to process a certificate-based external system, the SP protects the EC and / or merchant from operation of the external interface. The SP will only return the necessary information to the EC and / or merchant to complete the transaction with the EC and / or merchant.
【0133】 本発明の好適及び例示的実施形態と考えられるものが本明細書で説明されたが
、本発明の他の修正も当業者には明らかであろう。従って、そうした全ての修正
及び拡張は本発明の真の精神及び範囲内にあるものとして添付の請求項で保証さ
れることが望ましい。本発明は添付の請求の範囲内にある全ての実施形態を含む
ものと考えられ、本発明は以下の添付の請求項によってのみ制限される。さらに
、本発明の精神と範囲から離れることなく他の適用業務が本明細書で示されたも
のに置換されることを当業者は容易に認識するであろう。While what has been described herein as being preferred and exemplary embodiments of the present invention, other modifications of the present invention will be apparent to those skilled in the art. It is therefore desired that all such modifications and extensions be covered by the appended claims as falling within the true spirit and scope of the invention. The invention is considered to include all embodiments that fall within the scope of the appended claims, and the invention is limited only by the following claims. Further, those skilled in the art will readily recognize that other applications may be substituted for those set forth herein without departing from the spirit and scope of the invention.
【図1】 図1は、本発明の実施例によるシステムのコンポーネント相互間の関係を示す
ブロック図である。FIG. 1 is a block diagram illustrating the relationships between components of a system according to an embodiment of the present invention.
【図2】 図2は、ネットワーク経由の2つの取引段階の流れを示す。FIG. 2 shows the flow of two transaction stages over a network.
【図3】 図3は、電子カード(EC)の図表的表現である。FIG. 3 is a diagrammatic representation of an electronic card (EC).
【図4】 図4は、サービスプロバイダのデータ領域のフォーマットを示す。サービスプ
ロバイダの情報は各々、表の中の1つのエントリに割り当てられ、アクセス条件
によって保護される。FIG. 4 shows a format of a data area of a service provider. Each service provider's information is assigned to one entry in the table and is protected by access conditions.
【図5】 図5は、本発明の実施例においてディジタル署名がどのように使用されている
かを示す。FIG. 5 illustrates how digital signatures are used in embodiments of the present invention.
【図6A】 図6Aは、本発明の実施例においてインターネットなどのオープン通信網を経由
して電子取引を行うのに使用される暗号システムと暗号法の概略的フローチャー
トを示す。FIG. 6A shows a schematic flowchart of a cryptographic system and cryptography used to conduct electronic transactions over an open communication network such as the Internet in an embodiment of the present invention.
【図6B】 図6Aと同様の図。FIG. 6B is a view similar to FIG. 6A.
【図6C】 図6Aと同様の図。FIG. 6C is a view similar to FIG. 6A.
【図6D】 図6Aと同様の図。FIG. 6D is a view similar to FIG. 6A.
【図6E】 図6Aと同様の図。FIG. 6E is a view similar to FIG. 6A.
【図6F】 図6Aと同様の図。FIG. 6F is a view similar to FIG. 6A.
【図6G】 図6Aと同様の図。FIG. 6G is a view similar to FIG. 6A.
【図6H】 図6Aと同様の図。FIG. 6H is a view similar to FIG. 6A.
【図6I】 図6Aと同様の図。FIG. 6I is a view similar to FIG. 6A.
【図6J】 図6Aと同様の図。FIG. 6J is a view similar to FIG. 6A.
【図6K】 図6Aと同様の図。FIG. 6K is a view similar to FIG. 6A.
【図6L】 図6Aと同様の図。FIG. 6L is a view similar to FIG. 6A.
【図6M】 図6Aと同様の図。FIG. 6M is a view similar to FIG. 6A.
【図6N】 図6Aと同様の図。FIG. 6N is a view similar to FIG. 6A.
【図6O】 図6Aと同様の図。FIG. 6O is a view similar to FIG. 6A.
【図6P】 図6Aと同様の図。FIG. 6P is a view similar to FIG. 6A.
【図6Q】 図6Aと同様の図。FIG. 6Q is a view similar to FIG. 6A.
【図7】 図7は、鍵交換段階と取引段階における複合的なリクエストメッセージと応答
メッセージの最終のフォーマットと内容を示す。FIG. 7 shows the final format and content of a combined request message and response message in the key exchange phase and the transaction phase.
【図8】 図7と同様の図。FIG. 8 is a view similar to FIG. 7;
【図9】 図7と同様の図。FIG. 9 is a view similar to FIG. 7;
【図10】 図7と同様の図。FIG. 10 is a view similar to FIG. 7;
【図11】 図7と同様の図。FIG. 11 is a view similar to FIG. 7;
【図12】 図12は、直列に配置された関係者と取引を行うサービスプロバイダを示す。FIG. 12 shows a service provider transacting with parties arranged in series.
【図13】 図13は、階層構造で配置された関係者とのネットワーク上でのサービスプロバ
イダ取引を示す。FIG. 13 shows a service provider transaction on a network with parties arranged in a hierarchical structure.
【手続補正書】[Procedure amendment]
【提出日】平成12年11月21日(2000.11.21)[Submission date] November 21, 2000 (2000.11.21)
【手続補正2】[Procedure amendment 2]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図1[Correction target item name] Fig. 1
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図1】 FIG.
【手続補正3】[Procedure amendment 3]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図3[Correction target item name] Figure 3
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図3】 FIG. 3
【手続補正4】[Procedure amendment 4]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図4[Correction target item name] Fig. 4
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図4】 FIG. 4
【手続補正5】[Procedure amendment 5]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図5[Correction target item name] Fig. 5
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図5】 FIG. 5
【手続補正6】[Procedure amendment 6]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6A[Correction target item name] Fig. 6A
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6A】 FIG. 6A
【手続補正7】[Procedure amendment 7]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6B[Correction target item name] FIG. 6B
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6B】 FIG. 6B
【手続補正8】[Procedure amendment 8]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6C[Correction target item name] Fig. 6C
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6C】 FIG. 6C
【手続補正9】[Procedure amendment 9]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6D[Correction target item name] Fig. 6D
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6D】 FIG. 6D
【手続補正10】[Procedure amendment 10]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6E[Correction target item name] Fig. 6E
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6E】 FIG. 6E
【手続補正11】[Procedure amendment 11]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6F[Correction target item name] Fig. 6F
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6F】 FIG. 6F
【手続補正12】[Procedure amendment 12]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6G[Correction target item name] Fig. 6G
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6G】 FIG. 6G
【手続補正13】[Procedure amendment 13]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6H[Correction target item name] Fig. 6H
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6H】 FIG. 6H
【手続補正14】[Procedure amendment 14]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6I[Correction target item name] Fig. 6I
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6I】 FIG. 6I
【手続補正15】[Procedure amendment 15]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6J[Correction target item name] Fig. 6J
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6J】 FIG. 6J
【手続補正16】[Procedure amendment 16]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6K[Correction target item name] Fig. 6K
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6K】 FIG. 6K
【手続補正17】[Procedure amendment 17]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6L[Correction target item name] FIG. 6L
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6L】 FIG. 6L
【手続補正18】[Procedure amendment 18]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6M[Correction target item name] Fig. 6M
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6M】 FIG. 6M
【手続補正19】[Procedure amendment 19]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6N[Correction target item name] Fig. 6N
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6N】 FIG. 6N
【手続補正20】[Procedure amendment 20]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6O[Correction target item name] Fig. 6O
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6O】 FIG. 6O
【手続補正21】[Procedure amendment 21]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6P[Correction target item name] Fig. 6P
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6P】 FIG. 6P
【手続補正22】[Procedure amendment 22]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図6Q[Correction target item name] Fig. 6Q
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図6Q】 FIG. 6Q
【手続補正23】[Procedure amendment 23]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図12[Correction target item name] FIG.
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図12】 FIG.
【手続補正24】[Procedure amendment 24]
【補正対象書類名】図面[Document name to be amended] Drawing
【補正対象項目名】図13[Correction target item name] FIG.
【補正方法】変更[Correction method] Change
【補正内容】[Correction contents]
【図13】 FIG. 13
───────────────────────────────────────────────────── フロントページの続き (81)指定国 EP(AT,BE,CH,CY, DE,DK,ES,FI,FR,GB,GR,IE,I T,LU,MC,NL,PT,SE),OA(BF,BJ ,CF,CG,CI,CM,GA,GN,GW,ML, MR,NE,SN,TD,TG),AP(GH,GM,K E,LS,MW,SD,SL,SZ,UG,ZW),E A(AM,AZ,BY,KG,KZ,MD,RU,TJ ,TM),AE,AL,AM,AT,AU,AZ,BA ,BB,BG,BR,BY,CA,CH,CN,CU, CZ,DE,DK,EE,ES,FI,GB,GD,G E,GH,GM,HR,HU,ID,IL,IN,IS ,JP,KE,KG,KP,KR,KZ,LC,LK, LR,LS,LT,LU,LV,MD,MG,MK,M N,MW,MX,NO,NZ,PL,PT,RO,RU ,SD,SE,SG,SI,SK,SL,TJ,TM, TR,TT,UA,UG,US,UZ,VN,YU,Z A,ZW──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR , BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS , JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, ZA, ZW
Claims (41)
領域とを有する電子カードと、 前記電子カードに応答するサービス・プロバイダ・メンバー端末と、 サービス・プロバイダ情報を伝えるサービス・プロバイダ端末とを具備する電
子商取引用のシステム。1. An electronic commerce system, comprising: a cryptographic service for encryption and decryption; a data area for storing information; and a data area for storing a cardholder having a service provider member terminal. An electronic commerce system comprising: an electronic card, a service provider member terminal responding to the electronic card, and a service provider terminal transmitting service provider information.
テム。2. The system according to claim 1, wherein said electronic card is a physical card.
求項1に記載のシステム。3. The system according to claim 1, further comprising software having said electronic card.
新し、PINを変更し、前記サービス・プロバイダ・データ領域を管理するカー
ド・オペレーティング・システムを備える、請求項1に記載のシステム。4. The electronic card of claim 1, wherein the electronic card further comprises a card operating system for loading and updating cardholder information, changing a PIN, and managing the service provider data area. system.
プロトコル処理を行う、請求項1に記載のシステム。5. The system of claim 1, wherein the electronic card performs external communication read / write operations and communication protocol processing.
ウェアを備える、請求項1に記載のシステム。6. The system according to claim 1, wherein the electronic card further comprises software for managing the electronic card.
えるサービス・プロバイダ記録を備える、請求項1に記載のシステム。7. A service provider record in which said data area for storing service provider information comprises: a name field indicating said service provider; a key figure; and an account information field containing information specific to each service provider. The system of claim 1, comprising:
備える、請求項1に記載のシステム。8. The system of claim 1, wherein the electronic card further comprises application software.
載のシステム。9. The system of claim 1, wherein the electronic card further comprises an applet.
イダ端末が前記外部システムと通信する、請求項1に記載のシステム。10. The system of claim 1, further comprising an external system, wherein the service provider terminal communicates with the external system.
イダがサポートする器具の種類を指定するカード種類フィールドを備える、請求
項7に記載のシステム。11. The system of claim 7, wherein each service provider record further comprises a card type field that specifies the type of equipment supported by the service provider.
ら前記メンバーにセッション鍵を送信することによって鍵を交換するステップと
、 トランザクションを行うために前記セッション鍵を使用するステップとを具備
する電子商取引用の方法。12. A method for e-commerce using an electronic card, the method comprising: generating a session key at the service provider; transmitting a key from a member to a service provider and transmitting the key from the service provider to the member. A method for e-commerce, comprising: exchanging a key by transmitting a session key; and using the session key to conduct a transaction.
プと、 メンバーに関する前記セッション鍵を含む鍵交換応答をフォーマットし前記鍵
交換応答をメンバーに送信するステップとを含む、請求項12に記載の方法。13. The method of exchanging keys, comprising: transmitting a key exchange request message from a member to a service provider; formatting a key exchange response including the session key for the member and transmitting the key exchange response to the member. 13. The method of claim 12, comprising:
記ステップが、 前記セッション鍵を使用してメンバー・トランザクション要求メッセージをフ
ォーマットしそれを前記サービス・プロバイダに送信するステップと、 前記サービス・プロバイダで、前記メンバーに関するトランザクション応答メ
ッセージをフォーマットし前記トランザクション応答メッセージを前記メンバー
に送信するステップとを含む、請求項12に記載の方法。14. Using the session key to perform a transaction, using the session key to format a member transaction request message and sending it to the service provider. And formatting the transaction response message for the member and sending the transaction response message to the member.
記ステップが、 第1メンバーによって、前記セッション鍵を使用して、前記第1メンバーのデ
ジタル署名を含むトランザクション要求メッセージをフォーマットし、前記トラ
ンザクション要求メッセージを第2メンバーに送信するステップと、 第2メンバーによって、前記セッション鍵を使用して、前記第2メンバーのデ
ジタル署名を含むトランザクション応答メッセージをフォーマットし、前記トラ
ンザクション応答メッセージを前記第1メンバーに送信するステップとを含む、
請求項12に記載の方法。15. The method of claim 1, wherein the step of using the session key to perform a transaction comprises: formatting, by the first member, a transaction request message including the first member's digital signature using the session key; Sending a request message to a second member; using the session key by the second member to format a transaction response message including the digital signature of the second member; and transmitting the transaction response message to the first member Sending to
The method according to claim 12.
記ステップが、 第1メンバーによって、前記セッション鍵を使用して、前記第1メンバーのデ
ジタル署名を含むトランザクション要求メッセージをフォーマットし、前記トラ
ンザクション要求メッセージを中間メンバーに送信するステップと、 中間メンバーによって、前記セッション鍵を使用して、前記中間メンバーのデ
ジタル署名を含むトランザクション応答メッセージをフォーマットし、前記トラ
ンザクション応答メッセージを最終メンバーに送信するステップと、 最終メンバーによって、前記セッション鍵を使用して、前記最終メンバーのデ
ジタル署名を含むトランザクション応答メッセージをフォーマットし、前記トラ
ンザクション応答メッセージを前記第1メンバーに送信するステップを含む、請
求項12に記載の方法。16. The method of claim 1, wherein the step of using a session key to perform a transaction comprises: formatting, by a first member, a transaction request message including the first member's digital signature using the session key; Sending a request message to the intermediate member; using the session key by the intermediate member to format a transaction response message that includes the intermediate member's digital signature; and transmitting the transaction response message to the final member. Formatting, by the last member, a transaction response message including the digital signature of the last member using the session key; 13. The method according to claim 12, comprising transmitting to one member.
と、 前記販売業者端末で、販売業者鍵交換要求メッセージを前記電子カードの鍵交
換要求メッセージと結合し、結合鍵交換要求メッセージをサービス・プロバイダ
に送信するステップと、 前記販売業者端末に関する前記セッション鍵を含む鍵交換応答をフォーマット
し、前記電子カードに関する前記セッション鍵を含む鍵交換応答をフォーマット
し、前記鍵交換応答を結合鍵交換応答に結合し、前記結合鍵交換応答を前記販売
業者端末に送信するステップと、 前記販売業者端末で、前記電子カード・システムに関する前記鍵交換応答から
前記販売業者に関する前記鍵交換応答を分離し、前記電子カードに関する前記鍵
交換応答を前記電子カードに転送するステップとを含む、請求項12に記載の方
法。17. The method of exchanging a key, comprising: transmitting a key exchange request message from the electronic card to a distributor terminal; and transmitting a distributor key exchange request message to the electronic card at the distributor terminal. Combining with a request message and sending a combined key exchange request message to a service provider; formatting a key exchange response including the session key for the merchant terminal and including the session key for the electronic card Formatting the key exchange response into a combined key exchange response and transmitting the combined key exchange response to the merchant terminal; and at the merchant terminal, from the key exchange response for the electronic card system. Separate the key exchange response for the merchant, and And transferring key exchange response to the electronic card, the method of claim 12.
記ステップが、 前記セッション鍵を使用して前記電子カードのトランザクション要求メッセー
ジをフォーマットしそれを前記販売業者端末に送信するステップと、 前記販売業者の端末で、前記セッション鍵を使用して、前記販売業者トランザ
クション要求メッセージをフォーマットし、受信トランザクション要求メッセー
ジを前記販売業者トランザクション要求メッセージと結合し、前記結合トランザ
クション要求メッセージを前記サービス・プロバイダに送信するステップと、 前記サービス・プロバイダによって、前記セッション鍵を使用して、前記販売
業者に関するトランザクション応答メッセージと前記電子カード・システムに関
するトランザクション応答メッセージをフォーマットし、前記トランザクション
応答メッセージを結合トランザクション応答メッセージに結合し、前記結合トラ
ンザクション応答メッセージを前記販売業者端末に送信するステップと、 前記販売業者端末で、前記電子カードに関する前記トランザクション応答メッ
セージから前記販売業者に関する前記トランザクション応答メッセージを分離し
、前記電子カード・システムに関する前記トランザクション応答メッセージを前
記電子カードに転送するステップとを含む、請求項12に記載の方法。18. Using the session key to perform a transaction, using the session key to format a transaction request message for the electronic card and transmitting it to the merchant terminal; At the merchant terminal, use the session key to format the merchant transaction request message, combine the incoming transaction request message with the merchant transaction request message, and send the combined transaction request message to the service provider Using the session key by the service provider to provide a transaction response message for the merchant and a transaction response message for the electronic card system. Formatting the message, combining the transaction response message into a combined transaction response message, and transmitting the combined transaction response message to the merchant terminal; and at the merchant terminal, the transaction response message for the electronic card from the transaction response message. Isolating the transaction response message for a merchant and forwarding the transaction response message for the electronic card system to the electronic card.
する時、前記サービス・プロバイダだけがメンバーから送信されたメッセージ中
の機密トランザクション・データを読むことができる、請求項12に記載の方法
。19. The method of claim 12, wherein when the service provider manages the transaction, only the service provider can read confidential transaction data in a message sent by a member.
しない時、前記サービス・プロバイダだけが鍵交換段階中メンバーから送信され
たメッセージ中の機密データを読むことができる、請求項12に記載の方法。20. The method of claim 12, wherein when the service provider does not manage the transaction, only the service provider can read sensitive data in messages sent from members during the key exchange phase. .
らゆるメンバーに関する公開鍵を備える、請求項13に記載の方法。21. The method of claim 13, wherein the key exchange response further comprises a public key for every member involved in the transaction.
部分中にメンバー生成乱数を含む、請求項13に記載の方法。22. The method of claim 13, wherein the key exchange request message includes a member generated random number in an encrypted portion of the key exchange message.
、請求項13に記載の方法。23. The method of claim 13, wherein the key exchange request message includes a member generated digital signature.
メッセージの暗号化部分中に乱数を含む、請求項14に記載の方法。25. The method according to claim 25, wherein the transaction message is
15. The method of claim 14, wherein a random number is included in the encrypted portion of the message.
含む、請求項14に記載の方法。26. The method of claim 14, wherein the transaction message includes a sender's digital signature.
セージ中の機密トランザクション・データを読むことができる、請求項14に記
載の方法。27. The method of claim 14, wherein only the service provider can read sensitive transaction data in a transaction message.
セージをフォーマットし、前記トランザクション肯定応答メッセージを前記サー
ビス・プロバイダに送信するステップを含む、請求項14に記載の方法。28. The method of claim 14, further comprising formatting a transaction acknowledgment message at the member using the session key and sending the transaction acknowledgment message to the service provider. .
メッセージをフォーマットし、前記トランザクション肯定応答メッセージを前記
販売業者に送信するステップと、 前記販売業者の端末で、前記セッション鍵を使用して、前記販売業者トランザ
クション肯定応答メッセージをフォーマットし、受信トランザクション肯定応答
メッセージを前記販売業者トランザクション肯定応答メッセージと結合し、前記
結合トランザクション肯定応答メッセージを前記サービス・プロバイダに送信す
るステップとを含む、請求項18に記載の方法。29. Formatting a transaction acknowledgment message at the electronic card using the session key and transmitting the transaction acknowledgment message to the merchant; and at the merchant terminal, Using the session key, format the merchant transaction acknowledgment message, combine a received transaction acknowledgment message with the merchant transaction acknowledgment message, and send the combined transaction acknowledgment message to the service provider 19. The method of claim 18, comprising:
える、請求項24に記載の方法。30. The method of claim 24, wherein the key exchange request message further comprises plain text.
名を含む、請求項24に記載の方法。31. The method of claim 24, wherein the key exchange request message further includes a digital signature of the member.
24に記載の方法。32. The method of claim 24, wherein the cipher further comprises the member's public key.
含む、請求項25に記載の方法。33. The method of claim 25, wherein the transaction message includes a sender's digital signature.
電子カードによって、乱数、電子カード公開鍵、及び電子カード機密トランザク
ション・データを暗号化するステップと、 電子カード結合メッセージを形成するために、前記電子カードによって、前記
電子カード暗号をもしあればプレーンテキストと結合するステップと、 電子カード・メッセージ・ダイジェストを形成するために、前記電子カード結
合メッセージにハッシュ・アルゴリズムを適用するステップと、 電子カード・デジタル署名メッセージを形成するために、前記電子カードによ
って、前記電子カード・プライベート鍵を使用して前記電子カード・メッセージ
・ダイジェストにデジタル署名するステップと、 前記電子カードからの鍵交換メッセージを形成するために、前記電子カードに
よって、前記電子カード結合メッセージを前記電子カード・デジタル署名メッセ
ージと結合するステップと、 前記電子カードから販売業者にネットワークを通じて前記電子カード鍵交換メ
ッセージを送信するステップとを含む方法。34. A method for transmitting a key exchange message, the method comprising: satisfying an electronic card access condition by an electronic card holder; selecting a service provider by the electronic card holder; Generating a random number, an electronic card public key, and electronic card confidential transaction data with the electronic card with a service provider public key to form an electronic card encryption. Combining the electronic card encryption with plain text, if any, by the electronic card to form an electronic card combining message; and forming the electronic card combining message to form an electronic card message digest. Hash A Applying an algorithm; digitally signing the electronic card message digest with the electronic card using the electronic card private key to form an electronic card digital signature message; Combining the electronic card combination message with the electronic card digital signature message by the electronic card to form a key exchange message from the card; and the electronic card key exchange from the electronic card to a merchant over a network. Sending the message.
り前記販売業者装置によって、販売業者乱数、販売業者公開鍵、及び販売業者機
密データを暗号化するステップと、 販売業者結合メッセージを形成するために、前記販売業者装置によって、前記
販売業者暗号をもしあればプレーンテキストと結合するステップと、 EC−販売業者結合メッセージを形成するために、前記販売業者によって、前
記電子カード(EC)鍵交換メッセージを前記販売業者結合メッセージと結合す
るステップと、 販売業者メッセージ・ダイジェストを形成するために、前記EC−販売業者結
合メッセージにハッシュ・アルゴリズムを適用するステップと、 販売業者デジタル署名メッセージを形成するために、前記販売業者装置によっ
て前記販売業者プライベート鍵を使用して前記販売業者メッセージ・ダイジェス
トにデジタル署名するステップと、 前記販売業者からの販売業者鍵交換要求メッセージを形成するために、前記販
売業者によって、前記EC−販売業者結合メッセージを前記販売業者デジタル署
名メッセージと結合するステップと、 前記販売業者からサービス・プロバイダにネットワークを通じて前記販売業者
鍵交換要求メッセージを送信するステップとを含む、請求項34に記載の方法。35. A method for generating a seller random number by a seller device, comprising the steps of: generating a seller random number; Encrypting the merchant public key and merchant confidential data; combining the merchant encryption with plain text, if any, by the merchant device to form a merchant association message; Combining the electronic card (EC) key exchange message with the merchant binding message by the merchant to form a merchant merging message; and forming the merchant message digest by the EC-key. Applying the hash algorithm to the merchant join message Digitally signing the merchant message digest with the merchant device using the merchant private key to form a merchant digital signature message; and a merchant key exchange request message from the merchant. Combining, by the merchant, the EC-merchant combination message with the merchant digital signature message; and transmitting the merchant key exchange request message from the merchant to a service provider over a network. 35. The method of claim 34, comprising:
データを備える、サービス・プロバイダ公開鍵によって暗号化された電子カード
暗号と、 前記電子カード・プレーンテキスト及び前記電子カード暗号の電子カード・デ
ジタル署名と、 販売業者プレーンテキストと、 販売業者乱数、販売業者公開鍵、及び販売業者機密トランザクション・データ
の、前記サービス・プロバイダ公開鍵によって暗号化された販売業者暗号と、 前記販売業者プレーンテキスト及び前記販売業者暗号の販売業者デジタル署名
とを備える鍵交換要求メッセージ。36. A key exchange request message, comprising: an electronic card plain text, an electronic card random number, an electronic card public key, and an electronic card confidential transaction.
An electronic card encryption encrypted with a service provider public key comprising data; an electronic card digital signature of the electronic card plaintext and the electronic card encryption; a seller plaintext; a seller random number; a seller A key exchange request message comprising a public key and a vendor encryption of the vendor sensitive transaction data encrypted with the service provider public key, and a vendor digital signature of the vendor plaintext and the vendor encryption. .
と、 ECに関するSPトランザクション識別番号と、 EC乱数、ECに関するSP乱数、セッション鍵、及びECに関するSP機密
トランザクション・データの、EC公開鍵によって暗号化されたECに関するS
P暗号と、 ECに関する前記SPプレーンテキスト、ECに関する前記SPトランザクシ
ョン識別番号、及びECに関する前記SP暗号のSPデジタル署名と、 販売業者に関するSPプレーンテキストと、 販売業者に関するSPトランザクション識別番号と、 販売業者乱数、販売業者に関するSP乱数、セッション鍵、及び販売業者に関
するSP機密データの、販売業者公開鍵によって暗号化された販売業者に関する
SP暗号と、 販売業者に関する前記SPプレーンテキスト、販売業者に関する前記SPトラ
ンザクション識別番号、及び前記販売業者に関する前記SP暗号のSPデジタル
署名とを備える鍵交換応答メッセージ。37. A key exchange response message, comprising: a service provider (SP) plain text for an electronic card (EC), an SP transaction identification number for an EC, an EC random number, an SP random number for an EC, a session key, and an EC. Of the SP confidential transaction data of the EC related to the EC
P cipher, the SP plaintext for EC, the SP transaction identification number for EC, and the SP digital signature of the SP cipher for EC, SP plaintext for seller, SP transaction identification number for seller, seller The SP cipher for the seller, encrypted with the seller public key, of the random number, the SP random number for the seller, the session key, and the SP secret data for the seller, and the SP plain text for the seller, and the SP transaction for the seller. A key exchange response message comprising an identification number and an SP digital signature of the SP cipher for the merchant.
行う方法であって、 第1当事者がメッセージ・ルータまたは参加者である時、電子カードから前記
第1当事者に鍵交換要求メッセージを送信するステップと、 前記第1当事者がルータである場合、前記第1当事者から次の当事者に前記鍵
交換要求メッセージを送信するステップと、 前記第1当事者が参加者である場合、第1当事者の鍵交換要求メッセージを前
記電子カードの鍵交換要求メッセージと結合し、結合鍵交換要求メッセージを次
の当事者に送信するステップと、 現在の当事者がメッセージ・ルータである場合、前記鍵交換要求メッセージを
次の当事者に送信するステップと、 現在の当事者が参加者である場合、現在の当事者の鍵交換要求メッセージを1
つ前の当事者の鍵交換要求メッセージと結合し、結合鍵交換要求メッセージを次
の当事者に送信するステップと、 サービス・プロバイダによって、各参加者に関する鍵交換応答を1つのメッセ
ージにフォーマットし、前記鍵交換要求メッセージを前記サービス・プロバイダ
に送信する経路と逆の順序で前記メッセージを送信するステップと、 あらゆる参加者によって、他の参加者に関する前記鍵交換応答からそれ自体に
関する前記鍵交換応答を分離し、前記電子カードがその鍵交換応答を受信するま
で、前記鍵交換要求メッセージを前記サービス・プロバイダに送信する経路と逆
の順序で残りの前記鍵交換応答を他の参加者に転送するステップとを含む方法。38. A method for conducting an electronic transaction between a plurality of parties arranged in series, comprising: when a first party is a message router or a participant, sending a key exchange request message from the electronic card to the first party. Transmitting, if the first party is a router, transmitting the key exchange request message from the first party to a next party; and, if the first party is a participant, Combining the key exchange request message with the key exchange request message of the electronic card and sending the combined key exchange request message to the next party; if the current party is a message router, the key exchange request message is Sending the current party's key exchange request message to the current party if the current party is a participant.
Combining the key exchange request message with the previous party's key exchange request message and sending the combined key exchange request message to the next party; formatting the key exchange response for each participant into one message by the service provider; Sending the exchange request message to the service provider in the reverse order of transmitting the message; separating the key exchange response for itself from the key exchange response for other participants by any participant. Forwarding the remaining key exchange responses to other participants in the reverse order of the path for transmitting the key exchange request message to the service provider until the electronic card receives the key exchange response. Including methods.
行う方法であって、 第1当事者がメッセージ・ルータまたは参加者である時、電子カードから前記
第1当事者にトランザクション要求メッセージを送信するステップと、 前記第1当事者がルータである場合、前記第1当事者から次の当事者に前記ト
ランザクション要求メッセージを送信するステップと、 前記第1当事者が参加者である場合、第1当事者のトランザクション要求メッ
セージを前記電子カードのトランザクション要求メッセージと結合し、結合トラ
ンザクション要求メッセージを次の当事者に送信するステップと、 現在の当事者がメッセージ・ルータである場合、前記トランザクション要求メ
ッセージを次の当事者に送信するステップと、 現在の当事者が参加者である場合、現在の当事者のトランザクション要求メッ
セージを1つ前の当事者のトランザクション要求メッセージと結合し、結合トラ
ンザクション要求メッセージを次の当事者に送信するステップと、 サービス・プロバイダによって、各参加者に関するトランザクション応答を1
つのメッセージにフォーマットし、前記トランザクション要求メッセージを前記
サービス・プロバイダに送信する経路と逆の順序で前記メッセージを送信するス
テップと、 あらゆる参加者によって、他の参加者に関するトランザクション応答からそれ
自体に関するトランザクション応答を分離し、前記電子カードがそのトランザク
ション応答を受信するまで、前記トランザクション要求メッセージを前記サービ
ス・プロバイダに送信する経路と逆の順序で残りのトランザクション応答を他の
参加者に転送するステップとを含む方法。39. A method for conducting an electronic transaction between a plurality of parties arranged in series, wherein when the first party is a message router or a participant, sending a transaction request message from the electronic card to the first party. Transmitting the transaction request message from the first party to a next party if the first party is a router; and a transaction request of the first party if the first party is a participant. Combining a message with a transaction request message of the electronic card and sending a combined transaction request message to a next party; and sending the transaction request message to a next party if the current party is a message router. And the present Is a participant, combining the transaction request message of the current party with the transaction request message of the previous party and sending the combined transaction request message to the next party; Transaction response for 1
Sending the transaction request message to the service provider in the reverse order of formatting the message into one message and transmitting the transaction request message to the service provider by any participant from a transaction response for another participant to itself. And forwarding the remaining transaction responses to the other participants in the reverse order of the path that sends the transaction request message to the service provider until the electronic card receives the transaction response. Method.
ョンを行う方法であって、 第1当事者がメッセージ・ルータまたは参加者である時、電子カードから前記
第1当事者に鍵交換要求メッセージを送信するステップと、 前記第1当事者がメッセージ・ルータである場合、前記鍵交換要求メッセージ
を次の当事者Xj,k(j=2、3、4、...;k=1、2、3、...m;m
は種類nの変数;n=1、2、3、...;mはjの異なった値に対して異なっ
た値のことがある)に送信するステップと、 前記第1当事者が参加者である場合、第1当事者の鍵交換要求メッセージを前
記電子カードの鍵交換要求メッセージと結合し、結合鍵交換要求メッセージを次
の当事者Xj,kに送信するステップと、 現在の当事者Xj,kがメッセージ・ルータである場合、前記鍵交換要求メッセ
ージを次の当事者Xj,kに送信するステップと、 現在の当事者Xj,kが参加者である場合、現在の当事者Xj,kの鍵交換要求メッ
セージを1つ前の当事者の鍵交換要求メッセージと結合し、結合鍵交換要求メッ
セージを次の当事者Xj,kに送信するステップと、 サービス・プロバイダによって、各参加者に関する鍵交換応答を1つのメッセ
ージにフォーマットし、前記鍵交換要求メッセージを前記サービス・プロバイダ
に送信する経路と逆の順序で前記メッセージを送信するステップと、 あらゆる参加者によって、他の参加者に関する鍵交換応答からそれ自体に関す
る鍵交換応答を分離し、前記電子カードがその鍵交換応答を受信するまで、前記
鍵交換要求メッセージを前記サービス・プロバイダに送信する経路と逆の順序で
残りの鍵交換応答を他の参加者に転送するステップとを含む方法。40. A method for conducting an electronic transaction between a number of parties arranged in a hierarchical organization, wherein when the first party is a message router or a participant, a key exchange request from the electronic card to the first party. Sending a message, and if the first party is a message router, sending the key exchange request message to the next party X j, k (j = 2, 3, 4,...; K = 1, 2) , 3, ... m; m
Are variables of type n; n = 1, 2, 3,. . . M may be different for different values of j), and if the first party is a participant, a key exchange request message of the first party for the key of the electronic card Combining with the exchange request message and sending the combined key exchange request message to the next party X j, k , if the current party X j, k is a message router, the key exchange request message to the next party X j, k transmitting X j, the k, the current party X j, k be a participant, combined with the current party X j, k of the previous one the key exchange request message party key exchange request message Sending a combined key exchange request message to the next party X j, k , formatting the key exchange response for each participant into one message by the service provider, Sending the message in reverse order to the path to send to the service provider; separating the key exchange response for itself from the key exchange response for other participants by any participant; Forwarding the remaining key exchange responses to other participants in the reverse order of the route of transmitting the key exchange request message to the service provider until the key exchange response is received.
ョンを行う方法であって、 第1当事者がメッセージ・ルータまたは参加者である時、電子カードから前記
第1当事者にトランザクション要求メッセージを送信するステップと、 前記第1当事者がメッセージ・ルータである場合、前記トランザクション要求
メッセージを次の当事者Xj,k(j=2、3、4、...;k=1、2、3、.
..m;mは種類nの変数;n=1、2、3、...;mはjの異なった値に対
して異なった値のことがある)に送信するステップと、 前記第1当事者が参加者である場合、第1当事者のトランザクション要求メッ
セージを前記電子カードのトランザクション要求メッセージと結合し、結合トラ
ンザクション要求メッセージを次の当事者Xj,kに送信するステップと、 現在の当事者Xj,kがメッセージ・ルータである場合、前記トランザクション
要求メッセージを次の当事者Xj,kに送信するステップと、 現在の当事者Xj,kが参加者である場合、現在の当事者Xj,kのトランザクショ
ン要求メッセージを1つ前の当事者のトランザクション要求メッセージと結合し
、結合トランザクション要求メッセージを次の当事者Xj,kに送信するステップ
と、 サービス・プロバイダによって、各参加者に関するトランザクション応答を1
つのメッセージにフォーマットし、前記トランザクション要求メッセージを前記
サービス・プロバイダに送信する経路と逆の順序で前記メッセージを送信するス
テップと、 あらゆる参加者によって、他の参加者に関するトランザクション応答からそれ
自体に関するトランザクション応答を分離し、前記電子カードがそのトランザク
ション応答を受信するまで、前記トランザクション要求メッセージを前記サービ
ス・プロバイダに送信する経路と逆の順序で残りのトランザクション応答を他の
参加者に転送するステップとを含む方法。41. A method for conducting an electronic transaction between a number of parties arranged in a hierarchical arrangement, wherein when the first party is a message router or a participant, a transaction request message from the electronic card to the first party. And transmitting the transaction request message to the next party X j, k (j = 2,3,4, ...; k = 1,2,3 if the first party is a message router ,.
. . m; m is a variable of type n; n = 1, 2, 3,. . . M may be different values for different values of j), and if the first party is a participant, a first party transaction request message to the electronic card transaction request. Combining the transaction request message with the next party X j, k and, if the current party X j, k is a message router, combining the transaction request message with the next party X j, k And, if the current party X j, k is a participant, combining the transaction request message of the current party X j, k with the transaction request message of the immediately preceding party and combining the combined transaction request message Sending to the next party X j, k , by the service provider, for each participant 1 for transaction response
Sending the transaction request message to the service provider in the reverse order of formatting the message into one message and transmitting the transaction request message to the service provider by any participant from a transaction response for another participant to itself. And forwarding the remaining transaction responses to the other participants in the reverse order of the path that sends the transaction request message to the service provider until the electronic card receives the transaction response. Method.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US8425798P | 1998-05-05 | 1998-05-05 | |
US60/084,257 | 1998-05-05 | ||
PCT/US1999/009938 WO1999057835A1 (en) | 1998-05-05 | 1999-05-05 | A cryptographic system and method for electronic transactions |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004270384A Division JP2005065315A (en) | 1998-05-05 | 2004-09-16 | Encryption method for electronic commerce |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2002514839A true JP2002514839A (en) | 2002-05-21 |
Family
ID=22183802
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000547720A Pending JP2002514839A (en) | 1998-05-05 | 1999-05-05 | Cryptographic system and method for electronic commerce |
JP2004270384A Pending JP2005065315A (en) | 1998-05-05 | 2004-09-16 | Encryption method for electronic commerce |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004270384A Pending JP2005065315A (en) | 1998-05-05 | 2004-09-16 | Encryption method for electronic commerce |
Country Status (8)
Country | Link |
---|---|
JP (2) | JP2002514839A (en) |
CN (2) | CN101087189A (en) |
AU (1) | AU762708B2 (en) |
CA (1) | CA2329032C (en) |
GB (1) | GB2353623B (en) |
HK (1) | HK1038657A1 (en) |
TW (1) | TW476202B (en) |
WO (1) | WO1999057835A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016500491A (en) * | 2012-12-06 | 2016-01-12 | クアルコム,インコーポレイテッド | Managing network devices that use authorization tokens |
WO2017175926A1 (en) * | 2016-04-05 | 2017-10-12 | 삼성전자 주식회사 | Electronic payment method and electronic device using id-based public key cryptography |
KR20170114905A (en) * | 2016-04-05 | 2017-10-16 | 삼성전자주식회사 | Elecronic device and electronic payement method using id-based public key cryptography |
Families Citing this family (27)
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 |
AU2005203599B2 (en) * | 2000-02-14 | 2007-03-08 | Yong Kin Ong (Michael) | Electronic funds transfer |
AU2001233484B2 (en) * | 2000-02-14 | 2005-05-12 | Ong, Yong Kin | Electronic funds transfers - zipfund |
FR2805913B1 (en) * | 2000-03-01 | 2002-08-09 | Ingenico Sa | PAYMENT TERMINAL ON LOCAL AREA |
FR2807552B1 (en) * | 2000-04-11 | 2004-01-09 | France Telecom | PAYMENT CLOCK TERMINAL ON PAID PARKING OF A MOTOR VEHICLE |
US7024395B1 (en) | 2000-06-16 | 2006-04-04 | Storage Technology Corporation | Method and system for secure credit card transactions |
AU2001287164B2 (en) * | 2000-08-04 | 2008-06-26 | First Data Corporation | Method and system for using electronic communications for an electronic contact |
JP2002158650A (en) | 2000-11-21 | 2002-05-31 | Fujitsu Ltd | Proxy server for certification/ciphering processing, access card program recording medium and portable terminal |
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 (en) * | 2002-06-25 | 2007-09-19 | ソニー株式会社 | Information storage device, memory access control method, and computer program |
JP2004171416A (en) * | 2002-11-21 | 2004-06-17 | Ntt Docomo Inc | Communication terminal, value substance providing server, application distribution server, electronic purchase support system, electronic purchase support method and electronic purchase support program |
ES2244283B1 (en) * | 2003-05-23 | 2007-02-16 | Fco. Manuel Cansino Fernandez | ELECTRONIC TRANSACTION SYSTEM. |
US7613915B2 (en) * | 2006-11-09 | 2009-11-03 | BroadOn Communications Corp | Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed |
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 (en) * | 2009-12-21 | 2012-11-14 | ***通信集团公司 | Method and system for realizing all-purpose card system and smart card |
CN102568097B (en) * | 2010-12-08 | 2017-02-22 | 邵通 | Method and system for improving safety of electronic wallets |
CN103108245B (en) * | 2011-11-15 | 2016-09-28 | ***股份有限公司 | A kind of intelligent television pays cipher key system and method for payment based on intelligent television |
US9792451B2 (en) | 2011-12-09 | 2017-10-17 | Echarge2 Corporation | System and methods for using cipher objects to protect data |
CN103942688A (en) * | 2014-04-25 | 2014-07-23 | 天地融科技股份有限公司 | Data security interactive system |
CN104243171A (en) * | 2014-10-15 | 2014-12-24 | 北京奇虎科技有限公司 | Method and device for full-text protection and verification of feedback data |
US11386409B2 (en) | 2016-03-04 | 2022-07-12 | Sertintyone Corporation | Systems and methods for media codecs and containers |
US10742419B2 (en) * | 2016-03-15 | 2020-08-11 | Visa International Service Association | Validation cryptogram for transaction |
Family Cites Families (7)
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 |
US5544246A (en) * | 1993-09-17 | 1996-08-06 | At&T Corp. | Smartcard adapted for a plurality of service providers and for remote installation of same |
JP3348753B2 (en) * | 1994-04-28 | 2002-11-20 | 日本電信電話株式会社 | Encryption key distribution system and method |
US5537474A (en) * | 1994-07-29 | 1996-07-16 | Motorola, Inc. | Method and apparatus for authentication in a communication system |
JP3498268B2 (en) * | 1994-09-14 | 2004-02-16 | 日本電信電話株式会社 | Document communication management method |
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 |
-
1999
- 1999-05-05 WO PCT/US1999/009938 patent/WO1999057835A1/en active IP Right Grant
- 1999-05-05 JP JP2000547720A patent/JP2002514839A/en active Pending
- 1999-05-05 GB GB0026755A patent/GB2353623B/en not_active Expired - Fee Related
- 1999-05-05 CN CNA2007100063782A patent/CN101087189A/en active Pending
- 1999-05-05 AU AU43075/99A patent/AU762708B2/en not_active Ceased
- 1999-05-05 CA CA002329032A patent/CA2329032C/en not_active Expired - Fee Related
- 1999-05-05 CN CNB998070726A patent/CN1307818C/en not_active Expired - Fee Related
- 1999-11-04 TW TW88119209A patent/TW476202B/en not_active IP Right Cessation
-
2002
- 2002-01-15 HK HK02100280A patent/HK1038657A1/en not_active IP Right Cessation
-
2004
- 2004-09-16 JP JP2004270384A patent/JP2005065315A/en active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016500491A (en) * | 2012-12-06 | 2016-01-12 | クアルコム,インコーポレイテッド | Managing network devices that use authorization tokens |
WO2017175926A1 (en) * | 2016-04-05 | 2017-10-12 | 삼성전자 주식회사 | Electronic payment method and electronic device using id-based public key cryptography |
KR20170114905A (en) * | 2016-04-05 | 2017-10-16 | 삼성전자주식회사 | Elecronic device and electronic payement method using id-based public key cryptography |
US11182783B2 (en) | 2016-04-05 | 2021-11-23 | Samsung Electronics Co., Ltd. | Electronic payment method and electronic device using ID-based public key cryptography |
KR102621116B1 (en) | 2016-04-05 | 2024-01-05 | 삼성전자주식회사 | Elecronic device and electronic payement method using id-based public key cryptography |
Also Published As
Publication number | Publication date |
---|---|
WO1999057835A9 (en) | 2000-02-03 |
HK1038657A1 (en) | 2002-03-22 |
CN1307818C (en) | 2007-03-28 |
CA2329032A1 (en) | 1999-11-11 |
TW476202B (en) | 2002-02-11 |
GB2353623A (en) | 2001-02-28 |
GB0026755D0 (en) | 2000-12-20 |
CN101087189A (en) | 2007-12-12 |
CN1304602A (en) | 2001-07-18 |
CA2329032C (en) | 2004-04-13 |
AU762708B2 (en) | 2003-07-03 |
WO1999057835A1 (en) | 1999-11-11 |
JP2005065315A (en) | 2005-03-10 |
GB2353623B (en) | 2003-01-08 |
AU4307599A (en) | 1999-11-23 |
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 | |
US5590197A (en) | Electronic payment system and method | |
US8725638B2 (en) | Method and system for payment authorization and card presentation using pre-issued identities | |
US6560581B1 (en) | System and method for secure electronic commerce transaction | |
US20030154376A1 (en) | Optical storage medium for storing, a public key infrastructure (pki)-based private key and certificate, a method and system for issuing the same and a method for using | |
US20070277013A1 (en) | Method for transmitting protected information to a plurality of recipients | |
US20020129248A1 (en) | Account-based digital signature (ABDS) system | |
US20030069792A1 (en) | System and method for effecting secure online payment using a client payment card | |
JP2013037711A (en) | Method of and system for authorizing purchases made over computer network | |
JP2003531447A (en) | Methods and systems for virtual safety | |
US20100043064A1 (en) | Method and system for protecting sensitive information and preventing unauthorized use of identity information | |
US6742125B1 (en) | Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol | |
CN109716373A (en) | Cipher authentication and tokenized transaction | |
US20090204518A1 (en) | System for electronically implementing a business transaction between a payee and a payor | |
EP1171849B1 (en) | Communication system and method for efficiently implementing electronic transactions in mobile communication networks | |
KR100458526B1 (en) | System and Method for the wire·wireless complex electronic payment | |
KR100822942B1 (en) | System for newly Processing Financial Goods | |
US11812260B2 (en) | Secure offline mobile interactions | |
Kravitz | Highly scalable on-line payments via task decoupling | |
GB2376337A (en) | A cryptographic method | |
WO2002001517A1 (en) | A method for carrying out electronic commerce transactions | |
AU2008254851B2 (en) | Method and system for payment authorization and card presentation using pre-issued identities | |
Waidner | Electronic Payment Systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20040615 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20040708 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040916 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041019 |