SYSTEM AND METHOD FORAUTHENTICATION OVERAPUBLIC
NETWORK
1. Field.
The present invention relates to the field of data security. In particular, this invention relates to a system and method for securing electronic commerce over a public network.
2. General Background
Over the last few years, personal and commercial usage of public networks has increased dramatically. One type of public network is the "Internet," an enormous compilation of publicly accessible networks situated throughout the world. Due to its growing acceptance, the Internet is quickly becoming a worldwide marketplace for products and services. For electronic commerce (e- commercc) to fully evolve, customers need access to information about the products or services being sold by a particular merchant. Also> it is important to the public at large that e-commerce implements a secure, on-line credit card payment system to avoid the perpetuation of fraud.
Recently, CyberCash, Inc. of Reston, Virginia has developed an electronic commerce payment system involving the use of an electronic wallet. An "electronic wallet" is a file stored on a hard drive of the owner of the wallet. The contents of an electronic wallet typically include sensitive information about the owner such as, for example, his or her social security number, drivers license number, credit card information (e.g., credit card number, expiration date, what financial institution issued the credit card, etc.) and the like. When purchasing a product over the Internet, the sensitive information is provided to a merchant. Thereafter, the merchant submits the credit card number and payment sum for authorization. This type of on-line electronic commerce payment system realizes a number of disadvantages.
For normal credit card payment systems, banks tend to assume a substantial amount of financial risk associated with the misuse of their issued credit cards, provided standard card verification procedures have been followed by the merchant. Normally, the card verification procedure requires the merchants to perform the following tasks: (i) verifying the identity of a credit card holder by comparing the signature on the back of the credit card with the signed charge receipt, and (ii) obtaining authorization from a payment processing system to indicate that the customer has sufficient credit before releasing the goods to the customer. Unfortunately, for e-commerce in general, a merchant cannot verify the
identity of the credit card holder because physical examination of the customer's credit card is not feasible.
If the financial risk of fraud is placed on the merchants, e-commerce will not increase in popularity because many merchants cannot assume such risk due to their limited financial resources. However, it is doubtful that banks will voluntarily assume the risk, especially when the digital content of electronic wallets is widely accessible in a plain text format. Hence, it would be desirable to develop an e-commerce authentication protocol for verifying the identity of a customer with information known only by the customer and not stored in an accessible medium.
Another general disadvantage associated with e-commerce is that electronic wallets are not portable. Rather, electronic wallets are exclusively assigned to the hard drive of the owner's computer. It would be desirable to develop a secure e- commerce network that allows a customer to conduct e-commerce transactions securely on other computers, besides his or her own computer.
Yet another disadvantage associated with conventional e-commerce authentication protocols, for each e-commerce transaction, the sensitive information is provided to a merchant. As a result, there is a greater susceptibility of fraud by merchants. It would be desirable to download sensitive information to a trusted electronic system which, in turn, would indicate to a merchant whether or not an e-commerce transaction (e.g., on-line purchase) has been authorized.
SUMMARY
Briefly, in one embodiment, the present invention relates to a method for increasing security of electronic commerce transactions over a public network between a first electronic system controlled by a customer and a second electronic system. With respect to a chosen authentication protocol, a challenge message is provided from the second electronic system to the first electronic system. The challenge message includes at least (i) a sequence number, (ii) a one-time pad (OTP) seed value, and (iii) a hash value based on the sequence number, the OTP seed value, an OTP key and a shared secret.
Upon receiving the challenge message, the first electronic system computes an OTP key and a shared secret. The OTP key based on the sequence number, the OTP seed value and a first segment of the electronic password entered by the customer. The shared secret is based on a second segment of the
cntcrod electronic password and a segment of an electronic personal identification generated by the second electronic system and associated with the customer.
Also, the first electronic system also computes a hash value based on (i) the sequence number, (ii) the OTP seed value, (iii) the computed OTP key and (iv) the computed shared secret. This hash value is used to authenticate the second electronic system by determining that the hash value matches the hash value of the challenge message.
Other aspects and features of the invention will become apparent to those of ordinary skill in that the art upon review of the following description of embodiments of the invention in conjunction with the accompanying figures.
BRTF.F DF.SCRTPTTΩN OF THE DRAWINGS
The features and advantages of the present invention will become apparent from the following detailed description of the present invention in which:
Figure I is a block diagram of an illustrative embodiment of a secure e- commerce network is shown.
Figure 2 is a flowchart of an illustrative embodiment of the registration scheme to support the authentication protocol of the network of Figure 1.
Figure 3 is a flowchart of an illustrative embodiment of a registration window displayable at the customer.
Figure 4 is a block diagram of an illustrative embodiment of the operations of the OTP function during registration.
Figure 5 is a block diagram of an illustrative embodiment of the operations of the OTP functions at registration.
Figure 6 is a block diagram of an illustrative embodiment of the authentication protocol during a transaction.
Figures 7A and 7B are flowcharts of an illustrative embodiment of the authentication protocol.
Figure 8 is a block diagram of an illustrative embodiment of a purchase verification window at the customer during authentication.
DRTATT.F.n r>P.srRTPTT N Certain embodiments of the invention are described to provide a system and method for increasing security of electronic commerce (e-commerce) transactions over a public network. The term "secure" indicates that it is virtually infeasible for an unauthorized individual to successfully perpetuate fraud by tampering with
transmitted information without detection. Herein, examples of system architecture and protocols for registration and authentication of a customer and service provider are described. These examples should be broadly construed as illustrative in nature in order to represent the spirit of the invention.
Certain terminology is used to describe various embodiments of the system architecture, For example, an "electronic system" is broadly defined as hardware capable of processing information and accessing a public network. Each electronic system includes, but is not limited or restricted to a computer (e.g., a laptop, desktop, hand-held, server, mainframe, etc.), imaging equipment (e.g., printer, facsimile machine, etc.), a set-top box, network routing equipment and the like. The electronic systems are coupled together by a public network (e.g., a wide area network "WAN", a local area network "LAN", etc.) which has one or more communication links through which information can be routed. These communication links can be established by any type of medium such as Plain Old Telephone System (POTS) lines, cable lines, leased lines, optical fiber, electrical wire, or even wireless communication channels.
Other terminology is used to describe various aspects of the authentication protocol and the use thereof. For example, ''information" includes one or more bits of data, address, control signals or any combination thereof. "Charge card information" includes one or more of the following: credit card numbers, debit card numbers, expiration date, name of the issuing financial institution, billing information concerning the credit card holder, etc. A "transaction" includes the purchase or rental of a product based on credit or an outstanding monetary balance on an account. Another examples of transactions include access requests to information stored at a web site accessible only to pre-paid members.
An "entity" includes a business, individual, partnership or other group of individuals. A "merchant" includes an entity (or hardware or software of an electronic system acting on behalf of the entity) in the business of selling goods and/or services. A "customer" includes an entity (or hardware or software of an electronic system acting on behalf of the entity) concerned with an on-line purchase from a merchant. A "service provider" includes an entity (or hardware or software of an electronic system acting on behalf of the entity) responsible for authorizing a transaction by a customer.
A. SYSTEM ARCHITECTURE (HARDWARE)
Referring now to Figure 1, an illustrative embodiment of a secure e- commerce network 100 is shown. Network 100 comprises a plurality of electronic
systems logically coupled together through a public network 110 such as the Internet for example. As shown, these electronic systems include a first electronic system (customer) 120, a second electronic system (merchant) 130 and a third electronic system (service provider) 140.
Herein, customer 120 establishes a logical connection with merchant 130 over public network 110, Normally, the logical connection is established through an Internet Service Provider (ISP) as shown by dashed lines, Customer 120 may directly access a web page produced by merchant 130 and retrieve digital advertisements therefrom. These advertisements include pictures and/or descriptions of products or services offered for sale or lease. Also, in lieu of directly accessing web pages of merchant 130, customer 120 may directly access one or more Uniform Resource Locators (URLs) associated with sponsored merchants that are displayed on a web page produced by service provider 140.
Additionally, first electronic system associated with customer 120 includes a One-Time Pad (OTP) function stored in memory. In general, during operation, the OTP function performs logical operations (e.g., exclusive OR "XOR" operations) on input information loaded into the OTP function. In particular, for this embodiment, the input information is bitwise XOR'ed with a predetermined reference, namely a sequence of bits referred to as a "OTP seed". As a result, the OTP function protects the integrity and confidentiality of input information in order to enhance security.
In this embodiment, the third electronic system associated with service provider 140 includes memory loaded with communication software (e.g., a browser), encryption/decryption software, and the OTP function. Also, service provider 140 is in communication with a remote, independent payment processing system 150 through dedicated communication links (e.g., secure leased lines) 160. Payment processing system 150 includes a database controlled by a financial institution or an agent for the financial institution responsible for authorizing debits or credits against a charge card. It is contemplated, however, that the credit/debit authorization may be performed by service provider 140 instead of being performed by a separate payment processing system 150. For example, this can be accomplished by caching invalid credit card numbers and periodically accessing payment processing system 150 for an updated listing of invalid credit card numbers,
The above-identified architecture supports a web-based, authentication protocol designed to facilitate secure on-line transactions. This authentication
protocol is a combination of "shared secret" authentication and a unique electronic transaction tag using an OTP function to validate a customer transaction. Thus, service provider 140 confirms (and perhaps determines) the approval or denial of the transaction. By securely storing all customer transaction information, service provider 140 is capable of authenticating customers and verifying transactions in order to reduce the number of "charge backs" that are common to mail order/telephone order transactions.
B. AUTHENΉCAΉON PROTOCOL - REGISTRATION
Referring to Figure 2, a flowchart of an illustrative embodiment of a registration scheme for the authentication protocol is shown, Upon completion of the registration scheme, one or more database records for the newly registered customer are created and stored by service provider 140 of Figure 1.
As shown in block 200 of Figure 2, during registration, a customer establishes a secure logical connection (e.g., a Transmission Control Protocol/Internet Protocol 'TCP/IP" connection) with the service provider of Figure 1 , After establishing a secure connection, the customer prompts the service provider to transfer an applet (block 210). In one embodiment, for example, the customer selects an ActiveX-controlled object on a publicly accessible web page produced by the service provider. "ActiveX" is a library provided by Microsoft Corporation of Redmond, Washington.
Upon execution, the applet produces a sequence of events (block 220). For example, one event involves the display of a registration window 300 as shown in Figure 3. Registration window 300 includes a plurality of fields of which the contents entered into these fields are provided to the service provider. In this embodiment, the plurality of fields includes a customer information field 310, a charge field 320 and a pass-phrase field 330.
As shown in Figure 3, customer information field 310 includes billing information such as a list of namc(s) and address(es) of the person or persons authorized to use the charge card(s) listed in charge field 320. Charge field 320 includes charge card information such as, for example, at least one charge card account number, the type of charge card (e.g., VISA®, Mastercard®, Discover®, American Express®, debit card from a certain financial institution, etc), and/or the expiration date of the charge card. It is contemplated that charge field 320 may include an account routing number for a cash balance retained at a bank or by the authorization system. Pass-phrase field 330 receives, a string of alphanumeric characters (referred to as "psygnature pass-phrase") as input,
Referring back to Figure 2, a segment (e.g., a portion, rearrangement of the current content, etc.) of the psygnature pass-phrase is used for customer authentication as described in Figures 4-7. During transmission to the service provider, the billing information, credit card information and the psygnature pass- phrase are encrypted in accordance with secure socket layer (SSL) encryption protocol before transmission to the service provider (block 230). Upon receipt by the service provider, both the billing information and charge card information provided by the customer are stored into a database entry (block 240). An account number (referred to as an electronic personal identification number "ePin") is assigned to the customer and subsequently provided to the customer electronically or by mail (block 250). A segment of the ePin, referred to as an "OTP_ID," operates as an index for the database entry assigned to the customer.
While the billing information and charge card information are stored by the service provider's database, the psygnature pass-phrase is not stored anywhere in the database for enhanced security. Instead, as described below, a segment of the psygnature pass-phrase (referred to as a "OTP pass-phrase") and an OTP seed (possibly being some segment or version of the ePin) are loaded into an OTP function. In one embodiment, the OTP pass-phrase is a remainder of the psygnature pass-phrase after removal of the OTP_ID. The OTP function undergoes N iterative operations, where intermediary results are reloaded in lieu of the OTP pass-phrase to produce an OTP key, where "N" is equal to a predetermined initial sequence number (block 260). The OTP key is stored in the database entry of the service provider (block 270).
Referring now to Figure 4, a block diagram of an illustrative embodiment of the operations of the OTP function during registration is shown. To produce the OTP key, the OTP function at the service provider receives as input three sources of information, namely the OTP pass-phrase, an OTP seed and a sequence number (blocks 410 and 420). These input sources are computed from values provided by the customer (e.g., psygnature pass-phrase) or generated by the service provider (e.g., ePin). In this embodiment, the "OTP pass-phrase" is a predetermined segment of the psygnature pass-phrase that is provided by the customer during registration. The "OTP seed" is a random series of alphanumeric characters. For example, a selected series of characters associated with the ePin may be used. Of course, other variations of the ePin or data produced in a random or pseudo-random fashion may be used. In this embodiment, the series has a maximum length of 16 bits. The "sequence number" is a number that is
decremcnted each time there is a successful authentication, Also, the sequence number determines the number of iterations performed by the OTP function on the input sources OTP pass-phrase and OTP seed (blocks 430, 440 and 450). The final result is equal to the OTP key (block 460). Therefore, the initial starting number should be high enough to support a "maximum" number of transactions prior to a changing the OTP pass-phrase, which resets the sequence number to its default (initial) value.
Also, to reduce the likelihood of successful simulation of the service provider to trick the customer in providing confidential information, selected data is held in secret and known only by the service provider and the customer. This "shared secret" is refrained from being transmitted over the network; instead, only computations based on its value are exchanged. The shared secret is computed from predetermined segments of both the psygnature pass-phrase (provided by the customer during registration) and the ePin (generated by the service provider during registration). The shared secret is also transparently added as part of the shopper's identity at the time of registration.
For example, as shown in Figure 5, assume that the shared secret is computed by removing the 4Λ through 7fe digits 510 of the generated 16-digit ePin (account number) 500 and the first 3 characters of every 12 characters entered by the customer for psygnature pass-phrase 520. For example, if ePin 500 is produced as "1234567890123456", the value "123890123456" (OTP_ID) 530 would be used for account identification and "4567" (SS_Pin) 510 would be available for the shared secret and, therefore, not transmitted. If psygnature pass- phrase 520 is selected by the customer to be "this is a very long password, really it is", the resultant OTP pass-phrase 540 would be "s is a velong passd" and the string "thiry wor" (SS_Pass) 550 would be used for the shared secret.
As a result, SS_Pin 510 and SS_Pass 550 are removed and combined in accordance with a selected combination (e.g., concatenation, modulo addition, etc.) 560 to produce shared secret 570. The remainder of ePin 500 and psygnature pass-phrase 520, namely OTP_ID 530 and OTP pass-phrase 540 are used for addressing and production of the OTP key, respectively.
Additionally, as an option, the customer may be prompted to select an image from a list of images stored at the service provider. Upon selection of an image by the customer, during each transaction, the image is transferred to the customer for display on a purchase verification window. This prohibits Trojan horse attacks.
C. AUTHENTICATION PROTOCOL - TRANSACTIONS
Referring now to Figures 6, 7A and 7B, a block diagram and flowcharts of an embodiment of the authentication protocol followed during a transaction are shown. The authentication protocol is initially performed over a TCP/IP connection established between customer 120 and service provider 140. Prior to these operations, customer 120 has followed the registration scheme as described above. Also, customer 120 has selected different goods and/or services to purchase through the use of a well-known shopping cart application and has selected a payment object supplied by the merchant's web page. This establishes the TCP IP connection with service provider 140 (block 700).
Once the TCP/IP connection is established, customer 120 enters his or her ePin and the psygnature pass-phrase into an appropriate field of a purchasing window and selects an A-OK button (block 705). As an option, both customer 120 and service provider 140 exchange sequences of random information 600 and 605 in order to reduce the threat of attack. In particular, service provider 140 internally generates and transmits a first sequence of random data (Ra) 600 to customer 120 (block 710). Customer 120 responds by sending OTP_ID 610 along with a second sequence of random data (Rb) 605 generated by customer 120 (block 715). OTP_ID 610 operates as an index to access a database entry associated with customer 120.
Thereafter, service provider 140 begins authentication of customer 120 by first detecting if OPT_ID 610 is invalid (block 720). This can be accomplished by searching through a number of list of indices associated with a look-up table for example. If OTP_ID 610 is invalid, random data is returned to customer 120 so that additional resources are required of an attacker (block 725), If OTP_ID 610 is valid, service provider 140 transmits a challenge message 615 back to customer 120 as shown in Figure 6 (block 730). "Challenge message" 615 contains a current sequence number (N) 620 stored in the database entry, an OTP seed value (OSV) 625 (perhaps a segment of the ePin used in the initial computation of the OTP key), customer specific data (UD) 630 such as an assigned image selected by the customer during registration, for example, and a hash value 635. Hash value 635 is the result produced by a hash function on a combination of sequence number (N) 620, OTP seed value (OSV) 625, customer specific data (UD) 630, a current OTP key computed by service provider 140 (OK) 640, shared secret (SS) 645 and optionally first and second random data sequences (Ra and Rb) 600 and 605.
Upon receiving challenge message 615, customer 120 computes a shared secret 650 based on a hash value of selected segments (SS_Pass, SS_Pin) of customer entered psygnature pass-phrase 655 and ePin 660 (block 735). Also, an OTP key 665 is computed based on contents (OTP pass-phrase) of the customer entered psygnature pass-phrase 655, sequence number 620 and OTP seed value 625 (block 740). Customer 120 combines the provided sequence number (N) 620, OTP seed value (OSV) 625, customer specific data (UD) 630 with computed OTP key 665 and shared secret 660 to produce a check result 670 (block 745). Check result 670 undergoes a hash operation to compute a hash value 675, which is compared to hash value 635 (blocks 750 and 755). If hash values 635 and 675 do not match, the transaction ceases because the data has been modified and or service provider 140 is not authenticated (block 760).
If hash values 635 and 675 compare, the current sequence number 620 is decremented (N-l) as shown in block 765. Also, the following items are displayed on a purchase verification window as shown in Figure 8. For example, the total purchase amount is displayed in a first field 800 while an image is displayed in a second field 810, The customer can visually check that the image is represented in second field 810 matches the registered image, If the image is different, the customer knows not to proceed with the transaction.
Referring back to Figures 6 and 7, in the event that the image is identical to the registered image and the total purchase amount is correct, the customer selects an A-OK button 820 (see Figure 8) as shown in blocks 770 and 775, Initially, this prompts the OTP function at customer 120 to produce a new OTP key (NOK) 680 based on N-l iterations of OTP pass-phrase 661 and OTP seed value 625 (block 780). A message including new OTP key 680 and purchase amount (AMT) 685 is provided to service provider 140. Additionally, a hash value 690 featuring new OTP key 680, AMT 685, shared secret 665 and optionally random data sequences 600 and 605 is produced to verify that the sequence number and OTP seed have not been tampered with and that service provider 140 knows the shared secret information (block 785).
The message is validated by applying one extra iteration of the OTP function on new OTP key 680 to produce result 695. Result 695 is compared with the stored (current) OTP key 640 (block 790). If result 695 matches stored OTP key 640, the shopper can continue (block 791). Otherwise, service provider 140 ceases the transaction and sends a "Failure" message and customer 120 responds accordingly (block 792).
If the newly computed OTP key 680 matches OTP key 640 stored in the database, the database is updated with this new OTP key 680 and decrements the sequence number for the next transaction. Customer 120 and service provider 140 will now receive different keys for the next authentication, The sequence number is decremented so hackers cannot compute sequences given historical data,
The entire communications between customer and service provider are protected by secure socket (SSL) encryption/decryption.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art. Rather, the invention should be construed from the following claims.