Target-Binding Certificates for Shared Root-Key Resource Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for implementing differential access to resources on devices rely on correct configuration of multiple trusted-authority root keys, leading to storage and management burdens and vulnerabilities due to incorrect associations between resources and root keys.
Innovation Solution
Extending cryptographic certificates with target-binding information that specifies a particular asymmetric keypair on the device, allowing the same trusted-authority root key to be used for multiple resource-specific keypairs, reducing the need for multiple root keys and ensuring correct associations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple trusted-authority root keys are configured for differential access to resources, then access control granularity is improved, but storage burden and management complexity increase
Solution Approach 1:
A single trusted-authority root key is configured to serve multiple resource-specific asymmetric keypairs. The root key can verify certificates for different resources without requiring separate root keys for each resource, thereby reducing storage burden while maintaining access control granularity through certificate-level differentiation.
Solution Approach 2:
Multiple certificate verification functions are merged into a single trusted-authority root key. Instead of having separate root keys for each resource, the system combines verification capabilities for multiple resources into one shared root key, reducing the number of stored keys while preserving security boundaries through target-binding information in individual certificates.
2Reliability
If multiple trusted-authority root keys are configured for differential access, then resource separation is improved, but vulnerability to incorrect configuration increases
Solution Approach 1:
Target-binding information is pre-included in each certificate during certificate issuance. This preliminary embedding of resource-specific identifiers in certificates ensures that when verification occurs, the correct resource association is already established, preventing incorrect configurations even when multiple resources share a common root key.
Solution Approach 2:
The verification process includes checking target-binding information in certificates against the appropriate resource-specific asymmetric keypairs. This feedback mechanism ensures that even if initial configurations have errors, the system can detect and prevent incorrect associations by verifying that the certificate's target-binding matches the resource being accessed.
3Device complexity
If the same trusted-authority root key is used for multiple resource-specific keypairs, then storage burden is reduced, but difficulty in ensuring correct associations increases
Solution Approach 1:
Each certificate contains local, resource-specific target-binding information that identifies which resource-specific asymmetric keypair it corresponds to. This localized identification within each certificate allows the system to distinguish between different resources even though they share a common root key, making correct association verification straightforward through certificate inspection.
Data Source
AI summary
A first computing device maintains multiple resource-specific asymmetric keypairs that are each uniquely associated with a different protected resource on the first device, including a first resource-specific asymmetric keypair that is uniquely associated with a first protected resource. The first device engages with a second device in an authentication flow based on the first resource-specific asymmetric keypair. The first device receives, from the second device, a public-key certificate that contains target-binding data that indicates a specified asymmetric keypair. The first device checks whether the specified asymmetric keypair matches the first resource-specific asymmetric keypair. If so, and assuming any other authentication conditions are also met, the first device authenticates the second device to the first resource-specific asymmetric keypair, and grants the second device access to the first protected resource.


