1

Redactable Signatures with Dependencies and Personal

Health Records

Presented by

David Bauer

2

Background

• Personal health records– Under patient’s control

• Redactable signature– Signature such that parts of the signed document can

be hidden and the signature still verified

• Sign medical records with a redactable signature– Patient can show relevant parts of records– Parts of records can be efficiently verified

3

Verified Database

Identifier Meta Data Meta Data Data

… … … …

… … … …

… … … …

… … … …

… … … …

Table View

4

Verified Database

Data

Metadata

Data

Data DataData

Data

Metadata

Metadata

Metadata

Cloud View

5

Verified Database

Data

Metadata

Data

Data DataData

Data

Metadata

Metadata

Metadata

Cloud View

Hash Tree Hash Tree

6

Dependencies Between Claims

• Claims can be related in many ways

• We may not want some claims released without supporting data or metadata– Medical x-ray needs meta-data– Medical diagnosis needs test results

• Policies for release may be complicated– Release A if also releasing B or C or a

combination of D and E

7

We can enforce disclosure dependencies cryptographically

(And we must, because we can’t trust whoever is distributing the information to voluntarily follow the record producer’s policies.)

8

Dependency Graph

“1” cannot be released without also release one of “2” or “3” along with one

of “4” or “5”

• Release policy is a graph– Each claim is a node– Each AND/OR is a node– No limit on fan-out or fan-

in

• May have many top-level and bottom-level nodes

• Bottom (leaf) nodes are stored directly in the hash tree– Other nodes are not

9

How to enforce policy

• Create chains of hash values– Think hash-tree or Merkle-Damgård– Chains overlap, creating a directed graph– Any directed-acyclic graph is acceptable

• A node contains– An operation (e.g., AND) or a claim– The hashes of nodes dependent on this node

10

What does a node look like?

• Consider z → x or y• S(x) is called the string for node x• S(x) = H(S(z) + x)

– H is a hash function– “+” is concatenation– x is the actual data– S(z) is the string for node z

• S(y) = H(S(z) + y)• S(z) = z

11

Notice: no actual OR node!

(They do exist in the program code, though)

12

AND Nodes

• OR Nodes disappear; AND nodes don’t

• AND nodes require secret sharing

• Consider z → x and y

• Generate random string A1

• S(AND) = H(S(z) + A1)

• A2 = S(AND) xor A1

• S(x) = H(A1 + x)

• S(y) = H(A2 + y)

13

Example Graph

• S(1) = 1• A1 = random string• S(AND) = H(S(1) + A1)• A2 = S(AND) xor A1• S(2) = H(A1 + 2)• S(3) = H(A1 + 3)• S(4) = H(A2 + 4)• S(5) = H(A2 + 5)

14

Example – Show 1, 2, and 4

• Start with S(2) and S(4)– On list of leaf nodes

• S(2) = H(A1 + 2)• S(4) = H(A2 + 4)• Show A1, A2, 2, and 4

– Can verify S(2), S(4)

• S(AND) = A1 xor A2• S(AND) = H(S(1) + A1)• Show S(1) = 1

– Can verify S(AND)

15

Extra Technical Notes

• For the security proof:– Nodes must be unambiguous in type– Nodes must have random padding– Nodes must be unambiguously parseable– The “random” values used in AND nodes

have some restrictions– The hash function used must have additional

properties (the most popular ones work)– Threat model is unusual

16

Performance Intro

• Two implementations were made

• Monolithic graph– Minimizes memory, initial computation– Good overall performance

• Multi-graph approach– Pre-computes each chain– Much faster for some parameters– Much worse in worst-case

17

Performance: Graph Description

The graph of dependencies is based on a table, with each element in the first column depending on also showing at least one element from each of the other columns.

(A second, denser form where each column depended upon the following column was also tested, but not shown here.)

18

Performance

Input Table Size Monolithic Graph Multi-Graph

Rows Columns Data size Verify chain Verify all Verify chain Verify all

Small inputs

4 4 10 360 330 120 450

4 8 10 520 460 200 660

4 16 10 960 890 400 1500

4 32 10 1900 1800 950 3600

Medium inputs

64 16 100 1700 8200 1300 77,000

64 32 100 3400 17,000 4400 280,000

64 64 100 6800 34,000 19,000 1,200,000

64 128 100 15,000 74,000 77,000 5,000,000

All times in microseconds

19

Advantages in a PHR

• Patients retain control of their records– Gives patients more reason to store their own

records– Allows patients to better use their records– Patients determine what is released

• Medical personnel can trust patient-provided records– Cryptographically signed by producer– Contains context as set by producer

20

Questions?