Volatile Key Database for Secure File Deletion

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for making data permanently unreadable face challenges such as high storage requirements and lack of scalability when deleting files on demand, as using a single key for multiple files renders it impossible to delete the key without making all other files encrypted with that key unreadable.

Innovation Solution

A system where files are encrypted with a key K, stored in non-volatile storage, and the key K is stored in a key database in volatile storage, which is then encrypted and stored non-volatilely. The key manager maintains a decryption key, allowing the file manager to interact for decryption upon crashes, and keys are managed to ensure secure deletion and recovery.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If a single key is used to encrypt multiple files, then storage space is reduced and key management is simplified, but the ability to delete individual files permanently is lost

Engineering Contradiction:
Improvestorage spaceVSAvoidfile deletion capability
Core Design Contradiction:
Quantity of substanceVSEase of operation

Solution Approach 1:

The patent segments the encryption key management by introducing hierarchical key structures (master keys, file-specific keys, and session keys) and separate key storage locations (encrypted key store, secure enclave, external key repository). This allows individual file keys to be deleted without affecting other files, while maintaining efficient storage through key reuse and derivation.

Inventive Principle:
Principle #1Segmentation

2Speed

If keys are stored in volatile storage for easy access, then decryption speed is improved, but data security is compromised if the system crashes

Engineering Contradiction:
Improvedecryption speedVSAvoiddata recovery after crash
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent implements preliminary action by pre-encrypting keys with multiple encryption layers before storing them in volatile memory. Recovery keys are pre-stored in secure non-volatile locations, and encrypted key backups are maintained externally. This allows the system to quickly decrypt data during normal operation while providing multiple recovery paths if a crash occurs.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If backup copies of data are created and stored at different locations, then data loss is prevented, but making deleted data permanently unreadable becomes complicated

Engineering Contradiction:
Improvedata preservationVSAvoidkey management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the key management complexity from the data storage system by separating keys from data. Keys are stored in dedicated secure key stores with their own encryption and management mechanisms, while data is stored in standard storage locations. This allows independent management of data backups and key deletion, simplifying the process of making deleted data permanently unreadable.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS7596696B1Efficiently managing keys to make data permanently unreadable
Publication Date: 2009.09.29 ORACLE AMERICAN INC
  • US7596696B1 patent drawing
  • US7596696B1 patent drawing
  • US7596696B1 patent drawing

AI summary

One embodiment of the present invention provides a system that facilitates making the files permanently unreadable. During operation, the system encrypts a file with a key K at a file manager and then stores the encrypted file in non-volatile storage. Next, the system stores the key K in a key database located in volatile storage at the file manager. The system then encrypts the key database, and stores the encrypted key database in non-volatile storage. Additionally, a key that can be used to decrypt the encrypted key database is maintained by a key manager, and is not maintained in non-volatile form by the file manager. In this way, if the file manager crashes, losing the contents of its volatile storage, the file manager must interact with the key manager to decrypt the encrypted key database.