US20130060705A1 - Method and system to securely store customer data in a network-based commerce system - Google Patents
Method and system to securely store customer data in a network-based commerce system Download PDFInfo
- Publication number
- US20130060705A1 US20130060705A1 US13/655,612 US201213655612A US2013060705A1 US 20130060705 A1 US20130060705 A1 US 20130060705A1 US 201213655612 A US201213655612 A US 201213655612A US 2013060705 A1 US2013060705 A1 US 2013060705A1
- Authority
- US
- United States
- Prior art keywords
- customer data
- symmetric key
- encoded
- encrypted
- key
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
-
- 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/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0251—Targeted advertisements
Definitions
- Exemplary embodiments of present invention relate generally to the technical field of network-based commerce and, in one exemplary embodiment, to methods and systems to securely store customer data in a network-based commerce system.
- Sensitive customer data can be stored in a database, which encrypts the sensitive data at the database level.
- a hardware encryption solution is embedded in the machine where the database runs, or, a software package such as PROTEGRITY is embedded in the database.
- Keys for encryption and decryption are managed and maintained at the database.
- traditional solutions such as hardware encryption and PROTEGRITY make migrating encrypted data from one database machine to another quite difficult, if not impossible, because decryption keys are often lost when migration is attempted.
- traditional solutions are unwieldy for database administrators who do not specialize in or design their systems with encryption in mind.
- Network-based commerce systems would benefit from an encryption solution with at least two levels of encryption, so that the system has defense-in-depth of encryption. Furthermore if an encryption solution is standards-based, the encrypted data could be easily migrated between machines and systems without the danger of exposing the encrypted data or losing the decryption keys.
- FIG. 1 is a network diagram depicting a system, according to one exemplary embodiment of the present invention, having a client-server architecture.
- FIG. 2 is a block diagram illustrating multiple marketplace and payment applications that, in one exemplary embodiment of the present invention, are provided as part of the network-based marketplace.
- FIG. 3 is a high-level entity-relationship diagram, illustrating various tables that may be maintained within the databases, and that are utilized by and support the marketplace and payment applications.
- FIG. 4 provides a data flow diagram representing the flow of data in one embodiment of the system described with reference to FIG. 1 .
- FIG. 5 provides a diagrammatic view of one embodiment of the sensitive customer data application interface through which sensitive customer data is received by the sensitive customer data application.
- FIG. 6 provides a diagrammatic representation of one embodiment of the flow of data from the self-describing data structure to the database, which is blind to the sensitive customer data.
- FIG. 7 provides a diagrammatic representation of another embodiment of the flow of data from the self-describing data structure to the database, which is blind to the sensitive customer data.
- FIG. 8 provides a diagrammatic representation of one embodiment of the flow of data from the database to the applications, which require the un-encrypted sensitive customer data.
- FIG. 9 provides a flow chart view of one embodiment of the method to securely store customer data in a network-based commerce system.
- FIG. 10 shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- FIG. 1 is a network diagram depicting a system 10 , according to one exemplary embodiment of the present invention, having a client-server architecture.
- a commerce platform in the exemplary form of a network-based marketplace 12 , provides server-side functionality, via a network connection 14 , for example, a HyperText Transfer Protocol (HTTP) connection, or a secure HTTP connection (HTTPS) over the Internet to one or more clients.
- HTTP HyperText Transfer Protocol
- HTTPS secure HTTP connection
- FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State), and a programmatic client 18 executing on respective client machines 20 and 22 .
- a web client 16 e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State
- programmatic client 18 executing on respective client machines 20 and 22 .
- an Application Program Interface (API) server 24 and a web server 26 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 28 .
- the application servers 28 host one or more marketplace applications 30 and payment applications 32 .
- the application servers 28 are, in turn, shown to be coupled to one or more databases servers 34 that facilitate access to one or more databases 36 .
- the marketplace applications 30 provide a number of marketplace functions and services to users that access the marketplace 12 .
- the payment applications 32 likewise provide a number of payment services and functions to users.
- the payment applications 30 may allow users to quantify for, and accumulate, value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 30 .
- value e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”
- the marketplace and payment applications 30 and 32 are shown in FIG. 1 to both form part of the network-based marketplace 12 , it will be appreciated that, in alternative embodiments of the present invention, the payment applications 32 may form part of a payment service that is separate and distinct from the marketplace 12 .
- system 10 shown in FIG. 1 employs a client-server architecture
- present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system.
- the various marketplace and payment applications 30 and 32 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.
- the web client 16 accesses the various marketplace and payment applications 30 and 32 via the web interface supported by the web server 26 .
- the programmatic client 18 accesses the various services and functions provided by the marketplace and payment applications 30 and 32 via the programmatic interface provided by the API server 24 .
- the programmatic client 18 may, for example, be a seller application (e.g., the TURBOLISTER application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the marketplace 12 in an off-line manner, and to perform batch-mode communications between the programmatic client 18 and the network-based marketplace 12 .
- FIG. 1 also illustrates a third party application 38 , executing on a third party server machine 40 , as having programmatic access to the network-based marketplace 12 via the programmatic interface provided by the API server 24 .
- the third party application 38 may, utilizing information retrieved from the network-based marketplace 12 , support one or more features or functions on a website hosted by the third party.
- the third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-based marketplace 12 .
- FIG. 2 is a block diagram illustrating multiple marketplace and payment applications 30 that, in one exemplary embodiment of the present invention, are provided as part of the network-based marketplace 12 .
- the marketplace 12 may provide a number of listing and price-setting mechanisms whereby a seller may list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services.
- the marketplace applications 30 are shown to include one or more auction applications 44 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.).
- the various auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a reserve price feature whereby a seller may specify a reserve price in connection with a listing
- a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a number of fixed-price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings.
- buyout-type listings e.g., including the BUY-IT-NOW (BIN) technology developed by eBay Inc., of San Jose, Calif.
- BIN BUY-IT-NOW
- auction-format listing may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction.
- Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
- Reputation applications 50 allow parties that transact utilizing the network-based marketplace 12 to establish, build and maintain reputations, which may be made available and published to potential trading partners.
- the network-based marketplace 12 supports person-to-person trading
- users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed.
- the reputation applications 50 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-based marketplace 12 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
- Personalization applications 52 allow users of the marketplace 12 to personalize various aspects of their interactions with the marketplace 12 . For example a user may, utilizing an appropriate personalization application 52 , create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 52 may enable a user to personalize listings and other aspects of their interactions with the marketplace 12 and other parties.
- the network-based marketplace 12 may support a number of marketplaces that are customized, for example, for specific geographic regions.
- a version of the marketplace 12 may be customized for the United Kingdom, whereas another version of the marketplace 12 may be customized for the United States.
- Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace.
- Navigation of the network based-marketplace 12 may be facilitated by one or more navigation applications 56 .
- a search application enables key word searches of listings published via the marketplace 12 .
- a browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within the marketplace 12 .
- Various other navigation applications may be provided to supplement the search and browsing applications.
- the marketplace applications 30 may include one or more imaging applications 58 utilizing which users may upload images for inclusion within listings.
- An imaging application 58 also operates to incorporate images within viewed listings.
- the imaging applications 58 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.
- Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the marketplace 12
- listing management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge.
- the listing management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings.
- One or more post-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 44 , a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 64 may provide an interface to one or more reputation applications 50 , so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 50 .
- Dispute resolution applications 66 provide mechanisms whereby disputes arising between transacting parties may be resolved.
- the dispute resolution applications 66 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third party mediator or arbitrator.
- a number of fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within the marketplace 12 .
- Messaging applications 70 are responsible for the generation and delivery of messages to users of the network-based marketplace 12 , such messages for example advising users regarding the status of listings at the marketplace 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).
- Merchandising applications 72 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the marketplace 12 .
- the merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
- the network-based marketplace 12 itself, or one or more parties that transact via the marketplace 12 may operate loyalty programs that are supported by one or more loyalty/promotions applications 74 . For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward thr which accumulated loyalty points can be redeemed.
- FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 90 that may be maintained within the databases 36 , and that are utilized by and support the marketplace and payment applications 30 and 32 .
- a user table 92 contains a record for each registered user of the network-based marketplace 12 , and may include identifier, address and financial instrument information pertaining to each such registered user.
- a user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-based marketplace 12 .
- a buyer may be a user that has accumulated value (e.g., commercial or proprietary currency), and is then able to exchange the accumulated value for items that are offered for sale by the network-based marketplace 12 .
- accumulated value e.g., commercial or proprietary currency
- the tables 90 also include an items table 94 in which are maintained item records for goods and services that are available to be, or have been, transacted via the marketplace 12 .
- Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92 , so as to associate a seller and one or more actual or potential buyers with each item record.
- a transaction table 96 contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94 .
- An order table 98 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 96 .
- Bid records within a bids table 100 each relate to a bid received at the network-based marketplace 12 in connection with an auction-format listing supported by an auction application 44 .
- a feedback table 102 is utilized by one or more reputation applications 50 , in one exemplary embodiment, to construct and maintain reputation information concerning users.
- a history table 104 maintains a history of transactions to which a user has been a party.
- One or more attributes tables 106 record attribute information pertaining to items for which records exist within the items table 94 . Considering only a single example of such an attribute, the attributes tables 106 may indicate a currency attribute associated with a particular item, the currency attribute identifying the currency of a price for the relevant item as specified in by a seller.
- FIG. 4 provides a data flow diagram representing the flow of data in one embodiment of the system 1000 of the present invention.
- Sensitive customer data 1020 is received from clients 22 by a sensitive customer data application 1100 .
- the sensitive customer data application 1100 can be one of the marketplace applications 30 or payment applications 32 .
- the sensitive customer data application 1100 interacts with clients 22 over the network 14 via a sensitive customer data application interface 500 .
- the sensitive customer data application 1100 connects with a symmetric key generator 1070 , which generates a symmetric key 1010 for the sensitive customer data 1020 being stored.
- Exemplary algorithms for generating symmetric keys and encrypting with them include the Data Encryption Standard (DES), Advanced Encryption Standard (AES), and several re-incarnations of DES, including triple-DES with Cipher Block Chaining (CBC).
- DES Data Encryption Standard
- AES Advanced Encryption Standard
- CBC Cipher Block Chaining
- a public key encryptor 1030 receives the symmetric key 1010 generated by the symmetric key generator 1070 .
- the public key encryptor 1030 is capable of encrypting the public key 1060 of an asymmetric key pair.
- Asymmetric key pairs include a public key 1060 and a private key, and are used in asymmetric encryption algorithms that are well known in the art, including standards such as RSA, Digital Signature Standard (DSS), and Pretty Good Privacy (PGP).
- the public key encryptor 1030 also receives (or has access to) the public key 1060 , which may be stored in a protected device such as a keystore 1050 .
- the public key encryptor 1030 uses the asymmetric public key 1060 to encode the symmetric key 1010 as an asymmetric key encrypted symmetric key 2010 .
- a sensitive customer data encryptor 1040 is also shown to receive the symmetric key 1010 . Additionally, the sensitive customer data encryptor 1040 receives sensitive customer data 1020 . The sensitive customer data encryptor 1040 uses the symmetric key 1010 to encode the sensitive customer data 1020 as encrypted sensitive customer data 2020 .
- a secure container module 1080 places the encrypted sensitive data 2020 and the asymmetric key encrypted symmetric key 2010 in a self-describing data structure 2000 .
- the self-describing data structure 2000 is a well-formed XML document.
- the self-describing data structure 2000 comprises snippets of XML that are not well-formed.
- the encrypted sensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored 1090 in one or more databases 36 , which are blind to the sensitive customer data 1020 .
- FIG. 5 provides a diagrammatic view of an exemplary embodiment of the sensitive customer data application interface 500 through which sensitive customer data 1020 is received by the sensitive customer data application 1100 .
- the sensitive customer data application interface 500 contains several method calls 550 , which it can utilize to set sensitive customer data values in the system 1000 .
- Example method calls 550 which may be useful in the system 1000 include Set_CC 510 , Set_NI 520 , Set_DD 530 , and other method calls 540 .
- the Set_CC method call 510 is utilized by the sensitive customer data application 1100 in order to safely and correctly accept and handle sensitive customer data 1020 in the form of credit card billing information.
- the Set_NI method call 520 is used by the sensitive customer data application 1100 in order to safely and correctly handle sensitive customer data 1020 in the form of national identification information.
- the Set_DD method call 530 is used by the sensitive customer data application 1100 in order to safely and correctly handle sensitive customer data 1020 in the form of direct debit information.
- Other method calls 540 can be used to handle sensitive customer data 1020 in other forms as is necessary.
- an XML document is formed which contains several elements including AccountNumber, Encrypted Data, EncryptionMethod, KeyInfo, EncryptedKey, CipherData. These elements are all defined in the XML ENC standard, which makes this particular embodiment of the self-describing container standards compliant.
- the self-describing data structure 2000 contains an asymmetric key encrypted symmetric key 2010 in the first ⁇ CipherData> element shown in lines 11-14 of the text. Additionally, this embodiment of the self-describing data structure 2000 contains asymmetric key encrypted sensitive customer data 2020 in the second ⁇ Cipher Data> element shown in lines 17-19 of the text. As will be apparent to those skilled in the art, the self-describing data structure 2000 is not required to contain any particular XML elements, nor is it required to be an XML document. It must simply have enough information to accurately describe itself, the information it contains, and the decryption algorithms and keys that must be used to decrypt the information it contains.
- FIG. 6 provides a diagrammatic representation of one embodiment of the flow of data from the self-describing data structure 2000 to the database 36 , which is blind to the sensitive customer data 1020 .
- the symmetric key encoded sensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in a common table 120 of the database 36 .
- This table 120 may be one of the database tables 90 described above with reference to FIG. 3 , or it may be a table expressly allocated for storage of sensitive customer data.
- the self-describing data structure 2000 is an XML document
- the entire XML document is stored in its own field 160 of the table 120 .
- the symmetric key encrypted sensitive customer data 2020 is stored in one field 160 of the table 120
- the asymmetric key encrypted symmetric key 2010 is stored in another field 170 of the table 120
- the table 120 where the symmetric key encrypted sensitive customer data 2020 is stored contains several fields including one field 160 where the symmetric key encrypted sensitive customer data is stored 2020 , one field 170 where the asymmetric key encrypted symmetric key 2010 is stored and other fields, 180 , 190 where additional information used by the system 1000 is stored.
- FIG. 7 provides a diagrammatic representation of one embodiment of the flow of data from the self-describing data structure 2000 to the database 36 , which is blind to the sensitive customer data 1020 .
- the symmetric key encrypted sensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in the different tables 120 , 140 of a database 36 .
- These tables 120 , 140 may both be one of the database tables 90 described above with reference to FIG. 3 , or one or both of them may be tables not previously described.
- the self-describing data structure 2000 is an XML document
- XML elements representing the symmetric key encrypted sensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in separate tables 120 , 140 of the database.
- the tables 120 , 140 may be linked to one another in a manner that represents the relationship between the symmetric key encrypted sensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 that encrypted it ( 2020 ).
- FIG. 8 provides a diagrammatic representation of one embodiment of the flow of data from the database 36 , which is blind to the sensitive customer data 1020 to the applications 30 , 32 that require the un-encrypted sensitive customer data 1020 .
- the asymmetric encrypted key 2010 and the encrypted sensitive customer data 2020 are received at the decryption module 900 .
- a second asymmetric key 1065 associated with the asymmetric key 1060 used by the asymmetric key encryptor 1030 is also received by the decryption module 900 .
- the second asymmetric key 1065 is a private key held in a protected device such as a keystore 1050 .
- the decryption module 900 utilizes the second asymmetric key 1065 and algorithms well-known in the art to decrypt the encrypted symmetric key 2010 into the symmetric key 1010 .
- the decryption module 900 then decrypts the symmetric key encrypted sensitive customer data 2020 with the symmetric key 1010 .
- the recently unencrypted sensitive customer data 1020 is received by applications 30 , 32 that require unencrypted sensitive customer data to perform their functions.
- the applications 30 , 32 include credit card billing applications, direct debit billing applications, and reporting applications.
- FIG. 9 provides a flow chart view of one embodiment of the method to securely store customer data in a network-based commerce system.
- sensitive customer data 1020 is received via a network connection 14 through an application interface 1100 .
- a symmetric key 1010 is generated.
- the sensitive customer data 1020 is encoded with the symmetric key 1010 to generate encoded sensitive customer data 2020 .
- the symmetric key 1010 is encoded with an asymmetric key 1060 in order to generate an encoded symmetric key 2010 .
- the encoded sensitive customer data 2020 and the encoded symmetric key 2010 are placed in a self-describing data structure 2000 .
- the encoded sensitive customer data 2020 and the encoded symmetric key 2010 are stored in a database 36 .
- FIG. 10 shows a diagrammatic representation of machine in the exemplary form of a computer system 300 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
- the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- STB set-top box
- a cellular telephone a web appliance
- network router switch or bridge
- the exemplary computer system 300 includes a processor 302 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 304 and a static memory 306 , which communicate with each other via a bus 308 .
- the computer system 300 may further include a video display unit 310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
- the computer system 300 also includes an alphanumeric input device 312 (e.g., a keyboard), a cursor control device 314 (e.g., a mouse), a disk drive unit 316 , a signal generation device 318 (e.g., a speaker) and a network interface device 320 .
- the disk drive unit 316 includes a machine-readable medium 322 on which is stored one or more sets of instructions (e.g., software 324 ) embodying any one or more of the methodologies or functions described herein.
- the software 324 may also reside, completely or at least partially, within the main memory 304 and/or within the processor 302 during execution thereof by the computer system 300 , the main memory 304 and the processor 302 also constituting machine-readable media.
- the software 324 may further be transmitted or received over a network 326 via the network interface device 320 .
- machine-readable medium 322 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
Abstract
A system and method for securely storing customer data in a network-based commerce system. Customer data is received via a network connection through an application interface. A symmetric key is generated and the customer data is encoded with the symmetric key. The symmetric key is encoded with an asymmetric key to generate an encoded symmetric key. The encoded customer data and the encoded symmetric key are stored.
Description
- This application is a continuation application which claims the priority benefit of U.S. application Ser. No. 10/902,647, filed Jul. 28, 2004, which is incorporated herein by reference in its entirety.
- Exemplary embodiments of present invention relate generally to the technical field of network-based commerce and, in one exemplary embodiment, to methods and systems to securely store customer data in a network-based commerce system.
- Sensitive customer data can be stored in a database, which encrypts the sensitive data at the database level. When encryption is done at the database level, a hardware encryption solution is embedded in the machine where the database runs, or, a software package such as PROTEGRITY is embedded in the database. Keys for encryption and decryption are managed and maintained at the database. However, traditional solutions such as hardware encryption and PROTEGRITY make migrating encrypted data from one database machine to another quite difficult, if not impossible, because decryption keys are often lost when migration is attempted. Additionally, traditional solutions are unwieldy for database administrators who do not specialize in or design their systems with encryption in mind. Furthermore, from a security standpoint, it is not advantageous to store the encryption key required to decrypt the data in the same location as the encrypted data.
- Network-based commerce systems would benefit from an encryption solution with at least two levels of encryption, so that the system has defense-in-depth of encryption. Furthermore if an encryption solution is standards-based, the encrypted data could be easily migrated between machines and systems without the danger of exposing the encrypted data or losing the decryption keys.
- The invention is now described, by way of example, with reference to the accompanying diagrammatic drawings in which the same reference numerals indicate the same or similar features, unless otherwise indicated.
-
FIG. 1 is a network diagram depicting a system, according to one exemplary embodiment of the present invention, having a client-server architecture. -
FIG. 2 is a block diagram illustrating multiple marketplace and payment applications that, in one exemplary embodiment of the present invention, are provided as part of the network-based marketplace. -
FIG. 3 is a high-level entity-relationship diagram, illustrating various tables that may be maintained within the databases, and that are utilized by and support the marketplace and payment applications. -
FIG. 4 provides a data flow diagram representing the flow of data in one embodiment of the system described with reference toFIG. 1 . -
FIG. 5 provides a diagrammatic view of one embodiment of the sensitive customer data application interface through which sensitive customer data is received by the sensitive customer data application. -
FIG. 6 provides a diagrammatic representation of one embodiment of the flow of data from the self-describing data structure to the database, which is blind to the sensitive customer data. -
FIG. 7 provides a diagrammatic representation of another embodiment of the flow of data from the self-describing data structure to the database, which is blind to the sensitive customer data. -
FIG. 8 provides a diagrammatic representation of one embodiment of the flow of data from the database to the applications, which require the un-encrypted sensitive customer data. -
FIG. 9 provides a flow chart view of one embodiment of the method to securely store customer data in a network-based commerce system. -
FIG. 10 shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. - A method and system to securely store customer data in a network-based commerce system are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
-
FIG. 1 is a network diagram depicting asystem 10, according to one exemplary embodiment of the present invention, having a client-server architecture. A commerce platform, in the exemplary form of a network-basedmarketplace 12, provides server-side functionality, via anetwork connection 14, for example, a HyperText Transfer Protocol (HTTP) connection, or a secure HTTP connection (HTTPS) over the Internet to one or more clients.FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State), and aprogrammatic client 18 executing onrespective client machines - Turning specifically to the network-based
marketplace 12, an Application Program Interface (API)server 24 and aweb server 26 are coupled to, and provide programmatic and web interfaces respectively to, one ormore application servers 28. Theapplication servers 28 host one ormore marketplace applications 30 andpayment applications 32. Theapplication servers 28 are, in turn, shown to be coupled to one ormore databases servers 34 that facilitate access to one ormore databases 36. - The
marketplace applications 30 provide a number of marketplace functions and services to users that access themarketplace 12. Thepayment applications 32 likewise provide a number of payment services and functions to users. Thepayment applications 30 may allow users to quantify for, and accumulate, value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via themarketplace applications 30. While the marketplace andpayment applications FIG. 1 to both form part of the network-basedmarketplace 12, it will be appreciated that, in alternative embodiments of the present invention, thepayment applications 32 may form part of a payment service that is separate and distinct from themarketplace 12. - Further, while the
system 10 shown inFIG. 1 employs a client-server architecture, the present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system. The various marketplace andpayment applications - The
web client 16, it will be appreciated, accesses the various marketplace andpayment applications web server 26. Similarly, theprogrammatic client 18 accesses the various services and functions provided by the marketplace andpayment applications API server 24. Theprogrammatic client 18 may, for example, be a seller application (e.g., the TURBOLISTER application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on themarketplace 12 in an off-line manner, and to perform batch-mode communications between theprogrammatic client 18 and the network-basedmarketplace 12. -
FIG. 1 also illustrates athird party application 38, executing on a thirdparty server machine 40, as having programmatic access to the network-basedmarketplace 12 via the programmatic interface provided by theAPI server 24. For example, thethird party application 38 may, utilizing information retrieved from the network-basedmarketplace 12, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-basedmarketplace 12. -
FIG. 2 is a block diagram illustrating multiple marketplace andpayment applications 30 that, in one exemplary embodiment of the present invention, are provided as part of the network-basedmarketplace 12. Themarketplace 12 may provide a number of listing and price-setting mechanisms whereby a seller may list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, themarketplace applications 30 are shown to include one ormore auction applications 44 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). Thevarious auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding. - A number of fixed-
price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the BUY-IT-NOW (BIN) technology developed by eBay Inc., of San Jose, Calif.) may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction. -
Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller. -
Reputation applications 50 allow parties that transact utilizing the network-basedmarketplace 12 to establish, build and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the network-basedmarketplace 12 supports person-to-person trading, users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. Thereputation applications 50 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-basedmarketplace 12 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness. -
Personalization applications 52 allow users of themarketplace 12 to personalize various aspects of their interactions with themarketplace 12. For example a user may, utilizing anappropriate personalization application 52, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, apersonalization application 52 may enable a user to personalize listings and other aspects of their interactions with themarketplace 12 and other parties. - in one embodiment, the network-based
marketplace 12 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of themarketplace 12 may be customized for the United Kingdom, whereas another version of themarketplace 12 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace. Navigation of the network based-marketplace 12 may be facilitated by one ormore navigation applications 56. For example, a search application enables key word searches of listings published via themarketplace 12. A browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within themarketplace 12. Various other navigation applications may be provided to supplement the search and browsing applications. - In order to make listings, available via the network-based
marketplace 12, as visually informing and attractive as possible, themarketplace applications 30 may include one ormore imaging applications 58 utilizing which users may upload images for inclusion within listings. Animaging application 58 also operates to incorporate images within viewed listings. Theimaging applications 58 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items. -
Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via themarketplace 12, andlisting management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. Thelisting management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or morepost-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one ormore auction applications 44, a seller may wish to leave feedback regarding a particular buyer. To this end, apost-listing management application 64 may provide an interface to one ormore reputation applications 50, so as to allow the seller conveniently to provide feedback regarding multiple buyers to thereputation applications 50. -
Dispute resolution applications 66 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, thedispute resolution applications 66 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third party mediator or arbitrator. - A number of
fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within themarketplace 12. -
Messaging applications 70 are responsible for the generation and delivery of messages to users of the network-basedmarketplace 12, such messages for example advising users regarding the status of listings at the marketplace 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users). -
Merchandising applications 72 support various merchandising functions that are made available to sellers to enable sellers to increase sales via themarketplace 12. The merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers. - The network-based
marketplace 12 itself, or one or more parties that transact via themarketplace 12, may operate loyalty programs that are supported by one or more loyalty/promotions applications 74. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward thr which accumulated loyalty points can be redeemed. -
FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 90 that may be maintained within thedatabases 36, and that are utilized by and support the marketplace andpayment applications marketplace 12, and may include identifier, address and financial instrument information pertaining to each such registered user. A user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-basedmarketplace 12. In one exemplary embodiment of the present invention, a buyer may be a user that has accumulated value (e.g., commercial or proprietary currency), and is then able to exchange the accumulated value for items that are offered for sale by the network-basedmarketplace 12. - The tables 90 also include an items table 94 in which are maintained item records for goods and services that are available to be, or have been, transacted via the
marketplace 12. Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92, so as to associate a seller and one or more actual or potential buyers with each item record. - A transaction table 96 contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94.
- An order table 98 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 96.
- Bid records within a bids table 100 each relate to a bid received at the network-based
marketplace 12 in connection with an auction-format listing supported by anauction application 44. A feedback table 102 is utilized by one ormore reputation applications 50, in one exemplary embodiment, to construct and maintain reputation information concerning users. A history table 104 maintains a history of transactions to which a user has been a party. One or more attributes tables 106 record attribute information pertaining to items for which records exist within the items table 94. Considering only a single example of such an attribute, the attributes tables 106 may indicate a currency attribute associated with a particular item, the currency attribute identifying the currency of a price for the relevant item as specified in by a seller. -
FIG. 4 provides a data flow diagram representing the flow of data in one embodiment of thesystem 1000 of the present invention.Sensitive customer data 1020 is received fromclients 22 by a sensitivecustomer data application 1100. The sensitivecustomer data application 1100 can be one of themarketplace applications 30 orpayment applications 32. The sensitivecustomer data application 1100 interacts withclients 22 over thenetwork 14 via a sensitive customerdata application interface 500. The sensitivecustomer data application 1100 connects with a symmetrickey generator 1070, which generates a symmetric key 1010 for thesensitive customer data 1020 being stored. Exemplary algorithms for generating symmetric keys and encrypting with them include the Data Encryption Standard (DES), Advanced Encryption Standard (AES), and several re-incarnations of DES, including triple-DES with Cipher Block Chaining (CBC). - A
public key encryptor 1030 receives the symmetric key 1010 generated by the symmetrickey generator 1070. Thepublic key encryptor 1030 is capable of encrypting thepublic key 1060 of an asymmetric key pair. Asymmetric key pairs include apublic key 1060 and a private key, and are used in asymmetric encryption algorithms that are well known in the art, including standards such as RSA, Digital Signature Standard (DSS), and Pretty Good Privacy (PGP). Thepublic key encryptor 1030 also receives (or has access to) thepublic key 1060, which may be stored in a protected device such as akeystore 1050. Thepublic key encryptor 1030 uses the asymmetric public key 1060 to encode the symmetric key 1010 as an asymmetric key encrypted symmetric key 2010. - A sensitive customer data encryptor 1040 is also shown to receive the symmetric key 1010. Additionally, the sensitive customer data encryptor 1040 receives
sensitive customer data 1020. The sensitive customer data encryptor 1040 uses the symmetric key 1010 to encode thesensitive customer data 1020 as encryptedsensitive customer data 2020. - A
secure container module 1080 places the encryptedsensitive data 2020 and the asymmetric key encrypted symmetric key 2010 in a self-describingdata structure 2000. In one embodiment, the self-describingdata structure 2000 is a well-formed XML document. In another embodiment, the self-describingdata structure 2000 comprises snippets of XML that are not well-formed. - After being placed in the self-describing
data structure 2000, the encryptedsensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored 1090 in one ormore databases 36, which are blind to thesensitive customer data 1020. -
FIG. 5 provides a diagrammatic view of an exemplary embodiment of the sensitive customerdata application interface 500 through whichsensitive customer data 1020 is received by the sensitivecustomer data application 1100. The sensitive customerdata application interface 500 contains several method calls 550, which it can utilize to set sensitive customer data values in thesystem 1000. Example method calls 550 which may be useful in thesystem 1000 includeSet_CC 510,Set_NI 520,Set_DD 530, and other method calls 540. - The Set_CC method call 510 is utilized by the sensitive
customer data application 1100 in order to safely and correctly accept and handlesensitive customer data 1020 in the form of credit card billing information. The Set_NI method call 520 is used by the sensitivecustomer data application 1100 in order to safely and correctly handlesensitive customer data 1020 in the form of national identification information. The Set_DD method call 530 is used by the sensitivecustomer data application 1100 in order to safely and correctly handlesensitive customer data 1020 in the form of direct debit information. Other method calls 540 can be used to handlesensitive customer data 1020 in other forms as is necessary. - In one embodiment of the self-describing
data structure 2000, an XML document is formed which contains several elements including AccountNumber, Encrypted Data, EncryptionMethod, KeyInfo, EncryptedKey, CipherData. These elements are all defined in the XML ENC standard, which makes this particular embodiment of the self-describing container standards compliant. - The text of an exemplary self-describing
data structure 2000, in the form of an XML document that follows the XML ENC standard follows: -
1 <?xml version=“1.0” encoding=“utf-8”?> 2 <AccountNumber> 3 <EncryptedData Type=“http://www.w3.org//2001/04/xmlenc#Content” xmins=“http://www.w3.org/2001/04/xmlenc#”> 4 <EncryptionMethod Algorithm= http://www.w3.org/2001/04/xmlenc#tripledes-cbc/> 5 <Keyinfo xmlns=“http://www.w3.org/2000/09/xmldsig#”> 6 <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”> 7 <EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-1_5/> 8 <Keyinfo xmlns= “http://www.w3.org/2000/09/xmldsig#”> 9 <KeyName> 1024bit_rsa</ KeyName> 10 </Keyinfo> 11 <CipherData> 12 <CipherValue>CI/VgARz2Wm/GI4YjPVfjjE2WbadJdllAUk/OyRd6xgoCBd4T BOJhGEk7Kx41IhR9Jjbvcf5W48+q/YkrTKnkiwZuHaqImdhqN XLKrqUNRlv0SdxTc9BhRM210kOGVuLhS70A+dmAm16HQbl4n3 X+Cz4nwdxK04Bxl9I514Qlhc= 13 </CipherValue> 14 < /CipherData> 15 </Encrypted Key> 16 </Keyinfo> 17 <CipherData> 18 <CipherValue>CUP8R4g3jRuA+npr8MMnH3gEJhEIVSe85r1OhzMtPpq= </CipherVaIue> 19 </CipherData> 20 </Encrypted Data> 21 </AccountNumber> - In the text shown above, the self-describing
data structure 2000 contains an asymmetric key encrypted symmetric key 2010 in the first <CipherData> element shown in lines 11-14 of the text. Additionally, this embodiment of the self-describingdata structure 2000 contains asymmetric key encryptedsensitive customer data 2020 in the second <Cipher Data> element shown in lines 17-19 of the text. As will be apparent to those skilled in the art, the self-describingdata structure 2000 is not required to contain any particular XML elements, nor is it required to be an XML document. It must simply have enough information to accurately describe itself, the information it contains, and the decryption algorithms and keys that must be used to decrypt the information it contains. -
FIG. 6 provides a diagrammatic representation of one embodiment of the flow of data from the self-describingdata structure 2000 to thedatabase 36, which is blind to thesensitive customer data 1020. In one embodiment, the symmetric key encodedsensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in a common table 120 of thedatabase 36. This table 120 may be one of the database tables 90 described above with reference toFIG. 3 , or it may be a table expressly allocated for storage of sensitive customer data. In one embodiment of the present invention, where the self-describingdata structure 2000 is an XML document, the entire XML document is stored in itsown field 160 of the table 120. In an alternate embodiment, the symmetric key encryptedsensitive customer data 2020 is stored in onefield 160 of the table 120, while the asymmetric key encrypted symmetric key 2010 is stored in anotherfield 170 of the table 120. In one exemplary embodiment the table 120 where the symmetric key encryptedsensitive customer data 2020 is stored contains several fields including onefield 160 where the symmetric key encrypted sensitive customer data is stored 2020, onefield 170 where the asymmetric key encrypted symmetric key 2010 is stored and other fields, 180, 190 where additional information used by thesystem 1000 is stored. -
FIG. 7 provides a diagrammatic representation of one embodiment of the flow of data from the self-describingdata structure 2000 to thedatabase 36, which is blind to thesensitive customer data 1020. In one embodiment, the symmetric key encryptedsensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in the different tables 120, 140 of adatabase 36. These tables 120, 140 may both be one of the database tables 90 described above with reference toFIG. 3 , or one or both of them may be tables not previously described. In one embodiment of the present invention, where the self-describingdata structure 2000 is an XML document, XML elements representing the symmetric key encryptedsensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 are stored in separate tables 120, 140 of the database. The tables 120, 140 may be linked to one another in a manner that represents the relationship between the symmetric key encryptedsensitive customer data 2020 and the asymmetric key encrypted symmetric key 2010 that encrypted it (2020). -
FIG. 8 provides a diagrammatic representation of one embodiment of the flow of data from thedatabase 36, which is blind to thesensitive customer data 1020 to theapplications sensitive customer data 1020. The asymmetric encrypted key 2010 and the encryptedsensitive customer data 2020 are received at thedecryption module 900. A second asymmetric key 1065 associated with the asymmetric key 1060 used by the asymmetrickey encryptor 1030 is also received by thedecryption module 900. In one embodiment, the second asymmetric key 1065 is a private key held in a protected device such as akeystore 1050. Thedecryption module 900 utilizes the second asymmetric key 1065 and algorithms well-known in the art to decrypt the encrypted symmetric key 2010 into the symmetric key 1010. - The
decryption module 900 then decrypts the symmetric key encryptedsensitive customer data 2020 with the symmetric key 1010. The recently unencryptedsensitive customer data 1020 is received byapplications applications -
FIG. 9 provides a flow chart view of one embodiment of the method to securely store customer data in a network-based commerce system. At afirst operation 600,sensitive customer data 1020 is received via anetwork connection 14 through anapplication interface 1100. At asecond operation 610, a symmetric key 1010 is generated. At thenext operation 620, thesensitive customer data 1020 is encoded with the symmetric key 1010 to generate encodedsensitive customer data 2020. At thenext operation 630, the symmetric key 1010 is encoded with an asymmetric key 1060 in order to generate an encoded symmetric key 2010. At thenext operation 640, the encodedsensitive customer data 2020 and the encoded symmetric key 2010 are placed in a self-describingdata structure 2000. At thenext operation 650, the encodedsensitive customer data 2020 and the encoded symmetric key 2010 are stored in adatabase 36. -
FIG. 10 shows a diagrammatic representation of machine in the exemplary form of acomputer system 300 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - The
exemplary computer system 300 includes a processor 302 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), amain memory 304 and astatic memory 306, which communicate with each other via abus 308. Thecomputer system 300 may further include a video display unit 310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 300 also includes an alphanumeric input device 312 (e.g., a keyboard), a cursor control device 314 (e.g., a mouse), adisk drive unit 316, a signal generation device 318 (e.g., a speaker) and anetwork interface device 320. - The
disk drive unit 316 includes a machine-readable medium 322 on which is stored one or more sets of instructions (e.g., software 324) embodying any one or more of the methodologies or functions described herein. Thesoftware 324 may also reside, completely or at least partially, within themain memory 304 and/or within theprocessor 302 during execution thereof by thecomputer system 300, themain memory 304 and theprocessor 302 also constituting machine-readable media. Thesoftware 324 may further be transmitted or received over a network 326 via thenetwork interface device 320. - While the machine-
readable medium 322 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. - Thus, a method and system to securely store customer data in a network-based commerce system have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Claims (26)
1. A system includes:
a customer data application to accept the customer data and, connected to a symmetric key generator, to generate a symmetric key;
a data encryptor to encrypt the customer data with the symmetric key to form encrypted customer data;
a key encryptor to encrypt the symmetric key with a public key to form an encrypted symmetric key; and
a secure container module to store the encrypted customer data.
2. The system of claim 1 , further includes a keystore for storing the public key.
3. The system of claim 1 , further includes a database to store the encrypted customer data and the encrypted symmetric key.
4. The system of claim 1 , wherein the secure container module is to store the encrypted customer data in a self-describing data structure, and wherein the self-describing data structure is an XML document.
5. The system of claim 4 , further includes a database to store the XML document.
6. The system of claim 5 , wherein the XML document is to store an indexed field in a database table.
7. A system includes:
means for receiving customer data from the client;
means for generating a symmetric key;
means for encrypting the customer data with the symmetric key to form encrypted customer data;
means for encrypting the symmetric key with a public key to form an encrypted symmetric key; and
means for storing the encrypted customer data and the encrypted symmetric key.
8. The system of claim 7 wherein the means for storing further includes storing the encrypted customer data and the encrypted symmetric key in a self-describing container in a database.
9. The system of claim 7 further including means for storing the encrypted symmetric key and the encrypted customer data in a database.
10. A computer readable medium comprising instructions, which when executed on a processor, cause the processor to perform a method comprising:
receiving customer data via a network connection;
generating a symmetric key;
encoding the customer data with the symmetric key to generate encoded customer data;
encoding the symmetric key with an asymmetric key to generate an encoded symmetric key; and
storing the encoded customer data and the encoded symmetric key.
11. A method including:
receiving customer data via a network connection;
generating a symmetric key;
encoding the customer data with the symmetric key to generate encoded customer data;
encoding the symmetric key with an asymmetric key to generate an encoded symmetric key; and
storing the encoded customer data and the encoded symmetric key.
12. The method of claim 11 , including obtaining the asymmetric key from a keystore.
13. The method of claim 11 , wherein the receiving the customer data via the network connection includes receiving the customer data via an application interface, and wherein the application interface is a payment application interface.
14. The method of claim 13 , wherein the receiving the customer data via the application interface includes receiving a national identification.
15. The method of claim 13 , wherein the customer data received via the application interface includes billing information.
16. The method of claim 13 , wherein the customer data received via the application interface includes direct debit information.
17. The method of claim 11 , wherein the customer data includes credit card information.
18. The method of claim 11 , wherein the network connection is an HTTPS connection.
19. The method of claim 11 , wherein the encoded customer data and the encoded symmetric key are stored in separate fields of a single table in a database.
20. The method of claim 19 , wherein the encoded customer data and the encoded symmetric key are stored in separate tables in the database.
21. The method of claim 11 , wherein the encoded customer data is stored in a database as an XML element.
22. The method of claim 11 , wherein the encoded symmetric key is stored in a database as an XML element.
23. The method of claim 11 , wherein the encoded customer data is stored in an indexed field in a database table.
24. The method of claim 11 , further including:
placing the encoded customer data and the encoded symmetric key in a self-describing data-structure and wherein the self-describing data structure is an XML document.
25. The method of claim 24 , wherein the XML document is stored in a database.
26. The method of claim 24 , wherein the XML document is stored in an indexed field of a database table.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/655,612 US20130060705A1 (en) | 2004-07-28 | 2012-10-19 | Method and system to securely store customer data in a network-based commerce system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/902,647 US8306920B1 (en) | 2004-07-28 | 2004-07-28 | Method and system to securely store customer data in a network-based commerce system |
US13/655,612 US20130060705A1 (en) | 2004-07-28 | 2012-10-19 | Method and system to securely store customer data in a network-based commerce system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/902,647 Continuation US8306920B1 (en) | 2004-07-28 | 2004-07-28 | Method and system to securely store customer data in a network-based commerce system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130060705A1 true US20130060705A1 (en) | 2013-03-07 |
Family
ID=47075540
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/902,647 Active 2029-12-18 US8306920B1 (en) | 2004-07-28 | 2004-07-28 | Method and system to securely store customer data in a network-based commerce system |
US13/655,612 Abandoned US20130060705A1 (en) | 2004-07-28 | 2012-10-19 | Method and system to securely store customer data in a network-based commerce system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/902,647 Active 2029-12-18 US8306920B1 (en) | 2004-07-28 | 2004-07-28 | Method and system to securely store customer data in a network-based commerce system |
Country Status (1)
Country | Link |
---|---|
US (2) | US8306920B1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103455914A (en) * | 2013-08-30 | 2013-12-18 | 深圳数字电视国家工程实验室股份有限公司 | Safety authentication method and remote controller and television payment system using same |
US9310981B2 (en) * | 2013-02-13 | 2016-04-12 | Dropbox, Inc. | Seamless editing and saving of online content items using applications |
CN105608577A (en) * | 2014-11-13 | 2016-05-25 | 乐金信世股份有限公司 | Method for performing non-repudiation, and payment managing server and user device therefor |
EP3513298A4 (en) * | 2016-09-15 | 2020-05-06 | Nuts Holdings, LLC | Encrypted userdata transit and storage |
US11558192B2 (en) | 2020-04-09 | 2023-01-17 | Nuts Holdings, Llc | NUTS: flexible hierarchy object graphs |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9147189B2 (en) * | 2009-08-20 | 2015-09-29 | Gilbarco Inc. | Secure reports for electronic payment systems |
US8473740B2 (en) * | 2011-05-09 | 2013-06-25 | Xerox Corporation | Method and system for secured management of online XML document services through structure-preserving asymmetric encryption |
DE102011118804A1 (en) * | 2011-08-05 | 2013-02-07 | Meiko Jensen | Persistent encryption with XML Encrytion |
US8694786B2 (en) * | 2011-10-04 | 2014-04-08 | International Business Machines Corporation | Virtual machine images encryption using trusted computing group sealing |
US8666992B2 (en) | 2012-06-15 | 2014-03-04 | Xerox Corporation | Privacy preserving method for querying a remote public service |
US9009469B2 (en) | 2013-01-15 | 2015-04-14 | Sap Se | Systems and methods for securing data in a cloud computing environment using in-memory techniques and secret key encryption |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6041123A (en) * | 1996-07-01 | 2000-03-21 | Allsoft Distributing Incorporated | Centralized secure communications system |
US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US20020002468A1 (en) * | 1998-08-13 | 2002-01-03 | International Business Machines Corporation | Method and system for securing local database file of local content stored on end-user system |
US20020049670A1 (en) * | 2000-10-06 | 2002-04-25 | Hitachi, Ltd. | Electronic payment method and system |
US20020150243A1 (en) * | 2001-04-12 | 2002-10-17 | International Business Machines Corporation | Method and system for controlled distribution of application code and content data within a computer network |
US20020184485A1 (en) * | 1999-12-20 | 2002-12-05 | Dray James F. | Method for electronic communication providing self-encrypting and self-verification capabilities |
US20030165241A1 (en) * | 2000-06-16 | 2003-09-04 | Fransdonk Robert W. | Method and system to digitally sign and deliver content in a geographically controlled manner via a network |
US20040003270A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Obtaining a signed rights label (SRL) for digital content and obtaining a digital license corresponding to the content based on the SRL in a digital rights management system |
US20040250085A1 (en) * | 2001-07-18 | 2004-12-09 | Oliver Tattan | Distributed network system using biometric authentication access |
US6981262B1 (en) * | 2000-06-27 | 2005-12-27 | Microsoft Corporation | System and method for client interaction in a multi-level rights-management architecture |
US20060015728A1 (en) * | 2004-07-14 | 2006-01-19 | Ballinger Keith W | Establishment of security context |
-
2004
- 2004-07-28 US US10/902,647 patent/US8306920B1/en active Active
-
2012
- 2012-10-19 US US13/655,612 patent/US20130060705A1/en not_active Abandoned
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6041123A (en) * | 1996-07-01 | 2000-03-21 | Allsoft Distributing Incorporated | Centralized secure communications system |
US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US20020002468A1 (en) * | 1998-08-13 | 2002-01-03 | International Business Machines Corporation | Method and system for securing local database file of local content stored on end-user system |
US20020184485A1 (en) * | 1999-12-20 | 2002-12-05 | Dray James F. | Method for electronic communication providing self-encrypting and self-verification capabilities |
US20030165241A1 (en) * | 2000-06-16 | 2003-09-04 | Fransdonk Robert W. | Method and system to digitally sign and deliver content in a geographically controlled manner via a network |
US6981262B1 (en) * | 2000-06-27 | 2005-12-27 | Microsoft Corporation | System and method for client interaction in a multi-level rights-management architecture |
US20020049670A1 (en) * | 2000-10-06 | 2002-04-25 | Hitachi, Ltd. | Electronic payment method and system |
US20020150243A1 (en) * | 2001-04-12 | 2002-10-17 | International Business Machines Corporation | Method and system for controlled distribution of application code and content data within a computer network |
US20040250085A1 (en) * | 2001-07-18 | 2004-12-09 | Oliver Tattan | Distributed network system using biometric authentication access |
US20040003270A1 (en) * | 2002-06-28 | 2004-01-01 | Microsoft Corporation | Obtaining a signed rights label (SRL) for digital content and obtaining a digital license corresponding to the content based on the SRL in a digital rights management system |
US20060015728A1 (en) * | 2004-07-14 | 2006-01-19 | Ballinger Keith W | Establishment of security context |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9310981B2 (en) * | 2013-02-13 | 2016-04-12 | Dropbox, Inc. | Seamless editing and saving of online content items using applications |
US10088990B2 (en) | 2013-02-13 | 2018-10-02 | Dropbox, Inc. | Seamless editing and saving of online content items using applications |
CN103455914A (en) * | 2013-08-30 | 2013-12-18 | 深圳数字电视国家工程实验室股份有限公司 | Safety authentication method and remote controller and television payment system using same |
CN105608577A (en) * | 2014-11-13 | 2016-05-25 | 乐金信世股份有限公司 | Method for performing non-repudiation, and payment managing server and user device therefor |
EP3513298A4 (en) * | 2016-09-15 | 2020-05-06 | Nuts Holdings, LLC | Encrypted userdata transit and storage |
US10671764B2 (en) | 2016-09-15 | 2020-06-02 | Nuts Holdings, Llc | NUTS: eNcrypted Userdata Transit and Storage |
US11003802B2 (en) | 2016-09-15 | 2021-05-11 | Nuts Holdings, Llc | NUTS: eNcrypted userdata transit and storage |
US11010496B2 (en) | 2016-09-15 | 2021-05-18 | Nuts Holdings, Llc | Structured data folding with transmutations |
US11720716B2 (en) | 2016-09-15 | 2023-08-08 | Nuts Holdings, Llc | Structured data folding with transmutations |
US11558192B2 (en) | 2020-04-09 | 2023-01-17 | Nuts Holdings, Llc | NUTS: flexible hierarchy object graphs |
Also Published As
Publication number | Publication date |
---|---|
US8306920B1 (en) | 2012-11-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20130060705A1 (en) | Method and system to securely store customer data in a network-based commerce system | |
US20220129866A1 (en) | Method and system for a secure registration | |
US20100070419A1 (en) | System and method to initiate a function with an email message | |
US7860784B2 (en) | Method and system for user payment account management | |
US10972273B2 (en) | Securing authorization tokens using client instance specific secrets | |
CA2973066C (en) | Payment application framework | |
US20160110715A1 (en) | Method and system for dynamic funding | |
US8225387B2 (en) | Method and system for access authentication | |
US10979404B2 (en) | Systems and methods for inspecting communication within an encrypted session | |
US20080133390A1 (en) | System and method for authorizing a transaction | |
US20080162295A1 (en) | Method and system for payment authentication | |
US20090265252A1 (en) | Money pooling with electronic invoice | |
US20150347207A1 (en) | Asynchronous messaging bus | |
US20150007277A1 (en) | Method and system for notification and request processing | |
US20100121649A1 (en) | Methods and systems for user registration | |
US20120054321A1 (en) | Method and system to deliver a digital good | |
AU2013205573B2 (en) | Payment application framework | |
AU2015275318A1 (en) | Payment application framework |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EBAY INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LYNCH, LIAM SEAN;REEL/FRAME:034863/0870 Effective date: 20050223 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |