Securely Implementing Regulatory Policy

1. Securely ImplementingRegulatory Policy Randal C. Burns presentation to the Library of Congress 2 December 2005

2. Project National Science Foundation and Library of Congress. Digital Archives, NSF 04-592. “Securely Managing the Lifetime of Versions in Digital Archives.” Randal Burns (PI), Aviel Rubin, Giuseppe Ateniese. IIS-0456027, 7/1/2005-6/31/2008.

3. Project Goals • Security constructs for storage policy • meet regulatory requirements • secure deletion in versioning systems • audit trails for versioned data • Development of technology • storage system and cryptographic tools • Release an open-source file system • inexpensive compliance and privacy for everyone

4. A Paperless World • Information is becoming entirely electronic • financial records, medical records, federal data • 300 million computers storing 150,000 terabytes • Tradeoffs in electronic record keeping • eases use, sharing, and indexing/searching • creates a new set of vulnerabilities • exposure of data that are deleted or discarded • the undetected modification of archived data

5. A Paperless World Lewis Bellardo, Deputy Archivist of the United States. “Preserving Our Federal Heritage in the Digital Era: What is NARA's Role in Creating the Government's Digital Archive?” March 27, 2001 http://www.archives.gov/about/speeches/03-27-01.html

6. Regulating the Paperless World • Congress and the courts are addressing the importance electronic record management • Over 4,000 laws and regulations • Some with explicit deletion requirements • Health Insurance Portability and Accountability Act (1996) • consumer records (Gramm-Leach-Bliley, 2002) • Most with an auditability mandate • corporate records and auditing (Sarbanes-Oxley, 2002) • FISMA (2002) and the Federal Records Act • Versioning storage systems are needed

7. Fine-Grained, Secure Deletion

8. Fine-Grained, Secure Deletion • Secure deletion means that deleted data are irrecoverable • to the owner of the data or system administrators • when an adversary has physical access to a disk • when an adversary has encryption keys • Fine-grained indicates that a single version of a file may be deleted independently • complicated by inter-version data sharing

9. The Need for Secure Deletion • For privacy protection • when a disk is retired or stolen • patients have the right to redact portions of their records • To limit liability • records that go out of audit scope should do so forever • when a disk or encryption keys are subpoenaed, previously deleted data must be inaccessible • Even in permanent archives • as part of access control, i.e. changing policy • for storage management, any time data are moved

10. Audit Trails for Versioning

11. Audit Trails for Versioning • Secure digital audit model • ensures compliance with retention guidelines • history of modifications to file versions • three party protocol • data store, auditor, trusted escrow agent • Efficient constructs for auditing • incremental computation of authentication data • minimize escrowed data

12. The Virtues of Digital Audit Trails • Provable, positive statement of compliance • continuous, immutable history of changes to data • “chain of custody” for electronic records • Reduce liability exposure for auditors • responsible for the veracity of their audits • KPMG employs forensic specialists for this task • Maintain the privacy of records • audit information reveals nothing about stored data

13. Fine-Grained, Secure Deletion

14. Existing Solutions • Secure Overwrite [Gutmann 1996] • data blocks are overwritten many times with alternating patterns of 1s and 0s • magnetic media is degaussed • Key Disposal [Boneh & Lipton 1996] • data encrypted with a key • key is securely deleted, eliminating meaningful data access

15. Obstacles to Secure Deletion • Existing solutions do not translate to versioning storage systems • Secure overwriting of data blocks is slow • particularly, when data are non-contiguous • data that have been versioned are non-contiguous • Cannot dispose file keys in a versioning systems • versioning system share data between versions • blocks encrypted with a particular key need to be available in future versions

16. The Central Idea • A keyed transform • converts a data blockand a nonce • into an encrypted block and a stub • When the key is private, data are secure and authenticated • Securely deleting stub, securely deletes block, even when the key has been exposed!

17. Secure Deletion Example File Metadata 11 s0 s1 s2 … Disk C0 C1 C2

18. 17 s0 s1’ s2 … C1’ Secure Deletion Example Receive a write to block #2 at time 17 File Metadata 11 s0 s1 s2 … Disk C0 C1 C2

19. Secure Deletion Example Delete file from time 11 File Metadata 11 s0 s1 s2 17 s0 s1’ s2 … … Disk C0 C1 C2 C1’

20. Secure Deletion Example Delete file from time 11 Block C1 is deleted permanently File Metadata 11 s0 s1 s2 17 s0 s1’ s2 … … Disk C0 C1 C2 C1’

21. Features of System Design • To delete a version, stubs are securely overwritten • This securely removes all data for that version • Stubs are not secret • stored on disk as part of metadata • Stubs make for efficient, secure deletion • stubs are stored contiguously • delete a large amount of data (1 MB) by overwriting a small, contiguous region of stubs (4 KB)

22. Applicability of Secure Deletion • Stubs increase deletion performance by 200x • depends upon file size and system block size • For systems that • use disk encryption • share-content between files or versions • This includes versioning file systems and content-indexing archives

23. Deletion Performance

24. I/O Performance

25. Research Directions • Secure deletion across multiple replicas • delete a file system image and its backup(s) • ability to delete and fault-tolerance compete

26. Audit Trails for Versioning

27. authenticator A(V1) version V1 Secure Digital Audit Model • File system transmits version authenticators to escrow site • reveal nothing about the file version File System Escrow Site

28. A(V9) V1 V2 V3 V4 V5 V6 V7 V8 V9 Secure Digital Audit Model • File system accumulates versions • Occasionally transmits authenticator to escrow site • commits file system to a “version history” A(V1)A(V9)

29. Secure Digital Audit Model • At a later time, auditor requests authenticators from escrow site • auditor trusts escrow site for accurate storage and timestamps A(V1)A(V9)

30. Secure Digital Audit Model • File system produces data consistent with authenticators • verifies contents of file system have not changed V1 V2 V3 V4 V5 V6 V7 V8 V9 A(V1)A(V9)

31. Secure Digital Audit Model • Cryptographically authenticate • content of each version • chains of version, including all intermediate changes • hierarchies of files (directories and file systems) • Failure to produce matching data is a compliance failure • not a proof of wrong doing • Parallels the paper audit process • penalties for failure are criminal or financial

32. Calculating Authenticators • Problem: Methods of authenticating data exist, but are unsuitable in the versioning environment • Store copies of data at the 3rd party • Overwhelming amount of storage • Privacy concerns • Stores MACs for each version at third party • Computationally intensive • No version ordering information

33. Incremental Authentication • Built on Parallel Message Authentication Codes (PMAC) • Allows for incremental authentication • Using only the blocks that have changed • Traditional MACs are sequential (not-incremental) • Computation scales with the amount of changed data, not size of the data

34. YK Incremental Authentication Example Av0 File 11 … L0 L1 L2 Disk P0 P1 P2

35. YK 17 … L0 L1’ L2 P1’ Incremental Authentication Example Av0 Av1 File 11 … L0 L1 L2 Disk P0 P1 P2

36. 17 … L0 L1’ L2 P1’ Incremental Authentication Example Av0 Av1 File 11 … L0 L1 L2 Disk P0 P1 P2

37. Limiting Escrowed Data • Infrequent transmission of authenticators • Use hash chaining to bind versions • An auditor may verify a version chain by using any two version authenticators • First must transform into the second • Verifies interior versions implicitly

38. Av0 Av1 Avi Avn 17 13 … … L0 L0 L1 L1 Limiting Escrowed Data Example 11 … L0 L1 …

39. Research Directions • Other methods for authenticating an entire system efficiently • Approximate MACS (AMACS) authenticate a file system given only a portion of its data • Continue to develop the audit model • Storage-less 3rd party • Communities of authentication

40. Project Status -- ext3cow

41. Project Status • Secure deletion is implemented in ext3cow (www.ext3cow.com) • Audit trails are being implemented in ext3cow

42. The ext3cow File System • Open-source file system that implements file system snapshot and versioning • Captures immutable, point-in-time views of the entire file system • Novel and intuitive time-shifting interface for accessing the past • Encapsulated entirely in the file system • Low storage overhead and negligible performance degradation

43. ext3cow Status • Fully implemented file system available at: www.ext3cow.com • Thousands of visitors, hundreds of downloads • Active development mailing list • Ext3cow being used as the foundation of other research and industrial projects • UCB, UCSC, Columbia, USC • Infrant Technologies

44. ext3cow as a Compliance System • Security constructs • Enforce regulations • secure deletion provides privacy guarantees • audit trails that track how file systems evolve • Manage liability • from exposure of private data • to auditors responsible for the content of their audit • Unencumbered, open-source implementation • reduces the cost of compliance • $5B for Sarbanes-Oxley in 2004

45. Publications • Z. Peterson and R. Burns. Ext3cow: A Time-Shifting File System for Regulatory Compliance.ACM Transactions on Storage, 1(2), 190-212, 2005. • Z. Peterson, R. Burns, J. Herring, A. Stubblefield, and A. Rubin. Secure Deletion for a Versioning File System. InProceedings of the File and Storage Technology Conference(FAST), USENIX, 2005. • R. Burns, Z. Peterson, G. Ateniese, and S. Bono, Verifiable Audit Trails for a Versioning File Systems, InInternational Workshop on Storage Security and Survivability, 2005. • Z. Peterson and R. Burns. Limiting Liability in a Federally Compliant File System. InPORTIA Workshop on Sensitive Data in Medical, Financial, and Content Distribution Systems, 2004.