Securely Implementing Regulatory Policy
description
Transcript of Securely Implementing Regulatory Policy
Department of Computer Science, Johns Hopkins University
Securely ImplementingRegulatory Policy
Randal C. Burnspresentation to the
Library of Congress
2 December 2005
DIGARCH presentation to LoC, 2 Dec 2005
ProjectNational 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.
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
Fine-Grained, Secure Deletion
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
Audit Trails for Versioning
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
Fine-Grained, Secure Deletion
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
The Central Idea
A keyed transform – converts a data block and 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!
iiik sCNBf ||),( →
DIGARCH presentation to LoC, 2 Dec 2005
C0
Secure Deletion Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
DIGARCH presentation to LoC, 2 Dec 2005
17 …
C0
Secure Deletion Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
s0 s2
Receive a write to block #2 at time 17
C1’
s1’
DIGARCH presentation to LoC, 2 Dec 2005
C0
Secure Deletion Example
C1 C2 C1’
s0 s1 s211 …
Disk
s0 s1’ s217 …
File Metadata
Delete file from time 11
DIGARCH presentation to LoC, 2 Dec 2005
C0
Secure Deletion Example
C1 C2 C1’
s0 s1 s211 …
Disk
s0 s1’ s217 …
File Metadata
Delete file from time 11
Block C1 is deleted permanently
DIGARCH presentation to LoC, 2 Dec 2005
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)
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
Deletion Performance
DIGARCH presentation to LoC, 2 Dec 2005
I/O Performance
DIGARCH presentation to LoC, 2 Dec 2005
Research Directions
Secure deletion across multiple replicas– delete a file system image and its backup(s)– ability to delete and fault-tolerance compete
DIGARCH presentation to LoC, 2 Dec 2005
Audit Trails for Versioning
DIGARCH presentation to LoC, 2 Dec 2005
Secure Digital Audit Model File system transmits version authenticators to escrow site
– reveal nothing about the file version
File System Escrow Site
version V1
authenticator A(V1)
DIGARCH presentation to LoC, 2 Dec 2005
Secure Digital Audit Model File system accumulates versions Occasionally transmits authenticator to escrow site
– commits file system to a “version history”
V1 V2 V3 V4 V5
V6 V7 V8 V9
A(V9)
A(V1)A(V9)
DIGARCH presentation to LoC, 2 Dec 2005
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)
DIGARCH presentation to LoC, 2 Dec 2005
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)
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
P0
Incremental Authentication Example
P1 P2
L0 L1 L211 …
Disk
File
Av0
YK
DIGARCH presentation to LoC, 2 Dec 2005
P0
Incremental Authentication Example
P1 P2
L0 L1 L211 …
Disk
File
Av0
L0 L1’ L217 …
Av1
P1’
YK
DIGARCH presentation to LoC, 2 Dec 2005
P0
Incremental Authentication Example
P1 P2
L0 L1 L211 …
Disk
File
Av0
L0 L1’ L217 …
Av1
P1’
DIGARCH presentation to LoC, 2 Dec 2005
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€
Avi= PMAC(v i)⊗Y (Avi−1
)
DIGARCH presentation to LoC, 2 Dec 2005
Limiting Escrowed Data Example
L0 L111 … L0 L113 … L0 L117 ……
Av0Avn
Av1Avi
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
Project Status -- ext3cow
DIGARCH presentation to LoC, 2 Dec 2005
Project Status
Secure deletion is implemented in ext3cow (www.ext3cow.com)
Audit trails are being implemented in ext3cow
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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
DIGARCH presentation to LoC, 2 Dec 2005
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. In Proceedings 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, In International Workshop on Storage Security and Survivability, 2005.
Z. Peterson and R. Burns. Limiting Liability in a Federally Compliant File System. In PORTIA Workshop on Sensitive Data in Medical,
Financial, and Content Distribution Systems, 2004.