Ephemeral Diffie-Hellman Proxy for Forward Secrecy
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In content delivery networks (CDNs), customers are hesitant to share their private TLS keys with service providers, and there is a requirement for data to remain undecrypted and verifiably authentic throughout transactions, posing challenges for secure key exchange and data transmission.
Innovation Solution
Implementing an RSA proxy service that offloads the decryption of encrypted pre-master secrets to an external server, allowing the CDN to manage the private key without storing it on the terminating server, and using Ephemeral Diffie-Hellman RSA key exchange to enhance security and prevent replay attacks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If the CDN stores the private TLS key on the terminating server for decryption, then the decryption operation can be performed locally, but the security is compromised because the private key is exposed and shared with the service provider
Solution Approach 1:
The private key is extracted from the terminating server and stored only in the key management server. The terminating server performs decryption by forwarding encrypted pre-master secrets to the key management server, which returns the decrypted values without the terminating server ever possessing the private key locally.
Solution Approach 2:
The key management server acts as an intermediary between the terminating server and the decryption operation. It holds the private key securely and performs decryption on behalf of the terminating server, eliminating the need for the terminating server to store or handle the private key directly.
2Productivity
If the CDN uses traditional RSA key exchange, then the decryption can be performed efficiently, but forward secrecy is not achieved and past communications can be decrypted if the key is compromised
Solution Approach 1:
The system uses ephemeral Diffie-Hellman key exchange where the private key is generated anew for each session and then discarded. This dynamic key generation ensures that even if the key management server is compromised in the future, past session keys cannot be derived because each session used a unique, ephemeral key pair.
Solution Approach 2:
The patent changes the cryptographic parameters from static RSA key pairs to ephemeral Diffie-Hellman key pairs that are generated and destroyed for each session. This parameter change enables forward secrecy while maintaining the ability to perform efficient decryption through the key management server.
3Reliability
If the private key is centralized in the key management server, then key security is improved and administrative control is enhanced, but the system complexity increases due to additional communication overhead
Solution Approach 1:
The key management server performs multiple functions: it securely stores the private key, generates ephemeral Diffie-Hellman key pairs, performs decryption operations, and manages session keys. This multi-functionality consolidates security operations in a single centralized component, managing complexity rather than distributing it across multiple systems.
Data Source
AI summary
An infrastructure delivery platform provides a proxy service as an enhancement to the TLS/SSL protocol to off-load to an external server the generation of a digital signature, the digital signature being generated using a private key that would otherwise have to be maintained on a terminating server. Using this service, instead of digitally signing (using the private key) “locally,” the terminating server proxies given public portions of ephemeral key exchange material to the external server and receives, in response, a signature validating the terminating server is authorized to continue with the key exchange. In this manner, a private key used to generate the digital signature (or, more generally, to facilitate the key exchange) does not need to be stored in association with the terminating server. Rather, that private key is stored only at the external server, and there is no requirement for the pre-master secret to travel (on the wire).