US20190035201A1

US20190035201A1 - Method and apparatus for establishing trust in smart card readers

Info

Publication number: US20190035201A1
Application number: US16/150,616
Authority: US
Inventors: Joseph F. Cihula
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-12-24
Filing date: 2018-10-03
Publication date: 2019-01-31
Also published as: US20050149457A1; US10109141B2

Abstract

A method for managing a smart card system includes testing a smart card reader for trustworthiness. An indication of the trustworthiness is provided via a smart card.

Description

PRIORITY CLAIM

The present application is a divisional of, and claims the benefit of priority of, U.S. patent application Ser. No. 10/746,077, filed Dec. 24, 2013.

FIELD

An embodiment of the present invention relates to smart cards. More specifically, an embodiment of the present invention relates to a method and apparatus for establishing trust in smart card readers.

BACKGROUND

Many smart cards are cards embedded with memory and a processor that allows data to be stored and transacted between parties. The data may, for example, be associated with a value and/or information. The data may be transacted via a smart card reader that is part of a computing system. Today, smart cards have applications in industries such as healthcare, banking, entertainment, and transportation.
In order to protect their data, some smart cards require user authentication before releasing the data to a smart card reader. The user authentication may involve requesting personal information from a user that is compared with stored personal information on the smart card. The personal information may range from non-physical types of information such as personal identification numbers (PINs) or passwords to more personal types of information such as biometrics. Biometrics may include, for example, blood vessel patterns in a retina, fingerprints, DNA and other biological properties of the user. Unlike non-physical types of information, biometrics are unique to the user. If compromised, biometrics may be difficult if not impossible for a user to change.
Most public smart card systems today are unconditionally trusting of smart card readers. These smart card systems do not provide a mechanism for which a user can determine whether a smart card reader is trustworthy or reliable. This may become problematic when sensitive personal information such as biometrics is provided to an untrustworthy or unreliable smart card reader during user authentication. One approach to protecting personal information involves placing user authentication hardware directly on the smart card instead of requiring the reader to have it. This solution, however, increases the overall size and the cost of manufacturing the smart card, which is undesirable.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the embodiments of the present invention are illustrated by way of example and are by no means intended to limit the scope of the present invention to the particular embodiments shown, and in which:

FIG. 1 is a block diagram of a smart card system according to an embodiment of the present invention;

FIG. 2 is a block diagram of smart card reader attestation unit according to an embodiment of the present invention;

FIG. 3 illustrates trust data from a smart card reader according to an embodiment of the present invention;

FIG. 4 illustrates trust data from a smart card reader according to a second embodiment of the present invention;

FIG. 5 is a block diagram of a smart card attestation unit according to an embodiment of the present invention;

FIG. 6 is a block diagram of an attestation verifier unit according to an embodiment of the present invention; and

FIG. 7 is a flow chart illustrating a method for establishing trust in a smart card reader according to an embodiment of the present invention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of embodiments of the present invention. However, it will be apparent to one skilled in the art that these specific details may not be required to practice the embodiments of the present invention. In other instances, well-known circuits, devices, and programs are shown in block diagram form to avoid unnecessarily obscuring embodiments of the present invention.
FIG. 1 is a block diagram of a smart card system 100 according to an embodiment of the present invention. The smart card system 100 includes a smart card 110 and a smart card reader 120. The smart card 110 includes a processor 111 that processes data signals. The processor 111 may be a microprocessor implemented by a single chip or a processor implemented by a plurality of chips. The smart card 110 includes a memory 112. The memory 112 may store instructions and code that may be executed by the processor 111. The memory 112 may be implemented with a dynamic random access memory device, a static random access memory device, or other memory device. The smart card 110 includes storage unit 113. The storage unit 113 may store trust data. This data may be used to describe a smart card reader in terms of the attributes and states of its components. For example, the trust data may include cryptographic measurements of trusted and untrusted smart card readers and smart card reader components. The smart card 110 includes an indicator 114 that outputs an indication to a user of the smart card 110. The indicator 114 may be a visible indicator such as a light, an audible indicator such as a speaker, or other type of indicator. Alternatively, the indicator 114 may cause the smart card 110 to vibrate, change temperature or generate other types of indications. The smart card 110 includes input/output interface 115. The input/output interface 115 allows the smart card 110 to communicate with the smart card reader 120.
The smart card reader 120 includes a processor 121 that processes data signals. The processor 121 is coupled to other components of the smart card reader 120 via bus 122. The smart card reader 120 includes a smart card interface 123. The smart card interface 123 allows the smart card reader 120 to communicate with the smart card 110 via its input/output interface 115. The smart card reader 120 includes a memory 124. The memory 124 may store instructions and code represented by data signals that may be executed by the processor 121. The smart card reader 120 includes storage unit 125. The storage unit 125 may store data such as instructions and code, certificates (credentials) for attributes of components and keys on the smart card reader 120, a private key for the smart card reader 120, and other data. The smart card reader 120 includes a display device 126 that outputs data and other information to a user. The smart card reader 120 includes a measurement agent 127. The measurement agent 127 generates a measurement value. According to one embodiment, measurement values represent attributes of components or states of the smart card reader 120. The smart card reader 120 includes a signing unit 128. The signing unit 128 includes a unique asymmetric signing key, protected by its hardware, that may be used to generate digital signatures for data. It should be appreciated that the measurement agent 127 and signing unit 128 may be implemented as a single combined measurement/signing unit. In this embodiment of the invention, additional measurement agents (not shown) may be used to generate measurement values. The combined measurement/signing unit may be used to generate digital signatures for the measurement values from the additional measurement agents. The smart card reader 120 includes an authentication unit 129. The authentication unit 129 collects authentication data. The authentication data may be non-physical data and/or biometrics.
According to an embodiment of the present invention, the smart card 110 tests the smart card reader 120 for trustworthiness. This may be achieved by transmitting a request to the smart card reader 120 for its trust data and determining whether the data received is acceptable. The trust data may include, for example, certificates and/or other signed data describing attributes of components on the smart card reader. In response to determining the trustworthiness of the smart card reader 120, the indicator 114 on the smart card 110 provides an indication of the trustworthiness to the user.
FIG. 2 is a block diagram of smart card reader attestation unit 200 according to an embodiment of the present invention. According to an embodiment of the smart card reader 120 (shown in FIG. 1), the smart card reader attestation unit 200 is implemented in software and resides in memory 124 (shown in FIG. 1) of the smart card reader 120 as sequences of instructions. It should be appreciated that the modules may also be implemented by hardware or a combination of both hardware and software.
The smart card reader attestation unit 200 includes a reader attestation protocol module (APM) 210. The reader attestation protocol module 210 prepares trust data to be transmitted to the smart card 110 in response to receiving a request or challenge from the smart card 110 to prove the reader's trustworthiness. The reader attestation protocol module 210 may also receive a nonce from the smart card 110 to be included in the trust data to be transmitted back.
The smart card reader attestation unit 200 includes a certificate handler 220. The certificate handler 220 interfaces with the storage unit 125 (shown in FIG. 1) of the smart card reader 120 to retrieve appropriate certificates to be transmitted to the smart card 110 in response to requests from the reader attestation protocol module 210. The certificates may include certificates associated with components on the platform of the smart card reader 120. These certificates may include a cryptographically signed description of a manufacturer, model number, or other information of a component and a public key that may be used for verification of the signature. The certificates may also include certificates associated with conformance testing. These certificates may include a cryptographically signed indicator of validation to some specification and a public key that may be used for verification of the signature. According to an embodiment of the smart card reader attestation unit 200, each public key transmitted includes a certificate signed by a certifying authority that attests to the public key's authenticity. According to an embodiment of the present invention, the certificate may be compliant with the X.509 v3 digital certificate standard (published April 2002).
The smart card reader attestation unit 200 includes a measurement agent manager 230. The measurement agent manager 230 interfaces with a measurement agent 127 and retrieves measurement values from the measurement agent 127 to be transmitted to the smart card 110 in response to requests from the reader attestation protocol module 210. Measurement values may represent information regarding a component or state of the smart card reader 120. The measurement values may include a value indicating whether the smart card reader 120 has been tampered with, data associated with a version of software running on the smart card reader 120, or other measurement values that may be generated dynamically.
The smart card reader attestation unit 200 includes a measurement value processor 240. The measurement value processor 240 interfaces with a signing unit 128 that cryptographically signs the measurement values generated by the measurement agent. According to an embodiment of the smart card reader attestation unit 200, the measurement value processor 240 combines the measurement values with a nonce received from the smart card 110 such that a cryptographic signature may be generated.
According to one embodiment of the present invention, the reader attestation protocol module 210 transmits with the measurement data, the cryptographic signature for the trust measurement data, certificates from the measurement agents and signing unit, and certificates from a certifying authority that authenticates the certificates from the measurement agents and signing unit.
FIG. 3 illustrates trust data 300 that may be transmitted by a smart card reader according to an embodiment of the present invention. The trust data 300 may be used to describe pre-configured components and properties of a smart card reader. The trust data 300 includes one or more certificates 310. The certificate 310 includes data 311 about one or more properties or components of the reader. If the component(s) are hardware component(s), for example, the data 311 may be a manufacturer or model number of the hardware component. The data may also relate to diagnostic test results performed on component(s). The certificate 310 includes a digital signature 312. The signature 312 may be generated by performing a hash function on the data 311 to form a digest, and encrypting the digest with a private key corresponding to the entity generating the signature. The certificate 310 includes a public key 313. The public key 313 may be used to verify the signature 312.
Trust data 300 may include one or more certificates 320 from trustworthy certifying authority(ies). The certificate 320 includes data 321 that includes a public key corresponding to the entity generating the signature 312 and may be used to attest to the trustworthiness of the signature key for certificate 310. According to an embodiment of the present invention where the signature 312 is authentic, the public key in data 321 is the same as the public key 313. The certificate 320 includes a digital signature 322. The signature 322 may be generated by performing a hash function on the public key 321 to form a digest, and encrypting the digest with a private key corresponding to the trustworthy certifying authority. A public key corresponding to the trustworthy certifying authority may be used to verify the signature 322. The public key may be stored as 323 on the certificate 320. It should be appreciated that the certificate 320 from the certifying authority need not be included in the trust data 300. The public key for the entity generating the signature 312 may be known and stored on the smart card 110 (shown in FIG. 1). In this example, no certifying authorities for that certificate need to be used.
FIG. 400 illustrates exemplary trust data 400 that may be transmitted by a smart card reader according to a second embodiment of the present invention. The trust data 400 may be used to describe measurement values that are generated dynamically by the component(s) generating and signing the measurement values. The trustworthy data 400 includes a signed data 410. The signed data 410 includes information that attests to the trustworthiness of the measurement process. The signed data 410 includes data 411 which includes the actual measurement values. According to an embodiment of the present invention, the data 411 also includes the nonce received from the smart card requesting the trust data 400. The signed data 410 includes a digital signature 412. The signature 412 may be generated by performing a hash function on the data 411 to form a digest, and encrypting the digest with a private key corresponding to the signing unit. The signed data 410 includes a public key 413 corresponding to the private key of the signing unit. The public key 413 may be used to verify the signature 412. According to an embodiment of the present invention, the entity generating the measurement values 411 and the entity generating the signature 412 are the same.
The trust data 400 includes certificate 420. The certificate 420 includes information that attest to the trustworthiness of the measurement/signing (M/S) unit that generated measurement values 411 and signature 412. The certificate 420 includes data which is a public key that may be used to verify the signature 412. The certificate 420 includes digital signature 422. The signatures 422 may be generated by performing a hash function on the data 421 to form a digest, and encrypting the digests with a private key corresponding to a certifying authority generating the signature 422. The certificate 420 includes public key 423 that corresponds to the certifying authority generating the signature 422
Trust data 400 may include a certificate 440 from a trustworthy certifying authority. The certificates 440 includes data 441 which include the public key corresponding to the certifying authority and may be used to attest to the trustworthiness of the certificate 420. The certificate 440 include digital signature 442. The signature 442 may be generated by performing a hash function on the data 441 to form a digest, and encrypting the digest with a private key corresponding to the trustworthy certifying authority. A public key 443 corresponding to the trustworthy certifying authority may be used to verify the signature 442. Alternatively, the public key corresponding to the certifying authority generating signature 422 may be known and stored on smart card 110 (shown in FIG. 1). In this example, certificate 440 need not be included in the trust data 400. FIGS. 3 and 4 show exemplary embodiments of trust data. It should be appreciated that trust data 300 and 400 may include additional and/or differing types of data.
FIG. 5 is a block diagram of smart card attestation unit 500 according to an embodiment of the present invention. According to an embodiment of the smart card 110 (shown in FIG. 1), the smart card attestation unit 500 is implemented in software and resides in main memory 112 (shown in FIG. 1) of the smart card 110 as a sequence of instructions. It should be appreciated that the modules may also be implemented by hardware or a combination of both hardware and software.
The smart card attestation unit 500 includes a smart card attestation protocol module (APM) 510. The smart card attestation protocol module 510 sends a request or challenge to the smart card reader 120 (shown in FIG. 1) to prove its trustworthiness. The smart card attestation protocol module 510 may also transmit a nonce that will then be included in the trust data to be transmitted from the smart card reader 120.
The smart card attestation unit 500 includes a nonce generator 520. The nonce generator 520 generates a nonce (“number used once”) that is transmitted to the smart card reader 120 along with a request to prove its trustworthiness. By having the smart card reader 120 transmit the nonce with the trust data, the smart card 110 adds a layer of security to allow detection of replayed trust data from a reader.
The smart card attestation unit 500 includes an attestation verifier unit 530. The attestation verifier unit 530 determines whether the smart card reader 120 is trustworthy from the trust data received from the smart card reader 120. According to an embodiment of the smart card attestation unit 500, the attestation verifier unit 530 verifies the signatures of the certificates received and determines whether the data describing attributes of the smart card reader 120 are acceptable.
The smart card attestation unit 500 includes a trust indicator unit 540. The trust indicator unit 540 interfaces with an indicator 114 (shown in FIG. 1) on the smart card 110 and prompts the indicator 114 to give an indication of the trustworthiness of the smart card reader 120 in response to the attestation verifier unit 530. According to an embodiment of the smart card attestation unit 500, the trust indicator 540 may prompt the indicator 114 to turn on a light, generate an audible sound, and/or produce other indications of the trustworthiness of the smart card reader 120.
FIG. 6 is a block diagram of an attestation verifier unit 600 according to an embodiment of the present invention. The attestation verifier unit 600 may be used to implement the attestation verifier unit 530 shown in FIG. 5. The attestation verifier unit 600 includes a trust data manager 610 that receives the trust data generated by the smart card reader 120 (shown in FIG. 1) and coordinates the verification of signatures and evaluation of data.
The attestation verifier unit 600 includes a key retriever unit 620. The key retriever unit 620 retrieves the appropriate key for verifying a signature on a certificate. For certificates originating from a certifying authority, the key retriever unit 620 may retrieve a public key associated with the certifying authority from the storage unit 113 of the smart card 110 (shown in FIG. 1). For certificates originating from a source other than a certifying authority, the key retriever unit 620 may retrieve a public key associated with the certificate from the certificate itself or from the storage unit 113. According to one embodiment, a hash of the public key can be stored instead of the public key in order to save storage space. In this case, the hash must be compared to the hash of the provided public key and then the provided pubic key is used to decrypt.
The attestation verifier unit 600 includes a digest decrypter unit 630. The digest decrypter unit 630 receives a key retrieved from the key retriever unit 620. The digest decrypter unit 630 decrypts a signature in a certificate generated by a private key corresponding to the public key. The decrypted signature is referred to as a decrypted digest.
The attestation verifier unit 600 includes a hashing unit 640. The hashing unit 640 performs a hash function on data in a certificate to generate a digest.
The attestation verifier unit 600 includes a comparator unit 650. The comparator unit 650 compares the digest generated by the hashing unit 640 with the digest decrypted from a signature by the digest decrypter unit 630. If the digests match, the comparator unit 650 determines that the signature is trustworthy and the signature is verified. The comparator unit 650 may further compare the data, which may include attributes or states of the smart card reader 120, with acceptable attributes and states to determine whether the smart card reader 120 is trustworthy. When performing comparisons, the comparator unit 650 is capable of processing data having dynamic properties (dynamic data) such as position and time. For example, a smart card able to determine its position may be able to process conditions where the smart card's coordinates are part of a trust equation. It should be appreciated that other types of dynamic data may also be processed by the comparator unit 650.
FIG. 7 is a flow chart of a method for establishing trust in a smart card reader according to an embodiment of the present invention. At 710, a request to attest is generated by a smart card and transmitted to a smart card reader. The request to attest challenges the smart card reader to prove its trustworthiness. According to an embodiment of the present invention, a nonce is generated by the smart card and transmitted to the smart card reader with the request to attest.
At 720, measurement values are signed by the smart card reader in response to receiving the request to attest. According to an embodiment of the present invention, a hash function is performed on the measurement values and the nonce received from the smart card to generate a digest. The digest is signed by a private key of a signing unit on the smart card reader.
At 730, certificates are retrieved. According to an embodiment of the present invention, certificates associated with components responsible for generating the measurement values, signing the measurement values, and/or other functions of the smart card reader, and certificates generated by a certifying authority associated with attesting to the trustworthiness of these certificates are retrieved.
At 740, trust data is transmitted to the smart card. According to an embodiment of the present invention, the signed measurement values and certificates retrieved are transmitted to the smart card.
At 750, it is determined whether the signatures are trustworthy and verifiable. According to an embodiment of the present invention, one or more public keys associated with a trustworthy certifying authority are first used to determine the trustworthiness of a certificate(s) signed by the certifying authority. Thereafter, public keys in the certificate(s) generated by the certifying authority are used to determine the trustworthiness of other certificates transmitted by the smart card reader. If the signatures in the certificates are trustworthy, control proceeds to 760. If the signatures in the certificates are not trustworthy, control proceeds to 770.
At 760, data in the certificates that correspond to attributes and/or states of components of the smart card reader are compared with acceptable and unacceptable attributes and/or states of the components of the smart card reader. According to one embodiment, if a nonce is sent the nonce received is compared with the nonce sent. If the data is not acceptable, control proceeds to 770. If the data is found to be acceptable, control proceeds to 780.
At 770, an indication is generated to indicate that the smart card reader is not trustworthy.
At 780, an indication is generated to indicate that the smart card reader is trustworthy.
FIG. 7 is a flow chart illustrating a method of establishing trust in a smart card reader according to embodiments of the present invention. Some of the techniques illustrated in this figure may be performed sequentially, in parallel or in an order other than that which is described. It should be appreciated that not all of the techniques described are required to be performed, that additional techniques may be added, and that some of the illustrated techniques may be substituted with other techniques.
In the foregoing specification the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the embodiments of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.

Claims

What is claimed is:

1. A method for managing a smart card system, comprising:

testing a smart card reader for trustworthiness by comparing a test result for a component of the smart card reader with an acceptable test result stored on a smart card; and

providing an indication of the trustworthiness of the smart card reader to a smart card user via the smart card.

2. The method of claim 1, wherein testing the smart card reader for trustworthiness comprises:

transmitting a request to the smart card reader for trust data; and

determining whether the trust data received is acceptable.

3. The method of claim 2, wherein determining whether the trust data is acceptable comprises:

determining whether a first certificate has a valid digital signature;

determining whether a public key from the first certificate is trustworthy; and

comparing data in the first certificate with data in the smart card.

4. The method of claim 3, wherein determining whether the public key from the first certificate is trustworthy comprises:

decrypting a signature of a second certificate with a public key for the second certificate to generate a first digest for the second certificate;

performing a hash function on data in the second certificate to generate a second digest for the second certificate;

identifying the data in the second certificate as the public key for the first certificate if the first digest and the second digest match; and

comparing the data in the second certificate with the public key from the first certificate.

5. The method of claim 3, wherein determining whether the first certificate has the valid digital signature comprises:

decrypting a signature of the first certificate with the public key for the first certificate to generate a first digest for the first certificate;

performing a hash function on data in the first certificate to generate a second digest for the first certificate; and

comparing the first digest for the first certificate with the second digest for the first certificate.

6. The method of claim 1, wherein providing an indication of the trustworthiness on the smart card comprises turning on a light.

7. The method of claim 1, wherein providing an indication of the trustworthiness of the smart card comprises generating an audible sound.

8. The method of claim 2, wherein the request includes a nonce.

9. The method of claim 3, further comprising comparing a nonce from the smart card with a nonce from the smart card reader.

10. The method of claim 2, wherein determining whether the trust data is acceptable comprises:

determining whether signed data has a valid digital signature;

determining whether a public key from the signed data is trustworthy; and

comparing data in the first signed data with data in the smart card.

11. The method of claim 9, wherein the signed data includes measurement values.

12. A method for managing a smart card system, comprising:

testing a smart card reader for trustworthiness by comparing an identity of a component of the smart card reader with an acceptable identity stored on a smart card; and

13. A method for managing a smart card system, comprising:

testing a smart card reader for trustworthiness by comparing a measurement value of a component of the smart card reader with an acceptable measurement value stored on a smart card; and

14. A smart card, comprising:

an attestation verifier unit to test a trustworthiness of a smart card reader by comparing a test result of a component of the smart card reader with an acceptable test result stored on a smart card.

15. The smart card of claim 14, wherein the attestation verifier unit comprises a digest decrypter unit to decrypt an encrypted digest.

16. A method for managing a smart card system, comprising:

testing a smart card reader for trustworthiness; and

17. The method of claim 16, wherein providing an indication comprises turning on a light.

18. The method of claim 16, wherein providing an indication comprises generating an audible sound.

19. The method of claim 16, wherein providing an indication comprises producing a vibration.

20. The method of claim 16, wherein providing an indication comprises changing a temperature of the smart card.