Privacy-preserving policy evaluation in multi-party access control

2.1.Policy specification and evaluation

For the specification of user and multi-party access control policies, we rely on an attribute-based access control (ABAC) policy language inspired by PTaCL [10,37], which provides an abstraction of the XACML policy language [44]. We first present an extension of the PTaCL syntax, which comprises two languages, one for targets, which is used to specify the applicability of a policy to a query, and another for policies, which is used to specify how policies are combined. Then, we present the semantics of target and policy evaluation.

ABAC Syntax: Let A={a1,…,an} be a finite set of attributes, where the domain of an attribute a is denoted by Va. The set of queries QA is defined as P(⋃i=1nai×Vai), and a query q∈QA is the set of attribute name-value pairs:

To determine the applicability of a policy to a query, we employ a target language, denoted by TA, which extends the PTaCL target language to allow the specification of access constraints built using the set of binary predicates Φ={=,≠,⩽,⩾}.33 A target t∈TA is defined as:

PTaCL also provides a policy language PA, where a policy p∈PA is defined as:

ABAC Semantics: Given the set of policies PA, the set of queries QA, and the set of decisions D, a policy evaluation function is a function ⟦·⟧:PA×QA→D, such that for query q and policy p, ⟦p⟧(q) represents the decision of evaluating q against p.

To evaluate a query against a policy, we first need to determine whether the policy is applicable to the given query. Given a query, a target evaluates to a single value in D3={1,0,⊥}, intuitively indicating if the target matches the query (1), if it does not match the query (0), or if the query does not contain the attributes required to evaluate the applicability of the target (⊥), respectively. Formally, given a query q, the target evaluation function is defined as:

A policy is evaluated to decisions within D7=P({1,0,⊥})∖∅, where 1 and 0 indicate that access should be granted or denied respectively, and ⊥ that the policy is not applicable to the given query. Non-singleton decisions are returned when the query does not provide the required information to evaluate a target. Intuitively, non-singleton decisions correspond to the Indeterminate decision in XACML [38]. It is worth mentioning that even though this set is syntactically equivalent to the one used for targets, the meaning of the values depends on whether it is used as a target or policy. Formally, the evaluation of policy p is given by the function:

2.2.Homomorphic encryption

Homomorphic Encryption (HE) is a family of cryptographic schemes that enable computation over encrypted data. HE allows performing an operation on ciphertexts, such that the resulting ciphertext would decrypt to the same value that would have been obtained by performing the operation on the corresponding plaintexts. In this work, we employ an additively homomorphic cryptosystem, e.g. the Paillier cryptosystem [46], which preserves the result of the addition of two ciphertexts.

Let Epk(·) and Dsk(·) represent the encryption function (with public-key pk) and decryption function (with secret-key sk), respectively. Let m1 and m2 be two messages and c a scalar value. The additive homomorphism has the following properties:

In additive homomorphic cryptosystem, addition and scalar multiplication operations are performed over ciphertexts, without the need to decrypt them. However, performing more complex operations in additive homomorphic cryptosystem requires designing two-party interactive protocols. Next, we introduce secure two-party computation protocols, which serve as building blocks for the construction of our HE-based protocols encoding policy evaluation.

Secure Equality Protocol: Secure equality is used to determine the equality of two ciphertexts [41]. Given two ciphertexts [a] and [b], the secure equality test between [a] and [b] is defined as follows:

2.3.Secure function evaluation

Despite allowing computations in the ciphertext domain, homomorphic encryption is usually expensive in terms of computation cost. Secure function evaluation (SFE) is an alternative to homomorphic encryption that enables several parties to compute a function on their private inputs without revealing any information apart from the result of the function. In this work, we implement secure function evaluation in two-party setting using the ABY framework [13]. ABY provides the constructions for Arithmetic circuits [4], Boolean circuits [22], and Yao’s garbled circuits [57]. For our work, we only use Boolean circuits since they provide efficient constructions for nonlinear functions.

Given two parties P1, P2 and their corresponding inputs x and y, ABY first creates secret shares for each party and a circuit that computes a specific function f, and then evaluates f on the secret shares using the circuit. Secret shares of each party are represented as ⟨x⟩1, ⟨x⟩2 and ⟨y⟩1, ⟨y⟩2. Secret shares are created for each bit of the input: given a bit xi, ⟨xi⟩1, ⟨xi⟩2 are such that ⟨xi⟩1⊞⟨xi⟩2≡ximod2, where ⊞ represents bitwise XOR operation. The result of the function is reconstructed by combing the secret shares obtained by each party through a bitwise XOR operation.

For this work, we adopt seven Boolean gates from the ABY framework as building blocks for the design of our SFE-based policy evaluation protocols. For more details on the mechanism and implementation of Boolean circuits, we refer the reader to [13]. Next, we present these gates.

Inverse Gate: The inverse gate is used to compute the negation of a secret shared input in modulus 2ℓ. The inverse here refers to the additive inverse in mod2ℓ, such that the additive inverse of a number a is equivalent to 2ℓ−a. Given a secret shared input ⟨a⟩, the inverse gate is defined as:

3.1.Multi-party policy model

Collaborative systems usually provide their users with an environment in which they can interact and jointly contribute to the creation and management of shared resources. To protect those resources, each user can specify access requirements stating who is authorized to access them and under which circumstances. The access requirements provided by different users, however, can be in conflict. Therefore, a collaborative system should resolve these conflicting requirements in order to determine whether access to co-owned resources should be granted.

Traditional access control models are centered on a single-owner governance model (i.e., they assume that resources are controlled by single entities) and, thus, they are not suitable for collaborative systems [11,24]. To this end, recent years have seen the emergence of several models for multi-party access control [45]. These models enable collaborative access decision making by providing a means to reconcile the conflicts arising from the evaluation of the access requirements provided by users involved in the protection of co-owned resources.

In this work, we adopt the data governance model proposed in [35] as the underlying multi-party access control model. This model provides a general framework to explicitly reason on the level of authority that users have over co-owned resources based on their relations with the resource [12] and to build a multi-party access control policy based on their authorization requirements. Specifically, it captures the relations that users have with a co-owned resource and, based on these relations, determines suitable strategies to resolve possible policy conflicts, thus accounting for the level of authority that users have on co-owned resources. These policy conflict resolution strategies can be realized using the operators presented in Table 1. Compared to other models for multi-party access control (see [45] for a survey), the model in [35] allows a more fine-grained governance of co-owned resources by allowing the adoption of arbitrary conflict resolution strategies.

As an illustration of the application of this model, consider the following example, which is based on one of the scenarios presented in the introduction. In particular, consider the case where two car companies (C1, C2), a navigation company (N1) and a ride sharing company (R1) form a joint venture to build a classification model in order to support autonomous driving cars in finding the fast navigation paths with respect to traffic conditions. To this end, these companies share their camera data, LiDAR sensor information, digital mapping data and passengers’ route preferences to train the classification model. The partners also agree that the model can be shared with other collaborators and clients for research purposes and/or additional revenue.

The classification model, however, can be used to reconstruct potentially privacy-sensitive training data [33]. Therefore, each partner in the joint venture might specify access control policies determining who is authorized to access the model and under which conditions based on their own business constraints. Below, we present some hypothetical policies, denoted by pC1, pC2, pR1 and pN1, for each partner:

These policies can specify conflicting access constraints. For instance, C1’s policy would allow a client riding sharing company located in the EU to access the model, whereas R1’s policy would deny that request; on the other hand, car company C2 and navigator company N1 do not impose any constraints for this case (i.e., the evaluation of their policies would return the not-applicable decision). To determine whether access to the classification model should be granted or not, the access control policies of every partner in the joint venture should be combined together, forming the multi-party access control policy for the classification model. Following the framework in [35], such a multi-party policy can be defined, for instance, by taking into account the shares of each partner in the joint venture. For example, the multi-party policy p=(pC1△pC2)⊳(pN1△pR1)⊳0 indicates that the access constraints of the car companies C1 and C2 have priorities over the constraints of other partners (e.g., due to their larger shares in the joint venture) and that access is denied in case none of the partners’ policies applies.

The multi-party policies considered in this work can be evaluated using existing access control mechanisms. However, such mechanisms require the policies to be provided in plaintext in order to be evaluated. Making these policies available to other partners (or third parties) might reveal confidential information about a company’s business strategies and commercial relationships with other companies, which the company might want to keep confidential (e.g., by knowing pC1, one may infer that C1 does not have clients and/or collaborators outside the EU). Information about companies’ business relationships can be exploited by the competitors to drive more appropriate business strategies, to make better decisions towards pricing, terms, risk, and thus win business competition [20]. In this work, we focus on the protection of user policy confidentiality and propose a framework that allows the involved members to disclose their access control policies in a private form while still remaining capable of making collaborative access decisions based on the access constraints provided by each individual user.

3.2.Architecture

To enable the evaluation of multi-party policies while protecting the confidentiality of user policies, we design an access control framework that supports policy evaluation over protected input. An overview of the proposed framework for privacy-preserving multi-party access control is presented in Fig. 1. The framework is general and can be realized using various privacy-preserving techniques. To avoid confusion, hereafter, we denote the protected version of a message m regardless of the specific privacy-preserving technique used for its realization as ⦗m⦘ and use the notation introduced in Section 2 only when explicitly referring to Homomorphic Encryption and Secure Functional Evaluation.

The proposed framework comprises four main entities:

Fig. 1.

Architecture.

Data holders provide their policies in a private form (represented by ⦗s1⦘,…,⦗sn⦘ in Fig. 1) to the Data Server. Data holders are not involved in the evaluation of either their policies or the multi-party policy and, thus, they are not required to be online for a decision to be made. This task is performed by the Data Server together with the STP.

Upon receiving an access request, the Data Server’s policy evaluation point evaluates the request against the multi-party policy, which comprises the user policies, under privacy preservation with the assistance of the STP. To enable policy evaluation under privacy preservation, we propose secure computation protocols to determine the applicability of policies to the access request and to compute the combining operators in Table 1 over private inputs (cf. Section 4). These protocols can be used as building blocks for the secure evaluation of arbitrary multi-party policies expressed using those operators.

Once the multi-party policy has been evaluated, the policy evaluation point returns the access decision in private form, ⦗d⦘, corresponding to the evaluation of the access request against the multi-party policy. To be able to enforce the decision, the Data Server derives the decision in plaintext from the decision in private form together with the STP.

We have realized the framework using two alternative privacy preserving techniques, namely Homomorphic Encryption (HE) and Secure Functional Evaluation (SFE). The underlying privacy-preserving technique dictates the ‘private form’ in which policies are provided and the computations to be performed in order to obtain the access decision in plaintext. In HE, the STP generates public (pk) and private (sk) keys and sends the public key pk to the data holders and to the Data Server. Data holders encrypt their policies using pk and send the encrypted policies to the Data Server. To derive the access decision, the Data Server should not have access to the private key; otherwise, it will be able to learn users’ policies. In order for the Data Server to decrypt the encrypted decision without the STP learning it, the Data Server adds random noise r to the encrypted decision [d] and sends [d+r] to the STP. The STP decrypts the ciphertext and sends d+r to the Data Server. The Data Server can obtain the decision to be enforced by removing noise r.

In SFE, data holders create two secret shares of their policies and provide one share to the Data Server and the other share to the STP. After policy evaluation, the Data Server derives the access decision in plaintext from the decision in private form by recombining the secret share obtained by evaluating the multi-party policy with the one obtained by the STP (cf. Section 2.3).

3.3.Security assumptions

We assume a semi-honest security model where all participants are assumed to be honest-but-curious [21]. This model implies that all entities follow the protocol specification properly, but they are interested in obtaining more information from their input, intermediary messages and output. Specifically, they keep track of the messages exchanged and try to learn as much information as possible from them. This assumption guarantees that computations do not leak any unintended information. It is worth noting that while the semi-honest adversary model is more restrictive compared to the malicious model, it is a well-accepted adversary model with many applications in real-world scenarios, e.g., to protect sensitive information against passive insider attacks by administrators or government agencies, or when it is assured that the parties are trusted to not actively misbehave [13]. In this light, the semi-honest adversary model can be applied in the context of privacy preserving multi-party access control as the involved parties are typically engaged in a collaboration, implying that there exists a certain level of trust among them (see, e.g., the scenarios in the introduction). We also remark that the semi-honest adversary model enables an efficient implementation of the secure computation protocols performing considerably faster than the malicious setting, while offering a sufficient level of security [47]. This is specifically a desirable property for applications like the evaluation of security policies in private forms where (collaborative) access decisions should be made in a short amount of time.

With respect to the semi-honest security assumption, our goal is to design protocols that provide security against honest-but-curious non-colluding Data Server and STP. The non-colluding two-server setting is typically employed to reduce the workload on the client side. Without the employment of a semi trusted party, all computations have to be performed between the client and Data Server. This, however, is not desirable because it requires the data holders to have enough computational resources and to be online during computations. Note that the definition of protocols aiming to prevent the Data Server and STP from colluding is orthogonal to the scope of this work and here we consider them as two servers with independent interest who do not wish to or cannot collude [30]. The assumption of non-colluding Data Server and STP can be achieved through physical means (e.g., with the use of ballot boxes [32]) or by adding additional security verification on trusted communication channels (e.g., with the use of mediator model [1]). Moreover, several approaches have been proposed to verify the faithfulness of servers in secure two-party computation. For instance, it has been shown that multi-party computation protocols secure against semi-honest adversaries can be transformed to zero-knowledge proofs [23,28].

Nonetheless, we assume that a semi-honest adversary can compromise any subset of data holders (where at least two data holders are honest), the access requester and at most one of the STP and Data Server (i.e., if one is controlled by the adversary, the other behaves honestly66). This security definition assumes that such an adversary can only learn the policies of the data holders it has compromised and the final output but nothing else about the policies of the honest data holders [36]. We require that at least two data holders are honest because colluding data holders can learn the policy evaluation of the other data holders by comparing the final decision with the evaluation of their policies due to the definition of the used policy combining operators (see also Section 6). Imposing that at least two data holders are honest allows us to focus on flaws in the design of the protocols rather than on leakages that are inevitable.

We also assume that all parties communicate over an authenticated channel. This assumption aims to prevent attacks coming from outside the framework.

4.1.Data structures

This section presents the data structures used for the specification of policies in private form and the representation of the decision space to enable the design of efficient protocols for secure policy evaluation.

Policy Specification: Privacy-preserving technologies like Homomorphic Encryption and Secure Function Evaluation only operate on integer numbers. To this end, we encode every attribute (ai∈A) and their attribute values (v∈Vai) into a unique integer number,77 where for numeric attribute values the ordering is preserved.

This work aims at a privacy-preserving mechanism that allows the evaluation of multi-party access control policies while protecting the confidentiality of the user policies forming the multi-party policy. In this light, we aim to protect the constraints in the target, which determine the applicability of policies, along with atomic policies (i.e., policies consisting of the permit and deny decisions) whereas combining operators are not protected. An atomic target t=aϕv is protected by protecting the attribute a, attribute value v, and predicate ϕ individually, i.e. ⦗t⦘=(⦗a⦘,⦗v⦘,⦗ϕ⦘). Given that an atomic target always consists of three elements, protecting each element of the target individually does not disclose information about the target. Note that, in order to reason over predicates under privacy preservation, they are also encoded into integer numbers. Hereafter, we use 1, 2, 3 and 4 to denote =, ≠, ⩽ and ⩾, respectively. A composite target t=op(t1…tk) is in protected form if its subtargets are in protected form, i.e. ⦗t⦘=op(⦗t1⦘,…,⦗tk⦘). Atomic policies are protected by protecting the decision, i.e. ⦗1⦘ and ⦗0⦘. Targeted and composite policies p are in protected form if their subpolicies and target (for targeted policies) are in protected form.

Note that, in this work, queries are not considered sensitive and, thus, they are received in plaintext. However, in order to be able to evaluate a policy against a query, the attributes and attribute values in the query should be mapped to integer numbers following the same encoding of attributes and attribute values used for the policy.

Decision Space: In this work, we adopt a policy language that is grounded on a three-valued logic and use D7=P({1,0,⊥})∖∅ as the decision set (cf. Section 2.1). Although this language is representative for several ABAC policy languages like XACML [38], the use of D7 and three-valued logic introduces a number of challenges when policy evaluation is performed under privacy preservation. Non-singleton decisions – even when each element of the decision is given in protected form – might reveal some information about user policies by observing the ‘size’ of the decision. For instance, by observing a decision consisting of three elements, an attacker can easily infer that the decision is {1,0,⊥} as this is the only decision consisting of three elements. Therefore, we need to mask the ‘size’ of decisions in order to preserve the confidentiality of user policies. One possible solution for hiding the number of elements in a decision is to use data packing [55]. The main idea behind data packing is to efficiently use the ciphertext message space, which is generally much larger than the size of encrypted values, to pack a set of values in one ciphertext. However, data packing techniques require packing and unpacking the set for each round of communication and, thus, it is not efficient to be employed in our context. Moreover, while data packing techniques have been proposed for Homomorphic Encryption [42], it is not supported by other secure computation frameworks like Secure Function Evaluation. In addition, previous work [51] has shown that a direct encoding of the three-valued logic operators in Table 1 requires the application of secure multiplication, equality and comparison protocols, which are usually heavy in terms of both computation and communication costs.

For the design of efficient secure computation protocols able to evaluate a policy in protected form against a query, we need suitable representation of the decision space encoding the results of policy evaluation. Inspired by previous work [37,56], we adopt a Boolean representation of the decision space and three-valued operators in Table 1. Given a policy p, we represent the decision space of p as a triple (b1,b0,b⊥) of propositional formulas representing sets of queries Q1, Q0 and Q⊥ such that d∈⟦p⟧P(q) exactly when q∈Qd. Intuitively, each element bi corresponds to a single decision i∈{1,0,⊥} with bi∈{1,0} such that bi=1 means that i∈d and bi=0 that i∉d.

In order to encode the target and policy evaluation functions and three-valued logic operators in Table 1 into triples of propositional formulas, we adopt and extend the rules proposed in [37]. These rules can be employed to compute a triple of propositional formulas (b1,b0,b⊥) representing ⟦p⟧P. More precisely, each propositional formula bd denotes the set of queries Qd⊆Q satisfying d=⟦p⟧P(q), whenever q∈Qd. The transformation rules τ (for targets) and π (for policies) presented in Tables 2 and 3 explain the construction of the propositional formula for all targets, (policy) constants and all (policy and target) operators in Table 1. We refer to [37] for details on the correctness of transformation rules τ and π.

This encoding of the target and policy evaluation functions allows the definition of protocols implementing the ¬, ∧, and ∨ operators, which can efficiently be implemented using inverse, AND and OR gates in SFE and negation, maximum and minimum protocols in HE (see Section 5). Moreover, this encoding allows masking the number of elements forming a decision d by using a fix-size representation for all decisions.

4.2.Target evaluation

To enable the secure evaluation of targets in protected form against a query, we design secure computation protocols implementing the rules presented in Table 2 over protected input. We first propose generic secure computation protocols for the evaluation of atomic targets (the first row of Table 2). As it can be observed in the table, two operations are needed for such an evaluation: i) an operation to determine whether the attribute in the target is present in the query (a∈Aq) and ii) an operation to determine whether there exists an attribute name-value pair in the query that satisfies the constraint in the target (⋁vi∈Va∣q(viϕv)). To this end, we propose building-block protocols for the secure computation of these two operations – secure membership and secure matching – over protected inputs. Then, we present a generic protocol for target evaluation.

Secure membership protocol. Secure membership is used to determine whether an encrypted value belongs to a set of encrypted values [19]. Given a ciphertext ⦗a⦘ and a set of ciphertexts ⦗B⦘={⦗b1⦘,…,⦗bn⦘}, we can determine if ⦗a⦘ belongs to ⦗B⦘ using the following protocol:

Secure matching protocol. To determine whether a policy is applicable to a query we need to verify if the attribute name-value pairs forming the query satisfy the constraints in its target. To this end, we first define the secure value-matching protocol to determine whether a protected value satisfies the constraint defined in an atomic target under privacy preservation and, then, we show how this protocol can be used to determine whether there exists an attribute name-value pair in the query that satisfies the target.

Recall that our goal is to protect the confidentiality of user policies. Accordingly, the constraints establishing the applicability of these policies should be protected and, thus, we assume that not only the attribute name and value but also the predicate in an atomic target is in protected form. Given an atomic target in protected form ⦗t⦘=(⦗a⦘,⦗v⦘,⦗ϕ⦘) and a protected value ⦗v′⦘, we define the secure value-matching protocol as follows:

The value-matching protocol verifies whether a given attribute value satisfies the constraint defined in the target. Determining whether a policy is applicable to a given request requires extending this verification by checking if there exists an attribute name-value pair in the query that satisfies the target of the policy. To this end, we define the secure matching protocol (Algorithm 1). Given an atomic target in protected form ⦗t⦘=(⦗a⦘,⦗v⦘,⦗ϕ⦘) and a query q={(a1,v1),…,(an,vn)}, the secure matching protocol determines whether the query contains an attribute name-value pair that satisfies the target under privacy preservation. The protocol encompasses two for loops to verify the target against every attribute name-value pair in the request.88 If the attribute in the target is present in the request and at least one of its values in q satisfies the constraint in the target, the protocol returns ⦗1⦘; otherwise the protocol returns ⦗0⦘.

Algorithm 1:

matching: secure matching protocol

Target evaluation protocol. We have now the machinery to define the protocol for secure target evaluation. Given a target in protected form ⦗t⦘ and a query q, the secure target evaluation protocol evalt(⦗t⦘,q) consists of three subprotocols evalit(⦗t⦘,q) with i∈{1,0,⊥}, and evaluates to a triple of protected values (⦗d1⦘,⦗d0⦘,⦗d⊥⦘) with di∈{1,0} such as ⦗di⦘=evalit(⦗t⦘,q). Next, we define protocol evalt(⦗t⦘,q) per cases based on the grammar of TA presented in Section 2.1.

Atomic target: Given an atomic target in protected form ⦗t⦘=(⦗a⦘,⦗v⦘,⦗ϕ⦘) and a query q, protocol evalt(⦗t⦘,q) consists of subprotocols:

4.3.Policy evaluation

The secure evaluation of a policy against a given query requires secure computation protocols implementing the formulas given in Table 3. Here, we provide the design of a generic protocol for policy evaluation under privacy preservation and then we discuss in Section 5 how it can be realized in Homomorphic Encryption and Secure Function Evaluation.

Given a policy in protected form ⦗p⦘ and a query q, the secure policy evaluation protocol evalp(⦗p⦘,q) consists of three subprotocols evalip(⦗p⦘,q), one per each single decision i∈{1,0,⊥}, and evaluates to a triple of protected values (⦗d1⦘,⦗d0⦘,⦗d⊥⦘) with di∈{1,0} such as ⦗di⦘=evalip(⦗p⦘,q). Next, we define protocol evalp(⦗p⦘,q) per cases based on the grammar of PA presented in Section 2.1.

Decision policy: Given a policy comprising the permit or deny decision in protected form (⦗1⦘ and ⦗0⦘ respectively) and a query q, protocol evalp(⦗p⦘,q) consists of the following subprotocols:

5.1.SFE-based protocols

To realize the protocols presented in Section 4 using Secure Functional Evaluation (SFE), we employ the building blocks presented in Section 2.3, i.e. inverse, AND, OR, subtraction, multiplication, equality, and comparison gates. We first observe that the protocols for the evaluation of composite targets (Table 2) and policies (Table 3) are built over operators ¬, ∧ and ∨, which can be implemented in SFE using the inverse, AND and OR gates, respectively. Therefore, in this section, we only detail how the secure membership and matching protocols can be realized in terms of SFE gates.

Secure membership protocol. Given a secret shared input ⟨a⟩ and a set of secret shared values B={⟨b1⟩,…,⟨bn⟩}, the secure membership protocol checks whether a belongs to B under privacy preservation. This protocol can be realized in SFE as:

Secure matching protocol. To verify the applicability of a secret shared policy to a query, we realize the value-matching protocol presented in Section 4 using Secure Function Evaluation. Given a secret shared target ⟨t⟩=(⟨a⟩,⟨v⟩,⟨ϕ⟩), and a secret shared value ⟨v′⟩, the value-matching protocol is implemented in SFE as:

5.2.HE-based protocols

As an alternative to Secure Function Evaluation, we realize the protocols for secure policy evaluation using (additively) Homomorphic Encryption (HE). Specifically, we implement the generic protocols presented in Section 4 using the five cryptographic building blocks presented in Section 2.2, i.e., addition, subtraction, multiplication, equality and comparison. As shown in Tables 2 and 3, the protocols for secure policy evaluation rely on operators ¬, ∧ and ∨. To this end, we first discuss how the secure computation of these operators can be realized in HE. Then, we present the implementation of the secure membership and matching protocols.

Secure HE-based computation of operators ¬, ∧ and ∨. For the realization of the secure membership and matching protocols as well as for the realization of the protocols for secure evaluation of composite targets and policies, we need building block protocols implementing operators ¬, ∧ and ∨.

It is worth noting that operators ¬, ∧ and ∨ defined over Boolean logic are a reduction of the negation (¬), strong conjunction (⊓˜) and strong disjunction (⊔˜) operators defined over three-valued logic [38], for which HE-based protocols have been proposed in [51]. Here, we propose an alternative implementation based on the Boolean encoding of the decision space (cf. Section 4.1), which is computationally cheaper compared to one proposed in [51] (cf. Section 5.3.2).

Operator ¬: Given an encrypted value [a], protocol ⌽[a] computes the negation of a (i.e., ¬a) under encryption as follows: