In this paper, the privacy/security of the proposed protocols is measured by the amount of information disclosed during execution. We adopt the security definitions and proof techniques from the literature on secure multi-party computation to analyse. The secure multi-party computation problem involves multiple parties collaboratively performing various types of computation with- out compromising the privacy of data. In the mid 1980s, C. Yao [8] introduced the idea of securely computing any two-party functionality in the presence of dishonest adversaries. Since then, various privacy-preserving protocols have been proposed to address different class of computation problems in the context of private data.

There are two common adversarial models under secure multi-party compu- tation: semi-honest and malicious. In the malicious model, the adversary has the ability to arbitrarily deviate from the protocol specifications. On the other hand, in the semi-honest model, an attacker (i.e. one of the participating parties) is expected to follow the prescribed steps of the protocol. However, the attacker is subsequently free to compute additional information based on his or her private input, output and messages received during the execution of the secure protocol. Although the assumptions of the semi-honest adversarial model are weaker than those of the malicious model, we insist that this assumption is realistic under the problem settings. We assume that the data keepers are trusted (as they are governmental agencies) to ensure the confidentiality of sensitive client data. It is difficult to imagine them colluding with other companies to damage their own reputation. Moreover, it is often non-trivial for one party to maliciously deviate from a particular protocol which may be hidden in a complex process.

In short, we assume that the verifier and the data keeper are semi-honest. They will correctly follow the protocol specifications. However, at the same time, they are also curious about the applicants’ information. In general, secure personal information as described in Section 5 should meet the following privacy requirements:

・ Client-to-verifier privacy. The verifier should not be able to gain any details concerning the client’s personal data stored in the data keeper’s database, except for those he can learn from the result (i.e. the client qualifies or not).

・ Client-to-data-keeper privacy. At any point during protocol execution, the identity of the applicant should not be revealed to the data keeper.

・ End user’s privacy. The verifier should not be able to obtain any information relating to other clients stored in the data keeper’s database.

・ Verifier-to-data-keeper privacy. The details of the predicates should not be leaked to the data keeper. This requirement is particularly applicable to private services where the selection criteria may be private to the provider.

An additive homomorphic encryption scheme is a cryptosystem that allows arithmetic (i.e. addition) operations to be performed on the ciphertext without decryption or knowing the actual values. Efficient additive homomorphic cryptosystems have been proposed, such as the Pallier cryptosystem [11] , or the Damgard and Jurik cryptosystems [12] , which are Paillier encryption scheme of flexible lengths. For simplicity, we assume that a Paillier cryptosystem is used for encryption and decryption throughout this paper.

The Paillier cryptosystem consists of three algorithms:

1): Inputs a security parameter and produces the key pair.

2): Inputs a public key and a message m, and outputs a ciphertext c.

3): Inputs a private key and a ciphertext c, and outputs a message m, such as.

The security of the Paillier encryption scheme relies on the computational hardness assumption of a novel mathematical problem called composite residuosity. The decision version of this problem class assumes that no polynomial-time algorithm can distinguish the N-th residues modulo with a non-negligible probability. and denote the Paillier encryption and decry- ption algorithms, respectively.

The Paillier cryptosystem is additive homomorphic encryption. If we consider two operators ´ and + in the ciphertext and the plaintext domains, respectively, and are two plaintext elements. The Paillier encryption scheme satisfies the followings properties:

・ Additive Homomorphism:

・ Homomorphic Multiplication:

・ Semantic Security: Informally, a semantically secure [13] encryption scheme is a probabilistic, polynomial-time algorithm such that given the ciphertext, an adversary cannot deduce any additional information about the plaintext.

The above computation is performed modulo. We refer the reader to [11] for more details. We also note that any additive homomorphic encryption scheme that satisfies the above properties can be utilized to implement our proposed framework.

Our proposed approach to the secure information verification problem consists of four stages:

1) Setup―During this phase, the client goes through an anonymous authen- tication process so that the verifier is authenticated to communicate with the data keepers for the verification stage. In addition, the data keeper and the verifier generate an encryption key pair and exchange the public key of the homomorphic cryptosystem. These public keypairs are utilized for secure com- munication and computation at the later stages.

2) Single Predicate―In this stage, the data consumer evaluates a predicate for each entity in the dataset of the data keeper. The output of this stage is the encryption of either 1 or 0, depending on whether the entity satisfies the pre- dicate.

3) Secure Complex Predicate Evaluation―Based on the results of the previous stage, the verifier collaborates with the data keeper to compute the result of the complex logical combination of Boolean predicates. Again, the output of this stage is the encryption of either 1 or 0 depending on whether the entity satisfies the predicate.

4) Aggregation of Output Data―At this stage, the final result is aggregated, decrypted and shown to the verifier. Since the data keeper computes the de- cryption, we propose a secure protocol to generate the outcome so that the data keeper cannot obtain any information concerning the final result.

In the setup phase, the client is first required to complete anonymous authen- tication with the data keeper Alice, who then allows the verifier Bob to initiate the secure information verification process on the records of Alice’s database. When the clients agree to their personal information being stored in Alice’s database, she issues to each client a credential to be used for authentication. Each time a client subsequently requests access to Alice’s database, he/she uses her credentials for verification with Alice, who begins communication with Bob for the information verification process.

Traditional password-based authentication systems expose the identity of the client to the data keeper Alice. Hence, they violate the client-to-data-keeper privacy requirement. To satisfy this, it is desirable to have an authentication scheme that promises unlinkability, i.e. the server should not be able to link user requests such that access to the same user cannot be recognised as such.

As the anonymous authentication process is not our main contribution here, we only briefly review possible approaches to satisfy this requirement. The most feasible solution is anonymous credentials introduced by D. Chaum [14] . This allows a user to prove that he/she has obtained a credential issued by an organisation without revealing anything regarding his/her identity other than the credential. J. Camenisch [15] proposed a protocol that allows an organisation to issue a credential by obtaining a signature on a committed value. The client can then prove with zero knowledge that she has a signature under the organisation’s public key on the given value.

Applied to our problem setting, the client first generates a non-interactive zero-knowledge proof (i.e. applying the Fiat--Shamir transform) of his/her credentials with Alice. He/She transfers the proof to Bob, who submits the proof to Alice. Finally, Alice authenticates Bob to communicate and verify the client’s information.

Following the authentication process, Alice and Bob generate two Paillier key pairs using the algorithms and agree on two key public pairs for communication during verification execution. We denote by and the Paillier encryption under Alice’s public key and that under Bob’s public key, respectively.

In the single predicate evaluation stage, for each data record and each attribute that needs to be verified, the verifier Bob and the data keeper Alice together perform one of the following protocols: equality predicate evaluation, inequality predicate evaluation and (non-) membership predicate evaluation. The output of each protocol is an encrypted bit maintained by Bob. The resulting bit is encrypted under the data keeper’s public key so that Bob cannot obtain any information relating to the other entities in the database. We now describe the three protocols to securely evaluate the results of these predicates.

At this stage, Bob holds the encrypted result of the evaluation for each data record, with each attribute in a complex predicate that needs to be verified. This sub-section discusses three basic primitives that operate on the encrypted inputs at this stage. With these primitives, Bob has the capability to compute the results of the encryption of the desired bit to evaluate each data record. The output of this stage is an encrypted bit for each data record. This bit indicates whether the given record satisfies the complex statement.

The inputs of the three primitives are either one encrypted bit (NOT opera- tion) or two encrypted bits (AND and OR operations). They are described as follows:

1) (NOT)―It is easy to derive the formula for bit negation operation:. Clearly, the operation leaks no information re- garding the encrypted bit x to either Alice or Bob. It requires one exponentiation operation and one multiplication operation. Alice receives no more data, whereas Bob only works on his inputs, which are encrypted data.

2) (AND)―Because for any two bits, the primitive is identical to the description of SecMul (Protocol 2). The protocol requires five multiplication operations and five exponentiation operations in ciphertext space. The security of the protocol follows the analysis of secure multiplication (i.e. Protocol 2).

3) (OR)―Since, we can derive the definition of the OR primitive as in Protocol 5. The protocol requires seven multiplication operations and six exponentiation operations in ciphertext space. During the protocol, data that Bob and Alice receive are identical to those received during Protocol 2; hence, Bob and Alice gain nothing following protocol execution.

As the input of this stage, for each entity in Alice’s database, Bob holds an encrypted bit that determines whether the data record qualifies the complex statement. In order to ensure there is exactly one qualified data record in case the application is successful, we introduce one special attribute to the final complex predicate. The attribute is the secret identification of the client in the database.

We assume that when the client registers his/her data with Alice the data keeper, Alice generates a secret random number to identify the client. The number is stored in the database as an attribute of the client. We introduce additional steps to address the requirement:

1) The client encrypts the random secret under Bob’s key, obtain.

2) The client anonymously sends the encryption of secret value to Alice.

3) Alice and Bob perform secure equality evaluation (starting from step 2) and get the result.

4) Bob applies AND operation with and the current result of evaluation process.

With the additional step, now Bob holds an array of encrypted bits with all 0s and at most one bit 1. Bob uses a homomorphism to compute the encrypted sum of these bits; the result is the encryption of either 1 or 0. He can send it to Alice for decryption and obtain the final result to determine whether the applicant qualifies. However, this may compromise Bob’s privacy, especially when he wants to hide his business progress. In order to maintain his privacy, we introduce one step for the randomization of the decryption process as follows:

1) Bob computes the encrypted sum using a homomorphism to obtain.

2) Bob generates a random number r, and computes and sends to Alice.

3) Alice decrypts c to obtain and sends it back to Bob. Note that Alice only receives a random number so that she learns nothing about the result of the application.

4) Bob computes the result.

Finally, Bob is able to decide the result of the verification process by bit s.

We first consider the security of the entire system, since all intermediate results revealed to Alice and Bob are either random or semantically secure encryptions of numbers. Furthermore, the outputs of all sub-protocols (only seen by Bob) are always encrypted under Alice’s key. Under the assumptions of the semi-honest model, we claim that the sequential composition of these sub- protocols leaks no details of the client or the predicates proposed by the verifier.

The second issue we consider is the practical implementation of the system. Since the same procedure is applied for all the data entries, the verification results for each data record can be computed in parallel. That means we are able to construct multiple verification threads, each one is corresponding to one data entry. By the batch verification approach, we can improve the running time of the whole process by a factor of n/m, where n is the number of data records and m is the number of threads.

While the same procedure is applied for each data record, the data keeper is not able to know who is the applicant. In practice, there are some cases that the data keeper (e.g. a governmental agency) is allowed to know the identity of the applicant, where this rigorous security feature is then not required. The proposed solution can be modified, and inherently improves performance. Specifically, the client can perform a simple authentication rather than an anonymous solution to allow the verifier to communicate with the data keeper. The verification process only needs to be performed on the only one data record identified by the client. Hence, the cost of the proposed solution is reduced by a factor of n where n is the number of data records in the data keeper’s database.

In our proposed solution, an applicant qualifies only if he/she satisfies all criteria specified by a single predicate or complex predicates. Hence, we can define a complex predicate to cover all criteria using the AND operation. We also can extend our protocol to adapt to threshold criteria, where the applicant qualifies only if he/she satisfies more than k criteria. The idea is to compute the sum of each predicates evaluation (in encrypted form) and apply a slightly modified version of Protocol 3 to compare the encrypted value with threshold k.