Server Authentication via Multiple Non-Overlapping Certificate Chains
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods to protect certificate authorities (CAs) from compromise are inadequate, as they often require notification and updating of clients after a compromised CA signing key is detected, which can lead to widespread attacks, and existing solutions like certificate revocation lists and public key pinning are complex or difficult to implement effectively.
Innovation Solution
A client implements a public key acceptance policy that requires multiple certificates from different trusted certificate authorities for a server's public key, ensuring the certificates are valid and non-overlapping, thereby increasing the difficulty for attackers to compromise the trust anchor and establishing a secure channel.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If certificate revocation lists or on-line certificate status are used to address compromised CAs, then security is improved after compromise detection, but implementation complexity and scalability are worsened due to difficulty in notifying and updating clients in short time periods
Solution Approach 1:
The system performs preliminary actions by having servers proactively register their public keys with multiple CAs before any compromise occurs. This creates pre-established certificate chains that are ready for immediate use, eliminating the need for complex real-time notification and update mechanisms when a compromise is detected. The client's public key acceptance policy is also established in advance, specifying the required number of valid chains and trust conditions.
2Reliability
If multiple certificates from different CAs are required for server authentication, then security is improved by increasing the number of CAs an attacker must compromise, but device complexity is worsened due to the need to manage and validate multiple certificate chains
Solution Approach 1:
The system employs self-service mechanisms where the client automatically manages the complexity of validating multiple certificate chains. The client's public key acceptance policy automatically evaluates multiple chains, checks their validity, verifies non-overlapping intermediate and root CAs, and determines trust satisfaction without requiring manual intervention. This shifts the complexity burden from manual certificate management to automated policy evaluation.
3Reliability
If public key pinning or DANE solutions are implemented to associate public keys with server names, then security is improved, but ease of operation is worsened due to complex implementation issues and scalability challenges
Solution Approach 1:
The system segments the authentication mechanism by separating the trust anchor (CA) from the certificate validation process. Instead of pinning specific public keys or implementing complex DANE solutions, the approach divides authentication into independent certificate chains from different CAs. Each chain can be validated independently, and the client policy specifies the number of valid chains required. This segmentation simplifies implementation compared to key pinning while maintaining security.
Data Source
AI summary
A client seeking to establish a cryptographically-secure channel to a server has an associated public key acceptance policy. The policy specifies a required number of certificates that must be associated with the server's public key, as well as one or more conditions associated with those certificates, that must be met before the client “accepts” the server's public key. The one or more conditions typically comprise a trust function that must be satisfied before a threshold level of trust of the client is met. A representative public key acceptance policy would be that certificate chains for the public key are valid and non-overlapping with different root CAs, and that some configurable number of those chains be present. The technique may be implemented within the context of an existing client-server SSL/TLS handshake.