US20030105965A1 - Business method for secure installation of a credit authorization key on a remote tcpa compliant system - Google Patents
Business method for secure installation of a credit authorization key on a remote tcpa compliant system Download PDFInfo
- Publication number
- US20030105965A1 US20030105965A1 US10/248,791 US24879103A US2003105965A1 US 20030105965 A1 US20030105965 A1 US 20030105965A1 US 24879103 A US24879103 A US 24879103A US 2003105965 A1 US2003105965 A1 US 2003105965A1
- Authority
- US
- United States
- Prior art keywords
- network
- tpm
- certificate
- key
- remote device
- 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
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/24—Credit schemes, i.e. "pay after"
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/342—Cards defining paid or billed services or quantities
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
- G06Q20/3552—Downloading or loading of personalisation data
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
- G06Q20/3558—Preliminary personalisation for transfer to user
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- 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
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0609—Buyer or seller confidence or verification
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
- G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
Definitions
- the present invention relates in general to data processing systems, and in particular, to enabling secure communications over data processing networks.
- One current method for obtaining a credit card from a credit card company on- line is for the user to fill out a credit card application at the credit card company's website, and then if approved, the credit card company will send a physical credit card to the user who can then activate the credit card by calling a toll-free number from the user's home phone.
- credit card theft is abundant, and according to some reports, accounts for half of the monetary loss of the credit card companies.
- the present invention makes use of the TCPA (Trusted Computing Platform Alliance) Specification to allow a company to remotely install an authorization private key into a TCPA module in a way that the company can be assured it is going to a trusted TPM (Trusted Platform Module). While the invention is not limited to credit card companies, the most detailed examples shown are for credit card companies. In the specific case of a credit card company, when a user applies for a credit card, the credit card company will first determine if the person is credit worthy. Assuming they are, then the user will send the credit card company a public portion of a "non-migratable storage key," which is accredited a TPM which is in turn endorsed by a Certification Authority (CA).
- CA Certification Authority
- the private portion of the "non-migratable storage key” is known to be a key that was created inside the TPM, and cannot be exported from the TPM.
- the credit card company will now create its own public/private key pair according to the TCPA Specification, using whatever size key it desires, create a TCPA header, and wrap the full structure by encrypting it with the public portion of the TCPA non-migratable storage key.
- the credit card company will then send by email to the person the encrypted bundle and a certificate for it, and via "snail mail," a pass phrase that is hashed to provide usage of the encrypted bundle on the person's system.
- the present invention provides for an interaction between the credit card company and the user in a way so that the credit card company is assured that a private key used by a user is used to the same degree that the user uses a physical credit card. That is, an embodiment of the present invention establishes a similar level of trust for a credit card authorization over the Internet as presently exists for transactions using physical credit cards in stores.
- the credit card company can be its own certification authority.
- An advantage of the present invention is that only one user computer can use the encrypted bundle sent by the credit card company, which will reduce the amount of fraud by use of credit cards in e-commerce transactions.
- Another advantage of the present invention is that the certificate can easily be checked against the credit card company's database for revocation. Using this type of signature instead of a credit card number precludes someone from charging a credit card multiple times, and also precludes someone keeping a database of credit card numbers to be exposed to a hacker accessing such numbers.
- FIGURE 1 illustrates a data processing system configured in accordance with an embodiment of the present invention
- FIGURE 2 illustrates a flow diagram configured in accordance with an embodiment of present invention
- FIGURE 3 illustrates a network configured in accordance with an embodiment of present invention.
- FIGURE 4 illustrates a business method in accordance with an embodiment of the present invention.
- FIGURE 3 there is illustrated a configuration of a network 300 in accordance with the present invention where a user (customer) computer 301 applies for a credit card authorization from a credit card company server 302 over the Internet 303.
- FIGURE 1 there is illustrated exemplary data processing system 113 configured in accordance with the present invention, whereby system 113 could be used for the user computer 301, the credit card company server 302, and any and all servers used in the Internet 303 to communicate data between computer 301 and server 302.
- the system 113 has a central processing unit (CPU) 110, which is coupled to various other components by system bus 112.
- Read-only memory (“ROM”) 116 is coupled to the system bus 112 and includes a basic input/output system (“BIOS”) that controls certain basic functions of the data processing system 113.
- RAM random access memory
- I/O adapter 118 may be a small computer system interface (“SCSI") adapter that communicates with a disk storage device 120.
- Communications adapter 134 interconnects bus 112 with an outside network 160 (e.g., the Internet 303) enabling the data processing system to communicate with other such systems.
- an outside network 160 e.g., the Internet 303
- Input/Output devices are also connected to system bus 112 via user interface adapter 122 and display adapter 136.
- Keyboard 124 and mouse 126 are all interconnected to bus 112 via user interface adapter 122.
- Display monitor 138 is connected to system bus 112 by display adapter 136. In this manner, a user is capable of inputting to the system 113 throughout the keyboard 124 or mouse 126 and receiving output from the system via display 138.
- Implementations of the invention include implementations as a computer system programmed to execute the method or methods described herein, and as a computer program product.
- sets of instructions for executing the method or methods may be resident in the random access memory 114 of one or more computer systems configured generally as described above.
- the set of instructions may be stored as a computer program product in another computer memory, for example, in disk drive 120 (which may include a removable memory such as an optical disk or floppy disk for eventual use in the disk drive 120).
- the computer program product can also be stored at another computer and transmitted when desired to the user's workstation by a network or by an external network such as the Internet 303.
- the physical storage of the sets of instructions physically changes the medium upon which it is stored so that the medium carries computer readable information.
- the change may be electrical, magnetic, chemical, biological, or some other physical change. While it is convenient to describe the invention in terms of instructions, symbols, characters, or the like, the reader should remember that all of these and similar terms should be associated with the appropriate physical elements.
- the invention may describe terms such as comparing, validating, selecting, identifying, or other terms that could be associated with a human operator.
- terms such as comparing, validating, selecting, identifying, or other terms that could be associated with a human operator.
- no action by a human operator is desirable.
- the operations described are, in large part, machine operations processing electrical signals to generate other electrical signals.
- FIGURE 2 there is illustrated a flow diagram of a process configured in accordance with an embodiment of the present invention where a potential credit card customer desires to receive an embedded credit card authorization within the customer's computer system 301.
- the customer will create a TPM identity per the TCPA Specification and obtain a certificate for it.
- the TCPA Specification is published at www.trustedpc.org/home/home.htm, as Version 1.1b, which is hereby incorporated by reference herein.
- P1 Only the public portion of that endorsement key, P1, is ever released from the chip, and is released to the manufacturer.
- the manufacturer of the TPM signs a certificate, C1, that goes along with the TPM.
- the certificate, C1 can be retrieved by a user over the Internet from the manufacturer.
- This certificate, C1 is tied to the public portion of the endorsement key, P1, that determines that the public key is the endorsement key of this particular TPM.
- This endorsement key, P1, is used for decrypting.
- a TPM identity is created in step 201, which is a special kind of private key.
- a TPM identity can be created by the customer, such as with a DOS command, and the TPM identity is the public portion of a public/private key pair.
- the public key, P2, of the TPM identity and the certificate, C1, tied to the public portion of the endorsement key, P1, are then sent over the Internet to a Certificate Authority (CA).
- CA Certificate Authority
- the CA checks the accuracy of the certificate, C1, signed by the manufacturer.
- the CA can perform this check by looking in a database at the manufacturer's website.
- the CA then makes a certificate, C2, for the TPM identity, P2, and encrypts the certificate, C2, and bundles it with the public key, P2, of the TPM identity sent by the customer. This second bundle is then encrypted with the public endorsement key, P1, of the TPM.
- the second bundle is then returned to the customer by the CA, which is then decrypted by the TPM with the private portion of the endorsement key, P3. This protects from unauthorized requests for certificates from a CA.
- the TPM will then decrypt the first bundle with the private key, P4, of its TPM identity to obtain the certificate, C2, issued by the CA.
- the result is a TPM identity that has been signed by a CA.
- step 202 the customer with create a non-migratable key.
- the TCPA Specification has two types of keys used to store other keys. The first type is "migratable," and the owner of the system is able to move such keys to other systems, as long as the owner knows the correct authorization data. It is possible to move such keys to insecure systems this way, and hence, migratable keys can be exposed by the owner of the system. This may or may not be a problem to a credit card company. Currently, a consumer exposes his key to a seller every time he shows his credit card, so currently, there is no requirement that keys be kept out of the hands of the customer. "Non-migratable" keys are locked to the hardware in a way that they cannot be cloned or migrated to another system even by the owner. They are thus inherently more secure.
- the customer creates a non-migratable storage key, K1, that may be a 2048-bit RSA key.
- K1 A storage key is used for encrypting other keys so that the TPM can read them (i.e., a storage key decrypts items into the TPM).
- the customer may use the CreateWrapKey function of the TCPA Specification. There may also be a piece of software that does this for the user in a user-friendly way. The customer will then decide if the key, K1, will require authorization or not, and what that authorization would be.
- the customer decides if he wants to require authorization for use and if so, what pass phrase to use to provide the authorization.
- Software can be used to require authorization using some other type of means instead of a pass phrase, such as through the use of biometrics.
- the customer also decides what parent will be used for storing this key (the SRK (storage root key) is available).
- the parent key is a key used to store another key.
- the key stored is called a child, while the key used to do the storing is called the parent.
- the parent In particular, if there are two key pairs, Private One, Public One and Private Two, Public Two, if Private Two is encrypted with Public One, then the first key pair would be referred to as the parent and the second key pair the child.
- the storage root key there is one key that is guaranteed to always be loaded inside the chip. It is called the storage root key, and it is an ancestor of every other key the chip can use. To load a key into the chip, it needs to have its parent's private key already loaded in the chip (so the chip can decrypt it). If the SRK is the great grandparent of a key, first one would need to load the grandparent of a key in the chip, then the parent of the key into the chip, and finally the key itself into the chip. This structure, called a daisy chain, is used to allow a TCPM chip to "store" an unlimited number of keys. The customer will then execute a TPM_CreateWrapKey command, with required parameters indicating the key produced will be a storage key. The customer then signs the non-migratable storage key, K1, with the TPM identity key, P2, creating a certificate, C3, for that non-migratable storage key.
- step 202 the customer creates a non-migratable signing key, K2, with the TPM_CreateWrapKey command, wherein the key may be a 2048-bit RSA key.
- Signing keys can be used by the TPM to sign the hash of a message (i.e., encrypt the hash of a message).
- the customer decides if this signing key, K2, will require authorization or not, and what that authorization will be.
- the customer decides what parent will be used for storing this key (the SRK is available).
- the customer signs the non-migratable signing key, K2, with the TPM identity key, P2, creating a certificate, C4, for that key, K2.
- step 203 the customer contacts a credit card company over the Internet by browsing the credit card company's website.
- step 204 the customer applies for a credit card authorization at the credit card company website by entering into a secure section of that website to fill out an application form.
- SSL Secure Sockets Layer
- SSL is a means of creating encrypted communication between a user and a web site for entering a credit card without snoopers being able to access the number.
- the customer fills out the application form with his name, address and whatever other information the credit card company requires to determine whether the customer is credit worthy.
- step 205 under the first alternative embodiment described above where the customer creates a non-migratable storage key, K1, the customer will provide to the credit card company the non-migratable public portion of the storage key, K1, the certificate, C3, by the TPM identity that the RSA storage key is a non-migratable TPM key, the certificate, C2, from the CA that the TPM identity is indeed a TPM identity, and a pass phrase the customer would like to use for authorizing use of the requested credit card authorization. It is at this point that the credit card company can evaluate the requested pass phrase and turn it down if it appears to be too trivial.
- step 205 If the customer had created a non-migratable signing key, K2, under the second alternative embodiment described above with respect to step 202, the customer will provide to credit card company in step 205 that non-migratable public portion of that signing key, K2, the certificate, C4, by the TPM identity that the signing key is a non-migratable TPM key, and the certificate, C2, from the CA that the TPM identity is indeed a TPM identity.
- the pass phrase is chosen by the user, but is never provided to the credit card company.
- step 206 the credit card company determines the credit worthiness of the customer, and assuming the customer is credit worthy, the credit card company then checks the TPM identity certificate, C2, to see the level of security inherent in the TPM system to determine if that is sufficient to proceed. The credit card company may also check to see if the TPM identity certificate, C2, has been revoked by the CA that issued it.
- step 207 the credit card company creates a public/private key pair, P5, and a certificate, C5, to send to the customer. If the customer had previously sent a non-migratable storage key, K1, under the first alternative discussed above, then the credit card company will perform the following procedure.
- the credit card company will create the public/private key pair, P5, which may be a 2048-bit RSA key. If the credit card company wants to use a different kind of key, the TPM identity certificate, C2, will have to be checked to see if the TPM supports such a different kind of key.
- the credit card company will then create a header for the key, P5, using the format defined in the TCPA Specification, which is hereby incorporated by reference herein.
- the header is created using the SHA-1 hash of the pass phrase selected by the customer, a migration pass phrase the credit card company generates, and creating a TCPA key bundle wrapping the key, P5, in the public key, K1, the customer gave the credit card company.
- the credit card company can create the header by using its own TCPA chip by commanding it to create a migratable key using the requisite pass phrases and choosing its own storage key (of any sort) for its own TPM, and then migrating that key to the customer's TPM public key, K1. If the credit card company performs this process, it must pass the end user the bundle and the random number that is used for this transition.
- the credit card company then creates its own certificate, C5, for the public key, P5, it created.
- the credit card company mails (traditional mail services) a diskette with the bundle stored on it to the verified address of the customer.
- the credit card company emails or mails the bundle to the customer (thus allowing verification of address) and either mails the random number to the customer with the bundle, or mails the random number to the end user separately, or mails the end user a 1-800 telephone number to call in order to get the random number (thus allowing verification of telephone number).
- the credit card company certifies the public key it has been sent and sends the certificate to the mailing address (proving verification of address) on a diskette. If the credit card company also wants to verify the telephone number, the certificate can be encrypted, for example X-ored with the SHA-1 hash of a pass phrase which is delivered over the phone.
- step 208 the customer now has a private key pair which can only be used on the customer's computer system using a pass phrase the customer was allowed to choose, and which has a certificate of the credit card company.
- the credit card company can revoke the certificate whenever it wants.
- a credit card company can perform a self-certification for a received non-migratable storage key.
- the customer of the system takes the certificate, C1, that was signed by the manufacturer of the system. This includes information regarding the security level the system was designed to as well as a certificate from the manufacturer of the TPM chip itself and a copy of P1, the endorsement public key from the TPM.
- the customer also asks the TPM (through a standard command) to generate a "TPM identity," a 2048-bit RSA signing key.
- the TPM returns the public portion of that key, P2.
- the customer takes P2 and the Certificate, C1, for the system and sends them to the credit card manufacturer.
- the credit card company verifies the certificate using the public keys of the manufacturer of both the TPM and the system and then provides a certificate, C6, for P2. However, the credit card company encrypts this certificate, C6, using P1 (as per the TCPA Specification). This encrypted certificate is sent back to the customer of the system. The customer sends the encrypted certificate, C6, to his TPM, (reloading the TPM identity key if necessary). The TPM checks the certificate against the identity key making certain that they match. If they do, the TPM exports enough information to decrypt the credit card company's certificate, C6, for that key.
- the customer requests his TPM to produce a non-migratable storage key (or non-migratable signing key depending on which alternative he is taking).
- the TPM returns the public portion of the key.
- the customer requests the TPM to sign the public portion of the non-migratable key in the last step with his identity.
- the TPM does this, providing an identity certificate that it is a non-migratable (storage or signing) key.
- the customer then sends the public portion of the non-migratable key, its identity-based certificate, and the credit card company certificate, C6, for the identity, back to the credit card company, which can then use its own certification of the quality of the non-migratable key.
- a remote entity can install a private key on a remote user's Trusted Platform Module (TPM) associated with the remote user's computer system.
- TPM Trusted Platform Module
- the embodiment provides for secure usage of the key while retaining the key's transfer within the control of the remote entity.
- This embodiment provides a method for conducting business by which a company, such as a credit card company, creates a private signature key (which would represent a credit card in the example which follows) and transfers the key to an end user in a way that (i) preserves security, (ii) preserves control over the locale or locales where the key is to be used - for example, restricting the locale to the remote entity's locale (so that the remote entity can restrict the usage of the key to secure environments), and (iii) preserve control over the usage of the key - for example, restricting usage to the end user (so that only the designated end user can use the credit card).
- a company such as a credit card company, creates a private signature key (which would represent a credit card in the example which follows) and transfers the key to an end user in a way that (i) preserves security, (ii) preserves control over the locale or locales where the key is to be used - for example, restricting the locale to the remote entity's locale (so that the
- a credit card company deploying a credit card product is shown as employing the method of doing business of this embodiment.
- the end product need not be a credit card, it can be a debit card or a general bank card used for all types of transactions.
- the example given below is not meant to be limiting in any way.
- the company can be a trust management company and the product can be a trust or will where authentication is given for power of attorney.
- the company can be an cable television company and the product a cable subscription service such as pay per view.
- the company may be an insurance provider and the product a medical benefits dispersion. In short, a provider benefits by the teachings of this embodiment for secure authentication for anything having good and valuable consideration.
- step 404 the credit card company 402 receives a credit card private key request from an end user 401 when end user 401 applies for a credit card private key.
- step 405 the credit card company 402 checks that the Applicant is qualified to receive the credit card key.
- This checking step 405 can be for example the checking of the end user's 401 credit worthiness.
- the checking step 405 can be to check whether the end user has an existing account etc.
- the credit card company 402 Upon qualification, in step 407, the credit card company 402 requests of the end user's 401 Trusted Platform Module (TPM) associated with the end user's 401 computer system a secure non-migratable storage key.
- TPM Trusted Platform Module
- the credit card company 402 receives the secure non-migratable storage key generated by end user's 401 Trusted Platform Module.
- the customer may use the CreateWrapKey function of the TCPA Specification as described hereinabove.
- the secure non-migratable storage key is received along with any of the following:
- Steps 409 and 410 are optionally utilized when it is the items of (C) which are received.
- the credit card company 402 creates a certificate for the TPM identity key, encrypts the certificate as per the TCPA specification / TPM specification - as in for example key1, and sends key1 back to the user encrypted in a blob containing the public identity key and encrypted with the public endorsement key.
- steps 409 and 410 are required, processing continues with step 410.
- a decrypted identity certificate is received by the credit card company 402.
- This decrypted identity certificate is generated as a result of the end user 401 utilizing the TPM associated with end user's 401 computer system to decrypt the TPM identity key certificate; which, in turn, utilizes the provided endorsement private key to decrypt the key used to decrypt the certificate - but only if the TPM identity key matches the identity key generated by that TPM.
- the credit card company 402 Upon verification that the storage key is a TPM non-migratable key, and hence secure, the credit card company 402 creates a pair of public credit card private keys, and
- step 412 the user 401 waits to receive the code word necessary to use the key via a secure channel to the user.
- the secure channel can be:
- VPN virtual private network
Abstract
Description
- This application is a continuation-in-part of application Serial No. 09/851956 entitled System and Method for Installing a Remote Credit Card Authorization on a System with a TCPA Complaint Chipset.
- The present invention relates in general to data processing systems, and in particular, to enabling secure communications over data processing networks.
- The Internet provides a new arena for electronic commerce in which credit card companies are very interested. Quite naturally, since "commerce" is a necessary part of e-commerce, it stands to note that providing for the transfer of funds and credit during e-commerce transactions bodes well for those credit card companies that can securely provide for such transactions. One of the main concerns that continues with respect to e-commerce is the lack of trust that the consuming public has in the security of such transactions to protect their credit card and banking accounts.
- One current method for obtaining a credit card from a credit card company on- line is for the user to fill out a credit card application at the credit card company's website, and then if approved, the credit card company will send a physical credit card to the user who can then activate the credit card by calling a toll-free number from the user's home phone. However, credit card theft is abundant, and according to some reports, accounts for half of the monetary loss of the credit card companies.
- To eliminate the need for a physical credit card, another prior art method is to send to the user a smartcard for use in on-line transactions. However, the problem with a smartcard is one of expense, since use of a smartcard requires a smartcard reader to be installed on the user's computer.
- As a result, there is a need in the art for a less expensive but reliable and secure process for enabling users to obtain a credit card authorization that they can use on their computer for facilitating purchases over the Internet.
- The present invention makes use of the TCPA (Trusted Computing Platform Alliance) Specification to allow a company to remotely install an authorization private key into a TCPA module in a way that the company can be assured it is going to a trusted TPM (Trusted Platform Module). While the invention is not limited to credit card companies, the most detailed examples shown are for credit card companies. In the specific case of a credit card company, when a user applies for a credit card, the credit card company will first determine if the person is credit worthy. Assuming they are, then the user will send the credit card company a public portion of a "non-migratable storage key," which is accredited a TPM which is in turn endorsed by a Certification Authority (CA). The private portion of the "non-migratable storage key" is known to be a key that was created inside the TPM, and cannot be exported from the TPM. The credit card company will now create its own public/private key pair according to the TCPA Specification, using whatever size key it desires, create a TCPA header, and wrap the full structure by encrypting it with the public portion of the TCPA non-migratable storage key. The credit card company will then send by email to the person the encrypted bundle and a certificate for it, and via "snail mail," a pass phrase that is hashed to provide usage of the encrypted bundle on the person's system. The present invention provides for an interaction between the credit card company and the user in a way so that the credit card company is assured that a private key used by a user is used to the same degree that the user uses a physical credit card. That is, an embodiment of the present invention establishes a similar level of trust for a credit card authorization over the Internet as presently exists for transactions using physical credit cards in stores.
- In one alternative embodiment of the present invention, the credit card company can be its own certification authority.
- An advantage of the present invention is that only one user computer can use the encrypted bundle sent by the credit card company, which will reduce the amount of fraud by use of credit cards in e-commerce transactions. Another advantage of the present invention is that the certificate can easily be checked against the credit card company's database for revocation. Using this type of signature instead of a credit card number precludes someone from charging a credit card multiple times, and also precludes someone keeping a database of credit card numbers to be exposed to a hacker accessing such numbers.
- The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.
- For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
- FIGURE 1 illustrates a data processing system configured in accordance with an embodiment of the present invention;
- FIGURE 2 illustrates a flow diagram configured in accordance with an embodiment of present invention; and
- FIGURE 3 illustrates a network configured in accordance with an embodiment of present invention.
- FIGURE 4 illustrates a business method in accordance with an embodiment of the present invention.
- In the following description, numerous specific details are set forth such as encryption methods or key lengths, etc. to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details concerning timing considerations and the like have been omitted in as much as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art.
- Referring to FIGURE 3, there is illustrated a configuration of a
network 300 in accordance with the present invention where a user (customer)computer 301 applies for a credit card authorization from a creditcard company server 302 over the Internet 303. - Referring to FIGURE 1, there is illustrated exemplary
data processing system 113 configured in accordance with the present invention, wherebysystem 113 could be used for theuser computer 301, the creditcard company server 302, and any and all servers used in the Internet 303 to communicate data betweencomputer 301 andserver 302. - The
system 113 has a central processing unit (CPU) 110, which is coupled to various other components bysystem bus 112. Read-only memory ("ROM") 116 is coupled to thesystem bus 112 and includes a basic input/output system ("BIOS") that controls certain basic functions of thedata processing system 113. Random access memory ("RAM") 114, I/O adapter 118, and communications adapter 134 are also coupled to thesystem bus 112. I/O adapter 118 may be a small computer system interface ("SCSI") adapter that communicates with adisk storage device 120. Communications adapter 134interconnects bus 112 with an outside network 160 (e.g., the Internet 303) enabling the data processing system to communicate with other such systems. Input/Output devices are also connected tosystem bus 112 viauser interface adapter 122 anddisplay adapter 136. Keyboard 124 andmouse 126 are all interconnected tobus 112 viauser interface adapter 122.Display monitor 138 is connected tosystem bus 112 bydisplay adapter 136. In this manner, a user is capable of inputting to thesystem 113 throughout thekeyboard 124 ormouse 126 and receiving output from the system viadisplay 138. - Implementations of the invention include implementations as a computer system programmed to execute the method or methods described herein, and as a computer program product. According to the computer system implementation, sets of instructions for executing the method or methods may be resident in the
random access memory 114 of one or more computer systems configured generally as described above. Until required by the computer system, the set of instructions may be stored as a computer program product in another computer memory, for example, in disk drive 120 (which may include a removable memory such as an optical disk or floppy disk for eventual use in the disk drive 120). Further, the computer program product can also be stored at another computer and transmitted when desired to the user's workstation by a network or by an external network such as the Internet 303. One skilled in the art would appreciate that the physical storage of the sets of instructions physically changes the medium upon which it is stored so that the medium carries computer readable information. The change may be electrical, magnetic, chemical, biological, or some other physical change. While it is convenient to describe the invention in terms of instructions, symbols, characters, or the like, the reader should remember that all of these and similar terms should be associated with the appropriate physical elements. - Note that the invention may describe terms such as comparing, validating, selecting, identifying, or other terms that could be associated with a human operator. However, for at least a number of the operations described herein which form part of at least one of the embodiments, no action by a human operator is desirable. The operations described are, in large part, machine operations processing electrical signals to generate other electrical signals.
- Referring to FIGURE 2, there is illustrated a flow diagram of a process configured in accordance with an embodiment of the present invention where a potential credit card customer desires to receive an embedded credit card authorization within the customer's
computer system 301. Instep 201, the customer will create a TPM identity per the TCPA Specification and obtain a certificate for it. The TCPA Specification is published at www.trustedpc.org/home/home.htm, as Version 1.1b, which is hereby incorporated by reference herein. When a TPM is manufactured, its own endorsement key is generated and placed into nonvolatile memory inside the TPM chip. Only the public portion of that endorsement key, P1, is ever released from the chip, and is released to the manufacturer. The manufacturer of the TPM signs a certificate, C1, that goes along with the TPM. Alternatively, the certificate, C1, can be retrieved by a user over the Internet from the manufacturer. This certificate, C1, is tied to the public portion of the endorsement key, P1, that determines that the public key is the endorsement key of this particular TPM. This endorsement key, P1, is used for decrypting. - As noted above, a TPM identity is created in
step 201, which is a special kind of private key. A TPM identity can be created by the customer, such as with a DOS command, and the TPM identity is the public portion of a public/private key pair. - The public key, P2, of the TPM identity and the certificate, C1, tied to the public portion of the endorsement key, P1, are then sent over the Internet to a Certificate Authority (CA). This may be authorized by the user as a result of a user command. The CA checks the accuracy of the certificate, C1, signed by the manufacturer. The CA can perform this check by looking in a database at the manufacturer's website. The CA then makes a certificate, C2, for the TPM identity, P2, and encrypts the certificate, C2, and bundles it with the public key, P2, of the TPM identity sent by the customer. This second bundle is then encrypted with the public endorsement key, P1, of the TPM.
- The second bundle is then returned to the customer by the CA, which is then decrypted by the TPM with the private portion of the endorsement key, P3. This protects from unauthorized requests for certificates from a CA. The TPM will then decrypt the first bundle with the private key, P4, of its TPM identity to obtain the certificate, C2, issued by the CA. The result is a TPM identity that has been signed by a CA.
- In
step 202, the customer with create a non-migratable key. The TCPA Specification has two types of keys used to store other keys. The first type is "migratable," and the owner of the system is able to move such keys to other systems, as long as the owner knows the correct authorization data. It is possible to move such keys to insecure systems this way, and hence, migratable keys can be exposed by the owner of the system. This may or may not be a problem to a credit card company. Currently, a consumer exposes his key to a seller every time he shows his credit card, so currently, there is no requirement that keys be kept out of the hands of the customer. "Non-migratable" keys are locked to the hardware in a way that they cannot be cloned or migrated to another system even by the owner. They are thus inherently more secure. - In one alternative embodiment of
step 202, the customer creates a non-migratable storage key, K1, that may be a 2048-bit RSA key. A storage key is used for encrypting other keys so that the TPM can read them (i.e., a storage key decrypts items into the TPM). To create a non-migratable storage key, the customer may use the CreateWrapKey function of the TCPA Specification. There may also be a piece of software that does this for the user in a user-friendly way. The customer will then decide if the key, K1, will require authorization or not, and what that authorization would be. When the key is created, the customer decides if he wants to require authorization for use and if so, what pass phrase to use to provide the authorization. Software can be used to require authorization using some other type of means instead of a pass phrase, such as through the use of biometrics. The customer also decides what parent will be used for storing this key (the SRK (storage root key) is available). The parent key is a key used to store another key. The key stored is called a child, while the key used to do the storing is called the parent. In particular, if there are two key pairs, Private One, Public One and Private Two, Public Two, if Private Two is encrypted with Public One, then the first key pair would be referred to as the parent and the second key pair the child. Further, there is one key that is guaranteed to always be loaded inside the chip. It is called the storage root key, and it is an ancestor of every other key the chip can use. To load a key into the chip, it needs to have its parent's private key already loaded in the chip (so the chip can decrypt it). If the SRK is the great grandparent of a key, first one would need to load the grandparent of a key in the chip, then the parent of the key into the chip, and finally the key itself into the chip. This structure, called a daisy chain, is used to allow a TCPM chip to "store" an unlimited number of keys. The customer will then execute a TPM_CreateWrapKey command, with required parameters indicating the key produced will be a storage key. The customer then signs the non-migratable storage key, K1, with the TPM identity key, P2, creating a certificate, C3, for that non-migratable storage key. - In another alternative embodiment of
step 202, the customer creates a non-migratable signing key, K2, with the TPM_CreateWrapKey command, wherein the key may be a 2048-bit RSA key. Signing keys can be used by the TPM to sign the hash of a message (i.e., encrypt the hash of a message). The customer decides if this signing key, K2, will require authorization or not, and what that authorization will be. The customer decides what parent will be used for storing this key (the SRK is available). The customer executes the TPM_CreateWrapKey command, with required parameters indicating the key, K2, will be a signing key. And then, the customer signs the non-migratable signing key, K2, with the TPM identity key, P2, creating a certificate, C4, for that key, K2. - In
step 203, the customer contacts a credit card company over the Internet by browsing the credit card company's website. Instep 204, the customer applies for a credit card authorization at the credit card company website by entering into a secure section of that website to fill out an application form. This implies a Secure Sockets Layer (SSL) to prove to the customer that the information he is giving the credit card company is not snoopable, and a certificate to prove to the customer he is indeed at the credit card company's web site. SSL is a means of creating encrypted communication between a user and a web site for entering a credit card without snoopers being able to access the number. The customer fills out the application form with his name, address and whatever other information the credit card company requires to determine whether the customer is credit worthy. - In
step 205, under the first alternative embodiment described above where the customer creates a non-migratable storage key, K1, the customer will provide to the credit card company the non-migratable public portion of the storage key, K1, the certificate, C3, by the TPM identity that the RSA storage key is a non-migratable TPM key, the certificate, C2, from the CA that the TPM identity is indeed a TPM identity, and a pass phrase the customer would like to use for authorizing use of the requested credit card authorization. It is at this point that the credit card company can evaluate the requested pass phrase and turn it down if it appears to be too trivial. - If the customer had created a non-migratable signing key, K2, under the second alternative embodiment described above with respect to step 202, the customer will provide to credit card company in
step 205 that non-migratable public portion of that signing key, K2, the certificate, C4, by the TPM identity that the signing key is a non-migratable TPM key, and the certificate, C2, from the CA that the TPM identity is indeed a TPM identity. In this embodiment, the pass phrase is chosen by the user, but is never provided to the credit card company. - In
step 206, the credit card company determines the credit worthiness of the customer, and assuming the customer is credit worthy, the credit card company then checks the TPM identity certificate, C2, to see the level of security inherent in the TPM system to determine if that is sufficient to proceed. The credit card company may also check to see if the TPM identity certificate, C2, has been revoked by the CA that issued it. - In
step 207, the credit card company creates a public/private key pair, P5, and a certificate, C5, to send to the customer. If the customer had previously sent a non-migratable storage key, K1, under the first alternative discussed above, then the credit card company will perform the following procedure. The credit card company will create the public/private key pair, P5, which may be a 2048-bit RSA key. If the credit card company wants to use a different kind of key, the TPM identity certificate, C2, will have to be checked to see if the TPM supports such a different kind of key. The credit card company will then create a header for the key, P5, using the format defined in the TCPA Specification, which is hereby incorporated by reference herein. In one alternative embodiment of this step, the header is created using the SHA-1 hash of the pass phrase selected by the customer, a migration pass phrase the credit card company generates, and creating a TCPA key bundle wrapping the key, P5, in the public key, K1, the customer gave the credit card company. In another alternative embodiment, the credit card company can create the header by using its own TCPA chip by commanding it to create a migratable key using the requisite pass phrases and choosing its own storage key (of any sort) for its own TPM, and then migrating that key to the customer's TPM public key, K1. If the credit card company performs this process, it must pass the end user the bundle and the random number that is used for this transition. - The credit card company then creates its own certificate, C5, for the public key, P5, it created. In one alternative embodiment of this substep, the credit card company mails (traditional mail services) a diskette with the bundle stored on it to the verified address of the customer. In another alternative embodiment of this subset, the credit card company emails or mails the bundle to the customer (thus allowing verification of address) and either mails the random number to the customer with the bundle, or mails the random number to the end user separately, or mails the end user a 1-800 telephone number to call in order to get the random number (thus allowing verification of telephone number).
- If the customer had sent a non-migratable public portion of a signing key, K2, then the credit card company certifies the public key it has been sent and sends the certificate to the mailing address (proving verification of address) on a diskette. If the credit card company also wants to verify the telephone number, the certificate can be encrypted, for example X-ored with the SHA-1 hash of a pass phrase which is delivered over the phone.
- At the end of this process, in
step 208, the customer now has a private key pair which can only be used on the customer's computer system using a pass phrase the customer was allowed to choose, and which has a certificate of the credit card company. The credit card company can revoke the certificate whenever it wants. - An advantage of the first alternative described above where a non-migratable storage key is utilized, the credit card company can use the same key on multiple systems belonging to the customer, by simply re-wrapping the key with multiple storage keys of the customer. This is not possible with the second alternative where a signing key is created, unless the credit card company is willing to use migratable signing keys.
- An advantage of the second alternative discussed above where the customer creates a non-migratable public portion of a signing key, the credit card company never receives the pass phrase from the customer used to authorize use of the key on the customer's system.
- In an alternative embodiment of the present invention, a credit card company can perform a self-certification for a received non-migratable storage key. The customer of the system takes the certificate, C1, that was signed by the manufacturer of the system. This includes information regarding the security level the system was designed to as well as a certificate from the manufacturer of the TPM chip itself and a copy of P1, the endorsement public key from the TPM. The customer also asks the TPM (through a standard command) to generate a "TPM identity," a 2048-bit RSA signing key. The TPM returns the public portion of that key, P2. The customer takes P2 and the Certificate, C1, for the system and sends them to the credit card manufacturer. The credit card company verifies the certificate using the public keys of the manufacturer of both the TPM and the system and then provides a certificate, C6, for P2. However, the credit card company encrypts this certificate, C6, using P1 (as per the TCPA Specification). This encrypted certificate is sent back to the customer of the system. The customer sends the encrypted certificate, C6, to his TPM, (reloading the TPM identity key if necessary). The TPM checks the certificate against the identity key making certain that they match. If they do, the TPM exports enough information to decrypt the credit card company's certificate, C6, for that key.
- The customer then requests his TPM to produce a non-migratable storage key (or non-migratable signing key depending on which alternative he is taking). The TPM returns the public portion of the key. The customer then requests the TPM to sign the public portion of the non-migratable key in the last step with his identity. The TPM does this, providing an identity certificate that it is a non-migratable (storage or signing) key. The customer then sends the public portion of the non-migratable key, its identity-based certificate, and the credit card company certificate, C6, for the identity, back to the credit card company, which can then use its own certification of the quality of the non-migratable key.
- An additional embodiment will now be described in which a remote entity can install a private key on a remote user's Trusted Platform Module (TPM) associated with the remote user's computer system. The embodiment provides for secure usage of the key while retaining the key's transfer within the control of the remote entity.
- This embodiment provides a method for conducting business by which a company, such as a credit card company, creates a private signature key (which would represent a credit card in the example which follows) and transfers the key to an end user in a way that (i) preserves security, (ii) preserves control over the locale or locales where the key is to be used - for example, restricting the locale to the remote entity's locale (so that the remote entity can restrict the usage of the key to secure environments), and (iii) preserve control over the usage of the key - for example, restricting usage to the end user (so that only the designated end user can use the credit card). In the example which follows, a credit card company deploying a credit card product is shown as employing the method of doing business of this embodiment. The end product need not be a credit card, it can be a debit card or a general bank card used for all types of transactions. The example given below is not meant to be limiting in any way. For example, and not by way of limitation, the company can be a trust management company and the product can be a trust or will where authentication is given for power of attorney. The company can be an cable television company and the product a cable subscription service such as pay per view. The company may be an insurance provider and the product a medical benefits dispersion. In short, a provider benefits by the teachings of this embodiment for secure authentication for anything having good and valuable consideration.
- Referring now to Fig. 4, the transactions or steps of this embodiment of a method of doing business are shown between an
end user 401 and acredit card company 402. Instep 404, thecredit card company 402 receives a credit card private key request from anend user 401 whenend user 401 applies for a credit card private key. Instep 405, thecredit card company 402 checks that the Applicant is qualified to receive the credit card key. This checkingstep 405 can be for example the checking of the end user's 401 credit worthiness. In still another embodiment ofstep 405, and not by way of limitation, the checkingstep 405 can be to check whether the end user has an existing account etc. Upon qualification, instep 407, thecredit card company 402 requests of the end user's 401 Trusted Platform Module (TPM) associated with the end user's 401 computer system a secure non-migratable storage key. Next, instep 408, thecredit card company 402 receives the secure non-migratable storage key generated by end user's 401 Trusted Platform Module. To create a non-migratable storage key, the customer may use the CreateWrapKey function of the TCPA Specification as described hereinabove. The secure non-migratable storage key is received along with any of the following: - (A) a certificate from a Certificate Authority (CA) that states that the storage key is secure and non-migratable;
- (B) a certificate from a TPM identity key which states that the storage key is secure and non-migratable along with a certificate from a Certificate Authority which states that the TPM identity is a TPM identity; or
- (C) an endorsement key certificate from a Certificate Authority , and a certificate from a TPM identity key which states that the storage key is secure and non-migratable along with a certificate from a Certificate Authority which states that the TPM identity is a TPM identity.
-
-
Steps credit card company 402 creates a certificate for the TPM identity key, encrypts the certificate as per the TCPA specification / TPM specification - as in for example key1, and sends key1 back to the user encrypted in a blob containing the public identity key and encrypted with the public endorsement key. Whensteps step 410. Instep 410, a decrypted identity certificate is received by thecredit card company 402. This decrypted identity certificate is generated as a result of theend user 401 utilizing the TPM associated with end user's 401 computer system to decrypt the TPM identity key certificate; which, in turn, utilizes the provided endorsement private key to decrypt the key used to decrypt the certificate - but only if the TPM identity key matches the identity key generated by that TPM. - Upon verification that the storage key is a TPM non-migratable key, and hence secure, the
credit card company 402 creates a pair of public credit card private keys, and - (A) keeps the first copy secure for later migration as necessary, along with the public portion of the storage key, and
- (B) continues with the step shown at 411. In
step 411, thecredit card company 402 wraps the second copy with the public storage key as per the TPM specification, and sends the requested credit card private key back to the user. -
- Upon receipt of the credit card private key per
step 411, the method continues with thefinal step 412. Instep 412, theuser 401 waits to receive the code word necessary to use the key via a secure channel to the user. The secure channel can be: - (1) Via phone with ANI verifying the calling party;
- (2) Via the mail, as credit card numbers / PINs are currently done; and
- (3) Via the mail and ANI, to verify the mail was received by the intended recipient.
-
- Additional steps can be securely taken as necessary. In the example which follows, a virtual private network (VPN) is utilized to establish a secure connection between the
end user 401 and thecredit card company 402. Details concerning VPNs are well known in the art and are omitted so as to not obfuscate the present disclosure in unnecessary detail. In this example, if theend user 401 desires to change his or her password or PIN code, this can be done securely as follows: - A VPN is setup between the
credit card company 402 and theend user 401, using the private key of the user to identify thecredit card company 402; - The
user 401 asks that the private key be re-wrapped using the preferred password / PIN; - The
credit card company 402 re-wraps the key with the public portion of the storage key, with the new password / PIN contained therein. -
- Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (18)
- A business method comprising the steps of:1. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving a certificate from a Certificate Authority which certifies the non-migratable storage key as both secure and non-migratable; and(e) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 2. The method of
claim 1 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 3. The method of
claim 1 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key. - A business method comprising the steps of:4. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving a certificate from a TPM identity certifying the non-migratable storage key as both secure and non-migratable, and further receiving a certificate from a Certificate Authority certifying that the TPM identity is a TPM identity; and(e) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 5. The method of
claim 4 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 6. The method of
claim 4 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key. - A business method comprising the steps of:7. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving an endorsement key certificate from a Certificate Authority, and further receiving a certificate from a TPM identity certifying the non-migratable storage key as both secure and non-migratable, and further receiving a certificate from a Certificate Authority certifying that the TPM identity is a TPM identity;(e) originating a certificate for the TPM identity and encrypting the certificate as per the TCPA specification and sending the encrypted certificate to the remote device wherein the encryption is based on the endorsement key certificate;(f) receiving a decrypted identity certificate which is decrypted by the remote device when the TPM identity certificate as originated in said originating step (e) matches the TPM identity of the remote device; and(g) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 8. The method of
claim 7 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 9. The method of
claim 7 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key. - A program product comprising: a computer usable medium having computer readable program code embodied therein, the computer readable program code in said program product being effective in executing the steps of:10. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving a certificate from a Certificate Authority which certifies the non-migratable storage key as both secure and non-migratable; and(e) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 11. The program product of
claim 10 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 12. The program product of
claim 10 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key. - A program product comprising: a computer usable medium having computer readable program code embodied therein, the computer readable program code in said program product being effective in executing the steps of:13. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving a certificate from a TPM identity certifying the non-migratable storage key as both secure and non-migratable, and further receiving a certificate from a Certificate Authority certifying that the TPM identity is a TPM identity; and(e) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 14. The program product of
claim 13 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 15. The program product of
claim 13 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key. - A program product comprising: a computer usable medium having computer readable program code embodied therein, the computer readable program code in said program product being effective in executing the steps of:16. (a) receiving a request for a private key over a first network and from a remote device having a TPM (Trusted Platform Module) associated with an end user entity;(b) verifying the worthiness of the received request as represented by a TPM identity of the remote device;(c) requesting and receiving over the first network a non-migratable storage key from the TPM of the remote device when the received request is deemed worthy as determined by said verifying step (b);(d) receiving an endorsement key certificate from a Certificate Authority, and further receiving a certificate from a TPM identity certifying the non-migratable storage key as both secure and non-migratable, and further receiving a certificate from a Certificate Authority certifying that the TPM identity is a TPM identity;(e) originating a certificate for the TPM identity and encrypting the certificate as per the TCPA specification and sending the encrypted certificate to the remote device wherein the encryption is based on the endorsement key certificate;(f) receiving a decrypted identity certificate which is decrypted by the remote device when the TPM identity certificate as originated in said originating step (e) matches the TPM identity of the remote device; and(g) wrapping an encrypted private key with the non-migratable storage key as per the TCPA specification, and sending the encrypted private key to the remote device over the first network.
- 17. The program product of
claim 16 further comprising the step of sending over a second network a pass code which facilitates the decryption of the encrypted private key, wherein the second network is a network selected from the group consisting of a network which is physically different than the first network, a network which is logically different than the first network, and a network which is physically and logically different than the first network. - 18. The program product of
claim 16 further comprising the step of sending over regular mail a pass code which facilitates the decryption of the encrypted private key.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/851,956 US7676430B2 (en) | 2001-05-09 | 2001-05-09 | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/851,956 Continuation-In-Part US7676430B2 (en) | 2001-05-09 | 2001-05-09 | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset |
Publications (1)
Publication Number | Publication Date |
---|---|
US20030105965A1 true US20030105965A1 (en) | 2003-06-05 |
Family
ID=25312133
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/851,956 Expired - Fee Related US7676430B2 (en) | 2001-05-09 | 2001-05-09 | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset |
US10/248,791 Abandoned US20030105965A1 (en) | 2001-05-09 | 2003-02-19 | Business method for secure installation of a credit authorization key on a remote tcpa compliant system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/851,956 Expired - Fee Related US7676430B2 (en) | 2001-05-09 | 2001-05-09 | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset |
Country Status (1)
Country | Link |
---|---|
US (2) | US7676430B2 (en) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050144440A1 (en) * | 2003-12-31 | 2005-06-30 | International Business Machines Corp. | Method for securely creating an endorsement certificate in an insecure environment |
US20050149733A1 (en) * | 2003-12-31 | 2005-07-07 | International Business Machines Corporation | Method for securely creating an endorsement certificate utilizing signing key pairs |
US20050166024A1 (en) * | 2004-01-26 | 2005-07-28 | Angelo Michael F. | Method and apparatus for operating multiple security modules |
US20050220095A1 (en) * | 2004-03-31 | 2005-10-06 | Sankaran Narayanan | Signing and validating Session Initiation Protocol routing headers |
US20050235141A1 (en) * | 2004-04-19 | 2005-10-20 | Hewlett-Packard Development Company, L.P. | Subordinate trusted platform module |
US20060059350A1 (en) * | 2004-08-24 | 2006-03-16 | Microsoft Corporation | Strong names |
US20060167810A1 (en) * | 2005-01-24 | 2006-07-27 | Microsoft Corporation | Multi-merchant purchasing environment for downloadable products |
US20060167819A1 (en) * | 2005-01-24 | 2006-07-27 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US20070022017A1 (en) * | 2005-01-24 | 2007-01-25 | Microsoft Corporation | Extended Data Collection For Multi-Merchant Purchasing Environment For Downloadable Products |
GB2430852A (en) * | 2003-08-12 | 2007-04-04 | Intel Corp | Generating an identification credential for a trusted hardware component based on a plurality of certificates |
US20090083539A1 (en) * | 2003-12-31 | 2009-03-26 | Ryan Charles Catherman | Method for Securely Creating an Endorsement Certificate in an Insecure Environment |
US8024476B2 (en) | 2004-05-21 | 2011-09-20 | Microsoft Corporation | Efficient message routing when using server pools |
US11240008B2 (en) | 2019-03-22 | 2022-02-01 | Advanced New Technologies Co., Ltd. | Key management method, security chip, service server and information system |
Families Citing this family (54)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6976162B1 (en) | 2000-06-28 | 2005-12-13 | Intel Corporation | Platform and method for establishing provable identities while maintaining privacy |
US7818808B1 (en) | 2000-12-27 | 2010-10-19 | Intel Corporation | Processor mode for limiting the operation of guest software running on a virtual machine supported by a virtual machine monitor |
US20030061494A1 (en) * | 2001-09-26 | 2003-03-27 | Girard Luke E. | Method and system for protecting data on a pc platform using bulk non-volatile storage |
US7024555B2 (en) | 2001-11-01 | 2006-04-04 | Intel Corporation | Apparatus and method for unilaterally loading a secure operating system within a multiprocessor environment |
US7631196B2 (en) | 2002-02-25 | 2009-12-08 | Intel Corporation | Method and apparatus for loading a trustable operating system |
US7069442B2 (en) | 2002-03-29 | 2006-06-27 | Intel Corporation | System and method for execution of a secured environment initialization instruction |
US7127548B2 (en) * | 2002-04-16 | 2006-10-24 | Intel Corporation | Control register access virtualization performance improvement in the virtual-machine architecture |
US7139890B2 (en) * | 2002-04-30 | 2006-11-21 | Intel Corporation | Methods and arrangements to interface memory |
US6996748B2 (en) * | 2002-06-29 | 2006-02-07 | Intel Corporation | Handling faults associated with operation of guest software in the virtual-machine architecture |
US7124327B2 (en) * | 2002-06-29 | 2006-10-17 | Intel Corporation | Control over faults occurring during the operation of guest software in the virtual-machine architecture |
US7165181B2 (en) * | 2002-11-27 | 2007-01-16 | Intel Corporation | System and method for establishing trust without revealing identity |
US7900017B2 (en) | 2002-12-27 | 2011-03-01 | Intel Corporation | Mechanism for remapping post virtual machine memory pages |
US8079034B2 (en) * | 2003-09-15 | 2011-12-13 | Intel Corporation | Optimizing processor-managed resources based on the behavior of a virtual machine monitor |
US7424709B2 (en) * | 2003-09-15 | 2008-09-09 | Intel Corporation | Use of multiple virtual machine monitors to handle privileged events |
US7287197B2 (en) * | 2003-09-15 | 2007-10-23 | Intel Corporation | Vectoring an interrupt or exception upon resuming operation of a virtual machine |
US7739521B2 (en) | 2003-09-18 | 2010-06-15 | Intel Corporation | Method of obscuring cryptographic computations |
US20050080934A1 (en) | 2003-09-30 | 2005-04-14 | Cota-Robles Erik C. | Invalidating translation lookaside buffer entries in a virtual machine (VM) system |
US7237051B2 (en) * | 2003-09-30 | 2007-06-26 | Intel Corporation | Mechanism to control hardware interrupt acknowledgement in a virtual machine system |
JP2007507786A (en) * | 2003-10-06 | 2007-03-29 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | Method and circuit for identifying and / or verifying hardware and / or software of electrical equipment and data carriers cooperating with electrical equipment |
US7734279B2 (en) * | 2003-10-14 | 2010-06-08 | Telecom Italia S.P.A. | Method and system for controlling resources via a mobile terminal, related network and computer program product therefor |
US8156343B2 (en) * | 2003-11-26 | 2012-04-10 | Intel Corporation | Accessing private data about the state of a data processing machine from storage that is publicly accessible |
US20050133582A1 (en) * | 2003-12-22 | 2005-06-23 | Bajikar Sundeep M. | Method and apparatus for providing a trusted time stamp in an open platform |
US8037314B2 (en) | 2003-12-22 | 2011-10-11 | Intel Corporation | Replacing blinded authentication authority |
US7802085B2 (en) | 2004-02-18 | 2010-09-21 | Intel Corporation | Apparatus and method for distributing private keys to an entity with minimal secret, unique information |
US7620949B2 (en) | 2004-03-31 | 2009-11-17 | Intel Corporation | Method and apparatus for facilitating recognition of an open event window during operation of guest software in a virtual machine environment |
US7747862B2 (en) * | 2004-06-28 | 2010-06-29 | Intel Corporation | Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks |
US7840962B2 (en) | 2004-09-30 | 2010-11-23 | Intel Corporation | System and method for controlling switching between VMM and VM using enabling value of VMM timer indicator and VMM timer value having a specified time |
US8146078B2 (en) | 2004-10-29 | 2012-03-27 | Intel Corporation | Timer offsetting mechanism in a virtual machine environment |
US8924728B2 (en) | 2004-11-30 | 2014-12-30 | Intel Corporation | Apparatus and method for establishing a secure session with a device without exposing privacy-sensitive information |
US8533777B2 (en) | 2004-12-29 | 2013-09-10 | Intel Corporation | Mechanism to determine trust of out-of-band management agents |
US7395405B2 (en) | 2005-01-28 | 2008-07-01 | Intel Corporation | Method and apparatus for supporting address translation in a virtual machine environment |
US8539587B2 (en) * | 2005-03-22 | 2013-09-17 | Hewlett-Packard Development Company, L.P. | Methods, devices and data structures for trusted data |
US8074262B2 (en) * | 2005-05-13 | 2011-12-06 | Intel Corporation | Method and apparatus for migrating virtual trusted platform modules |
US7587595B2 (en) * | 2005-05-13 | 2009-09-08 | Intel Corporation | Method and apparatus for providing software-based security coprocessors |
US8549592B2 (en) * | 2005-07-12 | 2013-10-01 | International Business Machines Corporation | Establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform |
US7809957B2 (en) | 2005-09-29 | 2010-10-05 | Intel Corporation | Trusted platform module for generating sealed data |
US20070192580A1 (en) * | 2006-02-10 | 2007-08-16 | Challener David C | Secure remote management of a TPM |
US8014530B2 (en) | 2006-03-22 | 2011-09-06 | Intel Corporation | Method and apparatus for authenticated, recoverable key distribution with no database secrets |
US8108668B2 (en) | 2006-06-26 | 2012-01-31 | Intel Corporation | Associating a multi-context trusted platform module with distributed platforms |
EP1879321A1 (en) * | 2006-07-11 | 2008-01-16 | STMicroelectronics GmbH | Electronic signature with a trusted platform |
US8036967B2 (en) * | 2007-01-12 | 2011-10-11 | Allegacy Federal Credit Union | Bank card fraud detection and/or prevention methods |
JP5196883B2 (en) * | 2007-06-25 | 2013-05-15 | パナソニック株式会社 | Information security apparatus and information security system |
US8064605B2 (en) * | 2007-09-27 | 2011-11-22 | Intel Corporation | Methods and apparatus for providing upgradeable key bindings for trusted platform modules |
US8249257B2 (en) | 2007-09-28 | 2012-08-21 | Intel Corporation | Virtual TPM keys rooted in a hardware TPM |
US10104522B2 (en) * | 2015-07-02 | 2018-10-16 | Gn Hearing A/S | Hearing device and method of hearing device communication |
DK3113407T3 (en) * | 2015-07-02 | 2019-05-13 | Gn Hearing As | CLIENT RENTAL WITH CERTIFICATE AND RELATED PROCEDURE |
US10158953B2 (en) | 2015-07-02 | 2018-12-18 | Gn Hearing A/S | Hearing device and method of updating a hearing device |
US10158955B2 (en) | 2015-07-02 | 2018-12-18 | Gn Hearing A/S | Rights management in a hearing device |
US10318720B2 (en) | 2015-07-02 | 2019-06-11 | Gn Hearing A/S | Hearing device with communication logging and related method |
US9877123B2 (en) | 2015-07-02 | 2018-01-23 | Gn Hearing A/S | Method of manufacturing a hearing device and hearing device with certificate |
DK201570433A1 (en) | 2015-07-02 | 2017-01-30 | Gn Hearing As | Hearing device with model control and associated methods |
US9887848B2 (en) | 2015-07-02 | 2018-02-06 | Gn Hearing A/S | Client device with certificate and related method |
US10832248B1 (en) | 2016-03-25 | 2020-11-10 | State Farm Mutual Automobile Insurance Company | Reducing false positives using customer data and machine learning |
CN110458662B (en) * | 2019-08-06 | 2022-01-07 | 西安纸贵互联网科技有限公司 | Anti-fraud wind control method and device |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5883810A (en) * | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US6236972B1 (en) * | 1998-12-02 | 2001-05-22 | Gary Shkedy | Method and apparatus for facilitating transactions on a commercial network system |
US20020080974A1 (en) * | 2000-12-27 | 2002-06-27 | Grawrock David W. | Platform and method for securely transmitting an authorization secret. |
US20020087877A1 (en) * | 2000-12-28 | 2002-07-04 | Grawrock David W. | Platform and method of creating a secure boot that enforces proper user authentication and enforces hardware configurations |
US6947908B1 (en) * | 1998-08-27 | 2005-09-20 | Citibank, N.A. | System and use for correspondent banking |
US6983368B2 (en) * | 2000-08-04 | 2006-01-03 | First Data Corporation | Linking public key of device to information during manufacture |
US6988250B1 (en) * | 1999-02-15 | 2006-01-17 | Hewlett-Packard Development Company, L.P. | Trusted computing platform using a trusted device assembly |
US7069234B1 (en) * | 1999-12-22 | 2006-06-27 | Accenture Llp | Initiating an agreement in an e-commerce environment |
US7136835B1 (en) * | 1998-03-25 | 2006-11-14 | Orbis Patents Ltd. | Credit card system and method |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5982898A (en) | 1997-03-07 | 1999-11-09 | At&T Corp. | Certification process |
BR9809272A (en) | 1997-05-09 | 2000-06-27 | Connotech Experts Conseils Inc | Initial secret key establishment including facilities for identity verification |
US6105131A (en) | 1997-06-13 | 2000-08-15 | International Business Machines Corporation | Secure server and method of operation for a distributed information system |
US5991399A (en) | 1997-12-18 | 1999-11-23 | Intel Corporation | Method for securely distributing a conditional use private key to a trusted entity on a remote system |
US6105006A (en) | 1997-12-22 | 2000-08-15 | Motorola Inc | Transaction authentication for 1-way wireless financial messaging units |
US6820202B1 (en) * | 1998-11-09 | 2004-11-16 | First Data Corporation | Account authority digital signature (AADS) system |
US6389537B1 (en) * | 1999-04-23 | 2002-05-14 | Intel Corporation | Platform and method for assuring integrity of trusted agent communications |
-
2001
- 2001-05-09 US US09/851,956 patent/US7676430B2/en not_active Expired - Fee Related
-
2003
- 2003-02-19 US US10/248,791 patent/US20030105965A1/en not_active Abandoned
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5883810A (en) * | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US7136835B1 (en) * | 1998-03-25 | 2006-11-14 | Orbis Patents Ltd. | Credit card system and method |
US6947908B1 (en) * | 1998-08-27 | 2005-09-20 | Citibank, N.A. | System and use for correspondent banking |
US6236972B1 (en) * | 1998-12-02 | 2001-05-22 | Gary Shkedy | Method and apparatus for facilitating transactions on a commercial network system |
US6988250B1 (en) * | 1999-02-15 | 2006-01-17 | Hewlett-Packard Development Company, L.P. | Trusted computing platform using a trusted device assembly |
US7069234B1 (en) * | 1999-12-22 | 2006-06-27 | Accenture Llp | Initiating an agreement in an e-commerce environment |
US6983368B2 (en) * | 2000-08-04 | 2006-01-03 | First Data Corporation | Linking public key of device to information during manufacture |
US20020080974A1 (en) * | 2000-12-27 | 2002-06-27 | Grawrock David W. | Platform and method for securely transmitting an authorization secret. |
US6948065B2 (en) * | 2000-12-27 | 2005-09-20 | Intel Corporation | Platform and method for securely transmitting an authorization secret |
US20020087877A1 (en) * | 2000-12-28 | 2002-07-04 | Grawrock David W. | Platform and method of creating a secure boot that enforces proper user authentication and enforces hardware configurations |
US7117376B2 (en) * | 2000-12-28 | 2006-10-03 | Intel Corporation | Platform and method of creating a secure boot that enforces proper user authentication and enforces hardware configurations |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2430852A (en) * | 2003-08-12 | 2007-04-04 | Intel Corp | Generating an identification credential for a trusted hardware component based on a plurality of certificates |
US20050149733A1 (en) * | 2003-12-31 | 2005-07-07 | International Business Machines Corporation | Method for securely creating an endorsement certificate utilizing signing key pairs |
US8495361B2 (en) | 2003-12-31 | 2013-07-23 | International Business Machines Corporation | Securely creating an endorsement certificate in an insecure environment |
US7751568B2 (en) * | 2003-12-31 | 2010-07-06 | International Business Machines Corporation | Method for securely creating an endorsement certificate utilizing signing key pairs |
US7644278B2 (en) * | 2003-12-31 | 2010-01-05 | International Business Machines Corporation | Method for securely creating an endorsement certificate in an insecure environment |
US20050144440A1 (en) * | 2003-12-31 | 2005-06-30 | International Business Machines Corp. | Method for securely creating an endorsement certificate in an insecure environment |
US20090083539A1 (en) * | 2003-12-31 | 2009-03-26 | Ryan Charles Catherman | Method for Securely Creating an Endorsement Certificate in an Insecure Environment |
US20050166024A1 (en) * | 2004-01-26 | 2005-07-28 | Angelo Michael F. | Method and apparatus for operating multiple security modules |
US7930503B2 (en) * | 2004-01-26 | 2011-04-19 | Hewlett-Packard Development Company, L.P. | Method and apparatus for operating multiple security modules |
US7535905B2 (en) | 2004-03-31 | 2009-05-19 | Microsoft Corporation | Signing and validating session initiation protocol routing headers |
US20050220095A1 (en) * | 2004-03-31 | 2005-10-06 | Sankaran Narayanan | Signing and validating Session Initiation Protocol routing headers |
US20050235141A1 (en) * | 2004-04-19 | 2005-10-20 | Hewlett-Packard Development Company, L.P. | Subordinate trusted platform module |
US8271783B2 (en) * | 2004-04-19 | 2012-09-18 | Hewlett-Packard Development Company, L.P. | Subordinate trusted platform module |
US8024476B2 (en) | 2004-05-21 | 2011-09-20 | Microsoft Corporation | Efficient message routing when using server pools |
US20060059350A1 (en) * | 2004-08-24 | 2006-03-16 | Microsoft Corporation | Strong names |
US8284942B2 (en) * | 2004-08-24 | 2012-10-09 | Microsoft Corporation | Persisting private/public key pairs in password-encrypted files for transportation to local cryptographic store |
US20060167810A1 (en) * | 2005-01-24 | 2006-07-27 | Microsoft Corporation | Multi-merchant purchasing environment for downloadable products |
US20070027779A1 (en) * | 2005-01-24 | 2007-02-01 | Microsoft Corporation | Add License Anonymously To Product Locker For Multi-Merchant Purchasing Environment |
US20110060660A1 (en) * | 2005-01-24 | 2011-03-10 | Microsoft Corporation | Digital content purchase management |
US20090171847A2 (en) * | 2005-01-24 | 2009-07-02 | Microsoft Corporation | Multi-merchant purchasing environment for downloadable products |
US7548889B2 (en) * | 2005-01-24 | 2009-06-16 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US8099365B2 (en) | 2005-01-24 | 2012-01-17 | Microsoft Corporation | Extended data collection for multi-merchant purchasing environment for downloadable products |
US20060167819A1 (en) * | 2005-01-24 | 2006-07-27 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US20070022017A1 (en) * | 2005-01-24 | 2007-01-25 | Microsoft Corporation | Extended Data Collection For Multi-Merchant Purchasing Environment For Downloadable Products |
US11240008B2 (en) | 2019-03-22 | 2022-02-01 | Advanced New Technologies Co., Ltd. | Key management method, security chip, service server and information system |
Also Published As
Publication number | Publication date |
---|---|
US20020169717A1 (en) | 2002-11-14 |
US7676430B2 (en) | 2010-03-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7676430B2 (en) | System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset | |
US8145899B2 (en) | Creation of user digital certificate for portable consumer payment device | |
US7380125B2 (en) | Smart card data transaction system and methods for providing high levels of storage and transmission security | |
US6934838B1 (en) | Method and apparatus for a service provider to provide secure services to a user | |
US6430688B1 (en) | Architecture for web-based on-line-off-line digital certificate authority | |
US6038551A (en) | System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer | |
US7526649B2 (en) | Session key exchange | |
US6105012A (en) | Security system and method for financial institution server and client web browser | |
US7925878B2 (en) | System and method for creating a trusted network capable of facilitating secure open network transactions using batch credentials | |
USRE38070E1 (en) | Cryptography system and method for providing cryptographic services for a computer application | |
US7254706B2 (en) | System and method for downloading of files to a secure terminal | |
US20090198618A1 (en) | Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce | |
US20030135740A1 (en) | Biometric-based system and method for enabling authentication of electronic messages sent over a network | |
JPH0936851A (en) | System and method of integrating private key operation from smart card in a transmissive way with host base cryptograph service | |
WO2000072226A2 (en) | Delegation of permissions in an electronic commerce system | |
JP2002056360A (en) | Ic card system and ic card | |
CA2568990C (en) | Smart card data transaction system and methods for providing storage and transmission security | |
US7793097B2 (en) | Extension of X.509 certificates to simultaneously support multiple cryptographic algorithms | |
CN113347008B (en) | Loan information storage method adopting addition homomorphic encryption | |
CN113015991A (en) | Secure digital wallet processing system | |
M'Raı̈hi et al. | E-commerce applications of smart cards | |
KR100349888B1 (en) | PKI system for and method of using micro explorer on mobile terminals | |
CN113706261A (en) | Block chain-based power transaction method, device and system | |
Clifford Neuman | Protection and security issues for future systems | |
CN116455579A (en) | Digital certificate management method and system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHALLENER, DAVID CARROLL;REEL/FRAME:013428/0796 Effective date: 20030214 |
|
AS | Assignment |
Owner name: LENOVO (SINGAPORE) PTE LTD.,SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:016891/0507 Effective date: 20050520 Owner name: LENOVO (SINGAPORE) PTE LTD., SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:016891/0507 Effective date: 20050520 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |