On Structural Signatures for Tree Data Structures€¦ · On Structural Signatures for Tree Data Structures Kai Samelin*, Henrich C. Pöhls**, Arne Bilzhause, Joachim Posegga and

On Structural Signatures for Tree Data Structures

Kai Samelin*, Henrich C. Pöhls**, Arne Bilzhause,

Joachim Posegga and Hermann de Meer

*) supported by “Regionale Wettbewerbsfähigkeit und Beschäftigung", 2007-2013 (EFRE) as part of www.SECBIT.de **) funded by BMBF (FKZ: 13N10966) and ANR as part of the ReSCUe IT project

24.06.2012 2

Contribution

Three new attacks on Kundu and Bertino‘s Redactable Signature Scheme (RSS)

Unforgeability broken

Transparency broken

Privacy broken

New secure and efficient scheme

Signing in O(n)

Verifying in O (n)

Storage in O(n)

Implementation and performance measurements:

Kundu and Bertino

Brzuska et al.

24.06.2012 3

Redactable Signature Schemes – An Introduction

Basic idea:

Sign data (Sign)

• Name

• Date of Birth

• Gender

Just disclose parts of it (Redact)

• E.g.: Date of Birth

Redaction is public

Applications (Verify)

• Age-restricted locations (Pubs/Liquor Stores…)

• Hospitals

• …

24.06.2012 4

Redactable Signature Schemes – Model

The security model:

Unforgeability

Privacy

Transparency

24.06.2012 5

Redactable Signature Schemes – Unforgeability

Unforgeability means:

Attacker cannot generate a signature for a message not derivable from existing message

• Adaptive

Analogous to unforgeability requirements of standard signatures

• Every meaningful RSS must be unforgeable!

24.06.2012 6

Redactable Signature Schemes – Privacy

Privacy means:

Attacker cannot gain any knowledge about redacted parts

To be more precise:

Attacker chooses ( , , )

Oracle signs and redacts the chosen or to

Attacker is not better than guessing, whether

or has been adjusted

• Every meaningful RSS must be private!

m1 m2

sign mb

σ, m3

Redact to m3

Oracle

m3

b {1,2}

24.06.2012 7

Redactable Signature Schemes – Transparency

Transparency means:

Attacker cannot decide how the received message was created

To be more precise:

Attacker chooses ( , )

Oracle • Either: adjusts to and

then signs

• Or: is signed and

then adjusted by redaction

Attacker is not noticable better than guessing which path was taken

• Transparency Privacy

m1

m2 = MOD(m1)

sign m1

σ, m2

sign m2 redaction

Oracle

m2

b {1,2}

24.06.2012 8

Current Schemes for trees?

Kundu and Bertino @VLDB ’08

Now broken: All four different „revisions” have flaws

Allows non-leaf redaction (More later on…)

Underlying idea allows efficient construction: O(n)

Brzuska et al. @ACNS ’10

Secure

only leaves

Not efficient: O(n2)

Kundu, Mikhail and Bertino @CODASPY ’12

Security not yet broken

Not efficient: O(n2) due to a different underlying idea

only leaves

24.06.2012 9

Kundu and Bertino’s RSS for Trees

Idea: Tree is uniquely determined by Pre- and Postorder traversal numbers

24.06.2012 10

Kundu and Bertino’s RSS for Trees - Sign


We will refer to the following tree

n1

n3

n2

n4

n5

24.06.2012 11



Calculate preorder traversals for the following tree:

Algorithm:

1. Preorder n1

n3

n2

n4

(1;

(2;

(3; (4;

(5; n5

24.06.2012 12



Calculate postorder traversals for the following tree:

Algorithm:

1. Preorder

2. Postorder

5)

4)

1) 3)

2)

n1

n3

n2

n4

n5

(1;

(2;

(3; (4;

(5;

24.06.2012 13




Algorithm:

1. Preorder

2. Postorder

5)

4)

1) 3)

2)

n1

n3

n2

n4

n5

(1;

(2;

(3; (4;

(5;

Ancestor Relation:

Preorder increase

Postorder decrease

24.06.2012 14




Algorithm:

1. Preorder

2. Postorder

5)

4)

1) 3)

2)

n1

n3

n2

n4

n5

(1;

(2;

(3; (4;

(5;

Ancestor Relation:

Preorder increase

Postorder decrease

24.06.2012 15




Algorithm:

1. Preorder

2. Postorder

5)

4)

1) 3)

2)

n1

n3

n2

n4

n5

(1;

(2;

(3; (4;

(5;

Sibling order

(left-to-right):

Preorder increase

Postorder increase

24.06.2012 16



Randomize traversal numbers

Algorithm:

1. Preorder

2. Postorder

3. Randomize numbers ORDER-PRESERVING onto [0,1]

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 17




Algorithm:

1. Preorder

2. Postorder


(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

Sibling order

(left-to-right):

Preorder increase

Postorder increase

Ancestor Relation:

Preorder increase

Postorder decrease

24.06.2012 18

Kundu and Bertino’s RSS for Trees – Attack on Privacy I



Algorithm:

1. Preorder

2. Postorder


24.06.2012 19

Kundu and Bertino’s RSS for Trees – Attack on Privacy I



Algorithm:

1. Preorder

2. Postorder


Schemes based on ordered nonces cannot be private! (See Brzuska et al. @ ACNS ’10)

24.06.2012 20

Kundu and Bertino’s RSS for Trees – Sign cont’d

Let ρi := (prei, posti)

GT := (ρ1,…,ρl)

Use an aggregate signature scheme to sign:

• σi ← Sign(sk, GT || ρi ||ci)

• Note: all σ

• Aggregate all σi into σc

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 21

Kundu and Bertino’s RSS for Trees – Attack On Privacy II


GT := (ρ1,…,ρl)



• Note: all σ


• GT must be available for verifying…

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 22

Kundu and Bertino’s RSS for Trees – Attack On Privacy II


GT := (ρ1,…,ρl)



• Note: all σ


• GT must be available for verifying…

Attacker

• Calculates GT’ from T’

• Breaks Privacy by Comparing GT’ and GT

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 23

Kundu and Bertino’s RSS for Trees – Attack On Unforgeability

Newest Revision…


GT := Ø


• σ ← Sign(sk, Ø||ci|| ρi )

• Aggregate all σi onto σc

24.06.2012 24


Newest Revision…


GT := Ø




Attacker uses two nodes from two signed trees

(0.1;0.7) n1

T1

(0.2;0.5) n’1

T2

24.06.2012 25


Newest Revision…


GT := Ø




Attacker uses two nodes from two signed trees to generate a forged new tree:

(0.1;0.7) n1

TA

(0.2;0.5) n’1

Ancestor Relation:

Preorder increase

Postorder decrease

24.06.2012 26

Kundu and Bertino’s RSS for Trees – Structural Integrity

What about redacting non-leaves?

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 27



New edges…

See Samelin et al. @ ISPEC ’12

Maybe useful to redact hierarchies…

However: Let the signer decide!

(0.1;0.7)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3 n4

n5

24.06.2012 28



What about the root?

(0.1;0.7)

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n1

n3

n2

n4

n5

24.06.2012 29



What about the root?

Same attacks apply!

Let the signer decide…

(0.3;0.5)

(0.7;0.1) (0.71;0.37)

(0.94;0.3)

n3

n2

n4

n5

24.06.2012 30

Kundu and Bertino’s RSS for Trees – Conclusion

All schemes of Kundu and Bertino are insecure concerning at least one property!

• Not easily fixable

The schemes by Brzuska et al. and Kundu et al. are in O(n2)

Can we have the best of both worlds?

24.06.2012 31

Kundu and Bertino’s RSS for Trees – Conclusion

All schemes of Kundu and Bertino are insecure concerning at least one property!

• Not easily fixable

The schemes by Brzuska et al. and Kundu et al. are in O(n2)

Can we have the best of both worlds?

Yes!

24.06.2012 32

Kundu and Bertino’s RSS for Trees – Our Scheme

Two requirements:

• Aggregate Signature Scheme

• RSS for lists in O(n)

• Storage

• Runtime

Idea: Use Pre- and Postorder traversal numbers

• Do not sort them

• But how to protect the order?

• Let the underlying RSS handle this!

24.06.2012 33


Generate 2 lists with |V| uniformly distributed nonces

n1

n3

n2

n4

n5

M =

L =

1 3 8 2 7

10 4 6 9 11

24.06.2012 34



Sign M and L using the RSS

1 3 8 2 7 M =

10 4 6 9 11 L =

n1

n3

n2

n4

n5

24.06.2012 35




Map using the traversal numbers

1 3 8 2 7 M =

10 4 6 9 11 L =

5)

4)

1) 3)

2)

(1;

(2;

(3; (4;

(5;

Pos: 1st 2nd 3rd 4th 5th

1st of M

5th of L

1, 11

24.06.2012 36





1,11

8,10

1 3 8 2 7 M =

10 4 6 9 11 L =

5)

4)

1) 3)

2)

(1;

(2;

(3; (4;

(5;


3rd of M

1st of L

24.06.2012 37





1,11

8,10

3,9

2,6

7,4

1 3 8 2 7 M =

10 4 6 9 11 L =

5)

4)

1) 3)

2)

(1;

(2;

(3; (4;

(5;


24.06.2012 38





Sign each node:

• σ ← Sign(sk, Mpre||Lpost||τ||ci)

• Aggregate all signatures into σ

τ is a tag binding nodes (unique for each tree signed)

1,11

8,10

3,9

2,6

7,4

1 3 8 2 7 M =

10 4 6 9 11 L =


24.06.2012 39


What if we want to redact a node?

Delete the node and adjust the lists!

1,11

8,10

3,9

2,6

1 3 8 2 M’ =

10 6 9 11 L’ =

7,4

7

4

24.06.2012 40


What if we want to redact a node?

Delete the node and adjust the lists!

Aggregate Signature Scheme information theoretically transparent!

Transparency solely depends on the underlying RSS used! (Implies Privacy!)

1,11

8,10

3,9

2,6

1 3 8 2 M’ =

10 6 9 11 L’ =

24.06.2012 41


Verification is straight forward:

• Verify M’ and L’

• Verify σ

• Check, if nodes are positioned correctly using M’ and L’

1,11

8,10

3,9

2,6

1 3 8 2 M’ =

10 6 9 11 L’ =

24.06.2012 42


HEY! We still allow non-leaf redaction and root removal!

Prohibit root-removal:

• If the root is not to be redacted: Annotate it!

• Else: Leave as is…

Prohibit intermediate node-redaction

• If not allowed: Sign “depth” with random offset

• Otherwise: Leave as is…

Simple way for the SIGNER to control what can be done!

1,11

8,10

3,9

2,6

24.06.2012 43

Conclusion

• Kundu and Bertino’s schemes not secure!

• Existing Secure Schemes have quadratic overhead become slow very fast

• The presented Redacatble Signature Scheme for Trees is

Efficient: O(n) signing and verification steps (n = # of nodes in T) O(n) storage space

Provably Secure

Flexible & Signer Controlled: Signer decides if non-leaves (incl. root) are allowed to be redacted

24.06.2012 44

Conclusion

• Kundu and Bertino’s schemes not secure!

• Existing Secure Schemes have quadratic overhead become slow very fast

• The presented Redacatble Signature Scheme for Trees is

Efficient: O(n) signing and verification steps (n = # of nodes in T) O(n) storage space

Provably Secure

Flexible & Signer Controlled: Signer decides if non-leaves (incl. root) are allowed to be redacted

Contact: {ks, hcp, ab, jp}@sec.uni-passau.de [email protected]

24.06.2012 45 24.06.2012 45

Documents

On Structural Signatures for Tree Data Structures€¦ · On Structural Signatures for Tree Data Structures Kai Samelin*, Henrich C. Pöhls**, Arne Bilzhause, Joachim Posegga and