JP2002514839A - Cryptographic system and method for electronic commerce - Google Patents

Abstract

(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

DETAILED DESCRIPTION OF THE INVENTION

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.

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] 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] 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] 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.

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] 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.

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.

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] 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.

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.

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.

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.

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] 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.

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.

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.

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.

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.

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.

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.

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.

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.

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] The Internet connection may use any Internet protocol. Protocols that can be used are, for example, TCP / IP, UDP, HTTP and the like.

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.

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.

Other possible communication links include optical connections, wireless RF modem connections, cellular
Modem connection, satellite connection, etc.

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.

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.

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.

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.

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.

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.

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.

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.

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.

(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.

(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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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] 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.

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.

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.

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.

(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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

To format its own KE message, the merchant uses a random number RN_M 148
And create this as the merchant public key PK_M 150 and merchant sensitive
Transaction data STD_M 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
K_SP Encrypt using 146. The ciphertext thus completed is the plaintext part
PLAIN TEXT_M 154 to form a merchant composite message.
You. Merchant's public key PK_M 150 is the merchant compound message PLAIN TEX
T_M* E_SP-PK(RN_M* PK_M* STD_M) Instead of being encrypted when forming PLAIN TEXT _M May be placed inside.

Merchant Compound Message [PLAIN TEXT_M* E_SP-PK(RN_M* PK_M* STD_M)]
EC KE message [[PLAIN TEXT_EC* E_SP-PK(RN_EC* PK_EC* STD_EC)] * DS_{EC-Private- Key} ], Where there are KE messages for both merchants and EC
Is formed. That is, the EC / merchant composite message [[PLAIN
TEXT_EC* E_SP-PK(RN_EC* PK_EC* STD_EC)] * DS_{EC-Private-Key}] * [PLAIN TEXT_M* E_SP-PK(RN _M * PK_M* STD_M)]. This combined EC / merchant message is
Sent through algorithm 160, where it forms a hash message. This
Rega Merchant Message Digest MD_M It is. Merchant message
Digest MD_M The merchant uses the merchant's proprietary key 164
162 digitally signed. This allows digitally signed merchant messages
Sage DS_{M-Private-Key} Is formed. Digitally signed merchant
Sage DS_{M-Private-Key} Is the next message, the EC / merchant
166, where the merchant and EC
Exchange message <<< [PLAIN TEXT_EC* E_SP-PK(RN_EC* PK_EC* ST
D_EC)] * DS_{EC-Private-Key}] * [PLAIN TEXT_M* E_SP-PK(RN_M* PK_M* STD_M)] >> * DS_{M-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.

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.

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] 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.

To format the KE response message for the EC, the SP uses a random number RN_SP-EC 1
84 and Session Key Skey for EC_EC 186, and these are used as EC random numbers RN_{E C} 188, service provider's detectable transaction data STD_SP-EC Combined with 190
The data 192 to the public key PK of the EC._EC Encrypt using. In this way
Completed ciphertext E_EC-PK(RN_EC* RN_SP-EC* Skey_EC* STD_SP-EC), Then to the SP
Therefore, transaction identification number TID assigned to EC_SP-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 MD_SP-EC Calculate 198. Using his own private key 202, the SP
Sage digest MD_SP-EC Response message by digital signature of
Digital signature DS_{SP-Private-Key} Create 200. Data part of message
Digital signature DS with newly calculated minutes_{SP-Private-Key} After combining with 204
 The KE response message of the SP for the EC is completed. That is, [TID_SP-EC* PLAIN T
EXT_SP-EC* E_EC-PK(RN_SP-EC* RN_EC* Skey_EC* STD_EC)] * DS_{SP-Private-Key} It is.

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 )].

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.

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.
.

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.

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 TID_SP-EC , PLAIN
 TEXT_SP-EC , CRYPTO_SP-EC , DS_{SP-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 MD_SP-EC Collect. Ma EC newly collected
MD ^_SP-EC DS (at 260) from the KE response message for EC_{SP-Private- Key} MD recovered by decryption of_SP-EC Compare with 262. MD ^_SP-ECAnd MD_SP-EC If any inconsistencies are found during the
It is deemed to have been altered and rejected. MD ^_SP-MAnd MD_SP-M If
The EC identifies the part of the response message addressed to it and includes it in the message.
CRYPTO_SP-EC Using its own private key 266. Now the EC
Original random number RN sent in EC response message_EC(124) can be collected
Should be.

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.

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.

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.

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.

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] 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} .

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.

[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.

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.

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.

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.

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.

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.

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} .

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 )].

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.

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.

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.

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} .

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.

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.

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] 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.

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] 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.

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.

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 ).

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.

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.

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.

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.

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.

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.

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.

FIG. 13 shows the elements arranged in a hierarchical organization scheme, where each element, X _1,1 ~ X_{1, n}(N = 1, 2, 3,...) 1200 are the participants of the transaction
There is not a message router, but each element, X_{j, 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.

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.

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.

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.

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.

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.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating the relationships between components of a system according to an embodiment of the present invention.

FIG. 2 shows the flow of two transaction stages over a network.

FIG. 3 is a diagrammatic representation of an electronic card (EC).

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.

FIG. 5 illustrates how digital signatures are used in embodiments of the present invention.

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.

FIG. 6B is a view similar to FIG. 6A.

FIG. 6C is a view similar to FIG. 6A.

FIG. 6D is a view similar to FIG. 6A.

FIG. 6E is a view similar to FIG. 6A.

FIG. 6F is a view similar to FIG. 6A.

FIG. 6G is a view similar to FIG. 6A.

FIG. 6H is a view similar to FIG. 6A.

FIG. 6I is a view similar to FIG. 6A.

FIG. 6J is a view similar to FIG. 6A.

FIG. 6K is a view similar to FIG. 6A.

FIG. 6L is a view similar to FIG. 6A.

FIG. 6M is a view similar to FIG. 6A.

FIG. 6N is a view similar to FIG. 6A.

FIG. 6O is a view similar to FIG. 6A.

FIG. 6P is a view similar to FIG. 6A.

FIG. 6Q is a view similar to FIG. 6A.

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.

FIG. 8 is a view similar to FIG. 7;

FIG. 9 is a view similar to FIG. 7;

FIG. 10 is a view similar to FIG. 7;

FIG. 11 is a view similar to FIG. 7;

FIG. 12 shows a service provider transacting with parties arranged in series.

FIG. 13 shows a service provider transaction on a network with parties arranged in a hierarchical structure.

[Procedure amendment]

[Submission date] November 21, 2000 (2000.11.21)

[Procedure amendment 2]

[Document name to be amended] Drawing

[Correction target item name] Fig. 1

[Correction method] Change

[Correction contents]

FIG.

[Procedure amendment 3]

[Document name to be amended] Drawing

[Correction target item name] Figure 3

[Correction method] Change

[Correction contents]

FIG. 3

[Procedure amendment 4]

[Document name to be amended] Drawing

[Correction target item name] Fig. 4

[Correction method] Change

[Correction contents]

FIG. 4

[Procedure amendment 5]

[Document name to be amended] Drawing

[Correction target item name] Fig. 5

[Correction method] Change

[Correction contents]

FIG. 5

[Procedure amendment 6]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6A

[Correction method] Change

[Correction contents]

FIG. 6A

[Procedure amendment 7]

[Document name to be amended] Drawing

[Correction target item name] FIG. 6B

[Correction method] Change

[Correction contents]

FIG. 6B

[Procedure amendment 8]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6C

[Correction method] Change

[Correction contents]

FIG. 6C

[Procedure amendment 9]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6D

[Correction method] Change

[Correction contents]

FIG. 6D

[Procedure amendment 10]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6E

[Correction method] Change

[Correction contents]

FIG. 6E

[Procedure amendment 11]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6F

[Correction method] Change

[Correction contents]

FIG. 6F

[Procedure amendment 12]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6G

[Correction method] Change

[Correction contents]

FIG. 6G

[Procedure amendment 13]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6H

[Correction method] Change

[Correction contents]

FIG. 6H

[Procedure amendment 14]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6I

[Correction method] Change

[Correction contents]

FIG. 6I

[Procedure amendment 15]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6J

[Correction method] Change

[Correction contents]

FIG. 6J

[Procedure amendment 16]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6K

[Correction method] Change

[Correction contents]

FIG. 6K

[Procedure amendment 17]

[Document name to be amended] Drawing

[Correction target item name] FIG. 6L

[Correction method] Change

[Correction contents]

FIG. 6L

[Procedure amendment 18]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6M

[Correction method] Change

[Correction contents]

FIG. 6M

[Procedure amendment 19]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6N

[Correction method] Change

[Correction contents]

FIG. 6N

[Procedure amendment 20]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6O

[Correction method] Change

[Correction contents]

FIG. 6O

[Procedure amendment 21]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6P

[Correction method] Change

[Correction contents]

FIG. 6P

[Procedure amendment 22]

[Document name to be amended] Drawing

[Correction target item name] Fig. 6Q

[Correction method] Change

[Correction contents]

FIG. 6Q

[Procedure amendment 23]

[Document name to be amended] Drawing

[Correction target item name] FIG.

[Correction method] Change

[Correction contents]

FIG.

[Procedure amendment 24]

[Document name to be amended] Drawing

[Correction target item name] FIG.

[Correction method] Change

[Correction contents]

FIG. 13

──────────────────────────────────────────────────続 き 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)

[Claims] 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. 3. The system according to claim 1, further comprising software having said electronic card. 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. 5. The system of claim 1, wherein the electronic card performs external communication read / write operations and communication protocol processing. 6. The system according to claim 1, wherein the electronic card further comprises software for managing the electronic card. 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: 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. 10. The system of claim 1, further comprising an external system, wherein the service provider terminal communicates with the external system. 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. 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: 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. 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. 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. 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. 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. 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. 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. . 21. The method of claim 13, wherein the key exchange response further comprises a public key for every member involved in the transaction. 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. 23. The method of claim 13, wherein the key exchange request message includes a member generated digital signature. 24. The method of claim 13, wherein the key exchange request message from the member includes a cipher comprising the member's random number and the member's confidential data. 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. 26. The method of claim 14, wherein the transaction message includes a sender's digital signature. 27. The method of claim 14, wherein only the service provider can read sensitive transaction data in a transaction message. 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. . 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: 30. The method of claim 24, wherein the key exchange request message further comprises plain text. 31. The method of claim 24, wherein the key exchange request message further includes a digital signature of the member. 32. The method of claim 24, wherein the cipher further comprises the member's public key. 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. 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. . 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. 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. 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. 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. 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.