Portable electronic charge and authorization devices and methods therefor

PORTABLE ELECTRONIC CHARGE AND AUTHORIZATION DEVICES AND METHODS THEREFOR

The present invention relates to a method and apparatus for executing an electronic transaction. More particularly, the present invention relates to portable electronic authentication devices (PEADs) that advantageously and substantially eliminate the security risks associated with the prior art of authorizing transactions between a user and an electronic transaction system.

Electronic transaction systems are known. Electronic transaction systems typically allow users to electronically execute designated transactions, substantially improving efficiency and convenience for users. Examples of electronic transactions include transactions executed by computer networks, automated teller machines (ATMs), automatic point-of-sale systems, automated library systems, and the like. Transactions executed by a computer network may include a wide range of transactions including exchanging information and data by well-known computer networks such as the Internet to purchase goods from vendors on the network. ATMs typically allow users to perform financial transactions (withdrawals, transfers, deposits, etc.) against financial institutions electronically. Automated point-of-sale systems may be employed by merchants, allowing users to purchase goods or services using a user's electronic account, and automated library systems to allow library users to borrow and return library materials. can be used Other examples of electronic transaction systems are readily available in general literature, and thus have not been enumerated in this specification for clarity of explanation.

To enhance the security of a user's account, electronic transaction systems typically require the user to provide authentication data authenticating that they are an authenticated user in order to approve a requested transaction or transactions. If the user cannot provide the requested recognition data, the requested transaction or transactions will not be authenticated and will not be processed. Authentication data may be required at each transaction. For example, an automated point-of-sale system will require a user to approve a purchase transaction, and will receive an approval message only if it is satisfactory that the person authorizing the transaction provides appropriate identification data to authenticate himself for approval. Optionally, identification data may be entered by the user at the start of a session to authenticate himself, allowing the user to subsequently perform several transactions without further authentication.

In the prior art, users typically need to manually enter identification data into an electronic transaction system for authentication. Typically, entering identification data involves typing a password on a numeric keypad or keyboard. The identification data is then compared with data previously stored in the electronic transaction system, and authentication is satisfied when the identification data matches. As mentioned above, the requested transaction or transactions will not be processed unless the identification data match.

Conventional electronic transaction systems protect user accounts from unauthorized access and use, but there are drawbacks. To illustrate certain disadvantages associated with conventional electronic transaction systems, reference will be made to FIG. 1 . 1 shows an automated teller machine (ATM) 100 representing a requesting device of an electronic transaction system 102 . Electronic transaction system 102 may include, for example, a central database 104 containing previously stored identification data and account data of user 106 .

To initiate a typical transaction with ATM 100 , user 106 first inserts data card 107 , such as a bank card or credit card, into card reader 109 . Data card 107 typically includes a magnetic stripe containing an account number and other information related to the user, which will then be read by card reader 109 . The data stored on the data card 107 may enable the electronic transaction system 102 to ascertain which account in the database 104 the user 106 wishes to conduct a business transaction with.

With the keypad 108 of the ATM 100, the user 106 will then enter identification data, such as, for example, his or her personal identification number (PIN) to authenticate himself. If the entered identification data matches the stored identification data and the account in the database 104 identified by the data card 107, the user is authenticated and can access the account. If there is no match, authentication fails. After authentication, user 106 may use a combination of keypad 108 and screen 110 to withdraw cash from the account, for example, resulting in cash being withdrawn from ATM 100 and database 104 . The balance of one's own account within is thus reduced.

Theoretically, the identification data input to the ATM 100 should be secure. Indeed, there are several potential security risks for identification data in prior authentication techniques. Since the identification data is not encrypted before being entered into the ATM 100, the unencrypted identification data has a high risk of easily unauthorized access and acquisition. Encryption of authentication data is not practical in the prior art because it is too complicated or inconvenient for a user to perform encryption or memorize encrypted identification data. The unauthorized acquisition of prior art identification data may, for example, inadvertently observe a third party behind user 106, i.e., another person, typing on screen 110 or similar keypad 108. It can also be done through input from another person.

Although encryption has been used in the prior art, for example, on identification data prior to being transmitted from ATM 100 to database 104, encryption will typically occur within ATM 100 and will still still provide unencrypted identification of user 106. It will require the entry of data and the presence of the identification data for some time in ATM 100. Unauthorized access to the identification data would occur if an unauthorized person could obtain input into the ATM 100 and intercept the unencrypted identification data by software or hardware executing in the ATM 100 .

In addition, if public key cryptography is used in ATM 100, the storage of the user's private key in the ATM 100 makes the private key susceptible to theft, and also exposes the user's account to risk. The stolen password and/or private key can then be used by an unauthorized individual to gain access to the user's account and compromise the user.

In view of the preceding description, there is a need for a preferred apparatus and method for conducting transactions with an electronic transaction system while substantially eliminating the risk of unauthorized acquisition of a user's authentication data and unauthorized access to a user's account. Preferably, the device should be easily carried so that the user can conveniently and comfortably perform transaction authentication at any location.

The present invention relates in one embodiment to a portable transaction device that enables a user to perform a credit card transaction against a credit card terminal of an electronic transaction system. The credit card terminal is configured to communicate with the credit card to conduct a credit card transaction. A credit card is one of a magnetic stripe card and an electronic smart card. The portable transaction device includes an emulation card having an emulation card interface. The emulation card interface emulates the interface of a credit card. The interface of the credit card facilitates communication between the credit card and the credit card terminal. Also included is a portable emulation card configuration device arranged for use with the emulation card, comprising a memory configured to store first credit card data relating to a first credit card of a user and an authentication mechanism. The portable emulation card configuration device is configured to write the first credit card data from the memory to the emulation card if the user has been authenticated by the authentication mechanism, so the emulation card is written to the credit card terminal as well as the first credit card to perform the transaction after the recording. It can appear through the emulation card interface for the user, and enables the credit card terminal to read the first credit card data from the emulation card to perform a credit card transaction.

In another embodiment, the present invention relates to a method for allowing a user to perform a credit card transaction with a credit card terminal of an electronic transaction system. The credit card terminal is configured to interface with the credit card to perform a credit card transaction. A credit card is one of a magnetic stripe card and an electronic smart card. The method includes providing an emulation card having an emulation card interface. The emulation card interface emulates the interface of a credit card. The interface of the credit card facilitates communication between the credit card and the credit card terminal. It also includes providing a portable emulation card configuration device arranged for use with an emulation card, comprising a memory and an authentication mechanism configured to store first credit card data relating to a first credit card of a user. The portable emulation card configuration device is configured to write the first credit card data from the memory to the emulation card if the user has been authenticated by the authentication mechanism, so the emulation card is written to the credit card terminal as well as the first credit card to perform the transaction after the recording. It can appear through the emulation card interface for the user, and enables the credit card terminal to read the first credit card data from the emulation card to perform a credit card transaction.

In another embodiment, the present invention relates to a method for enabling a user to authorize an Internet transaction request to a user computer terminal connected to the Internet. The Internet transaction request is generated by a first computer connected to the Internet. The method includes transmitting first digital data from a first computer to a user computer terminal, the first digital data representing an Internet transaction request. The method also includes receiving at a second computer coupled to the Internet second digital data. The second digital data is manually input by the user through the user computer terminal. The second digital data is an Internet transaction encrypted using the user's private key by one of PEAD and PECAD from information entered by the user into one of the portable electronic authentication device (PEAD) and the portable electronic billing and authentication device (PECAD). Represents user-readable cryptographic transaction authorization, meaning user authorization of the request. The method further includes decrypting the second digital data using the user's public key after being received.

In another embodiment, the present invention relates to a computer performing a method for user registration of a particular electronic encryption device configured to encrypt data according to a public key cryptography scheme. The method includes providing a list of public keys and identifying information relating to a plurality of electronic cryptographic devices in a computer database, each list of public keys associated with each of the plurality of electronic cryptographic devices. The method further includes receiving device identification data from the user. This device identification data identifies a particular electronic encryption device. It also includes receiving encrypted user identification data to verify the identity of the user. Additionally, it may include associating device identification data with a specific electronic cryptographic device in the database, thus identifying a specific public key associated with the specific electronic cryptographic device from the database . In addition, it involves decrypting the encrypted user identification data using a particular public key and associating the user with a particular electronic encryption device in a database if the decryption is successful.

Several advantages of the present invention are explained in detail below with reference to the drawings.

1 shows a prior art electronic transaction system including an automated teller machine (ATM).

Figure 2 illustrates a portable electronic authentication device (PEAD) representing a device for securely authorizing a transaction that has been performed facing an electronic transaction system in accordance with an embodiment of the present invention.

3A shows a simplified diagram of the PEAD of FIG. 2 in accordance with one embodiment of the present invention.

3B illustrates a representative transaction authorization data format in one embodiment.

4 shows a logic block diagram of a PEAD according to an embodiment of the present invention.

5A illustrates a high-level hardware implementation of a PEAD in accordance with one embodiment of the present invention.

5B shows an embodiment of PEAD in which the PEAD circuit is implemented in an IC.

Figure 5C shows the outside of the PEAD of Figure 5B after being embedded in a card-like package.

6A shows the outside of a PEAD according to one embodiment of the present invention.

6B illustrates hardware for the execution of the PEAD of FIG. 6A in a simplified manner in accordance with an aspect of the present invention.

7 is a flow diagram illustrating an authorization technique using PEAD in accordance with an aspect of the present invention.

8 is a flow diagram illustrating the steps involved in encrypting a transaction authorization using a public key decryption technique in accordance with an aspect of the present invention.

9 shows a simplified block diagram of a portable electronic billing and authentication device (PECAD) in accordance with an aspect of the present invention.

10 is a simplified diagram of a PECAD including an emulation card arranged in accordance with an aspect of the present invention.

11 is a simplified flowchart illustrating a method in which a transaction number is performed in association with PECAD to perform transaction security according to an aspect of the present invention.

Figure 2 illustrates a portable electronic authentication device (PEAD) 200 representing a device for securely authorizing a transaction that has been performed facing an electronic transaction system in accordance with an embodiment of the present invention. Referring to FIG. 2 , the requesting device 202 may initiate a transaction approval process together with the PEAD 200 by sending a transaction request regarding the requested transaction to the PEAD 200 through the communication port 204 . The requesting device 202 may represent, for example, an ATM device, a computer terminal on a network, an automated library loan terminal, or similar device through which the user may transact business with an electronic transaction system. The requested transaction may be, for example, a sale transaction of a specific item for a certain amount of money. The transaction request itself may include, for example, the transaction ID, the merchant's name, the merchant's ID, the time of purchase requested, and the like. In one embodiment, the transaction request from the requesting device 202 may be encrypted with enhanced security, but this is not required. Data pertaining to the subscribed transaction arrives at PEAD 200 via path 206 in FIG. 2 .

Port 204 may be an infrared port to facilitate infrared communication with PEAD 200 . Optionally, port 204 may be a wireless port to facilitate wireless communication. Port 204 may even be a contact type connection, such as a plug or magnetic read/write mechanism, with electrical contacts for directly plugging PEAD 200 into port 204 to facilitate communication. Other techniques for facilitating communication between the requesting device 202 and the PEAD 200 are readily understood by those skilled in the art.

Data pertaining to the applied transaction(s) may then be reviewed by the user on either the screen 208 of the requesting device 202 or, optionally, a display screen (not shown in FIG. 2 ) provided with the PEAD 200 . have. If the user approves a transaction, such as purchasing an item for a certain amount of money, the user will then indicate his/her approval by activating the switch 210 of the PEAD 200, which indicates that an approval message will be sent to identify the user. The data is generated together and transmitted encrypted back to the requesting device 202 via path 212 . If the transaction is not approved, the user simply does nothing and after a certain amount of time has elapsed the transaction will either request a timeout or activate another switch in PEAD 200 (not shown in Figure 1), which may be encrypted or non-encrypted. Causes an encrypted reject message to be sent back to the requesting device 202 via path 212 .

The present invention differs from the prior art of FIG. 1 in that it is necessary in the prior art for a user to input his/her authentication data into an electronic transaction system such as, for example, ATM 100 in order to authenticate himself/herself. Conversely, the present invention keeps the identification data associated with the user within the PEAD 200 secure at all times. Transaction authorization takes place within PEAD 200, and the data representing the authorization is re-encrypted within PEAD 200 before being transmitted to an electronic transaction system such as, for example, requesting device 202 of FIG.

Thus, even if the authorization data is intercepted, its encryption can prevent unauthorized users from using it illegally. If public key encryption is used to encrypt the authorization data, the user's private key is always held in PEAD 200 . Because the user's private key is needed for encryption and is not known to others, even to the electronic transaction system in one embodiment, the encrypted authorization data, if intercepted, cannot be decrypted using the user's public key. Even if it could, it would be useless to an unauthorized third party. Also, this differs from prior art authentication techniques, where encryption occurs in electronic transaction systems, requiring input of identification data, and/or reading a user's private key from an ID card such as an ATM card, credit card, etc. . As mentioned above, the fact that prior art electronic transaction systems require such identification data and/or the user's private key is a fact that, for example, if the requesting device is not secure or is open to data interception by software or hardware. puts the data at risk.

Another difference is that the present invention utilizes circuitry within the portable electronic authentication device (PEAD) to perform authentication and encryption of transaction authorization data within the PEAD itself. In contrast, prior art data cards are essentially passive devices. For example, a prior art ATM card or credit card only has a magnetic stripe for storing account information, and does not have any device for performing authorization and/or encryption of transaction authorization data. While smart cards or IC cards currently under development may have electronic circuitry, current standards for their implementation still require the requesting device to read the user's private key and/or identification data to perform any authorization and/or encryption. It requires a reader associated with the requesting device to do so. As noted above, transmitting such data to the requesting device unnecessarily exposes such data to risks such as theft and/or unauthorized interception when transmitted.

Although public key cryptography is described in detail herein to highlight and facilitate understanding certain aspects of the invention, the entire invention is not limited to any particular encryption algorithm, and also includes public key cryptographic algorithms such as RSA, Diffie-Hellman, and other It may be performed using any conventional encryption technique, including such as discrete log systems, elliptic curve systems, and the like. For additional information on some of the different public key decryption techniques, see, for example, the public key dated October 5, 1998, available from IEEE Standard Dept.345 East 7th Street, New York, New York 10017-2349. You can refer to the IEEE P1363/D8 standard specification for decryption.

As mentioned above, prior art transaction authorization takes place within an electronic transaction system. Conversely, the present invention allows transaction authorization to occur within PEAD 200 . The fact that transaction approval takes place entirely within PEAD 200 provides several advantages. For example, this feature eliminates the need for a user's private key and/or identification data at the requesting device in one embodiment. The fact that transaction approval takes place entirely in the PEAD 200 (using user identification data and/or the user's dedicated encryption key that is always kept secure in the PEAD 200) is actually the user's private key in addition to the completeness of the transaction approval process. and improve the confidentiality of user identification data.

As authorization occurs entirely in PEAD 200, the user identification data used to authenticate the transaction can become more complex and sophisticated to ensure greater security. For example, user identification data may be more sophisticated than a simple password and may include unique identification data such as the user's name, date of birth, social security number or fingerprint, DNA coding sequence, voice print, or other unique biological measurements. Conversely, prior art authentication techniques restrict user identification data to simple patterns, such as simple passwords of few characters that are easily remembered by the user because more sophisticated identification data may be too difficult to remember or cumbersome to enter manually. do. Moreover, although complex ID data may be stored on prior art data cards, they still have to be read at the requesting device of the electronic transaction system, and this data is also exposed from interception or theft upon reading.

Additional safeguards, which will be described in detail below, may also be provided to prevent access to the user's private keys and/or user authentication data in PEAD 200, either electrically or by physical means. Because the identification data and/or the user's private key is never exposed, the security risk to such data is substantially minimized.

3A shows a simplified schematic of the PEAD 200 of FIG. 2 including a switch 210 in one embodiment of the present invention. A data path 206 is provided for receiving a transaction request from an electronic transaction system, and a data path 212 is provided for sending transaction approval data back to the electronic transaction system. Although two data paths have been described for ease of understanding, the data paths and other data paths may represent logical data paths in one embodiment, and may be performed over a single physical data connection. Similarly, different ports may represent logical data ports for ease of understanding in one embodiment, and may actually be implemented using a single physical port.

When a transaction request, such as a transaction to withdraw $200.00 from an ATM device, is sent to PEAD 200 via data path 206 , the transaction is received by cryptographic logic 300 . At this point, the user may review the submitted transaction, for example through the electronic transaction system and/or the display screen provided on the PEAD 200, and select to approve or disapprove the requested transaction. If the user approves the transaction, in one embodiment that user may activate switch 210 , whereby the transaction approval data is generated and then sent back to the electronic transaction system via path 212 via cryptographic logic ( 300) is encrypted.

The user identification data block 302 used in the transaction approval process is not directly coupled to the paths 206 and 212 . That is, the memory unit for storing the user identification data is intentionally separated from the input/output port of the PEAD 200 in order to prevent direct access thereto.

If access to the user identification data 302 is needed, for example, to authorize a transaction, this access is only possible by the cryptographic logic block 300 . Similarly, it is impossible to directly access the memory unit 304 storing the user's private key. If access to the user private key 304 is needed, for example to encrypt the transaction authorization data, this access will be possible only by the encryption logic block 300 . Although the user identification 302 and the user-only key 304 are shown to be stored in different memory units, this illustration is made for ease of understanding, both of which are actually different in one embodiment in the same memory module. address can be stored.

In some cases, the transaction authorization data is required to include a specific portion of the identification data 302 . For example, a transaction implemented upon a transaction request from an electronic transaction system may be encrypted and appended with data representing an "electronic signature" before being sent back to the electronic transaction system. 3B illustrates the format of exemplary transaction authorization data 350 in one embodiment. Referring to FIG. 3B , transaction data 352 represents an entire transaction request or a portion thereof received from an electronic transaction system, appended with specific user identification data 354 and optionally a time stamp 356 . The form of transaction approval data 350 occurs only when a transaction request has already been approved by the user. Once added, the transaction authorization data 350 may then be encrypted before being transmitted back to the electronic transaction system.

In some cases, it may be desirable to encrypt a transaction request before sending it to PEAD to further enhance security. For example, certain transaction partners, such as merchants or other users of a computer network, may want to keep information confidential at the time of a transaction request, and may want to encrypt the transaction request before feeding it to PEAD. Data encryption is also desirable, for example, when user identification data and the user's private key are initially written to the blank PEAD to constitute a unique PEAD for a given user. The user identification data and configuration data relating to the user's private key are preferably encrypted to lessen exposure to theft, although they must be written to PEAD 200 once by the issuer of PEAD 200 . The issuer of PEAD 200 may represent, for example, a credit card issuer, government, or any other entity with which the user maintains an account.

4 shows a schematic diagram of the PEAD 200 of FIG. 2 in accordance with one embodiment of the present invention. The PEAD 200 of FIG. 4 may also use decryption logic to receive encrypted configuration data and optionally encrypted transaction requests. 4, cryptographic logic 300, user's private key 304, and data paths 206 and 212 are deployed and function substantially as described in connection with FIG. 3A.

Transaction requests are generally unencrypted, i.e. received and processed in the manner described in Figure 3A. However, for very sensitive transactions, the transaction request may be encrypted and sent to PEAD 200 via data path 206 and entered into decryption logic 402 for decryption. If public key decryption is used, the encrypted transaction request may be decrypted with the transaction partner public key 404 .

Once decrypted, the transaction request is then displayed to the user for approval. The transaction authorization data may be supplied to the encryption logic 300 via path 406 for encryption, for example if accepted in response to activation of the switch 210 . Encryption will preferably be performed with the user's private key 304 if public key decryption techniques are used, and the encrypted transaction acknowledgment data is then sent back to the electronic transaction system via data path 212 .

Configuration data typically includes sensitive user identification data and the user's private key, which is often encrypted prior to transmission to PEAD 200 via data path 408 . The encrypted configuration data is received by the decryption logic 402 and decrypted before being written to the user identification data block 410 and the user's private key block 304 . If public key decryption is used, the encrypted configuration data may be encrypted with the issuer's private key in the electronic transaction system prior to transmission, and decrypted when received by the PEAD 200 along with the issuer's public key 412 . do.

Once the configuration data has been decrypted and written to the user identification data block 410 and the user's private key block 304, the user identification data and the user's private key can only be subsequently accessed by the encryption logic 300. Let's note that Also note that there is no direct connection to the user identification data block 410 other than the user's private key block 304 from any I/O data path such as, for example, data path 206,212 or 408. Advantageously, the sensitive user identification data and the user's private key are sensitive to external access once written to the respective blocks 410 and 304 (which in one embodiment may simply represent a memory block of the PEAD 200's memory). don't

In addition, the user identification data and the user's private key cannot be updated by those who do not have the issuer's private key. As shown in Figure 4, after the data is decrypted by the decryption logic 402 together with the issuer public key 412, it is only possible to write to the user's private key block 304 and the user identification block 410 do. Thus, if the updated configuration data is not encrypted using the user's private key (which is assumed to be highly secure), the updated configuration data will not be decrypted and will not be written to the respective blocks 304 and 410 . Of course, if the configuration data in blocks 304 and 410 cannot be physically updated, then memory that can be written once, e.g., PROM (Programmable Read Only Memory), WORM (Write Once, Read Multiple), etc. If stored using, the security issues associated with unauthorized alteration of configuration data can be substantially eliminated.

If a higher level of security is required, the user's private key may be selectively scrambled or randomized before being written to the user's private key block 304 by the optional scrambler/descrambler logic 413 . The scrambler/descrambler logic 413 may receive, in one embodiment, a user's private key, which is supplied by an institution that issues the PEAD 200 to the user, and another user's private key and the corresponding user's public key. It will scramble and/or randomize it to generate a key. This scrambled/randomized user's private key is then stored in the user's private key block 304, which is currently unknown even to the issuer of the PEAD 200, and that user's public key facilitates the transaction. issuers and/or transaction partners may be notified. Advantageously, there is no scrambled/randomized copy of the user's private key anywhere except the user's private key block 304 .

In an alternative embodiment, optional key generation that generates the user's private key and the user's public key in response to a request from the issuing authority, without the need to randomize the user's private key by itself, ie, by first receiving the user's private key from the issuing authority. Logic 414 may be used. The generated user's private key is then stored in the private key block 304, and the public key is known to the issuer and/or transaction partner to facilitate the transaction. In this way, no version of the user-specific key exists outside of PEAD, whether randomized or not. As will be appreciated by those skilled in the art, using key generation logic 414 further increases the confidentiality of the user's private key.

5A illustrates a high-level hardware implementation of PEAD 200 in accordance with one embodiment of the present invention. As shown in FIG. 5A, PEAD 200 includes logic circuitry 502, which may be implemented by a microprocessor or microprocessor to implement encryption logic 300 of FIG. It may represent a central processing unit such as a microcontroller, discrete logic, programmable logic, or application specific integrated circuit (ASIC).

The program/data memory 504 specifically stores the code for operating the PEAD 200 in addition to the user identification data and the user's private key. Program/data memory 504 preferably uses some form of non-volatile memory (NVM), such as flash memory, electrically programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), or the like. is implemented by Temporary memory 506 serves as a scratch pad for computational purposes and temporary storage of data, and may be implemented using some form of random access memory (RAM), such as static RAM or dynamic RAM, known in the art. . Optionally, one of optical memory, magnetic memory, or other type of memory may be used to implement program/data memory 504 and/or temporary memory 506 .

Bus 508 couples program/data memory 504 and temporary memory 506 with logic circuitry 502 . Communication port 510 represents a communication gateway between PEAD 200 and an electronic transaction system, using infrared technology, wireless RF technology, magnetic read/write heads, contact plugs that facilitate serial or parallel data transfer, etc. can be implemented. The communications port may also represent a PC Card port (popularly known to those skilled in the art as a PCMCIA card) in one embodiment. Data path 206 inputs a transaction request to logic circuitry 502 , while data path 212 outputs transaction authorization data from logic circuitry 502 to an electronic transaction system. An optional data path 408 shown in FIG. 4 is a PEAD ( 200), enter the configuration data.

Note also that access to program/data memory 504 and the data therein (eg, user identification data and a user's private key) is only possible by logic circuitry 502 . For example, the user identification data and the user's private key may be written to the program/data memory 504 if such data has been encrypted with the issuer's private key. Access to these memory blocks for writing may also be restricted by logic circuitry 502 under appropriate software and/or firmware control.

Similarly, reading the user identification data and accessing the user's private key may be accomplished only through the encryption logic of the logic circuitry 502 . The security benefits of this aspect have been described with reference to Figures 3A and 4, and most importantly, there is no direct access to the user's private key and sensitive user identification data from the outside. Consequently, the confidentiality and security of the data items are greatly enhanced by the design of the present invention.

Any type of power source, such as a battery, may also be provided. If PEAD 200 is implemented in a single chip design, i.e., almost all of the devices shown in Figure 5A are fabricated on a single die, the power is external to the die. If contact communication is used, for example if the PEAD 200 has to be plugged into an electronic transaction system in order to perform a transaction, then the entire PEAD's external power will be used for transaction authorization when plugged in, and thus to the portable transaction device. Having an onboard battery would eliminate the associated size, weight and cost penalty.

In one embodiment, the PEAD 200 may be implemented using a general-purpose portable computing device such as a personal digital assistant (PDA) or a miniaturized portable computer. For example, a PDA such as Apple Newton® may be used to implement PEAD 200 .

Figure 5B shows one embodiment of PEAD in which the circuit is implemented on an IC. In Fig. 5B, components having similar reference numerals as those in Fig. 5A have similar functions. Data paths 408, 206, and 212 have been described with respect to FIG. 5A and are coupled to serial I/O circuitry 520, which transmits data in a serial manner in data path 522 between PEAD 200 and the electronic transaction system and facilitate reception. The Vcc pin 524 and ground pin 526 that power PEAD 200 of FIG. 5B are shown.

5C shows the appearance of the PEAD of FIG. 5B after being housed in a card-like package to facilitate transport and insertion into a serial I/O port of an electronic transaction system. Card 550 contains an integrated circuit implementing the present PEAD, and in one embodiment includes four external contacts. External serial contacts 552 and 554 are grounded to carry data and facilitate serial communication with serial devices in electronic transaction systems. An external Vcc contact 524 and an external ground contact 526 are shown and provide power to the PEAD as described in connection with FIG. 5A. When card 550 is inserted into the electronic transaction system, it is powered on via external contacts 524,526, so that the PEAD circuitry can receive transaction requests via external serial contacts 552,554 and, if appropriate, requests in PEAD. , encrypts the transaction acknowledgment data in the PEAD circuit, and serially transmits the encrypted transaction acknowledgment data to the electronic transaction system through external serial contacts 552 and 554.

6A shows the appearance of a PEAD according to a preferred embodiment of the present invention. The PEAD 200 of FIG. 6A is preferably implemented as a small, stand-alone package that is sufficiently ruggedized for routine use in the art. Preferably, the PEAD 200 of FIG. 6A is small enough to be comfortably carried by a user at any time, eg, as a small package or keychain attachment that can easily fit inside a wallet. The physical appearance of the PEAD 200 is preferably arranged such that its contents cannot be negatively tampered with (ie, if opened in an unauthorized manner, the user's private key and/or user identification data is destroyed or the PEAD is no longer tampered with). will not approve the transaction). For example, the façade will be arranged such that, if open, there is a change in the current flow in the current path, for example an existing current flow is stopped or an idle current path begins to flow. A change in current flow will then force the RE.

An infrared communication port 602 for receiving and transmitting data to and from the electronic transaction system is shown. A small on/off switch 604 allows the user to turn the PEAD off to conserve power when not in use. Approve button 606 allows the user to indicate approval of the requested transaction. An optional skip button 608 allows the user to indicate rejection of a particular transaction. Skip button 608 may be omitted in some implementations because the transaction request is understood as not granted if the grant button 606 is not activated for a given amount of time after receiving the request.

Optional display 610 may be implemented using any type of display technology, such as liquid crystal technology. Display 610 specifically displays transactions that have been submitted for approval. Display 610 may be omitted if desired, in which case the transaction may be shown on a display associated with the electronic transaction system. Optional user authentication mechanism 612 prevents PEAD 200 from being used to authorize transactions if the user cannot identify himself to PEAD 200 as a legitimate and authenticated user. Optional user authentication mechanism 612 may prompt the PEAD 200 to enter a password to provide a fingerprint or voice print or other biometric measurement and/or specific identifying characters to an authenticated user before the PEAD 200 is activated and used to authenticate a transaction. You can ask the user.

Figure 6B shows hardware for implementing the PEAD 200 of Figure 6A in accordance with a simple manner of one embodiment of the present invention. Battery 652 provides power to the circuitry of PEAD 200 . The microcontroller 654 executes the codes stored in the flash memory 656 and uses the random access memory 658 for execution. In one embodiment, microcontroller 654, flash memory 656, and even random access memory 658 may be implemented on a single chip, for example an NC68HC05SCXX family of chips such as the NC68HC05SC28 from Motorola Inc. of Schaumburg, Illinois. have. An accept button 606 and an optional skip button 608 are coupled to the microcontroller 654 to allow the user to indicate approval and rejection of a particular transaction displayed using the display circuit 660 . Communication to and from the electronic transaction system is accomplished under the control of a microcontroller 654 via an infrared transceiver 662 . Power switch 664 allows the user to turn PEAD 200 off when not in use to conserve power and prevent erroneous acknowledgments.

7 is a flow diagram illustrating an authorization technique for implementing the present PEAD in accordance with an aspect of the present invention. In step 702, a transaction request is received at the PEAD from a requesting device associated with the electronic transaction system. In step 704, the user has the option as to whether the requested transaction will be approved or rejected. By activating PEAD's skip button or simply timing out this request, nothing happens if it's not granted.

On the other hand, if the user approves the requested transaction, the user may activate the approve button to generate transaction approval data. The transaction authorization data is then encrypted within the PEAD at step 708 . In step 710, the encrypted transaction approval data is encrypted and then transmitted to the requesting device of the electronic transaction system.

8 is a flowchart illustrating the steps involved in encrypting transaction authorization data using public key cryptography in accordance with an aspect of the present invention. In step 802, a transaction authorization data package is created. As described above with respect to FIG. 3B, the transaction authorization data may be generated by appending any necessary user identification data to a portion of the overall transaction request. Optionally, a time stamp may also be added. In step 804, the transaction authorization data may be encrypted using the user's private key, which is preferably kept secure in PEAD. Thereafter, the encrypted transaction authorization data is transmitted back to the electronic transaction system.

According to one aspect of the present invention, even if encrypted transaction authorization data is intercepted and decrypted by a third party, the security feature of the present invention cannot be circumvented as long as the user's private key or user identification data is securely present. find out As mentioned above, since user identification data cannot be accessed from outside, it is always safe within PEAD. This differs from the prior art in that the user needs to enter identification data, for example a password, in an electronic transaction system and there is a risk of exposing such sensitive data.

Even if the user identification data is compromised, transaction approval still cannot occur unless the user's private key is in possession. Even if decryption using the user's public key, the transaction partner, e.g., the seller's request approval of the transaction, does not receive any transaction approval data that is not encrypted using the user's private key. Intercepting authorization data is pointless. Also, since the private key cannot be accessed from outside, it is always safe in PEAD. This aspect of the invention is useful for conducting online transactions because the user's private key is no longer stored in a vulnerable computer file on the workstation that can be accessed by others and is difficult to carry conveniently for other authentication tasks. has a great advantage.

The fact that PEAD is performed in a small, portable package makes it convenient and comfortable for users to keep PEAD in their possession. Even if the PEAD has been physically stolen, an optional user authentication mechanism, eg, the user authentication mechanism 612 of Figure 6A, provides an additional level of protection and renders the PEAD virtually useless to authenticated users. Of course, the user can always report to the PEAD's issuer if the PEAD is stolen or lost, and the issuer can inform the transaction partner to reject any transaction authorization data encrypted with the stolen PEAD's user's private key.

The fact that the transaction approval data includes a time stamp, seller's name, authorized amount and other relevant data enhances the completeness of the transaction approval process. If the merchant inadvertently or intentionally issues multiple transaction authorizations to the issuer, the issuer may be aware that the issuance is duplicated from these data items and ignores any duplicate transaction authorization data. For example, a publisher may recognize that a user will not order multiple identical meals from the same restaurant at a given time and date.

PEAD and PEAD-enabled point of sale terminals provide a very secure system for authorizing transactions, but they are widely used, including millions of existing credit card and point of sale terminals (eg, credit card readers or ATM terminals). It is recognized by the present invention that credit card architectures exist that can be made and widely used. It is also recognized that certain PEAD functionality can provide improved transaction security for existing credit card architectures, even in the absence of PEAD-enabled point-of-sale terminals.

According to another aspect of the present invention, it is not possible only to provide the above-described PEAD function in order for a user to approve a transaction for a PEAD-enabled point-of-sale terminal but also to perform a transaction for an existing credit card infrastructure. A billing/authorization device (PECAD) is provided. In particular, a complete PECAD system includes a PECAD and a corresponding emulation card that complies with current credit card standards as far as interfaces with existing card readers are concerned. The emulation card can be flexibly configured by PECAD to appear as a plain credit card to current credit card readers. Additionally, PECAD and emulation cards form a secure system for performing transactions against existing credit card infrastructure.

Credit cards include both magnetic stripe cards and electronic smart cards because the condition is used in connection with the above embodiment. Credit Card refers to any other type of card, other than a credit card (Visa or Mastercard), ATM card, loyalty card, discount card, that a user may use against a point of sale terminal to obtain cash, goods, and/or services. can

Prior to performing the transaction, PECAD has in its memory credit card data relating to the user's one or more credit cards. To perform PEAD functions, the memory may also contain other data items described above with respect to PEAD. The credit card data may be input into the PECAD in advance through an appropriate input port or may be first read from the actual credit card using an appropriate R/W mechanism of the PECAD.

Since PECAD includes PEAD functionality, it can of course also be used to authorize transactions for PEAD-activated point-of-sale terminals in the manner described above with respect to PEAD. However, in the absence of PEAD-enabled point-of-sale terminals, an emulation card can be used instead to perform transactions against the existing credit card infrastructure.

In order to perform a transaction using the emulation card, the user first requests that PECAD record the credit card data included in the selected credit card in the emulation card. The selected credit card may be selected by the user before being recorded. Because a single emulation card can emulate any number of credit cards, the single emulation card can advantageously replace the multiple credit cards carried by users today. Preferably, the user is first properly authenticated before being able to use PECAD to write credit card data to the emulation card.

After the credit card data associated with the user selected credit card is written to the emulation card, the user can use the emulation card as if it were a credit card to complete the transaction. That is, the emulation card can be read by existing credit card readers as if it were a credit card because it must match the I/O requirements of existing credit cards and credit card readers.

Once the transaction is complete, the user can optionally use PECAD to erase credit card data from the emulation card, so until a suitably authenticated user authenticates PECAD again to write credit card data to the emulation card. It can render the emulation card useless to perform other transactions. If the emulation card emulates an electronic smart card, the emulation card cannot be used for other transactions, for example by configuring the appropriate registers or flags in the emulation card. Therefore, even when the emulation card is stolen, it is useless to unauthorized users. Moreover, even when the emulation card and PECAD are stolen together, the emulation card cannot record credit card data unless the user is properly authenticated. This is in stark contrast to the current situation, where, for example, a stolen credit card still contains all the information it needs to perform a transaction in its magnetic stripe. For security, the emulation card itself can be physically signed by a suitably authenticated user, and a video of the authenticated user can be displayed to give the merchant virtually certainty that the person performing the transaction is actually the legitimate owner of the emulation card. may include

In a preferred embodiment, in a substantially unique manner, each emulation card is matched with a specific PECAD to further enhance security. In this situation, a given PECAD can only write credit card data to an emulation card that is uniquely associated with it. For example, an emulation card can be suitably endowed with optically encrypted marks (holograms), magnetically encrypted marks (magnetically stored bits), or magnetically encrypted marks (randomly spaced holes). and therefore can only be recorded by a specific PECAD.

Preferably, each emulation card is matched with a single unique PECAD. However, this unique matching aspect need not be mathematically adversarial (although it may be desirable). Those skilled in the art will recognize that given a sufficiently large number of issued emulation cards and PECADs, any overlap may occur that makes it possible (although far from real life) for a given emulation card to be recognized by more than one PECAD. you will find out easily Indeed, a generator or manufacturer may own a master PECAD capable of recognizing a number of issued emulation cards. Therefore, the relationship between the emulation card and the PECAD is practically unique in that the door key is substantially unique for each door lock, but the potential for the creator to choose to make the emulation card absolutely unique with respect to a given PECAD. However, in a situation where millions of door locks are manufactured, the slim possibility that a given key can open more than one lock cannot be ruled out. Preferably, the geographically dispersed pattern of the encrypted marks of the emulation card/PEECAD (eg in the same city or state) is arranged so as to minimize the odds.

Since each emulation is effectively uniquely matched to a particular PECAD, even if the PECAD is stolen and the authentication mechanism is successfully evaded from the scammer, the PECAD will still use any arbitrary arbitrarily blank emulation card to perform fraudulent transactions. It cannot be used to record credit card data on As another advantage, the requirement that a given PECAD can substantially only write (after proper authentication) to the emulation card uniquely associated with it can greatly eliminate accidental overwriting of existing credit cards by PECAD.

9 shows a simplified block diagram of a PECAD 902 in accordance with one embodiment of the present invention. 9, memory 904 is preferably non-volatile and tamper-resistant memory, except for the fact that memory 904 may be used to store encrypted credit card data pertaining to one or more credit cards of a user. It performs the same role as the memory circuit of PEAD. Encryption logic 906 performs the same encryption/decryption/security functions as the encryption logic described with respect to PEAD. That is, access to data stored in memory 904 including the user's private key, the user's personal data and credit card data is preferably facilitated only by the encryption logic 906 .

The authentication mechanism 908 performs the same user authentication functions described in connection with PEAD. I/O circuitry 910 represents circuitry that allows a PECAD to communicate with a PEAD-enabled point of sale terminal if available for the purpose of authorizing a transaction. The transaction approval aspect will not be discussed further, as it has already been discussed in relation to PEAD. I/O circuitry 910 may be omitted in a particular PECAD model if the PECAD model does not communicate with a PEAD point of sale terminal and is only expected to be used to construct an emulation card to perform transactions against an existing billing infrastructure. .

The card R/W mechanism 912 represents the mechanism used to write selected credit card data to the emulation card and erase the emulation card after the transaction is complete. If the credit card data is obtained by reading from the existing credit card, the card R/W mechanism 912 also stores the credit card data in the memory 904 (via encryption logic 906) to the existing credit card. may include the ability to read from Data reads through card R/W mechanism 912 are encrypted by encryption logic 906 before being stored in memory 904 . Similarly, data stored in memory 904 (credit card data) is first decrypted by encryption logic 906 before being written to the emulation card via card R/W mechanism 912 .

10 is a simplified diagram of a PECAD 1002 including an emulation card 1004 disposed therein. The emulation card 1004 may be removed from the slot 1006 to complete a transaction for an existing credit card reader. In Fig. 10, the emulation card 1004 includes a magnetic stripe 1008 to emulate a magnetic stripe credit card. However, as noted above, emulation card 1004 may be configured to emulate any type of credit card interface, including IC contacts. The card R/W mechanism 1010 is shown in outline form to indicate that it is part of the PECAD 1002 . The card R/W mechanism 1010 allows data to be read from an existing credit card or written to an emulation card. The keypad 1015 may be used as an authentication mechanism, shown at 908 and 612 . The user may write a password or PIN to activate PECAD to write credit card data to the emulation card 1004 .

Approve button 1012 is substantially similar to approve button 606 of FIG. 6A and may be used to approve a transaction through a PEAD enabled point of sale terminal. On the other hand, the card button 1014 represents the user's desire to complete the transaction via the emulation card. Card selector buttons 1016(a)-(d) are typical choices that may be selected by a user to select a particular credit card that may be used to conduct a transaction. Display 1018 may be used to display credit card data such as the credit card number, expiration date, and holder's name of the selected credit card to allow the merchant to copy the information to complete the transaction if desired.

According to another aspect of the present invention, transaction security uses PECAD to write encrypted transaction number or other encrypted data (stored in secure non-volatile memory of PECAD) encrypted using the user's private key to the emulation card. is strengthened 11 illustrates this aspect of the invention according to one embodiment. In step 1102, a unique transaction number is generated and encrypted with the user's private key for each transaction. In step 1104, the encrypted transaction number is written from the PECAD to the emulation card. If the emulation card emulates a magnetic stripe card, the encrypted transaction number may be written to one of the existing but unused tracks or one of the reserved tracks of the magnetic stripe, for example track 3. In step 1106, the credit card reader's software may instruct the credit card reader to receive an encrypted transaction number, which is then authenticated using the user's private key obtained from a trusted third party (step 1108). ); or in step 1106, the credit card reader reads from the encrypted transaction number, which is then sent to a credit check center such as MasterCard or Visa card, and the credit check center retrieves the user's private key obtained from a trusted third party will be used to authenticate the user (step 1108). Typically, some form of user authentication is sent to a trusted third party to facilitate obtaining a public key. For example, the user ID or public key ID can be read by a credit card reader and sent to a trusted third party to obtain the public key. The public key ID may indicate a unique bit pattern (eg, least significant 32 bits or 64 bits) of the public key that may be transmitted to the destination for public key retrieval and decryption, for example. If authenticated, the transaction is approved and the seller can sell the goods/services to the user (step 1110).

As understood above, the present invention does not require substantially any hardware modifications to existing credit card readers and existing credit card infrastructure. The change simply involves a software change, which instructs existing credit card readers to read the encrypted transaction number and uses the user's public key obtained from a trusted third party to authenticate the encrypted transaction number. .

Moreover, there are no changes to the credit card reader. Instead, the credit check center software can be modified to authenticate the encrypted transaction number using the user's public key obtained from a trusted third party. A credit card reader reads all data from a credit card or emulation card, and sends all information to a credit inspection center for approval. In this way, the embodiment minimizes the changes that must be made to the existing credit card infrastructure (ie the changes must be made at a single location in the credit inspection center, not the millions of existing credit card readers).

If additional security is required, the user can enter the transaction amount and/or transaction time in PECAD. This kind of data can be encrypted using the user's private key, received by the credit card reader, and written to the emulation card so that it can be decrypted at the credit check center using the user's public key, which in turn Preferably obtained from a trusted third party. In this case, approval of the transaction is given only when the transaction is encrypted and for the amount dictated by the amount of transaction received and/or when the transaction is encrypted and occurs within a predetermined time of the received transaction time (this is from PECAD to the emulation card in advance recorded). Therefore, even if the emulation card is stolen, it is useless for other subsequent transactions, even if erasure or reconstruction of the emulation card has not occurred.

In the case of Internet transactions, the user can approve the transaction using PEAD or PECAD by encrypting the approved amount using a unique private key stored in PEAD and PECAD. Thereafter, the encrypted information displayed on the PEAD display 610 or the PECAD display 1002 can be copied to the Internet by inputting the information through the keyboard. The encrypted information displayed on PEAD display 610 or PECAD display 1002 can be easily read by a user from a computer connected through the Internet and entered manually (eg, keystrokes or voice commands) to conduct Internet transactions. ), a human-readable form such as an alphanumeric string is desirable. If necessary, the credit card number can be encrypted together with the transaction information by using PEAD or PECAD to securely perform Internet transactions. Manual entry/keying techniques, of course, are preferred for backward compatibility, but are replaced by other forms of data entry, such as wireless or infrared communications, through appropriate ports on the computer and PECAD (or PEAD) so that data can be transmitted over the Internet. can be

As mentioned above, it is preferred that the authentication of the user's identity be verified using the user's public key maintained by a trusted third party. A trusted third party may represent any entity with a very high level of credibility, such as, for example, an institution that is known to have a personal interest in gaining a credible reputation. Examples of this include government agencies, banks, and large corporations.

Trustees maintain a PECAD public key directory service that associates a list of public keys provided by producers with users. If the user first obtains PECAD (when purchasing or receiving payment from the issuer), the user can register a trusted third party with the owner of PECAD. Depending on the completeness of the registration process, the user may be assigned a validity level, which represents the degree of credit the person completing the registration really is.

For example, a user may sign a PECAD serial number and public key signature (which is a unique serial number assigned to a particular PECAD by the manufacturer and specified Registration can be done simply by providing a key sequence (which can be read from PECAD by pressing the key sequence). The PECAD public key directory center may then use the PECAD serial number provided by the user as a unique lookup ID to retrieve the public key from the database, and once it finds the public key it asks the user to verify the public key in the database. will use the public key signature provided by If this verification is successful, the user can be registered. Otherwise, the user will be rejected. The public key is preferably unique.

A more secure way to register a user's ownership is as follows (the process is usually issued at the place of purchase of PECAD/PEAD or by an issuer such as a bank). The publisher first activates PEAD/PECAD using the password provided by the producer. Afterwards, the PEAD/PECAD user can overwrite the user's password or other authentication mechanism(s) with the password provided by the manufacturer. The user can then instruct PEAD/PECAD to internally generate a new private/public key pair (referred to as user private key and user public key) inside PEAD/PECAD. The user also instructs PEAD/PECAD to encrypt a new user public key and personal information (resident number, home address, etc.) using a user-provided private key stored in PEAD/PECAD in advance to generate a user registration message. The private/public key pair provided by these producers can be generated by PEAD/PECAD when PEAD/PECAD is produced.

The issuer may then encrypt the PEAD/PECAD serial number and user registration message using the public key of the public key directory service center to generate a registration message and send the registration message to the public key directory service center. Upon receiving the registration message, the public key directory service center can then decrypt the registration message using its own private key. The public key directory service center can then use the PEAD/PECAD serial number to retrieve the public key provided by the manufacturer found in the database. If the decryption is successful, update the public key provided by the author with the new user public key in the directory service database, update personal information in the directory service database, for example, the person's name and phone number or other reference Generate a public key ID using one of the least significant 32 bits (or 64 bits) of the public key for On the other hand, if the decryption is not successful, the user will be rejected later.

This registration process usually involves people other than the user fraudulently obtaining the user's personal information for registration of ownership (and the user is liable for fraudulent claims once registration is complete and PECAD is activated). This allows for a lower effective level as possible.

The intermediate pay level may be obtained by providing information that provides a high degree of credibility regarding who the individual providing the information is in addition to the information provided to obtain the lower pay level. For example, the additional information may be in the form of a photograph, signature, notarized public symbol, or a combination thereof. A high level of validity can be achieved by providing information that provides a very high degree of credibility as to who the person providing the information is. For example, a registrant may appear to a person in the PECAD Public Key Directory Center to provide a photograph, signature, biological sample (fingerprint, retina scan, DNA print, etc.) or a combination thereof.

Once registration is complete, the PECAD public key directory by a trusted third party can be consulted by a credit check center or merchant to authenticate the user and authorize the transaction.

The PECAD public key directory can also be strengthened by establishing insurance policies that protect merchants or credit check centers from financial losses due to fraudulent activity, for example from incomplete registration procedures. The service coverage provided by the insurance policy is determined according to the effective level, and a high effective level is suitable for a high service range.

While the present invention has been described on the basis of several preferred embodiments, modifications, substitutions and equivalents exist within the scope of the present invention. There are also several alternative methods of practicing the methods and apparatus of the present invention. For example, although the above description has focused on transaction approval, PEAD may be used to perform any kind of transaction facing the electronic transaction system at any time to securely transfer data from the user to the electronic transaction system. It is obvious to those skilled in the art that For example, PEAD may be used to log to a highly sensitive computer system or device. When so used, the computer terminal with which the PEAD communicates may be equipped with an infrared port, magnetic reader, or contact plug for communication with the PEAD. The user can then use PEAD to perform any type of authentication task online.

In another example, PEAD can be used to "sign" any computer file for authentication (eg, to authenticate a date or user). The transaction acknowledgment data will be saved with the file to be authenticated for later reference. The transaction authentication data is not changed because any transaction authentication data that is not encrypted using the user's private key will not be authenticated. Also, if the PEAD is used to approve only predetermined transactions, it is clear that the transaction data can be pre-stored in the PEAD and does not need to be received externally by the PEAD. Accordingly, the following claims should be construed to cover all such modifications, substitutions and equivalents within the scope of the present invention.