Keywords

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

To efficiently handle frequently recurring processes within enterprises, it is advantageous to define standardized business processes. An ICT supported technical realization of a business process is usually denoted as a workflow [30]. Such a workflow can be seen as an abstract process, which defines a certain sequence of tasks as well as conditions on how participating entities have to complete these tasks. In such a context, workflows may span various departments within an enterprise or even various enterprises (interorganizational workflows).

To always have an overview of the current state of concrete workflow instances and to be able to react to deviations from the defined workflows, it is important to document each step and to report it to some entity. Thereby, an inherent requirement is that these reports allow to verify whether delegatees acted within their boundaries and that each task can be attributed to a certain delegatee. This shall hold true especially if the process is interorganizational. In addition, it is desireable to automatically derive information, e.g., to issue warnings if certain constraints in a workflow are not met. Furthermore, it is often required that documentations of certain workflows are retained in an unforgeable recording for auditing or legal purposes. For example, the European data protection law requires an organization to document the usage of data [6]. However, the boundaries within each participating entity can act in a workflow might already be a sensitive business internal. Hence, it should not be disclosed to other parties (e.g., other enterprises in interorganizational workflows). Thus, an additional requirement is that the defined boundaries are not revealed to entities verifying a report, i.e., to ensure privacy, while still being able to check whether delegatees acted within their boundaries. We stress that this goal is in contrast to confidentiality of task reports. In particular, privacy requires that—even when the task reports are available in plain—the defined boundaries are not recoverable.

A suitable application is outsourcing inter- or intra-enterprise workflows to some environment that is not under full control, e.g., to the cloud. An automated process outsourced to the cloud may then run on behalf of the participants to carry out a task within such a workflow. A participating enterprise will be interested in the correctness of the workflow, the compliance with associated privacy requirements and to hold the cloud accountable. We note that especially in context of accountability there are significant efforts to provide and standardize frameworks for cloud accountability, e.g., as demonstrated within the A4Cloud project [44]. We note that we are interested in a more abstract view on workflows and cryptographic tools that allow to realize the aforementioned requirements.

1.1 Related Work

Besides [34, 39, 40], not much attention has been paid to cryptographically enforcing certain properties of workflows. Subsequently, we review the existing approaches and other related concepts.

In [39, 40], the authors investigate traceability and integrity aspects of decentralized interorganizational workflow executions. This work focuses on preserving authenticity and integrity with respect to logical relations (AND, OR, XOR) among certain tasks in a priori defined workflows, while the concrete agents executing the workflow tasks do not need to be pre-specified (these could be dynamically chosen with the help of some discovery service). To do so, they use policy-based cryptography [4], where every agent gets issued credentials from some central authorities (specifying attributes that the agent satisfies). Then, for each workflow step a policy defines what needs to be satisfied for the execution of the respective task (basically the required decryption keys can only be obtained if the policy is satisfied). In addition they use group signatures to guarantee anonymity of honest agents, but support traceability of malicious ones.

In contrast, [34] allows to dynamically define those workflows during the workflow execution. That is, they map the workflow to a (dynamically extendable) tree, where each node in the tree is interpreted as one particular workflow task. Then, building upon the hierarchical identity based signature scheme in [35], one can build a hierarchy of signing keys (i.e., each node in possession of a signing key can issue signing keys for its child nodes). These signing keys are then used to sign some task-dependent information and, due to the hierarchical nature of the underlying primitive, this delivers an authentic documentation of the workflow execution regarding the logical relations among subsequent tasks.

Orthogonal to our goals of authenticity, accountability and privacy, variants of attribute-based encryption were used for cryptographically ensured access control with respect to some policy in [2, 22, 43]. Recent work [21], thereby, also considers the possibility to hide the access policy.

Somehow close to our goal is [28], but it does not target the enforcement of properties of workflows. However, the authors use malleable signatures to allow to remove (potentially confidential) information from signed data, while not influencing source authentication in service oriented architectures (SOAs). In their approach, workflow participants exchange signed data based on predecessor-successor relationships. This is not what we are looking for in this case.

Finally, the work done in this paper relates to data provenance, which deals with identifying the origins of data and also giving a record of the derivation [41]. More precisely, this work relates to the aspect of process documentation found in data provenance, i.e., the proposed solutions will allow to verify whether a certain workflow was carried out as intended. This and other aspects of data provenance have been surveyed and studied in the literature, for example in [23, 42, 47]. Our work may be considered as realizing some aspects of provenance with cryptographic guarantees, i.e., to ensure that any deviation from a planned workflow will be detectable and that each workflow participant can be held accountable for it’s actions.

1.2 Motivation and Contribution

The few existing approaches to authenticity, accountability and privacy in workflows [34, 39, 40] rely on rather non-standard and often complex schemes. Given the importance of outsourcing computations and processes to cloud providers, it is thus an interesting challenge to look for simpler and more efficient solutions that rely on standard cryptographic primitives.

We propose two generic patterns to document the workflow executions, which can be instantiated using various different signature primitives. These patterns follow the well-known delegation-by-certificate approach from proxy signatures [37], and—in contrast to existing solutions—allow to obtain particularly efficient schemes which only make use of standard cryptographic primitives with multiple efficient instantiations. In addition to existing work, which only considers tasks from an abstract point of view, we also consider the outputs of tasks and their corresponding documentation (reports).Footnote 1 In this context, we discuss means to predefine the structure of reports to ease an automated processing and also cover related privacy issues. We develop a set of requirements for workflow documentation systems and analyze possible instantiations of our generic patterns from different types of signature schemes with respect to these requirements. Finally, we discuss open problems and future directions.

2 Preliminaries

Throughout the paper we require the notion of digital signature schemes, which we recall subsequently. A digital signature scheme \({(\mathsf {DSS})}\) is a triple \(\mathsf{KeyGen},\) \(\mathsf{Sign},\mathsf{Verify})\) of efficient algorithms. Thereby, \(\mathsf{KeyGen}\) is a probabilistic key generation algorithm that takes a security parameter \(\kappa \in \mathbb {N}\) as input and outputs a secret (signing) key \(\mathsf{sk}\) and a public (verification) key \(\mathsf{pk}\). Further, \(\mathsf{Sign}\) is a (probabilistic) algorithm, which takes a message \(M \in \{0,1\}^*\) and a secret key \(\mathsf{sk}\) as input, and outputs a signature \(\sigma \). Finally, \(\mathsf{Verify}\) is a deterministic algorithm, which takes a signature \(\sigma \), a message \(M \in \{0,1\}^*\) and a public key \(\mathsf{pk}\) as input, and outputs a single bit \(b\in \{0,1\}\) indicating whether \(\sigma \) is a valid signature for M under \(\mathsf{pk}\).

A digital signature scheme is required to be correct, i.e., for all security parameters \(\kappa \), all \((\mathsf{sk, pk})\) generated by \(\mathsf{KeyGen}\) and all \(M \in \{0,1\}^*\) one requires \(\mathsf{Verify}(\mathsf{Sign}(M,\mathsf{sk}),M, \mathsf{pk}) = 1.\) Additionally, for security one requires existential unforgeability under adaptively chosen-message attacks (EUF-CMA) [24].

3 Workflow Model

In the following we align our notation largely with the one used in [34]. A workflow W comprises some central entity called the workflow manager (WM) who wants to outsource a workflow to some set A of entities denoted as agents. Thereby, every workflow can be decomposed into single atomic tasks \(t_i\in T\), where every task is executed by some agent. For instance, task \(t_i\in T\) may be executed by agent \(A_j\in A\), which we denote by \(A_j(t_i)\).

As it is common when modeling workflows (e.g., [29]), we define a workflow as a directed acyclic graph \(W=(T,E)\), where each vertex \(t_i\in T\) represents one particular task and edges \(e_j \in E \subseteq T\times T\) represent task dependencies, i.e., a vertex \((t_u,t_v)\in E\) means that task \(t_v\) follows after the completion of task \(t_u\). Now, we augment such a simple workflow by the following semantics and in the remainder of the paper we always mean such an augmented workflow when we speak of a workflow. Each vertex \(t_i\in T\) with at least two outgoing edges (i.e., where outdegree \(\text {deg}^{+}(t_i)\ge 2)\) is called a split and each vertex \(t_i\) with at least two incoming edges (i.e., where indegree \(\text {deg}^{-}(t_i)\ge 2)\)) is called a join. Each split and join is associated with a logical type \(\{\)AND,OR,XOR\(\}\). In case of an AND split all edges are executed in parallel; in case of an XOR split exactly one edge must be executed; and in an OR split at least one edge needs to be executed. To illustrate this idea, we present an example of a simple workflow in Fig. 1. For ease of presentation we label each outgoing edge with the respective type.

Fig. 1.
figure 1

A simple workflow example.

Full size image

To distinguish between successful and unsuccessful workflow executions, we need the notion of a trace. A trace \(\tau \) of a workflow is a sequence of tasks in the order of their execution and a trace is called valid if it is compatible with the workflow. Let us look at the example in Fig. 1. For instance, the trace \(\tau =(t_1,t_2,t_3,t_5,t_7,t_8,t_9)\) is invalid, but \(\tau '=(t_1,t_2,t_3,t_4,t_5,t_7,t_8,t_9)\) is a valid trace.

Another issue that needs to be addressed is that not every agent may be allowed to execute every task. Consequently, we use assignment \(\alpha (\tau )\) to denote the sequence indicating which agents have executed the respective task. For instance, we may have \(\alpha (\tau ')=(A_1,A_2,A_3,A_4,A_5,A_6,A_7,A_8)\). Furthermore, either the WM may specify which potential set of agents is allowed to execute each task (static assignment) or each agent may dynamically decide which agents may execute the subsequent task(s) (dynamic assignment). In case of a static assignment, we call an assignment \(\alpha (\tau ')\) valid if it is compatible with the restrictions set by the WM. We note that our above notation deviates from the one in [34] who only consider dynamic assignments. Also, in contrast to [34] who solely look at the tasks in a workflow from a very abstract level, we are also interested in properties of the outputs of the tasks and thus get a bit more concrete. Therefore, we introduce the notion of the documentation of one particular task in a workflow and denote it as the report of a task, or report in short.

Subsequently, we introduce desirable properties for the documentation of workflow executions. Firstly, the most crucial requirement in our setting is that reports are protected against unauthorized modifications. Recall, that we do not consider the orthogonal feature of providing confidentiality for workflow data.

Requirement 1

The integrity of the reports needs to be ensured.

Furthermore, it is required that only the workflow manager and the execution agent, which is actually performing a certain task, can produce a valid report.

Requirement 2

For a particular task \(t_i\), no one except the workflow manager and the agent(s) assigned to \(t_i\) is/are capable of creating task reports that are accepted by an auditor.

In this context, it is also important that each report can be used to identify the respective execution agent (workflow manager), i.e., to ensure accountability.

Requirement 3

The execution agent (workflow manager) that performs a certain task can be held accountable for its actions.

However, as long as the work is done correctly, a delegator might want to account for the work of a delegatee, while still being able to accuse the delegatee in case of a dispute.Footnote 2

Requirement 4

One can not publicly verify whether a delegator or a delegatee created a certain report, while it is still possible to provide a proof assigning the task execution to one of the aforementioned parties.

In addition, it is desirable to automatically derive information, e.g., to issue warnings if certain constraints in a workflow are not met.

Requirement 5

Task reports allow to derive the order of the tasks in a certain workflow instance.

Fig. 2.
figure 2

Pattern for statically assigned workflows. The tuples \((r_i, \sigma _i)\) denote the task reports corresponding to \(A_i(t_i)\). If \(\mathsf{OP} =\) AND then \(\hat{\sigma }\leftarrow \sigma _2||\sigma _3\), if \(\mathsf{OP} =\) OR then \(\hat{\sigma }\leftarrow \sigma _2\), \(\hat{\sigma }\leftarrow \sigma _3\), or \(\hat{\sigma }\leftarrow \sigma _2||\sigma _3\), if \(\mathsf{OP} =\) XOR then \(\hat{\sigma }\leftarrow \sigma _2\) or \(\hat{\sigma }\leftarrow \sigma _3\).

Full size image

3.1 Bringing Signatures to Workflows

We can model workflows using the well-known delegation-by-certificate approach from proxy signatures [37]. Subsequently, we describe two useful patterns.

Static Assignment. Figure 2 illustrates the pattern for a statically assigned workflow. Here, the workflow manager computes a signature \(\sigma _0\) on a sequence of (sets of) public keys \(\mathsf{PK}\) together with the respective split/join operations. Then, for each task, (one of) the authorized agent(s) can sign the respective report using its secret key \(\mathsf{sk}_i\) corresponding to the public key \(\mathsf{pk}_i\) in \(\mathsf{PK}\). To be able to reconstruct the order of the task executions, agent \(A_j\) also includes the signature(s) of the agent(s) executing the preceding tasks in its signature \(\sigma _i\).

Dynamic Assignment. Figure 3 describes the pattern for dynamically assigned workflows. In this approach, the workflow manager only delegates to the first agent within the workflow and the agents can further delegate the execution rights for subsequent tasks to subsequent agents.

Fig. 3.
figure 3

Pattern for dynamically assigned workflows. The tuples \((r_i, \sigma _i)\) denote the task reports corresponding to \(A_i(t_i)\). For simplicity, we omit split/join (cf. Fig. 2).

Full size image

3.2 Structuring Task Reports

Orthogonal to the requirement to ensure logical relations among tasks, it might also be interesting to automatically verify certain constraints regarding particular decisions upon execution of a task \(t_i\). For instance, it would be convenient to predefine certain sets of possible actions of an agent per task. As a simple realization one can think of a form containing several multiple-choice fields, where each multiple-choice field corresponds to a subtask of a specific task in a workflow. Then, an application monitoring reports can easily define constraints in the fashion of: if Option A was chosen in Subtask 1.1 and Option B was chosen in Subtask 1.2 then issue a warning. If required, this can easily be extended to arbitrarily complex forms per task (Fig. 4).

Fig. 4.
figure 4

A simple task report for a task \(t_1 = (t_{1.1},t_{1.2},t_{1.3})\), composed of three multiple choice elements.

Full size image

Adding a structure to the task reports, suggests to introduce the following additional requirements.

Requirement 6

It is possible to predefine the structure of task reports.

Besides addressing the structure of the report, allowing the delegatee to predefine sets of admissible choices for certain parts of task reports would help to improve the quality and help to automate the processing.

Requirement 7

It is possible to predefine sets of admissible choices for certain fields in the task report.

However, such detailed workflow reports also impose privacy requirements, since it is crucial that business internals remain confidential, e.g., when reports are revealed for auditing purposes.

Requirement 8

Task reports do not reveal additional information that is available to the delegator and/or the execution agent (e.g., the unused choices of the predefined sets of admissible replacements).

4 Instantiations

Using standard digital signatures, one can straightforwardly instantiate the patterns in Figs. 2 and 3. Subsequently, we revisit the instantiation of these patterns with other variants of digital signatures. We stress that we provide algorithmic descriptions for the schemes as we believe that this makes the presentation unambiguous and clearer than any informal textual description.

Append-Only Signatures. Append only signatures [32] allow to publicly extend signed messages and to update the signature correspondingly. An append only signature scheme (\(\mathsf{AOS}\)) is a tuple of efficient algorithms \((\mathsf{Setup}, \mathsf{Append}, \mathsf{Ver}\mathsf{ify})\), which are defined as follows:

  • \(\mathsf{Setup:}\) On input of a security parameter \(\kappa \), this algorithm outputs a keypair \((\mathsf{sk, pk})\), where \(\mathsf{sk}\) constitutes the signature on the empty message.

  • \(\mathsf{Append:}\) On input of a public key \(\mathsf{pk}\), a signature \(\sigma _{n-1}\) on a message \((m_1, \dots ,m_{n-1})\), and a message \(m_n\), this algorithm outputs a signature \(\sigma _n\) on the message \((m_1, \dots , m_n)\).

  • \(\mathsf{Verify:}\) On input of a public key \(\mathsf{pk}\), a signature \(\sigma \) and a message \(M = (m_1, \dots ,m_n)\), this algorithm outputs a bit \(b \in \{0, 1\}\), indicating whether \(\sigma \) is valid.

For security, \(\mathsf{AOS}\) are required to provide AOS-unforgeability under chosen message attacks. Informally this means that the only way of creating a valid signature of length n on a message \(M = (m_1, \dots , m_n)\) is to extend a valid signature on message \(M' = (m_1, \dots , m_{n-1})\).

Application to Workflows: Using append-only signatures, the workflow manager creates a signature on the empty message and each agent can append its documentation. Due to their public-append capabilities, \(\mathsf{AOS}\) are suited for unauthorized delegations, which only ensure the integrity of the signed reports.

Redactable Signatures. Informally, redactable signatures [31, 38, 48] allow to sign documents, where certain predefined parts can later be blacked out (or cloaked) without signer interaction and without invalidating the signature. A redactable signature scheme (\(\mathsf {RSS}\)) is a tuple of efficient algorithms \((\mathsf{KeyGen},\mathsf{Sign},\mathsf{Verify},\mathsf{Red}\mathsf{act})\), which are defined as follows (using the notation of [19]):

  • \(\mathsf{KeyGen:}\) On input of a security parameter \(\kappa \), this algorithm outputs a key-pair \((\mathsf{sk}, \mathsf{pk})\).

  • \(\mathsf{Sign:}\) On input of a secret key \(\mathsf{sk}\), a message M and admissible redactions \(\mathsf {ADM}\), this algorithm returns a message-signature pair \((M, \sigma )\) (where \(\mathsf {ADM}\) can be derived from \(\sigma \)).

  • \(\mathsf{Verify:}\) On input of a public key \(\mathsf{pk}\), a message M and a signature \(\sigma \), this algorithm outputs a bit \(b\in \{0, 1\}\), indicating the validity of \(\sigma \).

  • \(\mathsf{Redact:}\) This algorithm takes a public key \(\mathsf{pk}\), a signature \(\sigma \), a message M and modification instructions \(\mathsf {MOD}\), computes an updated signature \(\sigma '\) and outputs an updated message signature pair \((\mathsf {MOD}(M), \sigma ')\).

Essentially the redaction can be done by everyone, meaning that (1) the entity that performs the redaction is not accountable for the changes and (2) one is only able to black out certain document parts. For security, redactable signatures are required to be unforgeable and private.

  • Unforgeability captures the infeasibility to output a valid message signature pair \((M, \sigma )\) without knowing \(\mathsf{sk}\), unless \((M, \sigma )\) was obtained by redaction.

  • Privacy requires it to be infeasible for every efficient adversary to reconstruct the redacted message parts, given the redacted message and its signature.

See [19] for a formal security model. Besides these properties, the security model for \(\mathsf{RSS}\) has been refined and extended several times. Firstly, [45] introduced the notion of accountability, which requires that signers and redactors can be held accountable for their signatures/redactions. Secondly, [14, 45] independently introduced unlinkability for \(\mathsf{RSS}\) as an even stronger privacy notion. Unlinkability essentially requires multiple redactions of the same document to be unlinkable. We, however, note that we do not further consider unlinkability here, since privacy already provides the required security guarantees in our context. We also mention that redactable signatures are related to the more general framework of P-homomorphic signatures [1].

Application to Workflows: In context of workflows, \(\mathsf{RSS}\) can be used in two different ways:

  1. (1)

    One uses \(\mathsf{RSS}\) in the same way as conventional \(\mathsf{DSS}\). Then, when it is required to publish reports (e.g., for auditing purposes) it can be useful to redact certain confidential parts of the reports.

  2. (2)

    Provided that all potential reports are known prior to designating a task to an agent, one could enumerate all variants of the reports and sign this list using an \(\mathsf{RSS}\). The agent then simply redacts—thus removes—all reports that are not required. While conventional \(\mathsf{RSS}\) do not provide accountability in this setting, accountable \(\mathsf{RSS}\) (\(\mathsf{ARSS}\)) [45] can be used to additionally provide accountability.

Sanitizable Signatures. Sanitizable signatures [3, 9–13, 46] split messages in fixed and variable message parts and allow to issue signatures on them. A designated party (the sanitizer) is then able to modify the variable parts of the message without invalidating the signature. A sanitizable signature scheme (\(\mathsf {SSS}\)) is a tuple of efficient algorithms \((\mathsf{KeyGen_\mathsf {sig}, KeyGen_\mathsf {san},Sign, Sanit, Verify, Proof, Judge})\). Subsequently, we recall the definitions from [9]:

  • \(\mathsf{KeyGen_\mathsf {sig}:}\) On input of a security parameter \(\kappa \), this algorithm outputs a signer key-pair \((\mathsf{sk}_\mathsf {sig}, \mathsf{pk}_\mathsf {sig})\).

  • \(\mathsf{KeyGen_\mathsf {san}:}\) On input of a security parameter \(\kappa \), this algorithm outputs a sanitizer key-pair \((\mathsf{sk}_\mathsf {san}, \mathsf{pk}_\mathsf {san})\).

  • \(\mathsf{Sign:}\) On input of a message M, corresponding admissible modifications \(\mathsf {ADM}\), the keypair of the signer \((\mathsf{sk_\mathsf {sig}, \mathsf pk_\mathsf {sig}})\), as well as the verification key of the sanitizer \(\mathsf{pk}_\mathsf{san}\), this algorithm outputs a message-signature pair \((M, \sigma )\), where it is assumed that \(\mathsf {ADM}\) can be reconstructed from \(\sigma \).

  • \(\mathsf{Sanit:}\) On input of a valid message-signature pair \((M, \sigma )\), modification instructions \(\mathsf {MOD}\), some auxiliary information \(\mathsf {aux}\), the verification key of the signer \(\mathsf{pk_\mathsf {sig}}\) and the secret key of the sanitizer \(\mathsf{sk_\mathsf {san}}\), this algorithm outputs an updated message signature pair \((\mathsf {MOD}(m), \sigma ')\) and \(\bot \) if the modification instructions are incompatible with \(\mathsf {ADM}\).

  • \(\mathsf{Verify:}\) On input of a message-signature pair \((M, \sigma )\) and the verification keys of the signer \(\mathsf{pk_\mathsf {sig}}\) and the sanitizer \(\mathsf{pk_\mathsf {san}}\), this algorithm outputs a bit \(b\in \{0, 1\}\) indicating whether \(\sigma \) is a valid signature on M.

  • \(\mathsf{Proof:}\) On input of a message-signature pair \((M, \sigma )\), q message-signature pairs \((M_j, \sigma _j)_{j =1}^q\) created by the signer, the keypair \((\mathsf{sk_\mathsf {sig}, pk_\mathsf {sig}})\) of the signer and the verification key of the sanitizer \(\mathsf{pk_\mathsf {san}}\), this algorithm outputs a proof \(\pi \).

  • \(\mathsf{Judge:}\) On input of a message-signature pair \((M, \sigma )\), the verification keys of the signer \(\mathsf{pk_\mathsf {sig}}\) and the sanitizer \(\mathsf{pk_\mathsf {san}}\), and a valid a proof \(\pi \), this algorithm outputs a bit \(b \in \{ \mathtt{sig, san} \}\), indicating whether the respective signature was created by the signer or the sanitizer.

Subsequently, we informally discuss the security properties of sanitizable signatures (introduced in [3] and formalized in [9]):

  • Unforgeability requires that only honest signers and sanitizers are able to produce valid signatures.

  • Immutability requires that malicious sanitizers are not able to modify fixed message parts.

  • Transparency requires that no one (except the signer and the sanitizer) can distinguish signatures of the signer from signatures of the sanitizer.

  • Privacy requires that no one (except the signer and the sanitizer) can recover sanitized information.

  • Signer-/Sanitizer-accountability Requires that no signer can falsely accuse a sanitizer of having created a certain signature and vice versa.

The above properties have seen some refinement and gradual extension since their formalization in [9], e.g., by [12, 13, 16, 20, 25, 33, 45].

In [33], among others, an extension that additionally allows to define sets of admissible replacements per message block (LimitSet) was introduced and later formalized in [15] (henceforth called extended sanitizable signatures or \(\mathsf{ESSS}\)). Their formalization, however, does not require the sets of admissible modifications to remain concealed upon verification, and, thus, does not define privacy in the original sense. Thus, [20] introduced the notion of strong privacy, that additionally covers this requirement. In [20], it is also shown that \(\mathsf{ESSS}\) providing strong privacy can be black-box constructed from every secure \(\mathsf{SSS}\) in the model of [9] and indistinguishable accumulators [18].

Orthogonal to that, [13] discusses that accountability can be modeled in two ways: non-interactive or interactive. The model presented above is tailored to interactive (non-public) accountability. In contrast, non-interactive (public) accountability requires that \(\mathsf{Judge}\) works correctly on an empty proof \(\pi \).Footnote 3 We emphasize that non-interactive accountability might be helpful in workflows, where the original signer can not be involved for certain reasons, e.g., efficiency.

Application to Workflows: By definition, \(\mathsf{SSS}\) include a delegation mechanism, i.e., a signer grants a sanitizer permission to modify certain parts of a signed message without invalidating the signature. Thus, using this primitive, one can not only pre-specify the execution agent, but also the structure of the report.Footnote 4 In other words, \(\mathsf{SSS}\) allow to split the report into several fields; then, according to the pre-defined workflow, one specifies which agent (i.e., by specifying the sanitizer) is allowed to put arbitrary content into certain fields of the report. In addition, \(\mathsf{SSS}\) provide transparency, which is useful if it is required to hide whether a certain task was outsourced or not. In case of a dispute, the \(\{\mathsf{Proof},\mathsf{Judge}\}\) algorithms still guarantee accountability. In case the additional level of privacy given by transparency is not needed, one can use non-interactively (publicly) accountable \(\mathsf{SSS}\), e.g., [12, 13].

  • \(\mathsf{ESSS}\) [15]: Extended sanitizable signatures, as defined in [15], extend \(\mathsf{SSS}\) by the possibility to limit the admissible modifications per message block to sets of allowed messages. This allows for an even more fine grained definition of the report structure. However, the model of [15] does not require the unused choices in the sets of admissible modifications to remain hidden upon verification. While this extension eases the automatic processing of reports, the limited privacy features limit the practical applicability of this instantiation.

  • \(\mathsf{ESSS}\) [20]: Extended sanitizable signatures, as defined in [20], fix the aforementioned privacy problems, which, in turn, extends their applicability to workflow documentation systems.

Proxy Signatures. Proxy signature (\(\mathsf{PS}\)) schemes, introduced in [37] and formalized in [7] allow a delegator to delegate the signing rights for a certain message space \(\mathcal M\) to a proxy. A proxy can then produce signatures for messages \(m\in \mathcal M\) on behalf of the delegator. Subsequently, we recall the definitions from [7]:

  • \((\mathsf{D}, \mathsf{P}):\) The originator and the proxy jointly compute a delegation for the message space \(\mathcal M\) as well as a proxy signing key \(\mathsf{skp}\). The originator runs \(\mathsf{D}\) and outputs the delegation \(\sigma \) computed using its signing key \(\mathsf {sk}_i\), whereas the proxy verifies the delegation and obtains the proxy signing key \(\mathsf{skp}\), which consists of its private signing key \(\mathsf {sk}_j\) and the originators delegation.

  • \(\mathsf{Sign}:\) This algorithm computes and outputs a proxy signature \(\sigma _P\) for message \(m \in \mathcal M\) using the proxy signing key \(\mathsf{skp}\).

  • \(\mathsf{Verify}:\) This algorithm verifies whether proxy signature \(\sigma _P\) is a valid proxy signature for message m under \(\mathsf{pk}_{j}\), delegated by \(\mathsf{pk}_{i}\). On success, this algorithm outputs 1, and 0 otherwise.

  • \(\mathsf{ID}:\) This algorithm outputs the identity j of the proxy, when given a proxy signature \(\sigma _P\).

For security, proxy signatures are required to be unforgeable, which informally means that no one can produce valid signatures for messages \(m \notin \mathcal M\) and only the designated proxy can produce valid signatures for \(m \in \mathcal M\). In [27], the model was extended by introducing privacy, which essentially requires that—upon verification of a signature \(\sigma _P\) on a message \(m \in \mathcal M\)—the verifier learns nothing about \(\mathcal M\) (except that \(m \in \mathcal M\)). Signatures secure in this model are called warrant-hiding proxy signatures (\(\mathsf{WHPS}\)). We note that proxy signatures are one instantiation of the more general concept of functional signatures [5, 8].

Application to Workflows: Here, a delegator grants a proxy the signing rights for messages out of a certain message space \(\mathcal M\). This delegation mechanism can be used to predefine all possible reports and the executing agent only chooses the suitable report. In addition, \(\mathsf{WHPS}\) additionally provide privacy with respect to the unused reports in the designated message space.

Blank Digital Signatures. Blank digital signatures, introduced in [26], allow an originator \(\mathsf{O}\) to define and sign forms (so-called templates \(\mathcal T\)) consisting of fixed and exchangeable (multiple-choice) elements. These forms can then be filled in (instantiated) by a designated party (the proxy \(\mathsf{P}\)). Upon verification, the verifier only learns the values chosen by the designated party. A blank digital signature scheme (\(\mathsf{BDSS}\)) is a tuple of efficient algorithms \((\mathsf{KeyGen}, \mathsf{Sign}, \mathsf{Verify}_\mathsf{T}, \mathsf{Inst},\mathsf{Ver}\mathsf{ify}_\mathsf{I})\), which are introduced subsequently. Thereby, we assume that \(\mathsf{DSS}\) signing keys for the originator \((\mathsf{sk}_\mathsf{O}, \mathsf{pk}_\mathsf{O})\) and the proxy \((\mathsf{sk}_\mathsf{P}, \mathsf{pk}_\mathsf{P})\) already exist.

  • \(\mathsf{KeyGen}:\) On input of a security parameter \(\kappa \) and an upper bound for the template size t, this algorithm outputs public parameters \(\mathsf{pp}\). We assume \(\mathsf{pp}\) to be an implicit input to all subsequent algorithms.

  • \(\mathsf{Sign}:\) On input of a template \(\mathcal T\), the signing key of the originator \(\mathsf{sk_\mathsf{O}}\) and the verification key of the proxy \(\mathsf{pk_\mathsf{P}}\), this algorithm outputs a template signature \(\sigma _\mathcal{T}\) and a secret instantiation key \(\mathsf{sk_\mathsf{P}^\mathcal{T}}\) for the proxy.

  • \(\mathsf{Verify}_\mathsf{T}:\) On input of a template \(\mathcal T\), a template signature \(\sigma _\mathcal{T}\), the instantiation key of the proxy \(\mathsf{sk_\mathsf{P}^\mathcal{T}}\) and the public verification keys of the originator \(\mathsf{pk_\mathsf{O}}\) and the proxy \(\mathsf{pk_\mathsf{P}}\), this algorithm outputs a bit \(b \in \{0, 1\}\), indicating whether \(\sigma _\mathcal{T}\) is valid.

  • \(\mathsf{Inst}:\) On input of a template \(\mathcal T\), a template signature \(\sigma _\mathcal{T}\), an instance \(\mathcal M\), the signing key \(\mathsf{sk_\mathsf{P}}\) and the instantiation key \(\mathsf{sk_\mathsf{P}^\mathcal{T}}\) of the proxy, this algorithm outputs an instance signature \(\sigma _\mathcal{M}\) on \(\mathcal M\) if \(\mathcal M\) is a valid instance of \(\mathcal T\) and \(\bot \) otherwise.

  • \(\mathsf{Verify}_\mathsf{I}:\) On input of an instance \(\mathcal M\), an instance signature \(\sigma _\mathcal{M}\) and the verification keys of the originator \(\mathsf{pk_\mathsf{O}}\) and the proxy \(\mathsf{pk_\mathsf{P}}\), this algorithm outputs a bit \(b \in \{0, 1\}\), indicating whether \(\sigma _\mathcal{M}\) is valid.

The security requirements for \(\mathsf{BDSS}\) are (informally) defined as follows:

  • Unforgeability requires that only the honest originator and proxy can create valid signatures.

  • Immutability requires that even malicious proxies cannot create instance signatures for invalid instances \(\mathcal M\) of \(\mathcal T\).

  • Privacy requires that no one (except the proxy and the originator) can recover the unused choices for the exchangeable elements.

Application to Workflows: \(\mathsf{BDSS}\) are—up to the missing transparency and accountability properties—similar to \(\mathsf{ESSS}\) in [20] and can, thus, be used for similar purposes. We note that all known instantiations of \(\mathsf{BDSS}\) [17, 26] provide public accountability, since they require an explicit signature of the delegatee (proxy).

4.1 Comparison and Discussion

In Table 1, we bring the various possible instantiations discussed above into the context of the previously defined requirements, where we exclude naive instantiations.

Table 1. Requirements covered by the respective instantiations. Legend: \(\checkmark \) \(\dots \) supported, \(\mathsf{A}\dots \) supported by \(\mathsf{ARSS}\) [45], \(\dagger \dots \) if scheme is transparent
Full size table

Depending on the used scheme, we can cover different subsets of previously posed requirements. While choosing a concrete instantiation always depends on the requirements, we note that \(\mathsf{ESSS}\) and \(\mathsf{BDSS}\) seem to be particularly well suited for the considered applications. Note that—mainly due to the imposed overhead—we do not consider naive solutions such as achieving Requirements 6 and 7 by enumerating all possible task reports. We again stress that the instantiations discussed in this paper are very simple and only make use of standard cryptographic primitives with multiple efficient instantiations. Thereby, we only require to assume the existence of some public key authority.

Outlook. In this paper we have discussed potential solutions for authentic and accountable, yet privacy maintaining documentation of outsourced workflows. While we, thereby, followed a rather high-level and informal approach, it would be interesting to model the desired security properties more formally (as for instance done in [36] for cloud provenance). Furthermore, it would be interesting to evaluate the practical value of our proposed solutions in a real world setting. Finally, we note that it seems to be straight forward to extend our approach by cryptographic access control solutions (e.g., [21, 22]) to restrict the access to task reports. We leave these points as future work.