WO2017172314A1

WO2017172314A1 - System and method for breach-resistant centralized biometric authentication

Info

Publication number: WO2017172314A1
Application number: PCT/US2017/021391
Authority: WO
Inventors: Ari Juels
Original assignee: Pcms Holdings, Inc.
Priority date: 2016-03-28
Filing date: 2017-03-08
Publication date: 2017-10-05

Abstract

Disclosed herein are systems and methods for key retrieval. In an embodiment, the method includes receiving a set of multiple presented biometric values. For each presented biometric value, a matching stored biometric value is identified, the matching stored biometric value being mapped to a partial cryptographic key. A cryptographic key is retrieved from at least the partial cryptographic keys. The retrieved cryptographic key is output for use in at least one cryptographic function.

Description

SYSTEM AND METHOD FOR

BREACH-RESISTANT CENTRALIZED BIOMETRIC AUTHENTICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional of, and claims benefit under 35 U.S.C §119(e) from, U.S. Provisional Application No. 62/314,086, filed March 28, 2016 and entitled "System and Method for Breach-Resistant Centralized Biometric Authentication" and to U.S. Provisional Application No. 62/417,938, filed November 4, 2016 and entitled "System and Method for Breach-Resistant Centralized Biometric Authentication."

BACKGROUND

[0002] Authentication is often the starting point for user interaction with various devices, applications, and services. Existing solutions for authentication include, as examples, "something- you-know" factors such as passwords, "something-you-have" factors such as hardware authentication tokens and smartcards, and "something-you-are" factors such as biometrics.

[0003] A challenge with such factors is that they are prone to loss and data corruption. For example, data from a collection of internet of things (IoT) devices (e.g., smart home appliances) may be used to reconstruct a strong cryptographic key with the assistance of a database. But some devices may be lost or malfunction, causing the data for key derivation to be lost. Other devices may be replaced, causing such data, in effect, to be corrupted. Another concern is that that database itself may be breached, resulting in theft of the key. Similar concerns to these apply to biometrics.

[0004] Biometrics are becoming increasingly popular as sensors are incorporated into mobile devices and wirelessly-enabled embedded devices, such as smartwatches. Millions of iOS devices, for example, include TouchID fingerprint sensors. For many purposes, such as credential recovery, it may be convenient to compile central databases of biometric templates (individual biometric profiles). Such databases may be used to authenticate users who have lost or damaged their personal devices, enabling them to register new devices and/or recover data.

[0005] Biometric databases— like other databases of sensitive information— are vulnerable to breach. The consequences can be severely damaging and lifelong. The U.S. Office of Personnel Management, for example recently lost 5.6 million fingerprint templates.

[0006] Apart from standard measures for securing databases, a first technique for addressing the vulnerability of biometric databases is to store biometrics locally, i.e., in personal devices, avoiding the use of biometric databases entirely. iOS devices, for example, store biometric sensors in on-board trusted hardware modules. Local storage of biometric data provides strong confidentiality and avoids the problem of bulk data loss in the case of a server breach; however, it is not implementable in some contexts. For example, it rules out the use of databases for remote authentication or for credential recovery for users who have, e.g., lost or damaged personal devices.

[0007] A second technique is to use existing cryptographic techniques such as fuzzy extraction or cancelable biometrics to store biometric template representations that permit authentication without fully disclosing the templates themselves. Use of techniques such as fuzzy extraction or cancelable biometrics can in principle enable secure use of biometric databases. However, some proposed constructions employing such techniques do not provide rigorous security guarantees. Despite extensive research, they have rarely been applied in practice due to the challenges of formulating rigorous statistical models and distance metrics for biometrics. Similarly, many ad hoc methods have also been proposed and have seen limited commercial adoption, however these techniques lack rigorous security bounds and are therefore frequently compromised. Additionally, many of these methods entail special-purpose matching algorithms that may not provide good false-positive and false-negative rates in practice.

[0008] Another relevant aspect is that existing methods based on or inspired by fuzzy extraction nearly all have the goal of transforming a single biometric value into a key. Only a few existing methods are multimodal or otherwise accommodating of multiple biometric measurements. With the possible exception of iriscodes, existing biometrics provide only a relatively small amount of usable entropy. Thus, even if rigorous and practical fuzzy extraction was possible, use of a single biometric value would not enable the construction of cryptographically strong keys. Consequently, any system relying on these techniques and capable of authenticating a user would be vulnerable to brute-force attack upon compromise.

OVERVIEW

[0009] Described herein are methods and systems for breach-resistant centralized biometric authentication.

[0010] One embodiment takes the form of a method. The method includes receiving a set of multiple presented biometric values. The method also includes identifying, for each presented biometric value, a matching stored biometric value, the matching stored biometric value being mapped to a partial cryptographic key. The method also includes retrieving a cryptographic key from at least the partial cryptographic keys. The method also includes outputting the retrieved cryptographic key for use in at least one cryptographic function.

[0011] In at least one embodiment, identifying, for each biometric value, the matching biometric value comprises comparing the corresponding presented biometric value to at least one of a set of one or more stored biometric values that includes the matching stored biometric value, the matching stored biometric value being the closest match of the set based on the comparison.

[0012] In at least one embodiment, retrieving the cryptographic key comprises constructing the retrieved cryptographic key as a combination of the partial cryptographic keys with a helper value.

[0013] In at least one embodiment, the method further includes using the retrieved cryptographic key in at least one of an authentication attempt or a decryption attempt.

[0014] In at least one embodiment, the method further includes generating a check value of the retrieved cryptographic key and determining if the retrieved cryptographic key is valid based on the check value. In at least one such embodiment, generating the check value of the retrieved cryptographic key comprises using a hash function.

[0015] In at least one embodiment, the method further includes validating the retrieved cryptographic key.

[0016] In at least one embodiment, the method further includes outputting an authorization indication if the retrieved cryptographic key is validated.

[0017] In at least one embodiment, identifying, for each presented biometric value, the matching stored biometric value is based at least in part on a confidence score obtained for the corresponding matching stored biometric value.

[0018] In at least one embodiment, the index associated with the corresponding partial cryptographic key is the corresponding partial cryptographic key.

[0019] In at least one embodiment, the method further including encountering a cryptographic- key-recovery failure, and responsively requesting and receiving one or more re-presented biometric values.

[0020] In at least one embodiment, each matching stored biometric value being mapped to the corresponding partial cryptographic key comprises each matching stored biometric value having an index associated with the corresponding partial cryptographic key. [0021] In at least one embodiment, the index associated with the corresponding partial cryptographic key corresponds to an index at which to retrieve the corresponding partial cryptographic key.

[0022] In at least one embodiment, the method further comprising, based on an indication that the retrieved cryptographic key is not valid, identifying, for at least one presented biometric value of the set of presented biometric values, a different matching stored biometric value, the different matching stored biometric value being mapped to a different partial cryptographic key, retrieving a different cryptographic key from at least the different partial cryptographic key, and outputting the different cryptographic key for use in at least one cryptographic function.

[0023] One embodiment takes the form of an apparatus that includes a key retrieval system, configured to do one or more of the preceding functions.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0025] FIG. 1 A depicts an example communications system in which one or more disclosed embodiments may be implemented.

[0026] FIG. IB depicts an exemplary wireless transmit/receive unit (WTRU) that may be employed as a client device, in some embodiments.

[0027] FIG. 1C illustrates an exemplary network entity that may be employed as a virtual environment model service in some embodiments.

[0028] FIG. 2 depicts an exemplary key retrieval system, in accordance with some embodiments.

[0029] FIG. 3 illustrates a block diagram of an exemplary key retrieval system interacting with a user and a sensor.

[0030] FIG. 4 illustrates a block diagram of an exemplary Biometric-to-Key Conversion (BKC) module interacting with a user and a senor.

[0031] FIG. 5 depicts an exemplary database.

[0032] FIG. 6 depicts a bipartite graph in a chaff approach to construction of a biometric value selector, in accordance with some embodiments.

[0033] FIG. 7 depicts a flowchart of an example method. [0034] FIG. 8 depicts an exemplary database.

[0035] FIG. 9 is a schematic illustrating an exemplary database.

[0036] FIG. 10 depicts an exemplary database.

[0037] FIG. 11 is a schematic illustrating an exemplary architecture.

[0038] FIG. 12 depicts an exemplary architecture of a Key Management Interface (KMI) and a Secret-Share Database (KD).

[0039] FIG. 13 is a flow chart of a method, in accordance with at least one embodiment.

DETAILED DESCRIPTION

[0040] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application. The systems and methods may be used with the wired and wireless communication systems described with respect to FIGS. 1A-1C, which are described at the end of the specification.

[0041] Some embodiments described herein achieve a combination of characteristics unavailable in any other existing or proposed system: secure storage of biometric data in a central database, use of off-the-shelf biometric identification algorithms, support for remote authentication of users, and rigorous security bounds.

[0042] Biometric authentication systems that store templates locally (e.g., iOS devices) do not permit secure storage of biometric data in a central database, and are thus vulnerable to loss or compromise of users' personal devices. For example, a user who loses his/her biometrically- enabled mobile phone can no longer biometrically authenticate to online services. Systems that store a user's templates explicitly in a database are vulnerable to breaches that allow impersonation of the user. Previously proposed schemes that seek to store biometric data on a server in a confidentiality-preserving manner have had notable drawbacks. They have employed the use of special-purpose matching algorithms, resulting in considerable development cost and potentially poor performance and tradeoffs between false positive and false negative rates. Some of these schemes provide rigorous security bounds, but have not been amenable to practical deployment, at least in part, because of a lack of supporting statistical models for biometric data. Others provide only ad hoc or crude empirical security guarantees and thus introduce the risk of compromise due to an algorithmic design flaw. [0043] In contrast, some embodiments described herein offer the combined benefits of off-the- shelf biometric technology with rigorous and conceptually simple security for data stored in a centralized biometric database. In some embodiments, the system converts multiple biometric readings (e.g., fingerprints) from a user U into a strong cryptographic key K. Hereinafter, key is used for cryptographic key, unless context dictates otherwise. In some embodiments, the conversion is done in a robust manner, i.e., periodically and without error, despite the errors and erasures to which biometric readings may be subject to. Furthermore, it also aims at breach- resistance. In some embodiments the system is configured to rigorously quantify an adversary's success in reconstructing a given user's key K (or identifying a user's biometric templates) after compromising the system's stored data.

[0044] Systems described herein may be, for example, suitable for recovery of user credentials or restoration of personal device data. The systems can, for example, help minimize the risk of identity theft by enabling strong authentication of users while alleviating the inconveniences associated with passwords, personal questions, and identity verification through presentation of physical documents (as required for in-store purchases of new devices).

[0045] Consider, for example, a user with a device that permits fingerprint-based authentication using an onboard trusted hardware device (e.g., a smartcard or the trusted hardware in an iPhone). The user may authenticate biometrically both to the device itself and, by means of one or more applications on the device, indirectly to remote services (e.g., medical or financial services). If the user loses the device, the user loses the ability to use that device to authenticate biometrically to remote services. To remotely recover her data and credentials associated with the old device, the user may either use a secondary device (if one is available) or authenticate to an online service by means of a password or another such "something-you-know" authentication method (e.g., answering a personal question online or providing it to a customer service representative). As numerous breaches of online services have demonstrated, such authentication methods are weak. Identity thieves frequently exploit these weaknesses to steal user data, register new devices in their names, and so forth. Additionally, users often forget passwords and answers to personal questions.

[0046] Therefore, it may be convenient to use a centralized biometric database to authenticate such users whenever possible. As noted above, however, existing approaches to managing such databases are too dangerous for widespread use. At least some embodiments described herein create a secure, centralized biometric database. The database would allow a user to recover an authentication credential using a newly obtained purchased device, either in a supervised environment (e.g., a shop or personnel management office) or, with appropriate safeguards, in an unsupervised environment (e.g., at home). The device (e.g., mobile phone) or supporting software (e.g., a smartcard-based authentication system) may prompt the user to scan his/her ten fingers one by one, reconstruct the user's key K through interaction with the server, and allow the user to authenticate his/herself to an online service or decrypt cloud-stored data. The user could thereby restore a backup of his/her old device on a newly obtained one or authenticate his/herself to a service provider to gain access to his/her account. Strong authentication of the kind enabled by at least some embodiments of the system would help minimize the risk of identity theft. Consumer- grade biometric systems are somewhat unreliable. Systems described above may be deployed with high-reliability in-store biometric authentication devices as primary or secondary authentication mechanisms or combined with non-biometric secondary authentication methods to handle failure cases.

[0047] FIG. 2 depicts a block diagram of a key retrieval system, in accordance with some embodiments. In the depicted embodiment, the key retrieval system 200 is configured to receive a set of multiple presented biometric values (referred to at times as biometric readings and biometric targets) B[l], ... , B[q] and output a retrieved key K.

[0048] In at least some embodiments, the key retrieval system 200 is configured to identify, for each presented biometric value of the set B[l], B[q], a matching stored biometric value (biometric template) that is mapped to a partial cryptographic key. Hereinafter, partial key is used for partial cryptographic key, unless context dictates otherwise. A matching stored biometric value may be a biometric value stored in a database that is within a threshold similarity as compared to a presented biometric value. The key retrieval system 200 being configured to identify, for each presented biometric value of the set B[l], B[q], a matching stored biometric value that is mapped to a partial key, may include the key retrieval system 200 being configured to compare the corresponding presented biometric value to at least one of a set of one or more stored biometric values that includes the matching stored biometric value, the matching stored biometric value being the closest match of the set based on the comparison. The key retrieval system 200 may be configured to identify, for each presented biometric value, the matching stored biometric value based at least in part on a confidence score obtained from the corresponding matching stored biometric value. The matching stored biometric value being mapped to the corresponding partial key may include each matching stored biometric value having an index associated with the corresponding partial key. The index associated with the corresponding partial key may be the corresponding partial key. The index associated with the corresponding partial key may correspond to an index at which to retrieve the corresponding partial key.

[0049] In at least some embodiments, the key retrieval system 200 is configured to retrieve a key K from at least the partial keys. The key retrieval system 200 being configured to retrieve a key K from at least the partial keys may include the key retrieval system 200 being configured to construct the retrieved key as a combination of the partial keys with a helper value. The key retrieval system 200 may be configured to validate a mathematical relationship among the combination of the partial keys and the helper value prior to outputting the retrieved key.

[0050] After the key is retrieved, the key retrieval system 200 may output the retrieved key K for use in at least one cryptographic function. For example, the key retrieval system 200 may be configured to use the retrieved key in at least one of an authentication attempt or a decryption attempt.

[0051] In at least some embodiments, the key retrieval system 200 is configured to generate a check value of the retrieved key and determine if the retrieved key is valid based on the check value. In at least some embodiments, the key retrieval system 200 is configured to generate a check value of the retrieved key using a hash function.

[0052] In at least some embodiments, the key retrieval system 200 is configured to validate the retrieved key.

[0053] In at least some embodiments, the key retrieval system 200 is configured to output an authorization indication if the retrieved key is validated.

[0054] In at least some embodiments, the key retrieval system 200 is configured to, responsive to encountering a key-recovery failure, request and/or receive one or more re-presented biometric values.

[0055] In at least some embodiments, the key retrieval system 200 is configured to, based on an indication that the received key is not valid, identify, for at least one presented biometric value of the set of multiple presented biometric values, a different matching stored biometric value, the different matching stored biometric value being mapped to a different partial key. The key retrieval system 200 may also be configured to receive a different key from at least the different partial key. The key retrieval system 200 may also be configured to output the different key for use in at least one cryptographic function. [0056] An example use case of the key retrieval system 200 is to recover a key of a user Alice who lost her iPhone. Alice had many memories in the form of photos and text messages from loved ones stored on her phone but also stored in the cloud (e.g., iCloud) in association with her a. Alice is distraught, as she believes her beloved data is irretrievable. Alice goes to the Apple Store to see if there is any way to recover her data. Apple does not store the key that was used to encrypt her data that is stored in the cloud, and Alice does not remember her password. Alice is in luck though. She can use her biometrics to retrieve her key that can decrypt her encrypted data.

[0057] While at the Apple store, Alice presents her biometrics to a device in the store having a biometric reader. The device then transmits the presented biometric values to a key retrieval system that is configured to retrieve keys for registered users based on presented biometric values. The system maintains or has access to a database that stores biometric values that match those associated with registered users and maps those stored biometric values to partial keys that form, at least in part, the full key. Alice had previously registered her biometrics and therefore is able to retrieve her key and use the key to decrypt the encrypted data.

[0058] In at least some embodiments, the key retrieval system includes a confidentiality- preserving module and a Key- Assembly module (KA). The confidentiality-preserving module, for example, ingests and converts individual biometric measurements from a Sensor (S) into secrets called partial keys. This component may be referred to as the Biometric-to-Key Conversion (BKC) module. A key derived from a single, typical biometric, e.g., a fingerprint, typically has at least two limitations. First, the keys are low-entropy and are not cryptographically strong. Second, the keys are subject to errors and/or omissions due to the noisy nature of some biometric sensing. In some embodiments, the Key-Assembly module overcomes these limitations by combining multiple partial keys, e.g., prints from all ten of a user's fingers, into a full key K.

[0059] Employing the system may result in storing credentials in a centralized database with a greatly minimized risk of impersonation of users should a compromise occur. In some embodiments, the system includes a confidentiality-preserving system configured to convert a biometric measurement into a secret partial key and a key-assembly module (KA) for combining a set of partial keys into a full key in the presence of errors or erasures. The full key may be used for user authentication (or other goals such as, for example, decryption). In some embodiments, the confidentiality-preserving system incorporates an off-the-shelf biometric identification (one- to-many matching) algorithm for deriving a partial key K from a biometric value. The confidentiality-preserving system may be configured to store, for a given user's biometric value (e.g., a fingerprint), an associated collection C = { J[l], J[2], ... , T n ] of n different templates in a fixed, randomized order. When a user attempts to perform authentication and submits a biometric reading T, its closest match J[i] (or, in some embodiments, a plurality of matches) is found in C. The index i is the resulting partial key K. In some embodiments, C comprises Jand n-\ templates belonging to other users in the system, but the use of synthetic templates is also possible. In some embodiments, the confidentiality-preserving system is configured to store, for each biometric target of a plurality of biometric targets (e.g., a template for each user in a fixed, randomized order. In some embodiments, the KA module ingests a set of partial keys ¾^[l] .. PK[q] and converts the set of partial keys into a cryptographically strong, full key K. In some embodiments, the KA module uses fuzzy extraction or related techniques to tolerate errors and noise. The construction of the confidentiality-preserving system may provide uniformly and randomly distributed partial keys for a given user's biometric value, and thus rigorous security bounds can be obtained on the entropy of K. In some embodiments, the full key K is used to authenticate and facilitate credential recovery by the user. Authentication using the key K may be implemented in various ways, as is known in the art. Specific examples include performing authentication by using the full key K to derive a private key for use in a public-key based authentication protocol. In some embodiments, the full key K is used to decrypt user credentials that subsequently serve to authenticate a user (e.g., in a user-authentication protocol). In further embodiments, a hash value may be generated using a hashing function on the key K, and the hash value may be compared to a stored hash value that was generated from the key during user registration. In some embodiments, K is reconstructed by a user remotely, i.e., the mechanism may be on a client controlled by the user.

[0060] FIG. 3 illustrates a block diagram of an exemplary key retrieval system interacting with a user and a sensor. A user 305 may provide a sensor 315 with biometrics. For example, biometrics of the user 305 may be presented to the sensor 315 for reading. The sensor 315 may read each biometric and output presented biometric values.

[0061] As shown, the key retrieval system 300 includes a BKC 302 and a KA 306. The key retrieval system 300 ingests biometric readings 5[1] ...5[^] into the BKC module 302, which outputs partial keys PK[l] ...PK[q]. The partial keys, which, in at least some embodiments, are subject to omissions and errors, are assembled into a full key K by the KA module 304. A user may strongly authenticate information using the resulting key K, as well as for various other cryptographic purposes, such as communications.

[0062] FIG. 4 depicts a schematic of a BKC 402, in accordance with some embodiments. Uis defined as a unique user identifier and j is an index for a given biometric value for user U. For example, the ten distinct fingers of user U may be denoted by indices = 1, 2, ... , 10. [0063] In some embodiments, the BKC 402 ingests biometric readings and associated identifiers through a biometric intake interface 404. In some embodiments, the biometric intake interface 404 resides on a client machine operated by the user 405. In additional embodiments, the biometric intake interface 404 is a server-side application with which a user interacts through a browser. In some embodiments, the biometric intake interface 404 prompts the user 405 to provide a sequence of biometric readings, e.g., each of the user's fingers. In some embodiments, for each such reading the biometric intake interface 402 specifies the pair (UJ) to an algorithm called the biometric value selector 406 and passes Bj] to an identification algorithm 408. The identification algorithm 408 may include at least, for example, a one-to-many matching algorithm.

[0064] FIG. 5 depicts an example database. As shown, an associated database 510 receives four (UJ) pairs: (1,1), (1,2), (1,3) and (1,4). As shown, the various (UJ) pairs correspond to four different fingers of a user U. A biometric value selector outputs for each (UJ) pair, a sequence of n biometric values C ={T UJ, /^']} for i = 1 to n, where n is a security parameter. An identification algorithm receives a biometric value Bj] as an input and matches the biometric value Bj] against the values in C. (It is also referred to as 1 -to-many matching.) In FIG. 5, this is represented by closest match operation receiving biometric fingerprint B[4], which is associated with the user's pinky finger (1,4). Example identification algorithms include those used in the FBI Integrated Automated Fingerprint Identification System (IAFIS) system, research proposals such as Cappelli et al., "Large-Scale Fingerprint Identification on GPU," (Information Sciences 306, June 2015), and commercially available systems such as the VeriFinger system provided by Neurotechnology of Lithuania. As shown, the biometric fingerprint B[4] may be obtained via a sensor disposed on a mobile device 504, however there may be various other sensors, scanners and/or devices that may be used to obtain the biometric fingerprint. Furthermore, the embodiment of FIG. 5 is not limited to only obtaining fingerprint information, but other biometric information as well such as retinal data, iriscodes, voice data, and/or a 3D scan of a user's face, for example. For simplicity, only biometric fingerprint B[4] is shown in FIG. 5, however similar operations may be performed for pairs (1, 1), (1,2) and (1,3). In the exemplary embodiment shown in FIG. 5, the algorithm outputs a partial key index PKj] = i of the closest valid match or a failure message/symbol φ if there is no valid match. As shown in FIG. 5, the closest match i¾T[4] = 55. In some embodiments, in addition to outputting the closest match, the algorithm may additionally provide a confidence value associated with the match. In some embodiments, the algorithm may output multiple matches and thus multiple partial keys. In some embodiments, the algorithm may output a plurality of matches and a plurality of confidence values associated with the corresponding matches. The partial keys may then be concatenated to form key K, as shown in FIG. 5.

[0065] In general, the confidentiality or breach resistance of at least some embodiments of the system derives from the fact that the database associated with the biometric for a given pair {UJ) includes not one, but a collection of n distinct stored biometric values. Specifically, the sequence of stored biometric values C output by the biometric value selector on input (UJ) includes a true, conventional biometric template T*[U, j] corresponding to the (j-t ) target biometric value of the user U. The remaining n-\ values are "chaff templates, e.g., templates that do not correspond to the biometric value associated with (U, j). In some embodiments, chaff templates may be synthetically generated using Raffaele Cappelli's Synthetic Fingerprint Generator (SFinGe), for example. In other embodiments, chaff templates may be realized as follows. The database may store templates of right index fingers of a set of m (e.g., m = 100,000) users, along with a mapping from every user identifier U to both the true template T*[U, j] and a randomly selected set of n-\ right-index -finger templates from other users, for a total of n (e.g., 1,000) templates in the set C. In such embodiments, the biometric value selector may be viewed as inducing a bipartite graph on users and templates. Nodes on the left represent users {u k) for k = 1 to m, while those on the right represent their corresponding templates, permuted uniformly at random. Every node u k has outdegree n. Each node has an edge to T*[u kj] and n-\ edges to other nodes on the right (selected uniformly at random without replacement). That is, the nodes on the right incident on u k represent the set C associated with (U= u k, j). The position i of the true template for a given user U = u_k is her corresponding partial key PKj].

[0066] FIG. 6 depicts an example of a bipartite graph for m=5 users and n=2 templates in C using the chaff approach in construction of a biometric value selector. Edges from node u k designate the set of tempi ates C output for user u k. For example, for w l, C = [ T*[u_\J], T*[u_2, j]}, which are the true templates of users u_\ and w_2, respectively. As the *[u_lJ] is the second template on the right-hand side, i.e., in position i = 2, the graph shows that PKj] = 2 for user u_\ .

[0067] Using the above approach, if an adversary compromises the BKC 402 and database 410, the adversary may obtain the true template of every user. However, the true template of a given user u k is concealed among n-1 invalid templates, e.g., templates corresponding to other users. In the absence of additional information, it is therefore challenging for the adversary to identify the partial key/index PKj] = i for a given user u k with probability significantly greater than 1 / n. Given a correct biometric reading Bj] for user u k, however, the identification algorithm 408 in the BKC 402will with high probability match it to T*[u k ] and thus output the correct partial key PKj] = i.

[0068] Some embodiments described herein adopt such an approach, including synthetic templates in C, although, given the challenge of constructing plausible synthetic biometric templates, the use of other users' templates as chaff may be more desirable in some scenarios. The security parameter n determines the tradeoff between security and performance in the system. The larger n is, the better the security against guessing attack, but the lower the rate of breach detection and the lower the performance of the system. Thus, in some embodiments, n is tunable by the system administrator.

[0069] Employing techniques similar to those in (Juels, A., & Rivest, R. L. (2013, November). Honeywords: Making password-cracking detectable. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security (pp. 145-160). ACM.), an additional feature of breach detection may be realized. If a user submits a value that is in C but is incorrect for the user U, such an event constitutes evidence of a breach— as erroneous submissions of such values are rare under benign circumstances. One drawback of the approach in (Juels, A., & Rivest, R. L. (2013, November). Honeywords: Making password-cracking detectable. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security (pp. 145-160). ACM.), however, is that when m/n is relatively large (e.g., 1/2), it is hard to distinguish between a breach versus one user accidentally entering another user's username. When m is significantly large (e.g., m > n/2), it is improbable for a given user U'≠U that templates for U' will be present in a majority of the sets C for U' biometric features (i.e., sets C corresponding to distinct (U ) pairs).

[0070] Some embodiments described herein achieve strong detection of targeted breaches by generating a breach alert when an authentication attempt yields matches (e.g., partial keys) for greater than a threshold z (e.g., z = floor(^/2) + 1) (where q is the total number of partial keys) of the biometric values associated with a given user U, but the system fails to authenticate successfully— indicating that the matches are made against the chaff elements of the corresponding sets C.

[0071] The breach detection feature in some described embodiments provides a technical means of probing for infringement through the system API. In some embodiments, the system is configured for m/n to be relatively high (e.g., 1/4), meaning one or both of a relatively small number m of enrolled users and the choice of a relatively high security parameter n. Given a typical parameterization of q, (e.g., q = 10), then substitution of the biometric features of one enrolled user for those of another may create an alert with a small but non-negligible probability. In some embodiments, testing for the use of chaff to detect a breach includes repeatedly submitting as the biometric features measured for a given user U: (1) biometric features of other enrolled users and (2) biometric features of other, unenrolled users (e.g., synthetic biometrics). If the rate at which breach alerts are issued for (1) is statistically higher than for case (2), then there is evidence of the use of chaff in the BKC.

[0072] In some embodiments, the Key Assembly (KA) module stores for each user u k, a "helper" value S and a set J of q constituent biometric targets (e.g., the set of the user's ten fingerprints) used to recover K. To recover K, the system invokes the BKC for each biometric in J, producing partial keys ^[l], PK[2], ... , PK[q]. The KA combines the helper value S with the partial keys to recover K. A natural, general choice of technique for such reconstruction may be fuzzy extraction. An example of fuzzy extraction may be found in (Yevgeniy Dodis, Rafail Ostrovsky, Leonid, Reyzin, Adam Smith: Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data. SIAM J. Comput. 38(1): 97-139 (2008)).

[0073] Given a small enough number of partial keys and a means of checking the validity of K, it is possible to additionally correct errors using brute force techniques. That is, the KA can perform trial-and-error deletion of subsets of partial keys, creating erasures, and may thus use an erasure code rather than an error-correcting code as the basis for the extractor. Such a general approach was adopted in (Frykholm, N., & Juels, A. (2001, November). Error-tolerant password recovery. In Proceedings of the 8th ACM conference on Computer and Communications Security (pp. 1-9). ACM.) for non-biometric data, and without brute-force conversion of errors into erasures.

[0074] In some embodiments, a system utilizes a chaff-based BKC in which a set of ten fingerprints is used to recover the key K. K may be used to derive a private key sk whose corresponding public key pk is stored for user U. Given common false acceptance rates for fingerprint recognition systems (e.g., 1 :50,000 for TouchID), one may choose, e.g., n = 1024 = 2ⁱ⁰, to ensure a low probability that a user's fingerprint matches against an invalid template. In some embodiments, it is also possible to exclude false matches by appropriately constructing C when a user registers with the system, at the cost of some degradation in security. In some embodiments, a (10,6)-Reed Solomon code is used (over GF[2^rf]) in a fuzzy extractor based on (Juels, A., & Wattenberg, M. (1999, November). A fuzzy commitment scheme. In Proceedings of the 6th ACM conference on Computer and communications security (pp. 28-36). ACM.). Given a set of partial keys ^[l], ... , PK[\0 up to four errors can be corrected by brute-force decoding. Specifically, for every distinct subset P of four partial keys among the ten, the system can erase the partial keys in P, reconstruct a trial key K ' (or rej ect if reconstruction of K' fails), derive a trial key sk ' from K ', and output sk' = sk if sk ' matches pk.

[0075] Consider an adversary that compromises the system and obtains the helper value S and public key pk for a given user U. Assume the adversary has no advantage over a uniform random guess in determining a partial key PK[i], and assume an ideal model of security with an oracle that evaluates the predicate K' = K for input K'. Under these assumptions, the system provides 60-bit security forK. By deriving K using an iterated key-derivation function with count 2^d, it is possible to achieve (60+<f)-bit security, where d = 20 for example. This choice of parameters may thus be, in some scenarios, expected to achieve very strong security against brute-force cracking attacks, a correspondingly low false-acceptance rate, and— due to a high degree of error correction— a very low false-rejection rate.

[0076] In some embodiments, rather than authenticating a user, the key K or a derived private key sk could be used to decrypt sensitive user data, such as a vault J⁷ containing user credentials, device backups, etc. In some embodiments, the vault is stored in a system separate from that used to derive K.

[0077] In some embodiments, the system aids users in the recovery of credentials when they lose access to their primary authentication methods. For example, the system may help a user restore an image to a new mobile device if his/her existing one is lost or damaged. To mitigate the risk of online attacks, the system may perform a check to determine whether a user U still has access to a registered existing device, e.g., a mobile device, before permitting recovery of K. An alternative policy may be to disable the device given successful recovery of K. If the user still has access to the registered device, the system may reject authentication attempts for U. In some embodiments, infringement is detected simply by determining whether the system is checking for user access to a registered device prior to permitting credential recovery or implementing the policy of device disablement upon successful recovery of K.

[0078] In some embodiments, the BKC outputs multiple keys with confidence scores. The KA may then, for example, use a set-intersection fuzzy extraction scheme as proposed by (Yevgeniy Dodis, Rafail Ostrovsky, Leonid, Reyzin, Adam Smith: Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data. SIAM J. Comput. 38(1): 97-139 (2008)) or a fuzzy vault scheme proposed by (Juels, A., & Wattenberg, M. (1999, November). A fuzzy commitment scheme. In Proceedings of the 6th ACM conference on Computer and communications security (pp. 28-36). ACM.) to recover K.

[0079] FIG. 7 depicts a flowchart of a method 700, in accordance with some embodiments. As shown, method 700 for deriving and recovering a key from biometric information includes receiving, at step 702, a plurality of biometric targets. For each biometric target of the received plurality of biometric targets, the method includes sending, at step 704, a portion of information derived from the biometric targets to a server, receiving, at step 706, a plurality of potential matches for the biometric target selected by the server based on the sent portion of information, and determining, at step 708, an index value associated with one of the received plurality of potential matches which best matches the biometric target. Based on the index values, the method determines, at step 710, a key based at least on the plurality of determined matched index values associated with best matches from the plurality of potential matches for the plurality of biometric targets.

[0080] In some embodiments, determination of the key is performed by concatenating the determined match index values for the plurality of biometric targets.

[0081] FIG. 8 shows an example database. In at least one embodiment, the example database shown in FIG. 8 is the same as the example database shown in FIG. 5 and described above, except that they differ at least in the manner in which the partial keys are determined from the database and/or the organization of the database. In at least one embodiment, as shown in FIG. 8, the system includes a database (DB) 810 that is partitioned based on biometric targets. In some embodiments, the DB 810 includes a partition for each of a plurality of biometric targets. For example, as shown in FIG. 8, the DB 810 may be partitioned so that each partition is associated with a respective y^'th biometric target j=l, j=2, j=3, and j=4. As shown, partition 820 is associated with j=l, partition 830 is associated with j=2, partition 840 is associated with j=3, and partition 850 is associated with =4. In this example, the biometric targets correspond to, respectively, a right index finger, a right middle finger, a right ring finger, and a right pinky finger. In each y^'th partition, for each user, the exemplary DB 810 may store a biometric template for the corresponding y^'th biometric target. In some embodiments, the biometric template for each user is stored at an index i corresponding to a position of the biometric template in the DB 810. For example, the partition 850 for the biometric target j=4 may include a biometric template for each user's right pinky finger, and each right pinky- finger biometric template for all users may be stored within the partition j=4, in a random order. The index within the DB 810 at which each right pinky-finger biometric template is stored may be the corresponding partial key PKj=4]. As shown in FIG. 8, to determine a partial key PK\j the closest match operation is performed on the corresponding y^'th partition of the DB 810, and not on the entire DB 810.

[0082] FIG. 9 shows another example database. The example database shown in FIG. 9 is the same as the database shown in FIG. 5 and FIG. 8, except here, the DB 910 is not partitioned and the closest match operation is performed on the entire DB 910. In this example, the biometric templates are randomly stored in the DB 910 in an "unlabeled" manner, which means that the biometric templates are stored without considering the y^'th value of the corresponding biometric template.

[0083] A fundamental limitation given today' s biometric technologies is that there simply isn't enough entropy in a single fingerprint to construct a cryptographically strong key. As a result of this limitation, authentication of a user on the basis of a single fingerprint may not be feasible. Iriscodes contain sufficient entropy in principle, but typically have a number of drawbacks such as sensitivity to lighting conditions, the need for special-purpose cameras, highly restrictive patent encumbrance, etc. The above embodiments may be intended for credential recovery and may be deployed alongside backup credential recovery methods.

[0084] Deployment of some embodiments described above for consumers with iOS devices may pose a challenge, given that biometric measurements are handled by trusted hardware only and that the OS is controlled exclusively by Apple. In contrast, a mobile service provider selling Android handsets may customize them to support our solution, permitting potential deployment by a number of vendors. It seems likely that early users of our system would target non-consumer environments.

[0085] One or more embodiments described above remove user identifiers from biometric templates, associating key shares with these templates, use one-to-many matching on multiple biometrics (e.g., a user's ten fingers) to recover a user's key shares for authentication, and/or include error tolerance. Further embodiments are described below that include capabilities for increasing accuracy, for example, of key recovery for a user.

[0086] As large databases of biometric data proliferate, protecting them against breach and impersonation attacks becomes an increasingly urgent security goal. One new and efficient approach is described in one or more embodiments above and involves, for example, one-to-many matching of a user-provided biometric image against a set of templates without user identifiers. Some embodiments described below include additional and/or alternative features that enable boosting (e.g., significantly) accuracy (achieving a better false-negative/false-positive tradeoff). In some embodiments, the false negative rate (for a given false positive rate) is reduced (e.g., dramatically) by a key search procedure that is based on match quality/confidence and/or by dynamically refining a user's input by selectively prompting the user for one or more fresh biometric readings.

[0087] Many biometric systems incur false negatives, which can be considered as rejections of legitimate users. Lowering a system's false negative rate (for a given false acceptance rate) is often desirable, since lowering the system's false negative rate may translate into improvements in security and/or usability.

[0088] A typical approach to minimizing false negatives is to have a user present her biometric again after an authentication failure. The setting of some embodiments may differ from a typical one-to-many biometric setting. For example, some ordinary one-to-many settings aim at user identification, not authentication. In contrast to a typical one-to-many biometric matching system, in some embodiments described herein, successful authentication equates with successful recovery of a cryptographic key rather than a strictly biometric criterion, and as a result of increased computational investment, the probability of successful key recovery/user authentication may be increased. Further, in some embodiments the user is authenticated on the basis of multiple, distinct biometrics, which creates the opportunity for selective re-presentation of biometrics in the case of an authentication failure. Moreover, some embodiments have built-in tolerance to a small number of matching failures. For example, some embodiments enable recovery of a cryptographic key despite incorrectly matching one or more biometric readings (e.g., up to a threshold of incorrect matches).

[0089] Lowering false negative rates (for a given false-positive rate) using traditional techniques may be problematic when attempting to lower false negative rates (for a given false- positive rate) for embodiments described herein. Such a problem may require addressing the technical specifics of such embodiments, which may differ from those of more conventional biometric authentication systems (e.g., biometric authentication systems which store biometrics locally).

[0090] FIG. 10 is a schematic illustrating an exemplary system in accordance with some embodiments. As shown in FIG. 10, a biometric database 1002 obtains four {UJ) pairs: (1, 1), (1, 2), (1, 3), and (1, 4). The various (UJ) pairs correspond to four different fingers of a user U. The biometric database (DB) 1002 shown in FIG. 10 may store biometric data, such as, for example, a plurality of fingerprint templates for fingers of different users. For example, a biometric template for each of the user LPs ten fingers may be stored in the biometric database (e.g., as described in one or more embodiments above). In at least one embodiment, the biometric database of FIG. 10 is the same as the associated database 502 described above in connection with FIG. 5, the DB 802 described above with respect to FIG. 8, or the DB 902 described above with respect to FIG. 9. A set of biometric readings, {B[l], . . . , B[n]} (e.g., a full set of biometric readings of the user LPs fingerprints) may be obtained, for example, by a biometric reading sequencer (BRS) described below in connection with FIG. 11. In some embodiments, the biometric reading B[i] corresponds to the biometric reading having index i, which is an index uniquely associated with a particular finger. For example, index i = 1 may correspond to a pointer/index finger of a right hand, index i = 2 may correspond to a middle finger of a right hand, and index i = 6, may correspond to a pointer/index finger of a left hand. In a scenario with such index values, biometric readings B[l], B[2], and B[6] may correspond to the fingerprint reading of a pointer/index finger of a right hand, a middle finger of a right hand, and a pointer/index finger of a left hand, respectively. Each of the biometric readings of the set of biometric readings [B[l], . . . , B[n]} may be provided to the BRS.

[0091] FIG. 11 is a schematic illustrating an exemplary system architecture in accordance with some embodiments. The system architecture shown in FIG. 11 may be integrated with one or more components of embodiments described elsewhere herein. For example, the Biometric-to-Key Conversion (BKC) and/or Key Assembly (KA) modules in embodiments described above may call the components in the delineated region in FIG. 11.

[0092] The system architecture may include one or more modules. The exemplary system architecture shown in FIG. 11 includes a biometric reading sequencer (BRS) 1110, a biometric matching system (BMS) 1120, a working set structure (WSS) 1130, a key-reconstruction module (KRM) 1140, and a key management interface (KMI) 1150.

[0093] The BRS 1110 may be configured to collect and/or output one or more biometric readings B[i]. In some embodiments, the exemplary BRS 1110 interactively issues a request R (e.g., to a user-facing system) for a particular biometric and/or ingests the produced biometric reading from a given user. For example, the BRS 1 110 may issue a request R to a user U to present one or more biometrics for reading. For example, a mobile phone having a sensor configured to read one or more biometrics (e.g., mobile phone 504 of FIG. 5) may receive the issued request from the BRS 1110 and may responsively cause a user U to provide one or more biometrics for reading (e.g., by displaying a message for the user U to present the user LP middle finger for fingerprint reading). In some embodiments, the BRS 1110 issues the request R to a user first attempting authentication. In some embodiments, the BRS 1110 additionally or alternatively issues the request R to a user after occurrence of a condition. For example, after a failed authentication attempt for the user, the request R may be issued requesting re-presentation of one or more biometrics and/or additional/alternative biometrics or other user-specific data. As shown in FIG. 11, in some embodiments, the exemplary BRS 1110 collects one or more biometric readings B[i] for a given user and outputs the collected biometric readings to the BMS 1120.

[0094] The BMS 1120 may be configured to receive one or more biometric readings (e.g., corresponding to one or more biometrics of a user). For at least one of the received biometric readings, the BMS 1120 may output a plurality of biometric-template indices and associated match-confidence values for the corresponding received biometric readings. In some embodiments, the exemplary BMS 1120 is configured to return, upon representation of a biometric B, a sequence S of index/confidence pairs (S = {(I_l, C_l), (I_2, C_2), . . . , (I_d, C_d)}) for some d, where is an index of a possible match (e.g., a biometric template) within a biometric database (DB) to the biometric B and CJ is the associated confidence value or distance metric indicating a closeness of the possible match to the biometric B. In some embodiments, the confidence values may be generated by and output from a 1 : 1 biometric matching engine. For ease of explanation and for exemplary purposes only, the convention C I > C_2 . . . > C_d, where larger confidence values indicate a closer match, is adopted.

[0095] In some embodiments, the exemplary KRM 1140 attempts to recover a key K for a particular user by submitting a sequence of queries to the KMI 1150. For example, the KRM 1140 may submit various combinations of sets of indices to the KMI 1150, where each index corresponds to a position of a biometric template within a biometric database and may correspond to a key-share of an authenticating user's key.

[0096] The exemplary KMI 1150 may ingest indices of a set of biometrics and/or may output, drawing on a key-shared database (KD) 1160, either a reconstructed key K or a failure symbol #. Some embodiments of an interface of the KMI 1150 and the KD 1160are described in more detail below.

[0097] In some embodiments, when a given user U first attempts to authenticate, the BRS 1110 obtains a check value H on the user' s key K and collects a set of biometric readings {B[ I] ... B[n] } . For example, the check value H may be defined as H= H(K\\r) for salt r and a suitable hash function H (e.g., a password-hashing function such as bcrypt or Argon2), and the set of biometric readings may be a full set of a user's fingerprints. In some embodiments, the BRS obtains the check value H at a time other than when the user U first attempts to authenticate. In some embodiments, the BRS 1110 submits each biometric reading B[i] to the BMS 1120 and receives a set S[i] = {( [/^']_1, C[/^']_l), (I[i]_2, C[z]_2), . . . , (I[i]_d, C[i]_d)} of (index, confidence) pairs. The set ^fz] of index- confidence pairs may be inserted (e.g., by the BRS 1110) into a data structure called the WSS 1130, under an associated index i (e.g., an index uniquely associated with a particular finger). The BRS 1110 may additionally send H to the KRM 1140 and/or other modules and/or components described herein.

[0098] For a full WSS 1130 (e.g., a WSS including a set S for each of the n biometric values associated with a user), the KRM 1140 selects a set of indices {/[l], . . . , I[n]} (e.g., including one index /[/]_/ from each set S[i]) and submits (e.g., repeatedly submits) the set of selected indices to the KMI 1150. In some embodiments, the KRM 1140 submits the set of selected indices in decreasing order of the value of /(C[l], . . . , C[n]), for associated confidence values C[l], . . . , C[n] and a function /that computes a j oint confidence value over the full set of associated biometric readings. The function / may be, for example, Y[C[i] (e.g., for i = 1 to n). In some embodiments, the KRM 1140 submits the set of selected indices in decreasing order of the associated confidence values of C[l], . . . , C[n]. Such ordering of queries may minimize the total computation performed by the system as well as improve the probability of successful key recovery over other strategies of query ordering (e.g., randomized). For example, the KRM 1140 may select a first set of indices having the highest joint confidence value of /(C[l], . . . , C[n]) and may submit the selected first set of indices (e.g., to the KMI 1150) so that recovery of the user IPs key K may be attempted based on the selected first set of indices. If the recovery attempt fails to recover the user IPs key K with the first selected set of indices, the KRM 1140 may, for example, submit (e.g., to the KMI 1150) a selected second set of indices having the second highest joint confidence value of/(C[l], . . . , C[n]) so that recovery of the user LP key K may be attempted with the selected second set of indices. This process of submitting selected sets of indices in decreasing order of joint confidence values may continue, for example, until successful or unsuccessful recovery of the user LP key K or until another predetermined event/time (e.g., exceeding a threshold of recovery attempts). In some embodiments, only sets of indices having an associated joint confidence value greater than a threshold are selected and/or eligible to be selected.

[0099] Referring to FIG. 10, the exemplary joint-confidence value including one individual confidence value from each set S[l], S[2], [3], and [4] is highest when including the individual confidence values C[\]_\ (e.g., 0.66), C[2]_\ (e.g., 0.24), C[3]_\ (e.g., 0.72), and C[4]_\ (e.g., 0.49). In some embodiments, in such a scenario, the KRM selects the corresponding indices i[l]_l (e.g., 07), 7[2]_1 (e.g., 67), 7[3]_1 (e.g., 45), and 7[4]_1 (e.g., 12) and submits such indices to the KMI to first attempt key recovery of the user LPs key K. As shown in FIG. 10, in this exemplary scenario, the correct key K for the user U is 07 52 45 12, and the first key recovery attempt will result in a failed attempt. In some embodiments, the KMI will then select the corresponding indices of the second highest joint confidence value to attempt key recovery of the user LPs key K. In some embodiments, the KMI will continue to select corresponding indices of the next highest joint confidence value (e.g., with respect to the previously selected corresponding indices) and submit a set of indices including the selected indices to attempt key recovery of the user LP key K until the key K is recovered, a threshold number of attempts is reached, or the key K is not recovered after all combinations of indices are used in key recovery attempts.

[0100] In some embodiments, the KRM first submits (e.g., to the KMI) a selected set of indices {/[l], . . . , I[n]}, where the indices , . . , I[n] of the first submitted set of indices are the corresponding indices from each set S[i]. As described above, the index i_l [i] is the index of the biometric template in the biometric database having the highest confidence score in the set S[i] for biometric reading B[i]. Recovery of the user LP key K may, for example, be attempted based on the selected first set of indices. In some embodiments, if the recovery attempt fails to recover the user LPs key K with the first selected set of indices, the KRM submits (e.g., to the KMI) a selected second set of indices having at least one index different from the corresponding indices from the first submitted set of indices. In an exemplary scenario for n = 5, the selected first set of indices is {/[1]_1, [2]_1, 7[3]_1, 7[4]_1, 7[5]_1 } and the selected second set of indices is { [1]_1, [2]_1, /[3]_1, /[4]_2, Z[5]_l }. In this exemplary scenario, the selected second set of indices includes /[4]_2 instead of or in place of i[4]_l . In this exemplary scenario, i[4]_2 is included in the selected second set of indices instead of or in place of i[4]_l as a result of a difference between the corresponding confidence values being the least for 7[4]_2 and 7[4]_1 than for a difference between the corresponding confidence values for the other and I[i]_2 in each S[i]. In some embodiments, the selected second set of indices includes one or more from the selected first set of indices for which the difference between the corresponding confidence value for and I[i]_2 exceeds a threshold confidence value. Additionally, or alternatively, in some embodiments, the selected second set of indices includes one or more of a corresponding I[i]_2 from S[i] for which the difference between the corresponding confidence value for 7[i]_l and I[i]_2 does not exceed a threshold confidence value.

[0101] Upon successful reconstruction of a key K, the key K may be emitted and may be used for a variety of purposes such as, for example, those described above. For example, the key K may be used for decryption (e.g., in a decryption operation) in response to a request for access to and/or recovery of information that may be encrypted. In some embodiments, upon successful reconstruction of a key K, the KRM checks the key against H. Referring to FIG. 11, if K is correct (e.g., after checking key K against H) and/or after successful reconstruction, the KRM 1140, for example, may emit K and may send a T bit or an equivalent/alternative indication (e.g., to the BRS), indicating that no further querying of the user is required.

[0102] In some embodiments, upon submitting all queries or a number of queries exceeding a threshold of queries, for a given set of data in the WSS 1130 without successful key recovery, the KRM 1140 sends a '0' bit (or an equivalent/alternative indication) to the BRS 1110. In some embodiments, the BRS 1110 then requests that the user present a single biometric or set of biometrics for re-reading. The BRS 1110 may select the biometric or biometrics based on confidence values for sets in the WSS 1130. In one embodiment, the BRS 1110 may select the biometric for which C[z]_l is smallest for fresh presentation.

[0103] The BRS may insert one or more new biometric readings S[i] into the WSS, which may trigger a new round of key reconstruction queries (e.g., by the KRM). For example, after the BRS receives one or more new biometric readings (e.g., provided in response to a request R), new individual and/or joint confidence scores may be calculated and/or one or more new sets of index/confidence pairs may be provided to the WSS 1130. Key recovery may then proceed as described in embodiments above.

[0104] In some embodiments, for a given user authentication attempt, the system outputs either a successfully reconstructed key K or a symbol/message φ indicating a reconstruction failure.

[0105] Supplementary factors: Instead of the BRS requesting, from a user, fresh presentation of a biometric previously read in an authentication session, the BRS may request from a user presentation of an additional biometric and/or a non-biometric factor. For example, after an unsuccessful key recovery attempt of a user's key Abased on fingerprint readings of the user's ten fingers, the BRS may request that the user present one or both of her eyes (e.g., for a retinal scan) so that retinal data may be obtained. In such embodiments, the additional biometric data (e.g., the retinal data) and/or the non-biometric factor data corresponding to one or more users may be stored in the biometric database and/or another database from which suitable biometric and/or non- biometric data may be obtained. Additional factors may be supported by a suitable adjusted KMI.

[0106] Evolving user prompts: In some scenarios, low confidence values may be indicative of, for example, presentation of the wrong finger. For example, confidence values may be low in a scenario where the system (e.g., the exemplary BRS) requests presentation from a legitimate user of the smallest digit on the legitimate user's left hand and the legitimate user presents a different finger than requested. In the case of key recovery failures, the system may provide users with additional and/or alternative guidance to that previously presented (e.g., as a result of a request R from the BRS). For example, more detailed guidance and/or emphatic prompts (e.g., "Are you sure you've presented the smallest digit on your left hand?") may be offered to users after key recovery failures (e.g., that exceeds a threshold of failures) and/or at other times (e.g., if the user asks for help in presenting her biometric).

[0107] Bounding computation: To bound its computational effort (or for calibration of false accept / false reject rates), the system may, for example, bound the total number of KMI queries and/or the total number of WSS refreshes (e.g., for a predefined number of authentication sessions).

[0108] Consider, for example, some embodiments of a system for breach-resistant centralized biometric authentication as described herein which is implemented using a user LP full set of ten fingerprints. This form of strong, confidentiality-preserving biometric authentication may be useful in a broad range of scenarios, such as for example, for authenticating travelers, for in-store recovery of credentials for a user whose mobile device has failed or been lost, for preventing false claims for social services (in, e.g., the AADHAR system), among other scenarios. In some embodiments described above, key construction proceeds based only on the closest matches of the user LP s biometric against those in a global database. Even if a small number of erroneous matches are made, such embodiments described above can still successfully recover a user's key K.

[0109] Consider, however, the exemplary case where every finger is incorrectly matched, and the most closely matched fingerprints are not LPs, but the second most closely matched fingerprints belong to U. In such a case, embodiments described above that enable key recovery using more than only the closest match of the user IT s biometric against those in a database may be employed to successfully recover the user LPs key K. For example, after a failed attempt to recover the user LP key K with selected indices of the fingerprint templates that are most closely matched to the corresponding biometric readings of user U (e.g., as determined by individual and/or joint confidence values as described above), a successful attempt may be made to recover the user LP key K with selected indices of the fingerprint templates that are the second most closely matched to the corresponding biometric readings of user U (e.g., as determined by individual and/or joint confidence values as described above). [0110] Similarly, as another example, suppose that an exemplary embodiment described above is configured to tolerate two matching failures. Instead of two matching failures, three matching failures occur. Further, suppose that the matching failures result without even close subsidiary matches being made (e.g., by the exemplary KMI), which may happen if the user accidentally presents the wrong finger. In such a situation, if the exemplary embodiment is not also configured to enable re-presentation of one or more biometrics after matching failures, then with high probability low confidence values will result (since the user is presenting a finger not present in the associated database partition). In such a situation, employing an embodiment described above which is configured to enable re-presentation of one or more biometrics may result in the user being prompted (e.g., by the BRS) to again present her finger (e.g., as described above in relation to "evolving user prompts") and may lead to an increased probability of successful key recovery.

[0111] Detecting use from the outside: It may be feasible to detect use of systems and methods in accordance with embodiments as described herein, for example, with access to system internals. It may be possible to register a synthetic cluster of biometrics F* = {Fl . . . Fc} with the following properties: (1) any pair (Fi, Fj) of biometrics is close enough to be considered a valid match in a one-to-one matching system; (2) there exists a pair (Fi, Fj) such that Fj more closely matches all elements of F* \ Fi than Fi. Given such a set F* (e.g., which can be made arbitrarily large), it may be feasible to register Fi for a given user and then present Fj during an authentication session. An authentication failure may then provide strong evidence for use of one or more embodiments as described herein. Some embodiments described herein also support an additional test to detect use in which an authentication failure is created such that the absolute confidence for a particular biometric is high, but its confidence relative to others is low, and a fresh presentation is solicited by the system. Such a result may indicate infringement (e.g., unauthorized use) of one or more embodiments described herein.

[0112] In some embodiments described below, enhanced error and erasure correction for a system that constructs cryptographic keys (e.g., strong cryptographic keys) from noisy or error- prone data sources using the help of a database is provided. An exemplary application of some such embodiments may include key recovery using a collection of IoT devices, some of which may go missing or be replaced. In some embodiments, enhanced security is achieved in key retrieval systems and/or biometric authentication systems such as, for example, some of the systems described above.

[0113] A server-enhanced key-recovery system based on IoT devices may employ error- correcting codes to provide resilience to erasure or corruptions. For successful key recovery, some embodiments may need to additionally store user-specific error-correcting ("helper") information. In such embodiments, the error-correcting data leaks information about keys, but such embodiments may be simpler (e.g., to implement). Although such naive approaches can still achieve a high level of security for reasonable parameterizations, it may be desirable to achieve higher security and/or a broader range of possible parameterizations.

[0114] Moreover, the goal of key management in noise-prone environments, such as for example, environments in which data may be lost or corrupted that are addressed by some embodiments described herein may be desirable in various domains. For example, such a goal arises naturally in password authentication Yevgeniy Dodis, Rafail Ostrovsky, Leonid Reyzin, Adam Smith: Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data. SIAM J. Comput. 38(1): 97-139 (2008) , password recovery question Frykholm, N., & Juels, A. (2001, November). Error-tolerant password recovery. In Proceedings of the 8th ACM conference on Computer and Communications Security (pp. 1-9). ACM., authentication of physical objects [GKST07], as well as other domains.

[0115] Some embodiments described below offer a higher level of security for many parameters of interest, for example, for embodiments of systems described herein with a relatively high (e.g., tens of thousands) of users.

[0116] In some embodiments, the system is implemented as a mechanism that can facilitate error-correction in systems including a database, for example, that is used to achieve reconstruction of a strong cryptographic key with the aid of a number of independent data sources. As an example, the mechanism may be employed with embodiments described above to facilitate high-entropy key reconstruction in the presence of noisy biometric data.

[0117] Some embodiments described herein may be viewed as a novel adaptation of (Juels, A., & Sudan, M. (2006). A fuzzy vault scheme. Designs, Codes and Cryptography, 35(2), 237- 257). In such embodiments, a randomly generated, degree-A: polynomial represents a secret key of a given user, and shares (of which n > k are stored) are constructed as points on the polynomial. To reassemble the user's key, the shares are collected and the polynomial is reconstructed. In the presence of errors or erasures, for example, this process may involve Reed-Solomon decoding.

[0118] In at least one embodiment, the shares associated with all templates are stored in a randomly permuted order. In an example scenario, under a certain parametrization, the total set of shares induces a large number of degree-A polynomials, of which only a small fraction corresponds to actual user secrets. It is thus infeasible for an adversary to extract a user's secret from the database without knowing a priori which templates correspond to the user, in which case the adversary may likely be able to impersonate the user. Accordingly, in at least one embodiment, a broader range of parametrizations equates to a better security for a given error tolerance, or vice versa.

[0119] In a system relying on a database and a number of independent data sources belonging to a user, constructing a strong cryptographic key using at least one embodiment described below confers at least two advantages over naive approaches involving the direct use of data sources or their indices in a database as key shares. Such embodiments can provide a better security/error- correction tradeoff. As an example, in some embodiments described above, given 2^A16 (=65536) users (thus 16-bit subkeys), 10 fingerprint templates, and a 64-bit secure sketch (with four symbols from GF[2^A16]), it may be possible to achieve 96-bit security. In some embodiments described below, we estimate that 144-bit security may be achievable with a comparable degree of error- tolerance. This estimate considers a scenario where different template types are labeled (e.g., the system distinguishes among fingerprints from different fingers; without this requirement, stronger security would be possible). These estimates are based on an attacker having no side information that completely compromises all data in the system. The disclosed system may provide for easy registration of new users, as key shares for new users are independent of values stored for existing user's key shares.

[0120] The KMI does not directly handle the sensitive data from which keys are derived and may be maintained separately from the system managing such data (e.g., which may be an engineering advantage), for example, a biometric database (DB) (e.g., which may be the same as the biometric database DB in embodiments described above).

[0121] FIG. 12 is an architectural diagram illustrating an exemplary Key Management Interface (KMI) and a key-share database (KD), in accordance with at least one embodiment. The KMI may be a simple unifying interface through which various functionalities are presented. The KD may be a database which may be maintained and/or may include key shares. For example, the KMI may be employed to generate key shares, insert key shares into the KD and/or reconstruct a key. For example, the KMI may register a user, at least in part, by generating key shares for the user and inserting the user's key shares into the KD. As illustrated in FIG. 12, in at least one embodiment, the KMI accepts a user identifier U and/or provides mapping data For example, the KMI may accept a user identifier U upon registration of the corresponding user and/or may provide mapping data for management of a biometric database such as, for example, the DB as described in one or more embodiments above. Further, as illustrated in FIG. 12, in at least one embodiment, to reconstruct a user's key, the KMI accepts as input indices of the user's shares, {Ind[i]}, along with U and/or the KMI outputs key K if sufficiently many indices are correct. In some embodiments, the KMI does not directly handle sensitive data from which keys are derived and/or is maintained separately from the system managing such data, which in some scenarios is an engineering advantage. For example, the KMI may be maintained separately from a biometric database managing such data, such as, for example, the DB described in at least one embodiment above.

[0122] The exemplary embodiment of the KMI illustrated in FIG. 12 includes a GenShares Module 1252, an InsertShares Module 1254, and a Reconstruct Module 1256. As illustrated in FIG. 12, in at least one embodiment, the GenShares Module 1252 receives a user identifier U and/or outputs a set of generated key shares {s[i]}. In at least one embodiment, the InsertShares Module 1254 receives the set of generated key shares {s[i]} and/or inserts one or more key shares (e.g., randomly) into the KD 1204. In this exemplary embodiment, { [$]} is used to denote key shares that are inserted into random positions in the KD 1204 by the InsertShares Module 1254. In at least one embodiment, the KD 1204 may be viewed as a sequence of share values S[l] ... S[N] (in a field F). As illustrated in FIG. 12, in at least one embodiment, the Reconstruct Module 1256 receives a user identifier U and a corresponding set of indices {Ind[/^']}, and/or the corresponding set of indices are transmitted to the KD 1204. Further, as illustrated in FIG. 11, in at least one such embodiment, the KD 1204 responsively returns a set of key shares {s'[z^']} to the Reconstruct Module 1256 which outputs a reconstructed key K or a failure symbol #.

[0123] Share generation module. The GenShares Module 1252 may be referred to as a share generation module. In at least one embodiment, when a new user is to be enrolled in the KD 1204, a degree-A: polynomial p(x) over a field F is generated. Shares s[l], . . . , s[n] =p(x[l]), p(x[2]), . . . , p(x[n]) may then computed for X = {x[l], x[2], . . . , x[ri]}, for x[i] in F, where X may be user- specific or global values. For simplicity, we assume that these are global values.

[0124] In at least one embodiment, the GenShares Module 1252 uses an exemplary Function GenShares algorithm as described below for generating key shares for user registration/enrollment. In at least one such embodiment, parameters of the exemplary Function GenShares algorithm shown below are F, k, n, and X. F is a field (e.g., a field of finite elements) over which a degree-A: polynomial p(x) is generated and X is a set of n functional inputs {x[l], x[2], . . . , x[n]} to the degree-k polynomial p(x). In at least one such embodiment, the function GenShares has an input U, which is a user identifier and/or a unique associated string, and/or has an output (s[l], . . . , s[«]) and key K. It is noted that the <-$ symbol as used herein denotes uniform random selection. KeyDerive(£/, Z) F^k -> {0, 1 }^A/ U {#} may derive an /-bit key from U and an input Z consisting of k field elements (e.g., hash a concatenated bit representation). In some embodiments, if Z = # then KeyDerive outputs #.

To output KeyDerive (U, a[l] . . . a[k]), the following algorithm may be used:

For i = 1 to k

a[i] <-$ F

For i = 1 to n set s[z^'] = a\j]x[i]^j

Output KeyDerive U, a[l] . . . a[k])

[0125] In at least one embodiment, the a[i] values are generated by uniform random selection of elements in the field F. The a[i] values may correspond to coefficients of the randomly generated degree-k polynomial for a user. The a[i] values may be selected at random when the corresponding user registers. Note that the share values are evaluations of the degree-k univariate polynomial on distinct inputs.

[0126] Secret-share database API. The InsertShares Module may be referred to as a secret- share database application program interface (API). In at least one embodiment, an input to a function InsertShares is the n share values output by the GenShares Module, and an output of the function InsertShares is a differential index map M. In at least one embodiment, Insert(s, j) is defined to shift S[j] in the KD forward by one position and insert a share s into position S[j]. In at least one such embodiment, then the function InsertShares does the following:

For / = 1 to n, lmert(s[i]J), forj <-$ { 1 . . . N+i-l }

Set m[i] =j.

Return = {m[\\ . . . , m[n]}

[0127] A database of biometric templates (e.g., DB 1102) may reorder templates using the differential index map , for example, to ensure that the ordering of templates does not leak information about the correspondence between users and shares. After key shares are generated for a registering user (e.g., via the GenShares Module) and after a correspondence is established between the user's key shares stored in the KD and the user's biometric templates in the biometric database (e.g., by the biometric database storing the user's biometric templates at the same indices as the KD stored the user's key shares), the user may retrieve the key and/or authenticate.

[0128] Reconstruct Module. As illustrated in FIG. 12, in at least one embodiment, the Reconstruct Module receives a user identifier U of a user attempting to recover her key k. For example, the user may be attempting to recover her key k for authentication purposes. As illustrated in FIG. 12, in at least one such embodiment, the Reconstruct Module also receives a set of indices {Ind[i]} corresponding to the user's matched biometric values. One exemplary algorithm that the Reconstruct Module may use to reconstruct a user's key K is referred to as Function Reconstruct. An input to the Function Reconstruct algorithm may be (U, Ind[l], . . . , Ind[n]) and an output of the function Reconstruct may be secret key K or a failure symbol # if a decoding failure is detected.

[0129] To recover the secret key K, error-correcting decoding techniques may be used on the keyshare values responsively returned from the KD 1204 based on the set of indices provided to the KD. In at least one embodiment, the error-correcting decoding technique is Reed-Solomon decoding. In at least one such embodiment, RSdecode is defined to perform Reed-Solomon decoding on a set of symbols s[l], . . . , s[n] representing (noisy) evaluations of a polynomial p(x) on coordinates X, yielding a k-symbol output representing polynomial coefficients or # indicating a decoding failure. Let Ube a user identifier and/or unique associated string. Then the exemplary Function Reconstruct algorithm does the following:

For i = 1 to n set s' [i] = S[Ind[/]] (fetch shares from KD)

Output KeyDerive(£/, RSdecode(s' [l] . . . s'[n]), X))

[0130] If the secret key K has sufficient entropy, a hashed representation H(K) may be stored for a given user. In this case, the Function Reconstruct can check the correctness of the output of KeyDerive. The Reconstruct Module may thus be configured to correct a larger number of erasures or corruptions via brute-force search in the "neighborhood" of the shares s' [l] . . . s' [n]. Exploration of this "neighborhood" is possible by, e.g., ingesting from database KD and trying multiple candidates from one or more shares s'[i].

[0131] Authentication of the user may, for example, take the form of a comparison of a hashed representation of the derived key K to the hashed representation H(K) stored for a given user. For a given user, matching the hashed representation of the derived key K to the stored hashed representation H(K) may be, for example, indicative of authenticating the given user. Instead or in addition to authenticating a user based on a comparison of the stored hash representation with the hash representation of the derived key, a derived key K may be, for example, used to derive a private key for use in a public-key based authentication protocol. As another example, a derived key K may be, for example, used to decrypt user credentials that may subsequently serve in a user- authentication protocol. For example, a user's credentials may be stored in an encrypted form that may be decrypted with the derived key. Accordingly, after the user's credentials are decrypted with the derived key, the user may be authenticated with such credentials. These are provided as non-limiting examples of user authentication procedures.

[0132] As an example, consider an embodiment that employs a set of media access control (MAC) addresses of IoT devices belonging to a user to construct a strong cryptographic key. Such an embodiment may involve a database that maps MAC addresses to key shares. To register a new user U with MAC addresses A *[1] . . . A *[«], a BKC (e.g., the exemplary BKC described in some embodiments above) calls GenShares(£7) and then calls InsertShares(s[l], . . . , s[n]). In this example, using , the BKC matches the ordering of addresses A *[l] . . . A *[n] when placed in DB to the corresponding ordering of shares in KD.

[0133] As another example, let DB denote a database maintained for the BKC in which, for example, fingerprint templates are represented. Further, in this example, suppose that this database may be represented as an ordered sequence of templates J[l] ... 1 W], and that that for each T[f\ a key index L[i] may be stored. Let n = q. To register a new user U with templates B*[l] . . . B*[ri], the BKC may call GenShares(£7) and then may call InsertShares(s[l], . . . , s[n]). Using M, the BKC may match the ordering of templates B*[l] . . . B*[n] when placed in DB to the corresponding ordering of shares in KD.

[0134] When a user attempts to authenticate with biometrics B[l] . . . B[n], the BKC passes Ind[\], . . . , Ind[n] to the KA module, where Ind[i] is the position of B[i] in DB. A KA module (e.g., the KA module in embodiments described above) calls Reconstruct^, Ind[l], . . . , Ind[n]). Note that no helper value is required for reconstructing a key in this example.

[0135] Some embodiments are implemented in such a way that data sources (e.g., biometric template types) are labeled (e.g., by finger type). Higher security may be obtained here, however, with use of unlabeled sources (e.g., biometric templates of various types are stored together irrespective of type), as an adversary then cannot correspondingly partition shares.

[0136] FIG. 13 is a flow chart of a method in accordance with at least one embodiment. At 1302, a set of multiple presented biometric values are received. At 1304, for each presented biometric value, a matching stored biometric value is identified, the matching stored biometric value being mapped to a partial key. At 1306, a key from at least the partial keys is retrieved. At 1308, the retrieved key is output.

[0137] In at least some embodiments, identifying, for each presented biometric value, the matching stored biometric value comprises comparing the corresponding presented biometric value to at least one of a set of one or more stored biometric values that includes the matching stored biometric value, the matching stored biometric value being the closest match of the set based on the comparison.

[0138] In at least some embodiments, retrieving the key comprises constructing the retrieved key as a combination of the partial keys with a helper value. The method may also include validating a mathematical relationship among the combination of the partial keys and the helper value prior to outputting the retrieved key.

[0139] In at least some embodiments, identifying, for each presented biometric value, the matching stored biometric value is based at least in part on a confidence score obtained for the corresponding matching stored biometric value.

[0140] In at least some embodiments, each matching stored biometric value being mapped to the corresponding partial key comprises each matching stored biometric value having an index associated with the corresponding partial key. In at least some embodiments, retrieving the key comprises constructing the retrieved key as a combination of the partial keys with a helper value. In at least some embodiments, the index associated with the corresponding partial key is the corresponding partial key. In at least some embodiments, wherein the index associated with the corresponding partial key corresponds to an index at which to retrieve the corresponding partial key.

[0141] In at least some embodiments, the method comprises using the retrieved key in at least one of an authentication attempt or a decryption attempt.

[0142] In at least some embodiments, the corresponding presented biometric value is compared to at least one of a set of one or more stored biometric values that includes the matching stored biometric value, the matching stored biometric value being the closest match of the set based on the comparison.

[0143] In at least some embodiments, the method comprises generating a check value of the retrieved key and determining if the retrieved key is valid based on the check value. In at least some embodiments, generating the check value of the retrieved key comprises using a hash function.

[0144] In at least some embodiments, the method comprises validating the retrieved key.

[0145] In at least some embodiments, the method comprises outputting an authorization indication if the retrieved key is validated.

[0146] In at least some embodiments, the method comprises encountering a cryptographic- key-recovery failure, and responsively requesting and receiving one or more re-presented biometric values.

[0147] In at least one embodiment, identifying, for each presented biometric value, the matching stored biometric value is based at least in part on a confidence score obtained for the corresponding matching stored biometric value.

[0148] In at least one embodiment, the method includes, based on an indication that the retrieved key is not valid, identifying, for at least one presented biometric value of the set of multiple presented biometric values, a different matching stored biometric value, the different matching stored biometric value being mapped to a different partial key, retrieving a different key from at least the different partial key, and outputting the different key for use in at least one cryptographic function.

[0149] FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, and the like, to multiple wireless users. The communications system 100 may enable multiple wired and wireless users to access such content through the sharing of system resources, including wired and wireless bandwidth. For example, the communications systems 100 may employ one or more channel-access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. The communications systems 100 may also employ one or more wired communications standards (e.g. : Ethernet, DSL, radio frequency (RF) over coaxial cable, fiber optics, and the like.

[0150] As shown in FIG. 1A, the communications system 100 may include client devices

102a, 102b, 102c, and/or 102d, Radio Access Networks (RAN) 103/104/105, a core network

106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, and communication links 115/116/117, and 119, though it will be appreciated that the disclosed embodiments contemplate any number of client devices, base stations, networks, and/or network elements. Each of the client devices 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wired or wireless environment. By way of example, the client device 102a is depicted as a tablet computer/smartphone, the client device 102b is depicted as a pair of AR or VR goggles, the client device 102c is depicted as a computer, and the client device 102d is depicted as a television.

[0151] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0152] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple- input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0153] The base stations 114a, 1 14b may communicate with one or more of the client devices 102a, 102b, 102c, and 102d over an air interface 1 15/116/117, or communication link 119, which may be any suitable wired or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, and the like). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0154] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel-access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the client devices 102a and 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High- Speed Uplink Packet Access (HSUPA).

[0155] In another embodiment, the base station 114a and the client devices 102a and 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0156] In other embodiments, the base station 114a and the client devices 102a and 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0157] The base station 114b in FIG. 1 A may be a wired router, a wireless router, Home Node B, Home eNode B, or access point, as examples, and may utilize any suitable wired transmission standard or RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the client devices 102b, 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the client devices 102b, 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the client devices 102 b, 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, and the like) to establish a picocell or femtocell. In yet another embodiment, the base station 114b communicates with client devices 102a, 102b, 102c, and 102d through communication links 119. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109. [0158] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the client devices 102a, 102b, 102c, 102d. As examples, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and the like, and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0159] The core network 106/107/109 may also serve as a gateway for the client devices 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and IP in the TCP/IP Internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0160] Some or all of the client devices 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the client devices 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wired or wireless networks over different communication links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0161] FIG. IB depicts an example client device that may be used within the communications system of FIG. 1A. In some embodiments, the client device is an AR/VR HMD, a smartphone, a laptop computer, a tablet computer, any other client device known to those of skill in the art, or any combination thereof. In particular, FIG. IB is a system diagram of an example client device 102. As shown in FIG. IB, the client device 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the client device 102 may represent any of the client devices 102a, 102b, 102c, and 102d, and include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home Node-B, an evolved home Node-B (eNodeB), a home evolved Node-B (HeNB), a home evolved Node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0162] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the client device 102 to operate in a wired or wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0163] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117 or communication link 119. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive R signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. In yet another embodiment, the transmit/receive element may be a wired communication port, such as an Ethernet port. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wired or wireless signals.

[0164] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the client device 102 may include any number of transmit/receive elements 122. More specifically, the client device 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0165] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the client device 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the client device 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0166] The processor 118 of the client device 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the client device 102, such as on a server or a home computer (not shown).

[0167] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the client device 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, a wall outlet and the like.

[0168] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the client device 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the client device 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. In accordance with an embodiment, the client device 102 does not comprise a GPS chipset and does not acquire location information.

[0169] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. The peripherals 138 may also include any devices used to obtain biometric information, such as but not limited to fingerprint scanners and retinal scanners.

[0170] FIG. 1C depicts an exemplary network entity 190 that may be used in embodiments of the present disclosure, for example as a server operating as a virtual environment model service or other component described herein. As depicted in FIG. 1C, network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[0171] Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0172] Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP. [0173] Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non- transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 1C, data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.

Additional EXAMPLE Embodiments

[0174] A first additional embodiment takes the form of a method that includes receiving a set of indices corresponding to matched biometric values from an authentication request. The method also includes forming a key based on the indices and a helper value. The method also includes authenticating the user with the key.

[0175] In at least one first additional embodiment, the method further includes, obtaining a different set of concatenated indices, the different set of concatenated indices being selected based on one or more confidence values.

[0176] In at least one first additional embodiment, forming the key from the set of indices based on the helper value includes combining the helper value with the concatenated set of indices.

[0177] In at least one first additional embodiment, the helper value is a user-specific helper value. In at least one such embodiment, the method further includes receiving a unique user identifier associated with the user-specific helper value.

[0178] A second additional embodiment takes the form of a method that includes obtaining a plurality of fingerprint readings of a user. The method also includes comparing each obtained fingerprint reading of the user to a plurality of stored fingerprint templates, each of the stored fingerprint templates of the plurality of stored fingerprint templates having an index value. The method also includes obtaining a set of index values and associated confidence scores associated with a subset of the stored fingerprint templates. The method also includes assembling, based on the assigned confidence scores, a candidate key from respective index values. The method also includes attempting to validate the assembled candidate key. The method also includes outputting an authorization indication if the assembled candidate key is validated.

[0179] In at least one second additional embodiment, the method further includes if the assembled candidate key is not validated, outputting an indication of a decoding failure. In at least one such embodiment, outputting the indication of the decoding failure occurs responsive to a threshold number of validation attempts being exceeded.

[0180] In at least one second additional embodiment, the method further includes if the assembled candidate key is not validated, outputting a biometric resubmission request. In at least one such embodiment, the output biometric resubmission request is based on a comparison of confidence scores. In another at least one such embodiment, the method further includes receiving a resubmitted fingerprint reading of the user in response to the output biometric resubmission request.

[0181] In at least one second additional embodiment, the method further includes generating a check value of the assembled candidate key using a hash function. In at least one such embodiment, the method further includes detecting an error in the assembled candidate key based on the check value. In another at least one such embodiment, the method further includes determining the assembled candidate key is valid based on the check value.

[0182] In at least one second additional embodiment, assembling, based on the assigned confidence scores, the candidate key from respective index values includes selecting the set of index values having the highest confidence values. In at least one such embodiment, selecting the set of index values having the highest confidence scores includes calculating a joint confidence value. In another at least one such embodiment, the submitted set of selected index values includes an index value assigned the highest confidence score.

[0183] In at least one second additional embodiment, the method further includes issuing a request for presentation of a fingerprint for reading. In at least one such embodiment, wherein the obtaining of the plurality of fingerprint readings of the user occurs after issuing the request for presentation of the fingerprint for reading.

[0184] A third additional embodiment takes the form of a method that includes receiving a plurality of captured biometric values. The method also includes obtaining, for each captured biometric value, a corresponding set of stored biometric values. The method also includes determining, for each of the biometric values of the corresponding set of stored biometric values, a match-confidence value. The method also includes identifying, for each of the captured biometric values, at least one matching stored biometric value from the corresponding set of stored biometric values, the at least one matching stored biometric value being associated with a respective partial key. The method also includes generating a full key based on the plurality of partial keys and the match-confidence values. [0185] In at least one third additional embodiment, the method further includes assigning each determined match-confidence value to a corresponding index.

[0186] In at least one third additional embodiment the method further includes calculating a joint confidence value of a subset of matched-confidence values. In at least one such embodiment, the full key based on the plurality of partial keys and the match-confidence values is further based on the calculated joint confidence value.

[0187] A fourth additional embodiment takes the form of a method that includes receiving a plurality of biometric targets. The method also includes for each biometric target of the received plurality of biometric targets: sending a portion of information derived from the biometric targets; receiving a plurality of potential matches for the biometric target, the plurality of potential matches being selected by a server based on the sent portion of information; and determining an index value associated with the one of the received plurality of potential matches that best matches the biometric target and the confidence level. The method also includes attempting to determine a key based at least upon the plurality of determined matched index values associated with the best match from the plurality of potential matches for the plurality of biometric targets. The method also includes requesting from a user, upon failure to determine a key based on the plurality of determined matched index values, one or more biometric targets for the entries with the lowest confidence level.

[0188] A fifth additional embodiment takes the form of a method that includes obtaining a plurality of fingerprint readings of a user. The method also includes receiving a set of index values selected based on a confidence score resulting from a comparison of each of the obtained fingerprint readings to at least one of a plurality of stored fingerprint templates. The method also includes assembling a key from the received set of index values. The method also includes outputting the key.

[0189] A sixth additional embodiment takes the form of a method that includes obtaining a plurality of fingerprint readings of a user. The method also includes for each obtained fingerprint reading of the user, assigning a confidence score to an index value corresponding to each fingerprint template of a set of stored user-specific fingerprint templates, the assigning of the confidence score to the index value being based on a comparison of each fingerprint template in the set to the corresponding obtained fingerprint reading. The method also includes assembling, based on at least one of the assigned confidence scores, a candidate key from at least one index value of a corresponding stored user-specific fingerprint template. The method also includes attempting to validate the assembled candidate key. The method also includes outputting a validated key if the assembled candidate key is validated.

[0190] A seventh additional embodiment takes the form of a method that includes receiving a plurality of captured biometric readings. The method also includes accessing a plurality of stored biometric readings. The method also includes for a captured biometric reading of the plurality of captured biometric readings: obtaining a plurality of index -value confidence-score pairs, each index-value confidence-score pair being based on a comparison of the captured biometric reading to a respective stored biometric value of the plurality of stored biometric values, and identifying an index value from the plurality of index -value confidence-score pairs based on a corresponding confidence-score. The method also includes selecting a set of index values including the identified index value. The method also includes generating a key based on the selected set of index values.

[0191] An eighth additional embodiment takes the form of a method that includes receiving a request to register a user. The method also includes randomly generating a key value. The method also includes generating share values from the randomly generated key value. The method also includes receiving a set of data sources from a user device. The method also includes responsively storing the set of data sources and the set of share values using common index mapping data.

[0192] In at least one eighth additional embodiment, the randomly generated key value is a polynomial.

[0193] In at least one eighth additional embodiment, the generated share values are evaluated evaluations of a polynomial.

[0194] In at least one eighth additional embodiment, the generated share values represent evaluations of a polynomial on distinct inputs. In at least one such embodiment, the polynomial is a univariate polynomial.

[0195] In at least one eighth additional embodiment, the set of data sources and the set of share values are stored in databases remote from each other.

[0196] In at least one eighth additional embodiment, the data sources are biometric values.

[0197] In at least one eighth additional embodiment, the data sources are MAC address values.

[0198] A ninth additional embodiment takes the form of a method that includes receiving biometric values in response to a key reconstruction request. The method also includes submitting the received biometric values to a biometric matching system. The method also includes receiving encoded share values of matching biometric templates, the encoded share values having respective index values. The method also includes retrieving share values from a key share database using the respective index values. The method also includes from the encoded share values, reconstructing a key corresponding to the key reconstruction request.

[0199] In at least one ninth additional embodiment, the reconstructing the key from the encoded share values uses Reed-Solomon decoding.

[0200] A tenth additional embodiment takes the form of a method that includes receiving a set of indices corresponding to matched biometric values based on a request to decrypt encrypted information. The method also includes forming a key based on the indices and a helper value. The method also includes decrypting the encrypted information with the key.

[0201] An eleventh additional embodiment takes the form of a method that includes receiving a plurality of captured biometric values. The method also includes obtaining, for each captured biometric value, a corresponding set of n stored biometric values. The method also includes identifying, for a given captured biometric value, at least one matching stored biometric value from the corresponding set of n stored biometric values, the at least one matching stored biometric value being associated with a respective partial key. The method also includes generating a full key based on the plurality of partial keys.

[0202] In at least one eleventh additional embodiment, identifying the matching stored biometric value comprises using a matching algorithm to compare the captured biometric values to the set of n stored biometric values.

[0203] In at least one eleventh additional embodiment, the plurality of captured biometric values is received from a client device. In at least one such embodiment, the client device is a smartphone. In another at least one such embodiment, the client device is a tablet computer. In another at least one such embodiment, the client device is a laptop computer. In another at least one such embodiment, the client device is a head-mounted display (HMD). In another at least one such embodiment, the captured biometric values are captured via sensors disposed on the client device

[0204] In at least one eleventh additional embodiment, the corresponding sets of n stored biometric values are obtained from a database. In at least one such embodiment, the database comprises stored biometric values for a plurality of users.

[0205] In at least one eleventh additional embodiment, at least one captured biometric value is associated with a fingerprint. [0206] In at least one eleventh additional embodiment, at least one captured biometric value is associated with an iriscode.

[0207] In at least one eleventh additional embodiment, the method further includes outputting an error code if the given captured biometric value does not match any of the corresponding set of n stored biometric values.

[0208] In at least one eleventh additional embodiment, the full key is generated by concatenating the plurality of partial keys.

[0209] In at least one eleventh additional embodiment, the full key is generated using fuzzy extraction.

[0210] In at least one eleventh additional embodiment, the set of n stored biometric values comprises biometric values corresponding to other users.

[0211] In at least one eleventh additional embodiment, the corresponding sets of n stored biometric values are obtained according to a user-index associated with the given captured biometric value.

[0212] In at least one eleventh additional embodiment, the at least one matching stored biometric value has a partial-key index associated with it. In at least one such embodiment, the partial-key index is the respective partial key.

[0213] In at least one eleventh additional embodiment, the method further includes outputting at least one confidence value associated with a partial key.

[0214] In at least one eleventh additional embodiment, identifying the corresponding stored biometric value comprises using a closest-match algorithm.

[0215] An twelfth additional embodiment takes the form of an apparatus that includes a biometric-to-key conversion module configured to: receive a plurality of biometric measurements and a respective set of biometric templates for each biometric measurement; and generate a plurality of partial keys based on a closest match algorithm comparing each biometric measurement with the respective set of biometric templates to identify a closest-match biometric template.

[0216] In at least one twelfth additional embodiment, at least one partial key is generated for each biometric measurement in the plurality of biometric measurements. [0217] In at least one twelfth additional embodiment, each partial key is represented as an index of the closest-match biometric template.

[0218] In at least one twelfth additional embodiment, at least one biometric measurement in the plurality of biometric measurements is received via a biometric intake interface. In at least one such embodiment, at least one biometric measurement in the plurality of biometric measurements is received via a biometric intake interface. In another at least one such embodiment, the biometric intake interface comprises a fingerprint scanner. In another at least one such embodiment, the biometric intake interface comprises a retinal scanner.

[0219] In at least one twelfth additional embodiment, the partial keys have low entropy.

[0220] In at least one twelfth additional embodiment, the apparatus further includes a key assembly (KA) module configured to generate a full key based on the plurality of partial keys. In at least one such embodiment, the KA module is configured to generate the full key by concatenating the plurality of partial keys. In another at least one such embodiment, the full key is used as a cryptographic key. In another at least one such embodiment, the full key is used in an authentication process for receiving user-specific credentials. In another at least one such embodiment, the KA sends a device-deauthorization command upon generating the full key.

[0221] A thirteenth additional embodiment takes the form of a method that includes receiving a full-key comprising a set of partial keys. The method also includes determining that a subset of the partial keys are valid in an authentication attempt. The method also includes determining that the full-key is invalid based on the authentication attempt. The method also includes issuing a breach warning.

[0222] In at least one thirteenth additional embodiment, the valid subset of partial keys is a number of valid partial keys above a given threshold. In at least one such embodiment, the given threshold z is z =floor(q/2) + 1, wherein q is a positive integer. In one such at least one such embodiment, wherein q represents a number of partial keys in the set of partial keys. In another one such at least one such embodiment, wherein q is a tunable parameter.

[0223] A fourteenth additional embodiment takes the form of a method for deriving and recovering a key from biometric information. The method includes receiving a plurality of biometric targets. The method also includes for a given biometric target of the received plurality biometric targets: sending a portion of information derived from the given biometric target; receiving a plurality of potential matches for the given biometric target, the potential matches selected by the server based on the sent portion of information; and determining an index value associated with one of the received plurality of potential matches that best matches the given biometric target. The method also includes determining a key based at least upon the plurality of determined matched index values associated with the best match from the plurality of potential matches for the plurality of biometric targets.

[0224] In at least one fourteenth additional embodiment, the key is determined by concatenating the plurality of determined match index values.

[0225] In at least one fourteenth additional embodiment, at least one biometric target comprises a fingerprint.

[0226] In at least one fourteenth additional embodiment, at least one biometric target comprises an iriscode.

[0227] In at least one fourteenth additional embodiment, at least one biometric target comprises retinal information.

[0228] In at least one fourteenth additional embodiment, at least one biometric target comprises a 3D depth projection of a user's face.

[0229] In at least one fourteenth additional embodiment, the plurality of potential matches are received from a database. In at least one such embodiment, the plurality of potential matches comprises biometric target information for a plurality of other users.

[0230] In the present disclosure, various elements of one or more of the described embodiments are referred to as modules that carry out (i.e., perform, execute, and the like) various functions described herein. As the term "module" is used herein, each described module includes necessary hardware (e.g., one or more processors, microprocessors, microcontrollers, microchips, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), memory devices, and/or one or more of any other type or types of devices and/or components deemed suitable by those of skill in the relevant art in a given context and/or for a given implementation. Each described module also includes or at least has access to any necessary instructions executable for carrying out the one or more functions described as being carried out by the particular module, where those instructions could take the form of or at least include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, stored in a non-transitory computer-readable medium deemed suitable by those of skill in the relevant art. [0231] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is claimed is:

1. A method comprising: receiving a set of multiple presented biometric values; identifying, for each presented biometric value, a matching stored biometric value, the matching stored biometric value being mapped to a partial cryptographic key; retrieving a key from at least the partial cryptographic keys; and outputting the retrieved cryptographic key for use in at least one cryptographic function.

2. The method of claim 1, wherein identifying, for each presented biometric value, the matching stored biometric value comprises comparing the corresponding presented biometric value to at least one of a set of one or more stored biometric values that includes the matching stored biometric value, the matching stored biometric value being the closest match of the set based on the comparison.

3. The method of any of the claims 1 and 2, wherein retrieving the cryptographic key comprises constructing the retrieved cryptographic key as a combination of the partial cryptographic keys with a helper value.

4. The method of any of the claims 1-3, further comprising using the retrieved cryptographic key in at least one of an authentication attempt or a decryption attempt.

5. The method of any of the claims 1-4, further comprising generating a check value of the retrieved cryptographic key and determining if the retrieved cryptographic key is valid based on the check value.

6. The method of claim 5, wherein generating the check value of the retrieved cryptographic key comprises using a hash function.

7. The method of any of the claims 1-6, further comprising validating the retrieved cryptographic key.

8. The method of any of the claims 1-7, further comprising outputting an authorization indication if the retrieved cryptographic key is validated.

9. The method of any of the claims 1-5, further comprising encountering a

cryptographic-key-recovery failure, and responsively requesting and receiving one or more represented biometric values.

10. The method of any of the claims 1-9, wherein identifying, for each presented biometric value, the matching stored biometric value is based at least in part on a confidence score obtained for the corresponding matching stored biometric value.

11. The method of any of the claims 1-10, wherein each matching stored biometric value being mapped to the corresponding partial cryptographic key comprises each matching stored biometric value having an index associated with the corresponding partial cryptographic key.

12. The method of claim 11, wherein the index associated with the corresponding partial cryptographic key is the corresponding partial cryptographic key.

13. The method of claim 11, wherein the index associated with the corresponding partial cryptographic key corresponds to an index at which to retrieve the corresponding partial cryptographic key.

14. The method of any of the claims 1-5 and 9-13, further comprising: based on an indication that the retrieved cryptographic key is not valid, identifying, for at least one presented biometric value of the set of multiple presented biometric values, a different matching stored biometric value, the different matching stored biometric value being mapped to a different partial cryptographic key; retrieving a different cryptographic key from at least the different partial cryptographic key; and outputting the different cryptographic key for use in at least one cryptographic function.

15. An apparatus comprising: a key retrieval system configured to: receive a set of multiple presented biometric values; identify, for each presented biometric value, a matching stored biometric value, the matching stored biometric value being mapped to a partial cryptographic key; retrieve a cryptographic key from at least the partial cryptographic keys; and output the retrieved cryptographic key for use in at least one cryptographic function.