Enhancing Biometric Authentication Security Using Multiple Devices

Abstract

Systems, methods, and devices of a first device that uses biometric information to authenticate a user to a second device are described herein. A method includes storing, by the first device, a first key share of a private key and a first template share of a biometric template of the user. The second device stores a public key, and one or more other devices of the user store other key shares and other template shares. The first device receives a challenge message from the second device, measures a biometric characteristic of the user to obtain a measurement vector, and sends the measurement vector and the challenge message to the other devices. The first device receives partial computations generated using the corresponding template shares, key shares, and the challenge message from the other devices, uses the partial computations to generate a signature for the challenge message, and sends the signature to the second device.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 741,431, filed on October 4, 2018, entitled "Leveraging Multiple Devices To Enhance Security Of Biometric Authentication", which is incorporated herein by reference in its entirety for all purposes. Background Art

[0003] User authentication is a key component of today's Internet applications. A user logs into an email application to send / receive emails and increasingly enables a second authentication factor for other applications; visits a bank website to check balances and perform transactions; and goes to a payment application to transfer money between family and friends. User authentication is also a component of any enterprise access control mechanism that manages access to sensitive data, services, and resources.

[0004] For nearly three decades, password - based authentication has been the dominant method for authenticating users, relying on "something the user knows". However, this method may have security and usability issues. First, in password - based authentication, the server stores the function of all passwords and may thus be vulnerable to being breached and suffering from offline dictionary attacks. In fact, large - scale password breaches are extremely common in natural scenarios. Additionally, since an attacker only needs to capture the password, which serves as a permanent secret credential, to impersonate a user, password - based authentication is more prone to online fraud.

[0005] Passwords can also pose challenging usability problems. High - entropy passwords are difficult to remember, while low - entropy passwords offer little security, and studies have shown that introducing complex restrictions on password selection may be counterproductive. Especially on mobile and Internet - of - Things devices that dominate users' Internet activities, passwords can also be inconvenient and slow to enter.

[0006] Numerous efforts are underway in the industry to address some of these problems. For example, "unique" biometric traits such as fingerprints (e.g., the fingerprint of Google Pixel [1]), face scans (e.g., Face - ID used in Apple iPhone [2]), and iris scans (e.g., in Samsung Galaxy phones) are increasingly popular first or second - factor authentication mechanisms for logging into devices, making payments, and identifying numerous applications on consumer devices. Research has shown that biometric data is more user - friendly, especially on mobile devices, as users may not have to remember or enter any secret information.

[0007] In addition, the industry is moving away from transmitting or storing permanent user credentials / secrets on the server side. This can significantly reduce the likelihood of scalable attacks such as server breaches and online fraud. For example, biometric templates and measurements can be stored and processed on the client side, where biometric matching also takes place. A successful match then unlocks a private signature key for a digital signature scheme (i.e., a public key credential) that is used to generate tokens for various information such as new challenges, application origin, and certain user information. Only a one-time usable digital signature is transmitted to the server that stores and uses a public verification key to verify the token and identify the user.

[0008] This is the approach taken by the FIDO Alliance [3], the world's largest industry-wide effort to enable an interoperable ecosystem of hardware, mobile, and biometric data-based authenticators that can be used by enterprises and service providers. The framework has also been widely adopted by major Internet players and is embedded in all browser implementations in the form of the W3C standard WebAuthn API, such as the latest versions of Chrome, Firefox, and Edge.

[0009] In the case of storing biometric data and private keys on a client device, the main challenge lies in securely protecting them. This is particularly crucial for biometric data because, unlike passwords, biometric data is not replaceable. The safest way to do this is to rely on hardware solutions such as secure enclaves and trusted execution environments that provide physical and logical separation between various applications and secrets. However, hardware solutions are not always available on the device (e.g., not all mobile phones or IoT devices are equipped with a secure element), or large-scale support can be costly. In addition, they offer very little programmability for developers and innovators. For example, programming a new biometric authentication solution into a secure element requires the support of all relevant parties such as OEMs and OS developers.

[0010] Software-based solutions, such as white-box cryptography, are typically based on ad-hoc techniques that are regularly cracked. The provably secure alternative, i.e., cryptographic obfuscation, is extremely inefficient and the relevant community has no confidence in the mathematical basis of the alternative. An alternative approach is to apply the "salting and hashing" technique commonly used to protect passwords to biometric templates and then store them on the client device. The original salting and hashing solution may fail because biometric matching is typically a fuzzy match that checks whether the distance between two vectors is above a threshold.

[0011] A better way to implement the hashing and salting methods is by means of a powerful primitive called a fuzzy extractor [4]. Unfortunately, this is still vulnerable to offline dictionary attacks on biometrics (trying different biometric measurements until one is found that generates the correct public key), and does not solve the problem of protecting the reconstructed signature key in memory during each authentication session. In addition, existing fuzzy extractor solutions do not support a wide range of distance metrics (such as cosine similarity, Euclidean distance, etc.) and the necessary accuracy levels required for current practical biometric matching.

[0012] Embodiments of the present disclosure solve these problems and other problems both individually and jointly. Summary of the Invention

[0013] Some embodiments of the present disclosure relate to a method for a first electronic device to authenticate a user to a second electronic device using biometric information. The first electronic device may store a first key share of a private key, where the second electronic device stores a public key associated with the private key, and where one or more other electronic devices of the user store other key shares of the private key. The first device may store a first template share of the user's biometric template, where the one or more other electronic devices of the user store other template shares of the biometric template. When the first device receives a challenge message from the second electronic device, the first device may measure a set of biometric characteristics of the user via a biometric sensor to obtain a measurement vector consisting of measured values of the set of biometric characteristics, where the biometric template includes a template vector consisting of measured values of the set of biometric characteristics previously measured from the user. The first device may send the measurement vector and the challenge message to the one or more other electronic devices. The first device may generate a first partial calculation using the first template share, the first key share, and the challenge message, and receive at least T other partial calculations from the one or more other electronic devices, where each of the at least T other partial calculations is generated using a corresponding template share, a corresponding key share, and the challenge message. The first device may generate a signature of the challenge message using the first partial calculation and the at least T other partial calculations, and send the signature to the second electronic device.

[0014] Some embodiments of the present invention relate to generating partial calculations by a specific distance measure, while another embodiment relates to generating partial calculations by any suitable distance measure.

[0015] Other embodiments of the present invention relate to systems and computer-readable media associated with the methods described above.

[0016] These and other embodiments of the invention are described in further detail below with reference to the accompanying drawings and the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1A and 1B illustrate an overview of the FIDO Universal Authentication Framework process.

[0018] Figure 2 illustrate an advanced device registration process according to some embodiments.

[0019] Figure 3 illustrate an advanced device authentication process according to some embodiments.

[0020] Figure 4 illustrate a general flowchart for fuzzy threshold signature generation according to some embodiments.

[0021] Figure 5 illustrate a functional

[0022] Figure 6 illustrate a circuit according to an embodiment of the present invention.

[0023] Figure 7 illustrate another circuit according to an embodiment of the present invention.

[0024] Figure 8 illustrate a block diagram of an example computer system that can be used in conjunction with the systems and methods according to embodiments of the present invention. DETAILED DESCRIPTION

[0025] Embodiments of the present disclosure may be motivated by the fact that most users own and carry multiple devices, such as their laptop computers, smart phones, and smart watches, and there are other Internet of Things devices, such as their smart TVs or smart home appliances, in the vicinity during authentication. Embodiments provide a new framework for client-side biometric-based authentication that aims to distribute biometric templates and secret signature keys among multiple devices that jointly perform biometric matching and signature generation, but never reconstruct a template or signature key on a single device. This framework may be referred to as fuzzy threshold token generation (FTTG). FTTG can also be used to protect biometric information on the server side by distributing biometric information in a sufficiently distributed manner among multiple servers that perform matching and token generation (e.g., for single sign-on authentication tokens).

[0026] We initiate a formal study of FTTG and introduce some specific protocols that are secure within the framework. In the protocol according to the embodiment, during a one-time registration phase, both the template and the signature key are distributed among n devices, and any t of these devices can generate a token. The exact values of n and t are parameters of the scheme and are different in different protocols. Then, during each authentication session, the initiating device obtains biometric measurements and exchanges a constant number of messages with t - 1 other devices in order to verify that the biometric measurements are close enough to the secret - shared template relative to some distance metric, and if so, obtains a token on a message chosen by the initiator, which can also be referred to as a digital signature.

[0027] We formally define a fuzzy - threshold token - generation scheme. We provide a unified definition that fully embodies the privacy of biometric data and the unforgeability of tokens against malicious adversaries in a distributed environment. Our definition follows the real - ideal paradigm, but for efficiency and simplicity, an independent scenario can be used.

[0028] We propose a four - round protocol based on any distance function of any two - round UC - secure multi - party computation protocol, which can use a broadcast channel (e.g., [5, 6, 7, 8, 9]). This protocol is applicable to any n and t (≤n) and can tolerate up to t - 1 malicious corruptions. It should be noted that the general application of a constant - round MPC protocol may not satisfy the following important consideration: each contacting party only needs to exchange messages with a single initiating party. This protocol is a feasibility result because the resulting protocol is not a black - box. To obtain a protocol with specific efficiency, embodiments can handle the most popular distance functions for biometric authentication, including the Hamming distance (for iris scans), cosine similarity, and Euclidean distance (both for face recognition).

[0029] For cosine similarity, the embodiment can include a very efficient four - round protocol that supports any n with threshold t = 3 and is secure against the corruption of one party. The protocol can combine techniques such as an additive homomorphic encryption (AHE) scheme and associated NIZK with garbled - circuit techniques to obtain a hybrid protocol, where arithmetic operations (e.g., inner product) are performed using AHE, and non - arithmetic operations (e.g., comparison) are performed in small garbled circuits. The same construction can be easily extended to the construction for Euclidean distance.

[0030] I. Introduction

[0031] A. FIDO Universal Authentication Framework

[0032] Now let us study the FIDO Alliance architecture [3] in more depth, which proposes a way to authenticate a device to an authentication server. Figure 1AShows a high-level flowchart for typical device registration.

[0033] In step 102, the user device 110 may generate a public key and a secret key for an asymmetric encryption scheme. Alternatively, the public key and the secret key may be pre-provisioned to the user device 110.

[0034] In step 104, the user's device 110 may send the public key to the authentication server 140. The authentication server 140 may store the user's public key and register the device. The user's device 110 may securely store the secret key, for example, on a hardware security module. The user device 110 may use additional protection to safeguard the secret key, such as using previously entered biometric data (e.g., the user's fingerprint, the user's facial scan)

[0035] Figure 1B Shows a high-level flowchart for subsequent authentication of the device for registration. When the user's device 110 attempts to access a secure or protected resource, a protocol may be initiated. For example, the authentication server 140 may control access to a secure database. As another example, the authentication server 140 may authenticate the user before initiating a transaction.

[0036] In step 106, the authentication server 140 may send a challenge to the user device 110. The challenge may be a message and may be sent in response to an access attempt initiated by the user device 110.

[0037] In step 108, the user's device 110 may sign the challenge using the secret key and send the signed challenge back to the authentication server 140. For example, the user device 110 may sign the challenge by encrypting the challenge message with the secret key. As another example, the user device 110 may generate a password that includes the information in the challenge and the secret key. The authentication server 140 may use the previously provided public key to verify the challenge. For example, the authentication server 140 may use the public key to decrypt the signed message and determine whether the decrypted message matches the challenge. If the signature is valid, the user may be allowed access to the resource.

[0038] The user can make this process more secure by using biometrics. During the registration phase, the user may input biometric data into the user device 110. For example, the user may use the camera of the user device 110 to take a picture of the user's face. A biometric template (e.g., facial scan) may be extracted from the biometric data and "securely" stored inside the user device 110. At the same time, a secret key / public key pair may be generated. The public key may communicate with the authentication server 140, while the key is securely stored in the user device 110. The secret key is actually "locked" with the template. Later, during login, a candidate template is used to unlock the secret key, and then the secret key may be used in the standard identification protocol.

[0039] The FIDO specification emphasizes that approximate matching occurs "securely" inside the device during login. A commonly used instantiation method is to use a secure element (e.g., Apple iPhone [2]): Templates are always stored inside a secure element (SE) (e.g., a hardware security module) together with other sensitive data. When an input candidate template is provided, approximate matching is performed inside the SE. However, using an SE has many drawbacks: SEs are typically expensive, platform-specific, provide limited programmability, and are not easily updated (since updates may require changing the hardware). In addition, they are vulnerable to side-channel attacks, which can be performed on (e.g.) a stolen device. Therefore, it is very important to provide an efficient, provably secure, flexible, and pure-software solution.

[0040] B. Security Considerations

[0041] There are certain security constraints associated with the present invention. Biometric templates should never be fully reconstructed such that if any device is hacked, the template is not revealed. For similar reasons, secret keys should also not be fully reconstructed. Distributed matching should work as long as more than a certain threshold of devices in the network are not hacked.

[0042] The assisting devices should also not learn whether the biometric match was successful. This increases security because if other devices do not learn the result of the biometric match, they may not be able to leak information or have information to leak. For example, if one of the other devices is hacked, a malicious party will not be able to use information about the biometric match. The assisting devices also do not learn whether signature generation was successful. For example, if a device has been hacked but can still participate in authentication, a hacker will not be able to know whether the information it has about the biometric template or secret share is accurate or valid.

[0043] It is important to note that there is no need for the other participating devices to communicate with each other or even know about each other (all messages are exchanged between the initiating device and the other participants). In a typical usage scenario, one or two main user devices (e.g., a laptop or a smartphone) act as the initiating device, and all other devices are only paired / connected to the main device and may not even know that other devices exist in the system. This makes the design of an efficient, constant-round FTTG protocol significantly more challenging. We assume that the connected devices have established a point-to-point authentication channel (but not a broadcast channel).

[0044] C. Overview

[0045] 1. Device Registration

[0046] Figure 2 Shows an overall overview of the device registration process using distributed biometrics according to an embodiment.

[0047] In step 202, user 205 may input biometric measurements into the primary user device 215. Biometric sensors of the primary user device 215 (e.g., cameras, microphones, fingerprint sensors) are used to measure a set of biometric characteristics of user 205. For example, user 205 may use the camera of the primary user device 215 to take a picture of the user's face for face scanning. Other examples of biometric measurements may include voice recordings, iris scans, and fingerprint scans. The role of the primary device may also be performed by any trusted authorized party, which may not be the user's device. For example, the primary device may be a computer of an authentication system.

[0048] In step 204, the primary user device 215 may generate a public key and a private key for an asymmetric encryption scheme. The primary user device 215 may also use the biometric measurements to create a biometric template. The biometric template may include a template vector, and the template vector may include measured values of the set of biometric characteristics of the user. For example, the primary user device 215 may calculate the distances between the facial features identified in the user's face picture. The calculated distances may include the template vector of the biometric template.

[0049] In step 206, the primary user device 215 may generate shares of the private key and the template, as well as any other parameters that may be required for later authentication. Then, the primary user device 215 may store the first key share of the private key. The user device may also store the first template share of the biometric template.

[0050] In step 208, the primary user device 215 may send the other key shares of the private key, the other template shares of the template, and the other parameters to each of the user's multiple other user devices 225, 235. The user's other devices may include, for example, laptops, smartphones, wearable devices, smart TVs, IoT-connected devices, etc. Figure 2 Two other devices are shown, however, embodiments may include more or fewer devices associated with the primary user device 215. Each of the other user devices 225, 235 may store the key share of the private key, the template share of the template, and the other parameters. The other user devices 225, 235 may or may not store the received information in a secure storage device.

[0051] In step 210, the primary user device 215 may send the public key to the authentication server 245. The authentication server 245 may securely store the public key. The public key may be stored together with the identifier of user 205 and / or the primary user device 215. The primary user device 215 is now registered.

[0052] 2. Device Authentication

[0053] Figure 3 Illustrates an overall overview of device authentication using distributed biometrics when a primary user device 215 attempts to access a secure or protected resource. For example, the primary user device 215 may attempt to access a secure database controlled by an authentication server 245.

[0054] In step 302, the authentication server 245 may send a challenge message to the primary user device 215. The challenge message may be a vector.

[0055] In step 304, the user 205 may input biometric measurements into the primary user device 215. Biometric sensors of the primary user device 215 (e.g., camera, microphone, fingerprint sensor) are used to measure a set of biometric characteristics of the user 205. For example, the user 205 may use the camera of the primary user device 215 to take a picture of the user's face for face scanning. As another example, the user 205 may use the sensor of the primary user device 215 to scan their fingerprint. The primary user device 215 may then generate a measurement vector including measured values of the set of biometric characteristics. For example, the measured values may be calculated distances between the user's facial features.

[0056] In step 306, the primary user device 215 and other user devices 225, 235 may match previously distributed biometric templates with the new biometric measurements. The primary user device 215 may send the measurement vector and the challenge message to the other devices. Each user device 215, 225, 235 may generate a partial calculation using its template share and the measurement vector. For example, an inner product may be calculated between the template share and the measurement vector. In an embodiment, steps 306 and 308 may occur simultaneously.

[0057] In step 308, the primary user device 215 and other user devices 225, 235 may use the key shares of the secret key to sign the challenge message. Each user device 215, 225, 235 may generate a partial computation using the challenge message and the corresponding key share. The partial computation may be, for example, a partial encryption of the challenge message using the corresponding key share. The partial computation may also be generated by the result of the partial computation from the corresponding template share and the measurement vector. After generating each partial computation, each user device 225, 235 may send the partial computation to the primary user device 215. After receiving the partial computations, the primary user device 215 may use the partial computations to generate a signature for the challenge message. The primary user device 215 may need to receive partial computations from a threshold number T of other devices. The first partial computation generated by the primary user device 215 may be one of at least T partial computations. For example, the primary user device 215 may need to receive at least three partial computations and may receive the partial computations from two other devices. The threshold may be lower than the total number of other devices that received the key shares and the template shares, such that a signature can still be generated in the event that one or more of the other devices are compromised.

[0058] In step 310, the primary user device 215 may send the signature to the authentication server 245. The primary user device 215 may also send the challenge message to the authentication server. If a valid signature is generated, the authentication server 245 will be able to verify the signature using the previously provided public key and allow the user to access the resource. If a valid signature is not generated, the device will not be authenticated and the user will not be granted access to the resource.

[0059] II. Technical Overview

[0060] We first briefly describe the concept of the Fuzzy Threshold Token Generation scheme.

[0061] Consider a set of n parties and a distribution on the vector Let Dist denote the distance measure under consideration. First, in the registration phase, the biometric template is sampled and secretly shared among all parties. In addition, the setup of an unforgeable threshold signature scheme is also implemented, and the signing key is a secret shared among the n parties. Subsequently is the setup phase, in which suitable public and secret parameters are sampled by a trusted party and distributed among the n parties. Then, in an online authentication session (or login phase), any party P with an input vector who wishes to generate a token for the message m * can cooperate with any set Interact to generate a token (signature) for message m using a threshold signature scheme. Note that P * obtains the token only when d is parameterized by the scheme. Keep in mind that at this stage, the parties in the set are not allowed to communicate with each other. Specifically, the communication model only involves P * interacting separately with each party in .

[0062] The security definition of the Fuzzy Threshold Token Generation (FTTG) scheme fully embodies two properties: privacy and unforgeability. Informally, privacy means that the long-term secrets, i.e., the biometric template and the signature key of the threshold signature scheme, should be completely hidden from every party in the system. In a preferred embodiment, the online input vector used in each authentication session should be hidden from all parties except the initiator. Unforgeability requires that no party can use the message m and the input vector as the initiator who interacts with at least t other parties does to make to generate a token for any message m without participating in the authentication session. We formalize these two properties through a real-ideal security game against a malicious adversary. The reader is referred to Section V for the detailed definitions, including the discussion of various subtleties involved in the primitives for the formal definitions to achieve meaningful security while still being able to construct an efficient protocol.

[0063] Figure 4 A swimlane flowchart showing a general embodiment for fuzzy threshold signature generation is shown. Figure 4 Can be used to implement authentication using biometric measurements such as one or more fingerprints, eyes, etc.

[0064] In step 402, the first device 405 stores the first share of the private key, the second device 415 stores the public key associated with the private key, and the other devices 425 store the other shares of the private key. The private key and the public key are keys, which can be keys generated by a trusted authority for a secret key encryption scheme. The trusted authority can be the first device. The second device can be an authorization server.

[0065] In step 404, the first device 405 stores the first share of the biometric template, and the other devices 425 store the other shares of the biometric template. The biometric template includes a template vector, which is composed of the measured values of a set of biometric features previously measured from the user of the first device. The biometric template may have been generated by a trusted authority. In some embodiments, the biometric template may not be divided into shares. The first template share and the other template shares may all be the same value and can be an encryption of the biometric template.

[0066] In step 406, the second device 415 sends a challenge message to the first device 405. This message may be sent in response to a request by the first device 405 for authentication to access a certain secure or protected resource. For example, the challenge message may be a challenge message associated with the FIDO Universal Authentication Framework.

[0067] In step 408, the first device 405 obtains biometric measurements from a user of the device. The biometric measurements may be obtained by a biometric sensor of the first device 405. The first device 405 may use the biometric sensor to measure a set of biometric characteristics of the user to obtain a measurement vector composed of measured values of the set of biometric characteristics. For example, the biometric sensor may be a camera that takes a picture of the user's face. The first device may then measure the distances between the facial features identified in the picture to determine the biometric characteristics. In some embodiments, the biometric measurements may be encrypted.

[0068] In step 410, the first device 405 sends the challenge message and the biometric measurements to another device 425. The first device 405 may also send other information or calculations required for the other device 425 to generate a partial calculation. In some embodiments, the biometric measurements may be encrypted by the first device 405 before being sent to the other device 425. In other embodiments, the biometric measurements may not be sent to the other device 425 together with the challenge message.

[0069] In step 412, the first device 405 may use the challenge message, the biometric measurements, and / or a first share of the private key and the template to generate a first partial calculation. The other device 425 may use the challenge message, the biometric measurements, and / or its corresponding key share and corresponding template share to generate other partial calculations. The first device 405 and the other device 425 may also use information provided by a trusted authority, such as the key of a pseudorandom function. The partial calculation may be a calculation to determine whether the template and the measurement value match according to a pre-established distance measure. Therefore, the partial calculation may be a partial distance. The partial distance may be encrypted using an additive homomorphic encryption scheme, which may be a threshold fully homomorphic encryption (TFHE) scheme. TFHE may allow the first device 405 and the other device 425 to use addition and multiplication of the values without decrypting the encrypted values to calculate the partial calculation. The devices may also generate a partial calculation of a token that can be used to generate a signature of the challenge message. In some embodiments, the device may partially decrypt the partial calculation (or the partial distance).

[0070] In step 414, other device 425 sends partial computations to first device 405. First device 405 receives at least T partial computations, where T is the threshold for distributed signature generation. The first partial computation can be one of the at least T partial computations. First device 405 may receive a zero-knowledge proof along with each partial computation. The zero-knowledge proof can be used to verify the at least T partial computations.

[0071] In step 416, first device 405 uses the partial computations to generate a signature (e.g., a token) for the challenge message. For example, first device 405 may evaluate the partial computations to receive partial signatures (e.g., shares of the token), and then may combine the partial signatures to generate a complete signature. In some embodiments, the partial signatures may be encrypted, for example, using an additive homomorphic encryption scheme. First device 405 may add the additively homomorphically encrypted share of the partial distance between the template share and the measurement vector to obtain the total distance between the measurement vector and the template vector. The total distance may be compared with a threshold, and if the total distance is less than the threshold, first device 405 may generate a signature and sign the challenge message. In this way, the generation of the complete token can be related to the success of the biometric computation. In some embodiments, other devices may use zero-knowledge proofs to verify the comparison of the total distance with the threshold. Other devices or first device 405 may also use zero-knowledge proofs to verify the at least T partial computations.

[0072] In some embodiments, to generate the signature, first device 405 may generate a cryptographic program. The cryptographic program may conditionally use a set of keys to generate a signature when the measurement vector is within the threshold of the template vector. For example, if the cosine similarity measure between the measurement vector and the template vector is less than the threshold, the cryptographic program may generate a signature. In some embodiments, the cryptographic program may include a garbled circuit. The garbled circuit may perform the steps of adding the partial distances and comparing the total distance with the template. In some embodiments, first device 405 may input the measurement vector into the garbled circuit, so that the measurement vector can be compared with the template vector without first device 405 sending the measurement vector to other device 425. The cryptographic program may also use the property of additive homomorphic encryption to determine whether the measurement vector is within the threshold of the template vector. In some embodiments, the cryptographic program may use the template shares to reconstruct the biometric template. In some embodiments, the garbled circuit may output a string that can be used to decrypt the partial signature. In some embodiments, the cryptographic program may use the template shares to reconstruct the biometric template in order to compute the distance measure.

[0073] In step 418, first device 405 sends the signed challenge message to second device 415. Second device 415 may use the stored public key to verify the signature on the challenge message. If the signature is valid, first device 405 may be authenticated by second device 415.

[0074] A. General purpose

[0075] We now describe the technique used in the four-round fuzzy threshold token generation scheme, which is applicable to any distance measure and is maliciously secure against an adversary who may corrupt (t - 1) parties.

[0076] Our starting point is the following observation: Assuming that all parties can communicate freely in our model, if we consider the following functional: the initiator P * has an input each party has an input and its corresponding modular share template and signature key, then any r-round maliciously secure multi-party computation (MPC) protocol with a broadcast channel will also directly imply an r-round fuzzy threshold token generation scheme. If and then the functional will output the signature on m to P * party. Recently, several excellent works [5, 6, 7, 8, 9, 11] have shown how to construct a two-round UC-secure MPC protocol using a broadcast channel in the CRS model. However, since the communication model of our FTTG primitive does not allow all parties to interact with each other, our current goal is to simulate the two-round MPC protocol π in our setting.

[0077] For simplicity, we first consider n = t = 3. That is, there are three parties: P 1 , P 2 , P 3 . Consider the case where P 1 is the initiator. Now, in the first round of our FTTG scheme, P 1 sends m to both parties and notifies them of the set they will communicate with involving these two parties. Then, in the second round, we have P 2 and P 3 send their first-round messages of the MPC protocol π. In the third round of our FTTG scheme, P 1 sends its own first-round message of the MPC protocol to both parties. At the same time, P 1 also sends the first-round message of P 2 to P 3 , and vice versa. So now, at the end of the third round of our FTTG scheme, the parties have exchanged their first-round messages of the protocol π.

[0078] Our next observation is that since we only care about P 1 obtaining the output, in the underlying protocol π, only P 1It is necessary to receive messages from every other party in the second round. Thus, in the fourth round of our FTTG scheme, P 2 and P 3 can calculate their second-round messages based on the transcript so far and send the messages to P 1 . This will enable P 1 to calculate the output of protocol π.

[0079] Although the above FTTG scheme is correct, unfortunately, it is not secure. Note that in order to rely on the security of protocol π, we specifically need the following: for any honest P i party, each honest other party receives the same first-round message on its behalf. In addition, the embodiment may also require that all honest parties receive the same message on behalf of the adversary. In our case, since the communication is controlled and guided by P 1 instead of a broadcast channel, if P 1 is compromised while P 2 , P 3 is honest, this need not be the case. More specifically, one of two things may happen: (i) P 1 can forward an incorrect version of P 3 's first-round message of protocol π to P 2 , and vice versa, (ii) P 1 can send different copies of its first-round message of protocol π to P 2 and P 3 .

[0080] The first problem can be easily solved as follows: we simply force P 3 to send a signed copy of its first-round message of protocol π, and the signed copy is also forwarded by P 1 to P 2 . Then, if the signature is verified, P 2 accepts the message as valid. In the setup phase, we can distribute the signature key to P 3 , and distribute the verification key to P 2 . Similarly, we can ensure that the actual first-round message of protocol π of P 2 is forwarded by P 1 to P 3 .

[0081] The solution to the second problem is a bit tricky. The idea is that instead of forcing P 1 to send the same first-round message of protocol π to both parties, we ensure that P 1 learns their second-round messages of protocol π only when it does send the same first-round message of protocol π to both parties. We now describe how to implement this mechanism. We denote msg 2 as the one sent to P2 of P 1 the first-round message of protocol π, and denote msg 3 (possibly different from msg 2 ) as the first-round message of protocol π sent to P 3 of P 1 In the setup phase, we distribute two keys k 2 , k 3 of the pseudorandom function (PRF) to both P 2 , P 3 . Now, in the 4th round of our FTTG scheme, P 3 performs the following: Instead of sending its second-round message of protocol π as before, it encrypts this message using a secret-key encryption scheme with the key being PRF(k 3 , msg 3 ). Then, in the 4th round, in addition to its actual message, P 2 also sends PRF(k 3 , msg 2 ), which will be the correct key used by P 3 to encrypt its second-round message of protocol π only when msg 2 = msg 3 . Similarly, we use the key k 2 to ensure that the second-round message of protocol π of P 2 is revealed to P 3 only when msg 1 = msg 2 .

[0082] By sharing two PRF keys between each pair of parties, the above method naturally extends to any n, k. Then, each party encrypts its second-round message of protocol π with a secret key that is the XOR of all PRF computations. Please refer to Section VII for more details.

[0083] B. Cosine Similarity

[0084] We now describe the techniques used in our four-round efficient FTTG protocol with t = 3 for the cosine similarity distance measure. Our protocol can withstand a malicious adversary that can corrupt at most 1 party. Our construction is very similar to the highly related Euclidean distance function, but we focus on cosine similarity in this section. Remember, for two vectors where denotes the L 2 -norm of the vector). First, we assume that the distribution samples the vector such that Then, instead of checking we will check This is just a syntactic change that allows us to build a more efficient protocol.

[0085] Our starting point is as follows. Assume t = 2. Then the embodiment can use Yao's

[12] two-party semi-honest secure computation protocol to construct a two-round FTTG scheme. In the registration phase, we will secretly share into two parts and give each party one part. The initiator requests the tag corresponding to its share and input (via oblivious transfer), while hard-wiring the other share into the garbled circuit reconstruction Check and if so, output the signature. In this protocol, if we use an oblivious transfer protocol that is maliciously secure in the CRS model, then we have security against a malicious initiator who only evaluates the garbled circuit. However, to achieve malicious security against the garbler, we need expensive zero-knowledge proofs. Now, to establish an efficient protocol to achieve security against a malicious garbler and make the protocol applicable when the threshold t = 3, the idea is to distribute the garbling process between the two parties. That is, consider the initiator P 1 interacts with the parties P 2 and P 3 . Now, P 2 and P 3 can each use the shared randomness generated in the setup phase to generate a garbled circuit, and the evaluation procedure can check whether the two circuits are the same. In the registration phase, P 2 and P 3 both obtain shares and shares of the signature key. It should be noted that since the adversary can corrupt at most one party, this check will ensure that the evaluation procedure can learn whether the garbled circuit was honestly generated. To ensure that the evaluation procedure does not evaluate the two garbled circuits based on different inputs, the garbled circuit can check whether the OT receiver queries made by P 1 to both parties are the same. Although this directly gives a two-round FTTG scheme applicable to the threshold t = 3 and can securely resist a malicious adversary who can corrupt at most one party, the resulting protocol is less efficient. Note that to be applicable to the cosine similarity distance measure, the garbled circuit will have to perform many expensive operations - for vectors of length we have to perform multiplications inside the garbled circuit. Our goal is to establish an efficient protocol that only performs a constant number of operations inside the garbled circuit.

[0086] Our strategy for constructing an efficient protocol is to use additional rounds of communication outside the garbled circuit to share the heavy computations. Specifically, if we can perform the inner product computation outside the garbled circuit first in the first phase of the protocol, the resulting garbled circuit in the second phase will only need to perform a constant number of operations. To achieve this, we utilize an efficient additive homomorphic encryption scheme [14, 15]. In our new protocol, in round 1, the initiator P 1 will send the encryption of.P 1 can compute by itself P 2 and P 3 both respond with the encryption of computed homomorphically using the same shared randomness. Then, P 1 can decrypt this ciphertext and compute Then, the parties can run the garbled-circuit-based protocol as above in rounds 3 and 4 of our FTTG scheme: namely, P 1 requests the labels corresponding to and while the garbled circuit performs the remaining checks as before. Although this protocol is correct and efficient, there are still some problems.

[0087] The first problem is that the inner product is currently leaked to the initiator P 1 , thus violating the privacy of the template . To prevent this, we need to design a mechanism in which no party knows the inner product clearly, while the checks are still performed in the garbled circuit. A natural approach is for P 2 and P 3 to compute the encryption of the result homomorphically using a very efficient secret-key encryption scheme. In our example, a one-time pad might be sufficient. Now, P 1 only learns the encryption of this value, so the inner product is hidden, and the garbled circuit can easily decrypt the one-time pad by combining the secret key hardwired into it.

[0088] The second major challenge is to ensure that the input that P 1 wishes to use to evaluate the garbled circuit is indeed the decrypted output. If not, then P 1 might request the evaluation of the garbled circuit based on an appropriately high input of its choice, thus violating unforgeability. To prevent this attack, P 2 and P 3 use the shared randomness generated in the setup phase to compute We also compute a message authentication code (MAC) y with respect to the value x. We use a simple one-time MAC, which can be computed using linear operations and can thus be accomplished using an additively homomorphic encryption scheme. Now, the garbled circuit also checks that the MAC can be verified correctly, and from the security of the MAC, P 1 cannot change the input between the two phases. Additionally, P 1 can send the encryption in the first round, such that P 2 , P 3 can also compute the MAC based on this, thereby also preventing P 1 from cheating in this part of the computation.

[0089] Another important issue to address is that we need to ensure that P 1 does send a valid well-formed encryption. To do this, we rely on a valid zero-knowledge argument from the literature. We observe that in our final protocol, the garbled circuit only performs a constant number of operations and the protocol is very efficient.

[0090] To further optimize the concrete efficiency of our protocol, as done by Mohasel et al.

[13] , one or both of the two parties P 2 , P 3 can send the entire garbled circuit. The other party can send only the hash of the garbled circuit, and P 1 can check that the hash values are equal.

[0091] III. Prerequisites

[0092] A. Notation

[0093] The notation [j : x] can denote that the value x is private to party j. For a protocol π, we use [j : z′] ← π([i : (x, y)], [j : z], c) to denote that party i has two private inputs x and y; party j has one private input z; all other parties have no private inputs; c is the common public input; and after the execution, only j receives the output z′. x S denotes that each party i ∈ S has the private value x i .

[0094] B. Basic Primitives

[0095] The reader is referred to

[18] for the definitions of threshold linear secret sharing schemes, secret key encryption, oblivious transfer, garbled circuits, non-interactive zero-knowledge proofs, digital signatures, collision-resistant hash functions, and pseudorandom functions. The reader is referred to

[14] for the definition of additive homomorphic encryption schemes, and to

[19] for the definition of circuit privacy. The reader is referred to

[18] for the definition of secure multi-party computation. The reader is referred to Appendix A for the definitions of threshold oblivious pseudorandom functions and robust secret sharing.

[0096] C. Distance Measures

[0097] First, let us recall that the L -norm of a vector 2 is defined as Now, we define the various distance measures used in the embodiments of the present invention. This list is not restrictive, as any suitable distance measure can be used.

[0098] Definition 1 (Hamming Distance) For any two vectors the Hamming distance between them is defined as the number of positions j where

[0099] The Hamming distance statistically measures the number of points at which a vector and a template vector differ. If the Hamming distance between two vectors of length l is at most (l - d), then they can be said to be close, that is, they are equal at at least d positions.

[0100] Definition 2 (Cosine Similarity) For any two vectors the cosine similarity between them is defined as follows:

[0101]

[0102] Cosine similarity uses the inner product of two vectors to determine the cosine of the angle between the vectors. A smaller angle corresponds to more similar vectors. Thus, if the angle is small, the cosine of the angle is large, and if the cosine distance is greater than a established threshold, the vectors are said to match.

[0103] Definition 3 (Euclidean Distance) For any two vectors the Euclidean distance between them is defined as follows:

[0104]

[0105] The Euclidean distance measures the distance between the endpoints of two vectors as points in space. Two vectors with a smaller Euclidean distance are closer. Thus, if the Euclidean distance is below a established threshold, the vectors are said to match.

[0106] D. Threshold Signatures

[0107] We now formally define the notion of a threshold signature generation scheme

[16] and unforgeability.

[0108] Definition 4 (Threshold Signature) Let A threshold signature scheme TS is a tuple of four algorithms (Gen, Sign, Comb, Ver) that satisfies the following correctness conditions.

[0109] · Gen(1 κ , n, t) → (pp, vk, sk n ). This is a randomized key generation algorithm that takes as input n, t, and the security parameter κ, and generates a signature verification key vk, a shared signature key sk n and the public parameters pp. (pp is an implicit input to all the algorithms below.)

[0110] · Sign(sk i , m) := σ i . This is a deterministic signature algorithm that takes as input a signature key share sk i along with the message, and outputs a partial signature σ i .

[0111] · Comb( {σ i} i∈S ) := σ / ⊥. This is a deterministic algorithm that takes as input a set of partial signatures {sk i} i∈S , and outputs a signature σ or ⊥ indicating failure.

[0112] · Ver(vk, (m, σ)) := 1 / 0. This is a deterministic signature verification algorithm that takes as input the verification key vk and a candidate message-signature pair (m, σ), and returns a decision bit (1 for a valid signature, 0 for an invalid signature).

[0113] For all any such that t ≤ n, all (pp, vk, sk κ ) generated by Gen(1 n , n, t), any message m, and any set of size at least t i if σ i = Sign(sk i ), where i ∈ S, then Ver(vk, (m, Comb( {σ i∈S}

[0114] Definition 5 (Unforgeability) If for all t ≤ n and any PPT adversary If the following game outputs 1 with negligible probability (in the security parameter), then the threshold signature scheme TS = (Gen, Sign, Comb, Ver) is unforgeable.

[0115] · Initialization. Run (pp, vk, sk n ) ← Gen(1 κ , n, t). Give pp, vk to Receive from a set of corrupted parties of size at most t - 1 Then give sk C to Define γ := t - |C|. Initialize the list

[0116] · Signature query. When querying (m, i), where return σ i ← Sign(sk i , m). Run this step as many times as desired.

[0117] · Construction of the list. If the number of signature queries for the form (m, i) is at least γ, then insert m into the list L. (This suffices to show that there is enough information to compute a signature on m).

[0118] · Output. Finally, receive the output (m , σ ★ , σ ★ ) from. Return 1 if and only if Ver(vk, (m ★ , σ ★ )) = 1 and ; otherwise, return 0.

[0119] E. Specific Threshold Signature Schemes

[0120] We now describe the threshold signature schemes of Boldyreva

[16] based on the Gap - DDH assumption and of Shoup

[17] based on the RSA assumption. We will use these schemes in Section IX.

[0121] 1. Boldyreva Scheme

[0122] Let be a multiplicative cyclic group of prime order p that supports pairings and in which CDH is hard. Specifically, there exists an efficient algorithm VerDDH(g a , g b , g c , g), for any ​It returns 1 if and only if c = ab mod p, and returns 0 otherwise. Let be a hash function modeled as a random oracle. Let Share be Shamir's secret sharing scheme.

[0123] The threshold signature scheme is as follows:

[0124] · Setup(1 λ , n, t) → ([sk], vk, pp). Sample and obtain (s, s 1 ,..., s n ) ← Setup(n, t, p(0, s)). Let sk i := s i and vk := g s . Give (sk i , pp) to party i.

[0125] · PartEval(sk i , x) → y i . Compute w := H(x), and output h i .

[0126] · Combine({i, y i} i∈S ) := Token / ⊥. If |S| < t then output ⊥. Otherwise parse y i as h i , where i ∈ S, and output

[0127] · Verify(vk, x, Token) := 1 / 0. It returns 1 if and only if VerDDH(H(x), vk, Token, g) =.

[0128] 2. Shoup's scheme

[0129] Let Share be Shamir's secret sharing scheme and let be a hash function modeled as a random oracle.

[0130] The threshold signature scheme is as follows:

[0131] · Setup(1 λ , n, t) → ([sk], vk, pp). Let p′, q′ be two randomly chosen large primes of equal length, and let p = 2p′ + 1 and q = 2q′ + 1. Let N = pq. Randomly choose another large prime e and compute d ≡ e -1mod Φ(N), where is the Euler's totient function. Then (d, d 1 ,..., d n ) ← Share(n, t, Φ(N), (0, d)). Let sk i = d i and vk = (N, e). Let pp = Δ, where Δ = n!. Give (pp, vk, sk i ) to party i.

[0132] · PartEval(sk i , x) → y i . Output

[0133] · Combine({i, y i} i∈S ) =: Token / ⊥. If |S| < t, then output ⊥, otherwise compute where Find integers (a, b) via the extended Euclidean GCD algorithm such that 4Δ 2 a + eb = 1. Then compute Token = z a · H(x) b mod N. Output Token.

[0134] · Verify(vk, x, Token) = 1 / 0. Return 1 if and only if Token e = H(x) mod N.

[0135] F. Zero - Knowledge Argument of Knowledge of Additive Homomorphic Encryption

[0136] In this section, we list several NP - languages for any additive homomorphic encryption scheme, in which we use efficient non - interactive zero - knowledge arguments of knowledge systems.

[0137] First, let (AHE.Setup, AHE.Enc, AHE.Add, AHE.ConstMul, AHE.Dec) be the algorithms of an additive homomorphic encryption scheme. Let pk denote the public key sampled by running the setup algorithm AHE.Setup(1 λ ). Let denote the message space of the encryption scheme.

[0138] 1. NP - languages

[0139] The first NP language proves the knowledge of the plaintext in a given ciphertext. The second NP language proves that given three ciphertexts, where the first two ciphertexts are well-formed and the verifier knows the corresponding plaintexts and the randomness used to encrypt them, the third ciphertext is generated by running the algorithm AHE.ConstMul(·). That is, it proves that the third ciphertext contains the encryption of the product of the messages encrypted in the first two ciphertexts.

[0140] NP language L 1 is characterized by the following relation R 1 .

[0141] Proposition: st = (ct, pk)

[0142] Proof: wit = (x, r)

[0143] R holds if and only if the following 1 (st, wit) = 1:

[0144] -ct = AHE.Enc(pk, x; r).

[0145] NP language L 2 is characterized by the following relation R 2 .

[0146] Let ct 1 = AHE.Enc(pk, x 1 ; r 1 ), ct 2 = AHE.Enc(pk, x 2 ; r 2 ).

[0147] Proposition: st = (ct 1 , ct 2 , ct 3 , pk)

[0148] Proof: wit = (x 1 , r 1 , x 2 , r 2 , r 3 )

[0149] R holds if and only if the following 1 (st, wit) = 1:

[0150] -ct 3 = AHE.ConstMul(pk, ct 1 , x 2 ; r 3 ).

[0151] 2. Paillier encryption scheme.

[0152] Regarding the additive homomorphic encryption scheme of Paillier

[14] , we have efficient NIZK arguments for the above two languages. Formally, we have the following introductory theorem:

[0153] Introductory Theorem 1

[20] Considering the difficulty of the N - th residue assumption, in the random oracle model, there exist non - interactive zero - knowledge arguments for the knowledge of the above two languages.

[0154] The above zero - knowledge arguments are extremely efficient and only represent a constant number of group operations used by the prover and the verifier.

[0155] IV. Fuzzy Threshold Signature Generation

[0156] We introduce the concept of fuzzy threshold token generation (FTTG). An FTTG scheme is defined with respect to a function Dist that computes the distance, for example, between two vectors from the space of on d - dimensional vectors. In the registration phase, the key shares of a threshold signature scheme are generated and templates are selected according to the distribution on Then the shares of the keys and the templates are distributed among n parties. A separate setup algorithm generates some common parameters and some secret information for each party. After the one - time setup is completed, any one of the n parties can initiate a login session with new measurement values If at least t parties participate in the session and are close to the distributed template in terms of the Dist measure then the initiator will obtain a valid signature.

[0157] Definition 6 (Fuzzy Threshold Token Generation). Let and be a probability distribution on the vectors in where Let TS=(Gen, Sign, Comb, Ver) be a threshold signature scheme. An FTTG scheme for the distance measure is given by a tuple (Registration, Setup, SignOn, Verify) that satisfies the correctness properties stated below, where the threshold

[0158] · After inputting the parameters, this algorithm first runs the key generation of the threshold signature scheme (sk [n] , pp, vk)←Gen(1 κ , n, t). Then, it selects random samples Finally, each party i receives​ where is the share. (We will implicitly assume that all the protocols / algorithms below will take pp as input.)

[0159] · Setup() → (pp setup , s 1 ,..., s n ): Setup is an algorithm that outputs some common parameters pp setup and some secret information s for each party (in the algorithms below, pp i will also be an implicit input). setup

[0160] · SignOn is a distributed protocol where the j-th party with input obtains a (private) token τ (or ⊥, indicating failure) for the message m with the help of the parties in the set S through the said protocol. Each party i ∈ S uses its private input in the said protocol and outputs (m, j, S). The j-th party additionally outputs τ / ⊥. Moreover, in this protocol, the j-th party can communicate with each party in the set but the other parties in cannot directly interact with each other.

[0161] · Verify(vk, m, τ) → {0, 1}: Verify is an algorithm that takes the verification key vk, the message m, and the token τ as input, runs the verification algorithm b := Ver(vk, (m, τ)) of the threshold signature scheme, and outputs b.

[0162] Correctness. For all any such that t ≤ n, any threshold signature scheme TS, any any probability distribution over any distance any measurement any m, any such that |S| = t and any j ∈ [n], if (pp setup , s 1 ,..., s n ) ← Setup(), and then when Verifyl(vk, m, out) = 1.

[0163] ​For the FTTG scheme, two natural security considerations can be considered. The first is the privacy of biometric information. During the registration phase, templates are sampled and distributed. Obviously, a subset of the t-1 parties should not obtain any information about the template from their shares. Then, whenever a party performs a new measurement and generates a signature with the help of other parties, no participant should obtain any information about the measurement, not even the proximity of the measurement to the template. We allow the participants to learn the signed message, the identity of the initiator, and the set of all participants. The second natural security consideration is unforgeability. Even if the underlying threshold signature scheme is unforgeable, it is still possible to generate a signature without having measurements that are close enough. The unforgeable FTTG scheme should not allow this situation.

[0164] We propose a unified real-ideal style definition to fully embody these two considerations. In the real world, the adversary parties run sessions of the login protocol with the honest parties, while in the ideal world, they communicate with the functionality This two worlds are both initialized with the help of n, t, an unforgeable threshold signature scheme, the parameter q of the biometric space, the success matching threshold d, the distribution and the sequence of honest parties' measurements The indistinguishability condition defined below must apply to all values of these inputs. Specifically, as long as it is unforgeable, the indistinguishability condition should apply regardless of the threshold signature scheme used during initialization. The distribution on the biometric space can also be arbitrary.

[0165] During the initialization phase, Registration is run in both the real world and the ideal world to generate the signature key and the shares of the template (selected according to ). In the real world, Setup is also run. The common output of Registration and Setup is provided to the adversary The adversary outputs a set of parties C to be compromised and the sequence ((m 1 , j 1 , S 1 ),..., (m h , j h , S h )) which will be used later to initiate a login session from the honest parties (along with ). The secret shares of the compromised parties are given to and the remaining shares are given to the appropriate honest parties. On the other hand, in the ideal world, Select the output of Setup. We will use this later to generate a simulated common reference string. Note, however, that the output of Setup (whether honest or simulated) will be part of the final distribution.

[0166] The evaluation phase in the real world can be one of two types. The adversary can initiate a login session, or can ask an honest party to initiate a session with a previously chosen input. In the ideal world, talks to to run a login session. Similarly, there are two options. If (SignOn-Corrupt,m, j,S) is sent to the functionality (where j has been corrupted), then it can receive the honest parties' signature shares on message m in S, but only if is close enough to . When (SignOn-Honest,sid,i) is sent, waits to see if wants to complete the session. If so, then computes the signature and sends it to the initiating (honest) party.

[0167] An FTTG scheme is secure if the joint distribution of the real-world adversary's view and the honest parties' output is computationally indistinguishable from the joint distribution of the ideal-world adversary's view and the messages the honest parties receive from the functionality.

[0168] Regarding the above definition, there are several points to note. It allows the adversary to choose which parties to corrupt based on the common parameters. It also allows the adversary to run login sessions with arbitrary measurements. This can help the adversary generate signatures when some measurements are close enough. Even if no measurements are close enough, the adversary can still gradually learn the template. Our definition does not allow adaptively choosing the inputs of the sessions initiated by honest parties during the evaluation phase. Thus, the above definition is a stand-alone definition and not a (universally) composable definition. This type of restriction helps us design more efficient protocols and, in some cases, eliminates the need for any trusted setup.

[0169] Definition 7 A fuzzy threshold token generation scheme FG = (Registration, Setup, SignOn, Verify) is secure if for any n, t s.t. t ≤ n, any unforgeable threshold signature scheme TS, any any distance any PPT adversary there exists a PPT simulator such that for any probability distribution over and any sequence of measurements (where h = poly(κ) and ),

[0170]

[0171] where and are and observations in the real world and the ideal world, Out-Real i is the concatenated output of the (honest) Party i in the real world from all login sessions it participates in (plus the parameters given to it during initialization), while Out-Ideal i is the concatenation of all messages obtained by Party i in the ideal world from the functionality as shown in Figure 5 .

[0172] V. Any distance measure

[0173] In this section, we show how to use the broadcast channel as the main technical tool to construct a four-round secure fuzzy threshold token generation protocol using any two-round maliciously secure MPC protocol. Our token generation protocol satisfies Definition 7, is applicable to any n, t, and any distance measure. Formally, we show the following theorem:

[0174] Theorem 1 Assume the existence of threshold signatures, threshold secret sharing, a two-round UC secure MPC protocol in the CRS model that is secure against malicious adversaries corrupting at most (t - 1) parties in the presence of a broadcast channel, secret key encryption, pseudorandom functions, and strongly unforgeable signatures. Then, for any n, t, and any distance measure, there exists a four-round secure fuzzy threshold token generation protocol satisfying Definition 7.

[0175] Note that assuming DDH / LWE / QR / N-th residue [5, 6, 7, 8, 9, 11], such two-round MPC protocols can be constructed. All other primitives can be based on the existence of injective one-way functions.

[0176] Instantiating the primitives used in the above theorem, we obtain the following corollary:

[0177] Corollary 2 Assume the existence of injective one-way functions and A ∈ {DDH / LWE / QR / N-th residue}. Then there exists a four-round secure fuzzy threshold token generation protocol that satisfies Definition 7 for any n, t, any distance measure Dist, and any threshold d.

[0178] A. Construction

[0179] Before describing our construction, we first list some notations and primitives used.

[0180] Let Dist denote the distance function and d denote the threshold distance value for a match. Let the \(n\) parties be denoted by \(P\) 1 、...、\(P\) n respectively. Let \(\lambda\) denote the security parameter. Let denote the distribution from which random vectors are sampled. Assume that the length of the vector is where is a polynomial in \(\lambda\). Each element of this vector is an element of the field \(\mathbb{F}\) of some large prime modulus \(q\).

[0181] Let \(\mathsf{TS}=(\mathsf{TS.Gen},\mathsf{TS.Sign},\mathsf{TS.Combine},\mathsf{TS.Verify})\) be a threshold signature scheme. Let \((\mathsf{SKE.Enc},\mathsf{SKE.Dec})\) denote a secret - key encryption scheme. Let \((\mathsf{Share},\mathsf{Recon})\) be a \((t,n)\) - threshold secret - sharing scheme. Let \((\mathsf{Gen},\mathsf{Sign},\mathsf{Verify})\) be a strongly unforgeable digital signature scheme. Let PRF denote a pseudorandom function.

[0182] Let \(\pi\) be a two - round UC - secure MPC protocol in the CRS model that is secure against malicious adversaries corrupting at most \((t - 1)\) parties in the presence of a broadcast channel. Let \(\pi.\mathsf{Setup}\) denote the algorithm for generating the CRS. Let \((\pi.\mathsf{Round}\) 1 , \(\pi.\mathsf{Round}\) 2 ) denote the algorithms for any party to compute the messages in each of the two rounds, and \(\pi.\mathsf{Out}\) denote the algorithm for computing the final output. Further, let \(\pi.\mathsf{Sim}\) use the algorithms \((\pi.\mathsf{Sim}\) 1 , \(\pi.\mathsf{Sim}\) 2 ) to compute the messages in the first and second rounds respectively. Note that since we are considering a rushing adversary, the algorithm \(\pi.\mathsf{Sim}\) 1 (·) does not require the adversary's input or output. Let \(\pi.\mathsf{Ext}\) denote the extractor that extracts the adversary's input when given the adversary's one - round message input. Let \(\pi.\mathsf{Sim.Setup}\) denote the algorithm that \(\pi.\mathsf{Sim}\) uses to compute the simulated CRS.

[0183] Now we describe the construction of a four - round secure fuzzy threshold token generation protocol \(\pi\) Any for any \(n\) and \(k\).

[0184] 1. Registration

[0185] During the registration phase, the following algorithm is executed by a trusted authority. The trusted authority can be a device that will participate in subsequent biometric matching and signature generation. If the trusted authority may participate in biometric matching and signature generation, it can delete the information it should not have at the end of the registration phase. That is, it should delete the shares corresponding to other devices.

[0186] The trusted authority can sample a random vector from the distribution of biometric data and save it as a biometric template. Then, the trusted authority can use the share generation algorithm to calculate the appropriate shares of the template according to the key sharing algorithm used, the number of devices, the threshold, and the security parameters. TS The public key vk of the threshold signature scheme, the secret key shares TS and other relevant parameters pp can be generated by the threshold generation algorithm. Then, the trusted authority can send the relevant information (e.g., template shares, secret key shares, public key, and other threshold signature parameters) to each device. For example, the i-th device (P i party) can receive

[0187] 2. Setup

[0188] The setup can also be done by the trusted authority. The trusted authority can be the same as the trusted device that has completed the registration. If the trusted authority may participate in biometric matching and signature generation, it can delete the information it should not have at the end of the registration phase. That is, it should delete the shares corresponding to other devices.

[0189] - Generate crs ← π.Setup(1 λ ).

[0190] - For each i ∈ [n], compute (sk i , vk i ) ← Gen(1 λ ).

[0191] - For each i, j ∈ [n], compute as a uniform random string.

[0192] - For each i ∈ [n], give to the P i party.

[0193] First, the trusted authority can use the setup algorithm crs ← π.Setup(1 λ)Generate a common reference string crs for the multi-party computation scheme in use. Generate shares of the secret key and public key for authentication computation. Compute shares of the relevant parameters and secrets for the distributed pseudorandom function. Then, send the relevant information (such as crs and key shares) to each device.

[0194] 3. Login

[0195] In the login phase, consider P * party, which uses the input vector and wants to obtain the message m about the token. P * interacts with other parties in the following four-round protocol. The arrows in the first round can indicate that the message in this round is sent out from P * party.

[0196] - Round 1: (P * →) P * party performs the following operations:

[0197] i. Select a set 1 consisting of t parties from P n ... P For simplicity and without loss of generality, we assume that P * is also part of the set .

[0198] ii. Send i to each party P

[0199] - Round 2: (→p * ) Each party (except P * ) performs the following operations:

[0200] i. Use the input and randomness r i to participate in the execution of protocol π with the parties in the set to compute the circuit C defined in Figure 6 . That is, compute the first-round message msg 1，i ←π·Round 1 (y i ; r i ).

[0201] ii. Compute σ 1，i = Sign(sk i , msg 1，i ) using some randomness.

[0202] iii. Send (msg 1，i , σ 1，i ) to P* Side

[0203] - Round 3: (P * →)P * The side performs the following operations:

[0204] i. Let Trans DiFuz denote the set of messages received in Round 2.

[0205] ii. Use the input and randomness r * to participate in the execution of protocol π with the parties in the set to compute the circuit C defined in Figure 6 . That is, compute the first-round message msg 1，* ←π.Round 1 (y * ; r * ).

[0206] iii. Send (Trans , msg DiFuz , msg 1，* ) to each party

[0207] - Round 4: (→P * ) Each party (except P * ) performs the following operations:

[0208] i. Let Trans DiFuz consist of a set of messages of the form (msg 1，j , σ 1，j ).

[0209] If Verify(vk j , msg 1，j , σ 1，j ) ≠ 1, then output ⊥.

[0210] ii. Let τ 1 denote the transcript of protocol π after Round 1. That is,

[0211] iii. Compute the second-round message msg 2，i ←π.Round 2 (y i , τ 1 ; r i ).

[0212] iv. Let (Trans DiFuz , msg 1，* ) denote the messages received from P *Received message. Compute

[0213] v. Compute ct i = SKE.Enc(ek i , msg 2，i ).

[0214] vi. For each party Compute

[0215] vii. Send to P * .

[0216] - Output Computation: Each party Output In addition, Party P * performs the following operations to generate a token:

[0217] i. For each party Perform the following operations:

[0218] · Compute

[0219] · Compute msg 2，j = SKE.Dec(ek j , ct j ).

[0220] ii. Let τ 2 represent the transcript of protocol π after round 2.

[0221] iii. Compute the output of π as

[0222] iv. Compute

[0223] v. If TS.Verify(vk TS , m, Token), then output the token. Otherwise, output ⊥.

[0224] 4. Token Verification

[0225] Given the verification key vk TS , message m, and token Token, if TS.Verify(vk TS , m, Token) outputs 1, then the token verification algorithm outputs 1.

[0226] The correctness of the protocol follows directly from the correctness of the underlying primitives.

[0227] B. Security Proof

[0228] In this section, we formally prove Theorem 1.

[0229] Consider breaking t * party's adversary where t * < t. Our protocol π Any 's simulator Sim against malicious adversary 's strategy is described as follows. Note that the registration phase first occurs at the end when the simulator obtains the values to be sent to each corrupted party, and each corrupted party then forwards the said values to

[0230] 1. Description of the simulator

[0231] Setup: Sim does the following:

[0232] (a) Generate crs sim ← π.Sim.Setup(1 λ )

[0233] (b) For each i ∈ [n], compute (sk i , vk i ) ← Gen(1 λ )

[0234] (c) For each i, j ∈ [n], compute as a uniform random string.

[0235] (d) For each i ∈ [n], if P i is corrupted, then give to the adversary

[0236] Login phase: Case 1 – Honest party is P *

[0237] Imagine the honest party P * using the input vector u and the message m it wants to obtain the relevant token by interacting with a set of parties . The arrows in the first round can indicate that the message is sent from the simulator in this round. Sim obtains the tuple from the ideal functionality and interacts with the adversary as follows:

[0238] · Round 1: (Sim →) Sim sends to the adversary for each corrupted party

[0239] · Round 2: (→ Sim) On behalf of each corrupted party receive (msg1，i , σ 1，i ).

[0240] · Round 3: (Sim→) Sim performs the following operations:

[0241] (a) For each honest party P in j , compute msg 1，j ← π.Sim 1 (1 λ , P j ) and σ 1，j = Sign(sk j , msg 1，j ).

[0242] (b) Let Trans DiFuz denote the set of tuples of the form (msg 1，i , σ 1，i ) received in Round 2 and computed in the above steps.

[0243] (c) For the honest party P * compute the first-round message of the simulation of protocol π as follows: msg 1，* ← π.Sim 1 (1λ ， P * ).

[0244] (d) Send (Trans DiFuz , msg 1，* ) to the adversary for each corrupted party

[0245] · Round 4: (→Sim) For each corrupted party receive from the adversary

[0246] · Send a message to the functionality : Sim performs the following operations:

[0247] (a) Run π.Sim(·) on the transcript of the underlying protocol π.

[0248] (b) If π.Sim(·) decides that the ideal functionality of protocol π will output and deliver to the honest party P * in our distributed fuzzy security authentication protocol, then Sim also instructs the functionality to do so. Note that to do this, π.Sim(·) may internally use the algorithm π.Ext(·). Basically, this step ensures to Sim that the adversary behaves honestly in the protocol.

[0249] (c) Otherwise, Sim outputs ⊥.

[0250] Login Phase: Case 2 - Malicious Party is P *

[0251] Suppose the malicious party is the initiator P * . Sim and the adversary interact as follows:

[0252] · Round 1: (→Sim) Sim represents each honest party P j and receives from the adversary

[0253] · Round 2: (Sim→) Sim performs the following operations:

[0254] (a) On behalf of each honest party P in j , computes and sends to the adversary the signature of msg 1，j ←π.Sim 1 (1 λ , P j ) and σ 1，j = Sign(sk j , msg 1，j ).

[0255] · Round 3: (→Sim) Sim represents each honest party P j and receives from the adversary the tuple (Trans DiFuz , msg 1，* ).

[0256] · Round 4: (Sim→) Sim performs the following operations:

[0257] (a) On behalf of each honest party P j , performs the following operations:

[0258] i. Let Trans DiFuz consist of a set of messages of the form (msg 1，i , σ 1，i ).

[0259] If Verify(vk i , msg 1，i , σ 1，i ) ≠ 1, then output ⊥.

[0260] ii. Let τ 1 denote the transcript of the protocol π after Round 1. That is,

[0261] (b) Let τ 2 ​Denote τ 1 as a subset corresponding to all messages generated by honest parties.

[0262] (c) If τ 2 is different for all honest parties, output "SpecialAbort".

[0263] (d) If msg 1，* is different for all honest parties, set the variable flag = 0.

[0264] (e) Query the ideal functionality as follows:

[0265] i. Compute

[0266] ii. Query the ideal functionality to receive the output

[0267] (f) On behalf of each honest party P j as compute the second-round message msg 2，j set of the protocol π.

[0268] (g) On behalf of each honest party P j , perform the following operations:

[0269] i. Let (Trans DiFuz , msg 1，* ) denote the message received from the adversary in the third round. Compute

[0270] ii. If flag = 0, then compute where rand is a randomly and uniformly chosen string.

[0271] iii. Otherwise, compute ct j = SKE.Enc(ek j , msg 2，j ).

[0272] iv. For each party compute

[0273] v. Send to the adversary.

[0274] 2. Hybrid

[0275] We now prove that the above simulation strategy is successful against all malicious PPT adversaries. That is, in the real world and the ideal world, the adversary's view and the honest parties' outputs are computationally indistinguishable. We will show this through a series of computationally indistinguishable hybrids, where the first hybrid Hyb 0 corresponds to the real world, and the last hybrid Hyb 4 corresponds to the ideal world.

[0276] 1. Hyb 0 – Real world: In this hybrid, consider the simulator SimHyb that plays the role of the honest parties in the real world.

[0277] 2. Hyb 1 – Special abort: In this hybrid, SimHyb outputs "SpecialAbort", just as Sim did in the 4th round of the simulation strategy in case 2. That is, if all signatures are verified, but the adversary does not send the same transcript of the first round of the protocol π to all honest parties, SimHyb outputs "SpecialAbort".

[0278] 3. Hyb 2 – Simulate MPC messages: In this hybrid, SimHyb does the following:

[0279] - In the setup phase, compute the CRS as crs sim ← π.Sim.Setup(1 λ ).

[0280] - Case 1: Suppose an honest party plays the role of P * , and do:

[0281] * In the 3rd round, on behalf of each honest party, compute the first-round message msg 1 of the protocol π by running the algorithm π.Sim (·), and compute the first-round message msg 1，j on behalf of the P * party. 1，* .

[0282] * Then, instead of P * itself computing the output using the protocol messages, instruct the ideal functionality to deliver the output to P * . That is, execute the "send message to the ideal functionality" step exactly as in the ideal world.

[0283] - Case 2: Suppose the corrupted party plays the role of P * , and do:

[0284] * In the second round, run the algorithm π.Sim as in the ideal world 1 (·) to represent each honest party and compute the first-round message msg of the protocol π 1，j .

[0285] * Interact with the ideal functionality exactly as Sim does in the ideal world. That is, query the ideal functionality about the output of the extractor π.Ext(·) based on the input (τ 1 , crs sim ), and receive the output

[0286] * Represent each honest party P j as and compute the set of second-round messages msg of the protocol π 2，j .

[0287] 4. Hyb 3 – Switch the output of the DPRF in case 2: In this hybrid, assume the corrupted party plays the role of P * , and SimHyb computes the value of the variable flag as the simulator does in the 4th round of the simulation strategy. That is, if the adversary does not send the same first-round message of the protocol π to all honest parties , then SimHyb sets flag = 0. Then, SimHyb represents each honest party P j and performs the following operations:

[0288] - If flag = 1, then compute ct as in Hyb 1 . j .

[0289] - If flag = 0, then compute ct j = SKE.Enc(rand, msg 2，j ), where rand is randomly and uniformly chosen and is no longer used as the output of the DPRF.

[0290] 5. Hyb 4 – Switch the ciphertext in case 2: In this hybrid, assume the corrupted party plays the role of P * , and SimHyb performs the following operations: If flag = 0, then compute as in the ideal world This hybrid corresponds to the ideal world.

[0291] We now prove that each pair of consecutive hybrids is computationally indistinguishable.

[0292] Lemma 1 Assume that the strong unforgeability of the signature scheme Hyb 0 is computationally indistinguishable from Hyb 1 .

[0293] Proof. The only difference between these two hybrids is that in Hyb 1 , SimHyb may output "SpecialAbort". We now prove that SimHyb outputs "SpecialAbort" in Hyb 1 with only negligible probability.

[0294] Suppose not. That is, assume there exists an adversary 1 that can cause SimHyb to output "SpecialAbort" in Hyb with non - negligible probability. Then we will use to construct a contradictory adversary that breaks the strong unforgeability of the signature scheme

[0295] Start by executing the DiFuz protocol interacting with the adversary 1 as in Hyb . For each honest party P j , interacts with the challenged party and obtains the verification key vk j , which is forwarded as part of the DiFuz setup phase to . Then, during the protocol,[[]] forwards the signature queries from to and forwards the responses from to

[0296] Finally, assume causes to output "SpecialAbort" with non - negligible probability. Then it must be the case that for some tuple of the form (msg j , σ 1，j , σ 1，j ), corresponding to the honest party P 1，j the signature σ was not forwarded from but was still successfully verified. Thus, can output the same forged tuple (msg 1，j , σ 1，j ), thereby breaking the strong unforgeability of the signature scheme with non - negligible probability, which is a contradiction.

[0297] Lemma 2 Assume the MPC protocol is secure. Hyb 1 is computationally indistinguishable from Hyb 2 .

[0298] Proof. Suppose there exists an adversary that can distinguish between the two hybrids with non-negligible probability We will use to construct a contradiction that breaks the security of protocol π.

[0299] Start executing the DiFuz protocol that interacts with the adversary and execute protocol π for evaluating the circuit C( ) that interacts with the challenge acceptor Figure 6 ). Now, imagine compromising a set of parties Compromise the same set of parties in protocol π. First, the registration phase of protocol DiFuz occurs. Then receive from the challenge acceptor an honestly generated or simulated string crs. Via set this string as the crs for the setup phase of the DiFuz protocol. The rest of the setup protocol runs exactly the same as in Hyb 0 .

[0300] Case 1: The honest party is P *

[0301] Now, since we are considering a rushing adversary for protocol π, on behalf of each honest party P j , first receive the message msg from the challenge acceptor j . In the third round of its interaction with set msg j to msg 1，j , and then compute the rest of the messages it will send to just as in . On behalf of the compromised parties in receive a set of messages corresponding to protocol π from

[0302] Case 2: The compromised party is P *

[0303] As in the previous case, on behalf of each honest party P j , first receive the message msg from the challenge acceptor j . In its interaction with In the second round of the interaction, set msg j to be the message msg 1，j . Then, in the fourth round, if the signature is verified, the attacker on behalf of will forward the set of messages corresponding to the protocol π received from as its own protocol π messages to Then, on behalf of each honest party P j , receive the message msg from the challenge acceptor as the second-round message of the protocol π j . In the fourth round of its interaction with , set msg j to be the message msg 2，j , and compute the remaining messages it will send to just as in Hyb 1 .

[0304] Note that when the challenge acceptor sends a honestly generated message, the experiment between and exactly corresponds to Hyb 1 , and when the challenge acceptor sends a simulated message, the experiment exactly corresponds to Hyb 2 . Therefore, if can distinguish the two hybrids with non-negligible probability, then can break the security of the scheme π with non-negligible probability using the same guess, which is a contradiction

[0305] Lemma 3 Assume the security of the pseudorandom function. Hyb 2 is computationally indistinguishable from Hyb 3 .

[0306] Proof. Suppose there exists an adversary that can distinguish the two hybrids with non-negligible probability. We will use to construct an adversary

[0307] that breaks the security of the pseudorandom function in the execution of the protocol DiFuz. During the execution of the protocol DiFuz, the adversary interacts with the adversary . For each honest party, also interacts with the challenge acceptor in the PRF security game. For each j, According to Send the PRF key corresponding to the set of attackers (<k), and then forward it to Then, Continue to interact with until the 3rd round, just like in Hyb 1 Now, in the 4th round, assume it calculates the value of the variable flag as 0 (as calculated in Hyb 3 ), then Perform the following operations: For each honest party P j , forward the message msg 1，* received in the 3rd round. Then, set the XOR of the set of responses from to the value ek j used to generate the ciphertext ct j .

[0308] Now note that when the challenge acceptor responds through the set of honest party evaluation PRFs for each honest party j, the interaction between exactly corresponds to Hyb 2 , and when the challenge acceptor responds with a set of uniformly random strings, the interaction between exactly corresponds to Hyb 3 . Therefore, if can distinguish between these two hybrids with non-negligible probability, then can break the pseudorandom property of the PRF scheme with the same guess with non-negligible probability, which is a contradiction.

[0309] Lemma 4 Assuming the semantic security of the secret key encryption scheme, Hyb 3 is computationally indistinguishable from Hyb 4 .

[0310] Proof. Assume there exists an adversary that can distinguish between the two hybrids with non-negligible probability. We will use to construct an adversary

[0311] that breaks the semantic security of the encryption scheme, which is a contradiction. As in Hyb 3 , the adversary interacts with the adversary . Then, on behalf of each honest party P j , before sending its 4th round message, first sends the tuple to the challenge acceptor of the secret key encryption scheme For each honest party, it receives msg using a secretly and uniformly chosen secret key 2，j or encrypted. Then, set this ciphertext as the value ct j , and continue to interact with the adversary as in Hyb 2 . Note that when the challenged party sends the ciphertext of msg 2，j , the experiment between and exactly corresponds to Hyb 3 , and when the challenged party sends the ciphertext of , the experiment exactly corresponds to Hyb 4 . Therefore, if can distinguish these two hybrids with non-negligible probability, then can use the same guess to break the semantic security of the encryption scheme with non-negligible probability, which is a contradiction.

[0312] VI. Any Distance Measure Using Threshold FHE

[0313] In this section, we show how to construct a fuzzy threshold token generation protocol for any distance measure using any FHE scheme with threshold decryption. Our token generation protocol satisfies the definitions in Section III for any n, t and is applicable to any distance measure. Formally, we give the following theorem:

[0314] Theorem 3. Suppose the following exists: FHE with threshold decryption, threshold signature, secret key encryption, and strongly unforgeable digital signature, and there exists a four-round secure fuzzy threshold token generation protocol for any n, t, and any distance measure.

[0315] A. Construction

[0316] Before describing our construction, we first list some notations and primitives used.

[0317] Let Dist denote the distance function taking the template w and the measurement value u as inputs, and let d denote the threshold distance value to represent a match between w and u. Let C be a circuit taking the template w, the measurement value u, and a certain string K as inputs, and outputting K when Dist(w, u) < d, otherwise outputting 0. Let the n parties be denoted by P 1 ,..., P n respectively. Let λ denote the security parameter. Let W denote the distribution from which the random template vector is sampled. Assume the length of the vector is where is a polynomial of λ.

[0318] Let TEHE = (TFHE.Gen, TFHE.Enc, TFHE.PartialDec, TFHE.EvalTFHE.Combine) be a threshold FHE scheme. Let TS = (TS.Gen, TS.Sign, TS.CombineTS.Verify) be a threshold signature scheme. Let SKE = (SKE, Gen, SKE.Enc, SKE.Dec) denote a secret key encryption scheme.

[0319] Let (Gen, Sign, Verify) be a strongly unforgeable digital signature scheme. Let H be a collision-resistant hash function (e.g., modeled as a random oracle).

[0320] We now describe the construction of a four-round secure fuzzy threshold token generation protocol π for any n and k Any-TFHE of.

[0321] 1. Registration

[0322] In the registration phase, the following algorithm can be executed by a trusted authority:

[0323] · Sample a random w from the distribution

[0324] · Compute (pk, sk 1 ,..., sk N ) ← TFHE.Gen(1 λ , n, t)

[0325] · Compute

[0326] · Compute K ← SKE, Gen(1 λ )

[0327] · Compute the ciphertexts

[0328] ct 0 ← TFHE.Enc(pk, w), ct 1 ← TFHE.Enc(pk, K)

[0329] · For each i ∈ [n], do the following:

[0330] (a) Compute sk′ i , vk′ i ← Gen(1 λ )

[0331] (b) Compute K i = H(K, i).

[0332] (c) Give the following to Party i ​​

[0333]

[0334] A trusted authority (e.g., the primary user device) may sample a biometric template w from a biometric measurement distribution In addition to the public parameters pp TS , the verification key vk TS , multiple private key shares for the threshold signature scheme TS and the string K for the secret key encryption scheme SKE, the trusted authority may also compute the public key pk and multiple private key shares sk i for the threshold fully homomorphic encryption scheme TFHE. Using the public key pk, the trusted authority may encrypt the biometric template w to form the ciphertext ct 0 , and encrypt the string K to form the ciphertext ct 1 .

[0335] Then, the trusted authority may compute multiple values for each electronic device i (e.g., the first electronic device and other electronic devices) among the n electronic devices. The trusted authority may compute the secret key share sk′ i and the verification key share vk′ i for the digital signature scheme. The trusted authority may also compute the hash K using the string K and the hash function H i . Then, the trusted authority may send the public key pk, the ciphertext ct i and ct 0 and ct 1 , the verification key shares (vk′ i ,..., vk′ i ), the secret key share sk′ i , the public parameters pp TS , the verification key vk TS , the private key share sk i TS and the hash K i to each electronic device P

[0336] 2. Login Phase

[0337] In the login phase, consider the P * party that uses the input vector u and the message m for which it wants to associate a token. P * interacts with other parties in the following four-round protocol. The arrows in the first round may indicate that in this round, the message is sent from the P * party.

[0338] · Round 1: (P * →) The P * party performs the following operations:

[0339] a) Compute the ciphertext ct * = TFHE.Enc(pk, u).

[0340] b) Select a set S consisting of t parties from P 1 ,..., P n . For simplicity and without loss of generality, we assume that P * is also part of the set S.

[0341] c) Send (ct 1 , m) to each party P * ∈ S.

[0342] · Round 2: (→ P * ) Each party P i ∈ S (except P * ) performs the following operations:

[0343] a) Compute the signature σ′ i = Sign(sk′ i , ct * ).

[0344] b) Send σ′ i to the P * party.

[0345] · Round 3: (P * →) The P * party sends (σ′ 1 ,..., σ′ n ) to each party P i .

[0346] · Round 4: (→ P * ) Each party P i ∈ S (except P * ) performs the following operations:

[0347] a) If there exists an i ∈ [n] such that Verify(vk′ i , ct * , σ′ i ) ≠ 1, then output ⊥.

[0348] b) Otherwise, evaluate the following ciphertext

[0349] ct = TFHE.Eval(pk, C, ct 0 , ct * , ct 1 ),

[0350] and compute the partial decryption of ct as:

[0351] μ i= TFHE.PartialDec(sk i , ct).

[0352] c) Compute TOKEN i = TS.Sign(sk i , m) and

[0353] d) Send to Party P * .

[0354] · Output Computation: Party P * performs the following operations to generate a token:

[0355] a) Recover K = TFHE.Combine(μ 1 ,..., μ n ).

[0356] b) For each i ∈ [n], perform the following operations:

[0357] i. Compute K i = H(K, i).

[0358] ii. Recover

[0359] c) Compute Token ← TS.Combine({Token i}[[]] i∈ S).

[0360] d) If TS.Verify(vk TS , m, Token) = 1, then output Token. Otherwise, output ⊥.

[0361] The first electronic device P * can use the public key pk of the threshold fully homomorphic encryption scheme to encrypt the input vector u (e.g., the biometric measurement vector) to generate the encrypted biometric measurement ciphertext ct * . The first electronic device can send the encrypted biometric measurement value ct * and the message m to each of the other electronic devices. Each of the other electronic devices can use the ciphertext ct * and the secret key share sk′ i to compute the partial signature computation σ′ i . Each electronic device can send the partial signature computation σ′ i to the first electronic device. The first electronic device can send all the partial signature computations (σ′ 1 ,..., σ′ n ) to all the other electronic devices.

[0362] Each of the other electronic devices may use the ciphertext ct * and the received verification key (vk′ 1 ,..., vk′ n ) to verify each partial signature calculation (σ′ 1 ,..., σ′ n ). If any of the partial signature calculations fails to be verified (e.g., Verify(vk′ i , ct * , σ′ i ) ≠ 1), the electronic device may output ⊥, thereby indicating an error. The unverified signature may indicate that one (or more) of the electronic devices did not correctly calculate the partial signature calculation, and thus may be compromised or fraudulent. After verifying the partial signature calculation, each of the other electronic devices may evaluate the ciphertext ct * , ct 0 and ct 1 to generate a new ciphertext ct. Evaluating the ciphertext may include evaluating a circuit C that measures the distance between the calculation template w (in ciphertext ct 0 ) and the measurement value u (in ciphertext ct * ). If the distance measure is less than the threshold d, the circuit C may output a string K (in ciphertext ct 1 ). Then, each of the other electronic devices may calculate a partial decryption μ i of the ciphertext ct. The partial threshold signature token Token i may be generated by each of the other electronic devices using the secret key share sk i and the message m. The ciphertext i may be calculated as a secret key encryption through the partial threshold signature token Token i and the hash K . Then, the partial decryption μ i and the ciphertext may be sent to the first electronic device.

[0363] The first electronic device may homomorphically combine the partial decryptions (μ 1 ,..., μ n ) to recover the string K. Then, the first electronic device may use the string K and the hash function H to calculate the hash K i for each electronic device i, and then use the hash K i to decrypt the secret key encryption ciphertext to recover the partial threshold signature token Token i . Using each received partial threshold signature token Token i, the first electronic device can combine them to calculate the signature token Token. If the first electronic device can verify the token Token and the message m, the first electronic device can output the token Token; otherwise, the first electronic device can output ⊥.

[0364] 3. Token Verification

[0365] Given the verification key vk TS , the message m, and the token Token, if TS.Verify(vk TS , m, Token) outputs 1, the token verification algorithm outputs 1.

[0366] Correctness: The correctness of the protocol directly follows from the correctness of the underlying primitives.

[0367] B. Security Proof

[0368] In this section, we formally prove Theorem 3.

[0369] Consider an adversary A that compromises t * parties, where t * . Regarding our protocol π Any-TFHE , the strategy of the simulator Sim against the adversary A is outlined as follows.

[0370] 1. Description of the Simulator

[0371] Registration Phase: When the simulator Sim receives the first query of the form (“Register″, sid) from party P i , it receives the message (“Register″, sid, P DiFuz ) from the ideal functionality F i and forwards it to the adversary A.

[0372] Login Phase: Case 1 – The honest party is P * : Suppose that in a certain session with id sid, the honest party P * uses the input vector u and the message m that it wants to obtain the relevant token by interacting with the set S, which consists of t parties, some of which may be compromised. Sim obtains the tuple (m, S) from the ideal functionality F DiFuz and interacts with the adversary .

[0373] In the first round of the login phase, ∼ sends the encryption of 0 under the threshold FHE scheme to each malicious party in the set S. Note that this is indistinguishable from the real world in terms of the CPA security of the threshold FHE scheme. In subsequent rounds, it receives information from the adversary A on behalf of the compromised parties on S and sends messages to the compromised parties in the set S.

[0374] Sim also sends a query of the form (“SignOn”, sid, msg, P FTTG to the ideal functionality F i , ) and proceeds as follows:

[0375] - If the ideal functionality F FTTG responds with (“Sign”, sid, msg, P i ,), then Sim selects a signature σ and responds to F i with (“Signature”, msg, sid, P FTTG , σ), and sends (σ, msg,) to the adversary A.

[0376] - On the other hand, if the ideal functionality F FTTG responds with (“SignOn failed”, msg), then the simulator Sim aborts.

[0377] Login phase: Case 2 – Malicious party is P * : Suppose that in some session with id sid, the malicious party P * uses the input vector u and the message m that it wants to obtain the relevant token by interacting with the set S, which consists of t parties, some of which may be compromised. Sim also obtains the tuple (m, S) from the ideal functionality F DiFuz and interacts with the adversary .

[0378] The simulator Sim receives the measurement u from the adversary A on behalf of the compromised party P * and sends a query of the form (“TestPassword”, sid, u, P FTTG ,) to the ideal functionality F. It forwards the corresponding response of F i to the adversary A. FTTG FTTG

[0379] In the first round of the login phase, ~ represents each honest party in the set S receiving a ciphertext under the threshold FHE scheme from the adversary A. In subsequent rounds, it represents the honest parties in S sending messages to the adversary A and receiving messages from the adversary A on behalf of the honest parties in S.

[0380] Sim also sends a query of the form (“SignOn”, sid, msg, P FTTG to the ideal functionality F i , ) and proceeds as follows:

[0381] - If the ideal functionality F FTTG responds with (“Sign”, sid, msg, P i, ) response, the SIM selects the signature σ and responds to F with ("Signature", msg, sid, P i , σ) FTTG , and sends (σ, msg) to the adversary A.

[0382] - On the other hand, if the ideal functionality F FTTG responds with ("SignOn failed", msg), the simulator SIM aborts.

[0383] VII. Cosine Similarity and Euclidean Distance

[0384] In this section, we show how to construct an efficient four-round secure fuzzy threshold token generation protocol for Euclidean distance and cosine similarity distance measures in the random oracle model. Our token generation protocol satisfies Definition 7 for any n with threshold t = 3 and can securely withstand malicious adversaries that may corrupt any party. We first focus on the cosine similarity distance measure. At the end of this section, we also explain how to extend the results to the Euclidean distance.

[0385] We formally show the following theorem:

[0386] Theorem 3 Assume the existence of threshold signatures, threshold secret sharing, two-message oblivious transfer in the CRS model that securely withstands malicious adversaries, garbled circuits, threshold secret sharing schemes, circuit-specific additive homomorphic encryption, secret-key encryption, and non-interactive zero-knowledge arguments for the NP languages L 1 , L 2 defined in Section IV.E, there exists a four-round secure fuzzy threshold token generation protocol that satisfies Definition 7 with respect to the cosine similarity distance function. The protocol is applicable to any n, where the threshold t = 3, and can securely withstand malicious adversaries that may corrupt any party.

[0387] We know how to construct two-message OT [21, 22, 23, 24] in the CRS model assuming the DDH / LWE / Quadratic Residuosity / N - th Residuosity assumptions. The Paillier encryption scheme

[14] is an example of circuit-specific additive homomorphic encryption from the N - th Residuosity assumption. As shown in Section IV.E, we can also construct NIZK arguments for the languages L 1 , L 2 from the N - th Residuosity assumption in the random oracle model. The other primitives can be constructed without any assumptions or can utilize only the existence of one-way functions. Thus, instantiating the primitives used in the above theorem, we obtain the following corollary:

[0388] Corollary 4 Assume the difficulty of the N - th residue assumption. There exists a four - round secure fuzzy threshold token generation protocol in the random oracle model that satisfies Definition 7 with respect to the cosine similarity distance function. The protocol is applicable to any n with threshold t = 3 and can securely resist malicious adversaries who may compromise any party.

[0389] A. Construction

[0390] Before describing our construction, we first list some notations and primitives used.

[0391] Let d denote the threshold of the cosine similarity function. Let (Share, Recon) be a (2, n) - threshold secret - sharing scheme. Let the n parties be denoted by P 1 ,..., P n respectively. Let λ denote the security parameter. Let denote the distribution from which random vectors are sampled. Assume the length of the vector is where is a polynomial in λ. Each element of this vector is an element of the field F over a large prime modulus q.

[0392] Let TS=(TS.Gen, TS.Sign, TS.Combine, TS.Verify) be a threshold signature scheme. Let (SKE.Enc, SKE.Dec) denote a secret - key encryption scheme. Let (Garble, Eval) denote a circuit - garbling scheme. Let Sim.Garble denote the simulator for this scheme. Let OT=(OT.Setup, OT.Round 1 , OT.Round 2 , OT.Output) be a two - message oblivious transfer protocol in the CRS model. Let OT.Sim denote the simulator. Let OT.Sim.Setup denote the algorithm for the simulator to generate the simulated CRS, and OT.Sim.Round 2 denote the algorithm for generating the second - round message for a malicious receiver.

[0393] Let AHE=(AHE.Setup, AHE.Enc, AHE.Add, AHE.ConstMul, AHE.Dec) be the algorithms of a circuit - specific additively homomorphic encryption scheme. Let (NIZK.Prove, NIZK.Verify) denote a non - interactive zero - knowledge argument of knowledge system in the RO model. Let RO denote the random oracle. Let NIZK.Sim denote the simulator for this argument system, and let NIZK.Ext denote the extractor. Let PRF denote a pseudorandom function with input length l.

[0394] We now describe the four - round secure fuzzy threshold token generation protocol π for cosine similarity CSConstruction

[0395] 1. Registration

[0396] In the registration phase, the following algorithm is executed by a trusted authority. The trusted authority can be a device that will participate in subsequent biometric matching and signature generation. If the trusted authority may participate in biometric matching and signature generation, it may delete the information it should not possess at the end of the registration phase. That is, it should delete the shares corresponding to other devices.

[0397] - Sample a random vector from the distribution For simplicity, assume has an L2-norm of 1.

[0398] - Compute

[0399] - For each i ∈ [n], give to party P i .

[0400] - For each i ∈ [n], do the following:

[0401] * Compute

[0402] * Compute (sk i , pk i ) ← AHE.Setup(1 λ ).

[0403] * Let For all compute

[0404] * Give to party P i and give to all other parties.

[0405] The trusted device samples a biometric template from the distribution which can be the raw biometric data collected by a biometric sensor. For simplicity, assume is normalized. Then, the trusted device generates the public key, shares of the secret key, and any other required public parameters for the threshold signature scheme according to any suitable key sharing algorithm. Examples of key sharing algorithms include Shamir's Secret Sharing.

[0406] The i-th device among a total of n devices receives the public parameters pp TA of the secret key encryption scheme, the public key vk TAand the i-th share of the secret key Then, the trusted device can compute where is the i-th share of the biometric template. The trusted device can also compute the shares of the public key and the secret key of the additive homomorphic encryption scheme (sk i , pk i ). Then, the trusted device can encrypt each l-component of as ct i，j . The i-th device receives its template share, secret key, private key, and encrypted value, as well as the random factor used in the encryption. All other devices receive the template share, public key share, and the complement of the encrypted template, without the random factor. Thus, at the end of the registration phase, each device has the complete public key and the complete encrypted template.

[0407] 2. Setup

[0408] The setup can also be done by a trusted authority. The trusted authority can be the same as the trusted device that completed the registration. If the trusted authority may be involved in biometric matching and signature generation, it can delete the information it should not have at the end of the registration phase. That is, it should delete the shares corresponding to other devices.

[0409] For each i ∈ [n], the setup algorithm does the following:

[0410] - Generate crs i ← OT.Setup(1 λ ).

[0411] - Generate random keys (k i，a , k i，b , k i，c , k i，d , k i，p , k i，q , k i，z , k i，C , k i，enc , k i，ot ) for PRF.

[0412] - Give (crs i ) to party P i .

[0413] - Give (crs i , k i，a , k i，b , k i，c , k i，d , k i，p , k i，q , k i，z , k i，C , k i，enc , ki，ot ) to all other parties.

[0414] In the setup phase, the main device can generate and distribute several constants that can be used later for partial computations. The trusted device can generate a common reference string for oblivious transfer setup and multiple random keys for pseudorandom functions. The i-th device receives the i-th crs, and all other parties receive the i-th crs and the i-th set of random keys.

[0415] 3. Login

[0416] In the login phase, we consider using the input vector and the message m for which it wants a related token of party P i Party P i selects two other parties P j and P k , and interacts with the other parties in the following four-round protocol. In the login phase, the biometric measurements are matched against the templates, and a signature is generated for the authentication challenge. The main device P i selects two other devices P j and P k to participate out of a total of n devices. The login phase involves four rounds of communication. The main device has the measured biometric and the message m for which it wants a related token. The arrows in the first round can indicate that in this round, the message is sent from party P i .

[0417] Round 1: (P i →) Party P i performs the following operations:

[0418] i. Let

[0419] ii. Let where j < k.

[0420] iii. For each compute the following:

[0421] · ct 1，j = AHE.Enc(pk i , u j ; r 1，j ).

[0422] · π 1，j ← NIZK.Prove(st 1，j , wit 1，j ), for the proposition st 1，j = (ct 1，j , pk i ) ∈ L 1, use the witness wit 1，j =(u j , r 1，j ).

[0423] ·ct 2，j =AHE.ConstMul(pk i , ct 1，j , u j ; r 2，j ).

[0424] ·π 2，j ←NIZK.Prove(st 2，j , wit 2，j ), for the proposition st 2，j =(ct 1，j , ct 1，j , ct 2，j , pk i )∈L 2 , use the witness wit 2，j =(u j , r 1，j , u j , r 1，j , r 2，j ).

[0425] ·ct 3，j =AHE.ConstMul(pk i , ct 1，j , w i，j ; r 3，j ).

[0426] ·π 3，j ←NIZK.Prove(st 3，j , wit 3，j ), for the proposition st 3，j =(ct 1，j , ct i，j , ct 3，j , pk i )∈L 2 , use the witness wit 3，j =(u j , r 1，j , w i，j , r wi，j , r 3，j ).

[0427] iv. Send to both parties in Round 1: For each component of the measurement vector, P

[0428] i ​Perform a series of calculations and perform non-interactive zero-knowledge proofs on these calculations. First, it encrypts the components and generates a proof that the encryption is valid. Then it homomorphically calculates the product of the component with itself as part of the normalized proof. Finally, it calculates for the component the product with and generates a proof that the multiplication is valid. Then P i sends the message, the calculated values, and the proofs to the other two devices.

[0429] Round 2: (→P i )P j and P k both perform the following operations:

[0430] i. If any of the proofs {π 1，j , π 2，j , π 3，j} j∈[l] is not verified, abort.

[0431] ii. Generate the following randomness:

[0432] ·a = PRF(k i，a , msg 1 ), b = PRF(k i，b , msg 1 ).

[0433] ·c = PRF(k i，c , msg 1 ), d = PRF(k i，d , msg 1 ).

[0434] ·p = PRF(k i，p , msg 1 ), q = PRF(k i，q , msg 1 ).

[0435] ·r z = PRF(k i，z , msg 1 ).

[0436] iii. Using the algorithm AHE and using the randomness PRF(k i，enc , msg 1 ), calculate ct x，1 , ct x，2 , ct y，1 , ct y，2 , ct z，1 , ct z，2 to be the encryption of the following:

[0437] · x 2 = (a·x 1 + b)

[0438] · y 2 = (c·y 1 + d)

[0439] · z 2 = (p·z 1 + q)

[0440] iv. Send (ct x，2 , ct y，2 , ct z，1 , ct z，2 ) to P i .

[0441] Round 2: Both P j and P k verify the proofs. If any proof is invalid, it can abort the protocol. This ensures that P i is trustworthy and does not send invalid values in an attempt to force a match. Then, each device uses the random key provided in the setup phase to generate pseudorandom values a, b, c, d, p, q, and r z . Since they receive the same random key associated with the message from P i , they will generate the same random values.

[0442] Then, the parties can use the additive homomorphic encryption algorithm to compute some values, as well as one-time message authentication codes (MACs) for these values. These values are: the inner product of the measurement with the template share of P i (x 1 ), the inner product of the measurement with itself (y 1 ), and the inner product of the measurement with the complement plus the random value r z (z 1 ). The associated MACs are x 2 , y 2 , and z 2 . The inner product with the template share of P i can be completed because it is sent component-wise as a ciphertext and then reconstructed as an inner product over the full vector due to homomorphic addition. The one-time MAC provides another check on P i . Even if P i attempts to change the computed values to force a match, the MAC will no longer correspond to the computed values. Then, each party will exclude x 1 and y 1All content other than this is sent to P i .

[0443] Round 3: (P i →) For each party in , P i performs the following operations:

[0444] i. If the tuples sent by P j and P k in Round 2 are different, abort.

[0445] ii. Compute x 2 = AHE.Dec(sk i , ct x，2 ).

[0446] iii. Compute y 2 = AHE.Dec(sk i , ct y，2 ),

[0447] iv. Compute z 1 = AHE.Dec(sk i , ct z，1 ), z 2 = AHE.Dec(sk i , ct z，2 ).

[0448] v. Generate and send where is randomly and uniformly selected

[0449] Round 3: P i can compare the tuples sent by the other two parties. If the tuples do not match, P i can abort the protocol. This check is to ensure that P j and P k are trustworthy. Since they start with the same random key, all their computations should be the same. We assume that the two devices do not collude to send invalid values, as it is assumed that the devices only communicate with the main device. Then P i computes x 1 and y 1 for itself, and decrypts the message containing z 1 , x 2 , y 2 and z 2 . Then, P i sends an oblivious transfer message to each of the other two devices to convey the garbled inputs of the garbled circuit used in Round 4.

[0450] Round 4: (P j →P i )P j performs the following operations:

[0451] i. Calculate r C = PRE(k i，C , msg 1 ).

[0452] ii. Calculate for the circuit C depicted in Figure 7 .

[0453] iii. Let

[0454] iv. For each s ∈ {x, y, z} and each t ∈ {0, 1}, let denote the label of the garbled circuit t corresponding to the input wire s . Generate

[0455] v. Let

[0456] vi. Pick a random string Pad = PRF(k i，C , msg 3 ).

[0457] vii. Set

[0458] viii. Send to P i .

[0459] Round 4: (P k →P i )P k performs the following operations:

[0460] i. Calculate j ot exactly as P Sen did, and Pad.

[0461] ii. Set

[0462] iii. Send to P i .

[0463] Round 4: Both P j and P k can generate garbled circuits, as Figure 7As shown in, and ready to be sent. Each device also generates a suitable string Pad. The two devices should generate the same garbled circuit and string Pad because the devices have the same input parameters due to the shared randomness established during the setup phase. Then, the circuit checks whether each value / MAC pair is consistent, and aborts if there are any mismatches. It then calculates the inner product. If the inner product is greater than a predetermined threshold, the circuit outputs the string Pad. If the inner product is not greater than the threshold, the circuit outputs a failure flag. The random constants used to check the MAC are hardwired into the circuit, so P i cannot learn these values and forge the results.

[0464] Then, P j uses the string Pad and the secret key sharing from the registration phase to calculate a partial signature of the secret key encryption scheme. P k Performs the same action on its own key share. Then P j sends to P i , sending the garbled circuit and its partial calculations. P k sends its partial calculations and the random oracle hash of the circuit.

[0465] Output calculation: P j , P k party outputs In addition, P i party performs the following operations to generate a token:

[0466] i. Let be the message received from P j , and (msg 4 , OneCT k ) be the message received from P k .

[0467] ii. If then abort

[0468] iii. For each s ∈ {x, y, z} and each t ∈ {0, 1}, calculate

[0469] iv. Let lab = {lab s，t} s∈{x，y，z}，t∈{0，1} .

[0470] v. Calculate

[0471] vi. Calculate Token j = SKE.Dec(Pad, OneCT j ), Token k = SKE.Dec(Pad, OneCT k)、

[0472]

[0473] vii. Compute Token ← TS.Combine({Token s} s∈{i，j，k}) 。

[0474] viii. If TS.Verify(vk TS , m, Token), then output Token. Otherwise, output ⊥.

[0475] Output calculation: P i Now a token can be generated. It can check whether the hash of the circuit sent by P j matches the hash sent by P k . If not, abort the calculation. This ensures that the other two parties behave properly. P i Then the appropriate labels for the garbled circuit can be calculated, and the circuit can be evaluated to determine the string Pad (if there is a match). Using the string Pad, P i can decrypt the partial calculations sent by the other two parties and perform its own partial calculations on the signature. Finally, P i can combine the partial calculations and create a complete token.

[0476] 4. Token Verification

[0477] Given the verification key vk TS , message m and token Token, if TS.Verify(vk TS , m, Token outputs 1, then the token verification algorithm outputs 1.

[0478] The correctness of the protocol follows directly from the correctness of the underlying primitives.

[0479] B. Security Proof

[0480] In this section, we formally prove Theorem 3.

[0481] Consider an adversary who compromises our protocol π CS . The simulator Sim against the malicious adversary has the following strategy. Note that the registration phase occurs first, and the simulator obtains the values to be sent to at the end of this phase, and then forwards these values to

[0482] 1. Description of the Simulator

[0483] Setup: For each \(i\in[n]\), Sim does the following:

[0484] - Generate

[0485] - Generate random keys \((k i，a , k i，b , k i，c , k i，d , k i，p , k i，q , k i，z , k i，C ) for the PRF.

[0486] - If then give \((crs i ) to

[0487] - Otherwise, give \((crs i , k i，a , k i，b , k i，c , k i，d , k i，p , k i，q , k i，z , k i，C ) to

[0488] Login Phase: Case 1 – The honest party is \(P i

[0489] Suppose the honest party \(P i uses the input vector and the message \(m\) it wants to obtain the relevant token by interacting with the two-party set \(S\). One of the two parties is The arrow in the first round can indicate that in this round, the message is sent from the simulator. Sim obtains the tuple from the ideal functionality and interacts with the adversary as follows:

[0490] · Round 1: \((Sim\rightarrow)\) Sim does the following:

[0491] (a) For each compute the following:

[0492] * For each \(t\in\{1,2,3\}\), \(ct t，j = AHE.Enc(pk i , m t，j ; r t，j ), where \((m t，j , r t，j ) are randomly and uniformly selected.

[0493] *π 1，j ←NIZK.Sim(st 1，j ),for the statement st 1，j =(ct 1，j ,pk i )∈L 1 。

[0494] *π 2，j ←NIZK.Sim(st 2，j ),for the statement st 2，j =(ct 1，j ,ct 1，j ,ct 2，j ,pk i )∈L 2 。

[0495] *π 3，j ←NIZK.Sim(st 3，j ),for the statement st 3，j =(ct 1，j ,ct i，j ,ct 3，j ,pk i )L 2 。

[0496] (b) Send to

[0497] · Round 2: (→Sim) represents the attacking party receives (ct x，2 ,ct y，2 ,ct z，1 ,ct z，2 ) from the adversary.

[0498] · Round 3: (Sim→) Sim performs the following operations:

[0499] (a) If the ciphertexts (ct ,ct i，a ,ct i，b ,ct i，c ,ct i，d ,ct i，p ,ct i，q ,ct i，z ,ct i，enc ) are not correctly calculated using the AHE algorithm, vectors x，2 ,ct y，2 ,ct z，1 ,ct z，2 ) with the randomness (k

[0500] (b) Generate and send Among them, randomly and uniformly select

[0501] · Round 4: (→Sim) represents the attacker Receive from the adversary

[0502] · Send a message to the ideal functionality Sim performs the following operations:

[0503] (a) If the corresponding algorithm and randomness (k i，ot ,, k i，C ) are not used to correctly calculate Then abort.

[0504] (b) Otherwise, instruct the ideal functionality To deliver the output to the honest party P i .

[0505] Login phase: Case 2 - The malicious party is P i

[0506] Assume the malicious party is the initiator P i . Sim interacts with the adversary As follows:

[0507] · Round 1: (→Sim) Sim represents the two honest parties P j , P k Receive from the adversary Receive

[0508] · Round 2: (Sim→) Sim performs the following operations:

[0509] (a) Send a message to the ideal functionality :

[0510] i. Regarding the proof {π 1，j , π 2，j , π 3，j} j∈[l] Run the extractor NIZK.Ext to calculate

[0511] ii. Query the ideal functionality To receive the output

[0512] (b) Use the public key pk i And uniform randomness to generate (ct x，2 , ct y，2 , ct z，1 , ct z，2 ) as the encryption of the random message. Send it to​

[0513] · Round 3: (→Sim) Sim represents two honest parties P j and P k receives from the adversary receive

[0514] · Round 4: (Sim→) Sim performs the following operations:

[0515] (a) Randomly and uniformly select a value Pad.

[0516] (b) If

[0517] * Let

[0518] * Calculate

[0519] * Let lab sim ={lab s，t} s∈{x，y，z}，t∈{0，1}

[0520] * For each s ∈ {x, y, z} and each t ∈ {0, 1}, calculate

[0521] * Calculate

[0522] * Set OneCT j = SKE.Enc(Pad, Token j ) and OneCT k = SKE.Enc(Pad, Token k ).

[0523] (c) If

[0524] * Calculate

[0525] * Let lab sim ={lab s，t} s∈{x，y，z}，t∈{0，1}

[0526] * For each s ∈ {x, y, z} and each t ∈ {0, 1}, calculate

[0527] * Calculate

[0528] * Set OneCT j= SKE.Enc(Pad, r j ) and OneCT k = SKE.Enc(Pad, r k ), where r and r are randomly and uniformly selected j and r k .

[0529] (d) Send and to

[0530] 2. Hybrid

[0531] We now prove that the above simulation strategy is successful against all malicious PPT adversaries. That is, in the real world and the ideal world, the adversary's observations and the honest parties' outputs are computationally indistinguishable. We will show this through a series of computationally indistinguishable hybrids, where the first hybrid Hyb 0 corresponds to the real world and the last hybrid Hyb 8 corresponds to the ideal world.

[0532] 1. Hyb 0 – Real world: In this hybrid, consider the simulator SimHyb that plays the role of the honest party in the real world.

[0533] When the honest party is P i :[[]]

[0534] 2. Hyb 1 – Case 1: Abort concurrent messages to the ideal functionality. In this hybrid, if the adversary's messages are not generated in a way consistent with the randomness output in the setup phase, then SimHyb aborts and makes a query to the ideal functionality.

[0535] That is, SimHyb runs the "send message to the ideal functionality" step as Sim did after the 4th round in simulation strategy case 1. SimHyb also performs the abort check step in step 1 of round 3 of simulation case 1.

[0536] 3. Hyb 2 – Case 1: Simulate NIZK. In this hybrid, SimHyb computes the simulated NIZK argument in round 1 of case 1 as Sim did in the ideal world.

[0537] 4. Hyb 3 – Case 1: Switch ciphertext. In this hybrid, SimHyb computes the ciphertext in round 1 of case 1 using random messages as it did in the ideal world.

[0538] 5. Hyb 4– Case 1: Switch OT receiver message. In this hybrid, SimHyb computes the OT receiver message in round 3 of Case 1 using a random input as it does in the ideal world.

[0539] When the corrupted party is P i :

[0540] 6. Hyb 5 – Case 2: Send a message to the ideal functionality. In this hybrid, SimHyb runs the "send a message to the ideal functionality" step as Sim does in the simulation strategy in round 2 of Case 2. That is, SimHyb queries the ideal functionality using the output of the extractor NIZK.Ext on the proof given in round 1.

[0541] 7. Hyb 6 – Case 2: Simulate OT sender message. In this hybrid, SimHyb computes the CRS during the setup phase and the OT sender message in round 4 of Case 2 using the simulator OT.Sim as it does in the ideal world.

[0542] 8. Hyb 7 – Case 2: Simulate garbled circuit. In this hybrid, SimHyb computes the garbled circuit and the associated tags in round 4 of Case 2 using the simulator Sim.Garble as it does in the ideal world.

[0543] 9. Hyb 8 – Case 2: Switch ciphertext. In this hybrid, SimHyb computes the ciphertext in round 2 of Case 2 using a random message as it does in the ideal world. This hybrid corresponds to the ideal world.

[0544] We now prove that each pair of consecutive hybrids is computationally indistinguishable.

[0545] Lemma 5 Hyb 0 is statistically indistinguishable from Hyb 1 .

[0546] Proof. When the honest party initiates the protocol as the querying party P i and assumes it interacts with party P j and party P k such that P k is the corrupted party. In Hyb 0 SimHyb checks on behalf of P i whether the messages sent by the two parties P j and P k are the same, and if so, computes the output on behalf of the honest party. Since P kis honest, so this means that if the messages sent by both parties are indeed the same, it represents P j 's adversary did indeed use the shared randomness generated in the setup phase and the shared values generated in the registration phase to honestly generate these messages.

[0547] In Hyb 1 SimHyb represents P i checks whether the messages sent by the adversary on behalf of P j are correctly generated using the shared randomness and shared values generated in the setup phase and the registration phase. If so, it asks the ideal functionality to deliver the output to the honest party. Therefore, the switch from Hyb 0 to Hyb 1 is essentially just a syntactic change.

[0548] Lemma 6 Assuming the zero - knowledge property of the NIZK argument system, Hyb 1 is computationally indistinguishable from Hyb 2

[0549] Proof. The only difference between these two hybrids is that in Hyb 1 SimHyb computes the messages of the NIZK argument system by running the honest prover algorithm NIZK.Prove(·), while in Hyb 2 the messages are computed by running the simulator NIZK.Sim(·). Therefore, we can prove that if there exists an adversary who can distinguish these two hybrids with non - negligible probability then we can design a reduction that can distinguish the real argument from the simulated argument with non - negligible probability thus breaking the contradiction of the zero - knowledge property of the NIZK argument system.

[0550] Lemma 7 Assuming the semantic security of the additive homomorphic encryption scheme AHE, Hyb 2 is computationally indistinguishable from Hyb 3

[0551] Proof. The only difference between these two hybrids is that in Hyb 2 SimHyb encrypts the actual input of the honest party to compute the ciphertext in the first round, while in Hyb 3 the ciphertext encrypts a random message. Therefore, we can prove that if there exists an adversary who can distinguish these two hybrids with non - negligible probability then we can design a reduction that can distinguish the encryption of the honest party's actual input from the encryption of a random message with non - negligible probability ​​Thus, it breaks the contradiction of the semantic security of the encryption scheme AHE.

[0552] Lemma 8 Assume the security of the oblivious transfer protocol OT against malicious senders, Hyb 3 is computationally indistinguishable from Hyb 4

[0553] Proof. The only difference between these two hybrids is that in Hyb 3 , SimHyb computes the message of the OT receiver as an honest party does in the real world, while in Hyb 4 , the message of the OT receiver is computed using a random message as input. Therefore, we can prove that if there exists an adversary who can distinguish these two hybrids with non-negligible probability then we can design a reduction that can distinguish the actual input of an honest party and the random input of the OT receiver's message with non-negligible probability Thus, it breaks the contradiction of the security of the oblivious transfer protocol OT against malicious senders.

[0554] Lemma 9 Assume the knowledge property argument of the NIZK argument system, Hyb 4 is computationally indistinguishable from Hyb 5

[0555] Proof. The only difference between these two hybrids is that in Hyb 5 , SimHyb also runs the extractor NIZK.Ext based on the proof given by the adversary to compute its input Therefore, the only difference between these two hybrids is whether the adversary can generate a set of proofs {π j} such that all proofs are successfully verified with non-negligible probability, but SimHyb cannot extract Therefore, SimHyb aborts.

[0556] However, we can prove that if there exists an adversary who can make this happen with non-negligible probability then we can design a reduction that breaks the contradiction of the knowledge property argument of the system NIZK with non-negligible probability

[0557] Lemma 10 Assume the security of the oblivious transfer protocol OT against malicious receivers, Hyb 5 is computationally indistinguishable from Hyb 6

[0558] Proof. The only difference between these two hybrids is that in Hyb 5 ​​​In it, SimHyb uses the actual labels of the garbled circuit as an honest party would in the real world to compute the messages of the OT sender, while in Hyb 6 the messages of the OT sender are computed by running the simulator OT.Sim. In Hyb 6 the crs in the setup phase is also computed using the simulator OT.Sim.

[0559] Therefore, we can prove that if there exists an adversary that can distinguish between these two hybrids with non-negligible probability then we can design a reduction that can distinguish with non-negligible probability between the following two cases: the crs and the messages of the OT sender are generated by running the honest sender algorithm, and the crs and the messages of the OT sender are generated using the simulator OT.Sim; thus leading to a contradiction that breaks the security of the oblivious transfer protocol OT against malicious receivers.

[0560] Lemma 11 Assuming the correctness of the extractor NIZK.Ext and the security of the garbling scheme, Hyb 6 is computationally indistinguishable from Hyb 7 Proof. The only difference between these two hybrids is that in Hyb

[0561] SimHyb computes the garbled circuit by running the honest garbling algorithm Garble using honestly generated labels, while in Hyb 6 SimHyb computes the simulated garbled circuit and simulated labels by running the simulator Sim.Garble on the values output by the ideal functionality 7 From the correctness of the extractor NIZK.Ext, it follows that the output of the garbled circuit received by the evaluation procedure in Hyb 6 is the same as the output of the ideal functionality used in the ideal world Therefore, we can prove that if there exists an adversary that can distinguish between these two hybrids with non-negligible probability then we can design a reduction that can distinguish with non-negligible probability between the set of honestly generated input wire labels and the honestly generated garbled circuit and the set of simulated input wire labels and garbled circuit, thus leading to a contradiction that breaks the security of the garbling scheme.

[0562] Lemma 12 Assuming the circuit privacy property of the additive homomorphic encryption scheme AHE, Hyb 7 is computationally indistinguishable from Hyb 8 Proof. The only difference between these two hybrids is that in Hyb 7

[0563] the only difference between these two hybrids is that in Hyb 7In it, SimHyb computes the ciphertext sent in the second round by performing homomorphic operations on the well-formed ciphertext sent by the adversary in the first round exactly as in the real world, while in Hyb 3 SimHyb generates the ciphertext of an encrypted random message. Thus, we can prove that if there exists an adversary who can distinguish the two hybrids with non-negligible probability we can design a reduction that contradicts the circuit privacy of the circuit-specific additive homomorphic encryption scheme.

[0564] C. Euclidean Distance

[0565] Recall that given two vectors the square of the Euclidean distance EC.Dist between them is related to their cosine similarity CS.Dist as follows:

[0566]

[0567] Therefore, it is easy to observe that the above protocol and analysis can also be easily extended to the Euclidean distance.

[0568] VIII. Cosine Similarity Using Depth-1 Threshold FHE

[0569] In this section, we show how to efficiently construct a fuzzy threshold token generation protocol for cosine similarity using any depth-1 FHE scheme with threshold decryption.

[0570] A. Construction

[0571] Before describing our construction, we first list some notations and primitives used.

[0572] Let IP be a function that takes as input the input template w, the measurement u and outputs the inner product <w, u>, and let d denote the threshold inner product value to represent a match between w and u. Let n parties be denoted by P 1 ,..., P n respectively. Let λ denote the security parameter. Let W denote the distribution from which random template vectors are sampled. Assume that the length of the vectors is where is a polynomial in λ. Let C be a circuit that takes as input the template w, the measurement u and a certain string K, and outputs K when the distance between w and u is below a certain (predefined) threshold; otherwise it outputs 0.

[0573] Let TFHE = (TFHE.Gen, TFHE.Enc, TFHE.PartialDec, TFHE.Eval, TFHE.Combine) be a depth-1 threshold FHE scheme. Let TS = (TS.gen, TS.Sign, TS.Combine, TS.Verify) be a threshold signature scheme. Let SKE = (SKE.Gen, SKE.Enc, SKE.Dec) denote a secret-key encryption scheme. Let PKE = (PKE.Gen, PKE.Enc, PKE.Dec) denote a public-key encryption scheme.

[0574] Let (Gen, Sign, Verify) be a strongly unforgeable digital signature scheme. Let NIZK = (NIZK.Setup, NIZK.Prove, NIZK.Verify) denote a non-interactive zero-knowledge argument. Let H be a collision-resistant hash function (modeled later as a random oracle).

[0575] We now describe the construction of a six-round secure fuzzy threshold token generation protocol π for any n and k. IP Construction.

[0576] 1. Registration

[0577] In the registration phase, the following algorithm is executed by a trusted authority:

[0578] · Sample a random w from the distribution W.

[0579] · Compute (pk, sk 1 ,..., sk N ) ← TFHE.Gen(1 λ , n, t).

[0580] · Compute

[0581] · Compute

[0582] · Compute K ← SKE.Gen(1 λ ).

[0583] · Compute crs ← NIZK.Setup(1 λ ).

[0584] · Compute the ciphertexts

[0585] ct 0 ← TFHE.Enc(pk, w), ct 1 ← TFHE.Enc(pk, K).

[0586] · For each i ∈ [n], do the following:

[0587] a) Compute (sk′ i , vk′ i ) ← Gen(1 λ ).

[0588] b) Compute K i = H(K, i).

[0589] c) Give the following to P i Party

[0590]

[0591] A trusted authority (e.g., the primary user device) can sample a biometric template w from the biometric measurement distribution . In addition to the public parameters pp TS , the verification key vk TS and multiple private key shares for the threshold signature scheme TS , the trusted authority can also compute the public key pk and multiple private key shares sk i for the threshold fully homomorphic encryption scheme TFHE. The trusted authority can also compute the public key and the secret key for the public key encryption scheme PKE and the string K for the secret key scheme SKE. Using the public key pk, the trusted authority can encrypt the biometric template w to form the ciphertext ct 0 , and encrypt the string K to form the ciphertext ct 1 .

[0592] Then, the trusted authority can compute multiple values for each of the n electronic devices i (e.g., the first electronic device and other electronic devices). The trusted authority can compute the secret key share sk′ i and the verification key share vk′ i for the digital signature scheme. The trusted authority can also use the string K and the hash function H to compute the hash K i . Then, the trusted authority can send the public key pk, the ciphertext ct i and ct 0 and ct 1 , the verification key shares (vk′ i ,...., vk′ i ), the secret key share sk′ i , the public parameters pp TS , the verification key vk TS , the private key shares and the hash K i to each electronic device P

[0593] 2. Login Phase

[0594] In the login phase, consider Party P that uses the input vector u and the message m of the token it wants to be associated with. * Party P * interacts with other parties in the following four-round protocol. The arrows in the first round can indicate that in this round, the message is sent from Party P. * Party.

[0595] · Round 1: (P * →) Party P * performs the following operations:

[0596] a) Calculate the ciphertext ct * = TFHE.Enc(pk, u).

[0597] b) Select a set S consisting of t parties from among Party P 1 ,..., Party P n . For simplicity and without loss of generality, we assume that Party P * is also part of the set S.

[0598] c) Send (ct i , m) to each party P * ∈ S.

[0599] · Round 2: (→ Party P * ) Each party P i ∈ S (except Party P * ) performs the following operations:

[0600] a) Calculate the signature σ′ i = Sign(sk′ i , ct * ).

[0601] b) Send σ′ i to Party P * Party.

[0602] · Round 3: (Party P * →) Party P * sends (σ′ 1 ,..., σ′ n ) to each party P i .

[0603] · Round 4: (→ Party P * ) Each party P i ∈ S (except Party P * ) performs the following operations:

[0604] a) If there exists an i ∈ [n] such that Verify(vk′ i , ct * , σ′ i) If it is not equal to 1, then output ⊥.

[0605] b) Otherwise, evaluate the following ciphertext

[0606] ct = TFHE.Eval(pk, IP, ct 0 , ct * ),

[0607] And calculate the partial decryption of ct as:

[0608] μ i = TFHE.PartialDec(sk i , ct).

[0609] c) Send μ i to Party P * .

[0610] · Round 5: (P * →) Party P * performs the following operations:

[0611] a) Recover IP(v, u) = TFHE.Combine(μ 1 ,..., μ n ).

[0612] b) Calculate

[0613] c) For each i ∈ [n], calculate

[0614] d) Send the following tuple to each Party P i :

[0615] (C 0 , C 1 ,..., C n , π),

[0616] where π is a NIZK proof (generated by algorithm NIZK.Prove using crs) for the following proposition (subsequently denoted as γ):

[0617] Under the public key , the ciphertext C 0 encrypts the inner product μ 0 and each ciphertext C i encrypts some message μ i , where i ∈ [n], such that:

[0618] i. μ 0 < d.

[0619] ii. μ 0 = TFHE.Combine(μ1 ,..., μ n )。

[0620] · Round 6: (→ P * ) Each party {P i ∈ S (except P * ) performs the following operations:

[0621] a) If NIZK.Verify(crs, γ, π) ≠ 1, then output ⊥.

[0622] b) Otherwise, compute the partial decryption of ct 1 as:

[0623] μ i，1 = TFHE.PartialDec(sk i , ct 1 ).

[0624] (c) Compute Token i = TS.Sign(sk i , m) and

[0625] (d) Send to party P * .

[0626] · Output calculation: Party P * performs the following operations to generate a token:

[0627] (a) Recover K = TFHE.Combine(μ 1，1 ,..., μ n，1 ).

[0628] (b) For each i ∈ [n], perform the following operations:

[0629] i. Compute K i = H(K, i).

[0630] ii. Recover

[0631] (c) Compute ← TS.Combine({Token i}[[]] i∈S ).

[0632] (d) If TS.Verify(vk TS , m, Token) = 1, then output Token. Otherwise, output ⊥.

[0633] The first electronic device P *The public key pk of a threshold fully homomorphic encryption scheme can be utilized to encrypt an input vector u (e.g., a biometric measurement vector) to generate an encrypted biometric measurement ciphertext ct * . The first electronic device can send the encrypted biometric measurement value ct * and a message m to each of the other electronic devices. Each of the other electronic devices can use the ciphertext ct * and a secret key share sk′ i to compute a partial signature computation σ′ i . Each electronic device can send the partial signature computation σ′ i to the first electronic device. The first electronic device can send all of the partial signature computations (σ′ 1 ,..., σ′ n ) to all of the other electronic devices.

[0634] Each of the other electronic devices can use the ciphertext ct * and the received verification keys (vk′ 1 ,..., vk′ n ) to verify each partial signature computation (σ′ 1 ,..., σ′ n ). If any of the partial signature computations are not verified (e.g., Verify(vk′ i , ct * , σ′ i ) ≠ 1), then the electronic device can output ⊥, thereby indicating an error. An unverified signature can indicate that one (or more) of the electronic devices did not correctly compute the partial signature computation and may thus be compromised or fraudulent. After verifying the partial signature computations, each of the other electronic devices can evaluate the ciphertext ct * and ct 0 to generate a new ciphertext ct. Evaluating the ciphertext can include computing the inner product between a template w (in ciphertext ct 0 ) and a measurement u (in ciphertext ct * ). Then, the inner product can be used, for example, to compute a cosine similarity distance measure or an Euclidean distance. Then each of the other electronic devices can compute a partial decryption μ i of the ciphertext ct. Then the partial decryption μ i can be sent to the first electronic device.

[0635] The first electronic device can use threshold fully homomorphic encryption to combine the partial decryptions (μ 1 ,..., μ n ) to recover the inner product IP(w, u) of the template w and the measurement u. The first electronic device can encrypt the inner product IP(w, u) using a public key encryption scheme to generate a ciphertext C 0, and decrypt each part μ i Encrypt to generate multiple ciphertexts C i . The first electronic device can also generate a non-interactive zero-knowledge proof π. The proof π can prove C 0 Encrypted inner product μ 0 And each ciphertext C i Encrypted value μ i . The proof π can also show that the inner product (and thus the distance measure) is less than the threshold d, and the inner product μ 0 Is the result of the combination of partial decryption (μ 1 ,..., μ n ). The first electronic device can then send a tuple (C 0 , C 1 ,..., C n , π) with the ciphertext and the proof to each of the other electronic devices.

[0636] Each of the other electronic devices can verify the proof π. If the proof is not verified, the electronic device can output ⊥ and abort. If the proof π is verified, the electronic device can calculate the partial decryption μ 1 Of ct i，1 , the encryption of the string K. The partial threshold signature token Token i Can be generated by each of the other electronic devices using the secret key share sk i And the message m. The ciphertext Can be calculated as the secret key encryption through the partial threshold signature token Token i And the hash K i . Then, the partial decryption μ i，1 And the ciphertext Can be sent to the first electronic device.

[0637] The first electronic device can homomorphically combine the partial decryptions (μ 1，1 ,..., μ n，1 ) to recover the string K. Then, the first electronic device can use the string K and the hash function H to calculate the hash K i Of each electronic device i, and then use the hash K i To decrypt the secret key encrypted ciphertext To recover the partial threshold signature token Token i . Using each received partial threshold signature token Token i , the first electronic device can combine them to calculate the signature token Token. If the first electronic device can verify the token Token and the message m, the first electronic device can output the token Token; otherwise, the first electronic device can output ⊥.

[0638] Token verification

[0639] Given the verification key vk TS , message m, and Token, if TS.Verify(vk TS , m, Token) outputs 1, then the token verification algorithm outputs 1.

[0640] B. Security Analysis

[0641] We prove Informal Theorem 3 here. In fact, this proof is very similar to the proof using TFHE in the general case. Therefore, we omit the details and only provide a short summary. Note that this protocol implements a slightly weaker guarantee with the definition of the leakage function Specifically, the leakage function L c , L f , L m returns the exact inner product of the template w and the measurement value u. This is because: in the protocol (i.e., the login phase), the initiator will know this value. In the simulation, when the login session is initiated by the compromised party, this situation will occur. In this case, the simulator issues a "test password" query for the input of the initiator, and then learns the inner product it sends to the adversary. The other steps are basically the same as those of the general protocol simulator, so we omit the details.

[0642] IX. Hamming Distance

[0643] In this section, for the distance measure being the Hamming distance, we show how to construct an efficient two-round secure fuzzy threshold token generation protocol in the random oracle model. Our token generation protocol satisfies Definition 7 for any n, t, and can securely resist malicious adversaries who can compromise at most (t - 1) parties.

[0644] Formally, we show the following theorem:

[0645] Theorem 5 Assume the existence of threshold signatures, threshold linear secret sharing, robust linear secret sharing, secret key encryption, UC-secure threshold oblivious pseudorandom functions, and collision-resistant hash functions defined in Section III.E. For the Hamming distance function, there exists a two-round secure fuzzy threshold token generation protocol that satisfies Definition 7. The protocol is applicable to any n, any threshold t, and can securely resist malicious adversaries who can compromise at most (t - 1) parties.

[0646] In the random oracle model

[25] , assuming the gap threshold one - to - many Diffie - Hellman assumption, a threshold oblivious PRF can be constructed. Assuming DDH / RSA [16, 17], the threshold signature scheme we use can be constructed. The random oracle model implies a collision - resistant hash function. We will use the Shamir secret sharing scheme to instantiate the robust secret sharing scheme described in Theorem 1. Other primitives can be constructed unconditionally or assuming only one - way functions. Thus, instantiating the primitives used in the above theorem, we obtain the following corollary:

[0647] Corollary 6 Assume and the hardness of the gap threshold one - to - many Diffie - Hellman (Gap - TOMDH), there exists a two - round secure fuzzy threshold token generation protocol in the random oracle model satisfying Definition 7 for the Hamming distance function. The protocol works for any n, any threshold t, and can securely withstand a malicious adversary who can corrupt at most (t - 1) parties.

[0648] A. Construction

[0649] Before describing our construction, we first list some notations and primitives we use.

[0650] Let the n parties be denoted by P 1 ,..., P n respectively. Let λ denote the security parameter. Let denote the distribution from which random vectors are sampled. Assume the length of the vector is where is a polynomial in λ. Each element of this vector is an element of the field F over some large prime modulus q. Let d denote the threshold of the Hamming distance function. That is, two vectors and and of respective lengths are considered close if their Hamming distance is at most

[0651] (i.e., they are equal in at least d positions). Let (Share, Recon) be an (n, t) linear secret sharing scheme. Let (RSS.Share, RSS.Recon, Thres, Recon) be the robust linear secret sharing scheme defined in Appendix A. That is, the secret can be reconstructed by running the algorithm Thres.Recon when given exactly d honestly generated shares or by running Recon on a batch of shares whose When running the algorithm RSS.Recon for honest generation) for reconstruction. Let TS = (TS.Gen, TS.Sign, TS.Combine, TS.Verify) be the threshold signature scheme of Boldyreva

[16] . We note that a similar construction also applies to other threshold signature schemes. Without loss of generality, for simplicity, we present our scheme using the construction of Boldyreva

[16] here.

[0652] Let (SKE.Enc, SKE.Dec) denote the secret key encryption scheme. Let TOPRF = (TOPRF.Setup, TOPRF.Encode, TOPRF.Eval, TOPRF.Combine) denote the UC-secure threshold oblivious pseudorandom function in the random oracle (RO) model. Let TOPRF.Sim (TOPRF.Sim.Encode, TOPRF.Sim.Eval, TOPRF.Sim.Ext) denote the simulator of this scheme, where the algorithm TOPRF.Sim.Encode is used to generate simulated encodings, and TOPRF.Sim.Eval is used to generate simulated messages on behalf of the algorithm TOPRF.Eval. The algorithm TOPRF.Sim.Ext extracts the encoded messages based on the queries made to the RO during the TOPRF.Combine phase. Let us model the collision-resistant hash function H through the random oracle.

[0653] We now describe the construction of a two-round secure threshold fuzzy token generation protocol for the Hamming distance.

[0654] 1. Registration

[0655] In the registration phase, the following algorithm is executed by the trusted authority:

[0656] - Compute Remember is generated by running and generated.

[0657] - For each Compute

[0658] - For each j ∈ [n], give to P j party.

[0659] - Sample a random vector from the distribution Let

[0660] - Compute Let sk TOPRF denote the combined key of TOPRF.

[0661] - For each j ∈ [n], give P j .

[0662] - For each perform the following operations:

[0663] * Calculate h i = TOPRF(sk TOPRF , w i ).

[0664] * For each j ∈ [n], calculate h i，j = H(h i ||j). Give h i，j to P j party.

[0665] 2. Set

[0666] The setting algorithm has no action.

[0667] 3. Login phase

[0668] In the login phase, let's consider P * , which uses the input vector and the message m for which it wants a related token. P * interacts with other parties in the following two-round protocol.

[0669] - Round 1: (P * →) The P * party performs the following operations:

[0670] i. Select a set 1 consisting of t parties from P n ,..., P For simplicity and without loss of generality, we assume that P * is also part of the set .

[0671] ii. For each use the randomness ρ i to calculate c i = TOPRF.Encode(u i ; ρ i ).

[0672] iii. Send to each party

[0673] - Round 2: (→P * ) Each party (except P *)Perform the following operations:

[0674] i. Calculate

[0675] ii. For each perform:

[0676] · Calculate whose evaluation result is Let

[0677] · Calculate

[0678] · Calculate ct i，j = SKE.Enc(h i，j , y i，j ).

[0679] · Send (z i，j , ct i，j ) to P * party.

[0680] - Output calculation: Each party outputs In addition, the P * party performs the following operations to generate a token:

[0681] i. For each perform:

[0682] · Calculate

[0683] · For each calculate h i，j = H(h i ||j), and then calculate y i，j = SKE.Dec(h i，j , ct i，j ).

[0684] · Let α 1 ,..., α n be the reconstruction coefficients of the (n, t) linear secret sharing scheme for secret sharing of . Calculate

[0685] Strategy 1: Match

[0686] i. Let β 1 ,..., be for each party in to secretly share sk TS and 0, and the Reconstruction coefficients of the robust reconstruction algorithm RSS.Recon of the linear robust secret sharing scheme.

[0687] ii. Compute

[0688] iii. If TS.Verify(vk TS , m, Token), then output Token and stop.

[0689] iv. Otherwise, output ⊥.

[0690] Strategy 2: Only d matching

[0691] i. For each set such that do:

[0692] · Compute

[0693] · If TS.Verify(vk TS , m, Token), then output Token and stop.

[0694] ii. Otherwise, output ⊥.

[0695] 4. Token verification

[0696] Given the verification key vk TS , message m and token Token, if TS.Verify(vk TS , m, Token outputs 1, then the token verification algorithm outputs 1.

[0697] The correctness of the protocol directly follows from the correctness of the underlying primitives.

[0698] B. Security proof

[0699] In this section, we formally prove Theorem 5.

[0700] Suppose the adversary compromises t * parties, where t * < t. The following describes the strategy of our simulator Sim for the malicious adversary HD . Note that the registration phase occurs first, and the simulator obtains the values to be sent to each compromised party at the end of the phase, and then forwards the values to

[0701] 1. Description of the simulator

[0702] Login phase: Case 1 – The honest party is P *

[0703] Consider an honest party P * , which uses the input vector and the message m that it wants to obtain a relevant token by interacting with the set S, which consists of t, some of which may have been compromised. Sim obtains the tuple from the ideal functionality and interacts with the adversary as follows:

[0704] · Round 1: (Sim→) Sim does the following:

[0705] (a) For each using the randomness ρ i compute c i = TOPRF.Sim.Encode(1 λ ; ρ i ).

[0706] (b) Send to each malicious party the

[0707] · Round 2: (→Sim) For each on behalf of each compromised party receive from the adversary (z i，j , ct i，j ).

[0708] · Send a message to the ideal functionality Sim does the following:

[0709] (a) For each compromised party P j , do:

[0710] * For each if then abort.

[0711] * Compute y i，j = SKE.Dec(h i，j , ct i，j ).

[0712] * Let β 1 ,..., be the reconstruction coefficients of the robust reconstruction algorithm RSS.Recon of the linear robust secret sharing scheme for secret sharing 0.

[0713] * Compute if then abort.

[0714] (b) Instruct the ideal functionality ​Deliver the output to the honest party P * 。

[0715] Login phase: Case 2 - The malicious party is P *

[0716] Suppose the malicious party is the initiator P * 。Sim interacts with the adversary as follows:

[0717] · Round 1: (→Sim) Sim represents each honest party Receives from the adversary Receive

[0718] · Round 2: (Sim→) Represents each honest party Sim performs the following for each :

[0719] (a) Compute z i，j = TOPRF.Sim.Eval(c i )。

[0720] (b) Randomly and uniformly select the ciphertext ct i，j 。

[0721] (c) Send (z i，j , ct i，j ) to Party

[0722] · Output computation phase: Sim performs the following:

[0723] (a) Send a message to the ideal functionality

[0724] i. For each Based on the adversary's queries to the oracle RO, run the algorithm TOPRF.Sim.Ext to compute We assume that the evaluation procedure must perform all RO calls in parallel to allow extraction. This can be enforced in the protocol design, and we do not mention this explicitly to reduce the exposition.

[0725] ii. Query the ideal functionality by inputting to receive the output

[0726] (b) For each Let

[0727] (c) Represent each honest party P j , for each Set H(h i ||j) such that Select R as follows i，j .

[0728] (d) If then proceed with:

[0729] i. Randomly and uniformly select each R i，j .

[0730] (e) If For each honest party P j , proceed with:

[0731] i. Select

[0732] ii. Let where the selection is made such that the adversary's token output computation process produces an output

[0733] 2. Hybrids

[0734] We now prove that the above simulation strategy is successful against all malicious PPT adversaries. That is, in the real world and the ideal world, the adversary's observations and the honest parties' outputs are computationally indistinguishable. We will show this through a series of computationally indistinguishable hybrids, where the first hybrid Hyb 0 corresponds to the real world, and the last hybrid Hyb 7 corresponds to the ideal world.

[0735] 1. Hyb 0 - Real world: In this hybrid, consider the simulator SimHyb that plays the role of an honest party in the real world.

[0736] When the honest party is P * :

[0737] 2. Hyb 1 - Case 1: Simulate TOPRF encoding. In this hybrid, SimHyb computes the first-round message by running the simulator TOPRF.Sim.Encode(·) for each representing P * as in the first round of the ideal world to compute the encoding c i .

[0738] 3. Hyb 2 – Case 1: Send a message to the ideal functionality. In this hybrid, SimHyb runs the "send a message to the ideal functionality" step as Sim does after the second round of the simulation strategy in Case 1, rather than computing the output as the honest party P * does in the real world.

[0739] When the attacker is P * :

[0740] 4. Hyb 3 – Case 2: Sending a message to the ideal functionality. In this hybrid, SimHyb runs the "sending a message to the ideal functionality" step as Sim does after round 2 of the simulated strategy case 2. That is, SimHyb runs the extractor TOPRF.Sim.Ext to compute and queries the ideal functionality with this.

[0741] 5. Hyb 4 – Case 2: Simulating the TOPRF evaluation. In this hybrid, in round 2, SimHy computes the TOPRF evaluation response by running the algorithm TOPRF.Sim.Eval as in the ideal world.

[0742] 6. Hyb 5 – Case 2: In this hybrid, when the output from the ideal functionality is received, on behalf of each honest party P j , SimHyb sets the exponent of each y i，j to a uniformly random value R i，j instead of (sk i，j + r i，j ).

[0743] 7. Hyb 6 – Case 2: In this hybrid, when the output from the ideal functionality is received, instead of computing the ciphertext ct i，j as before, SimHyb randomly and uniformly selects ct i，j and responds to the random oracle queries to set the plaintext for decryption as in the ideal world.

[0744] 8. Hyb 7 – Case 2: In this hybrid, when the output of the ideal functionality is received, SimHyb computes the ciphertext ct i，j and the response to the RO queries exactly as in the ideal world. This hybrid corresponds to the ideal world.

[0745] We now prove that each pair of consecutive hybrids is computationally indistinguishable.

[0746] Lemma 13 Assuming the security of the threshold oblivious pseudorandom function TOPRF, Hyb 0 is computationally indistinguishable from Hyb 1 .

[0747] Proof. The only difference between these two hybrids is that in Hyb 0 , SimHyb computes each value \(c\) i by running the honest encoding algorithm TOPRF.Encode, while in Hyb 1 , it computes the said value by running the simulated encoding algorithm TOPRF.Sim.Encode. Suppose there exists an adversary that can distinguish these two hybrids with non-negligible probability. We can use to construct an adversary that can distinguish the real encoding and the simulated encoding with non-negligible probability, thus contradicting the security of TOPRF.

[0748] Lemma 14 Assuming the correctness of the threshold oblivious pseudorandom function TOPRF, the correctness of the private-key encryption scheme, and the correctness of the robust secret sharing scheme, Hyb 1 is computationally indistinguishable from Hyb 2 .

[0749] Proof. The only difference between these two hybrids is that in Hyb 2 , SimHyb checks whether the adversary has indeed computed its messages honestly and aborts if not. However, in Hyb 1 , SimHyb aborts only if the output computation phase is not successful. Therefore, we can observe that, assuming the correctness of the primitives used - namely, the threshold oblivious pseudorandom function TOPRF, the private-key encryption scheme, and the robust secret sharing scheme - Hyb 1 is computationally indistinguishable from Hyb 2 .

[0750] Lemma 15 Assuming the correctness of the extractor TOPRF.Sim.Ex of the threshold oblivious pseudorandom function TOPRF, Hyb 2 is computationally indistinguishable from Hyb 3 .

[0751] Proof. The only difference between these two hybrids is that in Hyb 3 , SimHyb also runs TOPRF.Sim.Ext based on the adversary's queries to the random oracle RO to extract the adversary's input Therefore, the only difference in the adversary's observations is whether SimHyb aborts with non-negligible probability because the extractor TOPRF.Sim.Ext aborts with non-negligible probability. Therefore, we can prove that, assuming the correctness of the extractor TOPRF.Sim.Ext of the threshold oblivious pseudorandom function TOPRE, Hyb 2 is computationally indistinguishable from Hyb3 Indistinguishable.

[0752] Lemma 16 Assuming the security of the threshold oblivious pseudorandom function TOPRF, Hyb 3 is computationally indistinguishable from Hyb 4 Indistinguishable.

[0753] Proof. The only difference between the two hybrids is that for each honest party P j , in Hyb 3 , SimHyb computes each value z i，j by running the honest evaluation algorithm TOPRF.Eval, while in Hyb 4 , it computes the value by running the simulated evaluation algorithm TOPRF.Sim.Eval. Suppose there exists an adversary that can distinguish the two hybrids with non-negligible probability. We can use to construct an adversary that can distinguish the real and simulated evaluation responses with non-negligible probability, thus contradicting the security of TOPRF.

[0754] Lemma 17 Assuming the correctness of the threshold oblivious pseudorandom function, the security of the private-key encryption scheme, the security of the threshold linear secret-sharing scheme, and the security of the robust linear secret-sharing scheme, Hyb 4 is computationally indistinguishable from Hyb 5 Indistinguishable.

[0755] Proof. In the scenario where the ideal functionality outputs , we know that the adversary's input matches the vector in at most (d - 1) positions. Therefore, according to the correctness of the TOPRF scheme, for each honest party P j , the adversary learns the decryption keys of at most (d - 1) out of the ciphertexts . Thus, from the security of the secret-key encryption scheme, the adversary learns at most plaintexts out of (d - 1).

[0756] Now, in Hyb 4 , for each party P j , for each i ∈ [l] for which the adversary learns its plaintext, the exponent in the plaintext y i，j is of the form (sk i，j +r i，j ), where r i，j is a secret sharing of 0, while in Hyb 5In it, the exponents are randomly and uniformly selected. Therefore, since the secret sharing scheme can statistically hide the secret as long as at most (d - 1) shares are revealed, we can prove that if there is an adversary who can distinguish between these two hybrids with non-negligible probability then we can use to construct an adversary who can distinguish between a set of (d - 1) real shares and a set of (d - 1) random values with non-negligible probability, thus breaking the security of the secret sharing scheme, which is a contradiction.

[0757] Lemma 18 Hyb 5 is statistically indistinguishable from Hyb 6 .

[0758] Proof. Note that from Hyb 5 to Hyb 6 , we only made a syntactic change. That is, instead of actually encrypting the required plaintext during encryption, we use a random oracle to program in the decryption key to allow the adversary to decrypt and learn the same required plaintext.

[0759] Lemma 19 Hyb 6 is statistically indistinguishable from Hyb 7 .

[0760] Proof. In the scenario where the ideal functionality outputs , we know that the adversary's input matches the vector in at least d positions. For each honest party P j , the adversary learns the plaintext {y i，j} for each position i where there is a match.

[0761] Now, in Hyb 6 , for each party P j , for each i ∈ [l] where the adversary learns its plaintext, the exponent in the plaintext y i，j is of the form (sk i，j +r i，j ), where r i，j is a secret sharing of 0. However, in Hyb 7 , the sk i，j value in the exponent is not selected as the secret share of the threshold signature key sharing , but is chosen in such a way that the adversary recovers the same output. There are no other differences between these two hybrids, and it is easy to observe that the difference between these two hybrids is only syntactic, so they are statistically indistinguishable.

[0762] X. Protocols Using Security Schemes

[0763] A secure sketch is a basic building block of a fuzzy extractor. We construct the FTTG protocol by combining any information-theoretic secure sketch and any threshold oblivious PRF. Due to the information-theoretic nature of the secure sketch, this protocol has the remarkable property that the probability of success of an offline attack is the same regardless of the attacker's computational power or the number of brute-force trials. However, if a party starts the protocol with a "nearby" measurement, it will recover the actual template. Also, for the same reason, the template cannot be fully hidden. In other words, this protocol has an inherent leakage on the template generated by the underlying secure sketch instantiation. In the current definition of all input setting functions L c returning the correct template as well as setting L f , L m returning ⊥, it is easy to fully exhibit the first distinct property. To capture the template leakage, we introduce a new query to the ideal functionality.

[0764] Consider another additional parameter, the leakage function When receiving a query of the form ("template leakage", sid, ) from S, first check whether the tuple is recorded. If not found, do nothing; otherwise, reply to S with ("leakage", ). The extended ideal functionality identical to but with this additional query is called

[0765] Now we present a protocol below that implements with some reasonable leakage. For simplicity, we only present the protocol for semi-honest adversaries in the secure region only. Adding a general NIZK proof has the potential to make it secure against malicious adversaries.

[0766] A. Setup

[0767] In the setup phase, the following algorithm is executed by a trusted authority:

[0768] · Run TOPRF setup([[sk OP , pp OP ) ← TOPRF.Setup(1 K , n, t).

[0769] · Compute

[0770] · For each i ∈ [n], give to party P i .

[0771] B. Register P i

[0772] P i Each party interacts with every other party to register its own template:

[0773] · Sample a random vector from the distribution Sample a random vector

[0774] · Run TOPRF encoding for some randomness rand to generate c ← TOPRF.Encode(w, rand) and send c to each one.

[0775] · Each party P j (j ≠ i) responds with its corresponding toprf evaluation

[0776]

[0777] · P i The party combines them after receiving at least t - 1 responses from a certain set (such as) S to compute h := TOPRF.Combine(w, {j, z j} j∈S∪{i} , rand).

[0778] · P i The party computes the key K for all j ∈ [n] j := H(h, j).

[0779] · P i The party also computes s ← Sketch(w).

[0780] · P i The party sends (K j , s) to each party P j .

[0781] C. Login phase

[0782] In the login phase, we consider party P with input vector u and message m for which it wants a related token. Party P i selects a set of t - 1 other parties {P i} j and P j∈S and interacts with them in the following four - round protocol. The arrows in the first round can indicate that the messages in this round are sent from party P k and are sent i from party P

[0783] · Round 1: :(P i →) P i Contacts all parties in set S via an initialization message that contains the message m to be signed and its measurement - extractable commitment Com(u).

[0784] · Round 2: (→P i ) Each party P i sends the sketch s back to P for j ∈ S i .

[0785] · Round 3: (P i →) After receiving all s, P i performs the following steps:

[0786] (a) Check if s matches. If not, abort; otherwise, proceed to the next step;

[0787] (b) Perform reconstruction w := Recon(u, s);

[0788] (c) Compute the TOPRF encoding using some new randomness rand

[0789] c := TOPRF.Encode(w, rand) and send c to all P in S j .

[0790] · Round 4: (→P i ) After receiving c from P i , for each party P with j ∈ S j performs the following steps:

[0791] (a) Compute the TOPRF evaluation

[0792] (b) Compute the partial signature on m as

[0793] (c) Encrypt the partial signature as ct j ← enc(K j , σ j ).

[0794] (d) Send the tuple (z j , ct j ) to P i

[0795] · Output Computation: After receiving all tuples (z j ) from the parties {P j∈[S]} j , ct j )

[0796] (a) P i combines the TOPRFs as z ← TOPRF.Combine(w, {j, z j} j∈S , rand);

[0797] (b) Then compute K j := H(z, j);

[0798] (c) Use K j to decrypt each ct j to recover all partial signatures σ j .

[0799] (d) Combine the partial signatures to obtain the token Token and output it.

[0800] D. Token Verification

[0801] Given the verification key vk TS , message m and token Token, if TS.Verify(vk TS , m, Token outputs 1, then the token verification algorithm outputs 1.

[0802] Correctness: The correctness of the protocol directly follows from the correctness of the underlying primitives.

[0803] E. Security Analysis

[0804] We prove that the above protocol realizes the extended ideal functionality in the presence of a semi - honest static adversary corrupting at most t - 1 parties Specifically, we formally prove (informally) Theorem 5 in this section. We do this by constructing a polynomial - time simulator as follows:

[0805] Simulator S:

[0806] During the setup, the simulator generates the signature key - pair for the threshold signature and forwards the secret key shares to the corrupted parties. The simulator also generates the TOPRF key and forwards the key shares to the corrupted parties. The simulator also generates the parameters for the extractable commitment and keeps the trapdoor secret.

[0807] After registration is complete, the simulator makes "template - leakage" queries to obtain some leakage of the template and uses the leakage to simulate a fake profile for the corrupted parties.

[0808] To simulate the login phase, the simulator works as follows, depending on whether the initiator is corrupted. If the initiator is honest, the simulator can easily simulate the honest - party view by correctly using the TOPRF share of the honest party and using dummy measurements. If the initiator has been corrupted, the simulator extracts the input measurements from the extractable commitment Com(u), and then uses the measurements to make a "test - password" query to the ideal functionality If u is close to the template, the simulator will successfully register the signature and then return the signature to the initiator in a threshold manner (which can be easily done by adding zero secret shares).

[0809] We believe that for any PPT adversary The above simulator successfully simulates the observations in the ideal world, which is computationally indistinguishable from the real world. Notice some results from the above description.

[0810] Due to the access leaked by the template query, the registration process is well simulated. Note that without such access, it is impossible to simulate this step. To prove this, we mention the simple attack when the attacker registers the emulation template, say the string 0 s . Then there is no security sketch in guaranteed form. Therefore, without the leaked access, the simulator will have no clue about the template. However, given the leaked access, the simulator can reconstruct the whole template (because without entropy, the information can be compressed within the allowed leakage range).

[0811] Attributed to the template privacy guarantee provided by the underlying TOPRF, the login phase initiated by honest parties is correctly simulated. Note that in this case, the adversary does not learn the signature, so it is not necessary to register the correct signature with the ideal functionality in the simulation. In another case, when the compromised party initiates a session, the extractability of the commitment scheme guarantees that the extracted commitment is indeed the correct input of the attacker, and then using the "test password" query, the simulator can correctly generate the signature when correctly guessing a close match.

[0812] XI. COMPUTER SYSTEM

[0813] Any computer system mentioned in this article can utilize any suitable number of subsystems. Figure 8 Examples of such subsystems in the computer device 700 are shown in. In some embodiments, the computer system includes a single computer device, where the subsystems can be components of the computer device. In other embodiments, the computer system can include multiple computer devices with internal components, and each computer device is a subsystem. The computer system can include desktop and laptop computers, tablets, mobile phones, and other mobile devices.

[0814] Figure 8 The subsystems shown in are interconnected by a system bus 75. Additional subsystems are shown, such as a printer 74, a keyboard 78, a storage device 79, a monitor 76 coupled to a display adapter 82, etc. Peripheral devices and I / O devices coupled to an input / output (I / O) controller 71 can be through any number of devices known in the art, such as input / output (I / O) ports 77 (e.g., USB, ) is connected to a computer system. For example, the I / O port 77 or the external interface 81 (such as Ethernet, Wi-Fi, etc.) can be used to connect the computer system 10 to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus 75 allows the central processing unit 73 to communicate with each subsystem and control the execution of instructions from the system memory 72 or the storage device 79 (for example, a fixed disk such as a hard disk drive or an optical disc), as well as the exchange of information between subsystems. The system memory 72 and / or the storage device 79 can embody a computer-readable medium. Another subsystem is the data acquisition device 85, such as a camera, a microphone, an accelerometer, etc. Any data mentioned herein can be output from one component to another component and can be output to the user.

[0815] The computer system can include multiple identical components or subsystems, which are connected together, for example, through the external interface 81, through an internal interface, or via a removable storage device that can be connected and removed from one component to another component. In some embodiments, the computer system, subsystem, or device can communicate through a network. In such cases, one computer can be regarded as a client, and another computer can be regarded as a server, where each can be part of the same computer system. The client and the server can each include multiple systems, subsystems, or components.

[0816] Aspects of the embodiments can be implemented in the form of control logic using hardware circuitry (such as an application-specific integrated circuit or a field-programmable gate array) and / or in a modular or integrated manner using computer software by a generally programmable processor. As used herein, a processor can include a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked, as well as dedicated hardware. Based on the disclosures and teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing the embodiments of the present invention using hardware and combinations of software and hardware.

[0817] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission. Suitable non-transitory computer-readable media can include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0818] Such programs can also be encoded and transmitted using a carrier signal suitable for transmission via wired, optical, and / or wireless networks compliant with various protocols, including the Internet. Thus, a computer-readable medium can be created using a data signal encoded with such a program. A computer-readable medium encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, a CD, or an entire computer system), and can be on or within different computer products in a system or network. A computer system can include a monitor, a printer, or other suitable display for providing any of the results mentioned herein to a user.

[0819] Any method described herein can be performed, in whole or in part, by a computer system including one or more processors configured to perform the steps. Thus, embodiments can relate to computer systems configured to perform the steps of any method described herein, which may have different components for performing the corresponding steps or groups of corresponding steps. Although presented as numbered steps, the method steps herein can also be performed simultaneously or in a different order. Additionally, portions of these steps can be used in conjunction with portions of other steps from other methods. Similarly, all or part of one step can be optional. Additionally, any step of any method can be performed by a module, a circuit, or other means for performing these steps.

[0820] The specific details of particular embodiments can be combined in any suitable manner without departing from the spirit and scope of the embodiments of the present invention. However, other embodiments of the present invention can relate to particular embodiments associated with each individual aspect or a particular combination of these individual aspects.

[0821] The foregoing description of the exemplary embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and many modifications and variations are possible in light of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated.

[0822] Unless expressly indicated to the contrary, the recitation “a” or “an” or “the” is intended to mean “one or more.” The use of “or” is intended to mean “inclusive or” rather than “exclusive or” unless expressly indicated to the contrary.

[0823] All patents, patent applications, publications, and descriptions mentioned in this document are hereby incorporated by reference in their entirety for all purposes. This is not an admission that they are prior art.

[0824] XII. References

[0825] [1] Google Pixel Fingerprint. https: / / support.google.com / pixelphone / answer / 6285273?hl=en. Accessed October 2, 2018. 1

[0826] [2] About Face ID advanced technology. https: / / support.apple.com / en-us / HT208108. Accessed October 2, 2018. 1

[0827] [3] FIDO Alliance. https: / / fidoalliance.org / . Accessed October 2, 2018. 1

[0828] [4] Yevgeniy Dodis, Leonid Reyzin, and Adam Smith. Fuzzy extractors: How to generate strong keys from biometrics and other noisy data. In Christian Cachin and Jan Camenisch (Eds.), Advances in Cryptology - EUROCRYPT 2004, Lecture Notes in Computer Science, Volume 3027, 523 - 540, Interlaken, Switzerland, May 2 - 6, 2004. Springer, Heidelberg, Germany. 2

[0829] [5] Pratyay Mukherjee and Daniel Wichs. Two - round multiparty computation via multikey fhe. Annual International Conference on the Theory and Applications of Cryptographic Techniques, 735 - 763. Springer, 2016. 3, 5, 16

[0830] [6] Chris Peikert and Sina Shiehian. Multi-key fhe from lwe, revisited. TCC, 2016.3, 5, 16

[0831] [7] Zvika Brakerski and Renen Perlman. Lattice-based fully dynamic multi-key fhe with short ciphertexts. CRYPTO, pp. 190 - 213. Springer, 2016.3, 5, 16

[0832] [8] Sanjam Garg and Akshayaram Srinivasan. Two-round multiparty secure computation from minimal assumptions. EUROCRYPT, 2018.3, 5, 16

[0833] [9] Fabrice Benhamouda and Huijia Lin. k-round mpc from k-round ot via garbled interactive circuits. EUROCRYPT, 2018.3, 5, 16

[0834]

[10] Shashank Agrawal, Peihan Miao, Payman Mohassel and Pratyay Mukherjee. Pasta: Password-based threshold authentication. IACR Cryptology ePrint Archive, 2018:885, 2018.4, 8

[0835]

[11] Prabhanjan Ananth, Saikrishna Badrinarayanan, Aayush Jain, Nathan Manohar and Amit Sahai. From FE combiners to secure MPC and back. IACR Cryptology ePrint Archive, 2018:457, 2018.5, 16

[0836]

[12] Andrew Chi-Chih Yao. How to generate and exchange secrets (extended abstract). Proceedings of the 27th Annual Symposium on Foundations of Computer Science, Toronto, Canada, October 27 - 29, 1986, pp. 162 - 167. IEEE Computer Society, 1986.6

[0837]

[13] Payman Mohassel, Mike Rosulek and Ye Zhang. Fast and secure three - party computation: The garbled circuit approach. Edited by Indrajit Ray, Ninghui Li and Christopher Kruegel, Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, USA, October 12 - 16, 2015, pp. 591 - 602. ACM, 2015.7, 8

[0838]

[14] Pascal Paillier. Public - key cryptosystems based on composite degree residuosity classes. International Conference on the Theory and Applications of Cryptology, pp. 223 - 238. Springer, 1999.7, 10, 12, 24

[0839]

[15] Taher El Gamal. A public key cryptosystem and a signature scheme based on discrete logarithms. Edited by G.R. Blakley and David Chaum, Advances in Cryptology, Proceedings of CRYPTO 84, Santa Barbara, California, USA, August 19 - 22, 1984, Proceedings, Lecture Notes in Computer Science Vol. 196, pp. 10 - 18. Springer, 1984.7, 41

[0840]

[16] Alexandra Boldyreva. Threshold signatures, multisignatures and blind signatures based on the gap - diffie - hellman - group signature scheme. International Workshop on Public Key Cryptography, pp. 31 - 46. Springer, 2003.9, 10, 33, 34

[0841]

[17] Victor Shoup. Practical threshold signatures. Edited by Bart Preneel, Advances in Cryptology - EUROCRYPT 2000, International Conference on the Theory and Applications of Cryptographic Techniques, Bruges, Belgium, May 14 - 18, 2000, Lecture Notes in Computer Science Vol. 1807, pp. 207 - 220. Springer, 2000.9, 33

[0842]

[18] Oded Goldreich. The Foundations of Cryptography - Volume 2, Basic Applications. Cambridge University Press, 2004.10

[0843]

[19] Rafail Ostrovsky, Anat Paskin - Cherniavsky and Beni Paskin - Cherniavsky. Maliciously circuit - private fhe. International Cryptology Conference, pp. 536 - 553. Springer, 2014.10

[0844]

[20] Ronald Cramer, Ivan and Jesper B Nielsen. Multiparty computation from threshold homomorphic encryption. International Conference on the Theory and Application of Cryptology, pp. 280-300. Springer, December 2001

[0845]

[21] William Aiello, Yuval Ishai, and Omer Reingold. Priced oblivious transfer: How to sell digital goods. In Birgit Pfitzmann (ed.), Advances in Cryptology - EUROCRYPT 2001, International Conference on the Theory and Application of Cryptology, Innsbruck, Austria, May 6-10, 2001, Lecture Notes in Computer Science Vol. 2045, pp. 119-135. Springer, 2001.24

[0846]

[22] Moni Naor and Benny Pinkas. Efficient oblivious transfer protocols. In S. Rao Kosaraju (ed.), Proceedings of the Twelfth Annual ACM-SIAM Symposium on Discrete Algorithms, January 7-9, 2001, Washington, D.C., USA, pp. 448-457. ACM / SIAM, 2001.24

[0847]

[23] Chris Peikert, Vinod Vaikuntanathan, and Brent Waters. A framework for efficient and composable oblivious transfer. In David A. Wagner (ed.), Advances in Cryptology - CRYPTO 2008, The 28th Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 2008. Proceedings, Lecture Notes in Computer Science Vol. 5157, pp. 554-571. Springer, 2008.24, 42

[0848]

[24] Shai Halevi and Yael Tauman Kalai. Smooth projective hashing and two-message oblivious transfer. Journal of Cryptology, 25(1), 2012.24

[0849]

[25] Stanislaw Jarecki, Aggelos Kiayias, Hugo Krawczyk, and Jiayu Xu. TOPPSS: cost-minimal password-protected secret sharing based on threshold OPRF. In Dieter Gollmann, Atsuko Miyaji, and Hiroaki Kikuchi (Eds.), Applied Cryptography and Network Security - The 15th International Conference, ACNS 2017, Kanazawa, Japan, July 10 - 12, 2017, Proceedings, Lecture Notes in Computer Science Volume 10355, pp. 39 - 58. Springer, 2017.33, 43

[0850]

[26] Robert J. McEliece and Dilip V. Sarwate. On sharing secrets and reed-solomon codes. Communications of the ACM, 24(9):583 - 584, 1981.44

[0851]

[27] Pierre - Alain Dupont, Julia Hesse, David Pointcheval, Leonid Reyzin, and Sophia Yakoubov. Fuzzy password - authenticated key exchange. In Jesper Buus Nielsen and Vincent Rijmen (Eds.), Advances in Cryptology - EUROCRYPT 2018, pp. 393 - 424, Cham, 2018. Springer International Publishing.43, 44

[0852] XIII. Appendix A: Other Prerequisites

[0853] A. Threshold Oblivious Pseudo - Random Functions

[0854] We now define the notion of a threshold oblivious pseudorandom function (TOPRF) that is taken almost verbatim from Jarecki et al.

[25] . The reader is referred to the security definition in Jarecki et al.

[25] , and we only list the algorithms that form part of the primitive.

[0855] Definition 8 A threshold oblivious pseudorandom function (TOPRF) is a tuple of four PPT algorithms (TOPRF.Setup, TOPRF.ENcode, TOPRF.Eval, TOPRF.Combine) described as follows.

[0856] · TOPRF.Setup(1 λ , n, t) → ([sk], pp). It generates n secret key shares sk 1 , sk 2 ,..., sk n and the public parameters pp. The share sk i is given to party i. (pp will be an implicit input in the following algorithms.)

[0857] · TOPRF.Encode(x, ρ) := c. It generates an encoding c of the input x using the randomness ρ.

[0858] · TOPRF.Eval(sk i , c) := z i . It generates a share of the TOPRF value from the encoding. Party i computes the i-th share z i from c by running TOPRF.Eval with sk i .

[0859] · It uses the randomness ρ to combine the shares received from the parties in the set to generate the value h. If the algorithm fails, it outputs ⊥.

[0860] B. Robust Secret Sharing

[0861] We now give the definition of a robust secret sharing scheme that is taken almost verbatim from Dupont et al.

[26] .

[0862] Definition 9 Let q be a prime number of λ bits, F q be a finite field, n, t, m, where t < r ≤ n and m < r. A (n, t, r)-robust secret sharing scheme (RSS) consists of two probabilistic algorithms and with the following properties:

[0863] · t-privacy: For any where |A| < t and c ← projection of RSS.Share(s) is identically distributed to the projection

[0864] · r - Robustness: For any s ∈ F where |A| ≥ r q , any c output by RSS.Share(s) and any such that both hold

[0865] In other words, (n, t, r) - RSS can reconstruct the shared secret even if the adversary tampers with up to shares, and the set of every t shares is independently distributed from the shared secret s and thus does not reveal any information about it

[0866] We say that robust secret sharing is linear if the reconstruction algorithm RSS.Recon performs only linear operations on its input shares, similar to standard secret sharing

[0867] Lemma 1 is introduced. The Shamir secret sharing scheme is a robust linear secret sharing scheme

[0868] The above lemma is borrowed from the instantiation lemma 5 of Dupont et al.

[26] , using the research of McEliece and Sarwate

[27] , as described by Dupont et al.

[26]

Claims

1. A method for a first electronic device to authenticate a user to a second electronic device using biometric information, the method comprising, performed by the first electronic device: Storing a first key share of a private key, wherein the second electronic device stores a public key associated with the private key, and wherein one or more other electronic devices of the user store other key shares of the private key; Storing a first template share of the user's biometric template, wherein the one or more other electronic devices of the user store other template shares of the biometric template; Receiving a challenge message from the second electronic device; Measuring, by a biometric sensor of the first electronic device, a set of biometric characteristics of the user to obtain a measurement vector composed of measured values of the set of biometric characteristics, and wherein the biometric template includes a template vector composed of measured values of the set of biometric characteristics previously measured from the user; Sending the measurement vector and the challenge message to the one or more other electronic devices; Receiving at least T partial computations, including one or more partial computations from the one or more other electronic devices, wherein each of the at least T partial computations is generated using a corresponding template share, a corresponding key share, and the challenge message; Generating a signature of the challenge message using the at least T partial computations; And Sending the signature to the second electronic device.

2. The method according to claim 1, further Comprising: Generating a first partial computation using the first template share, the first key share, and the challenge message, and wherein the signature of the challenge message is further generated using at least the first partial computation.

3. The method according to claim 2, wherein the first partial computation is one of the at least T partial computations.

4. The method according to claim 1, wherein each of the one or more other electronic devices generates one of the at least T partial computations using a corresponding template share, a corresponding key share, and the challenge message.

5. The method according to claim 1, wherein the first template share and the other template shares are encryptions of the biometric template.

6. The method according to claim 1, further comprising encrypting the measurement vector.

7. The method according to claim 1, further comprising performing a registration process by: Measuring, by the biometric sensor of the first electronic device, the biometric template of the user; Generating the public key, the private key, and the key shares of the private key; Generating the first template share and the other template shares of the biometric template; Deleting the private key and the biometric template; And Sending the public key to the second electronic device.

8. The method according to claim 7, further Comprising: Generating a cryptographic program that conditionally uses a set of key shares to generate the signature when the measurement vector is within a threshold of the template vector.

9. The method according to claim 8, wherein the cryptographic program includes a garbled circuit.

10. The method according to claim 8, wherein the cryptographic program uses additive homomorphic encryption.

11. The method according to claim 8, wherein threshold fully homomorphic encryption is used to encrypt the measurement vector and the template vector, and wherein the cryptographic program determines that the measurement vector is within the threshold of the template vector by calculating the inner product of the measurement vector and the template vector.

12. The method according to claim 8, wherein the cryptographic program reconstructs the biometric template using the template shares.

13. The method according to claim 1, wherein the signature of the challenge message is generated using the at least T parts calculation comprising: adding the additively homomorphically encrypted shares of the partial distances between the template shares and the measurement vector to obtain a total distance; comparing the total distance with a threshold; and when the total distance is less than the threshold, signing the challenge message using the partial signature calculated using the at least T parts.

14. The method according to claim 13, wherein the addition and comparison are performed using a garbled circuit.

15. The method according to claim 14, wherein the garbled circuit outputs a string and wherein the string is used to decrypt the partial signature calculated using the at least T parts.

16. The method according to claim 14, wherein the garbled circuit outputs the partial signature calculated using the at least T parts.

17. The method according to claim 13, wherein the additively homomorphically encrypted shares of the partial distances have been partially decrypted by the one or more other electronic devices.

18. The method according to claim 13, wherein the partial distance is determined using a cosine similarity or Hamming distance measure.

19. The method according to claim 13, additionally comprising: generating a zero-knowledge proof verifying the comparison of the total distance with the threshold; and sending the zero-knowledge proof to the one or more other electronic devices for verification.

20. The method according to claim 1, additionally comprising: generating a zero-knowledge proof verifying the at least T parts calculation; and sending the zero-knowledge proof to the one or more other electronic devices for verification.

21. A computer product comprising a computer-readable medium storing multiple instructions for controlling a computer system to execute the method according to any one of claims 1-20.

22. A system for biometric authentication, the system comprising: the computer product according to claim 21; and one or more processors for executing the instructions stored on the computer-readable medium.

23. A system for biometric authentication, the system comprising means for executing the method according to any one of claims 1-20.

24. A system for biometric authentication, the system comprising one or more processors configured to execute the method according to any one of claims 1-20.

25. A system for biometric authentication, the system comprising modules that respectively perform the steps of the method according to any one of claims 1-20.

Images