U.S. patent application number 10/248791 was filed with the patent office on 2003-06-05 for business method for secure installation of a credit authorization key on a remote tcpa compliant system.
This patent application is currently assigned to International Business Machines Corporation. Invention is credited to CHALLENER , DAVID CARROLL.
Application Number | 20030105965 10/248791 |
Document ID | / |
Family ID | 25312133 |
Filed Date | 2003-06-05 |
United States Patent
Application |
20030105965 |
Kind Code |
A1 |
CHALLENER , DAVID CARROLL |
June 5, 2003 |
BUSINESS METHOD FOR SECURE INSTALLATION OF A CREDIT AUTHORIZATION
KEY ON A REMOTE TCPA COMPLIANT SYSTEM
Abstract
A business method employing hardware complaint to the Trusted
Computing Platform Alliance (TCPA) Specification is implemented to
allow a credit card company to remotely install acredit card
private key into a TCPA module to create a Trusted Platform Module
(TPM). Morespecifically, when a credit worthy user applies for a
credit card, the user will send the credit cardcompany a public
portion of a "non-migratable storage key," which is accredited a
TPM endorsedby a Certification Authority. The credit card company
will create its own public/private key pairaccording to the TCPA
Specification, to create a TCPA header, and wrap the full structure
byencrypting it with the public portion of the TCPA non-migratable
storage key. The credit cardcompany then sends by email the
encrypted bundle with a certificate for it, and sends
acorresponding pass phrase by regular mail.
Inventors: |
CHALLENER , DAVID CARROLL; (
Raleigh, North Carolina) |
Assignee: |
International Business Machines
Corporation
New Orchard Road
Armonk
10504
NY
|
Family ID: |
25312133 |
Appl. No.: |
10/248791 |
Filed: |
February 19, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10248791 |
Feb 19, 2003 |
|
|
|
09/851956 |
Oct 50, 200 |
|
|
|
Current U.S.
Class: |
713/184 ;
705/76 |
Current CPC
Class: |
G06Q 20/102 20130101;
G06Q 20/24 20130101; G06Q 20/3558 20130101; G06Q 40/04 20130101;
G07F 7/025 20130101; G06Q 20/3552 20130101; G07F 7/1016 20130101;
G06Q 20/12 20130101; G06Q 20/10 20130101; G07F 7/1008 20130101;
G06Q 20/342 20130101; G06Q 40/025 20130101; G06Q 20/3821 20130101;
G06Q 30/0609 20130101; G06Q 20/105 20130101; G06Q 20/38215
20130101 |
Class at
Publication: |
713/184 ;
705/76 |
International
Class: |
G06F 017/60 |
Claims
What is Claimed is:
A business method comprising the steps of: 1. (a) receiving a
request for a private key over a first network and from a remote
devicehaving a TPM (Trusted Platform Module) associated with an end
user entity; (b) verifying the worthiness of the received request
as represented by a TPM identityof the remote device; (c)
requesting and receiving over the first network a non-migratable
storage key fromthe TPM of the remote device when the received
request is deemed worthy as determinedby 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 theTCPA specification, and
sending the encrypted private key to the remote device over
thefirst network.
2. The method ofclaim 1 furthercomprising the step of sending over
a second network a pass code which facilitates the decryptionof the
encrypted private key, wherein the second network is a network
selected from the groupconsisting of a network which is physically
different than the first network, a network which islogically
different than the first network, and a network which is physically
and logically differentthan the first network.
3. The method ofclaim 1 furthercomprising the step of sending over
regular mail a pass code which facilitates the decryption ofthe
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
devicehaving a TPM (Trusted Platform Module) associated with an end
user entity; (b) verifying the worthiness of the received request
as represented by a TPM identityof the remote device; (c)
requesting and receiving over the first network a non-migratable
storage key fromthe TPM of the remote device when the received
request is deemed worthy as determinedby said verifying step (b);
(d) receiving a certificate from a TPM identity certifying the
non-migratable storagekey as both secure and non-migratable, and
further receiving a certificate from aCertificate 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 theTCPA specification, and sending the encrypted private
key to the remote device over thefirst network.
5. The method ofclaim 4 furthercomprising the step of sending over
a second network a pass code which facilitates the decryptionof the
encrypted private key, wherein the second network is a network
selected from the groupconsisting of a network which is physically
different than the first network, a network which islogically
different than the first network, and a network which is physically
and logically differentthan the first network.
6. The method ofclaim 4 furthercomprising the step of sending over
regular mail a pass code which facilitates the decryption ofthe
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
devicehaving a TPM (Trusted Platform Module) associated with an end
user entity; (b) verifying the worthiness of the received request
as represented by a TPM identityof the remote device; (c)
requesting and receiving over the first network a non-migratable
storage key fromthe TPM of the remote device when the received
request is deemed worthy as determinedby said verifying step (b);
(d) receiving an endorsement key certificate from a Certificate
Authority, and furtherreceiving a certificate from a TPM identity
certifying the non-migratable storage key asboth secure and
non-migratable, and further receiving a certificate from a
CertificateAuthority certifying that the TPM identity is a TPM
identity; (e) originating a certificate for the TPM identity and
encrypting the certificate as perthe TCPA specification and sending
the encrypted certificate to the remote device whereinthe
encryption is based on the endorsement key certificate; (f)
receiving a decrypted identity certificate which is decrypted by
the remote devicewhen the TPM identity certificate as originated in
said originating step (e) matches theTPM identity of the remote
device; and (g) wrapping an encrypted private key with the
non-migratable storage key as per theTCPA specification, and
sending the encrypted private key to the remote device over
thefirst network.
8. The method ofclaim 7 furthercomprising the step of sending over
a second network a pass code which facilitates the decryptionof the
encrypted private key, wherein the second network is a network
selected from the groupconsisting of a network which is physically
different than the first network, a network which islogically
different than the first network, and a network which is physically
and logically differentthan the first network.
9. The method ofclaim 7 furthercomprising the step of sending over
regular mail a pass code which facilitates the decryption ofthe
encrypted private key.
A program product comprising: a computer usable medium having
computer readable program code embodied therein, thecomputer
readable program code in said program product being effective in
executing the stepsof: 10. (a) receiving a request for a private
key over a first network and from a remote devicehaving a TPM
(Trusted Platform Module) associated with an end user entity; (b)
verifying the worthiness of the received request as represented by
a TPM identityof the remote device; (c) requesting and receiving
over the first network a non-migratable storage key fromthe TPM of
the remote device when the received request is deemed worthy as
determinedby 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
theTCPA specification, and sending the encrypted private key to the
remote device over thefirst network.
11. The program product ofclaim 10further comprising the step of
sending over a second network a pass code which facilitates
thedecryption of the encrypted private key, wherein the second
network is a network selected fromthe group consisting of a network
which is physically different than the first network, a
networkwhich is logically different than the first network, and a
network which is physically and logicallydifferent than the first
network.
12. The program product ofclaim 10further comprising the step of
sending over regular mail a pass code which facilitates
thedecryption of the encrypted private key.
A program product comprising: a computer usable medium having
computer readable program code embodied therein, thecomputer
readable program code in said program product being effective in
executing the stepsof: 13. (a) receiving a request for a private
key over a first network and from a remote devicehaving a TPM
(Trusted Platform Module) associated with an end user entity; (b)
verifying the worthiness of the received request as represented by
a TPM identityof the remote device; (c) requesting and receiving
over the first network a non-migratable storage key fromthe TPM of
the remote device when the received request is deemed worthy as
determinedby said verifying step (b); (d) receiving a certificate
from a TPM identity certifying the non-migratable storagekey as
both secure and non-migratable, and further receiving a certificate
from aCertificate 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 theTCPA specification, and
sending the encrypted private key to the remote device over
thefirst network.
14. The program product ofclaim 13further comprising the step of
sending over a second network a pass code which facilitates
thedecryption of the encrypted private key, wherein the second
network is a network selected fromthe group consisting of a network
which is physically different than the first network, a
networkwhich is logically different than the first network, and a
network which is physically and logicallydifferent than the first
network.
15. The program product ofclaim 13further comprising the step of
sending over regular mail a pass code which facilitates
thedecryption of the encrypted private key.
A program product comprising: a computer usable medium having
computer readable program code embodied therein, thecomputer
readable program code in said program product being effective in
executing the stepsof: 16. (a) receiving a request for a private
key over a first network and from a remote devicehaving a TPM
(Trusted Platform Module) associated with an end user entity; (b)
verifying the worthiness of the received request as represented by
a TPM identityof the remote device; (c) requesting and receiving
over the first network a non-migratable storage key fromthe TPM of
the remote device when the received request is deemed worthy as
determinedby said verifying step (b); (d) receiving an endorsement
key certificate from a Certificate Authority, and furtherreceiving
a certificate from a TPM identity certifying the non-migratable
storage key asboth secure and non-migratable, and further receiving
a certificate from a CertificateAuthority certifying that the TPM
identity is a TPM identity; (e) originating a certificate for the
TPM identity and encrypting the certificate as perthe TCPA
specification and sending the encrypted certificate to the remote
device whereinthe encryption is based on the endorsement key
certificate; (f) receiving a decrypted identity certificate which
is decrypted by the remote devicewhen the TPM identity certificate
as originated in said originating step (e) matches theTPM identity
of the remote device; and (g) wrapping an encrypted private key
with the non-migratable storage key as per theTCPA specification,
and sending the encrypted private key to the remote device over
thefirst network.
17. The program product ofclaim 16further comprising the step of
sending over a second network a pass code which facilitates
thedecryption of the encrypted private key, wherein the second
network is a network selected fromthe group consisting of a network
which is physically different than the first network, a
networkwhich is logically different than the first network, and a
network which is physically and logicallydifferent than the first
network.
18. The program product ofclaim 16further comprising the step of
sending over regular mail a pass code which facilitates
thedecryption of the encrypted private key.
Description
Cross Reference to Related Applications
[0001] This application is a continuation-in-part of application
Serial No. 09/851956 entitled System andMethod for Installing a
Remote Credit Card Authorization on a System with a TCPA
ComplaintChipset.
Technical Field
[0002] The present invention relates in general to data processing
systems, and in particular, toenabling secure communications over
data processing networks.
Background Information
[0003] 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 ofe-commerce, it stands to
note that providing for the transfer of funds and credit
duringe-commerce transactions bodes well for those credit card
companies that can securely provide forsuch transactions. One of
the main concerns that continues with respect to e-commerce is
thelack of trust that the consuming public has in the security of
such transactions to protect theircredit card and banking
accounts.
[0004] 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
ifapproved, the credit card company will send a physical credit
card to the user who can thenactivate the credit card by calling a
toll-free number from the user's home phone. However, creditcard
theft is abundant, and according to some reports, accounts for half
of the monetary loss ofthe credit card companies.
[0005] 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
ofexpense, since use of a smartcard requires a smartcard reader to
be installed on the user'scomputer.
[0006] 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
forfacilitating purchases over the Internet.
Brief Summary of the Invention
[0007] 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 TCPAmodule in
a way that the company can be assured it is going to a trusted TPM
(Trusted PlatformModule). While the invention is not limited to
credit card companies, the most detailed examplesshown are for
credit card companies. In the specific case of a credit card
company, when a userapplies for a credit card, the credit card
company will first determine if the person is creditworthy.
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 aCertification
Authority (CA). The private portion of the "non-migratable storage
key" is knownto be a key that was created inside the TPM, and
cannot be exported from the TPM. The creditcard company will now
create its own public/private key pair according to the
TCPASpecification, using whatever size key it desires, create a
TCPA header, and wrap the fullstructure by encrypting it with the
public portion of the TCPA non-migratable storage key. Thecredit
card company will then send by email to the person the encrypted
bundle and a certificatefor it, and via "snail mail," a pass phrase
that is hashed to provide usage of the encrypted bundleon the
person's system.The present invention provides for an interaction
between the credit card company and the user ina way so that the
credit card company is assured that a private key used by a user is
used to thesame degree that the user uses a physical credit card.
That is, an embodiment of the presentinvention establishes a
similar level of trust for a credit card authorization over the
Internet aspresently exists for transactions using physical credit
cards in stores.
[0008] In one alternative embodiment of the present invention, the
credit card company can be its own certification authority.
[0009] 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 useof credit
cards in e-commerce transactions. Another advantage of the present
invention is that thecertificate can easily be checked against the
credit card company's database for revocation. Usingthis type of
signature instead of a credit card number precludes someone from
charging a creditcard multiple times, and also precludes someone
keeping a database of credit card numbers to beexposed to a hacker
accessing such numbers.
[0010] 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
betterunderstood. Additional features and advantages of the
invention will be described hereinafterwhich form the subject of
the claims of the invention.
Brief Description of the Several Views of the Drawings
[0011] 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 accompanyingdrawings, in
which:
[0012] FIGURE 1 illustrates a data processing system configured in
accordance with an embodiment of the present invention;
[0013] FIGURE 2 illustrates a flow diagram configured in accordance
with an embodiment of present invention; and
[0014] FIGURE 3 illustrates a network configured in accordance with
an embodiment of present invention.
[0015] FIGURE 4 illustrates a business method in accordance with an
embodiment of the present invention.
Detailed Description of the Invention
[0016] 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 practicedwithout such specific details. In other
instances, well-known circuits have been shown in blockdiagram form
in order not to obscure the present invention in unnecessary
detail. For the mostpart, details concerning timing considerations
and the like have been omitted in as much as suchdetails are not
necessary to obtain a complete understanding of the present
invention and arewithin the skills of persons of ordinary skill in
the relevant art.
[0017] 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 creditcard authorization
from a credit card company server 302 over the Internet 303.
[0018] Referring to FIGURE 1, there is illustrated exemplary data
processing system 113 configured in accordance with the present
invention, whereby system 113 could be used for theuser computer
301, the credit card company server 302, and any and all servers
used in theInternet 303 to communicate data between computer 301
and server 302.
[0019] 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 systembus 112 and
includes a basic input/output system ("BIOS") that controls certain
basic functions ofthe data processing system 113. Random access
memory ("RAM") 114, I/O adapter 118, andcommunications adapter 134
are also coupled to the system bus 112. I/O adapter 118 may be
asmall computer system interface ("SCSI") adapter that communicates
with a disk storagedevice 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 suchsystems. Input/Output devices are also connected to
system bus 112 via user interfaceadapter 122 and display adapter
136. Keyboard 124 and mouse 126 are all interconnected tobus 112
via user interface adapter 122. Display monitor 138 is connected to
system bus 112 bydisplay adapter 136. In this manner, a user is
capable of inputting to the system 113 throughoutthe keyboard 124
or mouse 126 and receiving output from the system via display
138.
[0020] Implementations of the invention include implementations as
a computer system programmed to execute the method or methods
described herein, and as a computer programproduct. According to
the computer system implementation, sets of instructions for
executing themethod or methods may be resident in the random access
memory 114 of one or more computersystems configured generally as
described above. Until required by the computer system, the setof
instructions may be stored as a computer program product in another
computer memory, forexample, in disk drive 120 (which may include a
removable memory such as an optical disk orfloppy disk for eventual
use in the disk drive 120). Further, the computer program product
canalso be stored at another computer and transmitted when desired
to the user's workstation by anetwork or by an external network
such as the Internet 303. One skilled in the art wouldappreciate
that the physical storage of the sets of instructions physically
changes the medium uponwhich it is stored so that the medium
carries computer readable information. The change may beelectrical,
magnetic, chemical, biological, or some other physical change.
While it is convenient todescribe the invention in terms of
instructions, symbols, characters, or the like, the reader
shouldremember that all of these and similar terms should be
associated with the appropriate physicalelements.
[0021] 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 leasta
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,
machineoperations processing electrical signals to generate other
electrical signals.
[0022] 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 customerdesires to
receive an embedded credit card authorization within the customer's
computer system301. In step 201, the customer will create a TPM
identity per the TCPA Specification and obtaina 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 isreleased to the
manufacturer. The manufacturer of the TPM signs a certificate, C1,
that goesalong with the TPM. Alternatively, the certificate, C1,
can be retrieved by a user over theInternet from the manufacturer.
This certificate, C1, is tied to the public portion of
theendorsement key, P1, that determines that the public key is the
endorsement key of this particularTPM. This endorsement key, P1, is
used for decrypting.
[0023] 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 theTPM identity is
the public portion of a public/private key pair.
[0024] 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). Thismay be
authorized by the user as a result of a user command. The CA checks
the accuracy of thecertificate, C1, signed by the manufacturer. The
CA can perform this check by looking in adatabase at the
manufacturer's website. The CA then makes a certificate, C2, for
the TPMidentity, P2, and encrypts the certificate, C2, and bundles
it with the public key, P2, of the TPMidentity sent by the
customer. This second bundle is then encrypted with the public
endorsementkey, P1, of the TPM.
[0025] 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 unauthorizedrequests
for certificates from a CA. The TPM will then decrypt the first
bundle with the privatekey, P4, of its TPM identity to obtain the
certificate, C2, issued by the CA. The result is a TPMidentity that
has been signed by a CA.
[0026] 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 thesystem is
able to move such keys to other systems, as long as the owner knows
the correctauthorization 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 toa
credit card company. Currently, a consumer exposes his key to a
seller every time he shows hiscredit card, so currently, there is
no requirement that keys be kept out of the hands of thecustomer.
"Non-migratable" keys are locked to the hardware in a way that they
cannot be clonedor migrated to another system even by the owner.
They are thus inherently more secure.
[0027] 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 thatthe
TPM can read them (i.e., a storage key decrypts items into the
TPM). To create anon-migratable storage key, the customer may use
the CreateWrapKey function of the TCPASpecification. There may also
be a piece of software that does this for the user in a
user-friendlyway. The customer will then decide if the key, K1,
will require authorization or not, and whatthat authorization would
be. When the key is created, the customer decides if he wants to
requireauthorization for use and if so, what pass phrase to use to
provide the authorization. Softwarecan 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 forstoring this key (the SRK
(storage root key) is available). The parent key is a key used to
storeanother key. The key stored is called a child, while the key
used to do the storing is called theparent. In particular, if there
are two key pairs, Private One, Public One and Private Two,
PublicTwo, if Private Two is encrypted with Public One, then the
first key pair would be referred to asthe parent and the second key
pair the child. Further, there is one key that is guaranteed
toalways be loaded inside the chip. It is called the storage root
key, and it is an ancestor of everyother key the chip can use. To
load a key into the chip, it needs to have its parent's private
keyalready loaded in the chip (so the chip can decrypt it). If the
SRK is the great grandparent of akey, first one would need to load
the grandparent of a key in the chip, then the parent of the
keyinto the chip, and finally the key itself into the chip. This
structure, called a daisy chain, is used toallow a TCPM chip to
"store" an unlimited number of keys. The customer will then execute
aTPM_CreateWrapKey command, with required parameters indicating the
key produced will be astorage key. The customer then signs the
non-migratable storage key, K1, with the TPM identitykey, P2,
creating a certificate, C3, for that non-migratable storage
key.
[0028] 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-bitRSA
key. Signing keys can be used by the TPM to sign the hash of a
message (i.e., encrypt thehash of a message). The customer decides
if this signing key, K2, will require authorization ornot, and what
that authorization will be. The customer decides what parent will
be used forstoring this key (the SRK is available). The customer
executes the TPM_CreateWrapKeycommand, with required parameters
indicating the key, K2, will be a signing key. And then,
thecustomer signs the non-migratable signing key, K2, with the TPM
identity key, P2, creating acertificate, C4, for that key, K2.
[0029] In step 203, the customer contacts a credit card company
over the Internet by browsing the credit card company's website. In
step 204, the customer applies for a credit cardauthorization at
the credit card company website by entering into a secure section
of that websiteto fill out an application form. This implies a
Secure Sockets Layer (SSL) to prove to thecustomer that the
information he is giving the credit card company is not snoopable,
and acertificate to prove to the customer he is indeed at the
credit card company's web site. SSL is ameans of creating encrypted
communication between a user and a web site for entering a
creditcard without snoopers being able to access the number. The
customer fills out the applicationform with his name, address and
whatever other information the credit card company requires
todetermine whether the customer is credit worthy.
[0030] 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 companythe
non-migratable public portion of the storage key, K1, the
certificate, C3, by the TPM identitythat the RSA storage key is a
non-migratable TPM key, the certificate, C2, from the CA that
theTPM identity is indeed a TPM identity, and a pass phrase the
customer would like to use forauthorizing use of the requested
credit card authorization. It is at this point that the credit
cardcompany can evaluate the requested pass phrase and turn it down
if it appears to be too trivial.
[0031] 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
cardcompany 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 phraseis chosen by the user, but is never
provided to the credit card company.
[0032] 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 TPMidentity
certificate, C2, to see the level of security inherent in the TPM
system to determine if thatis sufficient to proceed. The credit
card company may also check to see if the TPM identitycertificate,
C2, has been revoked by the CA that issued it.
[0033] 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-migratablestorage key, K1, under the first alternative
discussed above, then the credit card company willperform 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 kindof key, the TPM
identity certificate, C2, will have to be checked to see if the TPM
supports sucha different kind of key. The credit card company will
then create a header for the key, P5, usingthe 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 passphrase selected by the
customer, a migration pass phrase the credit card company
generates, andcreating a TCPA key bundle wrapping the key, P5, in
the public key, K1, the customer gave thecredit card company. In
another alternative embodiment, the credit card company can create
theheader by using its own TCPA chip by commanding it to create a
migratable key using therequisite pass phrases and choosing its own
storage key (of any sort) for its own TPM, and thenmigrating that
key to the customer's TPM public key, K1. If the credit card
company performsthis process, it must pass the end user the bundle
and the random number that is used for thistransition.
[0034] 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
(traditionalmail services) a diskette with the bundle stored on it
to the verified address of the customer. Inanother alternative
embodiment of this subset, the credit card company emails or mails
the bundleto the customer (thus allowing verification of address)
and either mails the random number to thecustomer with the bundle,
or mails the random number to the end user separately, or mails the
enduser a 1-800 telephone number to call in order to get the random
number (thus allowingverification of telephone number).
[0035] 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 themailing
address (proving verification of address) on a diskette. If the
credit card company alsowants to verify the telephone number, the
certificate can be encrypted, for example X-ored withthe SHA-1 hash
of a pass phrase which is delivered over the phone.
[0036] 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
tochoose, and which has a certificate of the credit card company.
The credit card company canrevoke the certificate whenever it
wants.
[0037] 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 thecustomer,
by simply re-wrapping the key with multiple storage keys of the
customer. This is notpossible with the second alternative where a
signing key is created, unless the credit card companyis willing to
use migratable signing keys.
[0038] An advantage of the second alternative discussed above where
the customer creates anon-migratable public portion of a signing
key, the credit card company never receives the passphrase from the
customer used to authorize use of the key on the customer's
system.
[0039] 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 takesthe
certificate, C1, that was signed by the manufacturer of the system.
This includes informationregarding the security level the system
was designed to as well as a certificate from themanufacturer 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," a2048-bit RSA signing key.
The TPM returns the public portion of that key, P2. The
customertakes 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 boththe TPM and the system and then provides a certificate, C6,
for P2. However, the credit cardcompany encrypts this certificate,
C6, using P1 (as per the TCPA Specification). This
encryptedcertificate is sent back to the customer of the system.
The customer sends the encryptedcertificate, C6, to his TPM,
(reloading the TPM identity key if necessary). The TPM checks
thecertificate against the identity key making certain that they
match. If they do, the TPM exportsenough information to decrypt the
credit card company's certificate, C6, for that key.
[0040] 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 thepublic
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 identitycertificate that
it is a non-migratable (storage or signing) key. The customer then
sends the publicportion of the non-migratable key, its
identity-based certificate, and the credit card companycertificate,
C6, for the identity, back to the credit card company, which can
then use its owncertification of the quality of the non-migratable
key.
[0041] 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'scomputer
system. The embodiment provides for secure usage of the key while
retaining thekey's transfer within the control of the remote
entity.
[0042] 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 theexample
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 usageof the key to secure environments), and (iii)
preserve control over the usage of the key - forexample,
restricting usage to the end user (so that only the designated end
user can use the creditcard). In the example which follows, a
credit card company deploying a credit card product isshown as
employing the method of doing business of this embodiment. The end
product need notbe 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 oflimitation, the company can be a trust management
company and the product can be a trust or willwhere authentication
is given for power of attorney. The company can be an cable
televisioncompany and the product a cable subscription service such
as pay per view. The company may bean insurance provider and the
product a medical benefits dispersion. In short, a provider
benefitsby the teachings of this embodiment for secure
authentication for anything having good andvaluable
consideration.
[0043] 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 a credit card company 402. In step 404, thecredit card
company 402 receives a credit card private key request from an end
user 401 whenend user 401 applies for a credit card private key. In
step 405, the credit card company 402checks that the Applicant is
qualified to receive the credit card key. This checking step 405
canbe for example the checking of the end user's 401 credit
worthiness. In still another embodimentof step 405, and not by way
of limitation, the checking step 405 can be to check whether the
enduser has an existing account etc. Upon qualification, in step
407, the credit card company 402requests of the end user's 401
Trusted Platform Module (TPM) associated with the end user's401
computer system a secure non-migratable storage key. Next, in step
408, the credit cardcompany 402 receives the secure non-migratable
storage key generated by end user's 401 TrustedPlatform Module. To
create a non-migratable storage key, the customer may use
theCreateWrapKey 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
secureand non-migratable; (B) a certificate from a TPM identity key
which states that the storage key is secure andnon-migratable along
with a certificate from a Certificate Authority which states that
the TPMidentity is a TPM identity; or(C) an endorsement key
certificate from a Certificate Authority , and a certificate from
aTPM identity key which states that the storage key is secure and
non-migratable along with acertificate from a Certificate Authority
which states that the TPM identity is a TPM identity.
[0044] Steps 409 and 410 are optionally utilized when it is the
items of (C) which are received. In this case, the credit card
company 402 creates a certificate for the TPM identity key,
encryptsthe certificate as per the TCPA specification / TPM
specification - as in for example key1, andsends key1 back to the
user encrypted in a blob containing the public identity key and
encryptedwith the public endorsement key. When steps 409 and 410
are required, processing continueswith step 410. In step 410, a
decrypted identity certificate is received by the credit card
company402. This decrypted identity certificate is generated as a
result of the end user 401 utilizing theTPM 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 decryptthe certificate - but
only if the TPM identity key matches the identity key generated by
that TPM.
[0045] 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 publicportion of the storage key, and(B) continues with the
step shown at 411. In step 411, the credit card company 402wraps
the second copy with the public storage key as per the TPM
specification, and sends therequested credit card private key back
to the user.
[0046] Upon receipt of the credit card private key per step 411,
the method continues with the final step 412. In step 412, the user
401 waits to receive the code word necessary to use the keyvia 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.
[0047] 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 user401 and the
credit card company 402. Details concerning VPNs are well known in
the art and areomitted 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 asfollows: A VPN is setup between the credit card
company 402 and the end user 401, usingthe private key of the user
to identify the credit 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.
[0048] 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 withoutdeparting
from the spirit and scope of the invention as defined by the
appended claims.
* * * * *
References