AUTHENTICATION WITH DEVICE ATTESTATION

BACKGROUND

Claim to Priority

[0001] This application claims the benefit of co-pending U.S. Provisional Patent Application No. 61/829,081 , filed May 30, 2013, entitled, "Combining Biometric

Authentication With Device Attestation" which is assigned to the assignee of the present nonprovisional application and is hereby incorporated by reference.

Field of the Invention

[0002] This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for biometric authentication with device attestation.

Description of Related Art

[0003] Existing systems have been designed for providing secure user

authentication over a network using biometric sensors. For example, Patent Application No. 201 1 /0082801 ('"801 Application") describes a framework for user registration and authentication on a network which provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against

"malware in the browser" and "man in the middle" attacks for transactions), and enrollment/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smartcards, trusted platform modules, etc).

[0004] Biometric sensors have been used for local computer authentication for years in commercial off-the-shelf computer systems such as Lenovo® Thinkpads® and HP® Elite Books®. Biometric sensors integrated into these computer systems typically can rely on the integrity of the computer system as convenience as opposed to attack resistance is their primary goal. Additionally commercial computer systems typically aren't robust against physical tampering at all. So adding physical protection for the fingerprint sensor alone hasn't been a priority.

[0005] While biometric devices have been used for remote authentication to certain applications, strict organizational methods have been required to protect the integrity of biometric systems. For example, these biometric systems are typically sealed and their interface to computer systems is accessible only to authorized and trusted personnel (e.g., a trusted individual or group which ensures that a known acceptable biometric device is used and is not tampered with). [0006] With the increased adoption of cloud services, a new use case for biometric authentication has evolved, i.e., biometric-based authentication to cloud services. In this case, at least the biometric sensor may be attached to an unsupervised machine. This unsupervised case has two important consequences:

a) The biometric device should have integrated anti-spoofing methods (i.e.

detection of fake biometrics) as there is no supervisor checking the system is not being spoofed; and

b) The machine's and the biometric device's integrity cannot be assumed to be

protected by external methods and hence need their own shielding mechanisms.

[0007] The need for (a) is well identified and addressed by the research community (Murali Mohan Chakka, 201 1 ) (Marcialis, 2009) (Umut Uludag, Anil K. Jain; Department of Computer Science and Engineering, Michigan State University). However,

techniques for (b) have yet to be fully developed. In particular, there are currently no standardized techniques for an Application to determine whether it is communicating with a real biometric device or with a piece of malware. Additionally, no acceptable techniques exist for a remote relying party such as a cloud service to determine whether a request to access the service is being sent by a trusted Application or by malware.

[0008] Figure 1 illustrates an exemplary client 120 with a biometric device 100.

When operated normally, a biometric sensor 102 reads raw biometric data from the user (e.g., capture the user's fingerprint, record the user's voice, snap a photo of the user, etc) and a feature extraction module 103 extracts specified characteristics of the raw biometric data (e.g., focusing on certain regions of the fingerprint, certain facial features, etc). A matcher module 104 compares the extracted features 133 with biometric reference data 1 10 stored in a secure storage on the client 120 and generates a score 153 based on the similarity between the extracted features and the biometric reference data 1 10. The biometric reference data 1 10 is typically the result of an enrollment process in which the user enrolls a fingerprint, voice sample, image or other biometric data with the device 100. An application 105 may then use the score 135 to determine whether the authentication was successful (e.g., if the score is above a certain specified threshold) .

[0009] An attacker may target various locations 130-136 within the biometric pipeline. At 130, for example, the attacker may submit fake biometric data to the biometric sensor 102 (e.g., submitting a recording of the user's voice or a photo of the user's fingerprint). At 131 , the attacker may re-submit an old signal containing previously-captured features to the feature extraction module 103 or, at 132, may override the feature extraction function entirely. At 133, the attacker may tamper with feature representation provided to the matcher 104 or, at 134, may override the matching function. At 136, the attacker may provide forged biometric reference data to the matcher 104 or, at 135, may provide a forged score to the application 105. Thus, as illustrated in Figure 1 , there are numerous locations within the biometric pipeline which may be susceptible to targeting by an attacker.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

[0011] FIG. 1 illustrates an exemplary client equipped with a biometric device.

[0012] FIG. 2 illustrates one embodiment of a system architecture for biometric authentication with device attestation.

[0013] FIG. 3A-C illustrate transaction diagrams showing exemplary transactions between a relying party and a cryptographic engine on a biometric device.

[0014] FIGS. 4A-B illustrate two different embodiments of a secure authentication system architecture.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0015] Described below are embodiments of an apparatus, method, and machine- readable medium for implementing an authentication framework with device attestation in a client-server environment. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown or are shown in a block diagram form to avoid obscuring the underlying principles of the present invention.

[0016] The embodiments of the invention discussed below involve client devices with authentication capabilities such as biometric devices or PIN entry. These devices are sometimes referred to herein as "tokens," "authentication devices," or "authenticators." Various different biometric devices may be used including, but not limited to, fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning the retina of a user). The authentication capabilities may also include non-biometric devices such as trusted platform modules (TPMs) and smartcards.

[0017] As mentioned above, in a mobile biometric implementation, the biometric device may be remote from the relying party. As used herein, the term "remote" means that the biometric sensor is not part of the security boundary of the computer it is communicatively coupled to (e.g., it is not embedded into the same physical enclosure as the relying party computer). By way of example, the biometric device may be coupled to the relying party via a network (e.g., the Internet, a wireless network link, etc) or via a peripheral input such as a USB port. Under these conditions, there may be no way for the relying party to know if the device is one which is authorized by the relying party (e.g., one which provides an acceptable level of authentication and integrity protection) and/or whether a hacker has compromised the biometric device.

Confidence in the biometric device depends on the particular implementation of the device.

[0018] One embodiment of the invention employs cryptographic attestation to ensure to the relying party that the correct biometric device is being used. The biometric device may enter into a cryptographic attestation transaction with the relying party to verify the type of sensor it has. In particular, a cryptographic engine with a secure attestation key storage is included with the biometric device to provide for secure attestation to the relying parties.

[0019] Figure 2 illustrates one embodiment of the invention which includes a cryptographic engine 205 for attesting to the model and/or the integrity of an

Authenticator 200. In particular, as discussed in detail below, the cryptographic engine 205 performs an attestation transaction with a relying party 207 to prove the integrity of the Authenticator 200. In this embodiment, the relying party 207 will trust the score generated by the matcher 204 only if it is also able to verify the proof of integrity of the Authenticator 200. As indicated in Figure 2, in one embodiment, the relying party 207 may be a cloud service. However, the underlying principles of the invention are not limited to any particular type of relying party.

[0020] In operation, the cryptographic engine 205 is provided with access to a secure key storage 21 1 for storing an attestation key used during the attestation transaction. For example, the key may be a private key stored in the Authenticator 200 at manufacture time and the relying party 207 may store a corresponding public key. However, the underlying principles of the invention are not limited to any particular asymmetric or symmetric key implementation.

[0021] In one embodiment, the biometric device includes additional protection logic that protects the attestation key. In response to detecting attempt to tamper with the key, the protection logic automatically erases the key. In one embodiment, secure key storage 21 1 may be the same secure storage as that used to store the biometric reference data 210, although the underlying principles of the invention are not limited to this implementation.

[0022] Figure 3a illustrates a series of attestation transactions employed in one embodiment of the invention. The relying party 207 generates a challenge in

transaction 300 and sends it to the application 206 in transaction 301 , which forwards it to the cryptographic engine 205 in transaction 302. In one embodiment, the challenge is a random number or nonce selected by the relying party 207. In operation 303, the cryptographic engine 205 generates a signature over the challenge and the score using the attestation key. As is understood by those of skill in the art, generating a signature may involve implementing a hash function over the challenge using the attestation key.

[0023] The matcher 204 generates a score in operation 304 and provides the score together with the User-ID to the cryptographic engine 205 in operation 305. Generating the score may be performed as previously described. For example, the biometric sensor 202 may read raw biometric data from the user (e.g., capture the user's fingerprint, record the user's voice, snap a photo of the user, etc) and a feature extraction module 203 may extract specified characteristics of the raw biometric data (e.g., focusing on certain regions of the fingerprint, certain facial features, etc). The matcher module 204 compares the extracted features with biometric reference data 210 stored in a secure storage on the client 220 and generates a score based on the similarity between the extracted features and the biometric reference data 210. As previously described, the biometric reference data 210 may be the result of an enrollment process in which the user enrolls a fingerprint, voice sample, image or other biometric data with the Authenticator 200. The application 206 or relying party 207 may subsequently use the score to determine whether the authentication was successful (e.g., if the score is above a certain threshold needed for the particular transaction).

[0024] In operation 306, the cryptographic engine 205 sends the combined signature, User ID, and score to the application 206 which it forwards to the relying party 207 in operation 307. The relying party 207 now knows the challenge (e.g., a nonce or random number which it previously generated) and the signature provided by the cryptographic engine 205. In operation 308, it uses its own key to verify the signature using the random number, thereby verifying the attestation key owned by the cryptographic engine. As mentioned, in one embodiment, the key used by the relying party is a public key for verifying the signature generated on the challenge using the private key. Alternatively, the cryptographic engine and relying party may use the same key (i.e., a symmetric key pair may be used). The underlying principles of the invention are not limited to any particular public/private key implementation. The cryptographic engine simply needs to be capable of generating a signature over the challenge which may be verified by the relying party.

[0025] If each biometric device is assigned its own unique attestation key, the key may be used as a global correlation handle for uniquely identifying the user. This creates a privacy problem in some regions of the world. By way of example, the CPUID instruction introduced by Intel® in 1993 could be used to retrieve a CPU's serial number. This feature was subsequently removed in response to privacy concerns.

[0026] To address privacy concerns, in one embodiment, the same attestation key may be used for multiple biometric devices. For example, all fingerprint sensors of a certain type (e.g., using a certain type of sensor, or being produced in one batch) may use the same shared attestation key. For example, the shared attestation key may identify a particular biometric device as having a sensor of "type X." Thus, with a shared attestation key, an individual user/device cannot be uniquely identified, thereby preserving each user's privacy.

[0027] One disadvantage of this configuration is that if the key is extracted by a potential hacker, the attestation process will be compromised. For this reason, the trusted computing group ("TCG") developed direct anonymous attestation (DAA), a cryptographic protocol which enables remote authentication of a trusted platform while preserving the user's privacy. In one embodiment, DAA is implemented between the relying party 207 and cryptographic engine 205 to attest to the integrity of the

Authenticator 200. In particular, the cryptographic engine 205 may comprise a trusted platform module (TPM) and perform attestation and authentication with the relying party 207 as described, for example, in Ernie Brickell et al, Direct Anonymous Attestation (Feb 1 1 , 2004) or Liqun Chen et al, Flexible and Scalable Digital Signatures in TPM 2.0 (2013).

[0028] Using Direct Anonymous Attestation in one embodiment, the Cryptographic Engine 205 can be prepared in two alternative ways before the attestation shown in Figure 3a can be executed. [0029] In the embodiment illustrated in Figure 3b, the DAA Issuer 370 is remote to the production line 371 . At the production time of the Authenticator, in operation 351 , the endorsement key pair is generated inside the cryptographic engine 205.

Alternatively, in one embodiment, it may be injected together with the endorsement key certificate by the production line 371 . This key is unique to the Authenticator. This doesn't present a privacy issue as the key is used one single time and only in conjunction with one relying party, the DAA-lssuer. In operation 352, the endorsement public key is extracted and in operation 353, a unique endorsement key certificate is created. In operation 354, the unique endorsement key certificate is injected into the cryptographic engine 205.

[0030] In one embodiment, the endorsement certificate is used once, i.e. in conjunction with the DAA-lssuer 370 in order to authenticate itself for the DAA-Join operation, performed at 356. During the DAA-Join operation, a DAA key pair is generated and a DAA "certificate" is sent from the DAA-lssuer to the cryptographic engine.

[0031] In the embodiment illustrated in Figure 3c, the DAA Issuer 380 is directly coupled to the production line. In this embodiment, the DAA-Join operation 375 can be performed by the DAA-lssuer (as part of the production line). No additional

endorsement key and certificate is required in this embodiment.

[0032] Regardless of which embodiment is implemented using DAA, the

cryptographic engine 205 will use the DAA-Sign operation instead of the normal signature in step 303 of Figure 3a.

EXEMPLARY SYSTEM ARCHITECTURES

[0033] Figures 4A-B illustrate two embodiments of a system architecture comprising client-side and server-side components for authenticating a user. The embodiment shown in Figure 4A uses a browser plugin-based architecture for communicating with a website while the embodiment shown in Figure 4B does not require a browser. The various techniques described herein for biometric authentication with device attestation using a cryptographic engine may be implemented on either of these system

architectures. For example, an authentication device 410-412 and its associated interface 402 shown in Figures 4A-B may include the biometric sensor 202, feature extraction module 203, matcher 204, and cryptographic engine 205 shown in Figure 2. The biometric reference data 210 illustrated in Figure 2 may be implemented with the secure storage 420 shown in Figures 4A-B. While the secure storage 420 is illustrated outside of the secure perimeter of the authentication device(s) 410-412, in one embodiment, each authentication device 410-412 may have its own integrated secure storage. Alternatively, each authentication device 410-412 may cryptographically protect the biometric reference data records (e.g., wrapping them using a symmetric key to make the storage 420 secure).

[0034] The application 206 illustrated in Figure 2 may be the application 454 and/or secure transaction service 401 shown in Figure 4B. In a browser implementation, the application 206 may be the browser 404/secure transaction plugin 405 and/or the secure transaction service 401 shown in Figure 4A. The relying party 207 may be the secure enterprise or web destination 430 shown in Figures 4A-B. It should be noted, however, that the embodiment illustrated in Figure 2 stands on its own and may be implemented using logical arrangements of hardware and software other than those shown in Figures 4A-B.

[0035] Turning first to Figure 4A, the illustrated embodiment includes a client 400 equipped with one or more authentication devices 410-412 for enrolling and

authenticating an end user. As mentioned above, the authentication devices 410-412 may include biometric devices such as fingerprint sensors, voice recognition

hardware/software (e.g., a microphone and associated software for recognizing a user's voice), facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning the retina of a user) and non-biometric devices such as a trusted platform modules (TPMs) and smartcards.

[0036] The authentication devices 410-412 are communicatively coupled to the client through an interface 402 (e.g., an application programming interface or API) exposed by a secure transaction service 401 . The secure transaction service 401 is a secure application for communicating with one or more secure transaction servers 432-433 over a network and for interfacing with a secure transaction plugin 405 executed within the context of a web browser 404. As illustrated, the Interface 402 may also provide secure access to a secure storage device 420 on the client 400 which stores

information related to each of the authentication devices 410-412 such as a device identification code, user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored into each of the authentication devices and used when communicating to servers 430 over a network such as the Internet. [0037] As discussed below, certain types of network transactions are supported by the secure transaction plugin 405 such as HTTP or HTTPS transactions with websites 431 or other servers. In one embodiment, the secure transaction plugin is initiated in response to specific HTML tags inserted into the HTML code of a web page by the web server 431 within the secure enterprise or Web destination 430 (sometimes simply referred to below as "server 430"). In response to detecting such a tag, the secure transaction plugin 405 may forward transactions to the secure transaction service 401 for processing. In addition, for certain types of transactions (e.g., such as secure key exchange) the secure transaction service 401 may open a direct communication channel with the on-premises transaction server 432 (i.e., co-located with the website) or with an off-premises transaction server 433.

[0038] The secure transaction servers 432-433 are coupled to a secure transaction database 440 for storing user data, authentication device data, keys and other secure information needed to support the secure authentication transactions described below. It should be noted, however, that the underlying principles of the invention do not require the separation of logical components within the secure enterprise or web destination 430 shown in Figure 4A. For example, the website 431 and the secure transaction servers 432-433 may be implemented within a single physical server or separate physical servers. Moreover, the website 431 and transaction servers 432-433 may be implemented within an integrated software module executed on one or more servers for performing the functions described below.

[0039] As mentioned above, the underlying principles of the invention are not limited to a browser-based architecture shown in Figure 4A. Figure 4B illustrates an alternate implementation in which a stand-alone application 454 utilizes the functionality provided by the secure transaction service 401 to authenticate a user over a network. In one embodiment, the application 454 is designed to establish communication sessions with one or more network services 451 which rely on the secure transaction servers 432-433 for performing the user/client authentication techniques described in detail below.

[0040] In either of the embodiments shown in Figures 4A-B, the secure transaction servers 432-433 may generate the keys which are then securely transmitted to the secure transaction service 401 and stored into the authentication devices within the secure storage 420. Additionally, the secure transaction servers 432-433 manage the secure transaction database 420 on the server side.

[0041] Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general- purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

[0042] Elements of the present invention may also be provided as a machine- readable medium for storing the machine-executable program code. The machine- readable medium may include, but is not limited to, floppy diskettes, optical disks, CD- ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic program code.

[0043] Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, it will be readily apparent to those of skill in the art that the functional modules and methods described herein may be implemented as software, hardware or any combination thereof.

Moreover, although some embodiments of the invention are described herein within the context of a mobile computing environment, the underlying principles of the invention are not limited to a mobile computing implementation. Virtually any type of client or peer data processing devices may be used in some embodiments including, for example, desktop or workstation computers. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.