Classifications

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

Definitions

• the present invention relates generally to a cryptographic system and method for secure electronic transactions, and more particularly to an electronic card, which takes the form of a "smart card” and/or its equivalent software.
• smart card generally denotes an integrated circuit (IC) card, that is, a credit-card-size piece of plastic with an embedded microchip.
• IC integrated circuit
• the IC chip on a smart card generally, but not necessarily, consists of a microprocessor (the CPU), read-only memory (ROM), random access memory (RAM), an input/output unit, and some persistent memory such as electrically erasable programmable read-only memory (EEPROM).
• the chip can perform arithmetic computations, logic processing, data management, and data communication.
• Smart cards are mainly of two types: contact and contact-less.
• the International Standard Organization (ISO) has established specifications for such electronic cards under the ISO series.
• ISO 7816 applies to integrated circuit(s) cards.
• a smart card can support a multitude of security features such as authentication, secured read/write, symmetric key and asymmetric key encryption/decryption. These smart card security features make it well suited for electronic commerce where data security and authenticity are of primary importance.
• the multi-application card uses a conventional data link to connect between the smart card and the remote service provider.
• Taylor's invention does not relate to any kind of open network or cryptographic method.
• Each service provider is considered a user of the smart card and is installed on the card by the issuer/owner of the smart card.
• Each user is allowed to build a tree-like file structure and protect it with a password file.
• Mandelbaum's invention depicts a smart card allows for the creation and deletion of multiple applications. Mandelbaum ' s smart card controls the access to each application by using an appropriate password file.
• Electronic commerce using a secure courier system describes a system for implementing electronic commerce over a public network using public/private key cryptography.
• the Elgamal patent did not mention the use of a smart card as a tool in conducting the electronic commerce and the participants were authenticated through the use of digital certificates.
• the secure courier system requires a secured channel such as a Secure Socket Layer (SSL) between the trading parties over an open network such as the Internet.
• SSL Secure Socket Layer
• each participant of a transaction registers with a trusted credential-binding server by sending to the server a registration packet.
• the server produces unique credentials based upon the request received and sends them to the request originator.
• the originator of the transaction requests, receives and verifies the credentials of all intended recipients of the commerce document and/or instrument and encrypts the document and/or instrument using the public key of the individual recipient.
• the semiconductor device uses public/private key cryptography to ensure the authenticity of two communicating parties.
• a mutual session key for enciphering data transfer between a secure terminal and a secure computer is generated by using a common key stored in the secure computer and a retailer smart card.
• the current invention presents another system and method, which replaces the need for certificate authorities and digital certificates.
• the current invention is a hybrid system for electronic transactions.
• the hybrid system uses public/private keys during the key exchange phase and uses a session key as a secret key during the transaction phase.
• the invention is a cryptographic system and method for electronic transactions by using an electronic card (EC) in the form of a smart card or equivalent software and communicating over a communications network.
• EC electronic card
• the preferred embodiment of the invention uses an open network, such as the Internet.
• Alternative embodiments of the invention may use other types of networks.
• An embodiment of the invention may either use a physical smart card, or alternatively, a smart card, which is implemented as computer software package and runs on a computing device such as a personal computer (PC).
• a merchant involved in a transaction may use a merchant device, which is a point-of-sale terminal, or a device, which uses software on a host computer to communicate with an EC and a service provider.
• a smart card reader is also needed to allow the card to communicate with a host device, such as a network ready merchant terminal, a PC, or any other electronic device, which is capable of supporting smart card transactions.
• transaction participants exchange public information through the use of digital certificates or other electronic credentials which are issued and certified by a certificate authority (CA) or credential binding server.
• CA certificate authority
• the communication between the CA or the server and each participant of the transaction must be secure. Random numbers and digital signatures are used to ensure the authenticity and validity of the messages transmitted among the participants.
• the cryptographic system and method of the preferred embodiment of the invention also uses public/private key cryptography, but it works in a slightly different way.
• the cryptographic system and method does not seek to create another kind of trust relationship as the one that exists between holders of digital certificates and the certificate authorities. It particularly targets large membership-based financial institutions such as a large credit card company and all its cardholders, or a major bank and all its ATM cardholders as its potential users.
• Non-financial institution can also use this cryptographic system and method to conduct commercial or non- financial transactions over a network.
• a service provider provides some service to its members. Financial institutions are just one kind of service provider. A service provider can also be non-financial in nature.
• a service provider is a financial institution or a non-financial institution
• the messages may include different data fields.
• the service provider When an EC holder signs up with one of the service providers, the service provider creates a dedicated entry on the EC. Each entry contains the account information for the service provider, the SP's public key, access control information, and other related data. Each EC can support a predetermined number (e.g. ten) of such entries and each such entry is a representation of one service provider.
• the public/private key cryptography the key distribution process is much simplified.
• the EC holder him/her/self or any trusted third party such as a bank branch or even a post office can perform the task.
• the SP's public key is only used for the initial key exchange between the SP and the cardholder. After the initial key exchange step, the SP assigns a session key, which protects any further message exchange between the cardholder and the SP or between the cardholders' themselves.
• This hybrid system which uses both public key/private key cryptography and secret key cryptography (i.e., session key), is in contrast to other secret-key systems in that in the hybrid system, the secret key (i.e., session key) is valid for a single session and is not applicable to other sessions.
• a session has a determinate length of time. A session may terminate based upon a time period or upon conditions being satisfied.
• the merchant goes through essentially the same procedures as the EC holder to communicate with the SP.
• the merchant will first perform a key exchange with the SP and receive a session key.
• the session key will be used by the merchant for subsequent communication with the SP.
• the cardholder and the merchant digitally sign each message going to the SP and the SP similarly signs the response message going back to the cardholder and the merchant.
• the SP In the event that a transaction requires interactions with another certificate-based system, the SP, after authenticating the cardholder and the merchant based on further information exchange after the initial key exchange, can act as a surrogate-certificate for the cardholder and the merchant. In the most extreme case, the SP performs solely this surrogate function and becomes a gateway for the certificate-based system.
• This type of hierarchy is highly desirable since it reduces the number of trust relationships needed to carry out a transaction among multiple systems. In addition, it eliminates the users' need to carry certificates.
• Figure 1 is a block diagram showing the relationship among the components of a system according to an embodiment of the invention.
• Figure 2 shows the flow of the two transaction phases via a network.
• Figure 3 is the diagrammatic representation of an EC.
• Figure 4 shows the format of the service provider data area. Each service provider's information is allocated an entry in the table and is protected by access conditions.
• Figure 5 shows how the digital signatures are used in an embodiment of the invention.
• Figures 6 A through 6Q shows the schematic flow chart of the cryptographic system and method used in an embodiment of the invention in order to conduct electronic transactions via an open telecommunication network, such as the Internet.
• Figure 7 through Figure 11 depicts the final format and content of the combined request and response messages in the key exchange phase and the transaction phase.
• Figure 12 shows a service provider conducting a transaction with participants that have been arranged in series.
• Figure 13 shows a service provider transaction on a network with participants that have been arranged in a hierarchical organization scheme.
• the preferred embodiment of the invention is a cryptographic system and method for electronic transactions by using an electronic card (EC) in the form of a smart card or equivalent software and communicating over a communications network.
• the network is an open network such as the Internet.
• other open networks and/or closed networks may be used to establish communication between a service provider and its members.
• a service provider may use its own proprietary financial network to communicate with its members.
• Any Intemet protocol may be used for Internet connections.
• Example protocols, which can be used include TCP/IP, UDP, HTTP, and the like.
• Communication may also be via a communications network transport service such as the Public Switched Telephone Network (PSTN) usingtraditional analog telephone service (a.k.a. Plain Old Telephone Service or POTS), or by using a digital communication service such as a T-l, El or DS-3 data circuit, Integrated Services Digital Network (ISDN), Digital
• PSTN Public Switched Telephone Network
• POTS Plain Old Telephone Service
• Digital communication service such as a T-l, El or DS-3 data circuit, Integrated Services Digital Network (ISDN), Digital
• DSL SubscriberLine
• the invention may be implemented independent of a communications protocol (i.e. at an electrical interface layer). Communication may also be via a local area network (LAN) or WideArea Network
• WAN such as Ethernet, Token Ring, FDDI, ATM or the like.
• Example protocols which can be used include TCP/IP, IPX, OSI, and the like.
• Other communication links might include an optical connection, a wireless RF modem connection, a cellular modem connection, a satellite connection, etc.
• the invention may be employed as long as a communication path can be established between a service provider and its members.
• the examples above are intended to illustrate several examples of the various communications environments in which the invention may be practiced. As is clear to one ordinarily skilled in the art, the invention is not limited to those environments detailed above.
• the 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).
• a smart card When the EC is implemented on a smart card, it can be used on a network-ready computer system such as a PC to transact with another member and/or a selected service provider. It will need a read/write interface device to communicate with a computer system and some application software such as an Internet browser to interface with the cardholder and the network. If the EC is a software package loaded into a computer system, then no read/write interface is needed.
• the exemplary embodiment of the invention is for the EC to act as an electronic wallet (or cyber wallet) which functions similar to real wallet.
• a real wallet can carry credit cards, debit cards, ATM cards, health provider cards, membership cards, cash, etc.
• An EC has the digital equivalent of all the above-mentioned financial and non-financial instruments and enables conducting secure transactions over the Internet.
• a service provider member can be a merchant and/or an EC cardholder.
• a merchant is a member who is paid by the service provider as a result of a transaction.
• a member can be both a merchant and an EC cardholder.
• a merchant may engage in a transaction with other cardholders, which results in the merchant being paid by the service provider.
• a merchant may also be an EC cardholder and purchase supplies, for example, from a merchant supplier.
• the cryptographic system may involve communication between a service provider and any number of service provider members.
• communication can be between an EC and an SP, between a merchant and an SP, between a first EC, a second EC, and an SP, between a first merchant, a second merchant, and an SP, etc.
• An EC may communicate directly with a service provider to inquire about an account balance for example.
• a merchant may communicate with a service provider only on his own behalf and not on behalf of an EC because, for example, the merchant wants to know his own account balance with the service provider.
• Communication between the SP and its members may follow any permutation of the SP and its members.
• the organization of the communication links between the SP and its members may be sequential and/or hierarchical.
• the cryptographic method is a two-phased key-exchange-transaction model.
• the first phase is a key exchange phase.
• the second phase is the transaction phase.
• the members exchange keys with the service provider.
• the members send their keys to the service provider and the service provider uses the keys to send a session key to the members.
• the session key protects any further message exchange between the cardholder and the SP or between the cardholders' themselves.
• the transaction phase either the SP can direct the transaction or the cardholders themselves may conduct the transaction.
• Figure 1 is a block diagram showing the relationship among the components of a system according to an exemplary embodiment of the invention involving a cardholder, a merchant, and service provider.
• An EC cardholder 20 can conduct a transaction over a network 50 and communicate with a merchant either by using an EC read/write device 82 attached to an originating computer 84 or by using EC equivalent software 92 running on an originating computer unit 90.
• a merchant can conduct a transaction over a network by either using a network-ready point-of-sale(s) (POS) terminal 40 or by using EC equivalent software running on a merchant device 70 to conduct an electronic transaction with a selected service provider 60 via a network 50 such as the Internet.
• POS point-of-sale
• EC equivalent software running on a merchant device 70 to conduct an electronic transaction with a selected service provider 60 via a network 50 such as the Internet.
• the cardholder can perform financial or non-financial transactions with other participants of the system through the network 50.
• Figure 1 there are three different scenarios in which a transaction over a network can be conducted.
• the EC reader/writer is connected to a network-ready merchant POS terminal 40.
• the network-ready merchant POS terminal 40 is a secure tamper-resistant programmable device comprising an input means such as a keyboard, a display device, a processing unit, and an EC read/write device 30 (an EC interface device). It is typically a small computer unit such as a PC equipped with a communication link to an open network.
• the POS terminal communicates to the SP via the network 50.
• a cardholder can conduct a transaction with other participants of the system by inserting the EC 20 into a read/write device 82, which is connected to the cardholder's personal computer 84 which is the originating computer.
• the originating computer connects to a network 50 allowing the EC to communicate with the merchant computer unit 70.
• the merchant computer unit 70 has EC equivalent software 72 that enables the merchant to receive the EC generated message and generates a message combining EC information and merchant information. Then, the combined message is sent to the SP over a network.
• a cardholder can conduct a transaction with other participants of the system by using EC equivalent software 92 on the customer cardholder's personal computer 90.
• the transaction begins at the originating computer unit 90, that is, the cardholder's personal computer.
• the cardholder conducts the transaction over a network 50 and communicates with the merchant's computer unit 70, which in turn communicates with the SP 60 over a network 50.
• a personal computer is used to hold the EC equivalent software
• other electronic devices can be used to hold the EC equivalent software.
• 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.
• the network used to enable the EC to communicate with the merchant may not be the same network used to enable the merchant to communicate with the SP.
• the network used to enable one merchant to communicate with the SP may not be the same as the network used to enable another merchant to communicate with the SP.
• the network used to enable an EC to communicate to the merchant may not be the same as the network used to enable another EC to communicate with another merchant.
• An embodiment may consist of a multiplicity of networks whereby different parties communicate.
• a transaction is broken down into two phases: a key exchange phase and a transaction phase.
• Figure 2 is a specific case, which illustrates the two-phase key-exchange-transaction model where the SP directs the transaction phase. There is no direct exchange of sensitive information between participants when the SP directs the transaction.
• the key exchange phase is the same where the transaction phase is among the cardholders themselves and where the SP directs the transaction phase. Where the transaction phase is among the cardholders themselves, the cardholders use the SP session key to communicate with each other and conduct a transaction.
• Figure 2 demonstrates a financial transaction where the SP directs the transaction phase.
• the transaction shown involves three parties: an EC (a transaction originator) 102, a merchant 104, and a service provider (SP) 106.
• the originating party is an EC cardholder who is the consumer and is represented by the computer unit 102.
• the computer unit 104 represents the merchant.
• the computer unit 106 represents the service provider.
• An SP is selected by both an EC and merchant.
• Figure 2 demonstrates a financial transaction wherein the process flow is from an EC to a merchant to an SP.
• the cryptographic method's process flow is not limited to any particular order between merchants and EC cardholders.
• Figure 2 is merely an example of a particular transaction, which flows from EC to merchant to service provider. The process flow can also go from merchant to EC to service provider.
• Figure 2 demonstrates how service provider members (in this case, the EC cardholder and the merchant) create, append, and send messages to a service provider.
• the ten arrows numbered 1 to 10 in figure 2 show how the messages flow among the three parties during the two transactions phases. Steps 1 through 4 belong to the key exchange phase and steps 5 through 10 belong to the transaction phase.
• the merchant serves as an intermediary between the EC and SP.
• the key exchange request is formatted by the EC and sent to merchant.
• the merchant combines his own key exchange message with the EC's key exchange message and sends the combination key exchange message to an SP.
• the SP formats a key exchange response for the merchant, formats a key exchange response for the EC, combines the key exchange responses to form a combined key exchange response and sends the combined key exchange response to the merchant.
• step 4 the merchant separates the key exchange response for the merchant from the key exchange response for the EC and forwards the EC's key exchange response message back to the EC.
• step 4 concludes the main activities in the key exchange phase.
• the transaction phase begins with step 5.
• step 5 the EC formats its transaction request message and sends it to merchant.
• step 6 the merchant combines the received transaction request message with his own transaction request message and sends the combination transaction request message to the SP.
• step 7 formats a transaction response message for the merchant, formats a transaction response message for the EC, combines the transaction response messages and sends the combined transaction response message back to merchant.
• step 8 the merchant separates the transaction response message for the merchant from the transaction response message for the EC and forwards the EC's transaction response message back to the EC.
• step 9 the EC formats a confirmation message and sends it to the merchant.
• step 10 the merchant combines the received confirmation message with his own confirmation message and sends the combination confirmation message the SP. Step 10 concludes the transaction phase of a transaction.
• FIG 2 demonstrates a simple transaction
• some transactions may involve multiple messages. During some transactions, more than one message may be required to complete each phase, in which case, those messages will follow the same mles of combination and flow pattern.
• the SP may require that the EC and the merchant send over account information first. If the account information is verified to be valid, the SP sends confirmation of the account information in the response message. Once the merchant and the EC receives the response message, then the EC and the merchant send the transaction amount and other transaction related information in the next message going to the SP. The SP subsequently approves or disapproves the transaction.
• the steps in figure 2 apply to both the account message and the transaction message.
• a desired result of the invention is to shield all of the participants of a transaction from an external system and therefore reduce the number of trust relationships needed to complete a transaction. If a participant of a transaction has dual membership of this system and an external system, then he has a choice of either acting as a member of this system or as a member of an external system. In the latter case, the SP will interface with the participants using the mles of an external system.
• the SP has in its possession all of the required certificate(s) or credential(s) which satisfies the t st relationship demanded by the external system.
• Such credentials are required in order for the SP and the external system to complete the transaction initiated by the EC and the merchant.
• the SP needs to have a tmst relationship with the external system. Based on this tmst relationship, individual ECs and merchants are able to complete transactions with the hypothetical external system.
• FIG 3 is a diagrammatic representation of a preferred embodiment of an EC.
• an EC is internally composed of the software/hardware components shown in Figure 3.
• the EC is ISO 7816-based and supports the same kind of communication protocols and commands as defined in ISO 7816.
• the EC has a card operating system 550 to manage the EC's internal resources.
• the on- card cryptographic service 650 can be implemented in software or be provided by a cryptographic co-processor (not shown in figure 3), or other hardware solutions, or a hybrid of software and hardware.
• the service provider data area (SPDA) 700 contains a number of slots.
• the SPDA contains a pre-defined number (e.g. ten) of slots ⁇ one for each potential service provider.
• the number of slots may be dynamically changed.
• a record for each service provider can be placed into an empty slot. Each record contains the account number, public key, and other related information for a specific service provider.
• the SPDA can optionally allow each SP to include some software (such as an "applet" in the JAVA terminology) to manage its own on-card data and provide an interface between the SP card data and the host application.
• the SPDA can contain more than just simple data; it can allow each SP to put a self-contained application program (such as an applet) on the EC to provide its own unique service to the cardholder.
• a self-contained application program such as an applet
• the advantage of this type of design is that the EC itself is now detached from the type of service it can provide. Each SP can bring with it its own service capability. When another SP replaces an on-card SP, there will be no change necessary to the EC platform. The new SP applet is simply loaded into the card and it will perform what it is designed to do.
• each service provider is allocated space for public keys. In many transactions, only one key pair is used, but for some online transactions, two or more key pairs are required.
• two public/private key pairs rather than one public/private key pair is used to communicate with other applications through a network because using two public/private key pairs rather than one public/private key pair provides greater security.
• One pair is used for decrypting an incoming message, i.e., the sender encrypts the message using the recipient's public key and the recipient decrypts the message using the corresponding private key.
• the other pair is for the sender to digitally sign the message he sends out and the recipient 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 public/private key pair for both incoming messages and signing of outgoing messages, then one public key is enough. If the SP uses different key pairs for receiving and signing messages, then both of the SP's public keys are required in the SPDA.
• more than two public/private key pairs may be required and used by a service provider for even greater security.
• the issuing institution or a t sted third party will load the needed information comprising a record into an available slot.
• the information in the slot can be erased when the service provider account is closed.
• Some of the information in a slot can be read and modified during a transaction, e.g. an account balance.
• Some information such as account number is write protected, but can be read.
• Some information such as a private key is both read and write protected.
• the access conditions 600 contain security information such as PINs, biometric data, etc., that an EC user must submit to open the card for use or to gain access to the information stored on the card.
• Biometrics involves the measurement of a cardholder's biological traits, such as physical traits and behavioral traits.
• a biometric system may measure an individual's fingerprints, hand-geometry, hand writing, facial appearance, speech, physical movements, keyboard typing rhythms, eye features, breath, body odor, DNA, or any other physical attribute of the cardholder.
• the functions provided by an EC can be activated only after all the access conditions have been satisfied.
• Each service provider residing on the card can optionally implement other access conditions.
• Figure 4 shows the format of the service provider data area of a preferred embodiment of the invention.
• Each service provider's information is allocated an entry in the table, which can be protected by additional access conditions.
• the PIN 712 and the miscellaneous data field 714 allows the service provider to provide extra protection or data field to the instmment it supports.
• the name field 702 contains the names of the service providers, which can be used by the cardholder at the beginning of an online transaction to initially select the applicable service provider for a transaction.
• the key type field 704 specifies the type of key the service provider chooses to use, secret key, public key, etc.
• the key value 706 and account information fields 708 contain information unique to each service provider.
• the card type field 710 specifies the type of instemper a service provider supports.
• COS on-card Operating System
• Service Provider Data Area management such as loading and updating of individual service provider information, SPDA access control, etc.
• the COS will also provide support during various stages of a transaction.
• the COS will also provide support during various stages of a transaction.
• the COS will also provide support during various stages of a transaction. For example, the
• COS can handle the SP selection at the beginning of a transaction and record the transaction into a log file when the transaction has been completed.
• An embodiment of the invention may implement one of the following two design approaches to the COS or a hybrid of the two design approaches:
• the COS can be a pool of general services each on-card SP can utilize.
• Each SP data area can contain applets, which have the intelligence to carry out a transaction with the merchant and the SP.
• the SP has more opportunity to implement its own unique feature when performing a transaction.
• Figure 5 shows how digital signatures are used in the preferred embodiment of the invention.
• a sender of a message first prepares and sends the data portion of a message M 900 through a one way hash algorithm, H(*) 902.
• the output from the hash algorithm is called the message digest MD of message M 903.
• the MD is then encrypted, E(*) 904, i.e. digitally signed, using the sender's private key (Pri).
• the result is called the digital signature DS of a message M.
• the DS is then combined with the original message M 900 and forms a complete message 906 ready for transmission to a recipient through a network 50.
• the public-key encryption/decryption function can be any of a number of encryption decryption functions.
• RSA which takes its name from the first initials of RSA developers' last names (Ronald Rivest, Adi Shamir, and Len Adelman), is just one example of a public-key encryption/decryption method, which can be used in an embodiment of the invention.
• the intended recipient When the intended recipient receives the message from a network 50, he first separates the data portion of the message M 900 from the digital signature 912 combined with it. The recipient then mns the data portion of the message M 900 through the same hash algorithm 910 that was used to encode the data portion of message M 900, and consequently obtains a message digest MD ⁇ 911 of M. The recipient then decrypts D(*) 908 using the EC's public key, the digital signature 912 contained in the original message using the sender's public key and recovers the original message digest, denoted here as MD 909. MD 909 is compared with the new calculated MD A 91 1 for correctness. If they are not identical, the original message has been corrupted and should be rejected.
• Acknowledgement Data EC A part of the message sent back by the EC to the SP. It notifies the
• Acknowledgement Data M A part of the message sent back by the merchant to the SP. It notifies the SP that the previous message has been successfully received and processed.
• AI EC Account information of EC holder.
• AI M Account information of merchant.
• D Decryption function
• D S p- P ⁇ vate - ⁇ ev Decryption using SP's private key.
• E (Data) Encryption of data under a data encryption key.
• Es ey - M, Ds ey - M Encryption/Decryption using the session key that the SP generated for the merchant.
• H (M) Apply a one-way hashing algorithm on M. It generates the message digest (MD) of M.
• MD ⁇ Message Digest produced by message recipient using the message just received as input data.
• MD EC The message digest of a message going from EC to SP.
• MD M The message digest of a message going from merchant to SP.
• MD SP.M The message digest of a message going from SP to merchant.
• MD SP . EC The message digest of a message going from SP to EC which is by passed by merchant.
• PLAIN TEXT Transaction data, which can be transmitted without encryption. Plain text can be different for different messages and transaction parties.
• PLAIN TEXT EC Part of the transaction data provided by EC in its outgoing messages. Plain text data fields are not security sensitive. Therefore, they are transmitted without encryption.
• PLAIN TEXT M Part of the transaction data provided by merchant in its outgoing messages.
• Plain text data fields are not security sensitive. Therefore, they are transmitted without encryption. Note that the content of this symbol can be different when used in a different message.
• PLAIN TEXT SP.EC Part of the transaction data provided by SP for EC only in its outgoing messages. Plain text data fields are not security sensitive. Therefore, they are transmitted without encryption. Note that the content of this symbol can be different when used in a different message.
• PLAIN TEXT SP . M Part of the transaction data provided by SP for merchant only in its outgoing messages. Plain text data fields are not security sensitive. Therefore, they are transmitted without encryption. Note that the content of this symbol can be different when used in a different message.
• STD Sensitive transaction data, which requires encryption during data transmission.
• STD EC Sensitive transaction digital data provided by EC in its outgoing messages. Note that the content of this symbol can be different when used in a different message.
• STD M Sensitive transaction digital data provided by merchant in its outgoing messages. Note that the content of this symbol can be different when used in a different message.
• PK EC Public key of the electronic card.
• PK M Public key of the merchant.
• SP-PK Public key of the selected service provider.
• E c A part of the message sent back by the SP to the EC during the transaction phase of a transaction. It can include approval/disapproval data and/or any other relevant data.
• Response Data SP . M A part of the message sent back by the SP to the merchant during the transaction phase of a transaction. It can include approval/disapproval data and/or any other relevant data.
• RN Random number.
• RN EC Random number generated by the EC and is sent to SP.
• EC Random number generated by the SP and is sent to EC.
• RN M Random number generated by the merchant.
• RN SP - M Random number generated by the SP and is sent to M.
• TA Transaction (currency) amount.
• Transaction Identification Number SP . EC , TID SP . EC (Transaction ID SP . EC ) A data field whose value is assigned by the SP during the key exchange phase of a transaction. The EC will use this value to communicate with the SP during the same transaction.
• Figures 6A through 6Q comprise the flowchart for a preferred embodiment of the cryptographic system and method.
• the flowchart assumes that each of the parties involved in the transaction uses one key pair.
• two public key pairs may be used, in which case, both public keys need to be exchanged.
• the preferred embodiment of the invention consists of two distinct phases: the key exchange phase and the transaction phase.
• PHASE I KEY EXCHANGE PHASE (HANDSHAKE PHASE)
• the EC cardholder inserts the EC into a card read/write device or starts the EC equivalent software and enters a PIN number and/or satisfies the access conditions 110 to use the EC card.
• the entered security information conditions is compared 112 with the on-card information 114 to verify that user is authorized to use the EC. If the security information does not match the card security information, then the request to use the card is rejected 116. Otherwise, the card is unlocked 118 for use. Once the card is unlocked, the user can request the list of the on-card SPs available for selection and make a selection 120 by issuing an SP selection command to the EC. Once the SP is selected, the EC proceeds to start the key exchange (KE) with the SP.
• KE key exchange
• the public key of the selected SP represented by the symbols SP-PK and PK SP is obtained from the EC's SPDA and is used to encrypt messages that will be sent to the SP.
• the main purpose of the KE is to securely send the cardholder's public key, PK EC 126 and an EC random number, RN EC 124 to the SP.
• the SP response to the EC is to assign a session key and a transaction ID to the EC, which will be used by the EC to communicate with the SP for the rest of the transaction.
• the EC To format the KE message, the EC generates a random number.
• E ES.PK (RN EC *PK EC *STD EC ), is then combined 130 with the plain text portion of the message,
• PLAIN TEXT EC 132 if any, to form an EC combination message, PLAIN TEXT EC *E SP.
• PK (RN EC *PK EC *STD EC ).
• the EC's public key PK EC 126 may be placed in the plain text PLAIN TEXT EC instead of being encrypted when forming the EC combination message.
• the resulting EC combination message is then sent through a hashing algorithm 134 to form a hash message, which is the EC message digest MD EC .
• the EC message digest MD EC is digitally signed by the EC 136 using the EC private key 138 to form a digitally signed message DS EC.Pr ⁇ vate.Key .
• the digitally signed message DS Ec . P ⁇ vate . Key is then combined 140 with the EC combination message.
• the combination of the plain text PLAIN TEXT EC cryptogram CRYPTO EC and the digital signature DS EC .p rlvate . Key is the KE message from the EC and is sent to the merchant 158 through a network.
• Plain text includes all the transaction data fields that are not sensitive in nature and therefore can be transmitted in a clear, discemable form; they do not need to be encrypted. These data fields are different for each message and are defined by the transacting parties.
• the merchant goes through essentially the same steps to format its own KE message with the SP as the EC goes through to format the EC's KE message with the merchant.
• the cardholder and the merchant do not communicate with the SP individually, but through a combined message. Consequently, there will be no need to exchange any confidential financial information between the cardholder and the merchant.
• the merchant prepares his device for the transaction 142 and selects from his own SPDA, which resides within the merchant's device, the same SP as the EC cardholder has selected for the transaction 144.
• the public key of the SP represented by the symbols SP-PK and PK SP is obtained from the SP's SPDA and is used to encrypt messages that will be sent to the SP.
• the merchant To format its own KE message, the merchant generates a random number, RN M 148, concatenates it with the merchant's public key, PK M 150, and the merchant's sensitive transaction data STD ⁇ Sensitive transaction data is data that is relevant to the transaction and/or required by the SP 152.
• the merchant encrypts 146 the combined data using the public key of the service provider, PK SP .
• the resulting cryptogram is then combined 154 with the plain text portion PLAIN TEXT M 156 of the message, if any, to form a merchant combination message.
• the merchant's public key PK M 150 may be placed within the plain text PLAIN TEXT M instead of being encrypted when forming the merchant combination message PLAIN TEXT M *E SP .
• the merchant combination message [PLAIN TEXT M *E SP-PK (RN M *PK M *STD M )] is further combined 158 with the EC's KE message ⁇ [PLAIN TEXT EC *E SP .
• PK (RN EC *PK EC *STD EC )]*DS EC .
• the EC-merchant combination message is sent through a hashing algorithm 160 to form a hash message, which is the merchant message digest MD M .
• the merchant message digest MD M is digitally signed 162 by the merchant using the merchant ' s private key 164 to form a merchant digitally signed message DS M .
• P ⁇ vate Key The merchant digitally signed message DS M .
• P ⁇ vat£ Key is then combined 166 with the data portion of the message, i.e., the EC-merchant combination message to form a key exchange request message « ⁇ [PLAIN TEXT EC * E SP .
• the merchant does not check the MD of the EC's request message MD EC because the EC encrypts his public key.
• the merchant can optionally check the EC's MD before passing it to the SP.
• the SP can still check the EC's MD.
• the merchant receives a combination response from the SP for both himself and the EC, the merchant does not have to check the MD for the EC since it is part of the overall message formed by a single originator ⁇ the SP. The merchant only needs to check the MD of the overall message he receives from the SP.
• the SP When the SP receives the KE request message, the SP first separates 168 the data portion of the KE request message from the DS and feeds the data portion of the KE request message into a one-way hash algorithm to recalculate the message digest, which becomes MD M . The SP then separates the merchant's plain text PLAIN TEXT M , cryptogram CRYPTO M , digital signature DS M . P ⁇ vate . Key and the EC's KE request message PLAIN TEXT EC *CRYPTO EC
• the SP decrypts merchant's cryptogram 170 and recovers, among other information, the merchant's random number RN M 148 and the merchant's public key PK M 150. The SP then uses the recovered PK M to decrypt the digital signature signed by the merchant DS M . Pr ⁇ vate . Key and recovers the MD M for the merchant's KE message. The SP compares 172 the newly hashed MD ⁇ M 168 with the MD M 170 recovered by decrypting the DS from the original KE message. If there is a discrepancy between MD ⁇ M and MD M found, then the KE message has been corrupted and is therefore rejected 174.
• the SP separates the data portion of the EC's KE request message from the DS and feeds the data portion of the EC's KE request message into a one-way hash algorithm to recalculate the message digest (MD ⁇ EC )-
• the sp tnen separates the EC's plain text PLAIN TEXT E ⁇ if any, cryptogram CRYPTO EC , and digital signature DS EC .
• P ⁇ vate Ke in the data portion of the EC's KE request message 176.
• the SP decrypts EC's cryptogram and recovers, among other information, EC's random number RN EC and EC's public key PK EC .
• the SP uses the recovered PK EC to decrypt the digital signature signed by EC and recovers the MD EC for EC's KE message.
• SP compares the newly hashed MD ⁇ EC 176 with the MD EC recovered by decrypting the DS from the original KE message. If there is any discrepancy found, the KE message has been cormpted and is therefore rejected 180. Otherwise, SP is ready to send a KE response message back to merchant and EC.
• the SP To format the KE response message for the EC, the SP generates a random number, RN SP . EC 184, and a session key Skey EC 186 for the EC, combines them with the EC generated random number, 188 RN EC , service provider sensitive transaction data STD SP . EC 190 and encrypts them 192 using the EC's public key PK EC .
• the resulting cryptogram, E EC.PK (RN EC *RN SP . EC *Skey EC *STD Sp.EC ), is combined 196 with a transaction identification number, TU s p . E c 194 assigned to the EC by the SP and plain text, PLAIN TEXT SP .
• EC 195 if any, to form the data portion of the response message for the EC.
• the SP runs this data through a hash algorithm to calculate the message digest MD SP . EC 198.
• the SP creates a digital signature DS SP.Pr , vate . Key 200 for the response message by digitally signing the message digest MD SP . EC .
• After combining 204 the data portion of the message with the newly calculated DS SP . Pr ⁇ vate . Key the SP's KE response message for the EC is complete, [TID SP.E c*PLAIN TEXTs P . E c*E EC . pK (RN Sp . EC *RN EC *Skey EC *STD EC )]*DS S p. P ⁇ vate . Key .
• the SP To format the KE response message for the merchant, the SP generates a random number RN SP . M 208 and a session key Skey M 210 for the merchant and combines them with the merchant generated random number RN M 212, sensitive transaction data STD SP . EC 214 and encrypts them 206 using the merchant's public key PK M recovered in 170.
• the resulting cryptogram is combined 216 with a transaction identification number, TID SP . M 218, assigned to the merchant by the SP and plain text, PLAIN TEXT SP . M 220, if any, to form the data portion of the response message for merchant.
• PK (RN SP.M *RN M *Skey M *STD SP . M ) is further combined 222 with the KE response message for the EC, [TID SP.EC *PLA ⁇ N TEXT SP.E c*E EC .p K (RNsp. EC *RN E c*Skey E c*STD EC )]*DS S p. p ⁇ vate - ⁇ ey> to form the data portion of the SP's final KE response message, [TID SP .
• the SP runs the data portion through a hash algorithm to calculate the message digest 224. Using its own private key 228, the SP creates a digital signature, DS SP.P ⁇ vate . Key 226, for the response message by digitally signing the message digest.
• the KE response message for both the EC and the merchant is complete.
• the response message « ⁇ [TID SP.EC *PLAIN TEXTsp. EC *(E EC .p ⁇ *RN S p. EC *RN EC *Skey EC *STD SP . E c)]*DS S p.p ⁇ vate .
• Figure 8 depicts the final format and content of the combined KE response message from the SP to the merchant.
• DS SP.P ⁇ vate.Key which was signed by the SP, and then feeds the data portion of the combined KE response message into a one-way hash algorithm to recalculate the message digest MD ⁇ SP . M .
• the merchant then separates the data portion of the SP's KE response message, i.e.. TID SP . M , PLAIN TEXT SP.M , CRYPTO SP . M , [(TID SP . EC *PLAIN TEXT SP . E c*CRYPTOs P . E c)]*DS SP .p rivate . Key .
• the merchant uses SP's public key (selected from 144) to decrypt the digital signature DS SP .
• the merchant compares 240 the recovered random number RN M (of the step 238) with the original random number RNM. If they are not equal, then the message has been corrupted and the message is rejected 242. Since the random number RN M can only be recovered by the SP using the correct SP private key, it is assured that the sender of the message is indeed the selected SP.
• the merchant then forwards the EC's KE response message [(TID SP _ EC *PLAIN TEXT Sp _ EC *CRYPTO Sp.EC )]*DS S p . p ⁇ vate . Key to the EC and prepares for the transaction phase of the transaction.
• the EC When the EC receives the KE response message 260, the EC first separates the DS SP . Pnvate . ey which was signed by the SP, and then feeds the data portion of the KE response message for the EC into a one-way hash algorithm producing a MD ⁇ SP . EC . The EC then separates the data portion of the message, i.e., TID SP . EC , PLAIN TEXT SP . EC , CRYPTO SP . EC , DS SP . P ⁇ vate . key . The EC uses SP's public key (selected in 120) to decrypt the digital signature DS SP . P ⁇ vate . key message and recovers the message digest MD SP .
• the EC compares 262 the newly hashed MD ⁇ SP _ EC (in 260) with the MD SP . EC recovered by decrypting the DS SP . P ⁇ vate . key from the KE response message for EC. If there is any discrepancy between MD ⁇ S p. EC and MD SP . EC found, the KE response message for the EC has been cormpted and is therefore rejected 264. If MD ⁇ SP . M and MD SP . M match, the EC identifies the part of the response message which is meant for him and decrypts 266 the cryptogram CRYPTO SP.EC which is contained in the message, using his own private key.
• the EC should be able to recover the original random number RN EC (of 124) that was sent in the EC KE request message.
• the EC compares 268 the recovered random number RN EC (of 266) with the original random number RN EC (of 124). If the random numbers are not equal, then the message has been cormpted and the message is rejected 270. Since only the SP using the correct SP private key can recover the random number RN EC , this serves to ensure that the sender of the message is indeed the selected SP.
• the EC prepares for the transaction phase of the transaction.
• timeout period set in the EC and the merchant. During a transaction, if a response message is not received within a timeout period, the EC and the merchant will consider the transaction aborted and will either retry or start the recovery process.
• the SP After successful completion of the KE message exchanges, the SP has EC's public key and the merchant's public key. At this point, both the EC and the merchant has a random number, a transaction ID. and a session key from the SP.
• the EC and the 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. The random numbers can be sent back through a confirmation message from both the EC and the merchant. Or the random numbers can be sent back as part of the next message going out from the EC and the merchant to the SP, such as a transaction message. The second method is simpler and is described in phase II below. The random numbers are used only once to ensure the correctness of the key exchange between the SP and merchant, and the SP and EC. Once the session keys and transaction identification number have been established, the random number are no longer be used.
• the merchant and the EC each sends their own account information such as an account number and other transaction related data such as transaction amount, request for approval or other processing, to the SP.
• the EC and the merchant talk to the SP individually but through combined messages and the merchant is responsible for combining the messages and sending them as one message to the SP.
• the EC first forms the transaction message by concatenating the random number RN SP .
• the EC encrypts 272 them using the session key Skey EC assigned by the SP.
• the Skey EC is a secret key and uses a cryptographic algorithm different from the cryptographic algorithm used for the public key encryption.
• the resulting cryptogram CRYPTO EC i.e., Skey EC (RN SP . EC *STD EC * AI EC *TA), is then combined 282 with the transaction ID TID SP .
• the data portion 282 is fed into a one-way hash algorithm 288 to calculate the message digest MD EC and the MD EC is then digitally signed 290 by the EC's private key 292.
• the resulting digital signature 290 is combined with the data portion of the message (from 282) 294 to form EC's transaction request message and then sent to the merchant, [TID SP.EC *PLA1 TEXT EC *Skey EC (RN SP.E c*STD E c*Al E c*TA)]*DS EC . P ⁇ vate.Key .
• the merchant goes through essentially the same steps to form his transaction message.
• the merchant forms his transaction message by concatenating 246 the RN SP . M from the SP and the merchant's account information with the selected SP, AI M 248, transaction amount TA 252 and any other sensitive data STD M 250 relevant to the transaction and/or required by the SP.
• the merchant encrypts them 244 using the session key Skey M assigned by the SP.
• the session key Skey M is a secret key and is created using a different cryptographic algorithm, such as DES, from the cryptographic algorithm used for public key encryption.
• the session key Skey M is used to perform the encryption at this point to create the cryptogram CRYPTO M .
• the resulting cryptogram CRYPTO M i.e., Skey M (RN SP.M *STD M *AI M *TA) is then combined 254 with the transaction ID TID SP.M 256 and the plain text PLAIN TEXT M 258, if any, to form the data portion of the merchant's transaction message, TID SP .
• M *PLAIN TEXT M *CRYPTO M This data is combined 296 with the EC's transaction request to form the data portion of the final transaction request message for the SP, [TID SP . EC *PLA ⁇ N TEXT EC *Skey EC (RN SP.
• the merchant feeds his combined data through a one-way hash algorithm 298 to calculate the message digest MD M and the MD M is then digitally signed 300 by the merchant's private key 302.
• Kev 300 is combined 304 with the data portion of the message (from 296) to form the final transaction request message and is then sent to the SP, ⁇ [TID Sp.EC *PLALN TEXT EC *Skey EC (RNsp. EC *STD EC *AI E c*TA)]*DS EC .p ⁇ vate .
• the SP separates the data portion of the message, i.e., TID SP . M , PLAIN TEXT M ,CRYPTO M , DS M.P ⁇ vate.Key , (TrD SP . EC *PLAIN TEXT EC *CRYPTO EC )*DS EC . P ⁇ vate . Kev .
• the SP decrypts 310 the DS M . P ⁇ vate . Key using the merchant's public key and compares the newly recovered message digest MD M with the message digest just calculated MD ⁇ M (from 306).
• the SP decrypts 316 the encrypted portion of the message using the session key Skey M (of 210) it assigned to the merchant during the KE phase and recovers the data fields contained in the encrypted portion.
• the SP compares 318 the random number RN SP . M the merchant sends back in the message with the message the SP sent to the merchant originally, RN SP.M (from 208). If the random numbers are not equal, then the merchant has failed the mutual authentication test and the message is rejected 320.
• the SP will verify the EC's account information AI EC and the transaction data such as the transaction amount TA.
• the message is rejected 320 if the Al is no longer valid. It is also rejected when the TA from the EC and the TA from the merchant do not match. There may be other conditions for invalidating a message. If the account information AI EC and the transaction are valid, then the SP goes on to verify the EC portion of the message.
• the SP first separates 322 the DS Ec . Pnvate . Key from the EC's message and feeds the data portion of the EC's message, (TID SP _ EC * PLAIN TEXT EC *CRYPTO EC ) into a one-way hash algorithm to calculate the message digest MD ⁇ EC of the EC message.
• the SP separates the data portion of EC's transaction request, TID SP . EC , PLAIN TEXT EC , CRYPTO EC , DS EC . Pnvate . Key
• the SP decrypts 324 DS EC . Pnvate .
• the SP compares 326 the recovered MD EC with MD ⁇ EC . If MD ⁇ EC and MD EC are not equal, the message has been cormpted and is rejected 328. If MD ⁇ EC and MD EC match, then the SP decrypts 330 the encrypted portion of the EC message using the session key Skey EC (of 186) it assigned to the EC during the KE phase and recovers the data fields contained in it.
• the SP compares 332 the random number RN SP . EC the EC sends back in the message with the random number RN SP.EC it sent out to the EC originally (in 184).
• the SP will verify the merchant's account information AI M and the transaction data such as the transaction amount TA and will reject the message when the account information is invalid or when the transaction data does not meet the SP's criterion 334.
• the SP can process the data contained in the message and send a response message back.
• the random number that is sent back in this message completes the mutual authentication between the SP and the merchant, and between the SP and the EC. After this message, no exchange of random numbers will be necessary.
• the SP can chooses to use the random number as the transaction identification number which the merchant and the EC will use in all subsequent messages that they send to the SP.
• the response message contains information for both the EC and the merchant.
• the SP To format the transaction response message for the EC, the SP generates the response data for the EC, Response Datas P.EC 338, and encrypts 336 it using the session key Skey EC assigned to the EC. Only sensitive data is encrypted. Non-sensitive response data is included in the plain text.
• the cryptogram CRYPTO SP . EC i.e., E Skey . EC (Response Data SP . EC ), is combined 340 with the transaction identification number TID SP .
• EC 342 that the SP assigned to the EC (from 194) and the plain text that the SP has for EC 344, if any, to form the data portion of the response message for the EC, i.e., TID SP.EC *PLAIN TEXT SP . EC *E skey . EC (Response Data SP _ EC ).
• the data portion of the message is fed into a hash algorithm 346 to generate a MD SP . EC which is digitally signed 348 by the SP using the SP's private key 350.
• the DS SP . P ⁇ vate . Key is combined 352 with the data portion of the response message (from 340) to form the complete response message for the EC, [TID SP .
• the SP To format the transaction response message for the merchant, the SP generates the response data for the merchant. Response Data SP . M 356, and encrypts 354 it using the session key Skey M assigned to the merchant (from 210).
• the cryptogram CRYPTO SP . M is combined 358 with the transaction identification number TID SP.M assigned to merchant 360 (from 218) and the plain text PLAIN TEXT SP.M that the SP has for merchant 362, if any, to form the data portion of the response message for the merchant, TID SP .
• the data is then fed into a hash algorithm 366 to generate a MD SP . M which is digitally signed 368 by the SP using the SP's private key 370.
• the DS SP . Pnvate . Key is combined 372 with the data portion of the response message for both the EC and the merchant to form the complete response message for both the EC and the merchant, « ⁇ [TID SP . EC *PLAIN TEXT SP . EC *E skey . EC (Response Data SP.E c)]*DS SP.Pr ⁇ vate.Key ⁇ *[TID Sp.M *PLAIN TEXT SP.M *E Skey . M (Response Data SP . M )]» DS SP.P ⁇ vate. Key .
• the SP then sends its response message back to the merchant.
• Figure 10 depicts the final format of the transaction response message.
• the merchant When the merchant receives the message, the merchant first checks 374 the transaction identification number, TID SP.M, in the message and makes sure it is valid. If the transaction identification number is invalid then the message is rejected 376. If the TID SP . M is valid, then the merchant separates the DS SP.P ⁇ vate.Key which was signed by the SP from the data portion of the message, and then feeds the data portion of the transaction response message « ⁇ [TID SP . EC *PLAIN TEXT SP.EC *E Skey.EC (Response Data SP.EC )]*DS SP . Pr ⁇ vate . Key ⁇ *[TID SP . M *PLAIN TEXT SP.
• TEXT SP.M CRYPTO SP . M , DS SP.Pr ⁇ vate.Key (TID SP . EC *PLAIN TEXT SP . EC *CRYPTO S p. E c*DS SP .p ⁇ vate . Key ) and prepares to forward SP's transaction response message to the EC.
• the merchant decrypts 378 the encrypted portion of the SP's message using the session key Skey M assigned by the SP during the KE phase and recovers the data fields contained within it.
• the merchant uses SP's public key, PK SP (from 144), to decrypt the digital signature DS SP . ftlvlle . Key to recover MD SP.M .
• the merchant compares 380 the newly hashed MD ⁇ SP . M (from 374) with the recovered MD SP.M If MD ⁇ SP.M and MD SP.M do not match, then the transaction response message has been cormpted and is therefore rejected 382. If the message digests match, then the merchant starts processing the message. As usual, the EC portion of the transaction response message (TID SP.EC *PLAIN TEXT SP.EC *CRYPTO SP.EC *DS SP _ P ⁇ vate . Key ) is passed to EC.
• the EC When the EC receives the transaction response message, the EC first checks 394 the transaction identification number, TID SP . EC ⁇ in the message and makes sure it is valid. If the transaction identification numbers is invalid, then the message is rejected 396. If the transaction identification number is valid, then the merchant separates the DS SP . P ⁇ vate . Key which was signed by the SP, from the data portion of the transaction response message, and then feeds the data portion of the EC transaction response message TID SP . EC *PLAIN TEXT SP . EC *E Skey.EC (Response Data SP.EC ) into a one-way hash algorithm producing MD ⁇ SP . Ee The EC separates the message into different parts, TID SP .
• the EC decrypts 398 the encrypted portion of SP's message using the session key Skey assigned by the SP during the KE phase and recovers the data fields contained within it.
• the EC uses SP's public key (from 120) to decrypt the digital signature DS SP . P ⁇ vate . Key and recovers the message digest MD SP . EC .
• the merchant compares 400 the newly hashed MD A SP . EC 394 with the recovered MD SP . EC . If MD ⁇ SP . EC and MD SP.EC do not match, then the transaction response message has been corrupted and is therefore rejected 402. If the message digests match, then the EC starts processing the message.
• the EC and the merchant can, if required by the SP, send an acknowledgement message to the SP to signal that the response message has been correctly received and processed.
• This acknowledgement data can be included as a part of the next message to be sent to the SP, if there are more messages to be exchanged between the SP and the merchant and the EC before the transaction ends. Or the acknowledgement data can be a message by itself.
• the EC To format the acknowledgement message, the EC first encrypts 404 the sensitive part of the acknowledgement data, Acknowledgement Data EC , 406, if any, using the session key, Skey EO thus creating Skey EC (Acknowledgement Data EC ).
• the EC combines 408 the resulting cryptogram with the transaction identification number TID SP .
• EC 410 assigned by the SP and the plain text PLAIN TEXT EC 412, if any.
• This combined data is then fed into a one-way hash algorithm 414 to generate the 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 . Pr ⁇ vate . Key .
• the merchant goes through the same steps to form his own acknowledgement message.
• the merchant first encrypts the sensitive parts of the acknowledgement data, Acknowledgement Data M 386, if any using the session key Skey M assigned by the SP to merchant, thus creating Skey M (RN SP . M * Acknowledgement Data ⁇ .
• the merchant combines 388 the resulting cryptogram with the transaction identification number lTD S p .M 390 assigned by the SP, and the plain text PLAIN TEXT M (from 392), if any. This forms the data portion of the merchant's acknowledgement message, TID SP . M * PLAIN TEXT M * Skey M (RN SP.M * Acknowledgement Data ⁇ ,).
• This data portion is further combined 422 with the acknowledgement message received from the EC to form the data portion of the combined acknowledgement message for the SP, ⁇ [TID SP . EC * PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )]*DS Ec.P ⁇ vate . Key ⁇ *[TID Sp.M *PLAIN TEXT M *Skey M (Acknowledgement Data M )].
• the merchant feeds the data portion of the combined acknowledgement message for the SP into a one-way hash algorithm to generate the message digest MD M .
• the resulting MD M is then digitally signed by the merchant using the merchant's private key 428 to generate DS M . Pnvate.Key 426.
• the DS ⁇ p ⁇ . ⁇ is combined 430 with the data portion of the message (from 422) to form the final combined acknowledgement message of the EC and the merchant designated for the SP, « ⁇ [TID Sp.EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] *DS Ec . Pnvate . Key ⁇ * [TID SP. M *PLAIN TEXT M *Skey M (Acknowledgement Data M )]»*DS M . Pnvate . Key .
• TID SP.M is the transaction identification number assigned by the SP to the merchant (from
• TID SP. EC is the transaction identification number assigned by the SP to the EC (from 194).
• the SP checks 432 the two transaction identification numbers, TID SP . M and TID SP . EC , sent by the EC and the merchant and makes sure they are valid. When either TID SP . M or TID SP . EC is found invalid, then the message is rejected 434.
• the SP proceeds to separate the DS M.P ⁇ vate.Kev from the combined acknowledgement message and feeds the data portion of the combined acknowledgement message « ⁇ [TID SP _ EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] *DS E c-p r , va , e - ⁇ ey ⁇ * [TID SP . M *PLAIN
• the SP decrypts 436 the DS M . P ⁇ vate . Key using the merchant's public key PK M and compares the recovered message digest MD M 432 with the message digest just calculated MD ⁇ M 436. If MD ⁇ M and MD M are not equal, then the message has been cormpted and is rejected 440. If MD ⁇ M and MD M match, then the SP decrypts 442 the encrypted portion of the merchant's acknowledgement message using the session key Skey M (from 210) that it assigned to the merchant during the KE phase and recovers the acknowledgement data contained within it.
• the SP separates 444 the DS EC.P ⁇ vate.Key from the EC's acknowledgement message and feeds the data portion of the EC's acknowledgement message, TID SP .
• EC *PLAIN TEXT EC *CRYPTO EC into a one-way hash algorithm to calculate the message digest MD ⁇ EC of this message.
• the SP separates the data portion of the EC's acknowledgement message, TID SP . EC , PLAIN TEXT EC , CRYPTO EC , DS Ec .p ⁇ vate . Key .
• the SP decrypts 446 the DS E c_ P ⁇ vate . ⁇ e y using the EC's public key PK EC and compares 448 the recovered MD EC with the message digest just calculated MD ⁇ EC 444. If the message digests are not equal, then the message has been corrupted and is rejected 450. If MD ⁇ EC and MD ⁇ match, then the SP decrypts 452 the encrypted portion of the message using the session key Skey EC (from 186) that it assigned to the EC during the KE phase and recovers the acknowledgement data contained within it. This completes the processing of the transaction phase of the transaction 454. Throughout the transaction, in a preferred embodiment, the EC works with interface software provided by Internet browser software such as the Microsoft Explorer or Netscape Navigator.
• the cardholder points his browser to the merchant's URL and orders goods or services from the merchant.
• the browser will invoke the EC interface software, which can be built into the browser or included as a plug-in or add-on sof ware component, and allow the transaction to proceed.
• the cardholder can point his browser to the URL of any SP member.
• the two-phased transaction described in figure 6A-6Q above is just a specific case of applying the two-phased key-exchange-transaction model.
• the number of parties involved in the transaction is three: the EC, the merchant and the SP.
• the two-phased key-exchange-transaction model is similarly applicable to cases where the number of parties involved varies from two to many. In a transaction that involves more than three parties, there is only one party that plays the role of the SP. All other parties use the public key of the selected SP to perform the initial key exchange and use session keys and transaction Ids assigned by the SP to carry out the transaction.
• the two-phased key-exchange-transaction model is applicable to organization schemes wherein: (1) the participants can be arranged with possible routers in series with the service provider; or (2) the participants can be arranged with possible routers in a hierarchical organization.
• These additional organization schemes may involve routers, which route messages to the next level.
• a level of a hierarchy may be composed of any number of participants and/or routers.
• the next level is the next participant or router that is next in the sequence or hierarchy.
• the next level includes all possible next participants and routers.
• the SP establishes the criterion for determining the next participant or router to which a message is sent.
• a router is a gateway/conduit, which collects the messages from a previous level and performs some processing on the messages according to an SP's requirements such as combining them, and then forwards the messages to the SP.
• Each participant need only form his own message (data and digital signature) and send it to the next level.
• a participant combines all the messages he receives with his own message and digitally signs the combined message before sending it to next level.
• there is only one message router which collects messages from all the other participants and sends the combined message to the SP.
• an originator of a transaction is in series with routers and/or participants who in turn are in series with a service a service provider 60.
• each element shown in figure 12 is a participant.
• any intermediate element between the originator and the SP can be a router.
• An originator conducts a transaction with participants 1100, 1120, 1140 andl 160 and a service provider that have been arranged in series as shown in Figure 12. This is similar to the three-party scenario described in figures 6A-6Q except for the fact that now there is more parties involved. Note participants 3,4,5,6 ... n-2 that have been arranged in series 1180. Each of the participants prepares his own message, incorporates it with the message he receives from a prior participant, if any, appends a digital signature with the message, and then sends it to the next participant in the line. The combined message is eventually sent to the SP and the SP forms the response message accordingly and sends it back through the same path the original request message has traveled.
• the upward pointing bold arrow represents sending a request message 1220.
• the downward pointing arrow represents sending a response message 1230.
• a hierarchical organization scheme may include only one participant to as many as is required (The most regressive case of the hierarchical scheme is one participant and one service provider).
• X ⁇ where ⁇ is of type n, all messages are combined into one message 1240, which is then sent to the SP 60. Again, the SP forms the response message and sends it back through the same route.
• a transaction can occur between two or more members.
• the messages can flow from member to member in any order.
• a member sends a transaction request message and receives a transaction response message.
• a member does not necessarily have to receive a transaction response message from the same member that he sent the transaction request message. For example, three members in a transaction can be organized in a ring and send messages around the ring.
• a first member can send a transaction request message to a second member who in turn sends a transaction request message and a transaction response message to 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 a second member.
• a member receiving a transaction request message creates a transaction response message, which eventually will be sent to the member who sent the transaction request message .
• the SP obtains the public keys of all the transaction participating members.
• the SP sends to each participating member, the other members' public keys prior to the participating members conducting a transaction among them.
• the transaction request messages and the transaction response message include plain text, if any, a cryptogram, and a digital signature of the sending party.
• the SP shields the EC and/or the merchant from the operation of the external interface.
• the SP only returns to the EC and/or the merchant, the information needed to complete the transaction with the EC and/or the merchant.

Landscapes

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

Priority Applications (6)

Applications Claiming Priority (2)

Publications (2)

Family

ID=22183802

Family Applications (1)

Country Status (8)

Cited By (18)

Families Citing this family (12)

Citations (2)

Family Cites Families (5)

• 1999
  • 1999-05-05 CN CNA2007100063782A patent/CN101087189A/zh active Pending
  • 1999-05-05 CN CNB998070726A patent/CN1307818C/zh not_active Expired - Fee Related
  • 1999-05-05 GB GB0026755A patent/GB2353623B/en not_active Expired - Fee Related
  • 1999-05-05 JP JP2000547720A patent/JP2002514839A/ja active Pending
  • 1999-05-05 CA CA002329032A patent/CA2329032C/en not_active Expired - Fee Related
  • 1999-05-05 AU AU43075/99A patent/AU762708B2/en not_active Ceased
  • 1999-05-05 WO PCT/US1999/009938 patent/WO1999057835A1/en active IP Right Grant
  • 1999-11-04 TW TW88119209A patent/TW476202B/zh not_active IP Right Cessation
• 2002
  • 2002-01-15 HK HK02100280A patent/HK1038657A1/xx not_active IP Right Cessation
• 2004
  • 2004-09-16 JP JP2004270384A patent/JP2005065315A/ja active Pending

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events