Klaus Stranacher et al.
• Compatibility: The signature scheme should be compatible with existing signature standards, such as XMLDSIG( W3C Recommendation, 2008) or XAdES( ETSI, 2010).
4. Examination
Redactable Signatures provide a cryptographic mechanism to allow redactors to apply modifications to signed messages without invalidating the original signature and have been introduced by Steinfeld et al.( 2001) and Johnson et al.( 2002). This mechanism has many applications in electronic healthcare as shown by Slamanig and Rass( 2010) and several other areas presented in Ateniese et al.( 2005). A main property of redactable signatures is that they only allow blacking certain parts of the signed data. To remove or replaced designated parts of the signed messages with an arbitrary string, Ateniese et al.( 2005) proposed Sanitizable Signatures. Sanitizable signatures can be seen as a small subset of redactable signatures, as they are basically redactable signatures where the replacement part is permanently exchanged.
Figure 1 shows an overview of about the most relevant redactable and sanitizable signature schemes proposed in the last years and their relation to each other. There exist also other schemes( not shown in Figure 1), but either they have been the basis for one of the mentioned schemes or they have been proven as insecure or not applicable. For instance, the authors of Yuen et al.( 2008) lacks on accountability of the proposed schema or Pöhls et al.( 2011) contains only minor updates on the property transparency( which is not of special interest for our use cases).
For our following examination we have looked initially on the redactable signature schemes proposed by Steinfeld et al.( 2001), Johnson et al.( 2002), Slamanig and Rass( 2010), Chang et al.( 2009) and Brzuska et al( 2010a). Right at the beginning of the examination we have figured out that all of these schemes do not support the specification of designated redactors. As this is one of the main requirements for the public sector data use cases, all of these schemes are not applicable for these scenarios. Therefore we omitted an in‐depth analysis of these schemes and concentrated on sanitizable signature schemes instead.
Figure 2 shows the sanitizable signature schemes we have chosen for our examination( highlighted in grey). A few sanitizable signature schemes we have skipped from our examination due to following reasons:
• Brzuska et al.( 2009) proposed a rigorous security model. This model has been incorporated by Canard and Jambert( 2010), which is examined below. Therefore we have skipped it from our analysis.
• Brzuska et al.( 2010b) proposed an update of Ateniese( 2005) which does not permit creating a link between different signatures over the same original message. This functionality is not of interest for the public sector use cases, so we have skipped this scheme.
Following sub‐sections give the examination of the chosen sanitizable signature schemes. In addition, we examine on the proposal of Slamanig and Hanser( 2013) on Blank Digital Signature, which incorporates the findings of redactable and sanitizable signatures.
4.1 Sanitizable signatures by Ateniese et al.( 2005)
The basic principle of redactable signatures bases upon commitments 2, which in turn build upon hashfunctions. This principle basis upon retaining the original hash values for redacted message blocks and to use them during the signature verification process( instead of calculating a new hash value over the redacted data). This process is described in Stranacher et al.( 2013) and in more detail in Johnson et al.( 2002) and Steinfeld et al.( 2001).
Ateniese et al.( 2006) proposed the first scheme for sanitizable signatures, where a designated redactor is able to modify designated parts of a signed message. Here the basic principle bases on chameleon hash‐functions instead of conventional hash‐functions for conventional signatures. Such chameleon hash‐functions are parameterized with the public key of the redactor. Because of the parameterization, the redactor is able to compute collisions. This means the redactor is able to generate messages, which lead to the same hash value
2 Commitments are often used in cryptographic protocols. They allow a committer to publish a commitment(= a value), which binds the
committer to a certain message, but without revealing it. If a verifier wants to check if the message is consistent with the commitment, the committer may open the commitment to reveal the message.
511