Group-Level Encryption Key Management in In-Memory Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In cloud-based, multi-tenant applications using in-memory databases, existing methods fail to efficiently manage group-level database encryption keys, ensuring customer data privacy without requiring application redesign and supporting graceful failure during key revocation.
Innovation Solution
A method that iterates through persisted data pages to create a transient in-memory data structure mapping encryption group identifiers to key identifiers and group-level encryption keys, allowing for efficient encryption and decryption without persisting keys, and utilizing a key management system and local secure store for secure key management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data-volume-level encryption is used to protect persisted data, then physical security is improved, but group-level data privacy is lost
Solution Approach 1:
The patent divides the encryption system into multiple hierarchical levels: data-volume-level encryption for physical security and group-level encryption keys for customer-specific data privacy. Each customer group receives unique encryption keys, segmenting the encryption protection at different granularities to simultaneously achieve both physical security and group-level privacy.
2Ease of operation
If group-level encryption keys are persisted to ensure key availability, then key accessibility is improved, but security is worsened due to key exposure risk
Solution Approach 1:
The patent extracts the actual encryption key values from the persisted database structure, storing only key identifiers and metadata in the data pages. The actual group-level encryption keys are kept separate in secure key management systems, not persisted in the database itself. This separation allows key accessibility through identifiers while maintaining security by preventing key exposure in the database.
3Reliability
If encryption keys are revoked to enhance security, then security is improved, but system availability deteriorates due to inability to access encrypted data
Solution Approach 1:
The patent implements preliminary versioning and save point mechanisms that track historical encryption key assignments. When keys are revoked, the system maintains metadata about previous key assignments and their validity periods. This allows the system to gracefully handle key revocation by switching to previously valid keys for existing data, maintaining availability while enabling security updates through controlled key lifecycle management.
4Adaptability or versatility
If application redesign is implemented to support group-level encryption, then encryption flexibility is improved, but implementation complexity increases
Solution Approach 1:
The patent introduces an intermediary encryption manager component that handles all group-level encryption key management operations. This mediator translates high-level encryption requirements into low-level cryptographic operations, shielding applications from complexity. The encryption manager automatically retrieves appropriate keys, handles key rotation, and manages key revocation, providing encryption flexibility without requiring application redesign or increasing implementation complexity for end users.
Data Source
AI summary
Computer-readable media, methods, and systems are disclosed for managing group-level database encryption keys under group-level encryption in a database management system. Upon startup of the database management system, persisted database entries are sequentially processed to produce an in-memory data structure comprising a set of encryption group identifier metadata tuples having an encryption group identifier and a valid-from save point cycle version. The set of encryption group identifier metadata tuples is mapped to a set of key identifier tuples including a local secure store identifier and a group-level encryption key identifier. A set of group-level encryption keys is received from a key management system, according to which a group-level encryption key is mapped to each encryption group identifier metadata tuple. Finally, an in-memory representation of the mapping between the set of encryption group identifier metadata tuples, the set of key identifier tuples, and the set of group-level encryption keys is constructed.