Method and system for a virtual safe6941285Abstract A transaction server for performing a transaction over a network using a virtual smart card the server comprising, a virtual smart card database having a plurality of records each record including a virtual card identification and a value corresponding to a single virtual smart card; a security module; an emulator for emulating a smart card, the emulator for receiving smart card commands and processing the commands in conjunction with the virtual smart card database and the security module; and a virtual card reader module for receiving the smart card commands and relaying the commands to the smart card emulator whereby transactions are performed over the network using one or more the records and the virtual smart card database. Claims 1. A method of performing a secure electronic commerce transaction over a network using a smart card, said network having a client terminal, a merchant server, a payment server, and an authentication server, said smart card being a physical smart card or a virtual smart card, said smart card being associated with a user at said client terminal, said smart card having associated smart card information, said smart card information including an account balance, said smart card information being stored at said client terminal and at said authentication server, said method comprising the steps of: Description BACKGROUND OF THE INVENTION
According to another aspect of the invention, the network is the Internet. According to another aspect of the invention, the debit result message is encrypted. According to another aspect of the invention a transaction server is provided for performing a transaction over a network using a virtual smart card. The server includes:
According to another aspect of the invention, a method for performing a transaction over a network using a virtual smart card and a server is provided. The method includes the steps of:
According to another aspect of the invention, the server's security module includes a plurality of encryption algorithms. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention may best be understood by referring to the following description and accompanying drawings. In the description and drawings, like numerals refer to like structures or processes. In the drawings: FIG. 1 is a block diagram illustrating VirtualSAFE software modules in accordance with an embodiment of the invention; FIG. 2 is a flowchart illustrating the operation of the secure remote pointer component of VirtualSAFE in accordance with an embodiment of the invention; FIG. 3 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in the general case in accordance with an embodiment of the invention; FIG. 4 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a second case in accordance with an embodiment of the invention; FIG. 5 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a third case in accordance with an embodiment of the invention; FIG. 6 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a fourth case in accordance with an embodiment of the invention; FIG. 7 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a fifth case in accordance with an embodiment of the invention; FIG. 8 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a sixth case in accordance with an embodiment of the invention; FIG. 9 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a seventh case in accordance with an embodiment of the invention; FIG. 10 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in an eighth case in accordance with an embodiment of the invention; FIG. 11 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a ninth case in accordance with an embodiment of the invention; FIG. 12 is a flowchart illustrating CA process steps in VirtualSAFE in accordance with an embodiment of the invention; FIG. 13 is a block diagram illustrating participants and their contractual relationships in VirtualSAFE in accordance with an embodiment of the invention; FIG. 14 is a block diagram illustrating the enrollment process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 15 is a block diagram illustrating the online transaction process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 16 is a block diagram illustrating the server authentication process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 17 is a block diagram illustrating the computer authentication process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 18 is a block diagram illustrating the user authentication process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 19 is a block diagram illustrating the back-end authentication process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 20 is a block diagram illustrating the fulfillment process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 21 is a block diagram illustrating the attribute authentication authority process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 22 is a block diagram illustrating the virtual identity (VI) process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 23 is a block diagram illustrating the virtual smart card (VSC) process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 24 is a block diagram illustrating the VirtualSAFE deposit box (VSDB) process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 25 is a block diagram illustrating the point-of-sale (POS) and virtual smart card (VSC) emulation process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 26 is a block diagram illustrating the ATM and virtual smart card (VSC) emulation process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 27 is a block diagram illustrating the wireless POS and ATM process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 28 is a block diagram illustrating the SAFEcheck process in VirtualSAFE in accordance with an embodiment of the invention; FIG. 29 is a block diagram illustrating physical access control in VirtualSAFE in accordance with an embodiment of the invention; FIG. 30 is a block diagram illustrating VirtualSAFE from a business-to-business perspective, and including an e-portal, in accordance with an embodiment of the invention; and, FIG. 31 is a block diagram illustrating VirtualSAFE from a business-to-consumer perspective, and including a merchant, in accordance with an embodiment of the invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known software, circuits, structures and processes have not been described or shown in detail in order not to obscure the invention. In the description and drawings, like numerals refer to like structures or processes. The term "VirtualSAFE" is used herein to refer to a system, including software, for secure electronic commerce using virtual smart cards in accordance with an embodiment of the invention. VirtualSAFE may include machines for processing data, including the computer systems and network arrangements described herein. System. VirtualSAFE is an electronic commerce system which includes a client terminal, a merchant server, a payment server, and a VirtualSAFE authentication server. The client terminal, merchant server, payment server, and VirtualSAFE authentication server are in communication over a network, typically, the Internet. Using a web browser, a user at the client terminal browses through product and service web pages presented by a merchant through the merchant server. The user may purchase products and services from the merchant using a virtual smart card. The VirtualSAFE authentication server authenticates the user through the software modules and method described below. In general, the payment server fulfills the e-commerce transaction. VirtualSAFE has stored therein data representing sequences of instructions which when executed cause the method described herein to be performed. Of course, VirtualSAFE may contain additional software and hardware a description of which is not necessary for understanding the invention. Modules. Referring to FIG. 1, there is shown a block diagram illustrating VirtualSAFE software modules 100 in accordance with an embodiment of the invention. VirtualSAFE software modules 100 include the following: Public Key Infrastructure (PKI) 101; Redirection Link (RL) 102; Secure Remote Pointer (SRP) 103; Attribute Authority (AA) 104; Virtual Identity (VI) 105; Virtual Smart Card (VSC) 106; Secure Data Repository 107; VirtualSAFE (or Authentication Authority) Server 108; Crypto-Engine (CEV) 109; Payment Processing Engine 110; Risk Management Engine 111; Transaction Fulfillment Mechanism (TFM) 112; Insurance Module 113; Secure Transaction Repository 114; and VirtualSAFE Deposit Box (VSDB) 115. These modules are described in detail in the following beginning with the VirtualSAFE server 108 and Crypto-Engine (CEV) 109. VirtualSAFE Server 108. Advantageously, the VirtualSAFE server 108 (or authentication server) dispenses with the need for physical smart cards and card readers. In the following, physical smart card transactions are contrasted with virtual smart card transactions as coordinated by the VirtualSAFE server 108. Physical Smart Card Transactions. Typically, local cardholder functions include a consumer card interface. Display and accept/cancel options are performed at the client terminal. Payment functions, including security card control, data storage, and the use of a concentration point, are performed by a payment server. The presentation and eventual delivery of goods and services by a merchant are performed under the control of a merchant server. The Internet performs routing functions between each entity. It should be appreciated that the Internet may include its present form or it may include any other open network implemented using a combination of computer, telephone, microwave, satellite, or cable networks. The client terminal controls the interaction with a consumer and interfaces to the card reader that accepts a smart card having a stored-value application. The payment server communicates directly with a terminal or through a concentrator that handles a number of terminals each having a security card. The payment server also communicates with the concentration point for transmission of transaction data to a clearing and settlement system. The database stores all the appropriate information passing through the payment server for each transaction. Use of such a database allows any number of merchants (or merchant servers) to use the payment server for transactions. The payment server controls payment functions such as handling attached terminals, managing the database, and collection functions. The merchant server is typically a site that has contracted with an acquirer to accept smart card transactions as payments for goods and services purchased over the Internet. As discussed above, the smart card may take a variety of forms and is useful in many situations where it is desirable to store monetary value on a card that a consumer may use. Generally speaking, the smart card is any card or similar device able to store a value and decrement that value when the card is used. The card may be purchased complete with a stored value or a given value may be added to the card later. Such cards may also have their value replenished. The smart card may also perform a variety of functions in addition to simply storing value, for example, debit, credit, prepayment, and other functions. Such a card typically includes information such as a bank identifier number, a sequence number, a purchase key, a load key, an update key, an expiration date, a transaction ID, and a running balance. The smart card may include an encryption module in order to provide a variety of security features. For example, security features may include simple PIN numbers, biometrics, simple algorithms, or sophisticated algorithms such as the Data Encryption Standard (DES) or Rivest Shamir Adelman (RSA) encryption. Typically, a smart card is able to use these features to verify consumers and card readers, to validate security cards, and to provide a unique digital signature. A smart card may include any number of keys which are known to the card issuer and that are used during the course of a payment or load transaction to generate digital signatures for validation of the stored-value card, security card or module, or the system itself. The client terminal may be any suitable device for interacting with the card and for communicating over a network with a payment server and a merchant server. For example, the client terminal may be a mainframe computer, a workstation, a personal computer, a set top box, a kiosk, or any type of service payment terminal that a consumer might use to purchase goods and services. The client terminal may also be embodied in any portable device including a laptop computer, a cellular telephone (including GSM telephones), or a personal digital assistant (PDA). The card reader may be any suitable interface device that is capable of transferring information and commands between the client terminal and the card. Typically, the client terminal includes a "client code module" and a "card reader module". The card reader module may be implemented using any suitable software and libraries for communicating with the card reader. Its actual implementation will depend upon the type of card reader used. The client code module controls communications between the client terminal, the card reader, the payment server, and the merchant server. The client code module may be implemented using any suitable software. For example, the client code module may be implemented using a combination of "C" code and a Java applet. The applet may be supplemented with parameters from an HTML page sent from the merchant server. The client code module is also responsible for controlling displays presented to consumers and for the interaction between the card and the card reader. This module also builds the draw request message after receiving all of the start-up information from the card and the amount of the purchase from the merchant server. Typically, the payment server includes a payment code module and a terminal interface. As with the client terminal, the payment server may be implemented using any suitable computer, for example, a personal computer. There may be one payment server for each merchant server or a single payment server may service any number of merchant servers. There may be multiple payment servers for a single merchant. In addition, the payment server need not be remote from the merchant server but may be located at the same site and have a different Internet address. Or, the payment server and the merchant server may be implemented on the same computer. The payment server is designed to facilitate communications between the consumer's smart card and a terminal's security card. The payment module may be implemented using any suitable code. For example, the payment module may be implemented using a combination of "C" code, "C++" code, and Java code. The payment module may be a multi-threaded process that can service multiple concurrent client applet transactions on demand. The module is responsible for controlling all interactions with terminals including the transaction collection function. For individual transactions, the payment module controls message flow and logs interim results. When an applet connects with the payment server, it creates a transaction thread to support the transaction through its life cycle. Each thread, in turn, assigns a terminal for communications. A one-to-one correspondence between transaction threads and terminals may provide good results. Typically, the terminal interface is any suitable set of software and libraries for communications with a terminal either directly or through a terminal concentrator. The actual implementation of the terminal interface will depend upon the type of terminal used. For example, an IQ Delta 2010 terminal made by Schlumberger may be used. Such a terminal supports a variety of commands originating from the terminal interface. These commands emulate the normal responses from a smart card to a security card should both be located in the same service payment terminal. The actual security card commands are held in the terminal while the terminal performs the tasks necessary to simulate the presence of a smart card. The emulation of the card commands can be done by the payment server using the terminal as a card reader, or may even be performed by the client terminal. Typically, the security card is any suitable security card such as those that are known in the art (often referred to as a Purchase Secure Application Module or PSAM). The functionality of the security card may be replaced by a crypto-engine (as is done in VirtualSAFE), may be implemented in hardware within the payment server, or may be implemented in software. For example, the security card may be a removable credit card-sized smart card that is programmed to process and store data relating to financial transactions. The security card may contain a microchip embedded in the card that enables the card to authenticate and to validate the consumer's smart card. If the consumer smart card is acceptable to the security card, and if the smart card contains sufficient value, then the security card guarantees that the merchant providing goods and services will receive payment in the amount deducted from the smart card. The security card may also contains DES and public key purchase security keys, may authenticate the smart card during a purchase transaction, and may secure the payment and collection totals. A security card may also store digital signature algorithms for all smart cards in use. A security card may also contain a transaction identifier for the current transaction, a financial sum of all transactions remaining to be settled, a session key, and master keys for all smart cards in use. Further, the security card may contain generations of keys, blocked card indicators, dates of last update, multiple card programs, different currency rates, and additional security. The concentration point is typically a staging computer that communicates with a payment server to collect batches of purchase transactions. The concentration point then sends these transaction batches to a clearing and settlement system for processing. Once processed, batch acknowledgments, along with other system updates, are returned. Typically, the merchant server includes a merchant code module. The merchant server may be implemented on any suitable computer capable of communicating with and presenting information to consumers over the Internet. The merchant code module may be implemented using any suitable code. For example, the merchant module may be implemented using a combination of Perl, HTML, and Java code. The merchant server is typically a generic web server customized for the merchant's business. The merchant server may include databases, CGI scripts, and back-office programs that produce HTML pages for an Internet user. During a financial transaction, the client terminal and the merchant server exchange information via the Internet. Each transaction initiated by a consumer has a transaction identifier created at the merchant server. A merchant identifier unique to the payment server is also available from the merchant server. The client code module and the payment server also use this unique transaction identifier for tracking and logging information about the transaction. The merchant server generates a unique identification for the transaction, completes other required parameters, encrypts as appropriate, and builds an HTML page and sends it to the client terminal. The client code module interacts with the smart card and builds a "draw request message" containing related card information, the purchase amount, and other information supplied by the merchant server. Next, the client terminal communicates with the payment server by first forwarding the draw request to the payment server. The payment server verifies the transaction to determine if it is a valid transaction from a known merchant. The transaction is logged in the payment server's transaction database. Upon completion of a transaction, the payment server builds a result message containing the identification of the transaction and signs it. The message is then routed to the merchant server via the client terminal. The merchant server then validates the result message. After determining that the transaction was successful, the merchant server creates an HTML page for the purchased information and sends it to the client terminal. The merchant may also deliver purchased goods and services to the consumer at this point. It is also possible for the payment server and the merchant server to communicate information directly between them. As the client terminal has already established communication with the merchant server and the payment server, links are used to exchange information between the payment server and the merchant server, rather than establishing a new link. Virtual Smart Card Transactions. Similar to transactions with physical smart cards, the system includes the client terminal, the payment server, and the merchant server. However, the system dispenses with the need for the physical smart cards and card readers as their functionality is contained within the VirtualSAfE server 108. In VirtualSAFE, the client code module is functionally part of the VirtualSAFE server 108 instead of being part of the client terminal. And, the functionality of the card reader module for transactions with physical smart cards is included in the client code module to allow communication with a "pseudo technology process module" (see below). Also, the user interface functionality of the client code module is transferred to a client terminal module in the client terminal. In this embodiment, a "pass through" client code module serves to "pass through" communications between the merchant server and the VirtualSAFE server 108. Again, the VirtualSAFE server 108 effectively replaces the need for physical smart cards and card readers. To achieve this, the server 108 implements a "pseudo technology process module" and smart card emulator in software. A card database stores information representing "virtual" smart cards 106 (see below) in use within the system. The card emulator interacts with the card database and a crypto-engine (CEV) 109 (see below) to effectively replace physical smart cards and card readers. Thus, the client code module may be implemented as before unaware that it is interacting with a software emulation of a smart card rather then with a physical smart card. The VirtualSAFE server 108 stores the same data used with physical cards in its database and handles incoming commands from initiation or payment servers to increment or decrement a "card" balance as appropriate. Important data is stored in encrypted form and all functions that require a change to important data or the generation or checking of digital signatures is performed by the CEV 109 (see below). The VirtualSAFE server 108 is typically located at an issuer's site. One such server may support multiple issuers provided appropriate safeguards are in place to partition data. Furthermore, to support interoperability with existing financial networks, including different credit card vendors, financial institutions, and processing gateways, the VirtualSAFE server 108 may be located at an acquirer's site. This configuration does not change existing transaction flows and does not require additional investment to secure the financial network. In an alternative embodiment, the client terminal includes a card reader and a smart card. In this embodiment, the client terminal includes a client code module with "pass through" functionality. The system may operate in either of two modes. The system may operate without using a physical smart card by using the emulation contained within the VirtualSAFE server 108. Concurrently, or at a later date when smart cards and readers are more common, the system may be upgraded to make use of a physical card and reader attached to the client terminal. The VirtualSAFE server 108 communicates with the client terminal through a "user verification module" and with the payment server over a link. The server 108 emulates a physical smart card through the use of the pseudo technology process module, a "smart card emulator", the crypto-engine (CEV) 109, and the database 105, 106, 107, 114, 115. The user verification module allows the VirtualSAFE server 108 to identify which user is logged on to the system and desires access to a virtual card in the database. The module provides a login procedure that requires a secret user identifier and PIN from each user. A combination of this user identifier and PIN is then used as an index into the database to identify the record that represents the virtual smart card 106 for that user. The user verification module may also include the card identifier (digital certificate digital signature) for the user, the funding account and its expiration date, and address information for address verification during the funding portion of the initiation transaction. An address verification system may compare billing information from an authorization to that on file to assure that the real cardholder is making the transaction. The pseudo technology process module is a software module that performs the functionality of a physical card reader so that the emulation of a smart card is transparent to the client code module. The card reader module accepts the actual card reader commands from the client code module and, instead of using them to drive a physical card reader, places them into a format to communicate with the smart card emulator that is emulating a smart card. Thus, an existing application programming interface (API) used by the client code module to communicate with a smart card may continue to be used. In an alternative embodiment, the card reader module and the emulator may be collapsed into a single functional block although this may require modification of the commands issued by the client code module. The smart card emulator emulates a physical smart card by accepting and passing the incoming card commands from the card reader module and determining actions to perform. In the course of performing these actions, the emulator handles the interface to the CEV 109, fetches data from, and stores data to, the database. For example, upon receiving a command to debit a card, the emulator fetches the balance from the appropriate record in the database and transfers the encrypted balance to the CEV 109 to be decrypted and decremented. Once the new balance is encrypted by the CEV 109, the emulator receives the new balance and stores it back in the transaction secure database. Once an action has been performed, the emulator generates a simulated smart card response that is then relayed via the card reader module and the client code module to the payment server. The emulator generates card commands that appear as if they have been generated by a physical smart card, thus making emulation of the smart card transparent to the rest of the system. The emulator also updates the secure transaction database 114 at appropriate steps in the processing of a debit or an initiation. In addition to debiting or initiating a virtual card in the card database, the server 108 is able to credit a virtual card if the card was debited by mistake. In other words, once a card has been debited to make a payment, the server 108 is able to recover that value and credit the virtual card in the card database, if necessary. For example, if a transaction fails and value has been taken off the card, but no value has been credited to a particular payment server, the system is able to credit the virtual card in the card database to replace the lost value. Such an operation is different from a formal initiation command in that a user's card is credited for a value that had earlier been taken off the card. VirtualSAFE's databases 105, 106, 107, 114, 115 may be implemented in any suitable format and contain records for each virtual smart card in use within the system. A secure transaction repository 114 and a secure data repository 107 include the information for each virtual smart card in use and thus assists in the simulation of physical smart cards. An identifier such as a user name, PIN, or combination thereof is used as an index into the database in order to identify the appropriate virtual smart card 106 for initiating, debiting, or authentication. Advantageously, the information contained in the database is typically stored in an encrypted form for security. In one embodiment, the database are implemented in Sybase. Records in the database store a variety of data for each virtual smart card 106. This information includes initiation and purchase key identifiers, card and issuer certificates, initiation algorithms, initiation key versions, purchase algorithms, purchase key versions, a bank identification number (BIN), a VirtualSAFE Deposit Box (VSDB) 115 number, a transaction ID, a balance, a currency and exponent, an expiration date, and a maximum balance. Initiation and business public keys indicate which keys should be used. Although all keys may be stored within CEV 109, in one embodiment, the keys are stored within the secure data repository 107 as well, with the exception of the CEV master key that is stored in the CEV 109. The secure transaction repository 114 stores information regarding transactions that occur such as a debit or an initiation and may be implemented in a similar fashion as the other databases. Also referred to as a history database, the secure transaction repository 114 includes a purchase table (i.e. log full of transactions and timestamps) and an initiation table (i.e. log full of transactions, funding request/response, and timestamps). Crypto-Engine (CEV) 109. The CEV module 109 is used to facilitate cryptographic processing. As will be described below, the CEV 109 stores secret keys and encryption algorithms, performs cryptographic functions on secret data and generates digital signatures. Typically, the CEV 109 is a tamper-proof device that employs a level of physical security as means to protect the sensitive information contained therein. The CEV 109 may be suitable security module, for example, it may be similar to the security box typically attached to automatic teller machines. In another embodiment, the CEV 109 may be implemented on a smart card within a card reader, on a series of smart cards, on any suitably secure computer, or in software. In addition to other tasks, the CEV 109 performs encryption for physical smart cards. For a physical smart card, various data elements such as balance and currency are contained securely within the card. However, such data elements are not stored within the CEV 109 but are stored in the server's 108 database. Typically, important information is stored in an encrypted form in the database. The CEV 109 performs the task of receiving encrypted card data from the database via an emulator, decrypting the card data, performing required cryptographic functions on the data, and then encrypting the data and sending it back out to be stored in the financial information database 114 and secure data repository 107. For example, if the card balance is to be reduced, the encrypted balance is sent from the database to the CEV 109 where it is decrypted, reduced, and then finally encrypted again before it is returned to the database. The CEV 109 also performs cryptograph functions related to digital signatures used within the system. Digital signatures are used during the initiation operation and typically are generated by the smart card. Some digital signatures are used during an initiation or purchase operation and are generated by the issuer or the payment server. Some digital signatures are generated by the smart card on occurrence of an initiation or debit and are considered the final digital signature after the card has either initiated value onto, or debited value from, itself. In VirtualSAFE, the CEV 109 performs these functions which are normally handled by a smart card as no physical smart card need be present with VirtualSAFE. The CEV 109 is used to generate digital signatures and verify digital signatures for an initiation operation, and is used to verify digital signatures and generate digital signatures for a purchase operation. The CEV 109 may also perform other cryptographic functions that would normally be performed by a physical smart card. Initiation algorithms are identifiers that identify which cryptographic algorithm of the CEV 109 is to be used for the verification and generation of digital signatures during an initiation. The initiation key version is an identifier identifying which version of a key will be used for the generation or verification of a particular digital signature. Purchase algorithms and purchase key versions perform a similar function during a purchase. A six-digit BIN in combination with the ten-digit TEP forms a sixteen-digit "identification number" that uniquely identifies a particular virtual smart card 106. This identification number may also be referred to as a "card identifier". Each BIN, or card range, has a single maximum balance and currency for all of its virtual cards. The balance keeps track of the value for the particular card. Currency and exponent information provide further details concerning the balance. An expiration date provides an expiration date for the card. The maximum balance provides a maximum for the virtual card, or could also indicate a maximum balance for all virtual cards associated with a BIN. Public-Key Infrastructure (PKI) 101. VirtualSAFE is compliant with PKI standards for X.509 v1 and v3 certificates, RSA cryptography, PKCS #11 certificates, S/MIME certificates, PKIX v3 extensions, and Secure Electronic Transactions (SET). The PKI process 101 consists of multi-tiered and distinct Certificate Authorities (CA) defined as follows:
As will be described below, VirtualSAFE has an Attribute Authority (AA) 104 designated for managing access and network permission attributes for users. Redirection Link (RL) 102. The redirection link 102 allows non-repudiation by using digital certificates and a secure algorithm and protocol residing on a remote merchant or business site. The redirection link 102 enables an online e-commerce process to access VirtualSAFE's secure transaction environment. The associated process consists of the following steps:
The redirection link 102 allows non-repudiation by using X.509 certificates and a secure algorithm and protocol residing on a remote merchant, business, or resource site. The redirection request, once processed, initiates the Secure Remote Pointer (SRP) 103 process for encrypting, signing, and hashing transferred data. The SRP 103 is described below. The merchant and/or user can digitally sign the transaction. Secure Remote Pointer (SRP) 103. The SRP 103 is a composite secure algorithm and protocol residing on a remote site (i.e. VirtualSAFE, merchant, user or any other entity) that provides encrypt/decrypt and digital signing timestamp functionality for communicating with VirtualSAFE. The SRP 103 is a VirtualSAFE compatible application that runs as a web browser plug-in, applet, or standard application. The client browser, to conduct secure communications with VirtualSAFE, uses the SRP 103. The process is initiated when the user clicks on a redirection link (RL) 102 that requires an authentication and authorization check. Clicking on this RL 102, as described above, implies a commitment to access a resource, for example, a payment transaction or a secure database. In order to execute a transaction, authentication of the user is required. The process requires authentication of the user computer via an X.509 Digital Certificate or other standard PKI format. Once authenticated with a digital certificate the user, application, or browser will always communicate with VirtualSAFE via the secure web browser plug-in or the SRP 103 or application. The security approach to the SRP 103 includes multi-layer security via encryption and enveloping techniques. The SRP 103 functions include encryption of data that will be packaged and then encrypted via secure sessions in addition to an SSL communication channel with the VirtualSAFE database to complete transactions and store operational data, or for other accesses purposes. Referring to FIG. 2, there is shown a flowchart illustrating the operation of the secure remote pointer (SRP) 103 in accordance with an embodiment of the invention. In order to securely capture and store data from the customer, the following steps and requirements are incorporated in the SRP 103:
Attribute Authentication Authority (AA) 104. The AA 104 is an internal and external VirtualSAFE module that enables the assignment of authorization to users and applications to access network resources, and remote non-repudiation providing valid digital signature and verification mechanisms for new or existing financial and other information infrastructures. The implementation of a remote electronic commerce application requires managing access to electronic resources. The core value of an e-commerce application lies in the ability to manage identities and the associated privileges attached to these identities. In traditional approaches to PKI, a Certification Authority (CA) issues and revokes certificates used to bind a name to a public key. However, the existing certificate structure requires an existing name space where each individual is uniquely identified with a unique name and often a unique number. In e-commerce transactions, the merchant server may be assured of the customer's identity by means of digital certificate verification. However, the authorization of the customer identity to actually perform the transaction (or other access privilege) is not necessarily a given. Advantageously, VirtualSAFE provides a means for the merchant to be certain that the actions to be undertaken are legally binding and the signer indeed has the authority to execute them. In VirtualSAFE, digital certificates are enhanced by including attributes that provide or grant a privilege to its owner. The benefit of this approach makes the attribute certificate well suited for system access control or authorization control. By definition, access control entails the limiting of activities of a user on the system. Enforcement of such controls is accomplished by maintaining a reference monitor that mediates access attempts by consulting an authorization base to determine if the user attempting the access is authorized to gain access. A distinction is made here between authentication and access control; authentication confirms the identity of the user, while access control establishes identity privileges on the basis of successful authentication. Access control may be deployed in one of two modes, namely, an activity-based mode or a group-based mode. In the activity-based mode, user access control is managed according to activity monitoring where each access is checked against an authorization table and permissions are granted or denied on that basis. In the group-based mode, user access control is based on the group to which a user belongs. Users of the same group are authorized to perform a specific set of system tasks or actions. Instead of specifying all the individual user authorizations, actions are assigned according to the group such that an individual user may perform the tasks assigned to the user's group. Group-based access control is characterized by the following:
A group-based model is advantageous on several levels. For example, overall administration is shifted to the group level from the individual user level. A user may have several authentications including the following:
The digital certificate infrastructure is well suited for this approach to access control. In the standard digital certificate, a public key is signed by a Certification Authority (CA) and distributed for authentication purposes. The same principle is applied to group-based access control. In this method, a group is described by a set of attributes that enable the members of the group to perform common functions. The attributes are bound together by a digital signature by a CA, creating an Attribute Certificate (AC), which is consequently unalterable until a new set of attributes is designated and signed. The Attribute Certificate may contain the following fields:
The attribute authentication authority (AA) 104 is advantageous for authentication and authorization of business processes. Typically, existing business processes use some means of account-based protocol to evaluate attributes. However, these methods are reliant on knowledge factor authentication where the user divulges a previously agreed secret. That is, typical business processes supporting authentication are primarily "shared-secret" based (e.g. PINs, mother's maiden name, SIN#, SSN#, etc.). The "shared-secret" has the disadvantage that the shared-secret can both originate as well as authenticate a transaction (i.e. existing business infrastructures need extra levels of security to prevent divulging the shared secret). Upgrading these existing authentication business infrastructures to PKI is straightforward and eliminates the vulnerability associated with divulging the authenticating value. Advantageously, VirtualSAFE includes a straightforward upgrade to existing "shared-secret" authentication processes to a "secret", "shared-secret", and "physical material" authentication process using existing business processes. By including an Attribute Certificate in a transaction, the authentication of the user is enhanced. Consider the following access control system, which is in accordance with an embodiment of the invention:
The Certification Authority CA(x) is capable of issuing public key certificates and of signing the root issuing certificate of the Authentication Authority AA(y). Resources are classed and labeled such that access to resource R(1) is distinct and non-connected with R(2), or any other resource R(n). Each group G(n) is assigned authorization to access a particular set of resources based on policy, for example, G(1) may access R(1), R(3), and R(4). In this embodiment, a method by which an authorization environment for resource access is made instantaneous, may include the following steps:
To exercise a resource access authorization, the following steps may now be followed:
Given the successful verification of these queries on U(1)'s AC, then the result will be either to deny access or to grant access on the basis of identity authentication and appropriate access authorization. Virtual Identity (VI) 105. The VI module 105 is a composite secure algorithm and protocol for creating a digital certificate based virtual identity based on the above described secret, shared-secret, and physical material process. VI 105 includes the use of X.509 Digital Certificates in the internal VirtualSAFE Certification Authority (VCA), as described above. VI 105 also includes the following:
Virtual Smart Card (VSC) 106. The Virtual Smart Card module 106 enables authentication and secure, isolated encrypt/decrypt and digital verification functionality. Remote or roaming VirtualSAFE digital certificate storage is an important part of this configuration. The VSC module 106 is an internal VirtualSAFE application that acts as a local secure proxy to an external virtual authentication token accessed via the Secure Remote Pointer (SRP) 103. The VSC 106 authenticates, encrypts and decrypts VirtualSAFE user data using a multi-tiered Public Key Infrastructure (PKI) 101 managed service. The VSC 106 implements a multi-tiered PKI by designating a dual set of key pairs for each user. As described above, the first set is an External Public-Private key pair, issued by the External Certification Authority (ECA), which resides on the client or web browser and interoperates with the SRP 103. The second set is a local VirtualSAFE Public-Private key pair issued by the VirtualSAFE Certification Authority (VCA) that resides securely and inaccessibly to the outside network within VirtualSAFE. The Virtual Smart Card (VSC) 106 is part of VirtualSAFE's secure backend Virtual Identity 105 management system. As described above, a system in which VirtualSAFE is deployed typically includes the following:
The method by which the VSC 106 is accessed by the remote client terminal and by which it executes an online interaction is as follows:
The VSC module 106 includes a multi-tiered authentication mechanism that consists of the elements described above with respect to PKI 101, that is, the ECA, VCA, and AA. The VSC 106 may be initiated through the following method:
The Virtual Smart Card (VSC) 106 process may be used in the context of a Point-of-Sale (POS) card-swipe terminal at a merchant's store or shop, as follows. Assume that the customer maintains an account with an existing financial institution. The following steps may be included in the use of the VSC 106:
The Virtual Smart Card (VSC) 106 process may also be used in the context of check processing, as follows. Assume that the customer is already enrolled in VirtualSAFE. The following steps may be included in the use of the VSC 106:
Secure Data Repository 107. The secure data repository 107 is an internal VirtualSAFE module that enables secure storage of dynamic and/or static application data, using a unique PKI based encryption scheme 101 and different crypto-engine security 109, in the same database. Existing standards and business practices allow VirtualSAFE to maintain an internal secure data repository of certificates in optimized format as long as the original certificate format can be exactly reproduced bit-for-bit. These optimizations are implementation dependent for specific operations and may contain a combination of data compression and/or field elimination. VirutalSAFE includes the following Database Repositories (DR):
The VSC/Customer and Merchant Repositories are interlinked based on the business rules and policies defined in accordance with business requirements. The VSC/Customer Repository is a composite of customers' VI 105 records. These records include all personal, financial, and credit data belonging to each customer. VSC/Merchant Repository is based on a fixed schema developed for payment and contains merchant data profiles. The VSC/Merchant Repository also contains payment transactions in various states of completion with a credit payment processor. These states may include the following:
These states may be managed, voided, cancelled, etc., and queries, such as retrieving transaction history, return various responses including transaction content which may include the following:
External financial systems are securely interfaced with VirtualSAFE in that transaction communications are digitally encrypted and signed. Payment Processing Engine 110. The payment processing engine 110 enables the processing of financial transactions with remote payment providers. The payment processing engine 110 may include a server and connectivity to a payment gateway that supports wherein the servers support VirtualSAFE's compatible client-server SSL authentication. Payment processing may include the following: credit card payment, debit card payment, direct debit, check processing, wire, and EFT. Payments in VirtualSAFE may be processed in several modes including batch processing and real-time processing. Each mode achieves the same set of possible results from a payment request, whether it is authorized, settled, or declined. Real-time processing is achieved by executing a single payment request in real-time while the customer is connected. VirtualSAFE's payment processing engine 110 may support several transactions including the following:
Draw Request Messages. In the follow, a detailed description of one method for processing a draw request message in conjunction with a virtual smart card is presented. Recall that draw request messages were introduced in the description of the VirtualSAFE sever 108 above. Once a draw request message has been received by the payment server and passed along its terminal, the terminal parses the message back into individual responses and passes these responses sequentially to the virtual smart card. In an alternative embodiment, a dumb terminal is used and the draw request is parsed into its components and otherwise processed by the payment server, which then sends the responses to the virtual smart card itself. The payment code module of the payment server edits the draw request for syntactic correctness and logs the draw request message as being received. The draw request is passed to the terminal interface of the payment server. In one embodiment, the terminal interface then requests a terminal from the payment server's terminal pool. The payment server may have a pool of terminals connected to a terminal concentrator that is established at start-up. At start-up, the payment server receives a list of all valid terminal identifiers. The payment server uses these identifiers and its knowledge of transactions in progress to determine an appropriate terminal to process the transaction. Once a terminal is determined, the terminal interface builds a terminal specific message based upon the draw request and the type of terminal. The terminal specific draw request is sent to the chosen terminal over a local area network. A concentrator may act as a router between a transaction thread in the payment server and a corresponding terminal if many terminals are attached to the payment server. The concentrator looks at a header on the draw request to determine to which terminal the transaction should be routed. In one embodiment of the invention, the concentrator is not necessary and the payment server communicates directly with the terminal. The terminal parses the draw request message into its various components and processes each component in turn to emulate a card interacting with the virtual smart card in a physical terminal. Prepackaging of a variety of data into the draw request message results in fewer exchanges over the Internet between the VirtualSAFE server 108 and the payment server. By simulating an interaction, the virtual smart card behaves as if it were in a physical terminal along with an actual smart card. A variety of responses from a smart card may be emulated. In one embodiment, the terminal sends each of the two commands "Answer to Reset" and "Initialize IE-W for Purchase" down to the virtual smart card individually and waits for a return message, "Debit IE-W," before sending the next response. For a public key transaction, the certificates read by the client are also included as individual responses. In this way, even though all of the smart card information (the draw request) originating from the VirtualSAFE server 108 has been sent at once in prepackaged form over the Internet, the interaction between the smart card and virtual smart card in a physical terminal is simulated at the terminal in a remote location. The terminal reaches a "draw amount" state, indicating that the virtual smart card is able to generate a debit command. The virtual smart card generates its virtual smart card digital signature and the command "Debit IE-W". The digital signature and debit commands are sent to the terminal. The debit command issued by the virtual smart card may contain a wide variety of information including the virtual smart card identifier, the transaction identifier, the amount to be debited, the currency and currency exponent for the amount, the virtual smart card digital signature, the date, time, and location. The terminal in turn sends the digital signature, command, and the terminal identifier to the payment server. Risk Management Engine 111. The risk management engine 111 is determines transaction validity using detailed heuristic processes. Certificate authority digital signatures are not only expensive to manage and computationally burdensome, but they place the issuer, typically a bank, in a risky position. In a Certification Authority Digital Signature (CADS) model, the compromise of a Certification Authority's (CA) private key can be catastrophic. For example, bogus certificates may be issued and fraudulent transactions initiated, all seemingly authorized by the CA. To remedy such a problem, the CA may have to re-issue certificates to every certificate holder and put every previously issued certificate on a CRL. While a breach is undetected, the CA is in a very risky position. Consequently, Certification Authorities guard their private keys with expensive physical and procedural security measures. The Account Authority Digital Signatures (AADS) model, on the other hand, carries no systemic risk. Without digital certificates, there is no technical need for a bank to have a private key. Most likely, any bank involved in PKI transactions will likely have a private key, but no certificates (or hierarchy of certificates) are inherently dependent on the security of that key in the AADS model. As attractive as AADS may sound, it will never eliminate the need for digital certificates. In cases where two parties have no prior relationship, third-party certification makes sense. For example, consider a retail customer wanting to open a new account with a bank over the Internet. The concept of a third-party certificate would aid the bank tremendously in making quick work of the electronic sign-up process. This resembles the role that credit bureaus play today. Third-party digital certificates will exist. Account authority digital signatures do not preclude the use of CADS. They rely on the same cryptographic operations to validate digital signatures. The latter simply requires additional steps in the validation process. An account authority can easily become a certification authority by applying its digital signature to a customer's public key rather than storing the public key in the account record. If an account authority wants to support trust propagation by issuing certificates, it should, but it should do so based on a conscious business decision. By requiring certificate authority digital signatures, as most existing methodologies do, banks are thrust into the position of propagating trust via digital certificates. It is no longer a business decision but a technical requirement. Banks may not want to take on the risk of trust propagation. As account authorities they don't have to, and they can still remain central to the transaction processing business. VirtualSAFE's risk management engine 111 augments the payment processing functionality by providing intermediate vetting of transactions prior to execution by a remote processor. Credit Risk Management occurs in different scenarios of customer enrolment, management, and payment processing. An individual customer's credit rating is used to determine acceptability of payment transaction processing. This value is collected either at enrolment time or during a profile update. It is retrieved by calling the local database using various information fields belonging to the customer. The risk value returned is stored in the VSDB 115. At transaction processing time, the credit value rating is retrieved from the VSDB 115 and used to evaluate whether a transaction should be transmitted to the payment processor. VirtualSAFE maintains ongoing transaction logs or a system transaction journal. That is, any transaction (e.g. payment, customer profile modification, etc) executed using VirtualSAFE is stored along with the information identifying the transaction, issuer, date, resources affected, and Registered Resource Site status. Transaction Fulfillment Mechanism (TFM) 112. The transaction fulfillment mechanism 112 is completes e-commerce transactions by means of a secure connection with fulfillment providers. The TFM 112 includes a set of fraud management heuristics that are invoked in a progression that leads to a final fulfillment condition. The fulfillment condition will dictate what type of delivery is to be made and the associated criteria for completion. The TFM 112 and fraud management heuristic is comprised of several steps including the following:
The first three of these steps are combined to achieve a transaction score that is used to determine the fulfillment response and type of fulfillment delivery. Each step is mutually exclusive with the combined result determining fulfillment completion. The above steps may be described in more detail as follows: Customer Authentication Scoring. This step is initiated by compiling the browser logon criteria into a composite score. Elements from the browser logon that may be considered include the following:
Credential Identification Scoring. This step creates a composite score based on the identifying elements in the order information. Each are weighted and summed based on various criteria which may include the following:
Transaction Scoring. This step involves computing a value and risk for the actual transaction being processed based on transaction attributes as follows:
Fulfillment Response. This is the required response to the established criteria. The transaction will be treated as a variant of "card present", where the physical credit card is actually present, or "authorization", where the credit issuer must confirm available credit.
Fulfillment Delivery. This is the resulting action taken on the composite score after all of the scoring attributes are evaluated and checked. The resulting delivery may include the following:
Insurance Module 113. Through the insurance module 113, VirutalSAFE provides liability and transaction value insurance. A transaction value insurance algorithm is an active link to the Risk Management Engine. The adjustable architecture of this module provides a full and flexible policy for cumulative, minimum, and contractual coverage related to policy and deductions. Secure Transaction Repository 114. The transaction secure repository 114 records and securely stores every single transaction that is made by the user. VirtualSAFE Deposit Box (VSDB) 115. Through VirtualSAFE's implementation of an authentication authourity server 108, multiple entities (see below) may inter-operate on an open and non-trusted network by means of AC access control. VirtualSAFE permits electronic payment, credit collection, and secure remote fulfillment processes. Through the use of the Virtual Smart Card 106, Secure Remote Pointer 103, Attribute Authority 104, and other modules, VirtualSAFE may be implemented in a variety of ways. Modularity of security objects and application objects enable VirtualSAFE to be applied to numerous electronic commerce environments. In VirtualSAFE, an electronic inter-networking payment system provides for transactions using an electronic payment VSDB 115 for keeping money, credit cards, and other forms of payment organized. Access to the instruments in the VSDB 115 is restricted by encryption and authentication to avoid unauthorized payments. A successful cryptographic authentication is required in order to obtain access to the VSDB 115. The authentication protocol obtains the information necessary for creating a network session granting authority to use an instrument, a payment holder, and a complete electronic wallet. Electronic approval results in the generation of an electronic transaction to complete the order. Operation. Referring to FIG. 30, there is shown a block diagram illustrating VirtualSAFE from a business-to-business perspective, and including an e-portal, in accordance with an embodiment of the invention. Referring to FIG. 31, there is shown a block diagram illustrating the VirtualSAFE system from a business-to-consumer perspective, and including a merchant, in accordance with an embodiment of the invention. VirtualSAFE ensures security through a combination of public key certificates and attribute certificates which are deployed for authentication and authorization purposes for each entity in the typical e-commerce transaction. The following entities are typically involved in an electronic commerce (e-commerce) transaction: Customer (or User); Merchant/ Business; Shipper; Payment Processor; Credit Issuer/Credit Acquirer/Credit Card Vendor; and Bank Account. In order to maintain a strong connection between security and business process, security objectives and business requirements are defined and merged in VirtualSAFE. The security objectives are based on fundamental principles of confidentiality, entity authentication, data integrity, and non-repudiation. In general, VirtualSAFE provides the following features and advantages to e-commerce entities:
In operation, an electronic commerce system in accordance with an embodiment of the invention includes a client terminal, a merchant server, a payment server, and a VirtualSAFE server 108. A virtual smart card inside the terminal is in communication with the payment server and other modules supported by a multi-tiered authentication authority. A method for conducting an electronic commerce transaction over the Internet using this electronic commerce system may be described as follows: Initially, a suitable web browser initiated on the client terminal is used to access a merchant server web site. The user selects goods and/or services from the merchant site and indicates to the site that the he or she wishes to purchase these items using a virtual smart card. The merchant server receives this request for a virtual card transaction. The merchant server builds an HTML page that includes several parameters. These parameters include the total cost of the transaction as determined by the merchant server, the type of currency being used, the port and IP address of the payment server, and a unique transaction identifier used by both the payment server and the merchant server to track a transaction. Also included is a unique merchant identifier assigned to the merchant by the acquirer and known to the payment server. Other information may also be included such as the currency's exponent, a status URL address of the merchant server used for communication from the client terminal, and a merchant server generated key and other security information to ensure the identity of the merchant server and the integrity of the message. Other process related information such as software release level, encryption methodology, and keys may also be conveyed. Once this page has been built, the page is sent to the requesting client browser and triggers the initiation of a client terminal module in the client terminal. Some browsers may not allow an applet to invoke a dynamic link library ("DLL") due to security reasons. As such, in one embodiment of the invention, the client terminal applet, along with any DLLs needed, are pre-initiated on the client terminal. Then, the merchant server is allowed to invoke the client terminal applet and DLLs dynamically to circumvent this security precaution. In an alternative embodiment, the client applet is signed to ensure its authenticity and integrity. The client terminal module then displays a screen containing the amount provided by the merchant and requests that the user authorize the amount by entering their user identifier (which preferably is masked on screen) and PIN. Once entered, the client terminal module routes the purchase request (including purchase parameters from the merchant server, user identifier and PIN) to the VirtualSAFE server 108. The VirtualSAFE server 108 then validates the user identifier and PIN with the user verification module. The client code module of the VirtualSAFE server 108 then interacts with the pseudo technology process module to build a draw request message for later transmission to the payment server. It should be noted that at this point two types of emulation occur. The VirtualSAFE server 108 neither includes a physical smart card nor a virtual smart card. The physical card is represented as a virtual card in a record of the card database, while the virtual smart card is attached to a remote payment server. Thus, the client code module will emulate commands that a virtual smart card would issue to build the draw request, while the pseudo technology process module, the smart card emulator and the database emulate a physical smart card. In one embodiment of the invention, the client code module initiates a local DLL, makes an API call to that library, which in turn makes a call to another DLL that finally makes a call to the pseudo technology process. An "Initiate VSDB for Purchase" command (Initiate VSDB) is created and forwarded to the emulator via the card reader module. This command is modified in a suitable fashion to identify which record in the database will be debited (i.e. which virtual card). For example, the user identifier or PIN may be included. Next, the emulator parses the incoming command and does a database fetch to obtain the virtual card record from the database. In another embodiment of the invention, the fetch may be optimized to only retrieve certain information. The emulator then sends the record to the CEV 109 for decryption of the card data found in the record. Once responses to the "Initiate IE-W" (i.e. Intersector Electronic-Wallet) command from the reader are received, the client module combines these responses into a byte stream suitable for transmission over a network to a payment server. Also at this point, the currency type and expiration date of the virtual card in the database are checked, and the total cost of the ordered merchandise is checked against the card balance to ensure that the value on the card is great enough to cover the transaction. If the checks are not successful, a message to that effect is delivered to the user and the transaction terminates. Since the virtual smart card is remotely located, it would not be advantageous to engage in numerous commands and responses between the virtual smart card and the client code module over an open network such as the Internet. In the interests of speed and reliability, it is advantageous to have fewer messages exchanged. Accordingly, the client module emulates a variety of virtual smart card commands in order to receive responses to these commands from the pseudo technology process. To operate securely and reliably in this environment, in one embodiment of the present invention, the client module emulates a virtual smart card and gathers all the responses for transmission in one draw request message. The commands and responses take place between the client code module and the pseudo technology process as if there were an actual card reader with a physical smart card inside. In other words, the client code module need not be aware that a virtual card is being used. The draw request message may include a variety of data including a draw request token, state information, the merchant identifier, the transaction identifier, security information, a wallet provider identifier, and an intersector electronic wallet ("IE-W") identifier. Also the message may include an algorithm used by the card, an expiry date, the balance of the card, a currency code, a currency exponent, the authentication mode of the IE-W, the transaction number of the IE-W, a key version, and the purchase amount. As all of this information is prepackaged into a single draw request message, the number of messages over the Internet between the VirtualSAFE server 108 and the payment server is greatly reduced. In one embodiment, the draw request message is built by packaging the virtual card's response to the "Reset" and "Initiate IE-W for Purchase" commands, any public key certificates, the total cost, and the currency of the transaction received from the HTML page. For public key cards, the card and the issuer certificates are obtained from read commands and may also be included in the draw request. By packaging all of this information together into one draw request message, it is possible to cut down on the number of messages exchanged between the VirtualSAFE server 108 and the payment server and hence reliability and speed are improved. Next, the VirtualSAFE server 108 accesses the payment server using the IP address received from the merchant server. The VirtualSAFE server 108 sends the draw request message to the payment server. The VirtualSAFE server 108 also creates a log of the message being sent. The payment server sends to the client terminal the draw request and processes the draw request in conjunction with an associated virtual smart card. In one embodiment of the invention, the payment server creates a transaction thread for each connected client module to service it through the life cycle of the transaction. The payment server receives a debit command and a virtual smart card digital signature from the virtual smart card. The virtual smart card digital signature is a value that uniquely identifies and validates the virtual smart card to prove to the VirtualSAFE server 108 that the incoming debit command is a valid command from a real virtual smart card. This validation ensures that when the virtual card is debited the financial totals in the virtual smart card are updated. Thus, the user of the virtual card is guaranteed that a valid debit of the card has occurred. In one embodiment of the invention, the virtual smart card digital signature is an encrypted value ensuring that no other entity can forge an identity of a virtual smart card. The payment server sends the debit command along with the virtual smart card digital signature to the VirtualSAFE server 108 to allow the virtual card to accept the debit. At this time, the payment server also logs the debit command into its database. Upon receiving the debit command from the payment server, the client module replaces the amount in the debit command with the original amount (from the merchant server) to ensure that the amount has not been tampered with while traveling over the network. At this time, the client module may also create a log of the debit command. The client module forwards the debit command and virtual smart card digital signature to the emulator and it again retrieves the appropriate virtual card record from the database for processing. The card record is retained in memory while a transaction is occurring. The card record, debit command, and digital signature are sent to the CEV 109 where the virtual smart card digital signature is verified and a virtual card digital signature is generated. The card record is updated in the CEV 109 with revised parameters (including balance and transaction ID) to reflect the purchase transaction and returned to the card database. The client module receives the CEV 109 response and generates a "Debit Response" message along with the card digital signature. If the virtual card does not have enough value to satisfy the purchase amount, then a "Debit Response" message indicates as such. The card digital signature is a unique value identifying a valid virtual card in the card database. In one embodiment of the invention, the digital signature is in encrypted form to prevent tampering. The emulator sends the response message along with the card digital signature back to the client module. At this point, the purchase amount has been deducted from the balance on the virtual card (assuming a successful transaction). Next, the client module packages the response message along with the card digital signature and sends them back to the payment server. The client module also logs the result of this virtual card debit. The payment server receives the incoming message and creates a log and updates the transaction status in its database for future error recovery. The payment server then directs this received message to the virtual smart card in the terminal. Next, the virtual smart card processes this response fro | ||||||