Multi-Core CRL Management for SSL Session Persistence
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-core systems, maintaining secure socket layer (SSL) session persistence and certificate revocation list (CRL) management across cores is challenging, particularly when an SSL session is disrupted, as cores may not have access to the master CRL, and certificate validation becomes complex.
Innovation Solution
A method and system for maintaining a certificate revocation list (CRL) in a multi-core device, where a core can access a secondary CRL based on the master CRL, allowing it to validate certificates and resume SSL sessions even if the core that originally established the session is not accessible.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If a multi-core system distributes SSL session management across cores, then system throughput and processing capacity are improved, but certificate validation complexity and CRL accessibility deteriorate
Solution Approach 1:
The CRL is segmented into multiple distributed copies, with each core having access to a local CRL copy. This segmentation allows parallel certificate validation across cores without requiring centralized CRL access, thereby maintaining high throughput while reducing validation complexity.
Solution Approach 2:
CRL data is pre-distributed to all cores before SSL session resumption occurs. When a core needs to validate a certificate, the CRL is already available locally, eliminating the need for real-time CRL retrieval and reducing validation complexity during session resumption.
2Speed
If a core accesses a secondary CRL instead of the master CRL, then SSL session resumption speed is improved, but certificate validation reliability may deteriorate
Solution Approach 1:
Multiple secondary CRL copies across different cores are merged into a consistent validation framework. Each core validates certificates against its local secondary CRL, and the system ensures all secondary CRLs remain synchronized with the master CRL, maintaining both fast validation and high reliability.
Solution Approach 2:
The system implements feedback mechanisms where cores periodically synchronize their secondary CRLs with the master CRL and report validation results. This feedback ensures that secondary CRLs remain current and reliable, preventing reliability deterioration while maintaining fast session resumption.
3Stability of the object's composition
If SSL session state is replicated across cores, then session persistence is improved, but memory usage and data synchronization overhead increase
Solution Approach 1:
The session state replication is extracted to a separate shared memory region or storage mechanism that is accessible by all cores. This allows session persistence information to be stored once and shared across cores, improving session persistence while avoiding duplicating entire session states in each core's memory.
Solution Approach 2:
A universal session state storage mechanism is implemented that serves all cores simultaneously. This shared storage structure allows any core to access and resume SSL sessions established by any other core, improving session persistence across the multi-core system without requiring each core to maintain separate session copies.
Data Source
Figure 1A
Figure 1B
Figure 1C
AI summary
The present invention is directed towards systems and methods for maintaining Certificate Revocation Lists (CRLs) for client access in a multi-core system. A first core may generate a secondary CRL corresponding to a master CRL maintained by the first core. The CRLs may identify certificates to revoke. The first core can store the secondary CRL to a memory element accessible by the cores. A second core may receive a request to validate a certificate. The second core can provisionally determine, via access to the secondary CRL, whether the certificate is revoked. The second core may also determine not to revoke the certificate. Responsive to the determination, the second core may request the first core to validate the certificate. The first core can determine whether to revoke the certificate based on the master CRL. The first core may send a message to the second core based on the determination.