Privacy-Preserving Biometric Matching Using Homomorphic Encryption

by   Gaëtan Pradel, et al.

Biometric matching involves storing and processing sensitive user information. Maintaining the privacy of this data is thus a major challenge, and homomorphic encryption offers a possible solution. We propose a privacy-preserving biometrics-based authentication protocol based on fully homomorphic encryption, where the biometric sample for a user is gathered by a local device but matched against a biometric template by a remote server operating solely on encrypted data. The design ensures that 1) the user's sensitive biometric data remains private, and 2) the user and client device are securely authenticated to the server. A proof-of-concept implementation building on the TFHE library is also presented, which includes the underlying basic operations needed to execute the biometric matching. Performance results from the implementation show how complex it is to make FHE practical in this context, but it appears that, with implementation optimisations and improvements, the protocol could be used for real-world applications.



There are no comments yet.


page 1

page 2

page 3

page 4


PassBio: Privacy-Preserving User-Centric Biometric Authentication

The proliferation of online biometric authentication has necessitated se...

Privacy-Preserving Speaker Recognition with Cohort Score Normalisation

In many voice biometrics applications there is a requirement to preserve...

Cancellable Template Design for Privacy-Preserving EEG Biometric Authentication Systems

As a promising candidate to complement traditional biometric modalities,...

Inference-Based Similarity Search in Randomized Montgomery Domains for Privacy-Preserving Biometric Identification

Similarity search is essential to many important applications and often ...

GaitPrivacyON: Privacy-Preserving Mobile Gait Biometrics using Unsupervised Learning

Numerous studies in the literature have already shown the potential of b...

Increasing Adversarial Uncertainty to Scale Private Similarity Testing

Social media and other platforms rely on automated detection of abusive ...

On the Root of Trust Identification Problem

Root of Trust Identification (RTI) refers to determining whether a given...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

This paper proposes a privacy-preserving biometric-based authentication protocol based on fully homomorphic encryption (FHE), designed for use in the case where the biometric sample for a user is gathered by a local device but matched against a biometric template by a remote server. The goal is to enable this to occur without the remote server,modeled as a honest-but-curious adversary,gaining access to any of the sensitive biometric data. The privacy-preserving and authentication properties of the protocol are formally established. A proof-of-concept C/C++ implementation building on the TFHE library due to Chillotti et al. [2] has also been developed, in which face matching is used as the biometric. Performance results from this implementation are presented. The results of the implementation confirm the difficulty of making FHE practical in such a scenario, but we suspect that, with optimisations and improvements, the protocol could be used for real-world applications.

As part of the proof-of-concept, all the elementary operations necessary to execute the protocol using FHE were implemented. Thus, as a side contribution, we have provided a set of elementary arithmetic routines in the ciphertext domain111The implementation is hosted here:, which could be useful for other prototype implementations.

Homomorphic encryption

Homomorphic encryption allows one to perform computations on encrypted data, without ever decrypting it. This enables users to perform operations in untrusted environments. The idea of performing computations on encrypted data was introduced in by Rivest, Shamir and Adleman [3]. While many homomorphic schemes have been proposed [4, 5, 6, 7], it wasn’t until that Gentry presented [8] the first FHE scheme, based on ideal lattices. Gentry’s breakthrough rests on a technique called bootstrapping. An FHE scheme based on Gentry’s blueprint enables an arbitrary number of additions and multiplications, i.e. any function, to be computed on encrypted data. Since then, many other schemes have been proposed [9, 10, 11, 12, 13, 14], including schemes not using the bootstrapping technique. For example, in 2012, Brakerski, Gentry and Vaikuntanathan[15] presented a scheme based on the ring version of the Learning With Errors problem, introduced by Regev [16]. A second type of FHE scheme was introduced by Gentry, Sahai and Waters [17]. This scheme was further improved [18, 19], and most recently by Chillotti et al. [20, 2].

Biometric authentication

The use of biometrics for authentication has been discussed for several decades, and has seen growing use. International organisations suggest passwordless222See for example the World Economic Forum:

systems for authentication, and biometrics can solve this issue. Advances mean that in some circumstances biometric recognition algorithms perform better than humans, even for face recognition

[21]. Nonetheless, biometric authentication faces a range of challenges [22], in particular regarding the protection of users’ sensitive data. Biometric data, such as a fingerprint, is fixed for a lifetime, meaning that its use gives rise to significant privacy concerns. Ideally, biometric data should not be processed without protection or anonymisation. Homomorphic encryption offers a possible solution to this problem [22], as it allows the authentication provider to perform biometric matching on (encrypted) data, while protecting the privacy of sensitive biometric data.

Related work

The use of homomorphic cryptography in the context of biometric matching is not new [23, 24]. However, most previous work uses partially homomorphic encryption and not FHE. Some of this work has promising performance results, e.g. Blanton and Gasti [25]

who calculate the Hamming distance between two iris feature vectors in only 150 ms. However, because of the additive-only (partially homomorphic) characteristic of the encryption schemes they use, they are not able to evaluate a circuit much more complex than for Hamming distance. Yasuda et al. 

[26] used a homomorphic scheme that also enables multiplications in the ciphertext domain, but still only compute the Hamming distance between two biometric vectors; moreover, the approach is vulnerable against malicious attackers [27]. Back in 2008, Bringer and Chabanne [28] proposed an authentication protocol based on the homomorphic properties of two partially homomorphic encryption schemes.

Biometric matching based on FHE has been previously proposed; perhaps the first example is the private face verification system of Troncoso-Pastoriza et al. [29]. Cheon et al. [30] proposed Ghostshell, a tool that works on iris templates, that is computationally costly. More recently, Boddeti [31] showed how to execute a secure face matching using the Fan-Vercauteren FHE scheme [32] and obtained practical results by packing the ciphertexts in a certain way.

Structure of the paper

Section II introduces the notions necessary for the rest of the paper. Sections III and IV are the core of the paper, presenting the design and security properties of the protocol. Finally, Sections V and VI give results from the protocol implementation and conclude the paper.

Ii Preliminaries

, , and represent the sets of natural numbers, integers, reals and bits, respectively.

Ii-a Security notions

We next introduce some formal security notions. For more complete versions of Definitions 1-5, see Goldreich [33].

Definition 1 (Negligible).

We say a function is negligible if for every polynomial there exists an such that, for all :

Definition 2 (Probability ensemble).

Let be a countable index set. A probability ensemble

indexed by I is a sequence of random variables indexed by

. Namely, any where each is a random variable, is an ensemble indexed by .

Definition 3 (Polynomial-time indistinguishability).

Suppose and are ensembles with index set where for all . Then and are said to be indistinguishable in polynomial-time if, for every probabilistic polynomial-time algorithm , every polynomial , and all sufficiently large :

We write

Remark 1.

We follow common practice and refer to computational indistinguishability instead of indistinguishability in polynomial-time.

Definition 4 (Statistical distance).

Suppose and are ensembles with index set where for all . Then the statistical distance function is defined as:

Definition 5 (Statistical indistinguishability).

Suppose and are ensembles with index set where for all . Then and are said to be statistically indistinguishable if their statistical distance is negligible.

We write .

Remark 2.

If the ensembles and are statistically indistinguishable, then they are also computationally indistinguishable. The converse is not true.

Definition 6 (Adversary).

An adversary for a cryptographic scheme is a polynomial-time algorithm (or a set of polynomial-time algorithms) that models a real-world attacker. It is equipped with defined computational resources and capabilities, and is designed to attack the security of the scheme typically as a participant in a security game.

Definition 7 (Challenger).

A challenger for a cryptographic scheme is a polynomial-time algorithm (or a set of polynomial-time algorithms) that models a real-world instance of the scheme. It is usually assumed to possess unlimited computational resources and capabilities, and is viewed as a ‘black box’ which responds to queries made by an adversary in a security game.

Definition 8 (Security game).

A security game models an attack on a cryptographic scheme involving an adversary and a challenger.

Definition 9 (Advantage).

In the context of a cryptographic scheme and a security game for this scheme, the advantage of an adversary is a function of the probability that the adversary wins the security game that measures the adversary’s improvement over random choice.

Ii-B Homomorphic Encryption

We next formally introduce homomorphic encryption and certain associated notions. For more complete versions of these definitions, see Armknecht et al. [34].

Definition 10 (Homomorphic Encryption scheme).

A homomorphic encryption scheme for a circuit family consists of four PPT algorithms , , , with the following properties.

  • . Given the security parameter , outputs a key triple made up of a secret key , a public key and an evaluation key . The plaintext space and the ciphertext space are determined by .

  • Given a public key and a plaintext , outputs a ciphertext .

  • Given a secret key and a ciphertext , outputs either the plaintext if or .

  • Given an evaluation key , a circuit , where is a circuit family (see Appendix A for details) and a ciphertext , outputs another ciphertext .

Remark 3.

Depending on the scheme, the evaluation key might be part of, or equal to, the public key . For simplicity of presentation, here and throughout we assume that the circuit input to has input size corresponding to the size of the input ciphertext(s).

Definition 10, and those below, holds for a range of types of plaintext, including both bit strings and vectors of plaintexts. Some algorithms, such as , take as input a security parameter , which will be denoted as such throughout this paper unless stated otherwise. This input is usually written in unary representation because we want an algorithm that runs in time polynomial in the size of to be considered as efficient. We refer to the outputs of as ‘fresh ciphertexts’ and those of as ‘evaluated ciphertexts’.

Definition 11 (Correctness).

Suppose , , , is a homomorphic encryption scheme with security parameter . We say is correct for a circuit family if correctly decrypts both fresh and evaluated ciphertexts, namely, for all , the following two conditions hold.

  • Suppose . If and then Else

  • For any key triple , any circuit , any plaintext and any ciphertext with , if then .

Definition 12 (Indistinguishability under Chosen-Plaintext Attacks security game).

Suppose is a homomorphic encryption scheme with security parameter . Suppose also that is a PPT adversary. The indistinguishability under chosen-plaintext attacks (IND-CPA) security game is as follows.

  1. A challenger runs and shares with .

  2. generates two distinct plaintexts and submits a query to the challenger to request the encryption of one of them with .

  3. The challenger chooses uniformly at random, computes and sends to .

  4. outputs a pair , where , and wins the game if .

We denote this security game by and a win in an instance of this security game by .

Definition 13 (Advantage for the IND-CPA security game).

Suppose is a homomorphic encryption scheme with security parameter . Suppose is an adversary in the IND-CPA security game. The advantage of with respect to , denoted , is defined to be:

Definition 14 (IND-CPA security).

Suppose , and are as in Definition 13. is IND-CPA secure if the advantage for in the IND-CPA security game is negligible.

Iii A novel privacy-preserving protocol

We now describe the privacy-preserving biometric matching protocol. In fact we give two descriptions: in §III-A we give an informal introduction, explaining the motivation for the design, and then in §III-B we give a formal description which we use as the basis for the analysis in Section IV. For simplicity of presentation we suppose that the public key and the evaluation key are equal.

Iii-a Informal description of the protocol

We describe a protocol involving two parties, a client and a server , where is acting on behalf of user . wishes to access a certain service, not offered by , which requires an initial authentication of the user associated with to . The process of authentication uses sensitive biometric data such as face images or iris information for that is gathered by . If successfully authenticates , sends an ID token , to . can now use to access the requested service.

Note that is trusted by to correctly gather a fresh biometric sample from . In the protocol, verifies that the gathered sample matches the appropriate user template, and also authenticates to . Note that the protocol neither provides authentication of to nor provides encryption of transferred messages; it is implicitly assumed that these properties are provided by the communications channel, e.g. using a server-authenticated TLS session.

In the description below, Step 0 (registration) is performed once before use of the protocol. Steps 1-4 of the protocol are performed every time the user wishes to be authenticated to (via ).

Step 0: Registration

generates a key pair for a homomorphic encryption scheme , and obtains by some means a biometric template for its associated user . then encrypts as and sends to via a trusted channel. stores , and subsequently uses it for biometric matching when the protocol is executed (see Step 2). In the remainder of this description we suppose that , by some means, is assured of the identity of and that the encrypted biometric template for is genuine.

Step 1: Initialisation

takes a fresh biometric sample from and, using , computes an encrypted version and sends it to .

Step 2: Construction of the Matching Token

Phase 1: Matching Computation

We suppose that is equipped with a biometric matching function which inputs a biometric template and a biometric sample and outputs an indication of whether there is a sufficiently close match between them. Suppose , where is the circuit family associated with which implements now computes

where is the encrypted version of a boolean indicating the success or not of the biometric matching, i.e. 

In a naïve version of the protocol, now sends the encrypted matching result ; decrypts it to obtain , and sends to . can now use to decide whether not to generate the ID Token . For obvious reasons this is not secure ( is not authenticated), and hence we need a slightly more elaborate protocol.

In order to enable to authenticate , we introduce the notion of a Matching Token, denoted by . In Phase 2 this token is constructed by as a function of (whilst still encrypted) in such a way that can, when provided by with a decrypted version of the token in Step 4, (a) verify its authenticity, and (b) determine the value of

Phase 2: Signature Computation  We suppose has an implementation of the function

first selects two random numbers and , and stores them for use in Step 4. next computes

In the encrypted domain of (under ), now uses to compute the encrypted matching token as:

where the circuit family associated with which implements That is, obtains although, of course, does not have access to ; i.e. at this stage does not know whether or not the biometric matching succeeded. sends now to .

Note that this part of the protocol requires to retain the random values and until Step 4, and hence the protocol is stateful.

Step 3: Decryption of

receives from and computes

At this point it is still the case that neither nor know whether the biometric matching succeeded. only possesses a string which looks random, and cannot decrypt any data encrypted with now sends to

Step 4: Authentication of

Phase 1: Verification

receives from , and checks whether it is equal to or . If so, has successfully authenticated ; if not rejects .

Phase 2: Token generation

generates an ID Token where , and otherwise, and sends it to . As a result, has a valid ID Token, which can be used to access the desired service, if and only if the biometric matching was successful and has authenticated .

Iii-B Formal description of the protocol

We now formally present the protocol, referred to as . The protocol is summarised in Figure 1, where is the security parameter of . Protocol initialisation, described immediately below, assumes Step 0 has been successfully completed.

Input to :

has a biometric sample , and a key pair generated with a homomorphic encryption scheme . This is represented by the tuple . We denote the plaintext space and the ciphertext space associated with by and respectively.

Input to :

has an encrypted biometric template generated by in a pre-computation phase. This is represented by the tuple

The following functions are used by

  • indicates whether or not two biometric values match, where is the set of possible biometric values and an output of 1 indicates a match.

  • creates a matching token from a boolean and two random numbers, where

The above two initialisations are expressed formally as .

Common input:

Both parties know the homomorphic encryption scheme and the public key generated by .

Protocol transcript:

  1. [label=()]

  2. [ Pre-computation]:

    1. [label=)]

    2. ;

    3. Take a fresh biometric sample from to be used as template;

    4. .

  3. [ Pre-computation]:

    1. [label=)]

    2. Send to .

  1. [ ] executes the following:

    1. Take a fresh biometric sample from ;

    2. Compute ;

    3. Send to .

  2. [ ] executes the following:

    1. (Phase 1) Compute ;

    2. (Phase 2) Generate ;

    3. Compute ;

    4. Compute ;

    5. Compute ;

    6. Send to .

  3. [ ] executes the following:

    1. Compute ;

    2. Send to .

  4. [ ] executes the following:

    1. If and , terminates execution;

    2. Compute

    3. Send to .

Fig. 1: Protocol summary

Iii-C Proof of knowledge

The protocol is an instance of an interactive proof system, as defined by Menezes et al. [35, Chapter 10]. We next show that is a proof of knowledge, i.e. it has the properties of completeness and soundness. The following definition is adapted from [35, Chapter 10].

Definition 15 (Completeness).

An authentication protocol is complete if, given an honest client and an honest server , the protocol succeeds with overwhelming probability (i.e.  accepts ’s claim).

Theorem 1 (Completeness).

The protocol is complete.


Suppose is run with an honest client that sends a validly constructed value for a sample to server We consider two cases.

  1. [label=()]

  2. Suppose the sample matches the template , i.e. suppose Then, by definition, , and thus Hence, if then Thus, accepts .

  3. Suppose the sample does not match the template , i.e. suppose .

    Then, by definition, , and thus . Hence, if then . Thus, does not accept

That is, accepts if and only if the sample matches the template . ∎

The following definition is adapted from [35, Chapter 10].

Definition 16 (Soundness).

An authentication protocol is sound if there exists an expected polynomial time algorithm with the following property: if a dishonest client (impersonating ) can with non-negligible probability successfully execute the protocol with , then can be used to extract from knowledge (essentially equivalent to ’s secret) which with non-negligible probability allows successful subsequent protocol executions.

We first need the following preliminary result.

Lemma 1.

Suppose a client engages in the protocol with the server , using sample , and that accepts . It follows that:

  1. [label=()]

  2. the sample matches the template held by ;

  3. has access to the value chosen by in Step 2b of .

  1. [label=()]

  2. Since accepts , it immediately follows from Theorem 1 that the sample matches the template .

  3. In Step 4 of , accepts if and only if the value sent by to in Step 3 equals . The result follows.

We can now give our main result.

Theorem 2.

The protocol is sound.


Suppose is run with a dishonest client , impersonating an honest client , that sends a validly constructed value for a sample to server in Step 1 of . Suppose also that there is a non-negligible probability that is accepted. We need to establish that can, with non-negligible probability, engage in further successful protocol executions with .

Since accepts in the protocol execution with non-negligible probability, by Lemma 1 we know that with non-negligible probability has access to , which was provided to in encrypted form in Step 2 of . Hence must have access to an oracle that, given an input encrypted using ’s public key, with non-negligible probability returns its decrypted version.

Assume a subsequent instance of the same protocol .

  1. In Step 1, uses the sample , computes using the public key of , and sends it to .

  2. Step 2 is executed as specified by , where the two random values chosen by are denoted by and . Clearly matches (from (a) above), and hence the value sent to will satisfy .

  3. In Step 3, uses oracle which will, with non-negligible probability, correctly decrypt ; that is, the value output by will satisfy with non-negligible probability. then sends to .

  4. In Step 4, since with non-negligible probability, will accept with non-negligible probability.

That is, there exists a PPT algorithm , using as a subroutine, that for any instance of can be used to arrange that will be accepted by with non-negligible probability. ∎

Iv Security properties

Iv-a Security model

We suppose the protocol is carried out in the real world between a challenger and an adversary. In the real world, adversaries can play the role of the client or the server. We suppose adversaries are static, i.e. they cannot change their role within an instance of the protocol, and cannot play both roles at the same time. We distinguish between two classes of adversary:

  • Honest-but-curious adversaries execute a protocol honestly, although ‘on the side’ they can make any other calculations with the purpose of obtaining information to which they are not entitled.

  • Malicious adversaries execute a protocol in ways not permitted in the specification, perform any calculations, and use any means to obtain information.

In our setting, we model an honest-but-curious adversary.

Iv-B Privacy of the biometric data

One of the main goals of is to give (and ) assurance regarding the privacy of biometric data shared with , i.e. all samples and templates. As we next show, this property relies on the IND-CPA security (see Definition 14) of the homomorphic encryption scheme.

Definition 17 (Privacy-preserving).

If a biometric authentication protocol preserves the privacy of the biometric data of the client against a honest-but-curious adversary (a server or external party), then the protocol is privacy-preserving.

Definition 18 (Privacy-preserving game).

Suppose the precomputation phase of the protocol is run with an honest client that sends a validly constructed encrypted value for template to server . Suppose also that is a PPT adversary. The privacy-preserving game is as follows.

  1. A challenger chooses uniformly at random and generates two distinct samples as follows.

    1. [label=()]

    2. , and

  2. The challenger encrypts the two samples as and

  3. The challenger sends to

  4. outputs a pair , where and wins the game if

We denote this security game by , where is the security parameter of the homomorphic encryption scheme and a win in an instance of this security game by .

Definition 19 (Advantage for the PRI-PRE game).

Suppose that , and are as in Definition 18. The advantage of the adversary with respect to , denoted by , is defined to be:

Definition 20 (PRI-PRE security).

Suppose , and are as in Definition 19. If the advantage for in the PRI-PRE game is negligible, then is PRI-PRE, i.e. privacy-preserving.

Theorem 3.

The protocol is privacy-preserving.


Suppose that the protocol is not privacy-preserving, i.e. by Definition 20, there exists an adversary that has a non-negligible advantage in the privacy-preserving game. By definition this means that has a distinguisher that distinguishes, with non-negligible probability, which of two encrypted samples and will match an encrypted template .

We next construct an adversary against the IND-CPA security of . Suppose generates a triple of values satisfying and . now submits the pair to a challenger in the IND-CPA security game. receives back from the challenger the ciphertext , where equals either or (with equal probability).

first computes and from and , and then runs the distinguisher with inputs and as the encrypted samples and as the encrypted template. If returns (which we call event ), then outputs in the IND-CPA game. If returns (which we call event ), then outputs in the IND-CPA game.

To evaluate the probability that wins the game, we consider two cases.

  • Suppose (event which has probability 0.5). Then the two encrypted samples and submitted to both match the template. Hence the probability that will return (event ) = the probability it returns (event ) = 0.5.

  • Suppose (event which also has probability 0.5). Then of the two encrypted samples and submitted to , only will match the template. Hence the probability that will return (event ) is , where is non-negligible (this follows since is a distinguisher).

Hence we have:

If occurs then, by assumption, outputs in the IND-CPA game. The probability this wins is simply . Similarly, if occurs then the probability of winning is . Hence, since events and are mutually exclusive, the probability that wins the game is:

By definition the advantage for is , which is non-negligible since is non-negligible. This contradicts the assumption that is IND-CPA secure, and hence is privacy-preserving. ∎

Iv-C Entity authentication

We next show that Steps 2–4(a) of constitute a secure authentication protocol. We follow the approach of Boyd et al. [36], based on the Bellare-Rogaway model [37], adapting a proof of Blake-Wilson and Menezes [38]. We first give an informal definition of entity authentication.

Definition 21 (Menezes et al. [35]).

Entity authentication is the process whereby one party is assured (through acquisition of corroborative evidence) of the identity of a second party involved in a protocol, and that the second has actually participated (i.e. is active at, or immediately prior to, the time the evidence is acquired).

Steps 2–4(a) of by design constitute a unilateral entity authentication protocol, i.e. only authenticates to . Before formally defining the authentication notion, we need the concept of matching conversations due to Bellare and Rogaway [37]. We suppose that an adversary has access to an infinite family of oracles denoted by , where and are in the space of participants of a protocol, denotes the -th instance of a protocol, and the oracle behaves as if entity is performing protocol in the belief it is communicating with the entity for th time.

Definition 22 (Conversation).

For any oracle , its conversation for instance is the following -tuple

where at time , the oracle received and sent .

We can now define matching conversations, again following Bellare and Rogaway [37, Definition 4.1]. We assume that the number of moves

in a protocol is odd (

even is investigated by Boyd et al. [36]).

Definition 23 (Matching conversations).

Suppose is a -move protocol, where for some integer . Run and suppose oracles and engage in conversations and , respectively. If there exist and such that   is prefixed by

and is prefixed by

then is a matching conversation to .

means that the oracle has no input, because it initiates the protocol; we call it an initiator oracle; otherwise, an oracle is a responder oracle. means that the oracle has no output, because the protocol ends with this last move.

Informally, this means that conversation of (a responder oracle) matches conversation of (an initiator oracle). We also need the following definition, which has been modified for the unilateral (as opposed to mutual) authentication case.

Definition 24 (No match).

Suppose is a protocol and is an adversary. Suppose also that when is run against there exists an initiator oracle with a conversation in the ACCEPT state but no oracle has a conversation matching with . We denote this event by and its probability by .

These preliminaries enable us to state the following key definition. Note that this definition corresponds to the case where the protocol responder (entity ) is authenticated by the protocol initiator (entity ), i.e. in the case of protocol where the server is entity and the client is entity .

Definition 25 (Secure unilateral authentication protocol).

A protocol is a secure unilateral entity authentication protocol if for every adversary :

  1. If and have matching conversations, then the initiator oracle accepts;

  2. is negligible.

The first condition refers to completeness. The second condition says that the only way for an adversary to corrupt an honest responder oracle to the ACCEPT state is to relay the messages in the protocol without modification, i.e. an adversary can only observe and relay messages.

We can now state the main result.

Theorem 4.

If is IND-CPA, then Steps 2–4(a) of form a secure unilateral authentication protocol.


Since for the purposes of the Theorem we are ignoring Steps 1, 4(b) and 4(c) of , the server is the protocol initiator and the client is the responder, although the reverse is true for in its entirety. Suppose is the security parameter of the underlying homomorphic encryption scheme . Suppose also that Steps 2–4(a) of do not form a secure authentication protocol. From Theorem 1, we know that is complete, i.e. that the first condition of Definition 25 holds. Thus the second condition does not hold, i.e. there exists a PPT adversary such that is non-negligible.

We say that succeeds against if, at the end of ’s operation, there exists an initiator oracle with a conversation in the ACCEPT state but no oracle has a conversation matching with . We denote the probability that succeeds against the initiator oracle by . Then, by assumption, is non-negligible. Suppose also possesses the public key of a genuine client. We next construct an adversary from against the IND-CPA security of .

We consider the details of the conversation of the oracle . Since we only consider Steps 2–4(a) of , we have . Suppose the conversation for is

where at time , the oracle sent and at time the oracle received and sent . Then it follows that we have (where is 0 or 1), , and ), where we ignore the ID token since its construction is independent of the design of the protocol.

Since is successful against with probability , it follows that with probability . Since and are chosen uniformly at random for each conversation instance, and since we are also assuming that there is no matching conversation, must have a means for recovering from which works with probability at least . Hence must have access to an oracle which, when given an input encrypted using the public key of , with non-negligible probability returns its decrypted version. However, since does not have access to the private key of , this oracle can immediately be used to construct an adversary against the IND-CPA security of . This gives the desired contradiction and hence it follows that is a secure unilateral authentication protocol. ∎

V Implementation

The protocol has been implemented using the C/C++ Fully Homomorphic Encryption over the Torus (TFHE) library due to Chillotti et al. [39]. One feature of TFHE is that it implements gate bootstrapping, i.e. at each evaluated gate the bootstrapping method is executed. This enables the evaluation of arbitrary circuits on encrypted data. In practice, TFHE offers the fastest gate bootstrapping in the literature, namely of the order of 13 milliseconds per gate on a single core; however, “bootstrapped bit operations are still about one billion times slower than their plaintext equivalents” [2].

In Section II, we described a homomorphic encryption scheme as a public key encryption system. The TFHE scheme is symmetric but can easily be used in the context of because it provides a pair of keys: a secret key and a cloud key . In the context of (see Section III), is kept secret and used by the client to encrypt and decrypt data. sends to the server during the registration phase. is then able to compute arbitrary circuits on data encrypted under using without being able to decrypt them. For further information on the design and security of TFHE see Chillotti et al. [2].

V-a Biometric matching

We chose facial recognition as the biometric method for our proof-of-concept implementation for two main reasons: it is a mature technology (see, for example, the NIST report [40]) and one that suits the homomorphic setting. For our purposes, facial samples and templates are vectors , where is the set of the integers modulo (for some ). Samples and templates are compared using Euclidean distance, as defined below.

Definition 26 (Euclidean distance).

Suppose . The Euclidean distance between and is defined to be:

To simplify calculations, we used the square of the distance as the metric. As in the following definition, a sample and a template are deemed to match if the (square of) the distance is at most , for some .

Definition 27 (Match).

A pair of vectors are said to match if and only if .

The function , defined in §III-B, is implemented in accordance with Definition 27 as follows: , where if and only if , and we assume this implementation throughout Section V. The algorithm used to implement is given in Appendix B (see Algorithm 1).

For comparison purposes, when verifying the correctness of the implementation, we also implemented the Manhattan distance, defined below.

Definition 28 (Manhattan distance).

Suppose , and let denote the absolute value of . The Manhattan distance between and is defined to be:

V-B Results

To obtain performance results, the implementation was run on an Ubuntu 20.04.1 LTS 64-bit machine with 8 GB of RAM and a four-core Intel(R) Core(TM) i3-6100CPU @ 3.70GHz. TFHE was used with the default parameter, which achieves 110-bit cryptographic security [39]. We chose to use biometric vectors of length 128 (i.e. ) because it is a likely real-world value.

To obtain timing figures, we first measured the ‘homomorphic’ (ciphertext domain) computation times for most of the arithmetic and bit comparison subroutines given in Appendix B. For comparison purposes, we also implemented and measured the performance of all the subroutines in the plaintext domain. Table I summarises the results.

It is clear that homomorphic computations have a substantial performance cost, with an order of magnitude of at least . This finding is in line with previous work [34], despite the optimisations included in the TFHE library [20].


Execution time

on plaintexts

(in nanoseconds)

Execution time

on ciphertexts

(in seconds)

-bit addition 335 9
Two’s complement 422 10
Absolute value 396 10
-bit subtraction 1108 30
-bit multiplication 2094 206
Manhattan distance 210370 5049
Euclidean distance 425022 33536
TABLE I: Performance results for basic operations

Building on the implementations of fundamental operations, we implemented a naive version of . The performance results are shown in Table II, and confirm that the current proof-of-concept implementation is certainly not practical, and needs considerable optimisation in order to be usable in practice. For comparison we also show computation results in the plaintext domain. Note that none of the performance results given in Table I include the encryption and decryption time.


Execution time

on plaintexts

(in microseconds)

Execution time

on ciphertexts

(in seconds)

Function 790 34308
Function 5 456
Protocol 810 34765
TABLE II: Performance results for the protocol and its underlying functions

These results demonstrate the importance of optimising the design of an algorithm and its implementation. The performance results are not only due to the homomorphic paradigm, but also because we implemented the most naive routines without any optimisations or parallelisations. We project from those results that with an optimised and targeted implementation could be practical in the real world.

To conclude, we showed that, implemented naively, homomorphic encryption does not meet the performance criteria for practical use, since a user cannot wait for a few hours to be authenticated in most (if not all) authentication use cases. Indeed, Nah [41] showed that a typical user will not tolerate a wait of more than two seconds for a web page to appear. Nonetheless, there are considerable possibilities for optimisation, and the implementation and design of can be enhanced in various ways, as we next briefly discuss.

V-C Possible optimisations

The most obvious improvement would be from the algorithmics perspective. As explained above all the subroutines are implemented in a very naïve way.

There exist various public libraries that could be used to add parallel computing features. One example would be a C++ library such as OpenMP. Many of the subroutines have for loops in which all execution instances are independent.

Finally, perhaps the most effective optimisation would be to mix the FHE schemes, as proposed by Boura et al. [42, 43]. Existing libraries are optimised for certain targeted homomorphic computations; the main idea is to switch between libraries, choosing the most efficient for each homomorphic computation. In our case, the arithmetic subroutines would be faster on libraries other then TFHE; however, bit comparisons are much better handled by the TFHE library. This idea is practically effective, as shown by Lou et al. [44] who present Glyph, a tool which switches between TFHE [39] and BGV cryptosystems [15].

Vi Conclusions and future work

We presented the design and a proof-of-concept implementation of a novel privacy preserving authentication protocol based on fully homomorphic encryption. Human authentication is based on biometric matching, implemented in the proof-of-concept using face matching. In the implementation, all underlying operations are executed using FHE, including biometric matching, Euclidean distance computation, and integer comparison. We showed that the protocol is privacy-preserving and a secure unilateral authentication protocol if the underlying homomorphic encryption scheme is IND-CPA.

The implementation results are for a naive and unoptimised version, i.e. the worst-case scenario. However, producing it involved developing a set of elementary routines in the ciphertext domain that can be used as low-level building blocks in other applications. The results confirm that FHE is not practical in a naive worst-case model, and real-world implementations would require optimisations. However, the results suggest that, with already identified improvements, the protocol can be made ready for real-world adoption.

There are number of possible directions for future work in improving performance. First, as identified in §V-B, mixing FHE schemes to take advantage of the best of each scheme (see [43, 44]

) would significantly benefit performance without compromising the IND-CPA security of the homomorphic encryption scheme. Better algorithmics and implementation design is also an obvious target for improvement. Another possibility would be to change the biometric matching paradigm. Deep Learning is known to be useful in this context, and the performance in particular for face matching has been much improved recently thanks to initiatives such as that of NIST

333See for more details.. However, when such deep learning techniques are used in combination with homomorphic encryption, only the inference phase is run homomorphically and the training phase is run on clear data (see e.g. [45, 46]). To achieve the level of security we showed in this paper with FHE, both phases need to be executed in the ciphertext domain. However, encrypting both phases may not be straightforward to achieve, as recent experience shows that it is costly [44, 47], despite improvements in making FHE practical.


  • [1] G. Pradel and C. Mitchell, “Privacy-preserving biometric matching using homomorphic encryption,” in TrustCom 2021.   IEEE, 2021.
  • [2] I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène, “TFHE: fast fully homomorphic encryption over the torus,” J. Cryptol., vol. 33, no. 1, pp. 34–91, 2020.
  • [3] R. L. Rivest, A. Shamir, and L. M. Adleman, “A method for obtaining digital signatures and public-key cryptosystems,” Commun. ACM, vol. 21, no. 2, pp. 120–126, 1978.
  • [4] D. Boneh, E. Goh, and K. Nissim, “Evaluating 2-dnf formulas on ciphertexts,” in TCC, ser. Lecture Notes in Computer Science, vol. 3378.   Springer, 2005, pp. 325–341.
  • [5] D. Naccache and J. Stern, “A new public key cryptosystem based on higher residues,” in CCS.   ACM, 1998, pp. 59–66.
  • [6] T. Okamoto and S. Uchiyama, “A new public-key cryptosystem as secure as factoring,” in EUROCRYPT, ser. Lecture Notes in Computer Science, vol. 1403.   Springer, 1998, pp. 308–318.
  • [7] P. Paillier, “Public-key cryptosystems based on composite degree residuosity classes,” in EUROCRYPT, ser. Lecture Notes in Computer Science, vol. 1592.   Springer, 1999, pp. 223–238.
  • [8] C. Gentry, “A fully homomorphic encryption scheme,” Ph.D. dissertation, Stanford University, 2009,
  • [9] Z. Brakerski and V. Vaikuntanathan, “Efficient fully homomorphic encryption from (standard) LWE,” in FOCS.   IEEE Computer Society, 2011, pp. 97–106.
  • [10] ——, “Lattice-based FHE as secure as PKE,” in ITCS.   ACM, 2014, pp. 1–12.
  • [11] M. van Dijk, C. Gentry, S. Halevi, and V. Vaikuntanathan, “Fully homomorphic encryption over the integers,” in EUROCRYPT, ser. Lecture Notes in Computer Science, vol. 6110.   Springer, 2010, pp. 24–43.
  • [12] C. Gentry, S. Halevi, and N. P. Smart, “Homomorphic evaluation of the AES circuit,” in CRYPTO, ser. Lecture Notes in Computer Science, vol. 7417.   Springer, 2012, pp. 850–867.
  • [13] N. P. Smart and F. Vercauteren, “Fully homomorphic encryption with relatively small key and ciphertext sizes,” in Public Key Cryptography, ser. Lecture Notes in Computer Science, vol. 6056.   Springer, 2010, pp. 420–443.
  • [14] D. Stehlé and R. Steinfeld, “Faster fully homomorphic encryption,” in ASIACRYPT, ser. Lecture Notes in Computer Science, vol. 6477.   Springer, 2010, pp. 377–394.
  • [15] Z. Brakerski, C. Gentry, and V. Vaikuntanathan, “(leveled) fully homomorphic encryption without bootstrapping,” in ITCS.   ACM, 2012, pp. 309–325.
  • [16] O. Regev, “On lattices, learning with errors, random linear codes, and cryptography,” in STOC.   ACM, 2005, pp. 84–93.
  • [17] C. Gentry, A. Sahai, and B. Waters, “Homomorphic encryption from learning with errors: Conceptually-simpler, asymptotically-faster, attribute-based,” in CRYPTO (1), ser. Lecture Notes in Computer Science, vol. 8042.   Springer, 2013, pp. 75–92.
  • [18] J. Alperin-Sheriff and C. Peikert, “Faster bootstrapping with polynomial error,” in CRYPTO (1), ser. Lecture Notes in Computer Science, vol. 8616.   Springer, 2014, pp. 297–314.
  • [19] L. Ducas and D. Micciancio, “FHEW: bootstrapping homomorphic encryption in less than a second,” in EUROCRYPT (1), ser. Lecture Notes in Computer Science, vol. 9056.   Springer, 2015, pp. 617–640.
  • [20] I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène, “Faster fully homomorphic encryption: Bootstrapping in less than 0.1 seconds,” in ASIACRYPT (1), ser. Lecture Notes in Computer Science, vol. 10031, 2016, pp. 3–33.
  • [21] C. Lu and X. Tang, “Surpassing human-level face verification performance on LFW with gaussianface,” in AAAI.   AAAI Press, 2015, pp. 3811–3819.
  • [22] E. Pagnin and A. Mitrokotsa, “Privacy-preserving biometric authentication: Challenges and directions,” Secur. Commun. Networks, vol. 2017, pp. 7 129 505:1–7 129 505:9, 2017.
  • [23] M. Osadchy, B. Pinkas, A. Jarrous, and B. Moskovich, “Scifi - A system for secure face identification,” in IEEE Symposium on Security and Privacy.   IEEE Computer Society, 2010, pp. 239–254.
  • [24] B. Schoenmakers and P. Tuyls, “Efficient binary conversion for paillier encrypted values,” in EUROCRYPT, ser. Lecture Notes in Computer Science, vol. 4004.   Springer, 2006, pp. 522–537.
  • [25] M. Blanton and P. Gasti, “Secure and efficient protocols for iris and fingerprint identification,” in ESORICS, ser. Lecture Notes in Computer Science, vol. 6879.   Springer, 2011, pp. 190–209.
  • [26] M. Yasuda, T. Shimoyama, J. Kogure, K. Yokoyama, and T. Koshiba, “Packed homomorphic encryption based on ideal lattices and its application to biometrics,” in CD-ARES Workshops, ser. Lecture Notes in Computer Science, vol. 8128.   Springer, 2013, pp. 55–74.
  • [27] A. Abidin, E. Pagnin, and A. Mitrokotsa, “Attacks on privacy-preserving biometric authentication,” in NordSec 2014, ser. Secure IT Systems, K. Bernsmed and S. Fischer-Hübner, Eds.   Springer, 2014, pp. 293–294.
  • [28] J. Bringer and H. Chabanne, “An authentication protocol with encrypted biometric data,” in AFRICACRYPT, ser. Lecture Notes in Computer Science, vol. 5023.   Springer, 2008, pp. 109–124.
  • [29] J. R. Troncoso-Pastoriza, D. González-Jiménez, and F. Pérez-González, “Fully private noninteractive face verification,” IEEE Trans. Inf. Forensics Secur., vol. 8, no. 7, pp. 1101–1114, 2013.
  • [30] J. H. Cheon, H. Chung, M. Kim, and K. Lee, “Ghostshell: Secure biometric authentication using integrity-based homomorphic evaluations,” IACR Cryptol. ePrint Arch., vol. 2016, p. 484, 2016.
  • [31] V. N. Boddeti, “Secure face matching using fully homomorphic encryption,” in BTAS.   IEEE, 2018, pp. 1–10.
  • [32] J. Fan and F. Vercauteren, “Somewhat practical fully homomorphic encryption,” IACR Cryptol. ePrint Arch., vol. 2012, p. 144, 2012.
  • [33] O. Goldreich, The Foundations of Cryptography — Volume 1: Basic Techniques.   Cambridge University Press, 2001.
  • [34] F. Armknecht, C. Boyd, C. Carr, K. Gjøsteen, A. Jäschke, C. A. Reuter, and M. Strand, “A guide to fully homomorphic encryption,” Cryptology ePrint Archive, Report 2015/1192, 2015,
  • [35] A. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography.   CRC Press, 1996.
  • [36] C. Boyd, A. Mathuria, and D. Stebila, Protocols for Authentication and Key Establishment, Second Edition, ser. Information Security and Cryptography.   Springer, 2020.
  • [37] M. Bellare and P. Rogaway, “Entity authentication and key distribution,” in CRYPTO, ser. Lecture Notes in Computer Science, vol. 773.   Springer, 1993, pp. 232–249.
  • [38] S. Blake-Wilson and A. Menezes, “Entity authentication and authenticated key transport protocols employing asymmetric techniques,” in Security Protocols Workshop, ser. Lecture Notes in Computer Science, vol. 1361.   Springer, 1997, pp. 137–158.
  • [39] I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène, “TFHE: Fast fully homomorphic encryption library,” August 2016,
  • [40] Facial Recognition Technology (FRT), National Institute of Standards and Technology (NIST), Accessed: 2020-02-06.
  • [41] F. F. Nah, “A study on tolerable waiting time: How long are web users willing to wait?” in AMCIS.   Association for Information Systems, 2003, p. 285.
  • [42] C. Boura, N. Gama, M. Georgieva, and D. Jetchev, “Chimera: Combining ring-lwe-based fully homomorphic encryption schemes,” Cryptology ePrint Archive, Report 2018/758, 2018,
  • [43] ——, “CHIMERA: combining ring-lwe-based fully homomorphic encryption schemes,” J. Math. Cryptol., vol. 14, no. 1, pp. 316–338, 2020.
  • [44]

    Q. Lou, B. Feng, G. C. Fox, and L. Jiang, “Glyph: Fast and accurately training deep neural networks on encrypted data,” in

    NeurIPS, 2020.
  • [45] F. Bourse, M. Minelli, M. Minihold, and P. Paillier, “Fast homomorphic evaluation of deep discretized neural networks,” in CRYPTO (3), ser. Lecture Notes in Computer Science, vol. 10993.   Springer, 2018, pp. 483–512.
  • [46] R. Gilad-Bachrach, N. Dowlin, K. Laine, K. E. Lauter, M. Naehrig, and J. Wernsing, “Cryptonets: Applying neural networks to encrypted data with high throughput and accuracy,” in ICML, ser. JMLR Workshop and Conference Proceedings, vol. 48., 2016, pp. 201–210.
  • [47] K. Nandakumar, N. K. Ratha, S. Pankanti, and S. Halevi, “Towards deep neural network training on encrypted data,” in CVPR Workshops

    .   Computer Vision Foundation / IEEE, 2019, pp. 40–48.

  • [48] H. Vollmer, Introduction to Circuit Complexity — A Uniform Approach, ser. Texts in Theoretical Computer Science. An EATCS Series.   Springer, 1999.
  • [49]

    J. L. H. Crawford, C. Gentry, S. Halevi, D. Platt, and V. Shoup, “Doing real work with FHE: the case of logistic regression,” in

    WAHC@CCS.   ACM, 2018, pp. 1–12.
  • [50] A. A. Karatsouba and Y. P. Ofman, “Multiplication of multidigit numbers on automata,” Soviet Physics –- Doklady, pp. 595––596, 1963.
  • [51] F. Bourse, O. Sanders, and J. Traoré, “Improved secure integer comparison via homomorphic encryption,” in CT-RSA, ser. Lecture Notes in Computer Science, vol. 12006.   Springer, 2020, pp. 391–416.
  • [52] A. C. Yao, “Protocols for secure computations (extended abstract),” in FOCS.   IEEE Computer Society, 1982, pp. 160–164.

Appendix A Circuits and circuit families

We next formally introduce notions related to circuits. For more complete versions of these definitions, see Vollmer [48].

Definition 29 (Boolean function).

A Boolean function is a function for some .

Definition 30 (Family of Boolean functions).

A family of Boolean functions is a sequence , where is an -ary Boolean function.

Definition 31 (Basis).

A basis is a finite set consisting of Boolean functions and families of Boolean functions.

Informally, a Boolean circuit is a directed acyclic graph with internal nodes marked by elements of Nodes with no in-going edges are called input nodes, and nodes with no outgoing edges are called output nodes. A node marked may have only one outgoing edge. Computation in the circuit begins with placing input bits on the input nodes (one bit per node) and proceeds as follows. If the outgoing edges of a node (of in-degree ) marked (similarly for nodes marked and ) have values then the node is assigned the value The output of the circuit is read from its output nodes. The size of a circuit is the number of its edges. A polynomial-size circuit family is an infinite sequence of Boolean circuits such that, for every , the circuit has input nodes and size , where is a polynomial fixed for the entire family.

Definition 32 (Circuit).

Let be a basis. A Boolean circuit over with inputs and outputs is a tuple

where is a finite directed acyclic graph, is an injective function, , and