1 / 55

Enabling the Archival Storage of Signed Documents

Enabling the Archival Storage of Signed Documents. Petros Maniatis, Mary Baker Computer Science Department Stanford University. Motivation by Example. You buy a house on-line You sign the contract digitally, and so does the seller You archive the contract for safe keeping

bambi
Télécharger la présentation

Enabling the Archival Storage of Signed Documents

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. Enabling the Archival Storage of Signed Documents Petros Maniatis, Mary Baker Computer Science Department Stanford University

  2. Motivation by Example • You buy a house on-line • You sign the contract digitally, and so does the seller • You archive the contract for safe keeping • In 30 years, the seller disputes the sale • How do you prove that the archived contract was, in fact, signed by the seller? FAST 2002

  3. Draw the Contract FAST 2002

  4. Seller Signs the Contract FAST 2002

  5. Buyer Gets Seller’s Public Key FAST 2002

  6. Buyer Checks the Signature FAST 2002

  7. Buyer Archives the Contract FAST 2002

  8. Time Passes FAST 2002

  9. Time Passes FAST 2002

  10. Time Passes FAST 2002

  11. Contract Validity Is Disputed FAST 2002

  12. Contract Is Archived and Well FAST 2002

  13. Seller’s Public Key Is Different! FAST 2002

  14. New Key Doesn’t Verify the Signature FAST 2002

  15. Time Sensitivity of Signatures • Keys are sensitive • They get lost, compromised, stolen • They get computationally vulnerable with time • Names change • People move, change jobs, get expelled • Certificates have an expiration date • To limit the possible damage due to compromise • A new certificate (new key) is issued regularly FAST 2002

  16. Two Big Questions • The sale contract was signed 30 years ago: • Many many public keys/certificates • Can I trust a 30-year old signature? • What if a broken key was used on a fake contract? • Where do I find a 30-year-old public key? • Certification Authorities don’t care about the past • I can’t rely on a 30-year-old certificate either, since it has the CA’s 30-year-old signature on it FAST 2002

  17. State of the Art, a.k.a.Two Really Bad Answers • Do nothing • Contract expires with the signature • You can’t have contracts that last longer than a couple of years • Re-sign documents • After every key change, sign and re-archive all of my documents • Management disaster! FAST 2002

  18. A Better Answer • Can I trust a 30-year old signature? • YES, if I establish that the signature was made while the key was still valid • Where do I find a 30-year-old public key? • In a timed, secure archive of the Certification Authority FAST 2002

  19. Our Solution: KASTS • An extended archival storage system for digitally signed documents • It time stamps all archived signed documents • It maintains a timed authenticated archive of public keys as they change • It enables the secure correlation of the times on document signatures and certificates FAST 2002

  20. Two Big Questions • Can I trust a 30-year old signature? • How can I tell that a document was signed while the signing key was still valid? • Where do I find a 30-year-old public key? FAST 2002

  21. Exploiting Time Stamping • A Time Stamping Service maintains a secure time of submission of documents • A time stamp on a signed document determines when the document was signed • A time stamp on a certificate, determines when the certificate was created and when it expires FAST 2002

  22. Two Big Questions • Can I trust a 30-year old signature? • Where do I find a 30-year-old public key? • What public key corresponds to an old signature? • How do I know it is the right one? FAST 2002

  23. Timed Authenticated Archives • Objective: Maintain a history of the CA • Time stamp all CA database changes • Insertions, revocations, replacements • Be able to answer • “at time t, what was the public key for name n?” • i.e., “find the certificate active at the signing time” • For all public keys of any name over time! • Share timelines with the Time Stamping Service FAST 2002

  24. Operational Overview FAST 2002

  25. Example Reprise • You buy a house on-line • You sign the contract digitally, and so does the seller • You time stamp the signed contract • You archive the contract for safe keeping • You make sure the seller’s certificate is in the archived CA, too • In 30 years, the seller disputes the sale • Retrieve the time stamped contract and the seller’s certificate, compare the times, go skiing FAST 2002

  26. Draw the Contract FAST 2002

  27. Seller Signs the Contract FAST 2002

  28. Buyer Gets Seller’s Public Key FAST 2002

  29. Buyer Checks Whether Seller’s Public Key Is Archived FAST 2002

  30. Buyer Checks the Signature FAST 2002

  31. Buyer Time Stamps the Contract FAST 2002

  32. Buyer Archives the Contract FAST 2002

  33. Time Passes FAST 2002

  34. Time Passes FAST 2002

  35. Time Passes FAST 2002

  36. Contract Validity Is Disputed FAST 2002

  37. Contract Is Archived and Well FAST 2002

  38. Seller’s Old Public Key Is Archived And Well FAST 2002

  39. Old Key Verifies the Seller’s Signature FAST 2002

  40. KAS Requirements • Accountable: • Cannot pre-date/post-date certificates. • Cannot forget certificates. • Scalable: • Should handle the histories of decades’ worth of certificates. FAST 2002

  41. KAS Functionality • Operates in rounds • During each round • Accumulates certificate creations and revocations • Serves lookup requests for previous rounds • At the end of the round • Execute archive updates (insertions/deletions) • Time stamp the modifications since previous round FAST 2002

  42. KAS Design • Based on Authenticated Search Trees [Merkle1980, Buldas2000] • Tamper-evident search trees, using cryptographic hash functions (e.g., SHA-1) • Can compute a secure digest for the tree • Given the secure digest, I can produce cryptographic proofs that an element is included in the tree • Each tree node has a <name,public key,validity period> tuple (sorted by name) FAST 2002

  43. Authenticated Search Trees • Each node is labeled • Root Hash is the digest • Inclusion proof is based on: • The path from the root to the node • All siblings of the node’s ancestors FAST 2002

  44. Timed Authenticated Search Trees • By time stamping the digest (root label), you time stamp the entire tree • When tree changes create a new snapshot of the tree (persistent dynamic sets) • By time stamping the new root label, you time stamp new tree snapshot (i.e., tree modifications since last time) FAST 2002

  45. Maintaining Archive Snapshots • Version 1 has keys a, b, c & d • Version 2 is Version 1 without key a • If I time stamp root 2, I time stamp the snapshot of the tree without a, i.e., a’s removal FAST 2002

  46. KAS Design (2) • Tree operations make efficient disk-accesses • Based on B-trees • Inclusion proofs have efficient length • Proof length dependent on max tree height & branching factor • Reduce branching factor by embedding a balanced binary tree in every B-tree node FAST 2002

  47. Preliminary Results • 1 million CA clients • 2-week KAS round • 1 million changes per round (average) • 87 Mbytes per round • About 1 minute of I/O and computation for a new snapshot • Proofs under 12 Kbytes FAST 2002

  48. Summary • We put together • Time stamping [Haber & Stornetta] • Authenticated search trees [Buldas] • We built an extended, time stamped, persistent archive • We use it for a Key Archival Service, a historic archive for a Certification Authority • Implementation Available (in Java) FAST 2002

  49. The Future • This paper assumes a “single trust domain” • One trusted, immortal service of each kind • We are working on a more troubled setting • Multiple competing services of each kind • No service lives forever • No service of any kind enjoys universal trust • Technique: Timeline Entanglement • Each competing service acts as a watchdog of its competitors’ historic record integrity • Look for a publication at a conference near you FAST 2002

  50. Questions • For more information/implementation: http://identiscape.stanford.edu/ FAST 2002

More Related