HK1220021B - System and method for biometric authentication with device attestation - Google Patents

Description

Systems and methods for biometric authentication using device verification

Claims for priority

This application claims the benefit of co-pending U.S. Provisional Patent Application No. 61/829,081, entitled “Combining Biometric Authentication With Device Attestation,” filed May 30, 2013, which is assigned to the assignee of this non-provisional patent application and is hereby incorporated by reference.

Technical Field

The present invention relates generally to the field of data processing systems. More particularly, the present invention relates to systems and methods for biometric authentication using device verification.

Background Art

Existing systems have been designed to provide secure user authentication over a network using biometric sensors. For example, Patent Application No. 2011/0082801 (“the '801 Application”) describes a framework for user registration and authentication over a network that provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “in-browser malware” and “man-in-the-middle” attacks during transactions), and registration/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

Biometric sensors have been used for years for local computer authentication in commercial off-the-shelf computer systems, such as the Intel Core i7-9000 and Intel Core i7-9000 Elite. Biometric sensors integrated into these systems often rely on the integrity of the computer system, as convenience (not attack resistance) is their primary goal. Furthermore, commercial computer systems are often not robust enough to resist physical tampering. Therefore, adding physical protection to fingerprint sensors alone has not been a priority.

Because biometric devices are already used for remote authentication of certain applications, a rigorous organizational approach is required to protect the integrity of biometric systems. For example, these biometric systems are typically closed, and their interfaces to computer systems are accessible only to authorized and trusted personnel (e.g., individuals or groups who are trusted to ensure that known acceptable biometric devices are used and that the devices have not been tampered with).

With the increasing adoption of cloud services, a new use case for biometric authentication has emerged: biometric-based authentication for cloud services. In this scenario, at least one biometric sensor can be attached to an unsupervised machine. This unsupervised approach has two consequences:

a) Biometric devices should have integrated anti-spoofing methods (i.e. detection of fake biometrics) as there is no supervisory party to check whether the system is being spoofed; and

b) The integrity of machines and biometric devices cannot be assumed to be protected by external means and therefore require their own shielding mechanisms.

The need for (a) has been well-identified and addressed by the research community (Murali Mohan Chakka, 2011) (Marcialis, 2009) (Umut Uludag, Anil K. Jain; Department of Computer Science and Engineering, Michigan State University). However, the technology for (b) has not yet been fully developed. In particular, there is currently no standardized technique for an application to determine whether it is communicating with an authentic biometric device or malware. Furthermore, there is currently no acceptable technique 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 malware.

FIG1 illustrates an exemplary client 120 having a biometric device 100. During normal operation, the biometric sensor 102 reads raw biometric data from the user (e.g., captures the user's fingerprint, records the user's voice, takes a photo of the user, etc.), and the feature extraction module 103 extracts specified features from the raw biometric data (e.g., focusing on certain areas of the fingerprint, certain facial features, etc.). The matcher module 104 compares the extracted features 133 with biometric reference data 110 stored in secure storage on the client 120 and generates a score 153 based on the similarity between the extracted features and the biometric reference data 110. The biometric reference data 110 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. The application 105 can then use the score 135 to determine whether authentication was successful (e.g., whether the score is above a specified threshold).

An attacker can target various locations within the biometric pipeline, 130 through 136. For example, at 130, an attacker can submit false biometric data to the biometric sensor 102 (e.g., a recording of the user's voice or a photo of the user's fingerprint). At 131, an attacker can resubmit an old signal containing previously captured features to the feature extraction module 103, or at 132, the attacker can completely override the feature extraction functionality. At 133, an attacker can tamper with the feature representation provided to the matcher 104, or at 134, the attacker can override the matching functionality. At 136, an attacker can provide forged biometric reference data to the matcher 104, or at 135, a forged score to the application 105. Thus, as shown in FIG1 , there are many locations within the biometric pipeline that are easily targeted by attackers.

Summary of the Invention

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood from the following detailed description in conjunction with the following drawings, in which:

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

FIG2 illustrates one embodiment of a system architecture for biometric authentication using device verification.

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

4A-B illustrate two different embodiments of a secure authentication system architecture.

DETAILED DESCRIPTION

The following describes an apparatus, method, and machine-readable medium for implementing an authentication framework using device authentication in a client-server environment. Throughout the description, for purposes of explanation, numerous specific details are set forth herein to provide a thorough understanding of the present invention. However, those skilled in the art will readily appreciate that the present invention may be practiced without some of these specific details. In other cases, to avoid obscuring the underlying principles of the present invention, well-known structures and devices are not shown or are shown in block diagram form.

The embodiments of the present invention discussed below relate to 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." A variety of different biometric devices can 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 a user's retina). Authentication capabilities may also include non-biometric devices, such as Trusted Platform Modules (TPMs) and smart cards.

As described above, in specific implementations of mobile biometrics, 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 perimeter of the computer to which it is communicatively coupled (e.g., the biometric sensor is not embedded in the same physical housing as the relying party's computer). For 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, the relying party may not be able to know whether the device is an authorized device by the relying party (e.g., a device that provides an acceptable level of authentication and integrity protection) and/or whether a hacker has compromised the biometric device. The confidence level of the biometric device depends on the specific implementation of the device.

One embodiment of the present invention uses cryptographic authentication to ensure a relying party that the correct biometric device is being used. The biometric device can enter into a cryptographic authentication transaction, during which the relying party verifies the type of sensor the biometric device possesses. Specifically, a cryptographic engine with secure authentication key storage is included in the biometric device to provide secure authentication to the relying party.

FIG2 illustrates one embodiment of the present invention, which includes a cryptographic engine 205 for verifying the model and/or integrity of a validator 200. Specifically, as discussed in detail below, cryptographic engine 205 performs a verification transaction with a relying party 207, thereby verifying the integrity of the validator 200. In this embodiment, relying party 207 trusts the score generated by matchmaker 204 only if it can also verify the evidence of the integrity of the validator 200. As shown in FIG2 , in one embodiment, relying party 207 may be a cloud service. However, the underlying principles of the present invention are not limited to any particular type of relying party.

In operation, the cryptographic engine 205 has access to a secure key storage 211, which is used to store the authentication key used during authentication transactions. For example, the key may be a private key stored in the authenticator 200 at production time, and the relying party 207 may store the corresponding public key. However, the underlying principles of the present invention are not limited to any particular asymmetric or symmetric key implementation.

In one embodiment, the biometric device includes additional protection logic to protect the authentication key. In response to detecting an attempt to tamper with the key, the protection logic automatically erases the key. In one embodiment, secure key storage 211 may be the same secure storage used to store biometric reference data 210, although the underlying principles of the invention are not limited to this specific implementation.

Figure 3a illustrates a series of authentication transactions employed in one embodiment of the present invention. In transaction 300, relying party 207 generates a challenge and sends the challenge to application 206 in transaction 301. In transaction 302, application 206 forwards the challenge to cryptographic engine 205. In one embodiment, the challenge is a random number or nonce selected by relying party 207. In operation 303, cryptographic engine 205 generates a signature for the challenge and generates a score using the authentication key. As will be appreciated by those skilled in the art, generating the signature may involve applying a hash function to the challenge using the authentication key.

In operation 304, the matcher 204 generates a score and, in operation 305, provides the score along with the user ID to the encryption engine 205. The score can be generated as previously described. For example, the biometric sensor 202 can read raw biometric data from the user (e.g., capture the user's fingerprint, record the user's voice, take a photo of the user, etc.), and the feature extraction module 203 can extract specified features from the raw biometric data (e.g., focusing on certain areas of the fingerprint, certain facial features, etc.). The matcher module 204 compares the extracted features with the biometric reference data 210 stored in the secure storage device 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 can 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 can then use the score to determine whether the authentication was successful (e.g., whether the score is above a certain threshold required for a specific transaction).

In operation 306, the encryption engine 205 sends the combined signature, user ID, and score to the application 206, which forwards these to the relying party 207 in operation 307. The relying party 207 now knows the challenge (e.g., the random number or nonce previously generated by the relying party) and the signature provided by the encryption engine 205. In operation 308, the relying party uses its own key to verify the signature using the nonce, thereby verifying the certification key possessed by the encryption engine. As described above, in one embodiment, the key used by the relying party is a public key, which is used to verify the signature generated using the private key to the challenge. Alternatively, the encryption engine and the relying party can use the same key (i.e., a symmetric key pair can be used). The basic principles of the present invention are not limited to any particular public/private key implementation. The encryption engine only needs to be able to generate a signature that can be verified by the relying party to the challenge.

If each biometric device is assigned its own unique authentication key, this key can be used as a global association handle to uniquely identify a user. This can cause privacy issues in some parts of the world. For example, the CPUID instruction, introduced in 1993, could be used to retrieve the CPU serial number. Due to privacy concerns, this feature was later removed.

To address privacy concerns, in one embodiment, the same authentication key can be used across multiple biometric devices. For example, all fingerprint sensors of a certain type (e.g., using a certain sensor type or manufactured in the same batch) can use a single shared authentication key. For example, this shared key can identify a specific biometric device with a "Type X" sensor. Therefore, when using a shared authentication key, individual users/devices cannot be uniquely identified, thereby protecting each user's privacy.

One disadvantage of this configuration is that if a potential hacker extracts the key, the authentication process will be compromised. To this end, the Trusted Computing Group ("TCG") has developed Direct Anonymous Attestation (DAA), a cryptographic protocol that enables remote authentication of trusted platforms while protecting user privacy. In one embodiment, DAA is implemented between the relying party 207 and the encryption engine 205 to verify the integrity of the authenticator 200. Specifically, the encryption engine 205 may include a trusted platform module (TPM) and perform authentication and verification with the relying party 207, as described in, for example, "Direct Anonymous Attestation" by Ernie Brickell et al. (February 11, 2004) or "Flexible and Scalable Digital Signatures in TPM 2.0" by Liqun Chen et al. (2013).

In one embodiment, using direct anonymous authentication, the encryption engine 205 may be prepared in two alternative ways and then perform the authentication shown in FIG. 3a.

In the embodiment shown in Figure 3b, the DAA issuer 370 is remote from the production line 371. When the validator is produced, in operation 351, an endorsement key pair is generated within the encryption engine 205. Alternatively, in one embodiment, the endorsement key pair can be injected by the production line 371 along with the endorsement key certificate. The key is unique to the validator. This does not cause privacy issues because the key is only used once and is only bound to one relying party, namely the DAA issuer. 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 encryption engine 205.

In one embodiment, the endorsement certificate is used once, namely in conjunction with the DAA issuer 370 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 issuer to the cryptographic engine.

In the embodiment shown in Figure 3c, the DAA issuer 380 is directly coupled to the production line. In this embodiment, the DAA issuer (as part of the production line) can perform the "DAA-join" operation 375. No additional endorsement keys and certificates are required in this embodiment.

Regardless of which embodiment is implemented using DAA, the cryptographic engine 205 will use a "DAA-sign" operation instead of the conventional signing in step 303 of FIG. 3a.

Exemplary system architecture

Figures 4A to B illustrate two embodiments of a system architecture including client-side components and server-side components for verifying a user. The embodiment shown in Figure 4A uses a browser plug-in-based architecture to communicate with a website, while the embodiment shown in Figure 4B does not require a browser. The various techniques described herein for using an encryption engine to perform biometric verification through device verification can be implemented on any of these system architectures. For example, the verification devices 410 to 412 and their associated interfaces 402 shown in Figures 4A to B may include the biometric sensor 202, feature extraction module 203, matcher 204, and encryption engine 205 shown in Figure 2. The biometric reference data 210 shown in Figure 2 can be implemented together with the secure storage device 420 shown in Figures 4A to B. Although the secure storage device 420 is shown as being outside the secure perimeter of the verification devices 410 to 412, in one embodiment, each verification device 410 to 412 may have its own integrated secure storage device. Alternatively, each verification device 410 to 412 can password-protect biometric reference data records (e.g., using a symmetric key to wrap these data records to make the storage device 420 secure).

Application 206 shown in FIG2 may be application 454 and/or secure transaction service 401 shown in FIG4B. In a browser implementation, application 206 may be browser 404/secure transaction plug-in 405 and/or secure transaction service 401 shown in FIG4A. Relying party 207 may be secure enterprise or web destination 430 shown in FIG4A-B. However, it should be noted that the embodiment shown in FIG2 is self-contained and may be implemented using logical arrangements of hardware and software other than those shown in FIG4A-B.

Turning first to Figure 4A, the illustrated embodiment includes a client 400 equipped with one or more authentication devices 410 to 412 for enrolling and authenticating an end user. As described above, the authentication devices 410 to 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 a user's retina); as well as non-biometric devices such as a Trusted Platform Module (TPM) and a smart card.

Authentication devices 410 to 412 are communicatively coupled to the client via 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 to 433 via a network and for interfacing with a secure transaction plug-in 405 executed within the environment of a web browser 404. As shown, the interface 402 may also provide secure access to a secure storage device 420 on the client 400, which stores information related to each authentication device 410 to 412, such as a device identification code, a user identification code, user registration data (e.g., a scanned fingerprint or other biometric data), and keys for performing the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored in each authentication device and used when communicating with the server 430 via a network (such as the Internet).

As discussed below, secure transaction plugin 405 supports certain types of network transactions, such as HTTP or HTTPS transactions with a website 431 or other server. In one embodiment, the secure transaction plugin is activated in response to a specific HTML tag inserted into the HTML code of a web page by a network server 431 (sometimes referred to hereinafter as "server 430") within a secure enterprise or web destination 430. In response to detecting such a tag, secure transaction plugin 405 may forward the transaction to secure transaction service 401 for processing. In addition, for certain types of transactions (e.g., such as secure key exchange), secure transaction service 401 may open a direct communication channel with a local transaction server 432 (i.e., co-located with the website) or an off-site transaction server 433.

Secure transaction servers 432-433 are coupled to a secure transaction database 440 to store user data, authentication device data, cryptographic keys, and other security information required to support secure authentication transactions as described below. However, it should be noted that the underlying principles of the present invention do not require the separation of logical components within the secure enterprise or web destination 430 shown in FIG4A. For example, website 431 and secure transaction servers 432-433 may be implemented within a single physical server or separate physical servers. Furthermore, website 431 and transaction servers 432-433 may be implemented within integrated software modules executed on one or more servers to perform the functions described below.

As mentioned above, the underlying principles of the present invention are not limited to the browser-based architecture shown in FIG4A . FIG4B illustrates an alternative implementation in which a standalone application 454 utilizes functionality provided by secure transaction service 401 to authenticate users via the network. In one embodiment, application 454 is designed to establish a communication session with one or more network services 451, which rely on secure transaction servers 432-433 to perform the user/client authentication techniques described in detail below.

4A-4B , the secure transaction servers 432-433 may generate keys that are then securely transmitted to the secure transaction service 401 and stored in a verification device within the secure storage 420. Additionally, the secure transaction servers 432-433 manage the secure transaction database 420 on the server side.

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

Element of the present invention can also be provided as machine-readable medium for storing machine executable program code.Machine-readable medium can include but is not limited to floppy disk, optical disk, CD-ROM and magneto-optical disk, ROM, RAM, EPROM, EEPROM, magnetic card or optical card or other types of medium/machine-readable medium that are suitable for storing electronic program code.

Throughout the foregoing description, for the purpose of explanation, many specific details have been set forth in order to provide a thorough understanding of the present invention. However, it will be readily apparent to those skilled in the art that the present invention may be practiced without some of these specific details. For example, it will be readily apparent to those skilled in the art that the functional modules and methods described herein may be implemented as software, hardware, or any combination thereof. Furthermore, although some embodiments of the present invention are described herein in the context of a mobile computing environment, the underlying principles of the present invention are not limited to mobile computing implementations. In some embodiments, virtually any type of client or peer data processing device may be used, including, for example, a desktop computer or a workstation computer. Therefore, the scope and spirit of the present invention should be determined based on the appended claims.

Claims (21)

1. An apparatus for remotely verifying the integrity of a verifier, the apparatus comprising: A validator that reads biometric validation data from a user and determines whether the user has been successfully validated based on a comparison with biometric reference data, generating a score from the comparison; and The encryption engine performs the following operations: Receive a challenge from the dependent party, the challenge including a randomly generated random number. The challenge and the score are signed using a verification key to generate a verification signature, wherein the verification key is established using a production line, specifically for the dependent party, after the signature key certificate is generated. The production line extracts a public signature key from the signature key pair to generate the signature key certificate and returns the signature key certificate to the encryption engine, wherein the signature key certificate corresponds to the verification key, and The user identifier ID, the score, and the verification signature are sent to the dependent party, wherein the dependent party uses a key corresponding to the signature key certificate to verify that the verification signature is valid, and wherein the score is used to determine whether the user's verification was successful. 2. The device according to claim 1, wherein the encryption engine is integrated within the verifier. 3. The device of claim 1, wherein the verification key is a private key, and the key of the dependent party is a public key associated with the private key. 4. The device of claim 1, wherein verifying the integrity of the verifier comprises implementing a series of Direct Anonymous Verification (DAA) transactions between the cryptographic engine and the dependent party. 5. The device of claim 4, wherein the DAA transaction includes a "DAA-sign" transaction and a "DAA-verify" transaction. 6. The device according to claim 1, further comprising: The protection logic erases the encrypted data when it detects that the encrypted data of the encryption engine has been tampered with. 7. The device of claim 1, wherein the verifier comprises: A biometric sensor that reads the biometric verification data from the user; A feature extraction module that extracts a specified portion of the biometric verification data that has certain features; A matcher compares a specified portion of the biometric validation data with biometric reference data and generates a score based on the comparison, the score indicating the degree of similarity between the specified portion of the biometric validation data and the biometric reference data. 8. A method for remotely verifying the integrity of a verifier, the method comprising: The process involves reading biometric validation data from a user and determining whether the user has been successfully validated based on a comparison with biometric reference data, wherein the reading and determination operations are performed by a validator, and generating a score from the comparison, wherein the reading and determination operations are performed by the validator; and Protecting communication with dependents; and Execute a confirmation transaction with the dependent party to confirm the integrity of the validator to the dependent party, the confirmation including: Receive a challenge from the dependent party, the challenge including a randomly generated random number. The challenge and the score are signed using a verification key to generate a verification signature, wherein the verification key is established using a production line, specifically for the dependent party, after the signature key certificate is generated. The production line extracts a public signature key from the signature key pair to generate and return the signature key certificate for signing the challenge and the score, and the signature key certificate corresponds to the verification key. The user identifier ID, the score, and the verification signature are sent to the dependent party, wherein the dependent party uses a key corresponding to the signature key certificate to verify that the verification signature is valid, and wherein the score is used to determine whether the user's verification was successful. 9. The method of claim 8, wherein the cryptographic engine executing the verification transaction is integrated within a validator, the validator reading the biometric verification data from the user and determining whether the user has been successfully verified based on a comparison with the biometric reference data. 10. The method of claim 8, wherein the verification key is a private key, and the key of the dependent party is a public key associated with the private key. 11. The method of claim 8, wherein verifying the integrity of the verifier comprises implementing a series of Direct Anonymous Verification (DAA) transactions between the cryptographic engine and the dependent party. 12. The method of claim 11, wherein the DAA transaction includes a “DAA-signing” transaction and a “DAA-verification” transaction. 13. The method of claim 8, further comprising: The encrypted data is erased when it is detected that the encrypted data has been tampered with. 14. The method of claim 8, wherein determining whether the user has been successfully verified further comprises: Read the biometric verification data from the user; Extract a specified portion of the biometric validation data that has certain characteristics; The specified portion of the biometric validation data is compared with biometric reference data, and a score is generated responsively based on the comparison, the score indicating the degree of similarity between the specified portion of the biometric validation data and the biometric reference data. 15. A machine-readable medium storing program code, which, when executed by a machine, causes the machine to perform the following operations: The system reads biometric validation data from the user and determines whether the user has been successfully validated based on a comparison with biometric reference data, generating a score from the comparison, wherein the reading and determination operations are performed by the validator; and protects communication with dependent parties; and Execute a confirmation transaction with the dependent party to confirm the integrity of the validator to the dependent party, the confirmation including: Receive a challenge from the dependent party, the challenge including a randomly generated random number. The challenge and the score are signed using a verification key to generate a verification signature, wherein the verification key is established using a production line, specifically for the dependent party, after the signature key certificate is generated. The production line extracts a public signature key from the signature key pair to generate and return the signature key certificate for signing the challenge and the score, and the signature key certificate corresponds to the verification key. The user identifier ID, the score, and the verification signature are sent to the dependent party, wherein the dependent party uses a key corresponding to the signature key certificate to verify that the verification signature is valid, and wherein the score is used to determine whether the user's verification was successful. 16. The machine-readable medium of claim 15, wherein the cryptographic engine executing the verification transaction is integrated within a validator, the validator reading the biometric verification data from the user and determining whether the user has been successfully verified based on a comparison with the biometric reference data. 17. The machine-readable medium of claim 15, wherein the verification key is a private key, and the key of the dependent party is a public key associated with the private key. 18. The machine-readable medium of claim 15, wherein verifying the integrity of the verifier comprises implementing a series of Direct Anonymous Verification (DAA) transactions between the cryptographic engine and the dependent party. 19. The machine-readable medium of claim 18, wherein the DAA transaction includes a “DAA-signing” transaction and a “DAA-verifying” transaction. 20. The machine-readable medium of claim 15, further comprising: The encrypted data is erased when it is detected that the encrypted data has been tampered with. 21. The machine-readable medium of claim 15, wherein determining whether the user has been successfully authenticated further comprises: Read the biometric verification data from the user; Extract a specified portion of the biometric validation data that has certain characteristics; The specified portion of the biometric validation data is compared with biometric reference data, and a score is generated responsively based on the comparison, the score indicating the degree of similarity between the specified portion of the biometric validation data and the biometric reference data.