Efficient cancellation support for digital services and offline operation
The two-stage validation method with reduced size certificate revocation lists and explicit non-revocation certificates addresses the inefficiencies and security risks of offline certificate revocation, ensuring accurate and secure certificate status without constant network access.
Patent Information
- Application Number
- DE102023110659
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-04-26
- Publication Date
- 2024-12-19
- Estimated Expiration
- 2043-04-26
AI Technical Summary
Existing certificate revocation methods for offline operations are inefficient and prone to false positives, especially in decentralized systems like Self-Sovereign Identity (SSI), leading to security risks and system failures due to invalid certificate checks.
A two-stage validation method using reduced size certificate revocation lists combined with explicit non-revocation certificates, where nodes check for false positives and request non-revocation certificates before going offline, ensuring accurate certificate status without constant network access.
This approach reduces the risk of invalid certificates and false positives, maintaining system security and integrity during offline operations by local validation and efficient certificate management.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[0001] The invention relates to digital services that use certificates to secure communications, and more particularly to digital services that use certificates that serve as an access key for other services or that prove identity or authorization in offline operation where communication nodes, such as vehicles, are not continuously connected to a network, such as the Internet.
[0002] DE 10 2017 128 455 A1 discloses a vehicle diagnostic device and a method for managing a certificate thereof, in particular a method for performing diagnostic communication with a vehicle using a diagnostic device, which comprises: acquiring a certificate revocation list (CRL) corresponding to a certificate of the diagnostic device from an external device, verifying a validity of the certificate using the acquired CRL, performing authentication with the vehicle when the validity of the certificate is verified, and starting diagnostic communication between the diagnostic device and the vehicle when the authentication is performed.
[0003] Certificates are not only typical for public key infrastructures used, for example, for corporate networks, where websites, for example, can have a certificate that ensures that the web page content originates from the actual owner of the website (i.e., retrieved without any man-in-the-middle), but also for mobile services or V2X (Vehicle to Everything) services. In the specific context of vehicle systems, secure communication and component identification are crucial for ensuring security and reliability.
[0004] However, certificates may have become invalid or may become invalid over time. This can pose a security risk to the system. To address this problem, certificate revocations are possible.
[0005] Revoked certificates are certificates that have been invalidated before their expiration date, usually due to a compromise or suspected compromise. Ephemeral certificates have a limited validity period, reducing the window of opportunity for an attacker to exploit a compromised certificate.
[0006] One challenge with revocation, however, is that all involved parties must be notified of the revocation. To achieve this, lists of revoked or suspended certificates (distributed by central libraries or repositories) and / or short-lived certificates are typically used.
[0007] The disadvantages of current risk mitigation solutions, such as distributing lists of revoked certificates, using only short-lived certificates, and / or issuing non-revoked certificates, include that the lists can be very large, that certificates need to be updated and changed frequently, or that certificates are designed for use in specific environments.
[0008] Self-Sovereign Identity (SSI) is a decentralized identity model that provides a secure and privacy-compliant way for automotive components to establish their identities and communicate with each other.
[0009] In offline mode, SSI can be implemented using certificates, which are digital documents that link an identity to a public key. Certificates can be used to prove the authenticity of a component's identity and establish a secure communication channel.
[0010] In the automotive sector, offline SSI can provide a secure and reliable way for components to communicate and identify each other using certificates with revoked certificate lists (CRLs) and / or short-lived certificates. This can improve the security and performance of vehicle systems and protect them from malicious attacks.
[0011] Recent work on optimizing certificate revocation lists, including the use of typical techniques such as hash functions or Bloom filters, is presented, for example, in Chotkan, Rowdy, Jérémie Decouchant, and Johan Pouwelse: "Distributed Attestation Revocation in Self-Sovereign Identity." 2022 IEEE 47th Conference on Local Computer Networks (LCN). IEEE, 2022.
[0012] Currently, there are several options for handling certificate revocation lists, especially for offline operation. This is important for critical services such as billing, which should be able to operate even in the event of network disruptions.
[0013] Existing solutions and approaches typically include offline storage of certificate chains, as well as an approach using short-lived certificates, an approach using certificates that attest to non-revocation status, an approach using explicit certificate revocation lists, and / or an approach with possible compression.
[0014] The disadvantage, however, is that short-lived certificates are impractical for longer-lived services or individuals and may require regular and frequent reissuance of many certificates, which in turn can cause problems if a particular device is not used for an extended period and therefore no valid certificates are available when the device is turned back on. Certificates that attest to non-revocation status are similar to the ones above, only with a reverse statement. Explicit certificate revocation lists must be distributed to everyone, or at least to all relevant parties. Compression techniques can be efficient at compressing, i.e., reducing the size of revocation or block lists. Lossless compression, such as "zip" and the like, can be used, but is not as effective because certificates as used here tend to contain random data.There are more effective compression techniques, such as Bloom filters, but compression based on Bloom filters can lead to losses that may even result in false positives or errors in certificate revocation lists being reduced, which can cause a valid certificate to be detected as invalid.
[0015] Since the current solutions and approaches mentioned above generally require a permanent online connection (a "connection setup"), they do not represent a complete trust configuration. This approach is difficult when support for offline operation is required. In the case of offline operation, central repositories containing certificate revocation lists are not accessible (at least not permanently).
[0016] The invention is based on the object of preventing compromised certificates in offline SSI operation by providing a reliable access key for digital services via a two-step validation for reliable authentication.
[0017] This object is achieved by the subject matter of claim 1 and / or alternatively by claim 3. Advantageous developments of the invention are the subject matter of the appended subclaims.
[0018] A fundamental idea of the present invention is to use a reduced-size certificate revocation list, which may contain invalidations and / or false positives, and to verify this list with explicit non-revoked certificates or non-revocation certificates. The certificates, where a certificate is, for example, a document signed by a trusted authority, confirm the non-revocation status. Explicit certificate revocation lists are distributed in compressed form to all or at least all relevant parties, hereinafter also referred to as nodes. The nodes can check whether they or other nodes with which they are connected and whose data is known are affected by a false positive problem. Validation is performed via the non-revocation certificate and mapping the authentication to the nodes (vehicle / service nodes) in a step-by-step approach.In other words, the basic idea of the present invention is to combine the approach or solution of compressed certificate revocation lists with confirmations of non-revocation status.
[0019] Specifically, according to a first aspect of the present invention, a method for efficient revocation support for digital services and offline operation is provided, wherein the digital services use certificates to provide authorization and / or prove identity or authorization in a public key infrastructure, for mobile services, or for V2X services. The method comprises creating a certificate revocation list by a revocation authority entity, reducing the size of the created certificate revocation list, and distributing the reduced certificate revocation list in an online mode using centralized revocation propagation to at least all relevant nodes of a target network.Before entering an offline mode, one of at least all relevant nodes of the target network is adapted to receive the distributed reduced certificate revocation list in order to check locally whether it is affected by an invalidation or not and, if so, to request an explicit non-revocation certificate from the revocation authority entity.
[0020] It is noted that entry into offline mode may already be a possible entry into offline mode, and the local check preferably includes, but is not limited to, the check at or in the end nodes. Local checking using a predetermined checking entity or device in a local network is also conceivable. It is further noted that invalidity in the case of a (purely) local list may also mean that at least one of the at least all relevant nodes is incorrectly covered or not covered by the reduced list, which also represents an error case within the meaning of the present invention.
[0021] Advantageously, in accordance with this method and the present invention, a reduced or reduced-size certificate revocation list is distributed in advance while a device or node is still online, and each device or node checks for a false positive. If so, it appropriately requests an unrevoked certificate. As a result, the method combines the advantages of distributed lists of revoked certificates, the use of only short-lived certificates, and the issuance of "unrevoked" certificates, resulting in reduced risk in offline transactions.
[0022] According to a second aspect of the present invention, which depends on the preceding first aspect, the method comprises a compression technique for compressing the created certificate revocation list, thereby reducing the size of the list.
[0023] According to a third aspect of the present invention, which depends on the preceding first or second aspect, the method comprises selecting a subset of the created and / or compressed certificate revocation list for a predetermined geographical area and for a subset of nodes that are located in and / or can enter this area.
[0024] According to a fourth aspect of the present invention, which depends on the preceding second or third aspect, before entering an offline mode, at least one of the at least all relevant nodes of the target network is adapted to receive the distributed compressed certificate revocation list to locally check whether or not it is affected by a false positive, and, if so, to request an explicit non-revocation certificate from the revocation authority entity. Advantageously, the local non-revocation check increases efficiency.
[0025] According to a fifth aspect of the present invention, which depends on the third aspect, before entering an offline mode, at least one of the at least all relevant nodes of the target network is designed to receive the distributed reduced certificate revocation list in order to locally check whether it is affected by an invalidity due to the absence or non-existence of a certificate, and if so, to request an explicit non-revocation certificate from the revocation authority entity. Advantageously, the local check for non-revocation increases efficiency. It is noted that regionally local lists can consist of multiple lists, so that in offline mode, it may be the case that two or different communication partners have different lists. It is therefore understood that different lists are or at least can be distributed in different regions.However, the core of the invention is not affected by this.
[0026] According to a sixth aspect of the present invention, which depends on any one of the preceding first to fifth aspects, the requested explicit non-revocation certificate is adapted to be valid at least until the next update of the compressed certificate revocation list distributed to the node after re-entering online mode. By maintaining the validity of an explicit non-revocation certificate at least until the receipt of an updated compressed certificate revocation list, repeated checks during an offline period without local changes to certificates can advantageously be eliminated.
[0027] According to a seventh aspect of the present invention, which depends on any one of the preceding first, second, or fourth to sixth aspects, the certificate revocation list is compressed by a factor of between 10 and 100. Factors between 10 and 100 represent a practical compromise between reducing the size of the certificate revocation list and the probability of generating false positive results from the perspective of tolerable risk. It is understood that factors between 10 and 100 are given merely as examples and are not limited thereto.
[0028] According to an eighth aspect of the present invention, which depends on any of the preceding first to seventh aspects, a predetermined limit of node mobility is set, services requiring a predetermined proximity are selected, and the size of the certificate revocation list is created with a correspondingly reduced size. Further restricting parameters such as node mobility and required proximity advantageously enables further reduction of the certificate revocation list without increasing the cost of a higher compression factor.
[0029] According to a ninth aspect of the present invention, which depends on any one of the preceding first to eighth aspects, a node is adapted to perform the false positive check on behalf of other nodes. If other entities, e.g., in a mobile network, know the local identities and certificates of (e.g., directly) connected devices, the processing load on these devices can be advantageously reduced.
[0030] According to a tenth aspect of the present invention, which depends on any of the preceding first to ninth aspects, local revocation and / or false positive lists are distributed via direct communication between nodes when they are offline. Direct communication between devices that are offline as such from a higher-level network, such as a cellular network, advantageously facilitates the offloading of workloads and the propagation of results of processing performed by one device on behalf of another.
[0031] The invention is intended to advantageously reduce the risk of invalid / revoked certificates for an offline case in which, for example, a mobile network is not reachable or not functional and therefore the connection establishment for a certificate check is not a complete trust configuration, as well as to reduce the effort for providing a revocation status before switching from online to offline.
[0032] In the above context and without limitation, various extensions and / or optimizations are possible, as set out below.
[0033] The invention will now be described in more detail with reference to the drawings and the corresponding detailed description, in which: Fig. 1 shows a known connection configuration where a certificate check is performed without full trust; Fig. Figure 2 shows a configuration according to the present invention, indicating a certificate check in possible online operation and a certificate check in the offline case; Fig. 3 shows an example scenario of a trust connection configuration using a certificate authority in which the present invention is used; and Fig. 4 shows an example scenario of a trust connection configuration using multiple certificate authorities in which the present invention is used.
[0034] As mentioned at the beginning, there are currently several options for handling certificate revocations or certificate revocation lists, especially in offline mode. Handling certificate revocation lists in offline mode, i.e., in cases where, for example, a mobile network is unavailable or not functioning, is necessary to reduce the risk of invalid certificate checks and is important, for example, for critical services such as billing, which should be possible even in the event of network disruptions.
[0035] Fig. Figure 1 shows a common connection configuration where a certificate check is performed without full trust. In such a constellation, the options or solutions for risk mitigation, as mentioned above, include the distribution of explicit certificate revocation lists with revoked certificates to all or all relevant parties or nodes. However, such a list can become very extensive. Using only short-lived certificates is another possibility. However, short-lived certificates must be frequently updated and changed. Another possibility is the issuance of so-called non-revoked certificates. The issuance of non-revoked certificates is somewhat similar to short-lived certificates and is used, for example, in the ID Union network developed by the IDunion organization, which aims to create an open ecosystem for decentralized identity management.
[0036] In some scenarios, offline systems may not have a working network connection to check the status of certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. This can pose a challenge to maintaining system security and integrity, especially if a certificate needs to be revoked before its expiration date.
[0037] Fig. Figure 2 illustrates a configuration according to the present invention, showing a certificate check in a possible online operation and a certificate check in the offline case. More specifically, Fig. 2 an online operating part in the upper part and an offline operating part in the lower part, separated by a dashed line.
[0038] In accordance with Fig. 2 During online operation, at least one compressed certificate revocation list is downloaded and a check for false positive certificates or false positives is performed regularly. During offline operation, the most recent compressed certificate revocation list and / or non-revocation certificates are used.
[0039] As mentioned above, certificate revocation lists are used to maintain a list of revoked certificates within a system. Since these can become quite large, certificate revocation lists can be compressed, for example, using hashes and Bloom filters, to remove redundant information and encode the remaining information in a more efficient format to reduce their size and improve performance.
[0040] However, this process can result in the compression of revoked certificate records that have similar characteristics to non-revoked certificates. When a compressed certificate revocation list is used to verify the validity of a certificate, this can result in a valid certificate being incorrectly identified as revoked, resulting in a false positive, which can lead to incorrect or incomplete data retrieval.
[0041] False positives can have significant consequences in the automotive sector, where safety-critical systems rely on the accuracy and reliability of certificate verification. A false positive can lead to a component being incorrectly classified as compromised or invalid, resulting in the disruption of critical functions or even system failure.
[0042] To reduce the risk of false positives introduced by the compression of certificate revocation lists, various techniques have been proposed, such as using multiple certificate revocation lists with different compression schemes and thresholds or using additional information such as certificate status information (CSI) or OCSP (Online Certificate Status Protocol) responses to supplement the certificate revocation lists.
[0043] To mitigate this problem, the present invention uses explicit non-revocation certificates (ENRCs) to ensure the integrity of compressed data by providing a mechanism for detecting and correcting errors in the data stream. For example, and not limited to, in the context of mobile networks and vehicles or automobiles, explicit non-revocation certificates are used to ensure that compressed data transmitted over the network or stored in the vehicle is correct and complete.
[0044] More precisely, in the Fig. In the configuration shown in Figure 2, a certificate revocation list can be compressed, for example, using techniques such as those described in Chotkan et al. As mentioned above, such techniques are typically hash functions or Bloom filters, which can be very efficient at compressing certificate revocation lists. However, these compressed lists may contain errors, as these techniques generally tend to generate false positives with a certain probability (for example, a technique that relies on a 907.24 KiB Bloom filter, uses 10 hash functions, and stores 100,000 elements has a probability of false positives of 1 in 1 billion).
[0045] While compression can lead to unwanted false positives, meaning valid certificates can be identified as invalid, one advantage of compression is that compressed lists can be efficiently distributed across the network (using an existing protocol scheme / normal online communication), significantly saving network resources. A compression factor can be, for example, 10 or 100, or a range between these factors.
[0046] According to the invention, such compressed certificate revocation lists with introduced false positives are used, and the problem of false positives is solved by using explicit non-revocation certificates. An explicit non-revocation certificate (ENRC) is a type of digital certificate used to ensure the integrity of data, especially in situations where the data has been compressed or otherwise altered. It should be noted that other location-based properties may also be applied.
[0047] This means that the compressed certificate revocation lists are distributed to or into the target network and nodes (e.g. a base station in a cellular network or a vehicle itself) are arranged to check whether they are affected by the false positive problem, in other words whether they have a valid certificate that is incorrectly indicated as revoked by the received compressed certificate revocation list.
[0048] If a node determines it is affected by the false positive problem, it can request an explicit non-revocation certificate that explicitly invalidates the false positive before going offline or disconnecting from the cellular network. Explicit non-revocation certificates are digital certificates that explicitly state that a certificate has not been revoked, even when there is no network connection.
[0049] Explicit non-revocation certificates can be created and distributed by a certificate authority (CA) and stored within an offline system. Explicit non-revocation certificates can be used to verify the validity of certificates without requiring a network connection or access to a CRL or OCSP response.
[0050] To ensure the security and integrity of the system, explicit non-revocation certificates should be generated using strong cryptographic algorithms and key sizes, and their distribution should be carefully managed to prevent unauthorized access or tampering. Furthermore, explicit non-revocation certificates should be updated and revoked as needed to reflect changes in certificate status.
[0051] An exemplary and non-limiting procedure for a requestor to obtain an explicit non-revocation certificate from a certificate authority (CA) may typically include the following steps: Step 1: Generate a public-private key pair. The requester generates a key pair consisting of a public and private key. The private key is kept confidential and used to sign the data, while the public key is shared with the certificate authority.
[0052] Step 2: Submit a certificate signing request (CSR). The requester sends a certificate signing request to the certificate authority, containing their public key and other identifying information.
[0053] Step 3: Identity verification. The certification authority verifies the requester's identity by verifying the relevant identification information.
[0054] Step 4: Issue an explicit non-revocation certificate. After verifying the requester's identity, the CA issues the explicit non-revocation certificate, which contains the requester's public key and a digital signature generated with the CA's private key. The explicit non-revocation certificate also contains a revocation status indicator indicating whether the certificate has been revoked or is still valid.
[0055] Step 5: Using the explicit non-revocation certificate. The requester can use the explicit non-revocation certificate to sign data and ensure its integrity. During retrieval, the signature and revocation status are checked to ensure the data is correct and complete, and any false positives caused by compression techniques are detected and corrected.
[0056] Preferably, an explicit non-revocation certificate is valid until the next update of the compressed certificate revocation list is submitted and distributed.
[0057] This avoids the problem of false positives and preserves the benefits of compression, as these cases are quite rare.
[0058] If such a process is performed continuously at regular intervals, offline operation with significantly reduced risk becomes possible. While it is possible that a revocation may occur after the last certificate revocation list has been submitted, this can be considered a significant risk reduction. The non-revocation check is also more efficient because it can be performed locally.
[0059] It is noted that further optimization is possible by assuming that services are local and distributed only to entities in a local environment (e.g., considering the range of vehicles). This is particularly useful for mobility services such as charging, which are inherently only available locally. Additionally or alternatively, further optimization is possible by assuming that services correspond to planned or usual user trips (e.g., as part of usual user behavior) and / or relevant entity types (e.g., vehicle vs. truck charging stations), and only considering relevant revocations.
[0060] Preferably, parties involved in using services can verify the revocation status using local information. Verifying the revocation status using local information is more efficient than verifying it with another entity and scales better. It also provides a significantly higher level of security in temporary offline situations where networks may be unavailable for short periods.
[0061] For example, when vehicles use services such as charging or parking, the network may be unavailable. In these cases, it is important to enable offline operation, which minimizes the risk of expired credentials. In cases such as charging or parking, the risk of invalid credentials is not very high and can be significantly reduced by the procedure described above.
[0062] The above procedure is also advantageous over short-lived certificates, which must be explicitly issued to each party at regular intervals, thus creating a significant overhead for issuing credentials.
[0063] Fig. Figure 3 shows an example scenario of a trust connection configuration using a certificate authority in which the present invention is applied. In the scenario of Fig. 3 In addition, a certification authority or authority is provided in a network cloud, certificates (and identities) are issued in the network cloud and the revocation check / certificate check is also performed by a check in the cloud.
[0064] Fig. Figure 4 illustrates an example scenario of a trust connection configuration using multiple certification authorities in which the present invention is applied. In the scenario of Fig. 4, a root or root certification authority and several subordinate certification authorities are deployed in a network cloud. Certificates (and identities) are issued in the network cloud, and revocation / certificate verification is also performed by a check in the cloud. The connection configuration is a trust configuration with certificate verification on both sides, including signatures from the subordinate certification authorities.
[0065] Modifications of the above embodiment provide various options and improvements.
[0066] In a first modification, assuming only services that require spatial proximity, such as parking or charging, and limited mobility of the parties, such as those in a car (i.e., those who do not move much), the size of the certificate revocation lists can be further reduced by calculating that only a smaller set of cars can reach certain locations within currently valid or applicable certificate revocation lists. In other words, if, for example, a certificate revocation list is only valid for a certain geographical area and only a subset of nodes, e.g., cars, are located in and / or able to reach a given geographical and physically reachable area, the certificate revocation list can be adapted to include only these nodes.More specifically, such an adaptation can involve a subset of the certificate revocation list, and a non-revocation certificate is required for each node not included in the subset. In a further modification, for example, when a node leaves the specified geographical area, a non-revocation certificate must be obtained beforehand. This can reduce the size of the certificate revocation list and make the system more efficient.
[0067] In a further modification, some nodes can perform the false positive check on behalf of others. In a cellular network, for example, the base stations can perform this check because they know the local identities and their certificates.
[0068] In a further modification, local revocation / false positive lists can be distributed via direct communication between base stations / vehicles if they are offline.
[0069] The invention has been described with reference to a preferred embodiment. However, it should be understood that the present invention is not limited to the specifically described embodiment and may include and cover additional aspects, configurations, and modifications without departing from the scope of the described and claimed subject matter. Such additional aspects, configurations, and modifications may include, for example, a method, apparatus, device, system, computer program, and apparatus for efficiently supporting the revocation of digital services and offline operation, using compressed certificate revocation lists and explicit non-revocation certificates to resolve false positive issues.
[0070] In general, embodiments of the invention may be implemented in hardware or special-purpose circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software executable by a controller, microprocessor, or other computing device, although the invention is not so limited. While various aspects of the invention may be illustrated and described in block diagram, flowchart, or other pictorial form, it should be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented, by way of non-limiting examples, in hardware, software, firmware, special-purpose circuits or logic, general-purpose hardware or controllers or other computing devices, or any combination thereof.
[0071] Embodiments of the present invention may be implemented by computer software executable by a data processor of a system unit, such as in the processor unit, or by hardware, or by a combination of software and hardware. In this context, it should be noted that blocks of logical flow illustrated in the figures may represent program steps or interconnected logical circuits, blocks, and functions, or a combination of program steps and logical circuits, blocks, and functions. The software may be stored on physical media such as memory chips or memory blocks implemented in the processor, on magnetic media such as hard disks or floppy disks, and on optical media such as DVDs and their data variants, CDs.
[0072] Memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor storage devices, magnetic storage devices and systems, optical storage devices and systems, read-only memory, and removable storage. Data processors may be of any type suitable for the local technical environment and may include, as non-limiting examples, one or more general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), gate-level circuits, and processors based on a multi-core processor architecture.
[0073] Embodiments of the inventions can be used in various components, such as integrated circuit modules. Integrated circuit design is, by and large, a highly automated process. Complex and powerful software tools are available for converting a logic-level design into a semiconductor circuit design that can be etched and formed onto a semiconductor substrate.
[0074] EDA (Electronic Design Automation) programs and tools automatically route circuit traces and place components on a semiconductor chip, using proven design rules and libraries of pre-stored design modules. Once the design for a semiconductor circuit is complete, the resulting design can be submitted in a standardized electronic format to a semiconductor manufacturing facility, or "fab," for manufacturing.
[0075] The description thus far has provided a complete and informative description of the exemplary embodiment of the present invention, by way of example and not by way of limitation. However, various modifications and adaptations may become apparent to those skilled in the relevant technical field in light of the foregoing description when read in conjunction with the accompanying drawings and the appended claims. It is to be understood that all such and similar modifications of the inventive teachings still fall within the scope of the invention as defined in the appended claims.
[0076] With the present invention as described above, a method for efficient revocation support for digital services and offline operation is provided, wherein the digital services use certificates to provide an access key and / or to prove identity or authorization in a public key infrastructure for mobile services or for V2X services.The method comprises compiling a certificate revocation list by a revocation authority, reducing the size of the compiled certificate revocation list, thereby reducing the list, and distributing the reduced certificate revocation list in an online mode using centralized revocation propagation to at least all relevant nodes of a target network, wherein each node of the target network can receive the distributed reduced certificate revocation list before entering an offline mode in order to locally check whether or not it is affected by an invalidity or a false positive or a false positive certificate assessment and, if so, requesting an explicit non-revocation certificate from the revocation authority.
[0077] As described above, a method for efficient revocation support for digital services and offline operations is provided, wherein the digital services use certificates to provide authorization and / or prove identity or authorization in a public key infrastructure, for mobile services, or for V2X services. The method comprises creating a certificate revocation list by a revocation authority entity, reducing the size of the created certificate revocation list, and distributing the reduced certificate revocation list in an online mode using centralized revocation propagation to at least all relevant nodes of a target network.Before entering an offline mode, at least one of the at least all relevant nodes of the target network is adapted to receive the distributed reduced certificate revocation list in order to check locally whether it is affected by an invalidation or not and, if so, to request an explicit non-revocation certificate from the revocation authority entity.
[0078] The method may comprise creating a certificate revocation list by a revocation authority entity, compressing the created certificate revocation list and / or selecting a subset of the created certificate revocation list for a predetermined geographical area and for a subset of nodes located in and / or capable of entering this area, thereby reducing the size of the list, and distributing the compressed certificate revocation list in an online mode using centralized revocation propagation to at least all relevant nodes of a target network.Before entering an offline mode, at least one of at least all relevant nodes of the target network is adapted to receive the distributed compressed certificate revocation list in order to locally check whether it is affected by a false positive or not and, if so, to request an explicit non-revocation certificate from the revocation authority entity.
[0079] In accordance with this method and the present invention, a reduced certificate revocation list is distributed in advance while an online connection is still active. Each device checks for invalidity and / or false positives and, if so, requests a suitable unrevoked certificate or non-revocation certificate. As a result, the method combines the advantages of distributed revoked certificate lists, the use of only short-lived certificates, and the issuance of "unrevoked" certificates, advantageously leading to a reduced risk of offline transactions.
Claims
[1] A method for efficient revocation support for digital services and offline operation, wherein the digital services use certificates to provide authorization and / or to prove identity or authorization in a public key infrastructure, for mobile services or for V2X services, the method comprising: Creation of a certificate revocation list by a revocation authority entity; Reducing the size of the created certificate revocation list; and Distributing the reduced certificate revocation list in an online mode using centralized revocation propagation to at least all relevant nodes of a target network, where before entering an offline mode, at least one of the at least all relevant nodes of the target network is adapted to receive the distributed reduced certificate revocation list in order to check locally whether it is affected by an invalidation or not and, if so, to request an explicit non-revocation certificate from the revocation authority entity. [2] The method of claim 1, comprising a compression technique for compressing the created certificate revocation list, thereby reducing the size of the list. [3] A method according to claim 1 or 2, comprising selecting a subset of the created and / or compressed certificate revocation list for a predetermined geographical area and for a subset of nodes that are located in and / or can enter this area. [4] A method according to claim 2 or 3, wherein, prior to entering an offline mode, at least one of the at least all relevant nodes of the target network is adapted to receive the distributed compressed certificate revocation list in order to locally check whether or not it is affected by a false positive and, if so, to request an explicit non-revocation certificate from the revocation authority entity. [5] The method of claim 3, wherein, prior to entering an offline mode, at least one of the at least all relevant nodes of the target network is configured to receive the distributed reduced certificate revocation list in order to locally check whether it is affected by an invalidity due to the absence or non-existence of a certificate and, if so, to request an explicit non-revocation certificate from the revocation authority entity. [6] A method according to any one of the preceding claims, wherein the requested explicit non-revocation certificate is adapted to have a validity at least until a next update of the compressed certificate revocation list distributed to the node after re-entering the online mode. [7] Method according to one of claims 1, 2 or 4 to 6, wherein the certificate revocation list is compressed by a factor between 10 and 100. [8] A method according to any one of the preceding claims, wherein a predetermined limit of node mobility is set and services requiring a predetermined proximity are selected, and the size of the certificate revocation list is created with a correspondingly reduced size. [9] A method according to any one of the preceding claims, wherein a node is adapted to perform the false positive check on behalf of other nodes. [10] A method according to any one of the preceding claims, wherein local revocation and / or false positive lists are distributed via direct communication between nodes when they are offline.
Citation Information
Patent Citations
Vehicle diagnostic device and method for managing a certificate thereof
DE102017128455A1
