CDN Edge Data Encryption with Metadata Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Content delivery networks (CDNs) face challenges in protecting data within edge locations from unauthorized access and data exposure, as existing methods are vulnerable to intruders and can lead to accidental data transfer issues, such as confused SSD threats, while also impacting throughput and resource consumption.
Innovation Solution
Implementing a system that encrypts data and metadata using client-specific keys, such as the Galois/Counter Mode (GCM) algorithm, within the CDN's edge location, allowing only the origin-facing and client-facing layers to access encryption keys, and using intermediate layers to route encrypted data without decrypting it, thus minimizing cleartext exposure and optimizing performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data is encrypted using client-specific keys throughout the edge location, then data protection and integrity are enhanced, but access to metadata becomes restricted and system complexity increases
Solution Approach 1:
The patent segments the data handling process by separating encrypted data from unencrypted metadata. Different layers (origin-facing, intermediate, client-facing) handle different forms of data with appropriate encryption levels, allowing metadata to remain accessible while data stays protected.
Solution Approach 2:
The patent introduces an intermediary encryption key management system that allows intermediate layers to route encrypted data without decrypting it. This mediator layer handles the complexity of key management while keeping the actual data encryption/decryption operations minimal at each layer.
2Reliability
If data is encrypted at all layers within the edge location, then unauthorized access is prevented, but throughput decreases due to repeated encryption and decryption operations
Solution Approach 1:
The patent applies preliminary encryption at the origin-facing layer before data enters the edge location. This way, data is already encrypted when it reaches intermediate layers, eliminating the need for repeated encryption operations and reducing processing overhead.
Solution Approach 2:
Instead of decrypting data at intermediate layers for processing, the patent inverts the approach by keeping data encrypted and only decrypting metadata or specific portions needed for routing decisions. This reversal maintains security while minimizing decryption overhead.
3Ease of operation
If all data is decrypted for processing at intermediate layers, then routing and processing are simplified, but cleartext exposure increases creating security vulnerabilities
Solution Approach 1:
The patent applies local quality by maintaining different encryption states for different parts of the data structure. The data payload remains encrypted while only necessary metadata or routing information is decrypted locally at intermediate layers, providing exactly the right level of access where needed.
Solution Approach 2:
The patent extracts only the necessary metadata from the encrypted data structure for processing at intermediate layers, leaving the main data payload encrypted. This extraction approach allows routing and processing decisions to be made without exposing the actual data content.
4Speed
If encryption keys are stored at multiple layers for easy access, then processing speed improves, but the risk of key compromise and unauthorized access increases
Solution Approach 1:
The patent changes the dimension of key storage by implementing a hierarchical key management structure across different layers. Instead of storing all keys at every layer, keys are distributed selectively, with intermediate layers having access only to metadata decryption keys while data decryption keys remain at origin-facing and client-facing layers only.
Data Source
AI summary
An edge location of a content delivery network may protect data that is stored and transmitted within the edge location while providing access to associated metadata. After an origin-facing server obtains a requested object, the server may encrypt the object using a client-specific encryption key. In some cases, the server may also separately encrypt the metadata. The encrypted object and metadata may be sent to an intermediate layer server. The intermediate server may decrypt the metadata (if it is encrypted) and determine, based on the metadata, routing for the object. The object remains encrypted at the intermediate server. In some cases, the metadata may be re-encrypted by the intermediate server. The encrypted object and metadata may be sent to a client-facing server, in accordance with the determined routing. The client-facing server may decrypt the encrypted object and send the encrypted object to the client.