Securely implementing regulatory policy
Download
1 / 45

Securely Implementing Regulatory Policy - PowerPoint PPT Presentation


  • 51 Views
  • Uploaded on

Securely Implementing Regulatory Policy. Randal C. Burns presentation to the Library of Congress 2 December 2005. Project. National Science Foundation and Library of Congress. Digital Archives , NSF 04-592. “Securely Managing the Lifetime of Versions in Digital Archives.”

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Securely Implementing Regulatory Policy' - shen


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Securely implementing regulatory policy

Securely ImplementingRegulatory Policy

Randal C. Burns

presentation to the

Library of Congress

2 December 2005


Project
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.


Project goals
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
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 world1
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
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 deletion1
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
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 versioning1
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
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



Existing solutions
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
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
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!


Secure deletion example
Secure Deletion Example

File Metadata

11

s0

s1

s2

Disk

C0

C1

C2


Secure deletion example1

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


Secure deletion example2
Secure Deletion Example

Delete file from time 11

File Metadata

11

s0

s1

s2

17

s0

s1’

s2

Disk

C0

C1

C2

C1’


Secure deletion example3
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’


Features of system design
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
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




Research directions
Research Directions

  • Secure deletion across multiple replicas

    • delete a file system image and its backup(s)

    • ability to delete and fault-tolerance compete



Secure digital audit model

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


Secure digital audit model1

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)


Secure digital audit model2
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 model3
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 model4
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
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
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


Incremental authentication example

YK

Incremental Authentication Example

Av0

File

11

L0

L1

L2

Disk

P0

P1

P2


Incremental authentication example1

YK

17

L0

L1’

L2

P1’

Incremental Authentication Example

Av0

Av1

File

11

L0

L1

L2

Disk

P0

P1

P2


Incremental authentication example2

17

L0

L1’

L2

P1’

Incremental Authentication Example

Av0

Av1

File

11

L0

L1

L2

Disk

P0

P1

P2


Limiting escrowed data
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


Limiting escrowed data example

Av0

Av1

Avi

Avn

17

13

L0

L0

L1

L1

Limiting Escrowed Data Example

11

L0

L1


Research directions1
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
Project Status

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

  • Audit trails are being implemented in ext3cow


The ext3cow file system
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
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
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
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.


ad