+

WO2006015052A1 - Procede de protection de donnees electroniques stockees sur une carte de credit - Google Patents

Procede de protection de donnees electroniques stockees sur une carte de credit Download PDF

Info

Publication number
WO2006015052A1
WO2006015052A1 PCT/US2005/026653 US2005026653W WO2006015052A1 WO 2006015052 A1 WO2006015052 A1 WO 2006015052A1 US 2005026653 W US2005026653 W US 2005026653W WO 2006015052 A1 WO2006015052 A1 WO 2006015052A1
Authority
WO
WIPO (PCT)
Prior art keywords
record
secured
information
private
merchant
Prior art date
Application number
PCT/US2005/026653
Other languages
English (en)
Inventor
Timothy G. Endres
Mark H. Schwartz
Original Assignee
Mandala Sciences, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mandala Sciences, Inc. filed Critical Mandala Sciences, Inc.
Publication of WO2006015052A1 publication Critical patent/WO2006015052A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/88—Detecting or preventing theft or loss
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135—Metering

Definitions

  • the present invention relates to systems and methods for facilitating online commerce over public networks (such as the Internet) using credit cards, debits cards, and other types of cards or cash equivalents used for commerce. More specifically, this invention relates to the problem of merchants storing sensitive account information that is subject to theft and misuse. The invention eliminates the problem by encrypting the sensitive information, tying the information to a specific vendor, and constraining the uses of the information.
  • the HTTPS protocol is designed to secure the information provided by a customer to a merchant when that information is transmitted over a public network such as the Internet.
  • the HTTPS protocol also provides for the use of Digital Public Key technology to verify that the computer systems that the customer is communicating with are indeed those of the merchant with whom they believe they are transacting business.
  • This invention discloses a simple technique for storing sensitive credit card information, along with usage constraints, in a data record that renders the record effectively unusable to anyone who might attempt to steal the record.
  • the method uses existing technologies, requires only minimal modifications to existing merchant and transaction processor systems, and requires no changes to existing networks and network protocols between merchant and customer.
  • This application claims the benefit of Provisional Patent Application Serial No. 60592586 filed on July 30, 2004.
  • This invention concerns a method for securing sensitive information that is stored by a merchant for the purposes of single and/or recurring commerce transactions.
  • the sensitive information usually consists of a sixteen digit credit or debit card number, the card's expiration date, and the card's three or four digit security code, but may consist of any information that should not be visible to anyone except the transaction processor.
  • the sensitive information could consist of a social security number that should be kept secret, to be accessed only by an appropriate governmental agency.
  • a "secured record” is defined.
  • This special record hereafter also known as “the secured record” is defined to consist of two critical parts or sections, the public part and the private part. The public part consists of information that is visible and intelligible to anyone who possesses the record.
  • the private part consists of information that is also visible to anyone, but is encrypted using the public key of a key pair and is thus unintelligible to anyone except the owner of the private key that corresponds to the public key used to encrypt the information.
  • the key pairs can be assigned on a per-merchant basis in order to minimize revocation and expiration costs.
  • a checksum of the entire record is included in the private part of the record, allowing for the verification of the record's contents at processing time.
  • the merchant is required to modify the task flow of their automated processing systems.
  • the merchant will use a function implemented in a software library to create the secured record, and they will need to store the secured record in place of the sensitive information. Since the sensitive information typically includes a sixteen digit card number, the merchant can compute an internal lookup key that is placed into the existing card number field, and then use this lookup key to retrieve the secured record from a separate storage location, minimizing the changes required to support the new secured record.
  • the merchant then uses a secured charge record, which is based upon the new secured record, to submit future charge requests.
  • the transaction processor is required to modify the task flow of their automated processing systems to accommodate the secured charge record, which is based upon the new secured record.
  • the record shall be transmitted directly to the processor.
  • the processor will then use their private key to decrypt the private part of the secured record once it is extracted from the secured charge record.
  • the processor will then use the checksum retrieved from the decrypted private section to verify the integrity of the secured record. Once the record is verified, the processor will apply filters based on the constraints that are defined by the secured record, such as confirming the merchant submitting the transaction, and the amount and frequency of the transaction.
  • the processor will retrieve from the private section the credit card information needed to continue processing of the transaction using the existing prior art procedures.
  • a proxy number may be used to stand in for the secured record.
  • the transaction processor will issue a number that looks exactly like a number normally issued by the processor (for example, sixteen digit credit card numbers), which by definition will work with existing protocols and systems.
  • the number will be a proxy for the secured record which is stored with the transaction processor, and will be acceptable for payment as if it were a standard credit or debit card number.
  • the proxy number when received by a transaction processor, will then be used to retrieve the corresponding secured record, which is then processed to complete the transaction.
  • the proxy number is issued to represent a secured record, as opposed to being issued on a per transaction basis, the proxy number can be reused. It can also be stored using existing systems designed for credit card numbers, as it is indistinguishable from a normal processor number such as a credit card number. Furthermore, customers can be issued physical cards containing the proxy number, just as they are issued standard credit cards today, allowing their use at physical credit card points of sale just as if they were standard credit cards. Thus, merchants with both a physical storefront, as well as an online presence, could issue a proxy number electronically via email, as well as issue a physical credit card with the proxy number. The physical card could even be printed directly from a web page.
  • the transaction processor will decrypt the private section of the secured record, validate the record integrity using the checksum from the private section, and validate the transaction constraints. If all of the validations pass, then the credit card information contained in the secured record is accepted and used to complete the transaction using existing processing methods. Otherwise the charge is rejected.
  • the transaction processor can provide the required public key via the Internet using a number of well established methods.
  • the public key could even be delivered via post on a floppy disk or CD.
  • public/private key pairs will be assigned on a per-merchant basis, although this is not a requirement.
  • the processor can also provide software libraries and/or program source code to facilitate the retrieval of their public key, the creation of the secured records, and the transmission of the secured charge records.
  • This computer software allows the merchants to integrate the secured record creation and transmission procedures anywhere within their existing processing pipeline.
  • the processor could provide a web service, or any other digital service, for secured record creation and distribution. Using such a system, the merchant could deliver to the processor all necessary information via a secure connection, such as HTTPS, and receive back a secured record for storage and future use.
  • the transaction processor could provide software which would allow the customer to generate the secured record locally on the customer's computer before it is transmitted to a merchant or the processor. Thus it is protected from compromise before the secured record information leaves the customer's computer.
  • the huge numbers of credit card records currently existing in merchant databases can be protected by a batch process that will create the secured records for all existing customer records, and then delete the stored sensitive credit card information. Furthermore, this process of conversion can be done in a piecewise fashion, across both merchants and processors, allowing for a staged, orderly transition from current practices to the invention method.
  • the only modifications to the existing transaction model are: 1 ) the merchant must add the ability to generate or retrieve the secured record, store the secured record if needed, and submit charges using the secured charge record; 2) the protocol between the merchant and transaction processor must accommodate transmission of the secured charge record in each transaction; and 3) the transaction processor must add the ability to validate the secured record and to extract the sensitive credit card information for further processing.
  • the transaction processor In the case of using a proxy number, the transaction processor must be capable of generating secured records, storing secured records, associating the secured record to a proxy number, issuing the proxy number to clients, recognizing the proxy number in transactions, retrieving the secured record that the proxy number represents, and validating and extracting the credit card information from the secured record.
  • each private section is encrypted with a different public key corresponding to the different clearing entities.
  • the stored checksum is computed over the header (if used), the public section, and only the private section being defined.
  • each private section has its own checksum of the public section and itself, allowing each clearing entity to verify and process the record without any regard for the other private sections.
  • FIG. 1 shows a general overview of the method to secure credit card transactions and information in accordance with the present invention.
  • Fig. 2 shows a general representation of the structure of the secured record defined by the present invention.
  • Fig. 3-A shows a sample summary of the fields of the public section of the secured record.
  • Fig. 3-B shows an embodiment in XML of an example of the public section of the secured record.
  • Fig. 4-A shows a sample summary of the fields of the private section of the secured record.
  • Fig. 4-B shows an embodiment in XML of an example for the private section of the secured record.
  • Fig. 5 shows the process flow diagram for the customer registration process as employed in electronic Internet commerce as conducted by customers and merchants in prior art.
  • Fig. 6 shows the process flow diagram for the purchase process as employed in electronic Internet commerce as conducted by customers, merchants, and transaction processors in prior art.
  • Fig. 7 shows the process flow diagram for the customer registration process as employed in electronic Internet commerce as conducted by merchants and customers in accordance with the present invention.
  • Fig. 8 shows the process flow diagram for the purchase process as employed in electronic Internet commerce as conducted by customers, merchants, and transaction processors in accordance with the present invention.
  • Fig. 9 shows an overview of the process flow diagram for the payment process as employed in electronic Internet commerce as conducted by merchants and transaction processors in accordance with the present invention.
  • Fig. 10-A shows a flow diagram to process open charge records in implementation of the payment process in accordance with the present invention.
  • Fig. 10-B shows a flow diagram to process secured charge records in implementation of the payment process in accordance with the present invention.
  • Fig. 10-C shows a process flow diagram to process secured charge records using a single use secured record in implementation of the payment process in accordance with the present invention.
  • Fig. 11 shows the process flow diagram for the method to generate secured records in accordance with the present invention.
  • Fig. 12 shows the process flow diagram for the method to decrypt and validate secured records in accordance with the present invention.
  • Fig. 13 shows the detail of the process flow diagram for the method to extract credit card information from the secured records in accordance with the present invention.
  • Fig. 14 shows the process flow diagram for the method to use a proxy number for an online transaction in accordance with the present invention.
  • Fig. 15 shows the general structure of the key revocation process for updating all secured records with a new public key in accordance with the present invention.
  • Registration Process - Invention 410 Generate Secured Record
  • the invention includes elements for (1) security - as provided by the encryption of the private section containing the sensitive information; (2) integrity - as provided by the calculation of a checksum of the record contents to verify that the contents have not been modified and to inextricably link the public and the private sections of the record; (3) constraint - as provided by tying the record to a merchant or merchants, as well as various usage constraints as defined in the public and private sections of the record.
  • the invention combines these elements to provide both a secured transaction method and a secured record structure which meet the objectives to permit no modification or loss of data, to allow access to the sensitive information only on a need to know basis, to protect transmittal of the purchase transaction information between a merchant and their transaction processor, and to render the sensitive information safe for storage in a merchant or transaction processor database.
  • the essential elements of the general secured record 100 definition include the following: 1) a flexible record definition which allows for multiple data representations (e.g. UNICODE text, and binary data), as well as the ability to modify the elements of the record definition without invalidating existing records (also known as backwards compatible extensions); 2) said public section 120 which may be read by anyone who has access to the secured record 100; 3) said private section 130 which can only be read by the party who possesses the private key 22 which corresponds to the public key 20 used to encrypt the data in the private section 130; 4) said checksum 140 in the private section 130 which can be used to validate the integrity of the record.
  • a flexible record definition which allows for multiple data representations (e.g. UNICODE text, and binary data), as well as the ability to modify the elements of the record definition without invalidating existing records (also known as backwards compatible extensions)
  • said public section 120 which may be read by anyone who has access to the secured record 100
  • said private section 130 which can only be read by the party who possesses the private key 22 which corresponds
  • the flexible definition for the secured record 100 provides for the other essential elements.
  • the public section 120 is necessary to make the record usable and manageable by parties other than the transaction processor 230.
  • the encrypted private section 130 is necessary to keep the sensitive information private, as well as prevent tampering with the checksum 140.
  • the checksum 140 is necessary to prevent tampering with the record's contents. In theory, the checksum need only be applied to the header and public sections of the record, however, this would be considered a weaker implementation from a cryptographic point of view. While the record header is not absolutely required, the benefits of the header make its omission very unlikely.
  • Fig. 2 Shown in Fig. 2 is a general representation of the secured record structure 100 defined by the invention.
  • the secured record 100 consists of three main parts; a header section 110, a public section 120, and a private section 130.
  • a checksum 140 is embedded in said private section 130.
  • the order of the sections is not important, although the header is typically first for obvious reasons.
  • the specific implementation of the secured record 100 is not pertinent to the invention description. It is possible that the definition established by a major transaction processor would become the de-facto standard.
  • the ASN.1 standard provides a means to define general records that are transportable to other platforms and operating systems, and has existing implementations, thus making it a good choice for manifesting the record as digital data.
  • the PKCS standards provide a well established structure for the definition of records involving encryption, checksums, keys, and identities, making it a good choice for defining the secured record's contents.
  • PKCS and ASN.1 might be used to implement the secured record 100 in practice, however, this is not a requirement of the invention, and other choices are viable.
  • the secured record 100 is typically prefixed by a header section 110 which provides information such as the size of the record, the version of the record's definition, and other possible general fields which might describe meta- information about the secured record 100.
  • the version field can be used to provide for backwards compatibility, as well as performing compatibility checks.
  • Possible meta-information might include, for example, MIME data types used to describe the type of data that a field in the record represents, as well as the possible means of viewing the field's contents.
  • the header is not absolutely required for the present invention, however the benefit of its functionality makes its omission very unlikely.
  • the public section of the secured record contains information that must be visible to make the record usable by all parties. Examples of this information might be the customer's name, the approved shipping addresses, the merchant id, and so on.
  • the fields placed in the public section 120 are primarily for the purposes of handling the secured record. For example, the merchant storing the record may wish to be able to see the customer's shipping address to automatically fill the fields of an online form used during an online checkout procedure. Another example might be a field showing the last four digits of the credit card number to allow the customer to identify the credit card represented by the secured record.
  • the public section of the secured record can identify fields that have been moved to the private section due to their perceived sensitivity, or because they are not required to be public by the customer or the merchant.
  • An example of this type of moved field might be the per transaction purchase limit. Since this limit can be applied by the transaction processor's constraint filtering, it is not required to be checked by the merchant, and may be considered sensitive information by the customer.
  • the required fields in the public section 120 are: 1 ) a globally unique merchant id or merchant id's to be used by the transaction processor; 2) a merchant's customer id for a merchant to identify the customer to which the record belongs; 3) a merchant record id for a merchant to uniquely identify the record.
  • the public section often contains constraint definitions used to restrict use of the secured record. Additionally for convenience, transaction processor versions of the customer id and record id may be included in the public header, to facilitate sharing of the same record by both merchant and processor, although the credit card information typically identifies the customer for the transaction processor. Other fields in the public section 120 may include a description of the key and method used to encrypt the private section of the record. [0057] In the case that a standard record structure such as PKCS7 is used, the PKCS7 standard will provide the description of the encryption method and key pair. In this case, the requirement for the key and encryption method used for the private section to be included in the public section is unnecessary.
  • the record and customer id fields may have both transaction processor and merchant versions. This allows the merchant and transaction processor to share record definitions while using their own internal ids.
  • the globally unique merchant id or ids is what ties the record to that merchant or merchants for all future purchases.
  • the encryption description allows for the support of different encryption standards, which is often required to accommodate international laws, patents infringements, and other issues.
  • Shown in Fig. 3-A is one possible embodiment of the public section 120 of the secured record 100. This version contains fields for the customer name 121 , customer shipping address 122, customer id 123, merchant id 124, and constraint definitions 125.
  • Extensible Markup Language is a simple, flexible text format which plays a significant role in the exchange of a wide variety of data on the Internet.
  • Fig. 3-B Shown in Fig. 3-B is an example of a possible definition for the public section of the secured record as implemented using XML in accordance with the present invention.
  • the public section is a simple list of fields.
  • the fields consist of name/value data pairs.
  • the customer name field 121 will preferably contain name/value pairs for both first and last names.
  • the customer shipping address 122 will preferably contain name/value pairs for street, city, state, zip code, and country information.
  • Constraint definitions field 125 can, for example, be used to set restrictions on the permissible frequency of charge events, the total duration interval in which these charge events may occur, a group of purchase types to limit the kind of goods which can be bought, and even price limits for particular purchase types. Knowing that these constraints are in force will serve to make a customer more confident in the use of their credit card over the Internet with merchants who can offer this advanced level of assurance with regard to the handling of the customer's sensitive credit card information. Private Section of the Secured Record
  • Fig. 4-A Shown in Fig. 4-A, is an example of the private section 130 of the secured record 100.
  • This version contains fields for the credit card number 131 , credit card expiration date 132, and credit card security number 133 which is typically located on the back of the card. It may also contain constraint definitions and other fields 134 which can be used only by the transaction processor. The other fields can provide additional information to further verify the identity of the customer or for any other general purpose to support verification or processing. If the transaction processor creates the secured record, it becomes possible to provide for fields and constraints which are never visible to the merchant.
  • Fig. 4-B shows an example of a possible definition for the private section 130 of the secured record 100 as implemented using XML in accordance with the present invention. As can be seen in Fig.
  • the private section 130 may preferably contain in addition to the fields already mentioned the billing address for the customer.
  • restricting viewing of the bill-to address information to only the transaction processor removes another piece of personal information from viewing by parties that do not require access to the information.
  • the required fields in the private section 130 include: 1) the credit card information necessary to complete processing (e.g., the card number, expiration date, and security number); 2) the checksum 140 of the public section data.
  • the private section 130 data is encrypted using the public key 20 of the transaction processor 34.
  • a one- shot encryption key may be generated and used to encrypt the private data, after which the one-shot key is included in the public section after being encrypted using the public key 20 of the transaction processor 34.
  • the private section can only be viewed by the possessor of the private key corresponding to said public key.
  • the public key 20 can be given to anyone, and can be easily transmitted over the Internet using, for example, web services or email. PKCS standards define data structures and methods that can be used to store, transmit, and email public keys, and it is expected that these existing mechanisms would be used for this purpose. However, this is not a requirement of the invention, and because the key is public, any effective means of transmitting the public key 20 to the merchants is acceptable.
  • the private key In order to decrypt the private section 130 data, the private key
  • the private key 22 corresponding to the public key 20 must be used to decrypt the data, or, in the case of the one-shot key being used, the private key 22 must be used to decrypt the one-shot key, which is then used to decrypt the private section 130 data. Therefore, the private section 130 data can only be decrypted, and thus can only be viewed, by the transaction processor 34 owning the private key 34. As such, the private keys become the primary, and singular, point of failure. Only the theft of the private key, or the reverse engineering (cracking) of the private key, can allow unauthorized access to the sensitive information.
  • the creator In order to create the secured record 100, the creator needs the following information: 1) The public key 20 provided by the transaction processor 230; 2) the public information for the public section 120, such as customer identification, merchant id, public constraints, etc.; 3) the private information for the private section 130, such as the sensitive credit card information.
  • the software must fill in the header section, fill in the public section 120, fill in the private section 130, zero the checksum field 140. Completion of these steps results in the unencrypted secured record 100-A. It is then possible to employ any number of checksum computation algorithms to compute the checksum 140 of the entire record. This computed value is then inserted back into the field resulting in the unencrypted secured record with computed checksum 100-B.
  • the public key 20 provided by the transaction processor 34 is used to encrypt the private section 130 including the checksum field 140 thereby resulting in the encrypted secured record 100-C.
  • a checksum may be performed over only the header and public section as an absolute minimum. This technique is weaker, from a cryptographic point of view, but still achieves the objective of assuring record integrity. Other checksum strategies exist, but offer no significant advantages over a checksum of the entire record, in terms of validating record integrity.
  • the transaction processor 34 In order to extract information from a secured record 100, the transaction processor 34 needs the following information: 1) The private key 22 corresponding to the public key 20 which was provided by the transaction processor 34 previously for the secured record generation 410 process; 2) the encrypted secured record 100-C.
  • the process to decrypt and validate the secured record 620 employs the private key 22 to decrypt the private section 130, extracts the checksum field 140, zeroes the checksum field, computes the checksum of the entire secured record, and then compares the newly computed checksum with the checksum value previously extracted. If the two checksum values are not identical, that is if the "is checksum valid test?" test fails, it means that the secured record 100 was tampered with, and the associated charge request is rejected. Otherwise, if the checksum fields are identical, it means that the encrypted secured record 100-C was not violated. This positive finding allows the associated charge request to be accepted for processing. Completion of these steps results in the unencrypted secured record 100-A.
  • FIG. 13 Shown in Fig. 13 is an overview of credit card information extraction process 660. It consists of two main sub-processes. They are the decrypt & validate secured record 620 process followed by the extract credit card information process 661 which copies or isolates the credit card information 93 from the decrypted secured record 100-A.
  • the general structure of electronic commerce implemented by merchants and transaction processors at the present time has a major vulnerability in the storage and transmission of unsecured customer credit information.
  • the customer registration and customer purchase processes together consist of several general steps: 1) the merchant collects information from the customer including the credit card number, expiration date, security code, etc., and stores this information in a database or file; 2) during a purchase, the merchant retrieves the customer's credit card information from storage; 3) the merchant submits the charge transaction to the transaction processor over a network.
  • Fig. 5 specifically shows the customer registration process 300 as practice by prior art.
  • the customer 30 completes a registration web page 50.
  • This acquired information including sensitive information, is packaged in an unsecured record 90.
  • the merchant 32 can, after communication in some other fashion with the customer 30 to acquire the relevant information, create the unsecured record 90.
  • a store unsecured record process 310 performs the simple operation of storage of the sensitive customer information contained in the unsecured record 90 into a customer information database 42. Because these prior art databases may store the sensitive credit card information in an unencrypted fashion they have been targeted and their customer credit card information successfully stolen not only by remote hackers over the Internet but also by rogue merchant employees or clients with direct physical or electronic access to the customer information database 42.
  • Fig. 6 specifically shows the customer purchase process 350 as practiced using prior art.
  • the customer 30 makes a purchase from an online merchant by completing a shopping cart web page 55. Alternatively, this information can be acquired from the customer 30 by some other means such as by telephone. This purchase information is then used in a process to retrieve the pertinent customer information 360 pertaining to the customer 30.
  • the create standard charge record process 370 combines the customer information 98 successfully retrieved from the database and the purchase information 97 to result in the merchant standard charge record 91.
  • the standard charge record 91 contains all the information necessary to be submitted to the transaction processor 34 for traditional credit card processing 250.
  • the merchant must extend their storage to accommodate the new secured record.
  • the simplest way to accomplish this is for the merchant to generate a unique lookup key that is stored in the location previously used to store the customer's credit card number. This lookup key is then used as an index into the secured record database to retrieve the secured record belonging to the customer.
  • the merchant must also modify existing software, or add some other processing in order to generate the secured record from the information provided by the customer at registration time, and store it into the database.
  • the merchant could make a request to the processor to have the record generated for them.
  • the merchant must modify their charge processing to accommodate the transmission of the new secured charge request .
  • the merchant does not need to make any changes to its systems or procedures.
  • the transaction processor must modify their systems to accommodate receiving secured charge requests utilizing the new secured charge request.
  • the transaction processor must also modify existing software, or otherwise add new processing, in order to process the transaction using the new secured record. This includes, decrypting the secured record, verifying the secured record, and applying constraint filters. If all processing is successful, then the customer's credit card information is retrieved from the private section of the secured record, and it used to continue the charge transaction just as all normal or prior art credit card transactions are processed.
  • the transaction processor In the proxy case, the transaction processor must recognize the proxy number and map it to a secured record in the database. The proxy case is shown in Fig. 14 and discussed below.
  • FIG. 1 A high level overview of a preferred embodiment of the present invention is depicted in Fig. 1 which illustrates the new secure credit card transaction 200 process.
  • Fig. 1 shows the key changes to the customer registration process 210, purchase process 220, and payment process 230.
  • the figure indicates the parties necessary for each phase of credit card transaction 200.
  • a customer 30 and a merchant 32 participate in the registration process 210 and purchase process 220.
  • Said merchant 32 communicates with a transaction processor 34 that performs the payment process 230.
  • the merchant 32 provides a registration web page 50.
  • Customer 30 provides the solicited information which is sufficient to complete the unencrypted secured record 100-A.
  • a generate secured record process 410 then uses the public key 20 provided to the merchant 32 by the transaction processor 34 to generate the encrypted secured record 100-C.
  • Fig. 1 Also shown in Fig. 1 , is the purchase process 220, for which the merchant 32 provides a shopping cart web page 55. Customer 30 provides the solicited information for their desired products.
  • a create secured charge record process 550 retrieves the secured record 100-C and produces the merchant secured charge record 92 for transmittal to the transaction processor 34.
  • the last phase of the new invention for secure credit card commerce 200 is shown in Fig. 1 as the payment process 230.
  • the merchant 32 transmits the secured charge record 92 to transaction processor 34.
  • Said transaction processor 34 uses their private key 22, corresponding to the public key 20 previously used to create the secured records, for a decrypt secured charge record process 610 on said secured charge record 92.
  • the output of the decryption process is the credit card information and charge detail information 95 which can then undergo traditional credit card processing 250.
  • the present invention leverages the storage of the credit card number by the merchant to facilitate the storage and retrieval of the secured record. Because, by definition, the credit card number is no longer used, as it is now secreted away in the secured record, this now unused field can be leveraged by the merchant to store the lookup key for the new database that will contain the new secured record. This not only eases the effort required to support the new secured record, but also greatly simplifies the task of securing existing customer records with no change to existing data structures or databases. This feature is essential to improve adoption of the invention. [0087] A further enhancement can be made by using the last four digits of the new secured record key to store the last four digits of the real credit card number. The remaining digits are used for the actual secured record key. This provides backward compatibility with existing systems which display the last four digits of the credit card number as a visual cue for the customer and or merchant. These features will help advance adoption of the invention.
  • Fig. 7 specifically shows the customer registration process 400 as disclosed by the present invention.
  • the customer 30 completes a registration web page 50 provided by a merchant 32.
  • the sensitive information acquired in this registration web page is processed using the public key 20 provided by a transaction processor 34 for said merchant 32.
  • a generate secured record process 410 secures the sensitive information and includes essential public information in the output form of a secured record 100.
  • Fig. 11 and its associated explanation disclose in more detail this generation process.
  • a store secured record process 420 which enters the secured record 100 into the customer information database 40 belonging to the merchant 32, the customer's sensitive credit card information is deleted.
  • the stored sensitive information is now as secure as the cryptography process used to encrypt the private section 130 of the secured record 100.
  • the transaction processor 34 it is also possible, and in some cases preferable, for the transaction processor 34 to provide for the registration process 400 and creation of the secured record 100, which is then transmitted to the online merchant 32 for storage into the merchant's customer information database 40 for future use. Having the transaction processor 34 provide the registration process 400 allows for several advantages: 1 ) it relieves the merchant from having to generate the secured record; 2) it allows the customer to conveniently issue secured records to multiple merchants via a single registration procedure; 3) it allows the customer and the transaction processor to include constraints and other fields in the private section that are never visible to the merchant.
  • Fig. 8 specifically shows the customer purchase process 500 as defined by the present invention.
  • the customer 30 places a purchase request by completing a shopping cart web page 55 provided by an online merchant 32.
  • the purchase information 97 serves as input to the retrieve secure customer record process 510 which selects the appropriate secured record 100 pertaining to the customer 30 from the secured customer information database 40.
  • the process create secured charge record 550 combines the secured record 100, which was successfully retrieved from the customer information database 40, the purchase information 97, and the public key 20 to generate a merchant secured charge record 92. It is possible that the public key 20 used in this case to create the secured charge record 92 is identical to the one used to create the secured record 100, but this is not necessary.
  • Fig. 9 specifically shows the overall credit card payment process 600 as disclosed by the present invention.
  • a merchant 32 submits a merchant secured charge record 92 to a transaction processor 34 for payment.
  • the transaction processor retrieves the private key 22 corresponding to the public key 20 used to encrypt the secured charge record 92.
  • the decrypt secured charge record using private key process 610 is then run employing inputs private key 22 and merchant secured charge record 92.
  • the outputs of this decryption process are the two records for credit card information 93 and charge details 94.
  • This process comprises the tasks of rearranging, reformatting, and reassembling the customer account information and shopping cart purchase information into the specific format used by the transaction processor 34 prior to use of the invention.
  • the output record is then the standard charge record 91 which can then serve as input for traditional credit card processing 250.
  • Figs. 10-A, 10-B, and 10-C detail three of the possible embodiments of a process to decrypt secured charge record 610. All three take as input the private key 22 and the merchant secured charge record 92. And as also illustrated in these figures, the three associated processes output the two records for credit card information 93 and charge details 94. However in the three cases the secured charge request takes differing forms. The various secured charge request formats thereby possess their own relative advantages and disadvantages.
  • Fig 10-A Shown in Fig 10-A is the simple secure method to process the secured charge record 610-A.
  • the secured charge record 92 wholly contains both the secured record 100, as disclosed in this invention, and the specific charge details 94.
  • the actual creation of the secured charge record was shown in Fig. 8 and described above.
  • the two embedded records are only loosely associated within the secured charge record 92.
  • the secured charge record 92 is also termed an open charge record 99 because the charge details may be modified unknowingly.
  • the simple secure method for decrypting the open charge record 99 affords the advantage of allowing the reuse of the secured record 100 which protects the critical credit card charge information.
  • the extract open charge record process 650 consists of a number of subtasks enclosed in the dashed box in Fig. 10-A. Because of the open structure of this charge record, a simple process to extract the secured record and charge details 640 directly results in the output of both the secured record 100 and charge details 94.
  • the transaction processor then uses the appropriate private key 22 to perform the extract credit card information process 660.
  • Shown in Fig. 13 are the details of how the extract credit card information process 660 uses the private key 22 for decryption and then performs a validation before the final output of the credit card information 93.
  • the simple secure method 610-A is complete.
  • Shown in Fig 10-B is the secure method 610-B.
  • the secured charge record 92 also wholly contains both the secured record 100, and the specific charge details 94.
  • secured charge record contents are encrypted within the secured charge record 92. Because of this fact, the secure method 610-B affords the dual advantages of allowing the reuse of the secured record 100 and also protecting the charge details 94 from unauthorized viewing or modification.
  • the private key 22 must be used to decrypt the secured charge record 630 which results in the open charge record 99. Subsequent processing is essentially identical to that used in the simple secure method 650.
  • This open charge record 99 and the private key serves as inputs to the extract open charge record process 650 which results in the output of both the credit card information 93 and charge details 94.
  • Fig 10-C Shown in Fig 10-C is the single use secure method 610-C.
  • This method for handling the secured charge is typically employed when these charge records are of the type created when each purchase transaction triggers generation of a new secured record 100, most commonly when customer information is not stored by the merchant.
  • the significance of this method is that it leverages the secured record itself by placing the charge details inside the secured record before the checksum is computed and the private section is encrypted. As such, this method provides for securing the charge details from tampering and possibly from viewing (if it is placed into the private section).
  • the secured record may only be used once, as the charge details will vary with each use, requiring its regeneration with each use.
  • the single use secure method 610-C differs from the simple secure method 610-A in that the charge detail information is protected by encryption in the former case.
  • the single use secure method 610-C differs from the secure method 610-B in that the purchase information is placed inside the encrypted secured record 100- C.
  • the charge detail information are encrypted with the private section 130 of the secured record 100, where they were placed, thus making the secured record 100 only usable for a single purchase. Because of these facts, the single use secure method for decrypting the secured charge record 610-C does afford the advantage of security for the charge details 94 information.
  • the processor uses the private key 22 as input to the process to decrypt secured record 620. This step results in the secured record unencrypted 100-A from which the credit card information 93 and the charge details 94 can be read.
  • charge details are preferably embedded in the private section to maximize security but may alternatively be embedded in the public section.
  • Proxy Number Processing [00103] The present invention also leverages the fact that many of the merchants who will adopt the use of this invention will be Internet-based businesses, and because of this, the protocols used to transmit the charge transaction from the merchant to the transaction processor are far more likely to be flexible, and thus provide for transmission of the new secured charge request in the transaction communication.
  • the use of proxy numbers can be used to allow the secured records to reside in the transaction processor's database, and to allow the merchant to deal with proxy numbers which are indistinguishable from normal credit card numbers and require the merchant to do nothing different from their existing procedures using their existing applications and databases without modification.
  • proxy number usage only the transaction processor has to accommodate any changes; the merchant and the customer continue to operate as they always have, other than the processor or merchant must issue the proxy number to the customer.
  • the processor In the event that a proxy number is received in a traditional transaction, the processor must: 1) recognize the case of a proxy number in use; 2) use the proxy number to retrieve the secured record from the processor's database; 3) process the charge transaction using the secured record as described above.
  • Fig. 14 Shown in Fig. 14 is the general structure of electronic commerce using the invention's proxy number 700.
  • Fig. 14 shows an online transaction using the proxy number.
  • the significance of the diagram is that the transaction is indistinguishable from an ordinary credit or debit card transaction, whether online, over the phone, or via point of sale locations.
  • a customer 30 who has a proxy number completes a shopping cart web page 55 just as they would if they had a normal charge card number.
  • the merchant creates a charge request in the existing format using said the proxy number for the credit card number.
  • the charge request is then transmitted to the transaction processor in the traditional fashion.
  • the secured record 100 retrieved using the proxy number, along with the corresponding private key 22 are used by the transaction processor in a process to decrypt and validate the secured record 620 resulting in the unsecured record 90.
  • the charge request follows traditional transaction processor credit card processing 250.
  • the merchant needs to do nothing, as the proxy number will be indistinguishable from a normal credit card number, and will be submitted for processing in the same manner as all current charge requests.
  • FIG. 15 shows the general structure of the key revocation process 800.
  • the merchant 32 collects all secured records and forms an update request database.
  • the database is uploaded to the transaction processor 34.
  • Said transaction processor 34 decrypts each secured record using the old private key 22 originally used to encrypt the records but now compromised. The processor 34 then uses a new and hence uncompromised public key 20 to re- encrypt each secured record. These newly secured records are combined in an updated secured record database which is transmitted back to the merchant 32 who then replaces the old secured records with the updated secured records thereby resecuring the customer information database 40.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Mathematical Physics (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé par lequel des commerçants stockant des données de carte de crédit sensibles peuvent protéger ces données contre le vol, tout en réduisant au minimum et leur effet pour le consommateur et leur coût de mise en oeuvre. Le commerçant utilise un enregistrement sécurisé particulier (fig. 2, 100) pour stocker les données de carte de crédit au bénéfice d'un client particulier. L'enregistrement comporte deux parties. La première partie de l'enregistrement contient des données publiques (120) visibles pour toute personne accédant à l'enregistrement (100). Les données publiques contiennent l'identité du commerçant accompagnée d'informations limitant l'usage de l'enregistrement, telles que les restrictions sur le type d'achat, la quantité de produits achetés, la fréquence des achats, ainsi que la date d'expiration de l'enregistrement, les adresses d'expédition approuvées et d'autres restrictions qui rendent l'enregistrement effectivement inopérant pour toute personne autre que le commerçant qui l'a créé et stocké, et limitent en même temps d'éventuels abus dudit commerçant. La seconde partie (130) de l'enregistrement (100) contient des données confidentielles chiffrées de façon à être visibles uniquement pour les parties autorisées à les consulter. La partie confidentielle (130) de l'enregistrement (100) contient les données de carte de crédit sensibles accompagnées d'un total de contrôle (140) des contenus de l'enregistrement (100). Une fois l'enregistrement (100) soumis à l'entité de validation, la partie confidentielle (130) de l'enregistrement (100) est déchiffrée au moyen de la clé appropriée. Le total de contrôle (140) est utilisé pour vérifier que l'enregistrement (100) n'a pas été modifié, et que les sections publique et confidentielle (120, 130) correspondent l'une à l'autre. Une fois l'enregistrement (100) validé, des contraintes sont appliquées et, si leurs critères sont remplis, les données de carte de crédit sont utilisées pour traiter la transaction.
PCT/US2005/026653 2004-07-30 2005-07-28 Procede de protection de donnees electroniques stockees sur une carte de credit WO2006015052A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US59258604P 2004-07-30 2004-07-30
US60/592,586 2004-07-30

Publications (1)

Publication Number Publication Date
WO2006015052A1 true WO2006015052A1 (fr) 2006-02-09

Family

ID=35787448

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/026653 WO2006015052A1 (fr) 2004-07-30 2005-07-28 Procede de protection de donnees electroniques stockees sur une carte de credit

Country Status (1)

Country Link
WO (1) WO2006015052A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5453601A (en) * 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US20030023549A1 (en) * 2001-06-27 2003-01-30 American Express Travel Related Services Company, Inc. Consolidated payment account system and method
US20030061170A1 (en) * 2000-08-29 2003-03-27 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5453601A (en) * 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US20030061170A1 (en) * 2000-08-29 2003-03-27 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
US20030023549A1 (en) * 2001-06-27 2003-01-30 American Express Travel Related Services Company, Inc. Consolidated payment account system and method

Similar Documents

Publication Publication Date Title
US20060282372A1 (en) Method to secure credit card information stored electronically
JP5721086B2 (ja) 電子マネーの管理方法
US10318932B2 (en) Payment card processing system with structure preserving encryption
JP3329432B2 (ja) 階層型電子現金実施方法およびこれに用いられる装置
US6195432B1 (en) Software distribution system and software utilization scheme for improving security and user convenience
AU751404B2 (en) Symmetrically-secured electronic communication system
US7353532B2 (en) Secure system and method for enforcement of privacy policy and protection of confidentiality
CA2481577C (fr) Systeme de stockage de donnees securise recourant a des techniques de repartition des donnees et de stockage separe
US20090261162A1 (en) Secure system and method for payment card and data storage and processing via information splitting
CN105027153A (zh) 用于安全配置、传送和验证支付数据的方法、装置和系统
US20030130961A1 (en) System and method for making secure data transmissions
JPH09305666A (ja) 電子決済方法ならびにシステム
CN113763158B (zh) 一种基于区块链底层的虚拟资产托管和支付系统及其方法
JPH09114904A (ja) 情報販売方法およびシステム
EP0886248B1 (fr) Méthode et dispositif pour l'enregistrement de données auprès de plusieurs instituts et moyen d'enregistrement avec programme d'enregistrement stocké dedans
AU2002254513B8 (en) System and method for conducting secure payment transactions
WO2006015052A1 (fr) Procede de protection de donnees electroniques stockees sur une carte de credit
JP3497936B2 (ja) 個人認証方法
JP4997270B2 (ja) 暗号化および復号化のためのシステムおよび方法
JP2003066836A (ja) 電子署名方法
KR20020003084A (ko) 클라이언트 결제 애플리케이션을 이용한 인터넷 기반 전자 상거래의 결제 서비스 제공 방법
JP2002099856A (ja) ネットワーク上でのカード情報取扱方式
KR20020061719A (ko) 전자상거래의 보안결제시스템
CA2295603C (fr) Systeme de communication electronique protege de maniere symetrique
KR100715556B1 (ko) 인터넷 기반 유통 정보 인증 장치 및 그 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载