Providing privacy on the tuple space model

2.1 DEPSPACE: A BFT coordination system

The DEPSPACE [5] system provides a Byzantine Fault-Tolerant (BFT) [14] coordination service based on the tuple space model. The following security and dependability attributes (or properties) are necessary for this model [1]: (1) reliability – the operations executed in the tuple space change its state according to their specification; (2) availability – the tuple space is always ready to execute the operations required by authorized parties; (3) integrity – no improper alteration of the tuple space can occur; (4) confidentiality – the content of tuple fields cannot be disclosed to unauthorized parties. With the goal of ensure these properties, DEPSPACE is built over a set of layers, each one responsible for the execution of a different functionality.

2.1.1 DEPSPACE layers

This section introduces the DEPSPACE layers emphasizing the confidentiality layer, which is responsible for the aspects related to this work. Figure 2 shows the layers and their location in the stack at both clients and servers.

Replication. To maintain consistency in the tuple space, DEPSPACE utilizes State Machine Replication [15, 16] as the bottom layer. This mechanism is related mainly with the properties of availability, integrity and confidentiality. Considering a system with n replicas/servers, it ensures that operations are executed according to their specification even if up to f=(n−1)/3 replicas are malicious (the correct replicas mask the behavior of the malicious ones). Through these protocols, the correct replicas execute the same sequence of operations and returns the same values, evolving in a synchronized way.

Confidentiality. Since tuples are maintained replicated in a set of servers, the provision of confidentiality (and privacy) must not be attributed to a single server because up to f of them could fail and expose the tuple contents to unauthorized parties.

Consequently, DEPSPACE implements confidentiality through the use of a (n,f+1)-Publicly Verifiable Secret Sharing (PVSS) [15] scheme. The clients, which represent the dealers in the scheme, generate a secret that they use to encrypt the tuples. Later, they generate a set of n shares of this secret and one different share is sent to each server. The secret can be recovered only with a combination of f+1 shares, what makes it impossible for a collusion of up to f malicious servers to expose the tuple contents.

As servers cannot access the tuple contents (since they are encrypted by the client), the protocol employs a fingerprint for the tuple, making it possible to implement and compute the matches between tuples and templates at the servers. The fingerprint is computed according to the type of each tuple fields, which can be classified as follows:

• Public (PU): the field content itself is used as its fingerprint, i.e, no cryptographic method is applied to the field content and it remains exposed.

• Comparable (CO): a hash of the field content is used as its fingerprint (using a collision resistant hash function), allowing servers to execute searches/matches in these type of fields while, at the same time, providing some level of security.

• Private (PR): a special symbol (PR) is used as fingerprint of these fields. Although it provides a level of security higher than the CO classification, no information in this field is available at the servers to verify if a tuple matches a template.

Once it is not possible to send different versions of a request for different servers in the state machine replication approach (containing only its share of the secret used to encrypt the tuple), the client encrypts each share with a secret key shared with the server that will store it. Consequently, each server will access only its share and, as a malicious server does not have access to all shares, it can not restore and expose the tuples contents.

In a nutshell, a insertion operation (out) works as follows:

• The client generates a secret s and encrypts the tuple using this secret.

• The client uses the PVSS scheme to generate n shares of s.

• The client encrypts each share with a secret key shared with each server (one share per server).

• The client computes the fingerprint according to the fields classification.

• The client uses the state machine replication protocol to send a request to the servers (in this protocol it must wait for f+1 replies to finish the request execution). The request contains the encrypted tuple, the encrypted shares, the proof that these shares are valid and the tuple fingerprint.

• When a server executes this request, it only stores all received data and sends an acknowledge to the client as a reply.

On the other hand, the protocol to read/remove a tuple works as follows:

• The client computes the fingerprint for the template according to the field classification. The fingerprint of a undefined field is the wildcard itself.

• The client uses the state machine replication protocol to send a read/remove operation to the servers containing the generated fingerprint.

• When a server executes this request, it chooses a tuple deterministically such that its fingerprint matches the received fingerprint (if it is a removal operation, this tuple is removed from the space). In case its share was not yet verified, it extracts its share and verify if this share is valid using the proofs received during the out operation. Afterward, the server replies to the client with the encrypted tuple, its encrypted share (to avoid eavesdropping on the replies), the tuple fingerprint and proofs that the share is valid.

• The client waits for f+1 replies, decrypts the shares, verifies their validity and combines them to recover the secret s. Finally, the client decrypts the tuple using s.

• The client verifies if the fingerprint it used is valid for the recovered tuple. If the fingerprint is valid, the operation is finished. Otherwise, a repair procedure is executed to remove invalid data from the space and the operation is repeated.

Notice that, according to the fingerprint definitions, searches are possible only in public and comparable fields, i.e., private fields cannot be used to verify if a tuple matches a template and are always used as undefined fields on the template. This limitation brings at least two consequences. On the one hand, a tuple with many private fields makes the search very restricted, losing the flexibility in the development of applications because a template with many undefined fields does not allow a fine-grained match at the servers. On the other hand, a tuple with many public and/or comparable fields is susceptible to many attacks, like correlation and preimage attacks.

Policy enforcement. This layer allows a fine-grained access policy execution [7] that takes into account three parameters (identifier of the invoker, operation and arguments, and the current tuples stored in the space) to decide if an operation is approved or denied. These policies are defined by the users and are loaded at the servers during the system setup.

Access control.

Access control is a fundamental mechanism to keep the integrity and confidentiality of information (tuples) stored in the DEPSPACE since it prevents unauthorized clients from getting access to the tuples. Moreover, this mechanism prevents malicious clients from saturating the tuple space by sending a lot of tuples. Currently, the DEPSPACE implements the access control based on credentials: for each tuple inserted in the DEPSPACE, a set of credentials are necessary to access it, both to read and to remove it from the space (access control at tuple level). These credentials are defined by the process that inserts the tuple. Moreover, it is possible to define which credentials are necessary to insert a tuple into the space (access control at space level) during its setup. The implementation of this functionality is realized through the association of access control lists to each tuple and space.

3.1 Deterministic and probabilistic ciphers

A cipher \(\mathcal {E}=(E,D)\) defined over \((\mathcal {K}, \mathcal {M}, \mathcal {C})\) is called probabilistic if, for a fixed key \(k\in \mathcal {K}\) and messages \(m\in \mathcal {M}\) that are used as inputs of the encrypt function \(E: \mathcal {K}\times \mathcal {M}\to \mathcal {C}\), the output c=E(k,m) may assume different values. Otherwise, the cipher is said to be deterministic [18].

Naturally, an inherent characteristic of deterministic ciphers is the leakage of equality of texts encrypted under the same key, that is, m ₀=m ₁ ⇔ E(k,m ₀)=E(k,m ₁). This fact could be used to perform equality searches over encrypted data [21, 22]. Clearly, this kind of cipher does not achieve security against the Chosen-Plaintext Attack (CPA) since an adversary may submit in the beginning two copies of the same message m ₀ to the oracle and receive two identical ciphertexts c ₀=E(k,m ₀). Afterwards, the attacker could send the messages m ₀ and m ₁ to the oracle, receiving c _b =E(k,m _b ), where b∈{0,1}. Now, it is enough to compare c _b (b∈{0,1}) with c ₀ to know if it is E(k,m ₀) or E(k,m ₁).

Probabilistic ciphers can resist stronger attacks, achieving the IND-CCA2 security level when combined with authentication primitives.

3.2 Order-preserving encryption - OPE

A symmetric order-preserving cryptography scheme preserves the order relation among the encrypted values [20]: for all i and j and for all keys k, E(k,i)<E(k,j) ⇔ i<j. This kind of cipher leaks the order among plaintexts through the ciphertexts, therefore not achieving the IND-CPA security level. Observing that this security level is not achievable by a deterministic algorithm with such property, even considering a weak security level (IND-OCPA), applying pseudo-random generators and functions (PRF’s and PRG’s) was proposed [20]. This approach provides a flexible (but strong) level of security called pseudorandom order-preserving function under chosen-ciphertext attack (POPF-CCA).

However, this security definition does not determine what kind of data could leak, besides the order. In [23], Order Revealing Encryption (ORE) is proposed, a construction that minimizes the amount of leaked data. Although this approach presents a higher level of security, it is impractical since the initial proposal presents poor performance. Trying to circumvent this limitation, a practical ORE algorithm [24] was proposed. This algorithm achieves the IND-OCPA security level since it could leak only the first bit that differs in the compared values. Finally, an ORE algorithm that resists inference attacks [25] was proposed and presents a good performance for encrypted database applications [22].

3.3 Homomorphic encryption

Homomorphic encryption [26] allows computations over encrypted data without decrypting them and without the knowledge of the secret keys. Given any two messages, m ₁ and m ₂, a homomorphic encryption function E and a key k, we have that E(k,m ₁)∘ _c E(k,m ₂)=E(k,m ₁∘ _m m ₂), where ∘ _m denotes an arithmetic operation on the message domain and ∘ _c denotes an arithmetic operation on the ciphertext domain.

Fully homomorphic systems generally present poor performance and are not practical in the development of applications. However, it is possible to avoid the performance issues of fully homomorphic schemes while preserving some of their functionality, since many applications need only some kind of operations, what can be done by a “somewhat” homomorphic scheme [27]. These schemes present a better performance and are practical. Paillier [28] and exponential ElGamal [29] are examples of efficient “somewhat” homomorphic ciphers. These schemes are also probabilistic, achieving the IND-CPA security level.

4.1 Improving fingerprint security

The fingerprint function ensures that if a tuple t matches a template \(\overline {t}\), the fingerprint t _h of t matches the fingerprint \(\overline {t}_{h}\) of \(\overline {t}\) if both are generated using the same protection type (field classification) for each field [5]. The fingerprint t _h =〈h ₁,...,h _m 〉 of a tuple t=〈f ₁,...,f _m 〉 is generated according to the formula presented at Fig. 3.

The new field classification brings a key management issue since it is necessary to share a secret key for CD and OR fields or a key pair (public and private) for OP fields. These keys must be shared among the processes that are communicating through the tuple space. For OP fields, the public key also is available to the servers allowing they to execute computations over these fields. Fortunately, key management is not a problem in our model since the tuple space itself could be used for this coordination (Section 7.3).

CD fields. We strongly recommend the preference of CD fields over CO. By using a deterministic symmetric cipher instead of a hash value, an attacker would need to access the secret key to encrypt a field, making it impossible to mount a preimage attack (Section 2.1.2). However, the CD classification must be employed carefully since this cipher reveals if plaintexts are equal. Consequently, if the field content belongs to a small domain, using few external information is enough to disclose it. For instance, consider the encryption of a field that contains the sex in a database that is known to have more men than women. An attacker could observe that there are only two possible ciphertexts and conclude that the one with more occurrences refers to the male sex. Therefore, this cipher should be used for fields that store indexes, with a high amount of possible values, and for non-sensitive data like identifiers, e-mail address, name of process nodes, among others.

Some cryptographic algorithms use operation modes with randomized initialization vectors (IV), in the form c=E(k,m,IV), as a way to provide probabilistic encryption. To provide deterministic encryption, these algorithms usually fix the IV (e.g. in zero). In these cases, we recommend the use of a PRF (pseudo random function) over the message m by using a key k ₁, producing a pseudo-random output r=F(k ₁,m). The encryption function then uses r as IV and another key k ₂ to produce the encrypted output c=E(k ₂,m;r). Since the PRF generates the same output for the same message and key, the algorithm remains deterministic. Moreover, the PRF generates different outputs for different messages inputs (even under the same key) and, therefore, different IV’s are obtained for different messages, achieving the IND-DCPA security level [18].

OP fields. OP fields allow the computation over encrypted data. For these fields, a homomorphic or a “somewhat” homomorphic cipher (Section 3.3) should be used, such as Paillier [28], according to the application requirements. These fields increase the functionality provided in DEPSPACE. For instance, it is possible to update values used to synchronize decoupled process without revealing process status.

If the field needs only one kind of arithmetic operations (e.g.: addition/subtraction or multiplication/division), a “somewhat” homomorphic cipher can be used to offer better performance than a fully homomorphic alternative.

Notice that all fingerprint fields are used only to select tuples, except for OP fields. In these cases, the updated value to be read is in the fingerprint, not in the decrypted tuple, and the client must consider this value during a reading/removal operation.

OR fields. This classification brings a lot of functionalities for the tuple spaces allowing servers to execute some operations, as (1) tuples ordering based on a field, (2) execution of queries for a field belonging to some range and (3) select a tuple with a field storing the maximum/minimum value. To execute these operations in the original DEPSPACE system, fields should be classified as PU, losing security. If they are classified as PR, clients need to read and decrypt all tuples prior to perform these operations. Allowing servers to execute such processing improves the system performance since fewer data are transferred through the network [8].

The OR fields must be chosen carefully since these fields are vulnerable to inference attacks if all possible values of a domain are present in the data collection [3]. For instance, if a tuple field refers to the age of patients in a hospital that is known to have patients of all ages from zero to 100 years old, then data could be revealed due to this association.

To overcome this vulnerability, we suggest the use of a composition of algorithms. First, encrypt the data with an OPE algorithm [20] and later use the output as input of an ORE algorithm [24]. By this approach the system achieves the IND-OCPA security level, with the leakage of the first bit that differs in the compared values. The distance between OPE encrypted numbers is a random value and it does not have any connection with the distance of the original numbers. This is the reason for the first step since in this case the leaked bit is from the OPE encrypted number instead of the original number.

Finally, the security of a system depends on the correct use of each cipher, considering the characteristics of the data stored in each field. Keeping all data encrypted, it is possible to avoid inference attacks that could cause a big damage to applications using lower computational effort.

6.1 Experimental setup

The Emulab environment was configured with 5 d710 machines (2.4 GHz 64-bit Intel Quad Core Xeon E5530 with 2 CPU threads per core, 12 GB of RAM and 1 Gbps network cards) and a 1Gbps switched network. The software installed on the machines was Ubuntu 14 64-bit and a 64-bit Java virtual machine version 1.8.0_121. For all experiments, the system was configured with four replicas hosted in separate machines to tolerate up to one replica failure, while the clients were executed in the remaining machine.

We employed this library without the composition with a ORE algorithm (see Section 3.2). This library outputs a deterministic BigInteger that preserves exactly the same order than the non encrypted number, with pseudo-random distances between any two encrypted numbers. To perform inequality queries (e.g.: less than or greater than), we implemented at the proxy layer of the client side a detector to identify the presence of these queries and handle them in a way that the tuple space layer at the servers side can understand, i.e, the tuple space layer was modified to perform matches using these queries. For instance, a tuple field containing the number 10 matches a template field containing a query “less than 11”. The current supported queries are: lt (less than), le (less than or equal to), eq (equal to), gt (greater than), and ge (greater than or equal to).

For executing out operations, we used tuples with only defined fields for each configuration described above (e.g.: 〈1,2,3〉, 〈1,2,3,4,5〉 and 〈1,2,3,4,5,6〉). Notice these fields were protected according to their configuration (PU, CO, PR, CD, OP or OR). On the other hand, the templates used for rdp and inp operations were configured with one defined field while the remaining ones were configured as wildcards (e.g.: 〈1,∗,∗〉, 〈1,∗,∗,∗,∗〉 and 〈1,∗,∗,∗,∗,∗,∗〉), except for the configurations PR and OP in which all fields were configured as wildcards since it is not possible to execute matches in these fields (Section 7).

We evaluated the raw throughput of the system at the servers and the latency perceived at the clients in all configurations. To evaluate latency, we used one client to execute each operation 1000 times and obtained the 90th percentile and the average time discarding the 10% values with greater variance. On the other hand, to execute throughput experiments, we variated the number of clients (from one to ten) and measured the maximum throughput obtained in each configuration. In order to stress the servers, each client preprocessed 1000 requests (most of the cryptographic costs are at the client side) before sending them to the servers, that measured the throughput periodically at each 100 executed requests. Although the DepSpace does tolerates faults, all performance values were obtained in fault-free executions.

6.2 Results

This section reports the results obtained in the experiments. First, Fig. 5 a and b present the 90th percentile and the average latency for the out operation, respectively. The cryptographic costs for these operations are related to: (1) the execution of the PVSS scheme [5], that is the same cost for all configurations; and (2) the generation of the fingerprint, that is different for each approach (see Table 2).

	Fingerprint	Verify	Extract	Query/Match
	(\(\overline {av}\) / σ)	(\(\overline {av}\) / σ)	(\(\overline {av}\) / σ)	(\(\overline {av}\) / σ)
PU	–	–	–	–
CO	(0.003 / 0.0003)	(0.003 / 0.0003)	–	–
PR	–	–	–	–
CD	(0.033 / 0.0067)	(0.033 / 0.0067)	–	–
OP	(0.619 / 0.0322)	–	(0.601 / 0.1064)	–
OR	(375.091 / 2.3129)	(375.348 / 1.9041)	–	(0.001 / 0.0002)

All values presented in the table consider the costs to process only one field and it is presented the average (\(\overline {av}\)) and the standard deviation (σ) in milliseconds (ms)

A configuration with fields PU or PR presented the best performance since no cryptographic operations is need to generate the fingerprint, followed by configurations CO and CD. Although more time is necessary to process the fingerprint for CD when compared to CO (Table 2), this fact does not impact its performance since it demands less than a millisecond to execute (0.033 ms). The configuration OP also presented an acceptable performance, although more time is necessary to process the fingerprint. On the other hand, the configuration OR presented poor performance since a lot of time was necessary to process the fingerprint.

Figure 6 a and b present the latency results for the rdp operation. These results are very similar to the results for the inp operation (Fig. 7 a and b), since the only difference is that the inp operation removes the tuple from the space. The cryptographic costs for these operations are related to: (1) the client must generate the fingerprint \(\overline {f}\) for the template; (2) servers search for a tuple with a fingerprint that matches \(\overline {f}\); (3) servers execute the PVSS scheme to extract their shares; and (4) the client must execute the PVSS scheme to combine the received shares and recover the tuple and verify if \(\overline {f}\) is valid for the received tuple. Moreover, it is necessary to extract the values of operable fields from the fingerprint. Table 2 presents these costs, except for the PVSS scheme that are the same for all configurations. The size of a request/reply also is presented at Table 3 and, as already commented, impacts the communication costs. The performance presented by the system in the execution of reading (rdp) and removal (inp) operations followed the same pattern of the insert (out) operations, basically for the same reasons.

Another very important aspect is that most of the cryptographic costs are executed at the client side, i.e., the costs reported at columns fingerprint, verify and extract of Table 2. Only the query/match (last column of Table 2) for OR fields are executed by the servers during the search for a tuple which has a fingerprint that matches the fingerprint of the template in a read or removal operation. Moreover, most of the costs related to the execution of the PVSS scheme also are placed at the client side [5]. This is important because it shows that it is possible to have a tuple space that ensures the privacy of the information it stores and, at the same time, is scalable. Consequently, although these costs impact the latency, it is not expected to have a significant impact on the system throughput.

Trying to investigate this aspect, Fig. 8 presents the throughput presented at the servers for each operation and configuration. The throughput is similar for all configurations since no significant cryptographic operation is executed at the servers (only a negligible time is demanded to execute a query/march for the OR configuration). Moreover, the throughput to insert (Fig. 8 a) a tuple in the space is higher than the throughput to read (Fig. 8 b) or to remove (Fig. 8 c) it from the space. In fact, in the execution of a reading or removal operation, servers must extract and verify the shares while no cryptographic function is executed at the servers for insertion operations (Section 2.1).

Another important aspect to be observed in the experiments is that the number of fields in a tuple does not significantly impacted the system performance for both latency and throughput. In fact, for all configurations and operations, the performance for 3, 5, and 7 fields are similar, except for the OR fields since they demanded much more time to generate the fingerprint (Table 2).