Threats to privacy in the forensic analysis of database systems

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

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

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

4. Areas for Recovery • Table Storage, indexes and the transaction log are possible area for data recoverability. • Other areas are temporary table, tuple identifiers.

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

6. 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 file system space.

7. Forensic analysis of table storage(contd...)

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

9. Experiment Results

10. Experiment Results (contd…)

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

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

14. Impact of modifications

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

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