Write-Only Filesystem Key Management for Compromised Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing file system encryption schemes fail to protect sensitive data from attackers when the system is compromised, as they require the private key for decryption, which is not addressed by current methods like the '866 patent.
Innovation Solution
A method that implements a write-only, limited-read filesystem using symmetric and asymmetric encryption keys, where the filesystem manages keys to ensure data is not decrypted by unauthorized parties, generating public and private key pairs, and deleting symmetric keys when read conditions are violated, allowing authorized parties to regenerate keys.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Power
If symmetric key encryption is used for file encryption, then encryption/decryption efficiency is improved, but security is worsened when the system is compromised as the symmetric key must be stored on the system
Solution Approach 1:
The patent extracts the symmetric decryption key from the encrypted file and stores it separately in a key store. When a process needs to read encrypted data, the filesystem retrieves the symmetric key from the key store rather than storing it within the encrypted file structure. This separation ensures that even if the system is compromised, the symmetric key is not automatically available with the encrypted data.
Solution Approach 2:
The patent introduces an asymmetric key pair as an intermediary mechanism. The asymmetric private key is used to decrypt the symmetric key, which then decrypts the encrypted data. This two-layer approach allows the symmetric key to be stored securely in the filesystem while requiring asymmetric key authentication for access, providing both efficiency and security.
2Reliability
If asymmetric key encryption is used for file encryption, then security is improved, but encryption/decryption efficiency is worsened due to the computational overhead
Solution Approach 1:
The patent segments the encryption process into two distinct layers: an outer asymmetric encryption layer for security and an inner symmetric encryption layer for efficiency. The asymmetric key pair handles key management and authentication, while the symmetric key handles the actual data encryption and decryption operations, combining the security benefits of asymmetric encryption with the performance benefits of symmetric encryption.
Solution Approach 2:
The patent performs preliminary asymmetric decryption of the symmetric key before the actual data decryption occurs. The symmetric key is decrypted from its asymmetric-encrypted form in advance and cached in memory during the lifetime of the filesystem. This preliminary action ensures that the computationally intensive asymmetric operation is performed only once, while subsequent data operations use the efficient symmetric algorithm.
3Ease of operation
If the symmetric key is stored in the filesystem for decryption, then read access is improved, but security is worsened as the key remains vulnerable to attacks
Solution Approach 1:
The patent implements dynamic key management where the symmetric key is loaded into memory when the filesystem is mounted and is automatically removed or invalidated when the filesystem is unmounted. The key exists in an active state only during the operational lifetime of the filesystem, reducing the window of vulnerability to attacks. This dynamic approach balances ease of operation during active use with security when the system is inactive.
Data Source
AI summary
A secure filesystem provides write-only access with limited read. The filesystem stores data as an encrypted block on a user machine using a symmetric (active) key, along with metadata including a read condition. While the read condition is valid, local applications can read the data using the active key. When the read condition becomes invalid, the active key is deleted so local applications no longer have access. However, the filesystem encrypts the active key to yield an inactive key, using an RSA public key. The corresponding private key is sent to an authorized party machine, but deleted from the user machine. Thus the user machine is unable to decrypt the inactive key, but the authorized party machine can still read the data by first decrypting the inactive key using the private key to regenerate the active key, and then decrypting the encrypted block using the regenerated active key.