System and method for secure smartcard issuance

• US 20020112156A1
• Filed: 08/14/2001
• Published: 08/15/2002
• Est. Priority Date: 08/14/2000
• Status: Abandoned Application

• Current Assignee: Identrus LLC (Assa Abloy AB), Secude Sicherheits Technologie Informations Systeme GmbH
• Original Assignee: Identrus LLC (Assa Abloy AB)
• Inventors: Gien, Peter H., Hetschold, Thomas
• Application Number:
  US09/928,999
• Publication Number:
  US 20020112156A1
• Time in Patent Office: Days
• US Class Current: 713/156
• CPC Class Codes: G06F 21/645 using a third party
• CPC Class Codes: G06F 2221/2119 Authenticating web pages, e.g. with suspicious links
• CPC Class Codes: G06Q 20/00 Payment architectures, schemes or protocols apparatus for performing or posting payment transactions G07F7/08, G07F19/00; electronic cash registers G07G1/12
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/341 Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• CPC Class Codes: G06Q 20/355 Personalisation of cards for use
• CPC Class Codes: G06Q 20/3558 Preliminary personalisation for transfer to user
• CPC Class Codes: G06Q 20/3674 involving authentication
• CPC Class Codes: G06Q 20/382 insuring higher security of transaction
• CPC Class Codes: G06Q 20/3823 combining multiple encryption tools for a transaction
• CPC Class Codes: G06Q 20/3825 Use of electronic signatures
• CPC Class Codes: G06Q 20/3829 involving key management
• CPC Class Codes: G06Q 20/389 Keeping log of transactions for guaranteeing non-repudiation of a transaction
• CPC Class Codes: G06Q 40/08 Insurance
• CPC Class Codes: G07F 7/1008 Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• CPC Class Codes: H04L 2463/102 applying security measure for e-commerce
• CPC Class Codes: H04L 63/062 for key distribution, e.g. centrally by trusted party cryptographic mechanisms or cryptographic arrangements for key distribution involving a central third party H04L9/0819
• CPC Class Codes: H04L 63/0823 using certificates cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263
• CPC Class Codes: H04L 63/0853 : using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 63/126 : the source of the received data

Abstract

A system and method are disclosed for ensuring the security and integrity of a party'"'"'s private key stored on a smartcard or other hardware token. A set of security requirements are defined for the smartcard that ensure that the card is manufactured and initialized in a secure environment and that it can withstand certain types of cryptographic and other attacks. The requirements further ensure that, at the conclusion of the initiation process, there exists only a single instance of the private key, thus decreasing the likelihood of a subsequent key compromise.

Claims

1. A method for facilitating secure hardware token issuance and use, comprising:

storing an only instance of a private key on the hardware token, the hardware token being adapted to prevent the private key from being exported from the hardware token;

binding the private key to a subscriber with a digital certificate;

creating a contract establishing ownership over the physical manifestation of the private key;

using the private key to create a digital signature on the hardware token.

2. The method of claim 1, wherein the hardware token is issued by a trusted entity.

3. The method of claim 2, wherein the contract specifies that the physical manifestation of the private key is owned by the trusted entity.

4. The method of claim 3, wherein the trusted entity is an issuing participant.

5. The method of claim 1, wherein the contract specifies that the physical manifestation of the private key is owned by a root entity.

6. The method of claim 1, wherein the contract specifies that the physical manifestation of the private key is owned by the subscriber.

7. The method of claim 1, wherein the hardware token is a smartcard.

8. The method of claim 1, wherein the hardware token is a PCMCIA device.

9. The method of claim 1, wherein the private key is an identity private key.

10. The method of claim 1, wherein the hardware token comprises means for monotonically counting each time the private key is used to create a digital signature.

11. The method of claim 1, wherein the hardware token comprises means for permanently storing a PIN/passphrase.

12. The method of claim 11, wherein the subscriber must enter the PIN/passphrase before a digital signature is generated.

13. The system of claim 12, wherein the subscriber must enter PIN/passphrase each time a digital signature is generated.

14. The system of claim 1, wherein the digital signature comprises security data.

15. The system of claim 14, wherein the security data is signed to create a security-data cryptogram.

16. The system of claim 15, wherein the security-data cryptogram is generated using an algorithm different than the one used to create the digital signature.

17. The system of claim 14, wherein the security data comprises data that is the subject of the digital signature.

18. A method for facilitating secure smartcard issuance and use, comprising:

providing a smartcard;

generating a private key on a hardware security module not resident on the smartcard;

copying the private key into memory on the smartcard;

adapting the smartcard to prevent the private key from being exported from the smartcard; and

destroying all instances of the private key not resident in the memory on the smartcard.

19. A system for facilitating secure smartcard issuance and use, comprising:

a smartcard;

means for generating a private key on a hardware security module not resident on the smartcard;

means for copying the private key into memory on the smartcard;

means on the smartcard for preventing the private key from being exported from the smartcard; and

means for destroying all instances of the private key not resident in the memory on the smartcard.

20. A method for facilitating secure hardware token issuance and use, comprising:

providing a signing module, the signing module comprising a hardware token, the hardware token permanently storing a single instance of a private key and being adapted to sign data in connection with transactions conducted within the context of a four-corner model comprising a root entity, a first participant, a second participant, a first customer of the first participant, the first customer having possession of the hardware token, and a second customer of the second participant;

the root entity identifying a plurality of high-level security objectives relating to the hardware token, the high-level security objectives comprising;

a. It is beyond practicality to breach the confidentiality of the private key;

b. It is beyond practicality to breach the confidentiality of a PIN/passphrase stored on the hardware token;

c. It is beyond practicality to change the life-cycle status of the hardware token;

d. It is beyond practicality to breach the integrity of the counters associated with blocking and unblocking mechanisms on the hardware token;

e. It requires a high security level attack to breach the confidentiality and/or integrity of data and program structures on the hardware token;

f. It requires a high security level attack to breach the integrity of a bond between the first customer'"'"'s identity and the hardware token;

g. It requires a high security level attack to breach the integrity of root entity applications present at the hardware token; and

h. It requires a high security level attack to breach the integrity of the signing module; and

the root entity identifying a plurality of low-level requirements to address the high-level objectives.

21. The method of claim 20, wherein the low-level requirements comprise:

a. It is beyond practicality to remove layers on top of a chip surface of the hardware token without damaging the chip;

b. It requires a high security level attack to visualize the contents of read only memory (ROM) memory cells, including electrically erasable programmable read only memory (EEPROM) cells;

c. It is beyond practicality to reverse engineer the functionality of the hardware token;

d. It is beyond practicality to modify chip structures by means of an FIB system;

e. It is beyond practicality to modify individual memory cells;

f. It requires a high security level of attack to misuse the hardware token chip'"'"'s test features;

g. It requires a high-level security attack to modify the hardware token chip'"'"'s fuses;

h. It requires a high-level security attack to modify or disable hardware token chip 401'"'"'s security sensors;

i. It is beyond practicality to use a probing attack to retrieve information from the hardware token;

j. It requires a high security level attack to change the status of a memory of the hardware token via active probing techniques;

k. It requires a high security level attack to influence the correct functionality of logical building blocks at the hardware token by means of active probing techniques;

l. It requires a high security level attack to influence the correct execution of applications approved by the root entity at the hardware token by means of active probing techniques;

m. It requires a high security level attack to influence the correct programming of memory cells by means of active probing attacks;

n. It requires a high security level attack to obtain information from the hardware token via voltage contrast;

o. It is beyond practicality to obtain sensitive information from the hardware token by analyzing externally available information, such as a power consumption profile or timing analysis of critical processes on the hardware token;

p. It is beyond practicality to influence the correct execution of applications approved by the root entity on the hardware token by disturbing external parameters such as clock input, temperature, or power supply;

q. It is beyond practicality to obtain sensitive information by disturbing external parameters of the hardware;

r. It requires a high security level attack to change the status of the memory by means of disturbing external parameters of the hardware token.

22. The method of claim 21, further comprising identifying a plurality of potential threats to the hardware token and determining that the low-level requirements address the potential threats.

23. The method of claim 22, wherein the potential threats comprise chip modification, reverse engineering, restoration of testing hardware and software, internal attack, and external attack.

24. The method of claim 23, wherein the external attacks include SPA, DPA, and manipulation of the hardware token environment.