Proxy Certificate Revocation Verification for Constrained Devices
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In communication security systems, certificate revocation status verification is challenging for verifier devices without online connectivity or a reliable source of current time, particularly in scenarios like MirrorLink where the car head-unit lacks direct connectivity and reliable time information.
Innovation Solution
The proposed solution involves the client device acting as a proxy for online status verification, using a nonce from the authentication protocol to derive the nonce for the revocation status protocol, and sending the needed nonce prior to authentication protocol execution to reduce connectivity requirements from on-demand to periodic connectivity, allowing the verifier device to verify certificate revocation status without immediate online connectivity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the verifier device queries revocation status online using CRL or OCSP, then the certificate revocation status can be verified accurately, but the verifier device requires online connectivity and reliable time source which constrained devices lack
Solution Approach 1:
The patent introduces a trusted intermediary component (secure element or HSM) that pre-loads CRL data and nonce values during periods when the verifier device has network connectivity. This intermediary stores the revocation information locally and provides it during authentication protocols without requiring real-time online access, thus mediating between the need for accurate revocation verification and the lack of continuous connectivity
Solution Approach 2:
The system performs preliminary actions by pre-fetching and storing Certificate Revocation Lists and generating nonce values in advance during windows of network availability. The CRL data and nonces are cached in secure storage before they are needed for authentication, eliminating the requirement for on-demand connectivity during the actual verification process
2Reliability
If the verifier sends authentication request with nonce and receives response, then authentication can be performed, but multiple message exchanges are required increasing communication overhead
Solution Approach 1:
The patent merges the authentication protocol message exchange with the revocation status verification protocol. The verifier incorporates the nonce-based revocation check within the existing authentication dialogue, combining two separate protocols into one unified exchange. This reduces the total number of messages while maintaining both authentication security and revocation verification integrity
Solution Approach 2:
The authentication protocol is designed to serve multiple functions simultaneously: it performs principal authentication, verifies certificate validity, and checks revocation status all within the same message exchange sequence. The nonce serves dual purposes as both an authentication challenge and a revocation verification token, eliminating redundant communications
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A process to achieve communication security certificate revocation status verification by using the client device act as a proxy in online status verification protocol. The process comprises a mechanism to utilize a nonce of an authentication protocol request message (nonce_A) to derive the nonce for the revocation status protocol request (nonce_S) to reduce the number of message exchanges needed between the client and the verifier devices, and a mechanism to send the needed nonce (nonce_S) prior to actual authentication protocol execution to ease the connectivity requirement of client device from on-demand connectivity to periodic connectivity. Similar functionality is achieved using a random seed established between the verifier and client. The verifier picks a seed for random number generation and sends that seed to the client. Client derives the nonce_S from the seed before status protocol execution, and the verifier derives the nonce_S from the seed before proxied status response verification.