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.


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


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


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


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


Fine-Grained, Secure Deletion


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


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


Audit Trails for Versioning


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


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


Fine-Grained, Secure Deletion


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


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


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 ||),( →


C0

Secure Deletion Example

C1 C2

s0 s1 s211 …

Disk

File Metadata


17 …

C0


C1 C2

s0 s1 s211 …

Disk

File Metadata

s0 s2

Receive a write to block #2 at time 17

C1’

s1’


C0


C1 C2 C1’

s0 s1 s211 …

Disk

s0 s1’ s217 …

File Metadata

Delete file from time 11


C0


C1 C2 C1’

s0 s1 s211 …

Disk

s0 s1’ s217 …

File Metadata

Delete file from time 11

Block C1 is deleted permanently


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)


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


Deletion Performance


I/O Performance


Research Directions

Secure deletion across multiple replicas– delete a file system image and its backup(s)– ability to delete and fault-tolerance compete


Audit Trails for Versioning


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)


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)


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)


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)


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


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


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


P0

Incremental Authentication Example

P1 P2

L0 L1 L211 …

Disk

File

Av0

YK


P0


P1 P2

L0 L1 L211 …

Disk

File

Av0

L0 L1’ L217 …

Av1

P1’

YK


P0


P1 P2

L0 L1 L211 …

Disk

File

Av0

L0 L1’ L217 …

Av1

P1’


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

)


Limiting Escrowed Data Example

L0 L111 … L0 L113 … L0 L117 ……

Av0Avn

Av1Avi


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


Project Status -- ext3cow


Project Status

Secure deletion is implemented in ext3cow (www.ext3cow.com)

Audit trails are being implemented in ext3cow


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


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


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


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.

Documents

Securely Implementing Regulatory Policy