The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
The use of biometrics as a mechanism of authentication between devices or between a device and a person has been in use for some time. However, templates of a person's biometric data may be shared and subsequently stored by devices outside a person's control. Should one or more of those biometric templates be compromised by that third party device, that person may have no recovery path, since the person cannot generate new fingerprints, face scans, iris images, etc.
In an embodiment, a biometric confirmation device may use a homomorphic encryption technique to compare a biometric template with a biometric scan to determine whether a match exists without actually disclosing the biometric template to the third party device. Further, the homomorphic process allows the terminal to send current biometric scan data to the terminal without leaking scan information. In order to optimize the encryption process, a term packing process allows a dramatic reduction in computing overhead during the verification stage.
The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
A terminal may wish to confirm that a person is associated with a particular device, such as a smartphone. For example, a point of sale device (POS), such as at a retailer, may be capable of processing a transaction using a sight-unseen smartphone. That is, the POS may be able to complete a transaction using Wi-Fi or Bluetooth with a smartphone using the same protocol as would have been used if the smartphone was presented to the POS via Near Field Communication (NFC) by tapping the smartphone to the POS. However, the POS would first need to determine which smartphone in the vicinity is the one with the proper credential corresponding to the current purchase and purchaser.
The POS may send a request to nearby smartphones requesting biometric templates of images for their respective users. The POS may also capture an image of the user engaged in the current transaction. Once the POS finds a smartphone with the image biometric template of the user matching the image just captured, the transaction processing can proceed using a normal payment flow. That is, in an exemplary embodiment, the smartphone can establish a secure channel with the POS, the transaction data can be transferred and signed by the smartphone's payment application along with the personal account number (PAN) or token data related to the user's payment card. This information may be passed by the POS to the retailer's acquiring bank for approval and processing.
However, in this process, the POS should not simply be able to request biometric templates from every nearby smartphone simply so that matching the image to the correct user can be performed. This would expose the biometric data of every nearby smartphone user, including those devices/users who are not involved in the transaction in any way. Conversely, the image of the user or its biometric template, should not be shared with each nearby smartphone so that the user's information remains protected from unwanted distribution. The techniques for accomplishing this are discussed below. In this example, there is little or no threat of the smartphone attempting to spoof the POS into thinking it is someone else, because the payment is made via a separate purchase transaction using a different credential. This type of identification may be thought of as passive.
In a similar process for a different transaction type, for example, one involving receiving cash at an automated teller machine (ATM), the benefit of a deliberate attempt to deceive the identification process at the ATM could result in fraudulent receipt of funds. In this case, an active identification may be used to further identify the user. In this case, instead of just matching the biometric template, the user may provide a copy of the template signed by an authority that also includes user identity information. In this case, the approval process results in not only establishing a relationship between a user and a smartphone, but the user and the user's identity as previously established with the authority.
A homomorphic cryptography algorithm, such as a Paillier encryption among others, may be used. The basic premise is that an operation performed on encrypted data has the same result as that operation being performed on unencrypted data. As will be discussed in greater detail below, this allows verification operations to be performed on encrypted data so that while the matching process may occur on the terminal, the biometric template never leaves the smartphone.
While the advantages of such a process are apparent, homomorphic cryptographic algorithms, such as Paillier, can be very compute-intensive at certain phases of the process. For example, key generation and data encryption can be very time consuming, so long that including these steps in a normal cryptographic transaction, such as a purchase transaction may be prohibitive. The following description discloses an approach to address these shortcomings. Further, the homomorphic algorithms as applied to biometrics can yield datasets that are large enough to adversely affect transmission time between the user device and the terminal (for example, the POS or ATM). An embodiment described below for packing data reduces the data required for transmission by a factor of 8, although other reduction factors are possible. Bit masking of non-essential terms also helps to reduce the potential for data leakage during the data reduction process.
In an embodiment using current technology, the matching process takes about 300 milliseconds with an initial communication payload of 55 Mbytes of data and about 1 Mbyte for each communication after that.
The homomorphic module 114 may include cryptographic routines for encryption and decryption, as well as routines for generating templates from biometric data received from the biometric capture device 112. These data may include facial images, fingerprint scans, iris scans, retinal scans, palm outline data, voice prints, etc. More specific functions associated with the homomorphic module 114 are discussed below. The wireless interface 116 may include a Wi-Fi module, a Bluetooth module, or any wireless connection hardware and associated protocol that allows relatively high speed data communication between the terminal 102 and external entities.
The system 100 may also include or be coupled with a plurality of mobile devices such as smartphones 118a, 118b, 118c, and 118d. The mobile devices may also include laptops, tablets, wearable devices or other electronic gear capable of storing data and two-way communication.
In operation, a user 120 may approach the terminal 102 to complete a transaction. The terminal 102 may wish to determine which, if any, of the smartphones 118 in the vicinity are associated with the user. Several different scenarios for this process are discussed with the help of
Turning to
At step 202, at the beginning of a potential transaction, the terminal 102 may collect a biometric measurement, such as an image, of the user 120 and use the raw data to generate a template y. Because the terminal 102 may have fewer limitations than the mobile device including access to power and a larger processor, the generation of the template via a neural network may be performed virtually in real time. In other embodiments, the terminal 102 and a mobile device may begin this initial step before the transaction is even initiated, such as when the user enters a store. Step 202 may continue by requesting a template match from surrounding mobile devices 118a, 118b, 118c, 118d. While the following process may be repeated for each mobile device, only a single response is followed for the sake of clarity and simplicity.
In response to the request, the smartphone's public key and the encrypted template may be sent to the terminal 102 at step 204. At block 206, the terminal 102 may multiply each term of the encrypted template with the corresponding term of the local template. As discussed more below, a characteristic of Paillier encryption or other additive homomorphic encryption schemes is that operations performed on encrypted data yield the same result as the same operation on unencrypted data.
At this point, the terminal has no information about the user's biometric template, other than that it exists. If the terminal 102 returns the result matrix z, that is, the inner product of x and y, to the device 118a, the device 118a may be able to determine the template taken at the terminal. To avoid leaking this information to the device 118a, the terminal 102 may add a random number, B, to the result of the operation. With the addition of the random value, the device 118a cannot discover any information about the template from the terminal 102.
The encrypted value z which includes the added value B, is sent at step 208 from the terminal 102 to the device 118a. There, at step 210, the device 118a may decrypt the z to reveal the plaintext value z. The decryption process is much more efficient than the encryption process, so the device 118a can perform the decryption in a timely manner compared to expected transaction processing time. Further, the data transferred at step 208 (and at step 212 below) is significantly smaller than the original transfer at block 204. This helps to speed the process.
This value may be returned at step 212 to the terminal 102. By subtracting the value B from z, the inner product of x and y can be developed. If this inner product is less than a threshold value, or in the case of cosine similarity match, close enough to a value of 1, the match is confirmed. As discussed above, since the biometric match is not actually used to complete the transaction, this passive technique is usable. The match merely confirms that the payment credentials on the device 118a can be used to make the payment. If the device 118a were to take steps to spoof or deceive the terminal 102 into thinking it is someone else, the result would simply be that the device 118a completes the payment transaction, perhaps for goods or services that in the end are taken by another user. In other words, there is no incentive to deceive in this scenario.
While the size of the data sent in the example of
The new encrypted vector, [[x′j]], may therefore be, in this example, eight times smaller than the similar encrypted value of the example of
At step 230, a random value grouping r=(r0, . . . r7) may be generated and added to the decrypted values to prevent overflows, as discussed in more detail below. The decrypted grouping z′ and value r′=r0+ . . . +r7 may be returned to the terminal at step 232. At step 234, the value p is the difference between z′ and B, while the inner product is the sum of the terms less r′.
As above, the value z is sent to the device 118a at step 248. At step 250, the private key, sk, is used to decrypt the value z, which is returned to the terminal 102 at step 252. At step 254, the value B is subtracted from z and the result divided by A to determine the inner product value.
Once the match is made, for example, at
The following describes details of the encryption and padding processes.
1 Introduction
Our goal is to enable a card holder's phone to store their biometric data/template r and to securely enable an untrusted payment terminal to determine if a biometric measurement taken by it matches the template v. For various reasons this must happen without revealing v to the terminal or the measurement to the phone. The communication channel will be Bluetooth or Wi-Fi. The current protocol implementation achieves this in roughly 0.3 seconds with 55 MB of communication for one comparison and 1 MB of communication for each comparison after that.
1.1 Biometrics
The field of biometric authentication is quite well explored under some use case. For facial and fingerprint biometrics, many of the most of effective methods follow a similar framework which build on machine learning and neural networks. Beforehand, given many raw biometric measurements (e.g. photos of people's faces or fingerprint scans) a neural network can be trained to “embed” a new biometric measurement into the vector space n such that two embeddings can easily be compared to determine if they are from the same source, i.e. person. In particular, we will consider the embedding where the “comparison” function is the cosine similarity function. The function outputs a value in [−1, 1] which is proportional to the angle between two vectors in n. That is, when two embedding have a small angle between them they are considered a match. More specifically, for a threshold t ∈ (0, 1] we say that two embeddings u,v ∈n match each other if
Putting it together, let NeuralNet be the trained neural network which outputs embeddings. The two measurements m1, m2 are said to be a match if
t<CosineSim(NeuralNet(m1), NeuralNet(m2))
For the remainder of the paper we will refer to these embeddings in n as a biometric template.
1.2 Setting
Broadly speaking, our goal is to allow a user to authenticate to terminal (e.g. Visa card terminal, ATM) using their biometric data. From a pure functionality point of view we wish the terminal to take a measurement (e.g. photo) m* of the user/customer, and then should learn if there exists a pre-registered measurement muser of a user that matches, i.e. learn user such that
t<CosineSim(NeuralNet(m*), NeuralNet(muser))
A naive solution to this problem is to maintain a large database containing the measurement muser for each user. When a terminal takes a measurement m* of the customer, the terminal sends m* to a central server which computes if a matching muser exists. One issue is that comparing all muser against m* could be expensive due to having many users. Secondly, the threshold t would have to be very strict to ensure that muser is unique. This could lead to a bad user experience due to the increased probability of rejecting valid customer measurements (photos). Finally, Visa does not wish to maintain a database of user biometric data due to privacy concerns and the risk of leaking this data during a security breach. For example, a rouge terminal could simply start asking the central server if a random/probable template v is contained in the database and the matching user ID if it exists.
1.3 Homomorphic Encryption
The solution we build relies on techniques known as (additively) homomorphic encryption. Classical encryption allows an entity to sample a random key k and then encrypt data as c=Enck(m). We will also use the notation that m=Enck(m) to denote that m ∈ is encrypted under some key. Homomorphic encryption extends this idea to allow an entity with m1, m2 to “add” the ciphertexts to get a ciphertext of the underlying values added together. That is
m1+m2=m1+m2
The ability to add two ciphertexts means that the encryption scheme is additively homomorphic. The computation of m1+m2 is performed modulo some integer p. An example of such a scheme is known as Paillier encryption. Additively homomorphic encryption also has the property that you can multiply a ciphertext m1 with a plaintext m2 by performing repeated additions. That is
Some encryption are multiplicatively homomorphic which means ciphertexts can be multiplied together. That is
m1*m2=m1+m2
For example, ElGamal encryption is multiplicatively homomorphic. If a scheme is both additive and multiplicatively homomorphic then it is called a fully homomorphic encryption scheme.
Unless otherwise stated, the protocols here are only required to be additively homomorphic. Therefore fully homomorphic encryptions schemes would also be compatible with our protocols.
2 Overview
This solution takes a different approach by having the user store their biometric data muser on their own phone. This approach has the advantage that the overall collection of data has no single point of failure. Moreover, storing biometric data only on the phone follows the existing FIDO standard. A breach of the central server or even a phone does not reveal the biometric data of all users.
We consider several entities for this application. A user with their mobile device and pre-registered biometric measurement muser. This user is running a banking app that will perform the following protocol(s). A central server will help in the authentication but will never store plain biometric data. Finally, a terminal which the user will interact with. This terminal can be in communication with both parties and trusts the server to be honest. Once set up, the terminal should not need to talk to the server to authenticate a user. The terminal is equipped with a biometric reader (e.g. fingerprint read or camera).
The overall flow of the protocol is given in
In the comparison phase the terminal will set up channels with nearby devices/users (e.g. over Bluetooth or Wi-Fi) and run the comparison protocol with each of them. The terminal has one (or more) measurement and wishes to identify which of the users have registered a matching biometric. Each user will begin by sending their token σuser and encrypted template u′ to the terminal.
When the terminal takes a measurement mi&, it first computes the template vi=NeuralNet(mi) and normalizes it as vi′=vi/∥vi∥2. It is then the case that CosineSim(u, vi)=Σjuj′vi,j′. Using additively homomorphic encryption, an encryption of CosineSim(u, vi) can be computed by the terminal as CosineSim(u, vi)=Σjuj′vi,j′. This encryption can then be sent to the user to be decrypted. However, this would reveal the result to the user instead of the terminal. This is rectified by having the terminal one-time mask the result with a random value ri as xi=ri+Σjuj′vi,j′. The user decrypts and sends back xi which allows the terminal to compute CosineSim(u, vi)=xi+ri.
This protocol has several notable improvements over a “standard” approach to solving this program. First is that this protocol is optimized for the case where the user's template is fixed and will be compared with server measurements m1*, . . . , . In particular, the user only sends the large vector u′ once which is used to compute the small results x1, . . . , . This greatly improves the efficiency of the protocol for the intended use case.
For example, when a user walks into a store, their device can send (σuser, u′) to the terminal. This will consist of the bulk of the communication between the devices and the terminal, e.g. 55 KB. This message is large due to u′ being the vector of roughly n=512 elements. Later, when the terminal takes a measurement mj*, they can compute the single element xi, which is n times smaller than u′, and send this to the user device. Not only does this decrease overall communication by allowing the terminal to reuse u′, it also decreases latency due to u′, being sent before a measurement has ever been taken. In practice with the use of Paillier encryption, sending u′ currently requires roughly 55 KB of communication while and xi and xi combined require less than 1 KB.
The second advantage of this approach is that the user only generates the encryption u′ once during the registration phase. This is of particular concern due to Paillier encryption being somewhat inefficient while computation and decryption is more efficient. For example, encrypting u′
Figure I: Overview of the Bask Protocol.
can require many seconds while the rest of the protocol requires much less than a single second. As such, if the user had to freshly encrypt u′ for each measurement, then the use of Paillier encryption could be prohibitively inefficient/power intensive for the practicality of this application.
An advantage of this approach over comparing the measure mi* with a central database containing all registered measurements muser is that the terminal can significantly narrow down the search to only the measurements of nearby users. For example, there could be 20 nearby users while the total number of users could be a hundred million or more. This could allow us to set the threshold t to be much more relaxed and decrease the probability of rejecting a pair of matching measurements.
3 Batching & Paillier Encryption
We now introduce a new optimization for Paillier encryption which reduces the communication overhead of the bask protocol by roughly 4 to 8 times. Paillier is additively homomorphic with a plaintext space pq where p, q are large primes. Typical sizes of p, q is 1024 bits each which means that a single Paillier ciphertext can contain 2048 bits of plaintext data. The security level would then be similar to RSA with a 2048 bit key. In the biometric application we must encrypt a vector u=(u1, . . . , un). The standard method for doing this to encrypt each ui on its own to give you ciphertexts u1, . . . , un. However, this is very wasteful since each element ui′ can typically be represented using at most 32 bits while a ciphertext is large enough to hold 2048 bits. The size of a Paillier ciphertext cannot be made smaller due to security constraints.
3.1 Encoding
A method known as packing has long been known to allow you to encode several values into a ciphertext. The idea is that you place multiple elements into a single ciphertext with zero padding between them. For example, the packing of u1, . . . , un ∈2m can be computed as u*=Σi=1n2(i−1)(m+d)ui∈n(m+d) where d is the number of padding bits between each element. Given two such packed values, u*, v*, adding them results in
i.e. the addition of each element in the encoded format. The d padding bits are used here to ensure that if ui+vi generates a carry bit, i.e. ui+vi≥2 m, then this carry will be stored in the padding bits. In this case d=1 would be sufficient. More generally, this approach works so long as no position ever requires more than m′=m+d bits to be represented.
This encoding also works when multiplying a single value x ∈ 2m with the encoded vector v*. In particular,
Again we require d to be large enough to make sure xvi can be represented with m′=m+d bits. In this case d=m would be sufficient. However, multiplying two vectors component-wise (Hadamard Product) does not work in this format. For example, if we have n=2 then
v*u*=20m′v1u1+21m′(v1v2+v2u1)+22m′v2u2
Although we do not get 20m′v1u1+2m′v2u2 as desired, observe that the values of interest (v1u1, v2u2) are stored in the result just with v2u2 at a different positions than in the input. We call this it's “level 2” position. It is easy to verify that for any ,
v*u*=v1u1+2m′( . . . )+22m′( . . . )+ . . . +2(2n−2)m′vnun
v1u1 and unun can be recovered but the other ( . . . ) terms will consist of various cross terms between ui and vj. We now show a new encoding strategy which allows us to recover all of the product terms viui from various positions v*u*. Let n=3 and let us now encode u1, . . . , un as
u*=u1+2m′u2+23m′u3
Note that the position for 22m′ is set to zero. If we then multiply v*u* using these encodings we obtain
v1u12m′(v1u2+v2u1)+22m′v2u2+23m′(v1u3+v32u1)+
24m′(v2u3+v3u2)+25m′(0)+26m′v3u3.
The “level 2” positions here are 0, 2, 6, i.e. the first bit of each viui starts at bit index 0, 2m′, 6m′. Then general ideal can be extended for an arbitrary value of n. In particular, given a suitable encoding for vectors of n−1 elements, an encoding for n elements can be performed by adding 2n
u*=Σi2m′I[i]ui
is the encoding.
For this encoding strategy, we must additionally ensure the d is sufficiently large such that any overflow from any of the cross terms does not exceed m′=m+d bits.
3.2 Masking
One issue with the encoding strategy is that if we reveal v*u* to a party, then they will learn {v1u1|i∈ [n]} and the value of all of the other positions. For example, with n=2 learning v*u* also reveals v1u2+v2u1 which is undesirable. This issue is overcome by adding an additional random value to each of these position. When encoding a vector, we now make every slot of size m′+λ bits, i.e.
u*=Σi=1n2I[i](m′+λ)ui
and when we decrypt/reveal v*u* we now reveal
x=v*u*+Σi∈Ī2i(m′+λ)ri
instead where ri is uniform value in and Ī indexes the positions with the cross terms we wish to hide. To ensure that adding the ri terms do not corrupt the other positions, we require that the addition between the cross terms and ri does not overflow the m′+λ bits of the position. Recall that we guarantee that m′ is large enough to hold the cross terms. Therefore the probability of an overflow is that probability that the top λ bits of ri is all ones. This happens with probability 2−λ which can be made arbitrarily small so that the overall error probability is acceptable.
3.3 Signed Values
Signed values can also be supported. This is achieved by using a twos complement encoding of the values. Given an m bit signed value, encode it as a twos complement 2m bit number1. This requirement for this expansion is to ensure that after multiplying two of these values, the first 2m bits of the product. One security ramification of this approach is that we must extend the masking approach described above to hide the top 2m bits of the 4m bit product. If these bits were not masked then when the product is reveal the decrypted could distinguish multiply two positive values and two negative values which both result in the same logical value, i.e. the product of negative numbers would have at least one 1 in the top 2m bits while the other would not. 1Actually, this must be sign extended to the size of the final result in bits (when not twos complement encoded). For inner products this could be as large as 2m+log2 n bits. See below.
Regardless, these top 2m bits can be masked in a straightforward extension of the masking technique described above.
3.4 Inner Product
Up to this point we have only discussed computing component wise multiplication. However, we desire computing inner product. The high level ideal is as follows where we are encoding 8 values per ciphertext.
Additional care here must be taken to ensure that enough padding bits are placed between each value to guarantee that no overflows will happens. This can be done simply by computing the maximum value any position can take.
As an optimization, if a priori it is known that any that the inner product will not exceed some given value then fewer padding bits may be needed. This is the case of cosine similarity where the inner product can Ia* at most 1 (times some scaling factor) while each product uiv1 can also be at most 1. This observation can be used to prove that log2 n fewer padding bits are needed. This is contrasted with the case where the only constraint is that uivi can be at most 1 which would imply that the inner product could be as large as n.
Fully Homomorphic Encryption (FHE) can be used in a similar way as Paillier encryption. It is actually more computationally efficient but requires an increase in communication overhead. With careful optimization this added overhead may be minimized. An advantage of FHE is that it could be used to give stronger guarantees that the user's encrypted template 1, . . . , n is of correct form. Further investigations are required.
A technical effect of the current concept is that a user's biometric template never leaves the user's possession even though the matching process occurs at the terminal device at which the user is requesting authentication. This is a technical solution to a technology problem, that of preserving the integrity of a person's biometric data from compromise during the act of using that biometric with a foreign and unknown device. Similarly, the process ensures that a terminal device capturing a person's biometric data will not leak that data to other devices while attempting to discover the correct device with which to interact.
Further, the bit packing process disclosed overcomes previous carry bit problems to allow significant data reductions in the size of data transferred between devices, resulting in significant speed improvements.
A system and method in accordance with the current disclosure benefits both users and merchants. The biometric matching may occur with little or no interaction from the user 120, and the transaction accomplished so that the user does not even need to remove his or her device 118a from a purse or pocket. This streamlines the interaction while reducing the inconvenience and threat posed by removing the device 118a from a purse or pocket. More importantly, the biometric matching occurs without the terminal 102 or any other server from even temporarily handling the user's biometric template. That information is stored solely on the user's device 118a. The terminal 102 may gather biometric data directly from the user for the period of the transaction but without the means to register that information, that template has little to no value. As a rule, a merchant does not want to be responsible for that kind of user data in the event of a breach and will systematically discard such information after a transaction.
The figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.
This application is a continuation of U.S. application Ser. No. 16/664,530, filed Oct. 25, 2019, the disclosure of which is incorporated by reference herein in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
9942032 | Kornaropoulos | Apr 2018 | B1 |
11250116 | Rindal | Feb 2022 | B2 |
20090006855 | Tuyls et al. | Jan 2009 | A1 |
20100329448 | Rane et al. | Dec 2010 | A1 |
20130318351 | Hirano et al. | Nov 2013 | A1 |
20140281567 | Rane et al. | Sep 2014 | A1 |
20150288519 | Tuyls | Oct 2015 | A1 |
20150381348 | Takenaka | Dec 2015 | A1 |
20150381349 | Nikolaenko | Dec 2015 | A1 |
20170149558 | Patel | May 2017 | A1 |
20180349585 | Ahn et al. | Dec 2018 | A1 |
20210124815 | Rindal | Apr 2021 | A1 |
Number | Date | Country |
---|---|---|
2278750 | Jan 2011 | EP |
2680488 | Jan 2014 | EP |
3007382 | Apr 2016 | EP |
Entry |
---|
Extended European Search Report for European Patent No. 20878595.6, dated May 25, 2023. |
Notice of Allowance dated Oct. 20, 2021 for U.S. Appl. No. 16/664,530 (pp. 1-7). |
Office Action dated Aug. 27, 2021 for U.S. Appl. No. 16/664,530 (pp. 1-5). |
Office Action dated Jun. 10, 2021 for U.S. Appl. No. 16/664,530 (pp. 1-5). |
Number | Date | Country | |
---|---|---|---|
20220129531 A1 | Apr 2022 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 16664530 | Oct 2019 | US |
Child | 17569281 | US |