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 IdentifierMeta Data Data ……… … ………… ………… ………… ………… Table View

4 Verified Database Data Metadata Data Metadata Cloud View

5 Verified Database Data Metadata Data Metadata Cloud View 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 SizeMonolithic GraphMulti-Graph RowsColumnsData sizeVerify chainVerify allVerify chainVerify all Small inputs Medium inputs , , , ,00019,0001,200, ,00074,00077,0005,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?