Redactable Signatures with
Dependencies and Personal
Health Records
Presented by
David Bauer
1
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
2
Verified Database
Table View
Identifier
Meta Data
Meta Data
Data
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
3
Verified Database
Cloud View
Data
Metadata
Metadata
Data
Data
Data
Data
Data
Metadata
Metadata
4
Verified Database
Hash Tree
Hash Tree
Cloud View
Data
Metadata
Metadata
Data
Data
Data
Data
Data
Metadata
Metadata
5
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
6
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.)
7
Dependency Graph
• Release policy is a graph
– Each claim is a node
– Each AND/OR is a node
– No limit on fan-out or
fan-in
“1” cannot be released without also
release one of “2” or “3” along with one
of “4” or “5”
• May have many top-level
and bottom-level nodes
• Bottom (leaf) nodes are
stored directly in the
hash tree
– Other nodes are not
8
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
9
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
10
Notice: no actual OR node!
(They do exist in the program code, though)
11
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)
12
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)
13
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)
14
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
15
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
16
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.)
17
Performance
All times in microseconds
Monolithic Graph
Input Table Size
Rows
Columns
Data size
Verify chain
Multi-Graph
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
18
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 patientprovided records
– Cryptographically signed by producer
– Contains context as set by producer
19
Questions?
20