Flexible Redactable Signature Schemes for Trees

Extended Security Model and Construction

Henrich C. P¨ohls

1,3∗

, Kai Samelin

2,3†

, Hermann de Meer

2,3

and Joachim Posegga

1,3

IT-Security, University of Passau, Passau, Germany

Computer Networks and Computer Communication, University of Passau, Passau, Germany

Institute of IT-Security and Security-Law (ISL), University of Passau, Passau, Germany

Keywords:

Redactable Signatures, Malleable Signatures, Trees.

Abstract:

At ISPEC’12, Samelin et al. show that the redactable signature scheme introduced at VLDB’08 by Kundu

and Bertino does not always preserve the structural integrity of the tree signed. In particular, they show how

redaction of non-leaves promotes descendants and allows a third party to add new edges to the signed tree.

This alters the semantic meaning of the tree and is not acceptable in certain scenarios. We generalize the

model, such that it offers the signer the ﬂexibility to sign trees where every node is transparently redactable.

This includes intermediates nodes, i.e, to allow redacting a hierarchy, but also the tree’s root. We present a

provably secure construction, where this possibility is given, while remaining under explicit control of the

signer. Our security model is as strong as Brzuska et al.’s introduced at ACNS’10. We have implemented our

secure construction and present a detailed performance analysis.

1 INTRODUCTION

Trees are commonly used to organize data; XML is

just one of today’s most prominent examples. To pro-

tect these documents against unauthorized modiﬁca-

tions, digital signature algorithms like RSA (Rivest

et al., 1983) can be used. Using these digital signa-

tures schemes, two important properties of the data

are protected: integrity ofthe dataitself and veriﬁabil-

ity of the signer and hence the data’s origin. However,

in certain scenarios, it is desirable to remove parts of

a signed document without invalidating the protecting

signature. Additionally, the remaining documentshall

still retain the integrity protection and origin veriﬁa-

bility offered by the signature.

This could be simply achieved by requesting a

new signature from the signer with the parts removed

before generating the new signature. While this

roundtrip allows to satisfy the above requirements,

the “digital document sanitization problem”, as in-

troduced in (Miyazaki et al., 2003), adds another re-

quirement: the original signer shall not be involved

∗

Is funded by BMBF (FKZ:13N10966) and ANR as part

of the ReSCUeIT project (www.sichere-warenketten.de).

†

Is supported by “Regionale Wettbewerbsf¨ahigkeit und

Besch¨aftigung”, Bayern, 2007-2013 (EFRE) as part of the

SECBIT project. (http://www.secbit.de).

again. This is useful in cases where the signer is not

reachable or must not know that parts of a signed doc-

ument are passed to third parties. Redactable signa-

ture schemes (RSS) have been designed to fulﬁll these

needs, i.e., they allow that parts of a signed document

can be removed without invalidating the signature. As

standard signatures scheme like RSA, they allow to

detect unauthorized changes of the signed data. In

our case, the data is tree-structured, e.g., XML. More-

over, the tree’s integrity needs to include the structure,

i.e., the edges of the tree, as it carries information as

well (Liu et al., 2009).

We found that existing RSS for trees have two ma-

jor shortcomings: (1) they differ in the integrity pro-

tection they offer for the tree’s structure (structural

integrity protection) (Kundu and Bertino, 2009). (2)

they differ in the ﬂexibility of redactions they allow

(non-leaf redaction) (Brzuska et al., 2010a). We will

explain the shortcomings of existing schemes, using

the trees depicted in Fig. 1-4. Next, we will highlight

the importance of each problems using illustrating ex-

amples:

Intermediate Node Redaction. Information stored

in the tree’s nodes might need to be redacted. Con-

sider the tree depicted in Fig. 1, ignore the labels for

now. To remove the leaf n

, the node n

itself and the

113

Pöhls H., Samelin K., de Meer H. and Posegga J..

Flexible Redactable Signature Schemes for Trees - Extended Security Model and Construction.

DOI: 10.5220/0004038701130125

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 113-125

ISBN: 978-989-8565-24-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

edge e

3,4

is redacted from the tree T = (V, E). Al-

lowing leaf removal also allows to remove sub-trees,

i.e., by consecutive removal of ﬁrst n

and n

after-

wards (Brzuska et al., 2010a). However, schemes

only allowing for redaction of leaves fail to redact the

data stored in n

only. In other words, we want that

is redacted, while the nodes n

and n

are not

subject to redaction. The resulting tree is depicted

in Fig.2. To connect n

to the remaining tree, the

third party requires to add a new edge, which was not

present before, i.e., e

1,4

. However, e

1,4

is in the tran-

sitive closure of T, as shown in Fig. 3. Hence, a RSS

which is generally restricted to (consecutive) redac-

tion of leaf nodes does not cater for all use cases. The

scheme introduced by Kundu and Bertino does allow

redaction of intermediate nodes, while also claiming

that this ﬂexibility is a useful property (Kundu and

Bertino, 2009). However, this behavior may be prob-

lematic, as we will show next.

(0.3;0.7)

(0.6;0.1)

(0.8;0.4)

(0.9;0.2)

Figure 1: Original Tree T with Randomized Traversal Num-

bers.

(0.3;0.7)

(0.6;0.1)

(0.9;0.2)

Implicit edge

1,4

after

redacting n

Figure 2: Intermediate Node Redaction T

′

following

Kundu.

Figure 3: Transitive Closure of T implicitly adds e

1,4

Figure 4: Allow Relocation (e

3,4

) and Level-Promotion of

1,4

). A dotted line denotes an explicit edge.

Structural Integrity Protection. Imagine the in-

formation stored in a tree T is a chart showing the em-

Relocate n

using e

3,4

after

redacting n

Figure 5: Redaction of n

and Re-location of n

using e

2,4

ployees’ names as nodes and their position within the

companies hierarchy (Liu et al., 2009). Hence, pro-

tecting structural integrity is equal to protecting the

correctness of the employees’ hierarchical positions

in the given example. If one would only protect the

ancestor relationship of nodes in T, one would only

have a protection of all edges that are part of the tran-

sitive closure of T. This is depicted in Fig. 3. This

allows a third party to add edges to the tree T

′

that

were not present in T. Samelin et al. show that the

scheme of Kundu and Bertino (KB-Scheme) is subject

to this attack and name it “Level Promotion” (Samelin

et al., 2012). In particular, an employee can be “pro-

moted”. We will give a more detailed description of

the attack on the KB-Scheme here and want to see it

in the light of allowing ﬂexibility. However, it mo-

tivates the need for structural integrity protection. A

full description of the s is given in our extended nota-

tion in App. 4. Their scheme builds upon the idea that

a party who has all pre- and post-order traversal num-

bers (See Fig. 1) of all nodes contained in the tree T

is always able to correctly reconstruct T. They argue

that signing each node n

∈ T along with both traver-

sal numbers is enough to protect the tree’s integrity.

Their veriﬁcation checks all signatures on the

nodes individually — with an additional step: A ver-

iﬁer has to check if all nodes are structured correctly

using the traversal numbers (Kundu and Bertino,

2009). This leads to the problem that a veriﬁer is

not able to determine whether a given edge existed

in the original tree T, just if it could have existed.

Assume that a third party redacts n

from T, as de-

picted in Fig. 2. On veriﬁcation the new edge e

1,4

which has not explicitly been present in the origi-

nal tree T becomes valid. This implies, that the tree

= ({n

},{e

1,2

1,4

}) is valid.

To be more precise, let us compute the traver-

sal numbers for the example tree in Fig. 1. The

pre-order traversal of T will output (1, 2,3,4), while

the post-order traversal will output (4,3,2,1). To

make their scheme not leaking occurred redaction,

these traversal numbers are randomized in an order-

preserving manner, which does not have an impact

on the reconstruction algorithm. The randomization

step may transform them into (0.3,0.6, 0.8,0.9) and

(0.7,0.4, 0.2,0.1) resp. Hence, the node n

has a

structural position of ρ

= (0.3;0.7). For n

, n

and

SECRYPT2012-InternationalConferenceonSecurityandCryptography

114

this is done accordingly. We redact n

, an inter-

mediate node of n

, and n

. For the redacted tree in

Fig. 2, the traversal-numbers are still in the correct

order. Hence, the created signature veriﬁes.

The impact of attacks on the structural integrity

are signiﬁcant, as the structure of a tree carries part

of the document’s information (Liu et al., 2009).

One might argue that nesting of elements must ad-

here to a speciﬁc codiﬁed structure, i.e., XML-

Schemata. Henceforth, attacks like level-promotions

will be detected by any XML-Schema validator, if

redactions are not valid. However, whenever an el-

ement can contain itself, like hierarchically structured

lists of employees or hospital treatments composed of

treatments, grandchildren can be promoted to direct

children, without Kundu’s traversal-number based

validation-algorithm detecting it (Kundu and Bertino,

2009) and without breaking an XML-Schemata.

This destroys the structure of the tree and directly

impacts on the semantics, maybe resulting in a differ-

ent way on how a patient is treated in a hospital or

impacting on the rights that one might believe an em-

ployee can have (Liu et al., 2009). Obviously, this is

not acceptable in the generic case and could lead to

several other attack vectors, similar to the ones XPath

has introduced (Gottlob et al., 2003).

We conclude that the signer must explicitly sign

the edges which can be used by the sanitizer rather

then implicitly “signing” all of them. Currently, a

signer is not able to control this behavior, neither in

the KB-Scheme nor in other existing schemes.

State of the Art. Next, we provide an overview

of the state of the art. The general concept of RSS

were introduced at the same time by Johnson et

al. in (Johnson et al., 2002) and Steinfeld and Bull

in (Steinfeld and Bull, 2002). The latter approach

was named ”content extraction signatures”. A dif-

ferent but related concept are sanitizable signature

schemes (Ateniese et al., 2005; Brzuska et al., 2009).

Instead of only redaction of parts they allow to ar-

bitrarily modify parts of the signed document. In

this work, we concentrate on redactable signatures for

trees. We take into account solutions that allow ﬂexi-

ble redaction or offer full protection of structural- and

content-integrity.

A recent work is Ahn et al. who cater for a spe-

cial sub-case of redaction called ”quoting” (Ahn et al.,

2011). Quoting is not as ﬂexible as redacting as it

resembles “content extraction” by allowing quoting

consecutive parts of a list. Hence, Ahn et al.’s ap-

proach is different and does not target trees.

Also recently, Camacho and Hevia have showed

how to build more efﬁcient transitive signatures for

directed trees (Camacho and Hevia, 2012). This idea

from Rivest and Micali (Micali and Rivest, 2002),

however, focuses on how to authenticate single edges

within a signed tree T.

Kundu and Bertino were the ﬁrst to develop a RSS

which addresses the speciﬁc needs of tree-structured

documents (Kundu and Bertino, 2008; Kundu and

Bertino, 2009). Brzuska et al. already broke the KB-

Scheme and showed that it does not hide redactions,

based on a probabilistic attack (Brzuska et al., 2010a).

One may argue that Kundu and Bertino do not see

their scheme in the context of RSS, since they just

want to prohibit “leakage” due to structural informa-

tion (Kundu and Bertino, 2009).

The solution by Brzuska et al. only allows redac-

tions of leaves (Brzuska et al., 2010a). Another

scheme for trees, by Wu et al. is also not ﬂexible (Wu

et al., 2010). Moreover, it relies on the Merkle-Hash-

Tree-Technique with standard cryptographic hashes

like SHA-512. Hence, their scheme does neither hide

redactions nor preserve privacy (Kundu and Bertino,

2008; Kundu and Bertino, 2009).

Table 1: Existing RSS Schemes’ Capabilities.

Redaction Structural Invisibility

of Non-leaves Integrity of Redaction

Kundu Yes, No, implicit No.

and Bertino allowed level-promotion

Brzuska et al. No. Yes. Yes.

Wu et al. No. Yes. No.

Comacho Yes, allows all different

and Hevia allowed transitive edges goal

Ahn et al. No, only Yes. Yes, stronger

quoting context-hiding

We discuss this in detail in Sect.2

Other schemes do not explicitly consider tree-

structured data, even though they mention XML as an

application: In (P¨ohls et al., 2011) existing sanitizable

and redactable signature schemes are integrated into

XML Signatures, extending the work done in (Tan

and Deng, 2009). Neither the approach of Tan et al.,

nor the work of P

ohls et al. do secure trees, since

neither of them caters explicitly for the structure.

Our Contribution and Outline. Our contribution

is twofold and motivated by a lack of ﬂexibility or

integrity protection of many existing RSS for trees:

Either no redaction of intermediate nodes is allowed

or, if allowed, the structural integrity protection is

relaxed to the transitive closure of the trees. As

shown, protecting transitive closures, i.e., ancestor-

descendant relations, is a weaker structural integrity

protection which leads to semantic attacks which go

unnoticed by the integrity protection.

Our ﬁrst contribution is the rigid security model

for a ﬂexible RSS for trees offering full structural

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

115

integrity protection. We follow Brzuska et al.’s se-

curity requirements for RSS for trees with leaf-only

redaction (Brzuska et al., 2010a). In Sect. 2, we

give precise, game-based deﬁnitions of the secu-

rity properties: unforgeability, privacy, and trans-

parency (Brzuska et al., 2010a). Our ﬂexibility is al-

lowing the signer to partially weaken the structural

integrity protection at his leisure. Hence, the security

requirements need to additionally capture the signer’s

ﬂexibility to allow redaction of any node. This al-

lows level promotions due to re-locations of speci-

ﬁed sub-trees, which resembles the implicit possibil-

ity of previous schemes. In particular, our signing

algorithm adds an additional edge to the tree to al-

low re-locations. A verifying party needs to decide

which edge to use. This allows the sanitizer to main-

tain transparency after occurred modiﬁcations. On

the other hand, the signer remains in charge when

describing how an occurred redaction is hidden by

re-locating the sub-tree. This leads to signer explic-

itly prohibiting the redaction of nodes individually, as

the signer must explicitly sign an edge for re-location.

Additionally, in our construction the signer controls

the protection of the order of siblings. Hence, our

scheme is capable of signing unordered trees. Our

ﬂexibility to redact an node of the tree does include in

its generality the tree’s root. Without loss of security,

the signer can add an annotation to the root to prohibit

redacting the roots by adapting the signing and veri-

ﬁcation algorithms. In particular, they must check, if

the annotated root still exists.

Our second contribution is our secure construction

presented in Sect. 3, including a performance mea-

surement. Our construction is based upon a collision-

resistant one-way accumulator (Benaloh and Mare,

1993; Bari´c and Pﬁtzmann, 1997) in combina-

tion with the Merkle-Hash-Tree-Technique (Merkle,

1989). Employing the Merkle-Hash-Tree-Technique

enforces the protection of structural integrity. Hence,

our scheme fulﬁlls the deﬁned security requirements

using only standard cryptographic primitives.

We conclude our work in Sect. 4. The appendix

contains the security proofs, the existing notations,

the security model from (Brzuska et al., 2010a) and

the KB-Scheme (Kundu and Bertino, 2009).

2 EXTENDED SECURITY

MODEL FOR RSS FOR TREES

We will use the following notation throughout this

paper: The root, usually n

, is the only node with-

out a parent. Nodes are addressed by n

. With c

we refer to all the content of node n

, which is an

additional information that might be associated with

a node, i.e., data, element name and so forth. The

ﬁrst rigid model for secure RSS for trees was given

in (Brzuska et al., 2010a). Brzuska et al. formalized

the requirements for redactable signatures for tree-

structured documents. Their model only allows re-

moving leaves; sequentially running their leaf-cutting

algorithm only removes complete sub-trees. How-

ever, the model is restrictive with the respect, that

it only allows redacting leaves of the tree. (Brzuska

et al., 2010a) We restate their model and review it

in App. 4. We will now rework the Brzuska et al.’s

model to securely allow the possibility to redact any

node. After we have stated our new security model,

we will shortly compare the new model to Brzuska et

al.’s and Ahn et al.’s (Ahn et al., 2012; Brzuska et al.,

2010a). Keep in mind, that our ﬂexibility allows to

work on ordered and un-ordered trees, and generally

we also allow redacting a tree’s root.

Flexible Redactable Signature Scheme

for Trees. A RSS R SS

for trees con-

sists of the four efﬁcient (PPT)

algorithms:

R SS

:= (KeyGen,Sign,Verify,Modify). Note, all

algorithms may output ⊥ in case of an error.

KeyGen. The algorithm KeyGen outputs the pub-

lic and private key of the signer, i.e., (pk,sk) ←

KeyGen(1

), λ being the security parameter.

Sign. On input of the secret key sk, the tree T and

ADM the algorithm Sign outputs the signature σ

ADM controls what changes by Modify are admis-

sible. In detail, ADM is the set containing all

signed edges, including the ones where a sub-tree

can be re-located to. In particular, (n

) ∈ ADM,

iff the edge (n

) is to be signed. These edges

cannot be derived from T alone. For simplicity,

we assume that ADM is always correctly deriv-

able from (T,σ

). The output: (T,σ

, ADM) ←

Sign(sk,T, ADM).

Verify. On input of the public key pk, the tree T and

the signature σ

the algorithm Verify outputs a bit

d ∈ {0,1} indicating the correctness of the sig-

nature σ

, w.r.t. pk, protecting the tree T. The

output: d ← Verify(pk,T,σ

Modify. The algorithm Modify takes as input the

signer’s public key pk, the tree T, the signature

and ADM of T, and an instruction MOD. MOD

contains the actual change to be made: redact a

leaf n

, relocate a sub-tree T

, distribute a sub-tree

without the original root, or prohibit relocating

Probabilistic polynomial-time (PPT).

SECRYPT2012-InternationalConferenceonSecurityandCryptography

116

a sub-tree T

. A modiﬁcation of T w.r.t. MOD is

denoted as T ⊗ MOD.

Apart from potentially changing T, the old ADM

must be adjusted: In particular, if a node n

redacted, the edge to its father needs to be re-

moved as well. Moreover, if there exists a sub-

tree which could be relocated under the redacted

node, the correspondingedges need to be removed

from ADM as well. A modiﬁcation of ADM w.r.t.

MOD will be denoted as ADM ⊗ MOD. The alter-

ation of ADM is crucial to maintain privacy and

transparency. Note, running Modify multiple times

is the same as a MOD containing more than one

change to be made. The output: (T

′

,σ

′

, ADM

′

) ←

Modify(pk,T, σ

, ADM, MOD).

Correctness. Genuinely signed or signed and mod-

iﬁed trees are considered valid by the veriﬁcation al-

gorithm. We use span

⊢

(T, ADM) to denote all valid

trees that can be generated from a signed tree T by

running Modify never, once or more times, with a

MOD which respects ADM. Hence, we require all el-

ements of span

⊢

(T, ADM) have valid signatures, iff T

has a valid signature. Note: Prohibiting additional re-

locations is allowed in our scheme. We will always

explicitly denote ADM in our algorithms for clarity.

The Extended Security Model. As discussed be-

fore, Ahn et al.’s framework has a stronger notation

for privacy than Brzuska et al. Our scheme is as se-

cure as Brzuska et al.’s. We extend this model to cater

for the ﬂexibility of intermediate node redaction and

re-locations, so the security properties must hold also

when the signer is given the new freedom to allow any

node being removed.

1. Unforgeability: No one should be able to com-

pute a valid signature on a tree T

∗

for pk out-

side span

⊢

(T, ADM) without access to the cor-

responding secret key sk. This is analogous to

the standard unforgeability requirement for signa-

ture schemes, as already noted in (Brzuska et al.,

2010a). A scheme RSS is unforgeable, iff for any

efﬁcient (PPT) adversary A, the probability that

the game depicted in Fig. 6 returns 1, is negligi-

ble (as a function of λ). In the game the attacker

is given access to a signature generating oracle

Sign(sk,·,·) and the public key pk, but not the se-

cret key. The attacker wins if he has a valid signa-

ture for T

∗

, which is a tree for which he has never

queried the oracle directly, nor can he generate T

∗

by modifying a previously queried signed tree.

2. Privacy: No one should be able to gain any

knowledgeabout the unmodiﬁed tree without hav-

Experiment Unforgeability

RSS

(λ)

(pk,sk) ← KeyGen(1

)

∗

,σ

∗

) ← A

Sign(sk,·,·)

(pk)

let i = 1,2,..., q index the queries

return 1 iff

Verify(pk,T

∗

,σ

∗

) = 1 and

for all 1 ≤ i ≤ q, T

∗

/∈ span

⊢

, ADM

)

Figure 6: Game for Unforgeability.

ing access to it. This is similar to the stan-

dard indistinguishability notation for encryption

schemes (Brzuska et al., 2010a). A scheme RSS

is private, iff for any efﬁcient (PPT) adversary A,

the probability that the game shown in Fig. 7 re-

turns 1, is negligibly close to

(as a function of

λ). In the game the attacker is given a signature

generating oracle and the public key. He con-

trols two inputs to the LoRModify oracle (Fig. 8)

and also how they need to be modiﬁed to result

in the same tree. The oracle modiﬁes both of

them into the same tree and outputs one of them

to the attacker. The attacker needs to identify the

used input to win. So the attacker controls all the

inputs T

j,0

, ADM

j,0

, MOD

j,0

j,1

, ADM

j,1

, MOD

j,1

but need to guess which of the (now modiﬁed)

trees is returned. Note, that the two inputs need

to be modiﬁed such that they are equal w.r.t. T, σ

and also ADM.

3. Transparency: A party who receives a signed

tree T cannot tell whether he received a freshly

signed tree or a tree which has been created via

Modify (Brzuska et al., 2010a). We say that a

scheme RSS is transparent, if for any efﬁcient

(PPT) adversary A, the probability that the game

shown in Fig. 9 returns 1, is negligibly close to

(as a function of λ). In the game for transparency,

the attacker has access to the public key and a sig-

nature generation oracle. He controls the input to

the ModifyOrSign oracle (Fig. 10). Hence, he can

choose the original tree T with admissible modi-

ﬁcations ADM and by MOD also the modiﬁed tree.

Note, MOD can contain several modiﬁcation in-

structions. To win, the attacker has to guess if

the signed outputted T

′

was created through the

modiﬁcation algorithm from a signed T (b = 0)

or through modifying T and ADM before signing

them (b = 1).

Separation of Security Properties. The implica-

tions and separations of Brzuska et al. do not change:

Unforgeability is independent; Transparency ⇒ Pri-

vacy; Privacy ; Transparency. We omit the proofs

in this paper; they are essentially the same as given

in (Brzuska et al., 2010a).

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

117

Experiment Privacy

RSS

(λ)

(pk,sk) ← KeyGen(1

)

← {0,1}

d ← A

Sign(sk,·,·),LoRModify(·,·,·,·,·,·,sk,b)

(pk)

return 1 iff b = d

Figure 7: Game for Privacy.

Oracle LoRModify(T

j,0

, ADM

j,0

, MOD

j,0

j,1

, ADM

j,1

, MOD

j,1

,sk,b)

if MOD

j,0

) 6= MOD

j,1

) return ⊥

j,0

,σ

T,0

, ADM

j,0

) ← Sign(sk,T

j,0

, ADM

j,0

)

j,1

,σ

T,1

, ADM

j,1

) ← Sign(sk,T

j,1

, ADM

j,1

)

′

j,0

,σ

′

T,0

, ADM

′

j,0

) ← Modify(pk,T

j,0

,σ

T,0

, ADM

j,0

MOD

j,0

)

′

j,1

,σ

′

T,1

, ADM

′

j,1

) ← Modify(pk,T

j,1

,σ

T,1

, ADM

j,1

MOD

j,1

)

if ADM

′

j,0

6= ADM

′

j,1

abort returning ⊥

return (T

′

j,b

,σ

′

T,b

, ADM

′

j,b

)

Figure 8: LoRModify Oracle (from Privacy).

Experiment Transparency

RSS

(λ)

(pk,sk) ← KeyGen(1

)

← {0,1}

d ← A

Sign(sk,·,·),ModifyOrSign(·,·,·,sk,b)

(pk)

return 1 iff b = d

Figure 9: Game for Transparency.

Oracle ModifyOrSign(T, ADM, MOD, sk,b)

if MOD /∈ ADM, return ⊥

if b = 0:(T, σ

, ADM) ← Sign(sk,T, ADM),

′

,σ

′

, ADM

′

) ← Modify(pk, T,σ

, ADM, MOD)

if b = 1:T

′

← T ⊗ MOD , ADM

′

← ADM ⊗ MOD

′

,σ

′

, ADM

′

) ← Sign(sk, T

′

, ADM

′

)

return (T

′

,σ

′

, ADM

′

Figure 10: ModifyOrSign Oracle (from Transparency).

Security of our Model. Our security model offers

the same security as Brzuska et al.’s: unforgeability,

privacy and transparency notations (Brzuska et al.,

2010a).

The security model of Ahn et al.’s important

work (Ahn et al., 2012) introduces “strong context-

hiding” as a very strong privacy notation. Compared

to Brzuska et al.’s privacy notation, context-hiding

will evenhide the fact “whether it [(T

′

,σ

′

, ADM

′

)] was

derived from a given signed message” when the at-

tacker has access to a real original message and sig-

nature, i.e., (T, σ, ADM) and the secret key sk. This is

considered a very strong privacy property by (Boneh

and Freeman, 2011) and we do not achieve this, as we

do not achieve unlinkability (Brzuska et al., 2010b).

However, in some use cases this strong privacy no-

tation is not needed, since the existing side-channel

information already links two signatures, i.e., non-

personal governmental datasets being released to fos-

ter Open Government initiatives.

Redacting any Node. To show the full ﬂexibility of

allowing any node to be redactable we do treat the

tree’s root as a redactable node. Note, redacting the

root, as shown in Fig. 11 (3c), is possible. In the

example (3c) n

transparently becomes the new root.

However, in general redacting, the root might leave

one with a forest of trees, i.e., two or more uncon-

nected sub-trees. Each sub-tree is than a valid signed

sub-tree, however the connection between the sub-

trees is lost. Iff the signer provided re-location edges

that allow to connect the sub-trees into one tree then

this is a possible option after having redacted the root.

Adding signer control, to prohibit this is straight

forward: During signing we annotate n

as root and

additionally indicate that redacting the root is prohib-

ited. Complementary, the verify algorithm will check

for that indicator and, iff present, it will verify, if one

node with the annotation is present in the root node

received.

3 OUR NEW SECURE FLEXIBLE

SCHEME

Merkle-hash-Tree (M H ). Our construction fol-

lows the ideas of the Merkle-Hash-Tree (Merkle,

1989): We use the following notation for the recur-

sively constructed extended version, which works on

arbitrary trees with content. We denote a concate-

nation of two strings x,y with x||y. The extended

Merkle-Hash M H is calculated as: M H (x) =

H (H (c

)||M H (x

)||...||M H (x

)), where H is a

cryptographic hash function like SHA-512, c

the

content of the node x, x

a child of x, and n the num-

ber of children of x. M H (n

)’s output, called root

hash, depends on all nodes and on the right order of

the siblings. Hence, signing the root hash protects the

integrity of the nodes in an ordered tree and the tree’s

structural integrity. Obviously, this technique does

not allow to hash unordered trees; an altered order

will most likely cause a different digest value. One

may argue that annotating an unordered sub-tree is

sufﬁcient. However, this does not allow to rearrange

items and hence enforces a given order, which may

not be wanted in certain use-cases, e.g., if invoices

are signed. Hence, an unsorted list or tree should be

signed and veriﬁed as such. A more detailed analy-

sis of the Merkle-Hash-Tree is given in (Kundu and

Bertino, 2009), which also gives an introduction on

the possible inference attacks on non-privateschemes.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

118

Accumulating Hash-functions (AH ). One-way

accumulators have been introduced by in (Benaloh

and Mare, 1993). The basic idea is to construct a

collision- and preimage-resistant family of functions

, where ∀AH

∈ AH

: X

× Y

→ X

which

members fulﬁll an additional property:

∀k ∈ K : ∀x ∈ X : ∀y

∈ Y :

(AH

(x,y

),y

) = AH

(AH

(x,y

),y

)

(1)

named quasi-commutativity. We just need the basic

operations of an accumulator, e.g., no dynamic up-

dates or revokation techniques are required. A ba-

sic accumulator consists of three efﬁcient algorithms,

i.e., AH := {KeyGen,Hash,Check}:

KeyGen. Outputs the system parameters prm on

input of a security parameter λ, i.e., prm ←

KeyGen(1

)

Hash. Outputs the accumulated digest d along with

the set of witnesses W = {w

,... , w

}, i.e.,

(d, W ) ← Hash(prm,I ), on input of a set of to-

be-digested items I = {v

,... , v

} and the param-

eters prm. The accumulatation of I = {v

;...;v

}

is denoted as AH

(prm,{v

;...;v

}), where k ∈

K. Each witnesses w

ℓ

in W allows to prove the

membership of the corresponding value v

ℓ

Check. Outputs a bit d ∈ {0, 1} indicating if a given

value v

was accumulated into the digest d with

respect to prm and a witness w

. In particular,b ←

Check(prm, v

,d,w

)

We require the usual soundness requirements (Bari´c

and Pﬁtzmann, 1997) to hold, while the concrete in-

stantiation of an accumulator must be strongly one-

way (Bari´c and Pﬁtzmann, 1997). In particular, an

outsider should not be able to guess members, to de-

cide how many additional values have been accumu-

lated, to forge a digest or to generate membership

proofs. The formal descriptions of our needs are rel-

egated to App. 4. Additional information about accu-

mulators can be found in (Bari´c and Pﬁtzmann, 1997;

Benaloh and Mare, 1993; Camenisch and Lysyan-

skaya, 2002). To maintain transparency, we require

that any output of AH is distributed uniformly over

the co-domain of the hash-function. An accumula-

tor not fulﬁlling these requirements has been pro-

posed by Nyberg in (Nyberg, 1996); the underlying

Bloom-Filter can be attacked by probabilistic meth-

ods and therefore leaks the amount of members. This

is not acceptable. To prohibit recalculations of a di-

gest, we require a nonce as the seed. This has al-

ready been proposed in (Nyberg, 1996) and (Bari´c

and Pﬁtzmann, 1997). The idea to use accumulat-

ing hashes has already been proposed by Kundu and

Bertino in (Kundu and Bertino, 2008). However, they

state that accumulators are not able to achieve the de-

sired functionality. We will show that they are sufﬁ-

cient by giving a concrete construction.

The Construction. We want to allow explicit re-

location of sub-trees. If a non-leaf is subject to redac-

tion, all sub-trees of the node need to be relocated. If

this is possible and what their new ancestor will be

must be under the sole control of the signer. We will

ﬁrst sketch our solution, and give a concrete instanti-

ation and the algorithms afterwards. Our re-location

deﬁnition does not require to delete the intermediate

node. This behaviour will be discussed, after the con-

struction has been introduced.

Sketch. Our solution requires that the signer repli-

cates all re-locatable nodes and the underlying sub-

trees to all the locations where a sanitizer is allowed to

relocate the sub-tree to. The replicas of the nodes are

implicitly used just to produce the re-locatable edges

as our algorithms all work on nodes. Each additional

edge is also noted in ADM. In Fig. 11(1+2), the dot-

ted area corresponds to the sub-tree n

and n

under

the re-locatable n

. The sub-tree n

and n

must be

re-located as a whole. The dashed curved edge e

1,3

corresponds to such an additional edge contained in

ADM to indicate the allowed re-location of n

as di-

rect child of n

. All algorithms work on nodes not on

edges, hence always imagine one builds all allowed

re-locations by replicating nodes before one runs an

algorithm like MODIFY, as depicted in Fig. 11(1).

We allow to re-locate a re-locatable sub-tree with-

out redaction of nodes. We prohibit simple copy

attacks, i.e., leaving a relocated sub-tree T

in two

locations, because each node n

gets an associated

unique nonce r

. The whole tree gets signed as in

the standard Merkle-Hash-Tree, with one notable ex-

ception: Instead of using a standard hash like SHA-

512, we use an accumulator which allows the san-

itizer to remove values without changing the digest

value. To remove parts the sanitizer is removing the

redacted elements and no longer provides the corre-

sponding witnesses of the redacted elements. The

quasi-commutative behavior of the accumulators also

allows us to sign unordered trees; it does not matter

in what order the members are checked. However, if

ordered trees are present, the ordering between sib-

lings has to be explicitly signed. To allow distribu-

tion of sub-trees without the root, we sign each node’s

Merkle-Hash individually using a standard signature

scheme. As said, redaction is therefore a simple re-

moval of the nodes and the corresponding witnesses.

Re-location is similar: Apply the necessary changes

to T. Additionally, a sanitizer can prohibit consec-

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

119

utive re-locations, this could be seen equal to con-

secutive sanitization control (Miyazaki et al., 2005).

To prohibit further re-location one removes the cor-

responding witnesses. This implies that ADM is ad-

justed accordingly.

Veriﬁcation: For a node x check, if x’s content, x

′

children and x’s order to other siblings is contained in

x’s Merkle-Hash. This is done for each node. A seed

is used to prohibit simple recalculation attacks (Bari´c

and Pﬁtzmann, 1997). To sign the ordering between

siblings, we sign the “left-of” relation, as already used

and proposed in (Brzuska et al., 2010a), (Chang et al.,

2009) and (Samelin et al., 2012).

The Algorithmic Description. We assume that wit-

nesses are generated, distributed and used to verify

memberships, and, of course, removed from distribu-

tion, if the corresponding values are removed. This

does not introduce any security problems, since the

sanitizer could give away the original tree anyway.

How the witnesses are generated depends on the ac-

tual accumulator used and is therefore omitted.

KeyGen(λ):

//Choose a suitable accumulator

Choose AH

∈ AH

Generate prm ← AHKeyGen

(λ)

//Choose an unforgeable signature scheme Π

Choose Π and set (pk

,sk

) ← Π.AKeyGen(λ)

//Return all generated material

return (pk = (pk

, prm,AH

,Π),sk = (sk

))

Expand(T, ADM):

For all edges e

∈ ADM

Replicate the sub-tree underneath the

node addressed by e

to the designated position

this must be done bottom-up

Note: This implies that r

are copied as well.

Return this expanded tree, denoted as Ω

Sign(sk,T, ADM):

For each node n

∈ T:

← {0,1}

If r

has already been drawn, draw again

Expanded tree Ω ← Expand(T, ADM)

For each node x ∈ Ω:

Draw a random seed s

← {0,1}

Let x

denote a children of x

If the tree is un-ordered:

= M H (x) ← AH

(prm,{s

||r

;

M H (x

);...;M H (x

)})

← Π.ASign(sk

||unordered)

Else: //ordered tree

= M H (x) ← AH

(prm,{s

||r

;

M H (x

);...;M H (x

);Ξ

})

// Build Ξ

, the set of

// all “left-of” relations of x

= {r

||r

| 0 < i < j ≤ n}

← Π.ASign(sk

||ordered)

// Build list of all witnesses:

Let W = {w

∈ Ω}.

return σ

= ({σ

}

∈Ω

,W , ADM)

Modify(pk,T, σ

, ADM, MOD):

use Verify to verify the tree T

Expanded tree Ω ← Expand(T, ADM)

Case 1: Redact node n

//1. remove all n

(incl. replicas) from Ω:

Set Ω

′

← Ω\ n

//2. remove the node n

from T:

Set T

′

← T \ n

return σ

′

= (T

′

,{σ

}

∈Ω

′

,{w

}

∈Ω

′

, ADM)

Case 2: Share sub-tree T

, where n

/∈ T

return σ

′

= (T

,{σ

}

∈T

,{w

}

∈T

, ADM)

Case 3: Re-locate T

Set T

′

← MOD(T)

return σ

′

= (T

′

,{σ

}

∈Ω

,{w

}

∈Ω

, ADM)

Case 4: Remove re-location edge e

Set ADM

′

← ADM \e

Expanded tree Ω

′

← Expand(T, ADM

′

)

//Note: This expansion is done with the modiﬁed

ADM

′

return σ

′

= (T, {σ

}

∈Ω

′

,{w

}

∈Ω

′

, ADM

′

)

Verify(pk,T,σ

Check if each r

∈ T is unique.

For each node x ∈ T:

Let the value protected by σ

be d

Let d ← Check(prm, c

||r

)

If d = 0, return 0

For all children c

of c do:

let the value protected by σ

be d

//Note: checks if children are signed

Let d ← Check(prm, d

)

If d = 0, return 0

If σ

= d

||ordered:

//Is every “left-of”-relation signed?

//Note: just linearly many checks

For all 0 < i < n:

d ← Check(prm, r

||r

i+1

x,x+1

)

If d = 0, return 0

return 1

Arguably, allowing re-location without redaction

may also be too much freedom. However, it allows

the signer to allow a ﬂattening of hierarchies, i.e., to

remove the hierarchical ordering of treatments in a

patients record. A third party can prohibit consecu-

tive re-locations by removing the associated witnesses

from distribution. An example of an resulting tree is

depicted in Fig.11(3a). Note, the algorithm Modify

actually works by removing the duplicated nodes, and

hence removes the allowed edge e

1,3

Runtime Complexity. For generation of σ

, the

sibling’s order requires

n(n−1)

hashing steps. All

other steps require to touch the nodes only once. Con-

sequently, the runtime approximation of our signing

algorithm is linear in the number of nodes, while be-

SECRYPT2012-InternationalConferenceonSecurityandCryptography

120

(1)

Additional

edge signed

and part of

ADM

re-locatable

sub-tree

(2)

Allowed

re-location

(3)

(3a)

Allowed

re-location

(3b)

(3c)

(3d)

(3e)

(3f)

Figure 11: (1) Expanded tree with duplicates for all possible re-locations of sub-trees, (2) Tree with allowed Level-Promotion

of n

, (3) Examples of valid trees with 3 or 4 nodes after: (3a) redact re-locatability, (3b) redact n

, (3c) redact root, (3d)

relocate-only n

, (3e) re-locate n

and redact n

, (3f) redact n

and level-promote n

Table 2: Median Runtime; in ms.

Generation of σ Veriﬁcation of σ

Nodes

10 100 1,000 10 100 1,000

Ordered 276 6,715 57,691 26 251 2,572

Unordered 103 599 5,527 21 188 1,820

SHA-512 4 13 40 4 13 40

ing quadratic in the number of siblings. Redacting

is just removing values. Veriﬁcation is O(|V|), since

a veriﬁer has to check, if each digest is contained

in its parent’s digest and if the content has been di-

gested. Checking the order of siblings can be done in

linear time due to the transitive behaviour. We have

implemented our scheme to demonstrate the practi-

cal usability. As the accumulator, we have choosen

the original construction (Benaloh and Mare, 1993).

Tests were performed on a Lenovo Thinkpad T61 with

an Intel T8300 Dual Core @

2.40

GHz and

GiB

of RAM. The OS was Ubuntu Version 10.04 LTS

(64 Bit) with Java-Framework

1.6.0 26-b03

(Open-

JDK). Source code will be made available upon re-

quest. We took the median of 10 runs. We measured

trees with unordered siblings and one with ordered

siblings. Time for generation of keys for the hash is

included. We excluded the time for creating the re-

quired key pairs; it becomes negligible in terms of

the performance for large n. On digest calculation

we store all intermediate results in RAM to avoid any

disk access impact.

As shown, our construction is useable, but be-

comes slow for large branching factors. The ad-

vanced features come at a price; our scheme is con-

siderably slower than a standard hash like SHA-512.

Signatures are more often veriﬁed than generated, so

the overhead for veriﬁcation has a greater impact.

All other provable secure and transparent schemes,

i.e., (Brzuska et al., 2010a) and (Chang et al., 2009),

have the same complexity and therefore just differ by

a constant factor, but do not provide a performance

analysis on real data.

Security of the Construction. Our scheme is un-

forgeable, private and transparent. Assuming AH

is collision-resistant and one-way, and the signature

scheme Π is strongly unforgeable, our scheme is un-

forgeable. Assuming AH to always output uniformly

distributed digests and the digests are therefore in-

distinguishable from random numbers, our scheme

is transparent and also private. Note, it is enough

to show that Transparency and Unforgeability hold

because Transparency =⇒ Privacy (Brzuska et al.,

2010a). The formal proofs are relegated to App. 4 for

readability.

4 CONCLUSIONS

The lack of ﬂexibility for redacting any node of a tree

and the lack of signer control motivated the construc-

tion of a new RSS. The scheme can sign ordered and

unordered trees. It allows the sanitizer to redact non-

leaf nodes and keeps the redaction transparent by al-

lowing level-promotions, but level promotions are un-

der the signer’s sole control. Keeping the signer in

control gives him the decision for which intermedi-

ate nodes he wants to weaken the structural integrity

protection and allow a re-location, but allows trans-

parency.

Furthermore, our construction is the ﬁrst which al-

lows a signer to explicitly sign ordered and unordered

trees. How to sign trees where both, ordered and

unordered siblings, are present is still an open prob-

lem. We allow re-locations without redaction so that

a signer can allow a sanitizer to redact the hierarchy

from a sub-tree which contains hierarchically struc-

tured, but otherwise equal, nodes. In these cases, our

scheme allows redacting just the structure. Such a vi-

olation of structural integrity requires explicit conﬁr-

mation by the signer.

Allowing the ﬂexibility required us to give an ex-

tended security model. Finally, we have proven our

scheme using the extended security model. The per-

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

121

formance analysis demonstrates that the scheme is

considerably slower than SHA-512. It therefore re-

mains an open problem how to construct transparent

schemes with an overhead of O(n) and how to mix

ordered and unordered trees.

REFERENCES

Ahn, J. H., Boneh, D., Camenisch, J., Hohenberger, S., She-

lat, A., and Waters, B. (2011). Computing on au-

thenticated data. Cryptology ePrint Archive, Report

2011/096. http://eprint.iacr.org/.

Ahn, J. H., Boneh, D., Camenisch, J., Hohenberger, S., She-

lat, A., and Waters, B. (2012). Computing on authen-

ticated data. In Cramer, R., editor, TCC, volume 7194

of Lecture Notes in Computer Science, pages 1–20.

Springer.

Ateniese, G., Chou, D. H., de Medeiros, B., and Tsudik, G.

(2005). Sanitizable Signatures. In ESORICS, pages

159–177.

Bari´c, N. and Pﬁtzmann, B. (1997). Collision-free accumu-

lators and fail-stop signature schemes without trees.

In EUROCRYPT, pages 480–494.

Benaloh, J. and Mare, M. D. (1993). One-way accumula-

tors: A decentralized alternative to digital signatures.

pages 274–285. Springer-Verlag.

Boneh, D. and Freeman, D. M. (2011). Homomorphic

signatures for polynomial functions. In Advances in

Cryptology – EUROCRYPT 2011, volume 6632 of

Lecture Notes in Computer Science, pages 149–168.

Boneh, D., Gentry, C., Lynn, B., and Shacham, H. (2003).

Aggregate and Veriﬁably Encrypted Signatures from

Bilinear Maps. In EUROCRYPT, pages 416–432.

Brzuska, C., Busch, H., Dagdelen, O., Fischlin, M., Franz,

M., Katzenbeisser, S., Manulis, M., Onete, C., Pe-

ter, A., Poettering, B., and Schr¨oder, D. (2010a).

Redactable Signatures for Tree-Structured Data: Def-

initions and Constructions. In Proceedings of the

8th International Conference on Applied Cryptogra-

phy and Network Security, ACNS’10, pages 87–104.

Springer.

Brzuska, C., Fischlin, M., Freudenreich, T., Lehmann, A.,

Page, M., Schelbert, J., Schr¨oder, D., and Volk, F.

(2009). Security of Sanitizable Signatures Revisited.

In Proc. of PKC 2009, pages 317–336. Springer.

Brzuska, C., Fischlin, M., Lehmann, A., and Schr¨oder, D.

(2010b). Unlinkability of Sanitizable Signatures. In

Public Key Cryptography, pages 444–461.

Camacho, P. and Hevia, A. (2012). Short transitive sig-

natures for directed trees. In Dunkelman, O., editor,

Topics in Cryptology – CT-RSA 2012, volume 7178

of Lecture Notes in Computer Science, pages 35–50.

Springer Berlin / Heidelberg.

Camenisch, J. and Lysyanskaya, A. (2002). Dynamic ac-

cumulators and application to efﬁcient revocation of

anonymous credentials. In CRYPTO, pages 61–76.

Chang, E.-C., Lim, C. L., and Xu, J. (2009). Short

Redactable Signatures Using Random Trees. In Pro-

ceedings of the The Cryptographers’ Track at the RSA

Conference 2009 on Topics in Cryptology, CT-RSA

’09, pages 133–147, Berlin, Heidelberg. Springer-

Verlag.

Gottlob, G., Koch, C., and Pichler, R. (2003). The complex-

ity of XPath query evaluation. In Proceedings of the

22nd Symposium on Principles of Database Systems,

PODS, pages 179–190, New York, USA. ACM.

Johnson, R., Molnar, D., Song, D., and D.Wagner (2002).

Homomorphic signature schemes. In Proceedings of

the RSA Security Conference - Cryptographers Track,

pages 244–262. Springer.

Kundu, A. and Bertino, E. (2008). Structural Signatures for

Tree Data Structures. In Proc. of PVLDB 2008, New

Zealand. ACM.

Kundu, A. and Bertino, E. (2009). CERIAS Tech Report

2009-1 Leakage-Free Integrity Assurance for Tree

Data Structures.

Liu, B., Lu, J., and Yip, J. (2009). XML data integrity based

on concatenated hash function. International Journal

of Computer Science and Information Security, 1(1).

Merkle, R. C. (1989). A certiﬁed digital signature. In

CRYPTO, pages 218–238.

Micali, S. and Rivest, R. L. (2002). Transitive signature

schemes. In Preneel, B., editor, CT-RSA, volume 2271

of Lecture Notes in Computer Science, pages 236–

243. Springer.

Miyazaki, K., Iwamura, M., Matsumoto, T., Sasaki, R.,

Yoshiura, H., Tezuka, S., and Imai, H. (2005). Dig-

itally Signed Document Sanitizing Scheme with Dis-

closure Condition Control. IEICE Transactions, 88-

A(1):239–246.

Miyazaki, K., Susaki, S., Iwamura, M., Matsumoto,

T., Sasaki, R., and Yoshiura, H. (2003). Digi-

tal documents sanitizing problem. Technical Report

ISEC2003-20, IEICE.

Nyberg, K. (1996). Fast accumulated hashing. In FSE,

pages 83–87.

P¨ohls, H. C., Samelin, K., and Posegga, J. (2011). Sani-

tizable Signatures in XML Signature - Performance,

Mixing Properties, and Revisiting the Property of

Transparency. In Applied Cryptography and Network

Security, 9th International Conference, volume 6715

of LNCS, pages 166–182. Springer-Verlag.

Rivest, R. L., Shamir, A., and Adleman, L. (1983). A

method for obtaining digital signatures and public-key

cryptosystems. Commun. ACM, 26(1):96–99.

Samelin, K., P¨ohls, H. C., Bilzhause, A., Posegga, J., and

de Meer, H. (2012). Redactable signatures for inde-

pendent removal of structure and content. In ISPEC,

volume 7232 of LNCS, pages 17–33. Springer-Verlag.

Steinfeld, R. and Bull, L. (2002). Content extraction signa-

tures. In Information Security and Cryptology - ICISC

2001: 4th International Conference. Springer Berlin /

Heidelberg.

Tan, K. W. and Deng, R. H. (2009). Applying Sanitiz-

able Signature to Web-Service-Enabled Business Pro-

cesses: Going Beyond Integrity Protection. In ICWS,

pages 67–74.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

122

Wu, Z.-Y., Hsueh, C.-W., Tsai, C.-Y., Lai, F., Lee, H.-

C., and Chung, Y. (2010). Redactable Signatures for

Signed CDA Documents. Journal of Medical Systems,

pages 1–14.

APPENDIX

A Security Proofs of the Construction

Our changes to the security model do not affect the

implications and separations as presented in (Brzuska

et al., 2010a). Hence, unforgeability is independent,

while transparency ⇒ privacy and privacy ; trans-

parency (Brzuska et al., 2010a). The proofs are es-

sentially the same as already given in (Brzuska et al.,

2010a). Following from that it is sufﬁcient to show

that transparency and unforgeability hold to show that

our scheme are secure. We will show this for each

property on its own.

The Construction is Unforgeable. If AH is

collision-resistant and one-way, and the signature

scheme Π is strongly unforgeable, our scheme is un-

forgeable.

Proof. Let A

unf

be an algorithm winning our un-

forgeability game. We can then use A

unf

to forge

the underlying signature scheme, to ﬁnd collisions in

the hash-domain, or to calculate membership proofs.

Hence, our scheme’s security relies upon the security

of the signature scheme and AH . Given the game in

Fig. 6 we can derive that a forgery must fall in at least

one of the three cases, for at least one node in the tree:

Type 1 Forgery: The value d protected by σ

has

never been queried by A

unf

to O

Sign

Type 2 Forgery:

The value d protected by σ

has been queried by A

unf

to O

Sign

, but T

∗

/∈ span

⊢

(T, ADM); so the tree T

∗

with

valid signature σ

is not in the transitive closure of T.

This case has to be divided as well:

Type 2a Forgery: T /∈ span

⊢

∗

, ADM) Type 2b

Forgery: T ∈ span

⊢

∗

, ADM) To win A

unf

, the at-

tacker must be able to construct one of the three above

forgeries. This forgery can be used to break at least

one of the underlying primitives.

Type 1 Forgery: In the ﬁrst case, we can use the

Type 1 Forgery of A

unf

to create A

unfSig

which forges

a signature. We construct A

unfSig

using A

unf

as fol-

lows:

(1) A

unfSig

chooses a hash-function AH and passes

prm to A

unf

. This is also true for pk of the signature

scheme to forge.

(2) All queries to O

Sign

from A

unf

are forwarded to

unfSig

’s oracle and genuinely returned to A

unf

(3) Eventually, A

unf

will output a pair (T

∗

,σ

∗

unfSig

returns (T

∗

,σ

∗

), as a valid forgery. The

concrete signature forged can easily be extracted by

deﬁning a tree-traversal algorithm looking for the sig-

nature not queried for the particular value. This is

due to the fact, that we allow to distribute sub-trees.

Hence, any node may be forged, not just the root

node.

Type 2a Forgery: In the case of 2a, we can use

the Type 2a Forgery produced by A

unf

to construct

col

which breaks the collision-resistance of the un-

derlying hash-function. To do so, (1) A

col

generates

a key pair of a signature scheme to emulate O

Sign

and

chooses AH .

(2) It passes pk and prm to A

unf

(3) For every request to the signing oracle, A

col

gen-

erates the signature σ using sk and returns it to A

unf

(4) Eventually, A

col

will output (T

∗

,σ

∗

). Given

the transcript of the simulation, A

col

searches for

a pair M H (n

) = M H (n

) with different content

resp. sub-trees. If such a pair is found and T

∗

/∈

span

⊢

, ADM

), A

col

outputs exactly this pair, else

it aborts. The outputted pair is a collision of the hash-

function.

Type 2b Forgery: If A

unf

returns a Type 2b

Forgery, we can build A

one

which calculates member-

ship proofs of the underlying accumulator. To do so,

(1) A

one

generates a key pair of a signature scheme to

emulate O

Sign

and chooses AH .

(2) It passes pk and AH to A

unf

(3) For every request to the signing oracle, A

one

gen-

erates the signature σ using sk and returns it to A

unf

(4) Eventually, A

unf

will output (T

∗

,σ

∗

). Given

the transcript of the simulation, A

one

searches for

a pair M H (n

) = M H (n

) with different content

resp. sub-trees. If such a pair is found and T

∈

span

⊢

∗

, ADM

∗

), A

one

outputs (T

∗

,σ

∗

), iff

the preimage maps to queried document. In other

words, the queried tree must be in the transitive clo-

sure of the preimage. Otherwise, we just have a

normal collision, which belongs to case 2a. The

membership proofs of the used accumulator can triv-

ially be extracted. We showed how to use all three

forgery types to break existential unforgeability of the

underlying signature scheme Π, the one-way or the

collision-resistance property of AH .

Our Construction is Transparent and Private. If

AH always outputs uniformly distributed digests and

the digests are therefore indistinguishable from ran-

dom numbers, our scheme is transparent and there-

fore also private (Brzuska et al., 2010a): This follows

directly from the deﬁnitions, i.e., the uniform distri-

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

123

bution of the digests and the random numbers. In

particular, all output of AH is computationally in-

distinguishable from random. This implies that the

output of O

ModifyOrSign

is also computationally indis-

tinguishable from uniform, hence hiding the secret

bit b with overwhelming probability. In other words,

an adversary breaking transparency is able to distin-

guish between random and computed digests, which

has been assumed to be infeasible. Attacking the

nonces is not possible, since removing a random from

a uniform distribution results in a uniform distribution

again. An additional note: This is the reason why we

require a random seed for the accumulator; otherwise,

an adversary could just recalculate the digests.

B Formal Deﬁnition of the Requirements

of AH

Collision-resistance and One-wayness. The fam-

ily AH

contains only collision-resistant func-

tions (Bari´c and Pﬁtzmann, 1997). Furthermore, it

must be hard to ﬁnda digest with the same value with-

out having the preimages, i.e., we need strong one-

wayness (Bari´c and Pﬁtzmann, 1997). We can capture

both requirements:

Pr[k

← K;x

← X

← Y

;(x

′

) ← A(x,y) :

(x,y) = AH

′

) ∧ y 6= y

′

] < ε(λ)

Where the probability is taken over all coin tosses.

In other words, an adversary should not be able to

reverse the hashing step and to ﬁnd a valid preimage

or to ﬁnd any other collision.

Indistinguishability of Output. We require that an

adversary cannot decide how many additional mem-

bers have been digested, i.e., the following distri-

butions S

and S

must be computationally indistin-

guishable:

= {x

| x

← X

}

= {AH

) | y

← Y

← X

← K}

The probability is taken over all coin tosses. In other

words, an outsider not having the preimages cannot

decide how many members a given digest has.

C Brzuska et al.’s Security Model

In (Brzuska et al., 2010a) Brzuska et al. formal-

ized the needs of signatures for tree-structured docu-

ments. A RSS for tree-structured documents requires

four efﬁcient algorithms; in particular R SS

(sKg,sSign,sVf,sCut):

• sKg(1

outputs the key-pair (sk, pk), where λ is

the security parameter;

• sSign(sk, T) outputs a structural signature σ

;

• sVf(pk,T,σ

) outputs a bit v ∈ {0, 1}, which indi-

cates the correctness of the signature σ

protect-

ing the tree T and

• the redaction algorithm sCut(pk,T,σ

), which

removes the leaf L

from the tree T and outputs a

sub-tree T

′

≃ T \ {L

}  T and the corresponding

new signature σ

′

for which sVf(pk, T

′

,σ

′

) out-

puts 1.

Applying the leaf-cutting algorithm

sCut

subse-

quently allows removing complete sub-trees (Brzuska

et al., 2010a). It does not allow to redact non-leaves

or to express re-locations of sub-trees.

RSS Security Requirements. We informally re-

peat the existing security properties for tree-

structured documents as given and formalized by

Brzuska et al. in (Brzuska et al., 2010a). These re-

quirements should also hold for the structure of the

tree T, not just its data. The structural integrity pro-

tection requires that all relations between nodes and

their position within the tree’s hierarchy are protected

by the signature σ

1. Unforgeability: No one should be able to com-

pute a valid signature on a tree T

′

for pk with-

out having access to the corresponding secret key

sk. This is analogous to the standard unforgeabil-

ity requirement for signature schemes, as already

noted in (Brzuska et al., 2010a).

2. Privacy: Given a sub-tree with a signature σ and

two possible source trees T

j,0

and T

j,1

, no one

should be able to decide from which source tree

the , stems from. This deﬁnition is similar to the

standard indistinguishability notation for encryp-

tion schemes (Brzuska et al., 2010a).

3. Transparency: A third party should not be able

to decide which operations may have been per-

formed on a signed tree. Hence, whether a sig-

nature σ

of a tree has been created from scratch

or through sCut shall remain indistinguishable for

a party receiving a signed tree T (Brzuska et al.,

2010a).

The given notations take the tree structure of docu-

ments into account and allow public redactions, as

sCut only requires the public key pk. The formal

games are depicted in Fig. 12, Fig. 13 and Fig. 14/15.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

124

Experiment Unforgeability

RSS

(λ)

(pk,sk) ← KeyGen(1

)

∗

,σ

∗

) ← A

DSign(sk,·)

(pk)

let i = 1,2,...,q index the queries

return 1 iff

DVerify(pk,T

∗

,σ

∗

) = 1 and

for all 1 ≤ i ≤ q, T

∗

 T

Figure 12: Game for Unforgeability.

Experiment Transparency

RSS

(λ)

(pk,sk) ← KeyGen(1

)

← {0,1}

d ← A

DSign(sk,·),DSign/DCut(·,·,sk,b)

(pk)

where oracle DSign/DCut for input T,L:

if L is not a leaf of T, return ⊥

if b = 0: (T,σ) ← DSign(sk,T),

′

,σ

′

) ← DCut(pk,T,σ,L)

if b = 1: T

′

← T \ L

′

,σ

′

) ← DSign(sk,T

′

ﬁnally return (T

′

,σ

′

return 1 iff b = d

Figure 13: Game for Transparency.

D Revisiting the KB-Scheme

Here we shortly review the KB-Scheme as introduced

in (Kundu and Bertino, 2009). We omit the step that

randomizes the traversal numbers preserving their or-

dering. The KB-Scheme claims this is done to pre-

serve transparency. It has been shown in (Brzuska

et al., 2010a) that this is not sufﬁcient to maintain

transparency. We already state the scheme in our

notation, since the original notation in (Kundu and

Bertino, 2009) and in (Brzuska et al., 2010a) is not

able to express the possibility of removing intermedi-

ate nodes. Every node n

∈ T will be addressed by his

pre-order traversal number, i.e., the root is denoted as

. Note, the amount of nodes in T, i.e., |V|, will be

denoted as n.

KeyGen. Generate a key pair (sk,pk) of an aggre-

gating signature scheme ASS allowing public ag-

gregation, e.g., the BGLS-Scheme (Boneh et al.,

2003). By abuse of notation, we assume that pk

Experiment Privacy

RSS

(λ)

(pk,sk) ← KeyGen(1

)

← {0,1}

d ← A

DSign(sk,·),SignCut(...,sk,b)

(pk)

return 1 iff b = d

Figure 14: Game for Privacy.

SignCut(T

j,0

j,1

,sk,b)

if T

j,0

\ L

j,0

≇ T

j,1

\ L

j,1

return ⊥

j,b

,σ

j,b

) ← sSign(sk,T

j,b

)

return (T

′

j,b

,σ

′

j,b

) ← sCut(pk,T

j,b

,σ

j,b

)

Figure 15: SignCut Oracle.

contains all system parameters.

Sign. The signing-step outputs a signature for each

node inside the tree:

1. Compute the pre- and post-order traversal num-

bers, of the tree T.

2. Transform these lists into an randomized but

order-preserving space. For each node n

, let

denote the associated pair of randomized

traversal numbers

3. Set G

← H (ω||ρ

||c

||... ||ρ

||c

), where ω

is a nonce and H a cryptographichash-function

like SHA-512

4. ∀n

∈ T compute: ξ

← H (G

||ρ

||c

)

5. Sign all ξ

, i.e., σ

← SIGN

AS S

(sk,ξ

)

6. Aggregate all signatures into σ

7. Output σ = (T,σ

,{(σ

,ρ

)}

0<i≤n

,pk)

Modify. The Kundu-Scheme allows redaction of arbi-

trary nodes but no re-locations. Hence, MOD just

contains the description to redact the node n

1. Verify the signature using Verify

2. Remove n

from T, i.e., T

′

← MOD(T). This

can be expressed as T

′

← T \ n

, where n

is the

node to be redacted as speciﬁed by MOD. Both

also includes all edges from resp. to n

. Note,

may not be a leaf

3. Aggregate all signatures {σ

}

j6=i

into σ

′

4. Output the altered tuple σ

′

, i.e.,:

′

= (T

′

,σ

′

,{(σ

,ρ

)}

0<i≤n

′

,pk)

Verify. Veriﬁcation just uses σ:

1. For each node n

∈ T compute ξ

←

H (G

||ρ

||c

)

2. Check the validity using ASS. In particular,

each ξ

calculated must be signed and contained

in σ

3. Traverse the tree using pre-order and check if

each of the associated traversal numbers is in

the correct order, i.e., the associated pre- and

post-order must remain plausible. Let f denote

the parent of g; it must yield that p

> p

and

< r

, where p

denotes the associated pre-

order-number and r

the post-order-number as-

sociated to the node x.

4. Output 1, if all checks pass, 0 otherwise resp.

⊥ on error

FlexibleRedactableSignatureSchemesforTrees-ExtendedSecurityModelandConstruction

125