Portable electronic charge and authorization devices and methods therefor

Description: TECHNICAL FIELD [Detailed description of the invention]

(Background of invention) The present invention relates to methods and devices for processing electronic transactions. In particular, it relates to a portable electronic authentication device (PEAD) that conveniently eliminates few security risks in the prior art of approving transactions between a user and an electronic transaction system. [0001]

Electronic transaction systems are well known. An electronic transaction system generally allows a user to process a predetermined transaction electronically, which greatly improves the efficiency and convenience of the user. Examples of electronic transactions include transactions that utilize computer networks, automated teller machines (ATMs), automated teller machine management systems, automated library systems, and the like. Transactions using computer networks include a wide range of transactions, such as shopping from vendors on a network by exchanging information and data over a computer network commonly known as the Internet. For example. At ATMs, users can usually perform financial transactions (withdrawals, transfers, deposits, etc.) with financial institutions electronically. The trader can use the point-of-sale information automatic management system that allows the user to purchase goods and services using the user's electronic account. An automated library system is used to allow users to borrow and return library materials. Other examples of electronic transaction systems are described in the general literature available and are not listed here for convenience. [0002]

To improve the security of a user's account, electronic transaction systems typically request the user to present identification data, thereby authenticating and applying for that user as an authenticated user. You can approve a transaction or multiple transactions. If the user is unable to present the requested identification data, the requested transaction will not be authorized and will not be processed. Identification data is requested on a transaction-by-transaction basis. As an example, the point-of-sale information automatic management system requested the user to approve the purchase transaction and presented appropriate identification data to authenticate that the person approving the transaction is the person who is entitled to approve. Only accept approval messages if. Alternatively, the user can be asked to enter identification data to authenticate himself at the beginning of the transaction, and then the transaction can be executed any number of times without asking for authentication again. [0003]

In the prior art, the user is generally requested to manually enter identification data into an electronic transaction system for authentication. In general, entering identification data involves typing a password on the numeric keypad or keyboard. The identification data is compared with the data stored in the electronic transaction system in advance, and if they match, the data is authenticated. As mentioned above, if they do not match, the submitted transaction will not be processed. [0004]

Conventional electronic transaction systems can protect user accounts to some extent from unauthorized access and use, but they have disadvantages. In order to show the electronic transaction system according to the prior art, FIG. 1 is referred to here. FIG. 1 shows an automated teller machine (ATM) 100, which is a device that issues a request for an electronic transaction system 102. The electronic transaction system 102 may include, for example, a central database 104 in which the identification data and account data of the user 106 are stored in advance. To initiate a normal transaction at ATM100, user 106 first inserts a data card 107, such as a bank card or credit card, into a card reader 109. The data card 107 usually has a magnetic stripe that contains information about the account number and other users, which the card reader 109 reads. The data stored in the data card 107 allows the electronic transaction system 102 to ascertain which account in the database 104 the user 106 wants to use for commercial transactions. [0005]

User 106 can authenticate himself by entering identification data, such as a personal identification number (PIN), from the ATM100 keypad 108. If the identification data, including the account stored in the database 104, identified by the data card 107 matches the entered identification data, the user is authenticated and is allowed access to his or her own account. If they do not match, you will not be authenticated. After authentication, user 106 can withdraw cash from his or her own account, for example, using the keypad 108 and screen 110 together. As a result, cash is withdrawn from the ATM 100 and the balance of the user 106's account in the database 104 is reduced accordingly. [0006]

In theory, the identification data entered into the ATM100 must be secure. In reality, traditional authentication technology identity data poses many potential security risks. The identification data is not encrypted until it is entered into the ATM100, and the unencrypted identification data is likely to be subject to unauthorized access or acquisition. Encryption of identification data by conventional techniques is not practical because it is too complicated or inconvenient for the user to perform encryption or store the encrypted identification data. In the prior art, identification data may be obtained without permission when typing on the screen 110, especially on the keypad 108, for example, if someone behind the user 106 inadvertently sees it. is there. [0007]

In the prior art, for example, even if the identification data is encrypted before being transmitted from the ATM 100 to the database 104, the encryption is usually performed inside the ATM 100, so that the unencrypted identification data from the user is also encrypted. Input is requested, and the identification data will exist in the ATM100 for a certain period of time. At that time, it is possible for an unauthorized person to invade the ATM100, access the identification data via the software or hardware installed in the ATM100, and intercept the unencrypted identification data. There is sex. Furthermore, when the public key cryptosystem is used in the ATM100, the public key is easily stolen by storing the user's private key in the ATM100, and the user's account is endangered. A stolen password or private key can allow an unauthorized person to access a user's account, resulting in damage to the user. [0008]

In view of the above, devices and means for processing transactions in electronic transaction systems are desired, with almost no risk of unauthorized access to the user's account or unauthorized theft of user identification data. It is desirable that such a device be easily portable so that the user can conveniently and comfortably perform transaction authentication anywhere. [0009]

(Outline of the invention) One embodiment of the present invention relates to a portable transaction configuration that allows a user to handle a charge card transaction using a charge card terminal of an electronic transaction system. The charge card terminal is configured to communicate with the charge card to handle charge card transactions. The charge card is one of a magnetic stripe card and an electronic smart card. The portable transaction configuration includes an emulation card with an emulation card interface. The emulation card interface emulates the charge card interface. The charge card interface facilitates communication between the charge card and the charge card terminal. It also includes a portable emulation card construction device configured to be used with the emulation card, which includes memory and authentication configured to store the first charge card data for the user's first charge card. The mechanism is included. If the user is authenticated through an authentication mechanism, the portable emulation card construction device is configured to write the first charge card data from memory to the emulation card. Therefore, in order to handle the transaction after writing, an emulation card appears via the emulation card interface as in the case of the first charge card in the charge card terminal, and the charge card terminal changes from the emulation card to the first charge card. The charge card transaction can be handled by reading the data. [0010]

Another embodiment of the present invention relates to a method of allowing a user to handle a charge card transaction by utilizing a charge card terminal of an electronic transaction system. The charge card terminal is configured to interface with the charge card to handle charge card transactions. The charge card is one of a magnetic stripe card and an electronic smart card. The method includes a method of providing an emulation card having an emulation card interface. The emulation card interface emulates the charge card interface. The charge card interface facilitates communication between the charge card and the charge card terminal. The method includes a method of providing a portable emulation card construction device configured for use with an emulation card. It also includes a memory and authentication mechanism configured to store the first charge card data for the user's first charge card. If the user is authenticated through an authentication mechanism, the portable emulation card construction device is configured to write the first charge card data from memory to the emulation card. As a result, an emulation card appears via the emulation card interface in the same way as the first charge card in the charge card terminal to handle the transaction after writing, and the charge card terminal transfers the first charge card data from the emulation card. Charge card transactions can be handled by reading. [0011]

Yet another embodiment of the present invention relates to a method of allowing a user to approve an Internet transaction request using a user's computer terminal connected to the Internet. Internet transaction requests are generated by a first computer connected to the Internet. The method includes a method of transmitting the first digital data from the first computer to the user's computer terminal, the first digital data representing an internet transaction request. The method also includes a method in which a second computer connected to the Internet receives the second digital data. The second digital data is manually entered by the user via the user's computer terminal. The second digital data is user-readable encrypted transaction authorization data, in which the user's private key is obtained by one of a portable electronic authentication device (PEAD) and a portable electronic billing / authentication device (PECAD). For Internet transaction requests that are encrypted from information entered by the user into one of the portable electronic billing / authentication device (PECAD) and the portable electronic billing / authentication device (PECAD). It is for the user to express approval. Further, the method includes decoding the second digital data using the user's public key after reception. [0012]

Yet another embodiment of the invention relates to a computer-based method of registering a user of a particular electronic cryptographic device configured to encrypt data based on a public key cryptosystem. The method includes providing a public key list and identifying information about multiple electronic cryptographic devices in a computer database, the public key list being associated with each of the multiple electronic cryptographic devices individually. Furthermore, the present invention includes receiving device identification data from the user. The device identification data identifies a particular electronic encryption device. Further, it includes confirming the identity of the user by receiving the encrypted user identification data. In addition, it involves verifying a particular public key associated with a particular electronic cryptographic device from the database by associating the device identification data with the particular electronic cryptographic device in the database. Further, it also includes decrypting the encrypted user identification data using a specific public key and associating the user with a specific electronic encryption device in the database if the decryption is successful. By reading the detailed description below and studying the various forms shown in the drawings, it will become clear that there are these and other advantages of the present invention. [0013]

(Detailed description of the invention) FIG. 2 shows a portable electronic authentication device (PEAD) 200 according to an embodiment of the present invention, which is a device that reliably approves transactions processed with respect to an electronic transaction system. Referring to FIG. 2, request device 202 initiates a transaction approval process with PEAD200 by sending a transaction request for the applied transaction to PEAD200 via COM port 204. The request device 202 is a device similar to a device that allows a user to make a commercial transaction using, for example, an ATM machine, a computer terminal of a network, an automated library checkout terminal, or an electronic transaction system. The applied transaction is, for example, a sales transaction for a particular merchandise of a fixed amount. The transaction request itself includes, for example, a transaction ID, a trader name, a trader ID, a time when a purchase is applied, and the like. In one embodiment, the transaction request from the request device 202 is encrypted for added security, but this is not required. Data about the submitted transaction arrives at PEAD200 via route 206 in Figure 2. [0014]

Port 204 is an infrared port for facilitating infrared communication with PEAD200. Alternatively, port 204 is a wireless port for facilitating wireless communication. Further, the port 204 is a magnetic read / write mechanism, that is, a contact COM port such as a plug having an electrical contact for directly connecting the PEAD 200 to the port 204, facilitating communication. Other techniques that facilitate communication between the request device 202 and PEAD200 are readily evaluable to those of skill in the art. The data regarding the requested transaction is then reviewed by the user on either screen 208 of request device 202 or the optional display screen provided by PEAD200 (not shown in FIG. 2). When the user approves a transaction, eg, the purchase of goods for a given amount of money, the user expresses approval by activating switch 210 on the PEAD200. As a result, the user's identification data is used to create an authorization message, which is encrypted and returned to the request device 202 via route 212. If the transaction is not approved, the user does nothing and either the transaction request times out after a certain amount of time, or another switch on the PEAD200 (not shown in Figure 1) is active. Will be done. This causes an encrypted or unencrypted deny message to be returned to the request device 202 via route 212. [0015]

In the prior art, the present invention is similar to the prior art of FIG. 1 in that the user must enter his or her own identification data into an electronic transaction system, eg, ATM100, in order to authenticate the user himself or herself. Is different. In contrast, the present invention always ensures identification data about the user within the PEAD200. The transaction is approved within PEAD200, and the data indicating the approval is encrypted again by PEAD200 before being sent to the electronic transaction system, for example, the request device 202 of FIG. [0016]

Therefore, even if the approval data is intercepted, it is encrypted so that an unauthorized user cannot illegally use the identification data. When using public key cryptography to encrypt authorization data, the user's private key is always kept in PEAD200. The user's private key is always required for encryption, and even the electronic transaction system of one embodiment does not know it, so that the encrypted authorization data is allowed even if it is intercepted. Encrypted authorization data is of no use to an unenforced third party. This is useless even if the authorization data can be decrypted using the user's public key. In addition, it differs from conventional authentication technology in that it encrypts with an electronic transaction system, requests input of identification data, and reads the user's private key from an ID card such as an ATM card or credit card. There is. As mentioned above, traditional electronic transaction systems require this identity data and the user's private key, so for example, if the requesting device is insecure, that is, the data can be intercepted via software or hardware. If so, these data will be at stake. [0017]

Another difference is that the present invention approves and encrypts transaction approval data within the PEAD itself by providing a circuit within the portable electronic authentication device (PEAD). In contrast, prior art data cards are essentially passive elements. For example, prior art ATM cards and credit cards have only magnetic stripes for storing account information and do not have the ability to approve or encrypt transaction approval data. In general, smart cards currently being developed, that is, IC cards, are equipped with electronic circuits, but according to their current practice standards, an additional reader corresponding to the requesting device is required, thereby The requesting device can read the identification data and the user's private key to perform authorization and encryption. As mentioned above, once these data are sent to the requesting device, they are at risk of inadvertent theft or unauthorized interception. [0018]

Here, in the present disclosure, public key cryptography has been discussed for ease of understanding and for emphasizing specific aspects of the present invention, but the present invention is limited to a specific encryption algorithm. Instead, it can be implemented using traditional cryptographic techniques, including RSA, Diffie-Hellman, and other public key cryptographic algorithms such as discrete log systems and elliptical curve systems. For additional information on other public key cryptography technologies, see, for example, IEEE P1363 / D8 Public Key Cryptography Standards available from the IEEE Standards Department located at 345 East 345, 7th Avenue, New York City, NY 10017-2349. (October 5, 1998) can be quoted. [0019]

As mentioned above, prior art transactions are approved within an electronic transaction system. In contrast, the present invention allows transactions to be approved with PEAD200. There are many benefits to approving all transactions inside PEAD200. For example, in one embodiment, this feature eliminates the need to enter identification data or the user's private key into the requesting device. All transactions are approved inside PEAD200 (using the user's identification data and the user's private encryption key, which are always securely held inside PEAD200), so that the transaction approval process is completed and the user's identification is verified. Greatly improves the confidentiality of data and user private keys. [0020]

Since the authorization is entirely internal to PEAD200, the user identification data used to approve the transaction becomes more complex and elaborate to ensure higher security. As an example, user identification data is more elaborate than simple passwords, such as usernames, birthdays, social insurance numbers and other unique biometric data such as fingerprints and DNA code sequences. Includes unique identification data such as voiceprints. In contrast, traditional authentication techniques limit user identification data to simple patterns that are easy for the user to remember, such as simple passwords that contain few characters. This is because more elaborate identification data is too difficult to remember and is cumbersome to enter manually. Moreover, even if complex ID data is stored on a prior art data card, it must be further read by the requesting device of the electronic transaction system, and once read, this data is intercepted, or stolen, again. You are at risk of being killed. [0021] [0021]

The other protective measures detailed here are provided to prevent access to the user's identification data and the user's private key within the PEAD 200 by electronic or physical means. Identity data and the user's private key are never disclosed, so security risks to these data are largely minimized. FIG. 3A shows a schematic view of PEAD200 of FIG. 2 including a switch 210 according to an embodiment of the present invention. Data path 206 is provided to receive transaction requests from the electronic transaction system, and data path 212 is provided to send transaction approval data back to the electronic transaction system. Although two data paths have been described here for ease of understanding, these and other data paths in one embodiment are logical data paths and can be implemented by a single physical data connection. There should be some consideration. Similarly, for ease of understanding, the various ports in an embodiment are logical data ports, which are actually implemented using one physical port. [0022]

When a transaction request, for example, a transaction to withdraw $ 200 from an ATM machine, is sent to PEAD200 via data path 206, this transaction is received by cryptographic unit 300. Here, for example, through an electronic transaction system or a display screen provided to the PEAD200, the user reviews the applied transaction and selects whether to approve or disapprove the applied transaction. In one embodiment, when the user approves a transaction, the transaction approval data is created by the user activating the switch 210 and then encrypted before being sent back to the electronic transaction system over route 212. It is encrypted by the logic unit 300. [0023]

Note that the user identification data block 302 used in the transaction approval process is not directly connected to routes 206 and 212. That is, the memory unit that stores the user's identification data is intentionally separated from the input / output port of the PEAD 200 in order to prevent direct access to the memory unit. For example, if the user's identification data 302 needs to be accessed in order to approve the transaction, only the cryptographic logic block 300 can access it. Similarly, it is not possible to directly access the memory unit 304 that stores the user's private key. For example, if the user's private key 304 needs to be accessed in order to encrypt the transaction approval data, the encryption logical block 300 can access it. The user identification data 302 and the user's private key 304 are shown to be stored in different memory units, but this figure is for ease of understanding, and in one embodiment, either of these Consider that they are also stored at different addresses on the same memory module. [0024]

In some cases, the transaction approval data may need to include part of the identification data 302. For example, a transaction embodied in a transaction request from an electronic transaction system before being encrypted and sent back to the electronic transaction system is supplemented with typical data called an "electronic signature." In one embodiment, FIG. 3B shows a typical transaction approval data 350 format. Referring to FIG. 3B, transaction data 352 showing a part or all of the transaction request received from the electronic transaction system is added to the identification data 354 of a specific user and the optional time stamp 356. Transaction approval data 350 is configured only if the transaction request has already been approved by the user. Once added, the transaction approval data 350 is encrypted before being sent back to the electronic transaction system. [0025]

In some cases, for even greater security, it may be desirable to encrypt the transaction request before sending it to PEAD. For example, a particular transaction partner, such as a vendor or other user on a computer network, wants to keep the information in a transaction request confidential and wants to encrypt the transaction request before submitting it to PEAD. For example, it is desirable to encrypt the data when it is first written to a blank PEAD in order for the user's identity data and the user's private key to form a PEAD that is unique to a given user. User identification data and configuration data about the user's private key must be written to PEAD200 only once by the PEAD200 issuer, but should be encrypted to prevent them from being stolen. .. The issuer of PEAD200 is, for example, a credit card issuer, relevant ministries, or other institution in which the user has an account. [0026]

FIG. 4 is a block diagram of PEAD200 according to an embodiment of the present invention of FIG. The PEAD200 in FIG. 4 further uses a decryption logic unit to receive encrypted configuration data and, as an option, an encrypted transaction request. In FIG. 4, the encryption logic unit 300, the user's private key 304, and the data paths 206 and 212 are arranged and function almost in the same manner as those described with respect to FIG. 3A. Transaction requests are usually unencrypted, i.e. they are received and processed in the manner described with respect to Figure 3A. However, in the case of a very sensitive transaction, the transaction request is encrypted, sent to PEAD200 via the data path 206, input to the decryption logic unit 402, and decrypted. Using public key cryptography, an encrypted transaction request is decrypted by the transaction partner's public key. [0027]

Once decrypted, the transaction request is displayed for user approval. If approved, the transaction approval data is sent to the encryption logic unit 300 via the path 406 and encrypted in response to the activation of the switch 210, for example. When using public key cryptography technology, it is desirable to encrypt with the user's private key 304. In addition, the encrypted transaction approval data is sent back to the electronic transaction system via the data path 212. [0028]

In general, the configuration data contains the user's sensitive identification data and the user's private key, so that they are encrypted before being sent to the PEAD 200 via the data path 408. The encrypted configuration data is received and decrypted by the decryption logic unit 402 before being written to the user identification data block 410 or the user's private key block 304. When using public key cryptography, the encrypted configuration data is encrypted with the issuer's private key of the electronic transaction system before transmission, and when received by PEAD200, it is used with the issuer's public key 412. It is decrypted. [0029]

When the configuration data is decrypted and written to the user's identification data block 410 or the user's private key block 304, after that, the user's identification data and the user's private key are only the encryption logic unit 300. Note that can be accessed. Furthermore, it should be noted that there is no direct connection from the I / O data paths such as data paths 206, 212, 408 to the user private key block 304 and to the user identification data block 410. Conveniently, once the user sensitive identity data and the user private key are written to blocks 410 and 304 (in one embodiment, they simply represent the memory blocks of the PEAD200 memory), they cannot be accessed externally. [0030]

Furthermore, the user identification data and the user private key cannot be updated without the issuer's private key. As shown in FIG. 4, after the data is decrypted by the decryption logic unit 402 using the issuer's public key 412, it is written only in the user's private key block 304 and the user's identification block 410. Therefore, unless the updated configuration data is encrypted with the issuer's private key (probably very secure), the updated configuration data will not be decrypted and will be written to blocks 304 and 410. I can't. Of course, if the configuration data for blocks 304 and 410 cannot be physically updated, store them in one-time writable memory such as PROM (programmable read-only storage) or WORM (write-once). In that case, the security issue of unauthorized modification of configuration data is largely eliminated. [0031]

If a high level of security is required, optionally scramble the user's private key, i.e. after randomization, the optional scrambler / descrambler logic unit 413 blocks the user's private key. You may write in 304. The scrambler / descrambler logic unit 413 of one embodiment receives the user private key provided by the institution issuing the PEAD 200 to the user, scrambles or randomizes it, and sets it as yet another user private key. Generate the corresponding user public key. This scrambled / randomized user private key is stored in the user's private key block 304, which is unknown to the issuer of PEAD200. The corresponding user public key can be notified to the issuer or transaction partner to facilitate the transaction. Fortunately, there is no scrambled / randomized copy of the user private key other than the user private key block 304. [0032]

In another embodiment, the key generation logic unit 414 is optionally used, which receives a request from the issuing authority, receives the user private key from the issuing authority, and does not randomize the user secret. Generate a key and its user public key. The generated user private key is then stored in the private key block 304, and the public key is informed to the issuing institution or transaction partner to facilitate the transaction. Thus, there is no version of the user private key outside of PEAD itself, whether randomized or not. As those skilled in the art know, the confidentiality of the user private key is further improved by using the key generation logic unit 414. [0033]

FIG. 5A shows a high level of hardware that implements PEAD200 according to an embodiment of the present invention. As shown in FIG. 5A, the PEAD 200 includes a logic circuit 502 to implement the encryption logic unit 300 of FIG. 2 and the optional decryption logic unit 402 shown in FIG. 4, and the logic circuit 502. Is a microprocessor, that is, a central processing device such as a microprocessor, a discrete logic unit, a programmable logic unit, or an integrated circuit (ASIC) for a specific application. In the program / data memory 504, for example, a code for operating the PEAD 200 is stored together with the user's identification data and the user's private key. It is desirable to implement the program / data memory 504 using non-volatile memory (NVM) such as flash memory or EPROM or EEPROM. The temporary storage memory 506 functions as a scratch pad for calculation and temporary storage of data, and is implemented using random access memory (RAM) such as static RAM or dynamic RAM, which is well known in the art. Alternatively, optical memory, magnetic memory, or other types of memory are used to implement program / data memory 504 or temporary storage memory 506. [0034]

The bus 508 connects the program / data memory 504 and the temporary storage memory 506 to the logic circuit 502. COM port 510 is a communication gateway between PEAD200 and an electronic transaction system, implemented by infrared technology, wireless RF technology, magnetic read / write heads, contact plugs to facilitate serial / parallel data communication, etc. .. The COM port of one embodiment is a PC card port (generally known as a PCMCIA card). The data path 206 inputs a transaction request to the logic circuit 502, and the data path 212 outputs transaction approval data from the logic circuit 502 to the electronic transaction system. The optional data path 408 described in FIG. 4 is uniquely constructed by PEAD200 for a specific user by inputting configuration data to PEAD200 and writing user identification data and user private key to program / data memory 504. Will be done. [0035]

Also note that only the logic circuit 502 can access the program / data memory 504 and the data in it (eg, user identification data and user private key). If this data is properly encrypted with the issuer's private key, for example, only the user identification data and the user private key can be written to the program / data memory 504. Accessing and writing to these memory blocks under the control of appropriate software and firmware is prohibited by logic circuit 502. Similarly, reading of the user's identification data and access to the user's private key are achieved only through the encrypted logic part of the logic circuit 502. The security benefits from this point of view have been described in Figures 3A and 4, but the most important point is that the confidential user identification data and user private key cannot be accessed directly from the outside. Therefore, the design of the present invention greatly improves the confidentiality and security of these data items. [0036]

A power source such as a battery can also be provided. If the PEAD200 is designed as a single chip, i.e., if almost all of the components shown in Figure 5A are assembled on one die, the power supply is external to the die itself. For contact transmissions, for example, if the PEAD200 must be connected to an electronic transaction system to handle the transaction, by using an external power supply for the entire PEAD to approve the transaction at the time of plug-in. It is possible to solve the problems of size, weight and cost of a portable transaction device equipped with a battery. [0037]

In one embodiment, the PEAD 200 can be realized by using a portable general-purpose computing device such as a portable small computer or a portable information terminal (PDA). In order to realize PEAD200, for example, a PDA such as Apple Newton (registered trademark) may be used. FIG. 5B shows an example of PEAD in which the circuit is implemented on the IC. In FIG. 5B, components with the same reference numbers as the components of FIG. 5A have similar functions. As described in FIG. 5A, the data paths 408, 206, 212 are connected to the serial I / O circuit 520 to facilitate serial transmission and reception of data via the data path 522 between the PEAD 200 and the electronic transaction system. .. Also shown are Vcc pin 524 and ground pin 526 that power the PEAD 200 in Figure 5B. [0038]

Figure 5C shows the appearance of the PEAD in Figure 5B embedded in a card-type package that is easy to move and insert into the serial I / O port of an electronic transaction system. The card 550 of one embodiment incorporating an integrated circuit for carrying out the PEAD of the present invention has four external contacts. External serial contacts 552 and 554 send data and ground levels, respectively, facilitating serial communication with serial devices in electronic transaction systems. As described in FIG. 5A, the external Vcc contact 524 and the external ground contact 526 supply power to the PEAD, which are also illustrated. When the card 550 is inserted into the electronic transaction system, it is powered through external contacts 524, 526. This causes the PEAD circuit to receive the transaction request via the external serial contacts 552 and 554, approve the request with PEAD if it is appropriate, encrypt the transaction approval data with the PEAD circuit, and use the external serial contact. Transaction approval data encrypted via 552 and 554 can be serially communicated to an electronic transaction system. [0039]

FIG. 6A shows the appearance of PEAD in a preferred embodiment of the present invention. The PEAD 200 in Figure 6A should be implemented as a self-encapsulating / small package reinforced to withstand everyday use in the field. The PEAD200 in Figure 6A should be small enough to be carried comfortably by the user, for example, in a small package that can be attached to a keychain and easily fits in a wallet. The PEAD200's physical data is configured to prevent unauthorized opening (ie, opening it in an unauthorized manner destroys the user's private key and user identification data, and PEAD can no longer approve transactions. ) Is preferable. As an example, if opened, the current flow in the current path will either change, for example, the existing current flow will be interrupted or the idle current path flow will begin. The internal data can be configured as follows. The change in current flow forces RE. [0040]

An infrared COM port 602 for sending and receiving data to and from an electronic transaction system is shown. A small on / off switch 604 allows the user to turn off PEAD to save power when not in use. The approval button 606 allows the user to approve the submitted transaction. The optional skip button 608 allows the user to indicate the rejection of a particular transaction. In certain embodiments, if the approval button 606 is not activated within a predetermined time after receiving the request, the transaction request is considered unapproved and the skip button 608 may be omitted. [0041]

The optional display 610 is realized by display technology such as liquid crystal technology. Display 610, among other things, shows the transaction submitted for approval. For example, if the transaction can be seen on a display for the electronic transaction system itself and the display 610 is desired to be eliminated, it may be eliminated. Using PEAD200 to approve a transaction is prohibited by the optional user authentication mechanism 612 if the user himself is not identified by PEAD200 as a legitimate user. An optional user authentication mechanism 612 identifies the user's unique characteristics by requiring the user to enter a password and provide fingerprints, voiceprints, and other biometric data. Then PEAD200 is activated and used to approve the transaction. [0042]

FIG. 6B briefly illustrates the hardware of one aspect of the invention to implement the PEAD 200 of FIG. 6A. Battery 652 powers the circuit of PEAD200. The microcontroller 654 executes the code stored in the flash memory 656, and uses the random access memory 658 for the execution. In one embodiment, even the microcontroller 654, flash memory 656, and random access memory 658 are mounted on one Motorola NC68HC05SCXX family chip in Schaumburg, Illinois, such as the NC68HC05SC28. Can be done. The approval button 606 and the optional skip button 608 are connected to the microcontroller 654 so that the user can instruct the approval or rejection of a particular transaction displayed using the display circuit 660. Communication with the electronic transaction system takes place under the control of microcontroller 654 via the infrared transceiver 662. The power switch 664 allows the user to power off the PEAD200 when not in use to retain power and prevent accidental approval. [0043]

FIG. 7 is a flowchart of one aspect of the present invention showing the approval technique using PEAD of the present invention. In step 702, PEAD receives a transaction request from the request device that works with the electronic transaction system. In step 704, the user has the option of approving or disapproving the submitted transaction. For example, if it is not approved by either activating the PEAD skip button or simply timing out the request, nothing is done. On the other hand, when the user approves the applied transaction, the user activates the approval button to create transaction approval data. The transaction approval data is then encrypted in step 708 within PEAD. After encryption, step 710 sends the encrypted transaction approval data to the request device of the electronic transaction system. [0044]

FIG. 8 is a flowchart showing a process included in the encryption of transaction approval data by the public key cryptosystem according to one aspect of the present invention. In step 802, a transaction approval data package is created. As described in FIG. 3B, transaction approval data is created by adding the required user identification data to part or all of the transaction request. Optionally, a time stamp is also added to it. In step 804, the transaction authorization data is encrypted by the user's private key, but it is desirable that the user's private key is always kept secure in PEAD. The encrypted transaction approval data is then sent back to the electronic transaction system. [0045]

In one aspect of the invention, even if the encrypted transaction authorization data is intercepted and decrypted by a third party for analysis, as long as the user's private key and user identification data are protected. It turns out that it is impossible to circumvent the security mechanism of the present invention. As mentioned above, the user's identification data is not accessible from the outside, so it is always protected within PEAD. This is different from the conventional technology in which there is a risk that this confidential data will be disclosed because the user has to enter identification data such as a password in an electronic transaction system. If the user's identification data is compromised, the transaction will not be approved unless the user's private key is owned. Even if it can be decrypted using the user's public key, it is useless to intercept the encrypted transaction approval data. This is because transaction partners, such as those requesting transaction approval, do not accept unencrypted transaction approval data, even with the user private key. Also, since the private key cannot be accessed from the outside, it is always protected within PEAD. This aspect of the invention has great advantages when dealing with transactions online. Because it is no longer necessary to store the user private key in a vulnerable computer file that resides on a workstation that is accessible to others but difficult to move conveniently with other authentication tasks. Because. [0046]

By implementing PEAD in a small / portable package, users can conveniently and easily keep PEAD in their own property at all times. However, even if the PEAD is physically stolen, an optional user authentication mechanism, such as the user authentication mechanism 612 in Figure 6A, provides additional protection and provides PEAD to anyone other than a properly authenticated user. To disable. Of course, if the PEAD is stolen or lost, the user can always notify the PEAD issuer, who will use the stolen PEAD user's private key to encrypt the transaction authorization data. Contact the transaction partner to refuse. [0047]

Transaction approval data includes type stamps, vendor names, approval amounts and other relevant data, further enhancing the integrity of the transaction approval process. If the vendor inadvertently or intentionally grants the issuer approval of multiple transactions, the issuer recognizes from these data items that the grants are duplicated and duplicate transaction approval data. Can be ignored. For example, the issuer recognizes that a user cannot order the same meal multiple times at the same restaurant at a given date and time. [0048]

Here, even though PEAD and point-of-sale terminals with PEAD enabled can provide a highly secure system for approving transactions, millions of existing ones are in use around the world. The inventor recognizes that there is an already established and widely available charge card infrastructure, including charge card point-of-sale terminals (eg, charge card readers and ATM terminals). We also recognize that certain PEAD features can improve transaction security in existing charge card infrastructure, even without a point-of-sale terminal with PEAD enabled. [0049]

Another aspect of the invention is a portable electronic billing / authorization device (PECAD). By providing the PEAD functionality described above, it not only allows users to utilize point-of-sale terminals with PEAD enabled to approve transactions, but also handles transactions in the existing charge card infrastructure. It is something that can be done. In particular, the entire PECAD system includes PECAD and ancillary emulation cards, which comply with current charge card standards only for interfaces with existing charge card readers. PECAD gives you the flexibility to configure your embroidery card so that your existing charge card reader can be considered a regular charge card. At the same time, PECAD and emulation cards form a secure system for handling transactions in the existing charge card infrastructure. [0050]

Note that the term charge card used in this embodiment includes both magnetic stripe cards and electronic smart cards. The charge card itself is a credit card (Visa card or Mastercard), ATM card, loyalty card, discount card, or other card that the user uses at the point-of-sale information management terminal to obtain cash, goods, or services. .. Prior to dealing with transactions, PECAD's memory contains charge card data for one or more of the user's charge cards. The memory also contains the other data items mentioned above for PEAD to perform the functions of PEAD. Charge card data is pre-populated into PECAD via the appropriate input port or pre-read from the actual charge card by PECAD's appropriate R / W mechanism. [0051]

Since PECAD has a PEAD function, it can be used to approve transactions using a point-of-sale terminal with PEAD enabled as described above for PEAD. However, if there is no point-of-sale terminal with PEAD enabled, an emulation card can be used instead to handle transactions in the existing charge card infrastructure. To handle transactions with an emulation card, the user first requires PECAD to write charge card data for the selected charge card to the emulation card. The selected charge card is selected by the user prior to writing. Since one emulation card can emulate multiple charge cards, this single emulation card can conveniently replace multiple charge cards that the user must carry with him at all times. First, the user is properly authenticated by the appropriate authentication mechanism affiliated with PECAD, and then PECAD it is desirable that the available to write charge card data to the emulation card. [0052]

After the charge card data for the charge card selected by the user has been written to the embroidery card, the user uses the emulation card as if it were a charge card to complete the transaction. That is, the emulation card complies with the I / O requirements of existing charge cards and charge card readers, so it is read by the existing charge card reader as if it were a charge card. [0053]

When the transaction is complete, the user uses the optional PECAD to erase the charge card data from the embroidery card until a properly authenticated user authenticates PECAD again and writes the charge card data to the emulation card. Emulation cards are useless for dealing with transactions. If the emulation card emulates an electronic smart card, for example if the emulation card has the appropriate registers and flags, the emulation card will not be available for other transactions. Therefore, if the emulation card is stolen, it does nothing to unauthorized users. Furthermore, even if the emulation card and PECAD are stolen together, the charge card data cannot be written to the emulation card itself unless the user is properly authenticated. This is in stark contrast to the existing situation. This is in contrast to, for example, a stolen credit card containing all the information needed to handle a transaction in a magnetic stripe. For additional security, a properly authenticated user may have a physical signature on the embroidery card itself or may include a photo of the authenticated user, which emulates the person handling the transaction. The vendor can visually confirm that the card is the legitimate owner. [0054]

In a preferred embodiment, each embroidery card is matched with a particular PECAD in a nearly unique way, further improving security. In this case, only a given PECAD can uniquely write the charge card data to the embroidery card associated with it. As an example, an emulation card may have properly encrypted marks (holograms, etc.), magnetically encrypted marks (magnetically stored bits, etc.) or mechanically encrypted marks (random intervals). Since there are holes etc.), only a specific PECAD can write. [0055]

Each emulation card should match one unique PECAD. However, it should be noted that this unique match does not have to be (preferably) a mathematical absolute value. It is a person skilled in the art that if there are enough emulation cards and PECADs, one or more PECADs will be able to recognize a given emulation card (although it is not practical) and overlap may occur. I know if there is one. In fact, issuers and manufacturers own a master PECAD that can recognize a large number of issued emulation cards. Therefore, the relationship between the emulation card and PECAD is almost unique in the sense that the door key is almost unique for each door lock, but the manufacturer chooses the emulation card and it is completely from the given PECAD. The possibility of being unique, that is, the rare possibility of unlocking one or more of the millions of door locks manufactured with a given key, is not ruled out. Geographical distribution patterns of encrypted marks and emulation cards / PECAD (eg, within the same city or country) should be configured to minimize their rarity. [0056]

Each emulation matches a particular PECAD almost uniquely, so even if the PECAD is stolen and the authentication mechanism is successfully evaded by someone who intends to cheat, it is stolen to cheat. It is not possible to write charge card data to any blank emulation card using PECAD. Another advantage is that the requirement that only a given PECAD be writable (after proper authentication) to the embroidery card associated with it almost uniquely eliminates the accidental overlap of existing charge cards by PECAD. Is to be done. [0057]

FIG. 9 shows a schematic block diagram of PECAD 902 according to an aspect of the present invention. In FIG. 9, memory 904 is a non-volatile tamper-proof memory, the memory of PEAD, except that it is used to store encrypted charge card data for one or more charge cards of the user. It is desirable to function like a circuit. The encryption logic unit 906 performs encryption / decryption / security functions in the same manner as the encryption logic unit described in relation to PEAD. That is, it is desirable that the data stored in the memory 904 including the user private key, the user's personal data, and the charge card data is easily accessed only through the encryption logic unit 906. [0058] [0058]

The authentication mechanism 908 performs the same user authentication functions as described for PEAD. If a point-of-sale terminal with PEAD enabled is available to approve the transaction, the circuit that enables communication between that terminal and PECAD is the I / O circuit 910. The mode of transaction approval has already been discussed in PEAD and will not be discussed in detail here. Specific if the PECAD model does not communicate with the PEAD point-of-sale terminal or is expected to be used solely for the purpose of building emulation cards to handle transactions in the existing charge card infrastructure. The I / O circuit 910 may be omitted from the PECAD model. [0059]

The card R / W mechanism 912 is a mechanism used to write selected charge card data to the embroidery card and erase the embroidery card after the transaction is complete. If the charge card data is acquired by reading the existing charge card, the ability to read the existing charge card to store the charge card data in memory 904 (via the encryption logic unit 906) is also a card R / W. Included in mechanism 912. Note that the data read through the card R / W mechanism 912 is encrypted by the encryption logic unit 906 before being stored in the memory 904. Similarly, the data (charge card data, etc.) stored in the memory 904 is first decrypted by the encryption logic unit 906 before being written to the emulation card via the card R / W mechanism 912. [0060]

FIG. 10 is a schematic view of PECAD 1002 in which the emulation card 1004 is arranged. The emulation card 1004 can be removed from slot 1006 to complete a transaction to an existing charge card reader. In the example of FIG. 10, the emulation card 1004 comprises a magnetic stripe 1008 and emulates a magnetic stripe charge card. However, as mentioned above, the emulation card 1004 is configured to emulate a charge card interface with IC contacts. It is shown in outline format to show that the card R / W mechanism 1010 is part of PECAD 1002. Data is read from an existing charge card via the card R / W mechanism 1010, or data is written to an emulation card. The keypad 1015, like the 908, can be used as the authentication mechanism described in 612. The user can write the charge card data to the emulation card 1004 by keying in the password, ie the PIN, to activate PECAD. [0061]

Approval button 1012 is substantially the same as Approval button 606 in Figure 6A and is used to approve a transaction through a point-of-sale terminal with PEAD enabled. The other card button 1014 indicates the user's desire to complete a transaction via an emulation card. The card selection buttons 1016 (a)-(d) are exemplary to be selected and are selected by the user to select a particular charge card to be used to perform a transaction. Display 1018 is used to display charge card data such as the charge card number, expiration date and owner name of the selected charge card, which allows the trader to copy that information and carry out transactions if desired. Can be completed. [0062]

According to another aspect of the invention, embroidery of encrypted transaction numbers (stored in secure non-volatile memory in PECAD) or other encrypted data encrypted using the user's private key. Transaction security is further enhanced by using PECAD to write to the card. FIG. 11 shows an embodiment of the present invention. In step 1102, a unique transaction number is generated, and each transaction is encrypted using the user private key. In step 1104, the encrypted transaction number is written from PECAD to the emulation card. For example, if the emulation card emulates a magnetic stripe card, the encrypted transaction number is written to one of the existing unused tracks, i.e. one of the spare tracks, eg, track 3 on the magnetic stripe. Is done. In step 1106, the charge card reader software instructs the charge card reader to receive the encrypted transaction number. The encrypted transaction number is then authenticated based on the user public key obtained from a trusted third party (step 1108). That is, in step 1106, the charge card reader reads the encrypted transaction number. The encrypted transaction number is then sent to a credit clearance center such as MasterCard or Visa, which authenticates the user based on the user's public key obtained from a trusted third party. (Step 1108). Generally, the user's identification form is sent to a trusted third party so that the public key can be easily obtained. As an example, the user ID and public key ID are read by a charge card reader and sent to a trusted third party to obtain the public key. For example, the public key ID is a unique bit pattern of the public key (for example, the least significant 32 bits or 64 bits), and the public key is for searching and decrypting the public key. Sent to the receiving site. If authenticated, the transaction is authenticated and the vendor can provide the goods / services to the user (step 1110). [0063]

As can be correctly understood from the above explanation, in the present invention, it is not necessary to modify the hardware to match the existing charge card reader or the existing charge card infrastructure. Only software changes are needed, instructing the existing charge card reader to read the encrypted transaction number and using the user's public key obtained from a trusted third party for the encrypted transaction. The number should be authenticated. [0064]

Moreover, the charge card reader does not need to be changed at all. Instead, the credit clearance center software is modified to authenticate the encrypted transaction number using the user's public key obtained from a trusted third party. The charge card reader reads all the data from the charge card or emulation card and sends all the information verbatim to the credit clearance center for approval. By this method, the present embodiment minimizes changes to the existing charge card infrastructure (ie, with only one credit clearance center rather than millions of existing charge card readers). Changes are needed). [0065]

If additional security is desired, the user keys the transaction volume and transaction time into PECAD. These data should also be encrypted using the user's private key, written to the emulation card received by the charge card reader, and re-obtained at the credit clearance center from a trusted third party. It is decrypted using the key. In this case, the transaction is the amount indicated by the amount of encrypted transactions received, or the transaction occurs within a given period of the encrypted and received transaction (pre-written from PECAD to the emulation card). Approval is given to the transaction only if it is done. Therefore, even if the emulation card is stolen, and it does not cause the emulation card to be erased or rebuilt, it will not be useful for another transaction that follows. [0066]

In an Internet transaction, a user can approve a transaction using PEAD or PECAD by encrypting the amount approved by the user by using the user's own private key stored in PEAD or PECAD. The user can then make a copy of the encrypted information displayed on the PEAD display 610 or PECAD display 1002 for the Internet by keying in the information from the keyboard. The encrypted information displayed on the PEAD display 610 and PECAD display 1002 is in a readable format such as an alphanumeric string, which can be easily read by the user and easily connected to a computer connected via the Internet ( It is desirable to be able to handle Internet transactions by manual input (for example, by keystrokes or speech commands). To handle Internet transactions securely, credit card numbers can be encrypted along with transaction information using PEAD or PECAD if necessary. Of course, by replacing the manual and keystroke techniques that are desirable for backward compatibility with other data entry methods, such as wireless or infrared communication over the appropriate port of a computer or PECAD (or PEAD), to the Internet. Data can be sent. [0067]

As mentioned above, it is desirable that the user's identity is reliably authenticated using the user public key held by a trusted third party. A trusted third party is, for example, an entity that the general public can greatly trust, such as a well-known organization that has a selfish desire to receive a reputation for being credible. This includes, for example, government agencies, banks and large corporations. The trusted person maintains the PECAD public key directory service associated with the user public key list provided to the manufacturer. Once the user first acquires PECAD (eg, through issuance or purchase by the issuer), the user can register ownership of PECAD with a trusted third party. Through the complete registration process, users are assigned a confirmation level. This indicates the degree of credibility that the person who completed the registration is the person. [0068]

As an example, a PECAD serial number / public key signature (a unique set of numbers assigned by the manufacturer to a particular PECAD that can be read from the PECAD by pressing the specified set of keys). The user can easily register the personal information such as the attached social insurance number, home address and telephone number by sending it by e-mail, telephone or ordinary mail. Next, the PECAD public key directory center searches the public key in the database using the PECAD serial number provided by the user as a unique search ID. Once the public key is found, it validates the public key in the database using the public key signature provided by the user. If the verification is successful, the user is registered. Otherwise, the user will be denied. The public key should be unique. [0069]

Here's a safer way to register user ownership (this process usually happens at the place where you buy PECAD / PEAD and where the issuer is, for example, at a bank). First, the issuer activates PEAD / PECAD with the password provided by the manufacturer. PEAD / PECAD users can then use user passwords and other authentication mechanisms to change the password provided by the manufacturer. The user can then instruct PEAD / PECAD to generate a new pair of private / public keys (called user private key and user public key) in PEAD / PECAD internally. In addition, personal information (social security information, home address, etc.) and the private key stored in advance in PEAD / PECAD to generate the user registration message and provided by the manufacturer are used to obtain the public key of the new user. The user can instruct PEAD / PECAD to encrypt. During the manufacture of PEAD / PECAD, PEAD / PECAD may generate a pair of private / public keys provided by this manufacturer. [0070]

The issuer then uses the public key of the public key directory service center to encrypt the PEAD / PECAD serial number and user registration message. This allows the registration message to be generated and sent to the public key directory service center. Upon receiving the registration message, the public key directory service center uses its own private key to decrypt the registration message. The public key directory service center then uses the PEAD / PECAD serial number to search the database for the public key provided by the manufacturer. Upon successful decryption, the public key provided by the manufacturer in the directory service database is updated with the new user public key, the personal information in the directory service database is updated, and for future reference, for example, the personal name. Generate a public key ID using the least significant 32 bits (or 64 bits) of your phone number or public key. On the other hand, if the decryption fails, the user is rejected. [0071]

This registration process generally corresponds to a low level of confirmation. This is because someone other than the user fraudulently obtains the user's personal information in order to register ownership (and to force the user to fraudulently pay the fee after registration is complete and PECAD is activated). Because it can be done. In addition to the information provided when the low confirmation level is obtained, the intermediate confirmation level can be obtained by providing highly reliable information that can surely identify the person who provided the information. Examples of additional information include photographs, signatures, notary seals, and combinations thereof. A high level of confirmation can be obtained by providing more reliable information that ensures that the person who provided the information is who they say they are. As an example, the registrant goes to the PECAD Public Key Directory Center and presents photographs, signatures, biometric samples (such as fingerprints, retinal scans, DNA prints, etc.) and combinations thereof. [0072]

Once registered, the credit clearance center or vendor can look up the PECAD public key directory by a trusted third party to authenticate the user and approve the transaction. The PECAD public key directory can also be improved, for example, by establishing insurance policies to protect vendors and credit clearance centers from financial losses due to fraud resulting from incomplete registration processes. The coverage of insurance contracts varies depending on the level of confirmation, but the higher level of confirmation is eligible for a higher amount of compensation. [0073]

Although the present invention has been described based on some preferred embodiments, there are modifications, substitutions and equivalents within the scope of the invention. Also note that there are many other methods for implementing the methods and devices of the present invention. Transaction approval has been described here as an example, but when it is preferred for users to securely send data to an electronic transaction system, it is for those skilled in the art to use PEAD to handle transactions related to the electronic transaction system. It's obvious. For example, PEAD is used to log in to highly sensitive computer systems and devices. When used in this way, the computer terminal with which PEAD communicates incorporates an infrared port, a magnetic reader port, and a contact plug for communicating with PEAD. The user can then use PEAD to perform an online authentication task. [0074]

In yet another example, PEAD can be leveraged to "sign" a computer file for authentication (eg, to authenticate a date or user). The transaction authorization data is then stored with the file to be authenticated for future reference. It should be noted that even if the user private key is used, unencrypted transaction authentication data is not officially accepted, so unauthorized opening of the transaction authentication data is prevented. Further, when PEAD is used to approve only a predetermined transaction, it is clear that the PEAD does not need to receive it from the outside because the transaction data is stored in the PEAD in advance. Therefore, the following appended claims should be construed as including all modifications, substitutions, equivalents, etc. within the spirit and scope of the invention.

[Simple explanation of drawings]

[Figure 1]

Figure 1 shows a prior art electronic transaction system that includes an automated teller machine (ATM) for ease of discussion. [Figure 2]

FIG. 2 shows a portable electronic authentication device (PEAD) according to an embodiment of the present invention, which is a device for securely approving transactions handled with respect to an electronic transaction system. [Fig. 3]

FIG. 3A is a schematic view of the PEAD of FIG. 2 according to an embodiment of the present invention. [Fig. 4]

FIG. 3B shows a typical transaction approval data format according to an embodiment of the present invention. [Fig. 5]

FIG. 4 shows a logical block diagram of PEAD according to an embodiment of the present invention. [Fig. 6]

FIG. 5A shows a high level of hardware that implements PEAD according to an embodiment of the present invention. [Fig. 7]

FIG. 5B shows an example of PEAD in which the circuit of PEAD is realized on an IC. [Fig. 8]

FIG. 5C shows the appearance of the PEAD of FIG. 5B after it is incorporated into a card-type package. [Fig. 9]

FIG. 6A shows an external view of PEAD according to a preferred embodiment of the present invention. [Fig. 10]

FIG. 6B briefly illustrates the hardware of one aspect of the invention that implements the PEAD of FIG. 6A. [Fig. 11]

FIG. 7 is a flowchart showing an approval technique of one aspect of the present invention using PEAD of the present invention. [Fig. 12]

FIG. 8 is a flowchart of one aspect of the present invention showing a process relating to encryption of transaction authentication data using public key cryptography technology. [Fig. 13]

FIG. 9 is a schematic block diagram of a portable electronic billing / authentication device (PECAD) according to an aspect of the present invention. [Fig. 14]

FIG. 10 is a schematic view of PEACAD in which an emulation card according to a preferred embodiment of the present invention is arranged. [Fig. 15]

FIG. 11 is a concise flowchart of an embodiment showing how transaction numbers are used with a PECAD system to improve transaction security.