Fully invisible protean signatures schemes

IET Information SecurityVolume 14, Issue 3 p. 266-285 Special Section: Selected Papers from 17th International Conference on Cryptology and Network Security (CANS)Free Access Fully invisible protean signatures schemes Stephan Krenn, Corresponding Author Stephan Krenn stephan.krenn@ait.ac.at AIT Austrian Institute of Technology, Vienna, AustriaSearch for more papers by this authorHenrich C. Pöhls, Henrich C. Pöhls ISL & Chair of IT-Security, University of Passau, Passau, GermanySearch for more papers by this authorKai Samelin, Kai Samelin TÜV Rheinland i-sec GmbH, Hallbergmoos, GermanySearch for more papers by this authorDaniel Slamanig, Daniel Slamanig AIT Austrian Institute of Technology, Vienna, AustriaSearch for more papers by this author Stephan Krenn, Corresponding Author Stephan Krenn stephan.krenn@ait.ac.at AIT Austrian Institute of Technology, Vienna, AustriaSearch for more papers by this authorHenrich C. Pöhls, Henrich C. Pöhls ISL & Chair of IT-Security, University of Passau, Passau, GermanySearch for more papers by this authorKai Samelin, Kai Samelin TÜV Rheinland i-sec GmbH, Hallbergmoos, GermanySearch for more papers by this authorDaniel Slamanig, Daniel Slamanig AIT Austrian Institute of Technology, Vienna, AustriaSearch for more papers by this author First published: 01 May 2020 https://doi.org/10.1049/iet-ifs.2019.0141Citations: 1AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Protean signatures (PSs), recently introduced by Krenn et al. (CANS '18), allow a semi-trusted third party (the sanitiser), to modify a signed message in a controlled way: the signer can define the message parts to be arbitrarily editable by the sanitiser, as well as message parts which can be redacted (but not altered otherwise) by the sanitiser. Thus, PS s generalise both redactable signatures (RSs) and sanitisable signatures (SSs) into a single notion. Invisibility for PSs guarantees that no outsider (i.e. any party not being signer or sanitiser) can decide which message parts can be edited. However, the current definition of invisibility does not prohibit that an outsider can decide which parts are redactable – only which parts can be edited are hidden. This negatively impacts the privacy guarantees provided by this definition. The authors extend PSs to be fully invisible. Their notion guarantees that an outsider can identify neither editable nor redactable parts. They, therefore, introduce the new notions of invisible RS s and invisible non-accountable SSs (), along with a consolidated framework for aggregate signatures. Using those building blocks, their resulting construction is significantly more efficient than the original scheme by Krenn et al., which they demonstrate in a prototypical implementation. 1 Introduction By definition, (plain) digital signatures prohibit any kind of modification of signed messages. That is, only the holder of the secret signing key can sign messages [1]. Still, there are a plethora of application scenarios where a later modification of signed messages by a (semi-trusted) third party has its merits [2], e.g. in the following use-case, based on the handling of patient data [3-6]. Assume that an M.D. always signs complete patient records. Further assume that each of those records consists of the patient's name, its insurance number and the treatments given. After the patient is released from the hospital, the responsible accountant receives the complete signed record corresponding to the to-be-released patient to be able to write a bill to the patient's insurance company. It is easy to see that this process is not very privacy-friendly from the patient's point of view, as the accountant receives all the information related to the patient. However, most of the information is not relevant for writing the bill, e.g. the patient's name. Thus, a solution is to only give the treatments and the insurance number to the accountant, anonymising the paperwork. The major obstacle is that standard digital signatures prohibit any alterations, and thus the M.D. either needs to re-sign the document, or an additional trusted entity does need to sign on behalf of the M.D. Both solutions are not satisfactory, as both induce additional overhead, one might even be impossible, e.g. if the M.D. is no longer employed. We conclude that modifying signed messages in a controlled way does have its merits. Motivation and contribution: Strictly speaking, the above application scenario only requires that parts of a signed message can be redacted without invalidating the signature, which is achieved by redactable signatures (RSs) [7, 8]. Yet, also editing, but not redacting, parts of a message has many use-cases, including secure routing, document sanitisation, and outsourcing of computation, cf. [2], which can be achieved using sanitisable signatures (SSs) [4]. Bilzhause et al. [2] asked whether SS s and RS s could be combined, enabling signatures which allow for editing and redacting blocks at the same time. This question was answered by Krenn et al. by introducing 'protean signatures' (PS) [3], which allow subsequent editing and redacting simultaneously. They provide a formal security model, a provably secure construction, and present first implementation results. However, their definition of invisibility only guarantees that an outsider cannot decide which parts of a message are editable, but not which are redactable. This negatively impacts on the privacy guarantees their construction provides. Moreover, their corresponding implementation shows that their construction cannot be considered practically efficient. We extend their work in the following areas: (i) As our main contribution we introduce a stronger invisibility definition for PS s. In more detail, in our definition, an outsider can neither decide which parts of a message are redactable nor which parts are editable. (ii) To show that our strengthened definition is actually achievable, we provide an altered (black-box) construction of a PS, derived from the original one by Krenn et al. [3]. (iii) We provide a new framework for aggregate signatures [9], which may be useful in other contexts as well. Namely, we introduce the new notions of strict aggregate uniqueness, a black-box 'no-extraction' notion, and explicitly allow for de-aggregation. (iv) Our construction makes use of two new primitives which we also introduce: an invisible designated redactor RS, and a non-accountable invisible . In an invisible designated redactor RS, only a signer-chosen semi-trusted third party can redact, while an outsider cannot decide which parts are redactable. Likewise, non-accountable invisible s behave as standard invisible SS s, but do not offer any form of accountability. This allows for a far more efficient instantiation. For both new notions, we provide formal frameworks, formal security models, and provably secure instantiations. (v) We have implemented our scheme in a prototypical way. Using our new primitives, the resulting construction is an order of magnitude more efficient than the one given by Krenn et al. [3], and can be considered really practical. (vi) Finally, on a very technical level, we provide a slightly stronger definition of invisibility for standard SSs, where the adversary is now able to query arbitrary messages to the sanitisation oracle instead of only honestly generated ones. Related work: Signatures allowing for subsequent alterations received a lot of attention in the recent past, as it became apparent that there are many application scenarios where signed messages need to be modified in a controlled way [2, 10-12]. This weakens the standard unforgeability definition, where the messages protected by signatures cannot be altered at all, which is clearly not avoidable if one wants to allow for modifications or derivations. From our perspective, existing work can be grouped into three, not always distinct, directions. The first direction is homomorphic signatures [7, 10, 13, 14], and some other closely related concepts [15, 16]. Homomorphic signatures take several (signed) messages as input and can be used to compute functions on authenticated data-sets. In such schemes, an entity not holding any secrets can derive a new (valid) signature on , where the function f is public. Related are RS s, where anyone (i.e. no secrets are required) can publish a subset of signed data, along with a new signature . To illustrate this, let along with a valid RS . Anyone can then derive a signature on , i.e. redact the second and third block and , if both blocks are marked as redactable. The original ideas of RS s [7, 8] were later formalised [17, 18], including adding new values after signature generation [19]. Then, RS s have been extended to allow for additional use-cases, including adding accountability [20], discussing their relation to SS s [21], allowing for redactable structure [22], prohibiting additional redactions [23-26], yet also defining dependencies between different parts of a message [5]. Moreover, there are also some real-world implementations of this primitive proving that they are practical [6, 27]. All these approaches (but accountability) have later been unified into a generalised framework by Derler et al. [28]. We stress that the work by Izu et al. [24] addresses the case of 'sanitisable and deletable signatures'. However, they actually address the case of RS s and not SS s. In particular, in their scheme, a third party can decide whether a redaction is visible or not, but does not allow for any other alterations. We follow the nomenclature clarified by Bilzhause et al. [2], and thus classify the work by Izu et al. [24] as an RS. In contrast, SS s allow editing of signer-chosen blocks of signed messages by a semi-trusted entity named the sanitiser [4]. In particular, the sanitiser holds its own secret key and can derive new messages, along with the corresponding signatures, but cannot completely redact blocks. For example, if (and is admissible, i.e. modifiable), then the sanitiser can, e.g. derive a new signature on the message . Even though this seems to be off the limits, it turned out that this primitive has many real-life application scenarios, see, e.g. Bilzhause et al. [2]. After the initial ideas by Ateniese et al. [4], SS s also received a lot of attention in the recent past. Namely, the first thorough security model was given by Brzuska et al. [29] (later revised by Gong et al. [30]), which was later extended for multiple signers/sanitisers [31, 32], unlinkability (which means a derived signature cannot be linked to its original) [33-36], trapdoor SS s (where a signer can choose additional sanitisers after signature generation) [37, 38], non-interactive public-accountability (an outsider can determine which party is accountable for a given valid message/signature pair) [39], limiting the sanitiser to signer-chosen values [40-42], invisibility (meaning that an outsider cannot derive which parts of a message are sanitisable) [43-45] and the case of strongly unforgeable signatures [46]. All these extensions allow for additional use-cases of this primitive [2]. Additional related work is given in some recent surveys [2, 11, 47]. We stress that a slightly altered SS can be used to 'mimic' an RS by defining a special symbol to which the specific block is sanitised to, which then marks the block as 'redacted'. However, as shown by de Meer et al. [21], this has a negative impact on the privacy guarantees of the resulting scheme because the special symbol remains visible. For example, is clearly different from . We stress that our scheme supports both possibilities, i.e. visible and non-visible (transparent) redactions, adding additional freedom. 2 Preliminaries and notation The security parameter is denoted by . All algorithms implicitly take as an additional input. We write if a is assigned to the output of the deterministic algorithm A with input x. If an algorithm A is probabilistic, we write . If we want to make the random coins r used explicit, we write . Otherwise, we assume that they are drawn internally. An algorithm is efficient if it runs in probabilistic polynomial time (PPT) in the length of its input. For the remainder of this paper, all algorithms are PPT if not explicitly mentioned otherwise. Most algorithms may return a special error symbol , denoting an exception. If S is a set, we write to denote that a is chosen uniformly at random from S. For a message , is called a block and denotes the number of blocks in m. If m is clear from the context, it is dropped from . To shorten notation, we use (both a and b, , are always positive natural numbers) for the set . A function is negligible, if it vanishes faster than every inverse polynomial, i.e. , such that , . 2.1 Building blocks We now present our required building blocks. These include labelled IND-CCA2 secure public-key encryption schemes (), SS, PRF s, and aggregate signatures (). 2.1.1 Labelled public-key encryption schemes A labelled public-key encryption scheme allows to encrypt a message m using a given public key and label . In a nutshell, the given ciphertext leaks no information about the contained message, except its length, if the corresponding secret key is not known: Definition 1.(Labelled Public-Key Encryption): A labelled public-key encryption scheme consists of four algorithms , such that:. This algorithm outputs the public parameters of the scheme : (1)It is assumed that is an implicit input to all other algorithms.. On input , this algorithm outputs the key pair : (2). On input the public key , a message m, and a label , this algorithm outputs a ciphertext c : (3). On input , and a ciphertext c, this deterministic algorithm outputs a message m or : (4) IND-CCA2-Security: We need IND-CCA2 -security (and perfect correctness) for our construction to work. Note is some message space implicitly defined by and . Definition 2.(IND-CCA2-Security): A labelled encryption scheme is IND-CCA2-secure if for any PPT adversary there exists a negligible function such that: (5)The corresponding experiment is depicted in Fig. 1. A suitable instantiation is CS-encryption with labels [48]. Fig. 1Open in figure viewerPowerPoint IND-CCA2-security 2.1.2 Aggregate signatures Standard digital signatures allow the holder of a secret key to sign a message m, while with knowledge of the corresponding public key everyone can verify whether a given signature was actually endorsed by the signer, i.e. the holder of [49]. An aggregate signature scheme allows to aggregate multiple signatures into a single (short) value [9]. As a side contribution, we introduce a new framework for aggregate signatures, where one can also de-aggregate signatures, and a novel aggregate uniqueness definition. This was, to the best of our knowledge, only considered in a white-box fashion in the context of BGLS-signatures [9], but was never formally defined in a black-box way, or only in some ad-hoc fashion [50]. Definition 3.(Aggregate Signatures): An aggregate signature scheme with explicit de-aggregation consists of six algorithms such that:. This algorithm outputs the public parameters (6)and we assume that contains and is implicit input to all other algorithms.. On input , this algorithm outputs the key pair of a signer: (7). On input the secret key and a message m, this algorithm outputs a signature: (8). On input a set of public keys/messages and an aggregate signature , this algorithm outputs a decision bit : (9). On input a set of key/message tuples with corresponding aggregated signatures , where the sets are pair-wise disjoint, this algorithm outputs a new aggregate signature (or if ): (10)We note that Boneh et al. require that each message appears at most once [9]. However, there are also mitigation strategies [9, 51].. On input a set of public key/message tuples, along with an aggregate signature (protecting , being pair-wise disjoint), an additional set with aggregate signature , this algorithm outputs an a new aggregate signature for : (11) Clearly, an aggregate signature may also protect a single message, i.e. degenerate to a 'normal' signature. Moreover, we require the usual correctness properties to hold. Namely, honestly generated signatures verify, which must also be true for honestly generated aggregates. Likewise, honestly generated signatures stemming from de-aggregation must also verify. From a security perspective, we require existential unforgeability under chosen-message attacks (eUNF-CMA), a strict form of uniqueness, correctness, and that a third party cannot remove signatures from an aggregate if it does not know the signatures for the messages to be removed. We now formally define each of those properties. Unforgeability requires that an adversary cannot (except with negligible probability) come up with a signature for a message for which the adversary did not see any signature before. As usual, the adversary can adaptively query for signatures on messages of its own choice. Definition 4.( Unforgeability): We say a scheme is unforgeable, if for every PPT adversary , there exists a negligible function such that: (12)The corresponding experiment is depicted in Fig. 2. Uniqueness for aggregate signatures requires that for each set at most one signature can be found, even if all values can be adversarially generated. In contrast to Kuchta and Manulis [52], we require a slightly different uniqueness notion, i.e. the complete signature must be unique, and not only some part of it. Additionally, all values, but the public parameters, are explicitly generated by the adversary. Fig. 2Open in figure viewerPowerPoint unforgeability Definition 5.( Uniqueness): We say a scheme is unique if, for every PPT adversary , there exists a negligible function such that: (13)The corresponding experiment is depicted in Fig. 3. Remark 1.It should be obvious that uniqueness for aggregate signatures implies uniqueness for normal signatures. However, the converse is not true by the following argument: append a random bit for every generated aggregate, and remove it before proceeding with the other algorithms, appending another random bit once they are finished if the resulting signature is an aggregate. Fig. 3Open in figure viewerPowerPoint uniqueness Our final definition requires that an adversary cannot de-aggregate signatures from an aggregate signature if the adversary never saw a signature (or aggregate) for the messages for which it tries to remove the signature from the aggregate. This resembles the k -element extraction assumption by Boneh et al. [9, 53], but for general aggregate signatures. To find out whether the adversary actually wins, we need to explicitly disregard aggregates which the adversary could find using non-avoidable transitivity relationships and adversarial signatures added 'on top'. We, therefore, use the algorithm Closure which finds all 'trivial' relations. Definition 6.( No-Extraction): We say a scheme provides no-extraction if, for every PPT adversary , there exists a negligible function such that: (14)The corresponding experiment is depicted in Fig. 4, where the algorithm Closure is given in Algorithm 1 (see Fig. 5 ). We additionally require that, regardless of the message m, each signature is of constant size. This can easily be achieved by hashing the message m using a collision-resistant hash-function prior to signing. A suitable instantiation is BGLS-signatures [9], if one can enforce distinct messages (what we do). Fig. 4Open in figure viewerPowerPoint extraction secure Fig. 5Open in figure viewerPowerPoint Algorithm 1: Algorithm closure Definition 7.(Pseudo-Random Functions): A pseudo-random function PRF consists of two algorithms such that:. On input , this algorithm outputs a function key : (15)EvalPRF. On input a function key x and , this deterministic algorithm outputs : (16)Security: For security, it is required that PRF is actually pseudo-random. Definition 8.(PRF Pseudo-Randomness): A pseudo-random function PRF is called pseudo-random, if for any PPT adversary there exists a negligible function such that: (17)The corresponding experiment is depicted in Fig. 6, where is the set of all functions f mapping a value to another value . 2.1.3 Sanitisable signatures Subsequently, we restate the definitions of (standard) SS s [29, 43, 46]. To recap, an SS allows a semi-trusted third party, named the sanitiser, to alter signer-chosen blocks to arbitrary bit-strings. The sanitiser holds its own key-pair and can be held accountable if it sanitises a message. Fig. 6Open in figure viewerPowerPoint PRF pseudo-randomness The following framework is essentially the one given by Camenisch et al. [44], which is itself based on existing work [29]. However, some additional notation is required beforehand. The variable contains the set of indices of the modifiable blocks, as well as , denoting the total number of blocks in the message m. For example, let . Then, m must contain four blocks () and all but the third are admissible. Note, can be encoded in a length-invariant way by using a sequence of bits, e.g. (1, 1, 0, 1) for . The variable is a set containing pairs for those blocks that are modified, meaning that is replaced by . We use the shorthand notation to denote the result of this replacement, while means that is a valid modification instruction w.r.t. m and . Likewise, we use to denote that is a valid description of the admissible blocks w.r.t. m. Definition 9.(Sanitisable Signatures): A sanitisable signature scheme SS consists of eight PPT algorithms such that:. This algorithm generates public parameters: (18)We assume that is implicitly input to all other algorithms.. On input , this algorithm outputs a key pair of the signer: (19). On input , this algorithm outputs a key pair of the sanitiser: (20). On the input of the public key , , a message m and , this algorithm outputs a signature : (21). On input , , message m, and a signature , this deterministic algorithm outputs a decision : (22). On input , , message m, a signature , and , this algorithm outputs a sanitised signature : (23)ProofSS. On input , , a message m, , and a set of polynomially many additional signature/message pairs , this algorithm outputs a proof to pinpoint the accountable party for a given signature: (24). On input , message m, , and a proof , this algorithm outputs a decision : (25) Correctness was already specified by Brzuska et al. [29]. 2.1.4 s security definitions We now introduce the security properties required. These are the ones given by Beck et al. [43], but altered for the used notation, already incorporating the strong definitions by Krenn et al. [46], but a stronger notion of invisibility, where the adversary is now able to query arbitrary signatures to the sanitisation oracle. Moreover, we consider neither unlinkability nor non-interactive public-accountability, as it depends on the context whether these properties are required [43, 44]. However, non-interactive public-accountability is easy to achieve, e.g. by signing the resulting signature again [39]. Unforgeability: This definition requires that an adversary not having any secret keys is not able to produce any new valid signature on a message which it has never seen, even if has full oracle access. Definition 10.(Unforgeability): An SS is unforgeable if for any PPT adversary there exists a negligible function such that: (26)where the corresponding experiment is defined in Fig. 7. Immutability: This definition prohibits that an adversary can generate a verifying signature for a message not derivable from the signatures given by an honest signer, even if it can generate the sanitiser's key pair. Fig. 7Open in figure viewerPowerPoint unforgeability Definition 11.(Immutability): An SS is immutable if for any PPT adversary there exists a negligible function such that: (27)where the corresponding experiment is defined in Fig. 8. Privacy: This definition prohibits that an adversary can learn anything about sanitised parts. This is similar to the definition of standard encryption schemes. Fig. 8Open in figure viewerPowerPoint SS immutability Definition 12.(Privacy): An SS is private if for any PPT adversary there exists a negligible function such that: (28)where the corresponding experiment is defined in Fig. 9. Transparency: This definition prohibits that an adversary does not learn whether a signature was generated through or . We stress that the adversary cannot query signatures obtained by the -oracle to the -oracle to avoid trivial attacks. Fig. 9Open in figure viewerPowerPoint SS privacy Definition 13.(Transparency): An SS is transparent if for any PPT adversary there exists a negligible function such that: (29)where the corresponding experiment is defined in Fig. 10. Signer-Accountability: Signer-accountability prohibits that an adversary can generate a bogus proof that makes decide that the sanitiser is responsible for a given signature/message pair , but the sanitiser has never generated this pair. This is even true if the adversary can generate the signer's key pair. Fig. 10Open in figure viewerPowerPoint SS transparency Definition 14.(Signer-Accountability): An SS is signer-accountable if for any PPT adversary there exists a negligible function such that: (30)where the corresponding experiment is defined in Fig. 11. Sanitiser-accountability: Sanitiser-accountability prohibits that an adversary can generate a bogus signature/message pair that makes output a (honestly generated) generated proof which points to the signer, but has never been generated by the signer. This is even true, if the adversary can generate the sanitiser's key pair. Fig. 11Open in figure viewerPowerPoint SS signer-accountability Definition 15.(Sanitiser-Accountability): An SS is sanitiser-accountable if for any PPT adversary there exists a negligible function such that: (31)where the corresponding experiment is defined in Fig. 12. Invisibility: Depending on the context, an additional privacy guarantee may be required. In particular, invisibility prohibits that an outsider holding no secret keys can decide which parts of a message m are sanitisable. Note, the signing oracle can be simulated using the LoRADM -oracle and setting . The notation means that only those indices are admissible which are admissible in and . Fig. 12Open in figure viewerPowerPoint SS sanitiser-accountability We stress, however, that we introduce a slightly stronger variant than discussed in prior work [43]; Namely, we allow that the adversary can query any signature to , and not only the ones generated honestly. In particular, now only if the signature was created by one of the oracles, we enforce the restriction . We stress, however, that all strongly invisible constructions proposed so far are also unforgeable, and thus such a signature can never be generated by the adversary. Definition 16.(Invisibility): An SS is invisible if for any PPT adversary there exists a negligible function such that: (32)where the corresponding experiment is defined in Fig. 13. 3 Invisible redactable signatures We now introduce the new notion of invisible RSs. In contrast to standard RS s [28], such schemes hide which parts of a message can be redacted from outsiders. As in standard RS s anyone can redact – and one can thus trivially decide which blocks are redactable – we need to introduce a 'designated redactor', which is the only party able to decide this question. Thus, the designated redactor is the sanitiser in an RS. This is related to already existing definitions but in a different context [20, 54]. However, before we start defining and constructing our invisible RS, we need to settle some additional notation. Fig. 13Open in figure viewerPowerPoint SS invisibility Additional notation: In the following, let be some message, while denotes the admissible redactions, i.e. if , then can be redacted by the designated redactor. The variable denotes how a message m is to be modified, i.e. each block , , is removed from m to form the redacted message . In comparison to Derler et al. [28], however, we already define how those data-structures look like for preciseness. Additionally, as done for SS s, we use the shorthand notation