Threats to privacy in the forensic analysis of database systems

16
Threats to privacy in the forensic analysis of database systems Patrick Stahlberg, Gerome Miklau, and Brian Neil Levine Department of Computer Science University of Massachusetts, Amherst Presented by: Sweta Shrestha

description

Threats to privacy in the forensic analysis of database systems. Patrick Stahlberg, Gerome Miklau, and Brian Neil Levine Department of Computer Science University of Massachusetts, Amherst Presented by: Sweta Shrestha. INTRODUCTION. Preserving historical data. - PowerPoint PPT Presentation

Transcript of Threats to privacy in the forensic analysis of database systems

Threats to privacy in the forensic analysis of database systems

Patrick Stahlberg, Gerome Miklau, and Brian Neil LevineDepartment of Computer ScienceUniversity of Massachusetts, Amherst

Presented by:Sweta Shrestha

INTRODUCTION

Preserving historical data. Merit: recovery from system failure. Demerit: serious threat to privacy.

Forensic Analysis: Focused on the collection and analysis of data

recovered from computer systems. Unauthorized forensic analysis threatens

confidentiality Goal is to design database systems that

allow users to appropriately balance the needs for privacy and accountability.

Few related terms

Active Record: that serves a purpose for database. Expired Record: active records whose purpose has

been removed. Slack data: Records that are expired but not removed

and so are recoverable. DB slack: located in a file in use by the database system File system slack: not allocated in a db file.

Removal here onward means the secure destruction of data.

Vacuum: table reorganization command executed periodically

Areas for Recovery

Table Storage, indexes and the transaction log are possible area for data recoverability.

Other areas are temporary table, tuple identifiers.

Forensic analysis of table storage

Tables are stored in paged files. Deletion of record:

Accomplished by setting a deletion bit and hence creates a free space.

Data is not removed and fully recoverable.

Vacuum may reduce table storage and return it to file system thus creating a file system slack.

Forensic analysis of table storage (contd..)

1. State(1) shows 6 active records, occupying most of the space allocated to table storage.2. After deletion of records t3 and t5, space is freed but the data is still fully recoverable, as shown in State (2).3. Next, record t7 is inserted, utilizing free space and overwriting the recoverable t3 from above. In addition, two more deletions occur: t1 and t4, resulting in state (3).4. In the next step, the vacuum procedure executes. It reorganizes the active records (t2, t7, t6), and reduces the space allocated to the database file, as shown in (4). This leaves previously deleted record t5 and a copy of active record t6 in unallocated filesystem space.

Forensic analysis of table storage(contd...)

Forensic analysis of the transaction log

Log provides recovery from transaction and system failure.

Includes before and after images of updated data.

Logs contains months of historical data, much of which is expired but still recoverable.

For the periods of time covered by log, a wealth of sensitive data can be retained.

Experiment Results

Experiment Results (contd…)

Making database systems transparent

General Strategy: Overwrite data Destroying the key of encrypted data

Overwriting is suitable for table storage

Encryption is used for log. InnoDB is used for further

experiments.

Overwriting data

Securing deletion Purge thread (continuously running program) is

modified so that records are overwritten as they are put on the free list.

This approach incurs no additional disk I/O operations.

Securing B-Tree operation It requires changes to the code of insert, delete

and update For each of these functions, any related

operations were modified to overwrite obsolete data.

No additional I/O costs.

Impact of modifications

Encrypting the records

encrypt the log and remove the keys used for encryption.

For a log record with LSN l, cryptographic key Kl is generated.

Keys are generated as an ordered sequence using a hash chain

Kn=H(Kn-1) Kn=Hn-1(Ki) where i<n Kcurrent is written on stable storage To destroy data overwrite the key.

CONCLUSION

Database system doesn’t remove the data securely. It’s a threat.

Modification was done in the code to handle this issue.

Modifications thus made did not produce any significant overhead.

Thank You.