1 / 20

Redactable Signatures with Dependencies and Personal Health Records

Redactable Signatures with Dependencies and Personal Health Records. Presented by David Bauer. 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

tad-hyde
Download Presentation

Redactable Signatures with Dependencies and Personal Health Records

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Table View

  4. Verified Database Cloud View Data Metadata Data Metadata Data Data Data Data Metadata Metadata

  5. Verified Database Hash Tree Hash Tree Cloud View Data Metadata Data Metadata Data Data Data Data Metadata Metadata

  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 • 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 “1” cannot be released without also release one of “2” or “3” along with one of “4” or “5”

  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 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?

More Related