Integrity and Authenticity Protection with Selective Disclosure Control in the Cloud & IoT

Abstract

$\mathsf {RSS}$ allow the redaction of parts from signed data. Updatable $\mathsf {RSS}$ additionally enable the signatory to add new elements, while signatures can be merged by third parties under certain conditions.

We propose a framework for two new real-life application scenarios and implement it using an $\mathsf {RSS}$ with sufficient functionality on three different platforms, ranging from a potent cloud to a very resource-constrained Android device. Our evaluation shows impractical run time especially on the IoT device for the existing construction that was proven to be secure in the standard model. Thus, we provide an adjusted scheme with far better performance, which we prove to be secure in the random oracle model. Furthermore, we show how to increase performance using parallelization and several optimizations.

C. Frädrich, H.C. Pöhls, and W. Popp were supported by EU H2020 project PRISMACLOUD, grant agreement No. 644962. H.C. Pöhls was supported by EU FP7 project RERUM under grant agreement No. 609094. H.C. Pöhls, W. Popp, and N. Rakotondravony were supported by the Bavarian State Ministry of Education, Science and the Arts as part of the FORSEC research association. K. Samelin was supported by the EU ERC under grant PERCY No. 321310.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Cryptographic protection of integrity using signatures gives us strong origin authentication for the data. To gain full end-to-end protection, and to verify the origin of the data, the signature has to be generated on the data gathering device. A drawback of standard digital signatures is that the signed data set cannot be split into parts to selectively disclose only required parts to protect the confidentiality of the unneeded data parts. Redactable signature schemes ($\mathsf {RSS}$), a concept initially introduced by Steinfeld and Bull [24], and independently by Johnson et al. [12], offer a solution to the problem and “...model a situation where a censor can delete certain parts of a signed document without destroying the ability of the recipient to verify the integrity of the resulting (redacted) document.” [12]. Clearly, this primitive has its merits whenever authentic data must be handled in a privacy friendly manner. However, despite their “obvious” usefulness, $\mathsf {RSS}$ did not gain the attention they deserve, most likely due to the lack of complete and convincing real-life application scenarios and a missing proof that they are truly practical.

Motivation. Our overall goal is to bring $\mathsf {RSS}$ to practice in a real-life application scenario. Namely, we applied $\mathsf {RSS}$ in two real-life use-cases and measured their performance. The two use cases that are described in more detail in Sect. 2 are: healthcare data and log entries. For medical data, or information that contains trade secrets, it is of paramount importance that the redacted parts do not leak from the redacted yet signed document. This property is called privacy, and means that a verifier must not be able to gain any knowledge about redacted elements without having access to them. In particular, we show how $\mathsf {RSS}$ can be used to ease managing data in a privacy friendly manner without any a-priori knowledge of the data’s later usage or intended recipients. As $\mathsf {RSS}$, in particular, keep the authenticity of the remaining data and are capable of identifying the signatory. This gives increased data quality assurance due to the possibility to verify the origin and the integrity of the data transmitted, and can even make the redacted data become acceptable as an evidence in court.

Contribution. We propose two privacy and authenticity preserving data workflows, sketched in Figs. 1 and 2. We found that the workflows can be instantiated with a suitable $\mathsf {RSS}$, solving the problems related to data privacy and authenticity from the use cases. We back our finding by the evaluation of the actual performance in three very different environments: a constrained IoT device, a standard Android smart phone, and a powerful computing device as found in clouds. Interestingly, our evaluation shows that our approach is suitable for workflows involving cloud as well as the Android mobile phone under consideration, if implemented with care and certain optimizations, including some changes to the used $\mathsf {RSS}$. Namely, the original $\mathsf {RSS}$ construction from [19] — cryptographically secure in the standard model — requires extensive primality tests. We reduce the cryptographic strength to the practically still useful random oracle model (ROM) to obtain usable and for many workflows satisfying performance. We provide a security proof of the altered construction.

Fig. 1.

Example workflow for e-health use-case: integrity and origin of remaining data remains verifiable and protected against active attacks; redaction needs no keys

State-of-the-Art. The concept of $\mathsf {RSS}$ has been introduced as “content extraction signatures” by Steinfeld et al. [24], and, in the same year, as “homomorphic signatures” [12] by Johnson et al. A security model for sets has been given by Miyazaki et al. [16]. Their ideas have been extended to work on trees [5, 21], on lists [6, 22], but also on arbitrary graphs [13]. A generalized security model was then derived by Derler et al. [9]. There are also schemes that offer context-hiding, a very strong privacy notion, and variations thereof [1, 2]. Context-hiding schemes allow to generate signatures on derived sets with no possibility to detect whether these correspond to an already signed set in a statistical sense. However, all proposed schemes achieving this notion do not allow updating signatures, i.e., add new data, which is inherently required in our case. $\mathsf {RSS}$ have also been analyzed to allow this within the EU legal framework [18, 25]. However, there is no work deploying more advanced $\mathsf {RSS}$, which also allow updating signed data in a real-life context, even though there are some implementations, which evaluate less expressive constructions [20, 23, 27]. Of course, there is much additional related work which we cannot discuss due to space requirements. Ghosh et al. [11] provide a comprehensive overview.

Fig. 2.

Example workflow for the log-file use-case: origin and integrity of log-entries with limited information remains verifiable; redaction needs no keys

2 Application Scenarios

In the first use-case (Fig. 1), healthcare data is gathered by a constrained, Internet-of-Things (IoT) like, yet certified and trusted, medical health monitoring device (HMD). The goal is to allow to share the resulting data with authenticity guarantees, e.g. that data was not maliciously modified and originated from a certain HMD. However, at the time of data generation and application of the integrity and authenticity protection, we do not know with whom we want to share which parts of the data being gathered. The workflow is as follows: The HMD senses the rate of the heartbeat and records it with a time stamp and a geo-location. When consulting the record, the medical personnel must be re-assured that it was indeed taken by some HMD (e.g. certified medical equipment with a known good calibration) and not tampered (e.g. the patient faking to have done exercises). For protection, each triplet (timestamp, heartbeat, geo.-loc.) is digitally signed on the HMD, using a secret signature generation key ($\mathsf {sk}$) only known to that HMD. This is done for each new measurement; therefore the HMD not only signs but also update data. Communication step 1 shows that signed data is sent to the patient’s mobile phone. The patient’s personal Android smart phone then plays the role of the privacy-enhancing gateway and selects which data is forwarded to the healthcare provider. For example, the timestamps are made more coarse and the geo-location can be removed in certain user chosen areas. The patient entrusts his device and software to do these redactions. But the redaction itself requires no additional keys, the signature can be adjusted to fit the reduced data, e.g. geo.-location information is removed in the workflow depicted in Fig. 1. The redacted and still verifiably signed data is sent in step 2 to the healthcare provider. The provider can verify the received reduced data’s adjusted signature on a cloud-based back-end. In step 3, it sends the data to a healthcare personnel’s tablet computers. Additionally, the workflow allows to further reduce the data set. Thus, by redacting sensitive and unneeded information from the data first, any service in the cloud can further tailor the still authentic information into smaller packages. This is depicted by the communication steps 4 and 5 in Fig. 1. Overall, there are three important advantages from facilitating an $\mathsf {RSS}$ in this way:

• The workflow requires no interaction with the HMD to tailor the data after the production into different packages for different healthcare usages or different personal; still it allows any privacy-aware party to implement the need-to-know principle in an ad-hoc fashion.

• The workflow allows to verify that other than potential removal of more data, the data that is available has not been tampered with and originated from an identifiable HMD.

• The party or parties doing privacy preserving redactions are not required to be entrusted not to introduce other errors or even tamper the data.

Thus, the workflow achieves to keep a high data quality: The authenticity of the information shown to the healthcare personnel is protected even against a manipulation on the patient’s smartphone, e.g., falsifying the heartbeat or geographic location to simulate jogging; and the origin is authenticated to be the certified HMD. This use-case has a small number of elements to be signed (${<} 20$) for each reading, but only very limited computing resources.

In the second use-case (Fig. 2), log-files of a service in the cloud are signed and thus are protected against unauthorized modifications when transferred to off-site storage services or other analyzing third party services. Here, our main requirement is again that certain unnecessary, or sensitive details from the log-file, e.g., an accessed URL¹, can be redacted. In a first step, the log-file’s entry is generated by the service and the information of the IP, the accessed URL, and the time is added to a signed log file that is stored in the private cloud (communication step 1 in Fig. 2). Again, note that being able to directly handle adding new signed elements to an already signed set is very helpful in this scenario. In the example, the URL is treated as confidential and is removed in step 2 before the reduced information is then shared with several services that analyze log-files. In our example, a service for detection of distributed denial of service (dDoS) is provided with authentic tuples of IP and timestamp of the access to a certain service. By verifying the signature, the service provider that offers to detect distributed denial of services could know that it was not tampered and from which service it originated, i.e. mapping the $\mathsf {pk}$ to a known customer of the dDoS-detection service. An additional service could be to redact (step 4) and give the remaining information to other services. All the time, the authenticity of the remaining information can be retained in order to be still usable as forensic evidence or for data quality purposes. The second use-case is challenging due to a potentially large number of redactable elements in the log-files (>1, 000), which we tackle by using cloud computing resources.

3 Cryptographic Preliminaries

For completeness of the paper, we re-state the cryptographic security properties needed for an $\mathsf {RSS}$ to be suitable in our scenario. We chose the construction by Pöhls and Samelin [19], as it is the only $\mathsf {RSS}$ achieving the required properties.

Notation. $\lambda \in \mathbb {N}$ denotes the security parameter. All algorithms take $1^\lambda$ as an (often implicit) additional input. We write $a \leftarrow A(x)$ if a is assigned the output of algorithm A with input x. An algorithm is efficient if it runs in probabilistic polynomial time (ppt) in the length of its input. It may return a special error symbol $\bot \ \notin \{0,1\}^*$, denoting an exception. For the remainder of this paper, all algorithms are ppt if not explicitly mentioned otherwise. If we have a list, we require that we have an injective, and efficiently reversible, encoding which maps the list to $\{0,1\}^*$. For a set S, we assume, for notational reasons, a lexicographical ordering on the elements. A message space $\mathcal {M}$, and the randomness space $\mathcal {R}$, may implicitly depend on a corresponding public key. If not otherwise stated, we assume that $\mathcal {M} = \{0,1\}^*$ to reduce unhelpful boilerplate notation. A function $\nu :\mathbb {N}\rightarrow [0,1]$ is negligible, if it vanishes faster than every inverse polynomial, i.e., $\forall k\in \mathbb {N}$, $\exists n_0\in \mathbb {N}$ such that $\nu (n)\le n^{-k}$, $\forall n>n_0$. || is a bit-concatenation.

The Strong-RSA Assumption. Let $(n,e',d,p,q) \leftarrow \mathsf {RSAKeyGen}(1^\lambda )$ be an RSA-key generator returning an RSA modulus $n = pq$, where p and q are random distinct (safe-) primes², $e' > 1$ an integer co-prime to $\varphi (n)$, and $d \equiv e'^{-1} \bmod \varphi (N)$. The flexible RSA problem associated to $\mathsf {RSAKeyGen}$ is, given n, and $y \leftarrow \mathbb {Z}_n^*$, to find x and e such that $x^{e} \equiv y \bmod N$, where e is also prime [3]. More formally, the Strong-RSA Assumption now states that for every PPT adversary $\mathcal {A}$, there exists a negligible function $\epsilon$ such that $\Pr [(n,e',d,p,q) \leftarrow \mathsf {RSAKeyGen}(1^\lambda ), y \leftarrow \mathbb {Z}_n^*, (x,e) \leftarrow \mathcal {A}(n, y) : x^{e} \equiv y \bmod n] \le \epsilon (\lambda )$ holds.

3.1 Cryptographic Accumulators $\mathsf {ACC}{}$

A cryptographic accumulator $\mathsf {ACC}{}$ is a succinct, but not necessarily hiding [8, 15], commitment to a potentially very large set $\mathcal {S}$ [3]. For each element $v \in \mathcal {S}$ a witness (or proof) $p_v$ can be generated which vouches v was really accumulated. A trapdoor accumulator allows to add new elements not priorly in the set $\mathcal {S}$.

Definition 1

(Trapdoor Accumulators) . A cryptographic trapdoor accumulator $\mathsf {ACC}{}$ consists of four ppt algorithms: $\mathsf {ACC}{}:= (\textsf {Gen},\textsf {Dig},\textsf {Proof},\textsf {Verf}\,)$:

• $\textsf {Gen}$. This algorithm generates the key pair: $(\mathsf {sk}_\mathsf {ACC}{}, \mathsf {pk}_\mathsf {ACC}{}) \leftarrow \textsf {Gen}(1^\lambda )$

• $\textsf {Dig}$. On input of the set $\mathcal {S}$ to accumulate and the public parameters $\mathsf {pk}_\mathsf {ACC}{}$, it outputs an accumulator value $a \leftarrow \textsf {Dig}(\mathsf {pk}_\mathsf {ACC}{}, \mathcal {S})$

• $\textsf {Proof}$. This deterministic algorithm, on input of the secret key $\mathsf {sk}_\mathsf {ACC}{}$, the accumulator a, and a value v, outputs a witness p for v: $p \leftarrow \textsf {Proof}(\mathsf {sk}_\mathsf {ACC}{}, a, v)$

• $\textsf {Verf}$. On input of the public key $\mathsf {pk}_\mathsf {ACC}{}$, an accumulator a, a witness p, and a value v, it outputs a bit $d \in \{0,1\}$, indicating whether p is a valid witness for v w.r.t. a and $\mathsf {pk}_\mathsf {ACC}{}$: $d \leftarrow \textsf {Verf}(\mathsf {pk}_\mathsf {ACC}{}, a, v, p)$

Even though there is a proof algorithm, providing $\mathcal {S}$ at accumulator generation may speed up the algorithms for elements in $\mathcal {S}$, if one knows $\mathsf {sk}_\mathsf {ACC}{}$.

Security Model. Essentially, we require that an adversary cannot find a witness for an element for which it does not already know a proof. This has to hold even adaptively. For the formal definition of the required properties, such as correctness and collision-resistance, please see the full version or [19].

3.2 Mergeable and Updatable $\mathsf {RSS}$ ($\mathsf {MRSS}$)

We now introduce mergeable and updatable $\mathsf {MRSS}$, derived from Pöhls and Samelin [19].

Definition 2

(Mergeable and Updatable ${\mathsf {RSS}}$ (${\mathsf {MRSS}}$)). A mergeable and updatable $\mathsf {MRSS}$ consists of six efficient algorithms. Let $\mathsf {MRSS}:= (\textsf {KeyGen},\textsf {Sign},\textsf {Verify}, \textsf {Redact},\textsf {Update},\textsf {Merge})$, such that:

• $\textsf {KeyGen}$. The algorithm $\textsf {KeyGen}$ outputs the public and private key of the signer, i.e., $(\mathsf {pk}, \mathsf {sk}) \leftarrow \textsf {KeyGen}(1^\lambda )$.

• $\textsf {Sign}$. The algorithm $\textsf {Sign}$ gets as input the secret key $\mathsf {sk}$ and the set $\mathcal {S}$. It outputs $(\sigma , \tau ) \leftarrow \textsf {Sign}(\mathsf {sk}, \mathcal {S})$. Here, $\tau$ is a tag.

• $\textsf {Verify}$. The algorithm $\textsf {Verify}$ outputs a bit $d \in \{0,1\}$ indicating the correctness of the signature $\sigma$, w.r.t. $\mathsf {pk}$ and $\tau$, protecting $\mathcal {S}$. 1 stands for a valid signature, while 0 indicates the opposite. In particular: $d \leftarrow \textsf {Verify}(\mathsf {pk}, \mathcal {S}, \sigma , \tau )$.

• $\textsf {Redact}$. The algorithm $\textsf {Redact}$ takes as input a set $\mathcal {S}$, the public key $\mathsf {pk}$ of the signer, a tag $\tau$, and a valid signature $\sigma$ and a set $\mathcal {R}\subset \mathcal {S}$ of elements to be redacted, outputting $\sigma ' \leftarrow \textsf {Redact}(\mathsf {pk}, \mathcal {S}, \sigma , \mathcal {R}, \tau )$. $\mathcal {R}$ is allowed to be $\emptyset$.

• $\textsf {Update}$. The algorithm $\textsf {Update}$ takes as input a set/signature/tag tuple $(\mathcal {S},\sigma , \tau )$, $\mathsf {sk}$ and a second set $\mathcal {U}$. It outputs $\sigma ' \leftarrow \textsf {Update}(\mathsf {sk},\mathcal {S},\sigma ,\mathcal {U}, \tau )$.

• $\textsf {Merge}$. The algorithm $\textsf {Merge}$ takes as input the public key $\mathsf {pk}$ of the signer, two sets $\mathcal {S}$ and $\mathcal {V}$, a tag $\tau$, and the corresponding signatures $\sigma _\mathcal {S}$ and $\sigma _\mathcal {V}$. It outputs the merged signature $\sigma _\mathcal {U}\leftarrow \textsf {Merge}(\mathsf {pk}, \mathcal {S}, \sigma _\mathcal {S}, \mathcal {V}, \sigma _\mathcal {V}, \tau )$.

Security Model. We now give a short overview of the security model. In a nutshell, an entity not having access to any secret keys must not be able to generate any signature which verifies for elements not endorsed by the signer, excluding merges under the same tag $\tau$, and redactions (unforgeability). From the privacy perspective, which is arguably as important as the unforgeability requirement, we need some additional guarantees. In particular, we require that: (1) An outsider must neither be able to decide whether a given set was freshly signed or created by redacting or which elements have been added afterwards (update privacy/transparency). (2) An adversary must neither be able to decide whether a given signature was generated through a merge or freshly signed or which elements have been merged (merge privacy/transparency). (3) An adversary must neither be able to learn anything about redacted elements nor whether a signature is fresh or was created by a redaction (privacy/transparency).

Due to space requirements, the formal definitions of these security properties can be found in the full version of this paper or in [19].

Definition 3

(Secure MRSS ). We call an $\mathsf {MRSS}$ secure, if it is corect, unforgeable, transparent, private, merge transparent, merge private, update private, and update transparent [19].

4 Constructions

The original paper’s instantiation of $\mathsf {ACC}{}$ (as the major building block of the $\mathsf {MRSS}$) was proven secure in the standard model [19]. We re-phrase the accumulator in the random-oracle model [4], as it offers better performance, after given the general instantiation of the $\mathsf {MRSS}$.

The Construction by Pöhls and Samelin [19]. The basic ideas of the $\mathsf {MRSS}$ construction given in [19] is to start with an empty accumulator a generated for each key pair. For a signature, the public information of the accumulator $\mathsf {pk}_\mathsf {ACC}{}$ is accompanied with the proofs for all the signed elements $v_i \in \mathcal {S}$ and the updated accumulator value a. Apart from the elements, a tag $\tau$ is also accumulated making each signature linkable, and to allow updates and merging. For new signatures, a new tag is chosen.

Construction 1

(Updatable and Mergeable $\mathsf {MRSS}$ ). Let $\mathsf {MRSS}:= (\textsf {Key}\textsf {Gen},\textsf {Sign},\textsf {Verify}, \textsf {Redact},\textsf {Update},\textsf {Merge})$ such that:

• $\textsf {KeyGen}$. The algorithm $\textsf {KeyGen}$ generates the key pair in the following way:

  • 1. Generate key pair required for $\mathsf {ACC}{}$, i.e., run

  • 2. Call

  • 3. Output

• $\textsf {Sign}$. To sign a set $\mathcal {S}$, perform the following steps:

  • 1. Draw a tag $\tau \in _R \{0,1\}^\lambda$

  • 2. Let $p_\tau \leftarrow \textsf {Proof}(\mathsf {sk}_\mathsf {ACC}{}, a, \tau )$

  • 3. Output $(\sigma , \tau )$, where $\sigma = (p_\tau , \{(v_i, p_i) \mid v_i \in \mathcal {S}~\wedge ~p_i \leftarrow \textsf {Proof}(\mathsf {sk}_\mathsf {ACC}{}, a, (v_i,\tau ))\})$

• $\textsf {Verify}$. To verify signature $\sigma = (p_\tau , \{(v_1, p_1),\dots ,(v_k, p_k)\})$ with tag $\tau$, perform:

  • 1. For all $v_i \in \mathcal {S}$ check that $\textsf {Verf}(\mathsf {pk}_\mathsf {ACC}{}, a, (v_i,\tau ), p_i) = 1$

  • 2. Check that $\textsf {Verf}(\mathsf {pk}_\mathsf {ACC}{}, a, \tau , p_\tau ) = 1$

  • 3. If Verf succeeded for all elements, output 1, otherwise 0

• $\textsf {Redact}$. To redact a subset $\mathcal {R}$ from a valid signed set $(\mathcal {S},\sigma )$ with tag $\tau$, with $\mathcal {R}\subseteq \mathcal {S}$, the algorithm performs the following steps:

  • 1. Check the validity of $\sigma$ using $\textsf {Verify}$. If $\sigma$ is not valid, return $\perp$

  • 2. Output $\sigma '$, where $\sigma ' = (p_\tau , \{(v_i, p_i) \mid v_i \in \mathcal {S}\setminus \mathcal {R}\})$

• $\textsf {Update}$. To update a valid signed set $(\mathcal {S},\sigma )$ with tag $\tau$ by adding $\mathcal {U}$ and knowing $\mathsf {sk}_\mathsf {ACC}{}$, the algorithm performs the following steps:

  • 1. Verify $\sigma$ w.r.t. $\tau$ using $\textsf {Verify}$. If $\sigma$ is not valid, return $\perp$

  • 2. Output $\sigma '$, where $\sigma ' = (p_\tau , \{(v_i, p_i) \mid v_i \in \mathcal {S}\} \cup \{(v_k, p_k) \mid v_k \in \mathcal {U}, p_k \leftarrow \textsf {Proof}(\mathsf {sk}_\mathsf {ACC}{}, a,(v_k,\tau ))\})$

• $\textsf {Merge}$. To merge two valid set/signature pairs $(\mathcal {S},\sigma _\mathcal {S})$ and $(\mathcal {T},\sigma _\mathcal {T})$ with an equal tag $\tau$, the algorithm performs the following steps:

  • 1. Verify $\sigma _\mathcal {S}$ and $\sigma _\mathcal {T}$ w.r.t. $\tau$ using $\textsf {Verify}$. If they do not verify, return $\perp$

  • 2. Output $\sigma _\mathcal {U}$, where $\sigma _\mathcal {U}= (p_\tau , \{(v_i, p_i) \mid v_i \in \mathcal {S}\cup \mathcal {T}\})$, where $p_i$ is taken from the corresponding signature

Clearly, this construction is simple, yet fulfills all security requirements we need for our scenarios, if instantiated with a “good” accumulator. Moreover, Pöhls and Samelin have shown that the given construction is secure in the standard model if the strong RSA-Assumption holds [19], if used with their accumulator. However, the underlying hash-function needs to be division-intractable, whose only suitable instantiation seems to be mapping to primes in a collision-avoiding manner [7]. From an implementation perspective, this is too time-consuming, as we show in Sect. 5. We stress that Pöhls and Samelin already were aware of the fact that a signature-only based construction exists. However, as shown by Derler et al. [8], a lot of different accumulators exists, which may be used to achieve different or additional properties. We also leave this as open work, as for our applications scenarios trapdoor accumulators are enough.

4.1 Revisiting the Accumulator by Pöhls and Samelin

We now show that their construction is also secure in the random oracle model, as it offers far better efficiency, as we show in Sect. 5.

Trapdoor Accumulators $\mathsf {ACC}{}'$. We now present the adjusted construction. Even though the changes are minimal (yet invasive), the resulting performance gain is significant. We therefore present the full scheme in detail next.

Construction 2

(Trapdoor-Accumulator $\mathsf {ACC}{}'$ ). Let $\mathcal {H} : \{0,1\}^* \rightarrow \{0,1\}^{\lambda -1}$ be a random oracle. Here, $\lambda$ means the bit-length of the RSA modulus as proposed by Coron and Naccache [7]. Let $\mathsf {ACC}{}' :=(\textsf {Gen},\textsf {Dig},\textsf {Proof},\textsf {Verf}\,)$ such that:

• $\textsf {Gen}$. Generate $n = pq$, where p and q are distinct safe primes using $\mathsf {RSAKeyGen}$. Return $(\varphi (n),(n,\mathcal {H}))$, where $\varphi (pq) := (p-1)\cdot (q-1)$.

• $\textsf {Dig}$. To improve efficiency, we use the build-in trapdoor. A new digest can therefore be drawn at random. Return $a \in _R \mathbb {Z}_n^\times$.

• $\textsf {Proof}$. To generate a witness $p_i$ for an element $v_i$, set $v_i' \leftarrow \mathcal {H}(v_i)||1$. Output $p_i \leftarrow a^{v_i'^{-1} \pmod {\varphi (n)}} \mod n$.

• $\textsf {Verf}$. To check the correctness of a proof p w.r.t. an accumulator a, the public key $\mathsf {pk}_\mathsf {ACC}{}$, and a value v, output 1, if $a \mathop {=}\limits ^{?} p^{\mathcal {H}(v)||1} \pmod n$, and 0 otherwise.

Theorem 1

Construction 2 is secure in the random-oracle model, if the Strong-RSA Assumption holds.

Proof

For construction 2, we only need to prove collision-resistance, while correctness is obvious. Essentially, the proof is the same as the one given by Gennaro et al. [10], but compressed. In a nutshell, we build an adversary $\mathcal {B}$ which uses $\mathcal {A}$ internally to break the Strong-RSA Assumption. Let $q_h$ be an upper bound on the queries to the random oracle. Then, $\mathcal {B}$ draws a random index $i \in \{1,2,\ldots ,q_h\}$. It then draws $q_h$ random bit-strings $e_j$ of length $\lambda -1$, and sets $e_j' \leftarrow e_j||1$. Then, it sets $p \leftarrow \prod _{j=1,i\ne j}^{q_h}e_j \bmod n$. If $\gcd (p,e_j) \ne 1$, abort. This abort only appears with negligible probability, as already shown by Gennaro et al. [7, 10]. Then, $\mathcal {B}$ embeds the challenge (t, n) from the strong RSA-Experiment in the following way. It gives $(n, t^p \bmod n)$ to the adversary $\mathcal {A}$. For each query $v_i$, it sets the random oracle response to $e_i'$. If for $v_i$ ($i \ne j$) a witness is requested, it returns $t^{p/e_i'} \bmod n$. If, however, $i = j$, $\mathcal {B}$ has to abort. If $\mathcal {A}$ outputs $(v^*, p^*)$ such that $t^p = p^{*v^*} \bmod n$, $\mathcal {B}$ calculates $ae_j' + bp = 1$ using EEA, and $r \leftarrow t^a{p^{*b}} \bmod n$. It outputs $(e_j',r)$ as its own solution. The probability of $\mathcal {B}$ winning is the same as $\mathcal {A}$ divided by $q_h$, ignoring negligible parts.   $\square$

Theorem 2

Construction 1 is secure if instantiated with the accumulator above (Construction 2).

Proof

As the random oracle is still deterministic, the original proofs by Pöhls and Samelin [19] directly carry over without any modifications.   $\square$

Clearly the full construction, inheriting from the given accumulator, is only secure in the random-oracle model. We stress that the same ideas hold for the signature-based construction given in the extended version of [19]. However, as already stated, an accumulator may offer better performance than the signature-based construction.

5 Implementation and Evaluation

We implemented both constructions of $\mathsf {RSS}$ described in Sect. 4 on three different platforms. The only known construction of a division-intractable hash-function includes expensive primality tests [7]. Henceforth, we refer to it as ‘Prime’. Our new construction simply requires the hash’s value to be odd and is henceforth denoted as ‘Odd’. All hashes have been implemented as full-domain hashes using concatenation of shorter hash-outputs, as described by Bellare and Rogaway [4], paired with rejection sampling. Algorithm 1 shows the pseudo code for the implementation where FDH describes the full-domain hash and $\mathcal {H}$ a standard hash function such as SHA-512, but modeled as a random oracle. It is not hard to see that this implementation behaves like a random oracle, if $\mathcal {H}$ is a random oracle.

The crypto primitive was implemented in the C programming language for the constrained device RE-Mote and as a Java library for use in the cloud and on Android. Java was chosen because it is a widely used programming language and it provides many useful functionalities as well as existing cryptographic libraries. It also allowed us to re-use the same code base on both the Android and the cloud platform.

5.1 Our Platforms

The Android, Cloud and RE-Mote platforms are very different in terms of available computing power. On the one end, we have the very powerful cloud platform and on the other end, the resource constrained RE-Mote platform. The Android device’s compute power is somewhere in between the two aforementioned ones.

A cloud computer uses multicore processors and has multiple gigabytes of RAM. In our implementation of the healthcare use-case, we used one Intel Core i7-4790 quad-core processor clocked at 3.60 GHz to 4.00 GHz with 16 GB of RAM and Oracle’s JVM in version 1.8.0.92.

We used a Motorola Moto G (3rd Gen.) smart phone as the Android device for our implementation. It has a Qualcomm Snapdragon 410 quad-core processor clocked at 1.4 GHz with 1 GB RAM and was running Android Version 6.0.

The RE-Mote is a resource-constrained IoT platform that has been designed for applications with additional cryptographic support for increased security and privacy [17, 26] and still offers a low power consumption. It is based on a CC2538 ARM Cortex-M3, with up to 512 KB of programmable flash and 32 KB of RAM.

5.2 $\mathsf {MRSS}$ Key Generation is Done in the Cloud

The generation of keys in both of our use-cases solely happens in the cloud (see Table 1 for performance). Still, providing a complete PKI was out of scope of our implementation. Nevertheless, our Java library needs access to the keys. We tackled this problem by loading the keys from a Java keystore, which is based on the keystore provided by the Bouncy Castle [14] crypto library. In the health-care scenario this is due to the high need for computation power: the search for large safe-primes on the constrained device could easily take a couple of days and we foresee these keys to be provided or indeed generated during a burn-in phase of the certified HMD. In the cloud scenario the cloud service signs.

5.3 $\mathsf {MRSS}$ in the Cloud

To use the computing power of the cloud environment to full advantage, we implemented parallelized versions of the sign, update and verify algorithms. Namely, these three algorithms perform modular arithmetics and compute cryptographic hashes. This is more computationally intensive than removing elements from a given set, which is what the merge and redact algorithms do. To no surprise the merge and redact operations are very fast compared to the sign, update and verify operations. Thus, we did not put effort into parallelizing merge and redact. Sign, update and verify perform computations on every element of a given set or message. This calculation is on one element only and it is independent³ from the calculations on all other elements of the message. Using this knowledge allowed us to parallelize sign, update and verify; using Java we carried out the computation on each element of the set in parallel.

5.4 $\mathsf {MRSS}$ on a Mobile Phone

As we were only interested in performance measurements and not in user interaction with the $\mathsf {RSS}$, we implemented a bare-bone Android application without a graphical user interface. This application reused the Java $\mathsf {RSS}$ library that we already developed and implemented for the cloud. All cryptographic algorithms and the testing benchmarks used for the cloud platform were implemented also on Android, except those concerning key generation. Key generation tests were excluded since in our framework only the public keys are needed for verification. The quad core CPU of the Motorola Moto G allowed us to use the parallelization features provided by our Java $\mathsf {RSS}$ library, which sped up the tests significantly but diminished the usability of the mobile phone because no optimizations in that regard were made, as this was not important for the test application.

5.5 $\mathsf {MRSS}$ on a Constrained Device

The sign and verify algorithms are implemented in the C programming language, compatible with the Contiki operating system ran by the RE-Mote device. We used the different functions provided by an existing Elliptic Curve Cryptography library⁴ for the manipulation of numbers of large size. These functions implement arithmetical operations on big integers.

To tackle the considerable amount of time required by the safe prime generation algorithm, we generated the keys externally and hard coded the values on the RE-Mote device. The implementation on the RE-Mote is not as fast as we hoped, but there is still room for improvement. In particular, we could use a better optimized function for modular exponentiation, since this is the most expensive calculation in $\mathsf {RSS}$ and also called very often. Another limitation of the RE-Mote is its small RAM size, which made it impossible to sign or verify large messages.

5.6 Evaluation

For every test, we varied different parameters like the security parameter $\lambda$ and different levels of parallelization as well as using the ‘Prime’ and ‘Odd’ hash function implementations. On the constrained device we used a message with 4 redactable elements. For the mobile phone and the cloud we used for the ‘Prime’ version a message with 100 elements and for those using the ‘Odd’ version of the hash function, we used 100 and 1, 000 elements. We decided not to run tests with 1, 000 elements when using the original —‘Prime’— version of the hash function, because these tests were painfully slow. Tests which took longer than 12 h (${>}0.5d$) were stopped as such a runtime makes the scheme impractical to use.

The Construction 2 checks if the given message and signature verifies before calling the actual merge, update and redact routines. However, we disabled signature verification in these algorithms to gain a better impression of how fast or slow these operations are, because otherwise it would have also included the verification runtime. For a full runtime of update, merge and redact one must add the runtime of the verification algorithm on top.

Tables 1, 2, 3 and 4 show the detailed results of our performance measurements. These tables show an average runtime of four repetitions of every test.

Observations. Most important of all, we found that using the revised hash function, that does not require primality tests, denoted as ‘Odd’, allowed to achieve an average speedup of 1, 100 times compared to the originally proposed one, denoted ‘Prime’. Figure 3 shows this very impressive speedup as well as how the construction of $\mathsf {MRSS}$ scales excellently on multi-core CPUs.

Further, the test results show that—as expected—the runtime of operations increases linearly with the number of elements in a message. Additionally, it can be noted that the redact and merge operations are extremely fast independent of the used security parameter. Regarding the update and sign operation, we expected update to be slightly faster, since sign needs to additionally process the tag. However, this did not show in the results. Also the linearity of the selected $\mathsf {RSS}$ shows its practicality regarding update: updating n elements to a small message is equally fast as updating the same amount to a large message.

Fig. 3.

Runtime in seconds of signing a 100-element message with 4, 096 and 2, 048 bit keys on an Intel Core i7-4790 CPU

Table 1. Runtime in seconds of the KeyGen, Redact, Merge operations

Table 2. Average runtime in seconds of signing 100- and 1,000-element messages

Table 3. Average runtime in seconds of updating 100 and 1,000 elements to a message

Table 4. Average runtime in seconds of verifying 100- and 1,000-element messages

6 Conclusion

We presented two use cases where Redactable Signature Schemes ($\mathsf {RSS}$) can be used to a great advantage of all involved parties. With the given building blocks and our adjusted accumulator, we proved that the existing construction—which is taken from the standard model to the random oracle model—becomes practical. We gave exact runtimes for the old and adjusted construction in two real world applications on three very diverse hardware platforms. Our proof of concept implementation on the three platforms showed the infeasibility of the construction in the standard model due to excessive runtime for all operations, whereas the construction in the random oracle model offers practical runtimes on cloud and mobile devices. On the constrained device even the adjusted algorithm already runs for several minutes for only a small number of elements. However no factorisation co-processor was used for any speed-up and the used type of arithmetics are known to be slow on constrained devices. For IoT, future work is to look for usable elliptic curve based redactable signature constructions.