Method for validating a signature

Abstract

The invention relates to a method for validating a signature (Sig) of at least one signing instance (SI) for a system (Sys) for which the signature (Sig) is intended, wherein the signing instance (SI) is furnished with an asymmetric key pair (SIPub, SIPriv) for creating the signature (Sig) of data (Dat) to be signed. The invention is characterized in that at least one checking instance (PI, BPI, FPI) is established and is furnished with all the necessary means needed to check signatures (Sig) generated by the at least one signing instance (SI), wherein, in order to carry out the check, the signature (Sig) to be checked is transmitted, together with the signed data (Dat), from the system (Sys) for which the signature (Sig) is intended to the checking instance (PI, BPI, FPI), following which the checking instance (PI, BPI, FPI) carries out the check of the signature (Sig), and following which the result (Erg) of the check is transmitted to the requesting system (Sys).

Description

[0001] Procedures for validating a signature

[0002] The invention relates to a method for validating a signature of at least one signing instance for a system which requires the result of the signature verification, wherein the signing instance is equipped with an asymmetric key pair for creating the signature of data.

[0003] In our increasingly digital world, information technology security (IT security) plays an ever more important role. Many systems communicate with each other via networks, and secure communication is relevant for all types of networked systems. This essentially means that communication partners need ways to ensure they are communicating with the intended entity and not with one that merely pretends to be the "right" one, or that data originates from the intended entity and is not being injected into the network by a third party. This is where digital signatures come into play, which are typically generated using the secret part of a key pair and can be verified by the communication partner using the public part of the same key pair.

[0004] This plays a crucial role not only, but especially, in the field of CarlT security, i.e., the security of communicating vehicle systems, as such systems or control units are often responsible for safety-relevant functions in the vehicles. Modern vehicles are typically part of a large vehicle ecosystem. In particular, the control units installed in the vehicles belong to this ecosystem. Another central part of this ecosystem is the so-called backend, an external server (usually owned by the OEM) to which the vehicles are connected via the internet. Communication between individual control units within a vehicle is often protected against unauthorized access, for example, using the SecOC (Secure Onboard Communication) standardized by AUTOSAR.Communication between vehicle control units and other participants in the vehicle ecosystem, especially the backend, is currently secured using established standard procedures (mostly TLS, sometimes IPSec). In some situations, for example for certain services and applications, the basic protection provided by standardized procedures is insufficient; in these cases, additional security mechanisms are employed.

[0005] Digital signatures are a key component of many security mechanisms used in the vehicle ecosystem. Digital signatures are based on asymmetric cryptography (e.g., RSA, ECC). Asymmetric cryptography uses key pairs consisting of a public key and a private key. Each instance intended to sign data, referred to here as the "signing instance," is equipped with such an individual key pair. The private key is known only to the signing instance, while the public key is distributed to all instances that are to be able to verify signatures generated by the signing instance, referred to here as "verifying instances."Ideally, the key pair is generated by the signing instance itself. The private key is then stored in read-only mode within this instance and never leaves it, while the public key is distributed to the verifying instances in a tamper-proof manner and stored there in a tamper-proof manner. To sign data, the signing instance requires the data itself and its own private key. The result of signing specific data with a specific private key is a so-called digital signature. To verify the correctness of a signature, the verifying instance requires the signing instance's public key, the signature, and the signed data. The result of the verification is a Boolean value: TRUE or FALSE. Verifying the correctness of a signature is synonymous with verifying the integrity of the signed data.

[0006] For signature verification, a verifying authority therefore needs, in addition to the signature and the data, an implementation of the signature verification procedure that matches the signing method used for signing and the public key that matches the private key used for signing.

[0007] A vehicle ecosystem can include everything from large servers to small, low-powered electronic control units (ECUs). Vehicle ecosystems are therefore extremely heterogeneous, meaning that the participants in the ecosystem can differ significantly in terms of their performance (computing power, memory, etc.). Depending on the method used, operations with asymmetric keys can be comparatively resource-intensive, both in terms of computing power and memory. This can be particularly true for both signing (i.e., generating digital signatures) and verifying digital signatures. As a consequence, many ECUs, especially low-powered ones, cannot efficiently implement all conceivable signature verification methods and must limit themselves to a few, often just one.In some electronic control units (ECUs), signature verification procedures cannot be implemented at all; in such cases, integrity protection must be ensured exclusively using symmetrical methods. At the same time, participants in the vehicle ecosystem often need to be able to verify signatures generated by signing instances located outside their own vehicle ecosystem. This is problematic because the vehicle manufacturer has little or no influence over which signing method the external signing instance uses.

[0008] As mentioned above, verifying the signature requires the public key of the signing instance, which must be transmitted to the verifying instance in a tamper-proof manner and stored there in a tamper-proof manner. Both of these requirements necessitate certain capabilities of the control unit, which are not always present, especially in less powerful control units.

[0009] Since the lifespan of vehicles and thus the installed control units can extend over several decades, it may become advantageous or even necessary during this time, for example from a security perspective, for a particular signing authority to use a different signing method and / or a different asymmetric key pair for signing data. For example, certain authorities, such as the Federal Office for Information Security (BSI), may recommend discontinuing the use of a specific cryptographic method or key length after a certain point in time. To comply with these requirements, it is necessary to implement the change in a timely manner and use a new signing method and / or key pair that meets the requirements. Switching to a new signing method and / or key pair at the signing authority may also be necessary because, for example...The originally used signing method and / or key length no longer conform to the state of the art and are generally considered insufficiently secure. The use of a different signing method and / or a different private key by the signing instance necessitates that each verifying instance also make adjustments. This involves implementing a signature verification procedure compatible with the new signing method and / or equipping the verifying instance with the new public key of the signing instance that matches the private key used for signing. These adjustments also require certain capabilities of the control unit, which are not always present, especially in low-performance control units.

[0010] In summary, signature verification poses certain challenges, particularly for less powerful participants, and not all participants can efficiently implement this function, especially given the required diversity and flexibility. This applies, for example, in a vehicle ecosystem, particularly to the control units mentioned above.

[0011] Approaches are known from the state of the art, e.g., from WO 2014 / 199 128 A1, in which devices delegate the signing of data, i.e., the creation of a signature, to another, more powerful instance. See, for example, "Proxy Signatures for Delegating Signing Operation" https: / / dl.acm.org / doi / pdf / 10.1145 / 238168.238185 (accessed on March 20, 2024) or "A Secure Proxy Signature Scheme with Delegation by Warrant" https: / / sic.ici.ro / wp-content / uploads / 2011 / 12 / SIC_2011-4-Art5.pdf (accessed on March 20, 2024).

[0012] For further information on the state of the art, reference can be made to US 2022 / 0069602 A1. This describes an encrypted authentication of a user at a charging station. Authorization is requested via a central mobility service provider, which then verifies and confirms it upon successful verification.

[0013] The object of the present invention is to provide a method for validating a signature of at least one signing instance for a system that must check the signature, which is improved in such a way that the flexibility in the use of the signature is increased, and that, above all, it enables reliable signature verification even for low-performance systems or devices - in the sense described above.

[0014] According to the invention, this problem is solved by a method with the features in claim 1, and in particular in the characterizing part of claim 1. Further advantageous embodiments and developments of the method are specified in the dependent claims. The method according to the invention thus proposes that, in addition to the signing instance equipped with a signing method and a suitable asymmetric key pair, which creates signatures for an ecosystem using this key pair, at least one verification instance is provided. Thus, within the ecosystem in which signature verifications are performed, there is at least one verification instance capable of checking the correctness of the signatures issued by the signing instance.This fact is now exploited by a system interested in verifying a signature, referred to here as the requesting system, by delegating this task to the verification authority instead of verifying the signature itself using the public key of the signing entity. The verification authority checks the signature and transmits the result of the check, e.g., a Boolean value such as TRUE or FALSE, to the requesting system. This allows even a relatively low-performance system with limited computing and / or storage capacity to obtain a reliable verification result.

[0015] By delegating signature verification to a verification authority, the requesting system does not need to implement a signature verification procedure to check signatures generated by the signing authority. In particular, the system does not need to store and use the signing authority's public key in a tamper-proof manner. This saves resources within the system and allows the signing authority, in coordination with the verification authority, to always use the most secure, state-of-the-art signing methods and key lengths for the signing process, independently of the requesting systems, with minimal effort. This eliminates the need to modify the requesting systems that want to verify the signature. This provides a genuine security advantage and allows for this even with long-lived systems, such as...Vehicle control units can be equipped with the latest technology without having to securely install new testing procedures and / or keys within the system itself. This is a crucial advantage, especially when dealing with a large number of units in the field, particularly if they are from different generations.

[0016] An advantageous design of the procedure further provides that the verification authority is equipped with at least one signature verification procedure for verifying signatures generated by the signing authority using the signing procedure, and with the public key of the signing authority. The verification authority can also perform the verification of signatures generated with different private keys, in particular signatures generated by different signing authorities. For this purpose, the verification authority must have implemented the corresponding signature verification procedures and be equipped with the associated public keys of the signing authorities. In order to perform a meaningful signature verification, the verification authority must be informed, in addition to the signed data and the signature itself, which signing procedure and which private key were used in the signing process.For this to work, the potentially usable key pairs must be assigned unique identifiers that allow them to be identified. The unique identifier of the private key used in the signing process must then be communicated to the requesting system along with the signature. The requesting system, in turn, transmits this identifier, along with the signed data and the signature, to the verification authority when requesting verification. If the signing method used is not clearly evident from the other transmitted data, such as the signature or the unique identifier of the public key, this information must also be transmitted to the verification authority.

[0017] The security of the requesting system can depend significantly on knowing whether the signature to be verified is correct, i.e., on the correctness of the verification performed by the verification instance on the signature transmitted to it. To prevent an attacker from undetected manipulating the request sent to the verification instance—for example, by replacing the transmitted data-signature pair—it is helpful to transmit the request to the verification instance in an integrity-protected manner. Accordingly, a highly advantageous embodiment of the method according to the invention provides that the system's request to the verification instance, including the data-signature pair to be verified, is transmitted in an integrity-protected and / or authenticated manner.

[0018] On the other hand, it is also important that an attacker cannot falsify or manipulate the result of the check performed by the checking instance unnoticed on its way from the checking instance to the requesting system. Therefore, another very advantageous design provides that the response from the checking instance to the requesting system, including the result of the check, is integrity-protected and / or authenticated.

[0019] Both the request and the response can be conducted using known asymmetric methods, e.g., digital signatures, or symmetric methods, e.g., Message Authentication Codes (MAC), to ensure integrity and authenticity.

[0020] It can be advantageous to include not only the binary result of the verification (TRUE / FALSE) in the notification of the verification result to the requesting system (Sys), but also the complete request or parts thereof, such as the verified data signature pair. If this comprehensive result is transmitted to the requesting system in an integrity-protected manner, the integrity-protected transmission of the request to the verification instance can be omitted. This is because, based on the communicated result containing the underlying request for the signature verification, particularly the verified data signature pair, the requesting system can determine whether the communicated result stems from the verification of the original request by comparing the data contained in the original request with the data from the request contained in the integrity-protected result, such as the verified data signature pair.Foregoing integrity-protected transmission of the request can significantly simplify the implementation of the requesting system, because integrity-protected transmission usually requires a secret stored in read-protection within the sender, in this case the requesting system, e.g. a private key, which can be dispensed with if integrity protection is omitted.

[0021] A particularly advantageous embodiment of the invention can therefore provide that, during the transmission of the result by the testing authority to the requesting system, at least parts of the query underlying the performed test are also transmitted to the latter. Preferably, the transmitted parts of the query can include the verified data-signature pair.

[0022] In this case, the system's request to the validation body can even be sent unprotected. The validation body's response, including the result of the validation, is then transmitted with integrity protection and / or authentication and, as previously explained, contains at least parts of the underlying request. Upon receiving the response, the system can then check whether the parts of the request transmitted along with the result match the original request.

[0023] In order for the requesting system to rely on the signature verification result communicated by the verification authority, the requesting system must trust the verification authority. According to a highly advantageous design of the procedure, the verification authority should therefore be a trustworthy entity from the perspective of the requesting system.

[0024] As mentioned several times above, this method can be particularly advantageous in a vehicle ecosystem. In this context, the systems are designed as control units within a vehicle environment that, in addition to the control units of the individual vehicles, includes at least one external server, the aforementioned backend, which maintains a communication link with the vehicles and at least some of their control units.

[0025] In such an application, it can be advantageous and intended for the verification instance to be implemented as a vehicle verification instance within a dedicated control unit, for example, as a part or module of that control unit in the respective vehicle. The verification can then be offered to the other control units installed in the same vehicle or to the other subsystems / modules of the same control unit. The vehicle's bus system can be used to transmit requests and communicate the results, which has the advantage of rapid response times and thus fast signature verification. Likewise, vehicle-internal integrity protection mechanisms, especially basic integrity protection mechanisms such as SecOC, can be used directly to protect the integrity of the requests and / or the results.A control unit, in particular a control unit or module of a control unit specifically designed for signature verification, can be optimized for this task, so that the capacity problems that otherwise frequently occur with control units do not play a role here.

[0026] In an alternative or particularly preferably also supplementary embodiment of the method according to the invention, the verification of signatures can also be carried out by a vehicle-external server (backend) or a subsystem thereof, which has the advantage that the backend has much greater resources and much greater flexibility compared to a control unit, which in particular enables a larger number of offered signature verification methods and / or used key lengths as well as, if required, a faster and simpler inclusion of further signature verification methods and / or used key lengths.

[0027] These two approaches can be advantageously combined by setting up a verification instance both in the vehicle and in the backend, and by having the signature verification carried out by one or the other verification instance depending on the case, thus making it possible to utilize the advantages of both types of verification instances.

[0028] For this purpose, it may now be provided that the system transmits its request, including the data signature pair to be checked, to the vehicle testing instance, which performs the check, or forwards the request, including the data signature pair to be checked, to the backend testing instance for check, which performs the check and transmits the result of the check to the vehicle testing instance.

[0029] The vehicle verification instance is always available to the system or control unit as a contact point. Communication between these two partners is therefore simple, efficient, and secure within the vehicle. After receiving the request, the vehicle verification instance checks whether it can perform the requested check itself, specifically whether it has implemented the necessary signature verification procedure and possesses the required public key of the signing instance. If so, the vehicle verification instance checks whether it is more efficient to perform the check itself or to delegate it to the backend verification instance. If not, the check is immediately delegated to the backend verification instance. In this process, the vehicle verification instance acts as a requesting system to the backend verification instance.If the test is performed by the vehicle testing instance, the situation described above occurs, involving a requesting system and a testing instance. If the test is performed by the backend testing instance, the vehicle testing instance receives the request from the requesting system and then forwards this request, in turn acting as the "requesting system," to the backend testing instance.

[0030] Regarding the result, several options are now possible. In one variant, the vehicle testing instance can transmit the result, along with information about which instance performed the test, to the requesting system. In a particularly advantageous implementation, end-to-end integrity protection can be established between the system and the backend testing instance for both the request and the transmission of the result. This allows the vehicle testing instance to remain in the transmission chain without gaining any means of interfering with the data traffic. Furthermore, in a highly beneficial refinement, the requesting system can specify which instance should perform the test. In this case, the system or control unit retains the right to select the testing instance.

[0031] According to another approach, the vehicle verification instance could always transmit the result to the requesting system in its own name. The requesting system would therefore have no knowledge of whether the vehicle verification instance or the backend verification instance verified the signature. In this configuration of a vehicle verification instance and a backend verification instance, the requesting system and the backend verification instance need not be aware of each other; the requesting system sends all requests to the vehicle verification instance, which also returns all results. If integrity protection procedures are used, the integrity of the received request or result must be checked by the vehicle verification instance in each case and then re-protected with the integrity protection procedure used between the vehicle verification instance and the recipient when forwarding the request or result to the respective recipient, e.g.,...with a signature or a message authentication code. However, this particular implementation does not guarantee end-to-end integrity protection.

[0032] Further advantageous embodiments of the method according to the invention also result from the remaining dependent subclaims and become clear with reference to the exemplary embodiments, which will be described in more detail below with reference to the figures.

[0033] This shows:

[0034] Fig. 1 shows a diagram of a schematic representation of a first embodiment of the method according to the invention;

[0035] Fig. 2 shows a diagram of a first embodiment of the method according to the invention with several signing instances;

[0036] Fig. 3 shows a diagram with an exemplary vehicle-related implementation of two test instances in a first embodiment of the method according to the invention; and

[0037] Fig. 4 shows a diagram with an exemplary vehicle-related implementation of two test instances in a second embodiment of the method according to the invention. The representation in Figure 1 shows a possible embodiment of the method in which a signature Sig generated by the signing instance Sl for data Dat is transmitted from a system Sys to a test instance PI and is checked there using a dedicated service implemented by the test instance PI. The dashed arrow and the cloud symbolize that the data Dat and the signature Sig are decoupled from the actual testing process and are transmitted to the requesting system Sys before the testing process. Since the signature Sig is generated by the signing instance Sl, it originates in the signing instance Sl.The data to be signed, Dat, does not necessarily have to originate from the signing instance Sl; it can be transmitted from any point in the ecosystem to the requesting system Sys.

[0038] If more than one signing instance Sl is used, the scheme, for the example of two signing instances SI1 and SI2, would look like the representation in Figure 2, analogous to the representation in Figure 1. With two signing instances SI1 and SI2 using the same signing method Sign, each with two key pairs and one key pair respectively, and a requesting system Sys, the following configuration results. Note that the verification instance PI must maintain three public keys to be able to verify all signatures generated by the signing instances SI1 and SI2. The unique identifiers of the keys result from the identity of the signing instance SI1 and SI2 and the sequential number of the key pair within the respective signing instance SI1 and SI2.

[0039] Figure 3 shows a first exemplary implementation of the combination of a vehicle inspection instance (FPI) and a backend inspection instance (BPI). Data is protected during transmission from one communication partner to the other, with communication between the requesting system (Sys) and the vehicle inspection instance (FPI) being protected using symmetric message authentication codes, and communication between the vehicle inspection instance (FPI) and the backend inspection instance (BPI) being protected using asymmetric digital signatures. The following steps are performed in detail.

[0040] 1. The signing instance Sl, equipped with at least an implementation of a signing algorithm Sign and a corresponding asymmetric key pair SIPub, SIPriv, a. signs the data Dat using the signing algorithm Sign and its private key SIPriv, thereby generating the signature Sig, b. transmits the signed data Dat and the signature Sig to the requesting system Sys. The requesting system Sys, which is equipped with at least the following means

[0041] - An implementation of a procedure for generating a Message Authentication Code (MAC) and a corresponding symmetric key (MKey), which it shares with the vehicle verification instance (FPI) and which ensures the integrity of communication with the FPI, performs the following steps after receiving the data signature pair (Dat, Sig): a. using the procedure for generating a Message Authentication Code (MAC) and the symmetric key (MKey), it generates a Message Authentication Code (M1) for the received data signature pair (Dat, Sig); b. transmits the data signature pair (Dat, Sig) and the generated Message Authentication Code (M1) to the vehicle verification instance (FPI). The vehicle verification instance (FPI), which is equipped with at least the following means...

[0042] - an implementation of a vehicle signing procedure SignF and a corresponding asymmetric key pair FPIPub, FPIPriv

[0043] - potentially (marked by question marks in Figure 3) an implementation of the signature verification procedure Ver for verifying signatures Sig generated by the signing instance Sl using the signing procedure Sign and the corresponding public key SIPub of the signing instance Sl

[0044] - an implementation of the procedure for generating a Message Authentication Code (MAC) and the corresponding symmetric key (MKey), which it shares with the requesting system (Sys) and with which the communication with the requesting system (Sys) is integrity-protected.

[0045] - An implementation of a signature verification procedure VerB for verifying signatures S2 generated by the backend signing procedure SignB implemented in the backend verification instance BPI and the corresponding public key BPI Pub of the backend verification instance BPI to ensure the integrity of the data received by the backend verification instance BPI performs the following steps after receiving the data signature pair (Dat, Sig) and the message authentication code M1: a. Using the message authentication code verification function CheckMAC, derived from the procedure for generating a message authentication code MAC, the stored symmetric key MKey, and the received message authentication code M1, the integrity of the received data signature pair (Dat, Sig) is checked. If the check fails, exception handling is initiated (not shown in Figure 3). b.c. checks whether the signature verification contained in the received data signature pair (Dat, Sig) can be performed locally. If not, proceed to step 3.g. c. checks whether it is efficient to perform the signature verification locally. If not, proceed to step 3.g. d. calculates the result Erg of the signature verification of the data signature pair (Dat, Sig) using the signature verification procedure Ver and the public key SIPub of the signing instance Sl. e. generates a message authentication code M2 ​​for the calculated result Erg using the procedure for generating a message authentication code MAC and the symmetric key MKey. f. transmits the result Erg and the generated message authentication code M2 ​​to the requesting system Sys. Then proceed to step 6a. g.The system generates the signature S1 of the data signature pair (Dat, Sig)n using the implemented vehicle signing method SignF and its own private key FPIPriv. It then transmits the data signature pair (Dat, Sig) and the generated signature S1 to the backend verification instance BPI. The backend verification instance BPI is equipped with at least the following means.

[0046] - an implementation of a backend signing algorithm SignB and a corresponding asymmetric key pair BPI Pub, BPIPriv,

[0047] - an implementation of the signature verification procedure Ver for verifying signatures Sig generated by the signing instance Sl using the signing procedure Sign and the corresponding public key SIPub of the signing instance Sl,

[0048] - An implementation of a signature verification procedure VerF for verifying signatures S1 generated by the vehicle signing procedure SignF implemented in the vehicle verification instance FPI and the corresponding public key FPIPub of the vehicle verification instance FPI to ensure the integrity of the data received by the vehicle verification instance FPI performs the following steps after receiving the data signature pair (Dat, Sig) and the signature S1: a. Using the implemented signature verification procedure VerF, the stored public key FPIPub of the vehicle verification instance FPI, and the received signature S1, the integrity of the received data signature pair (Dat, Sig) is checked. If the check fails, exception handling is initiated (not shown in Figure 3). b.The system calculates the result Erg of the signature verification of the data-signature pair (Dat, Sig) using the signature verification procedure Ver and the public key SIPub of the signing instance Sl. It then generates the signature S2 of the result Erg using the implemented signing procedure SignB and its own private key BPIPriv. Finally, it transmits the result Erg and the generated signature S2 to the vehicle verification instance FPI.

[0049] 5. After receiving the result Erg and the signature S2, the vehicle testing instance FPI performs the following steps: a. Using the implemented signature verification procedure VerB, the stored public key BPIPub of the backend testing instance BPI, and the received signature S2, it checks the integrity of the received result Erg. If the check fails, exception handling is initiated (not shown in Figure 3). b. It proceeds to step 3.e.

[0050] 6. After receiving the result Erg and the message authentication code M2, the requesting system Sys performs the following steps: a. It checks the integrity of the received result Erg using the message authentication code verification function CheckMAC, derived from the method for generating a message authentication code MAC, the stored symmetric key MKey, and the received message authentication code M2. If the verification fails, exception handling is initiated (not shown in Figure 3). b. It uses the transmitted result Erg.

[0051] The configuration described in Figure 3 has the advantage that the requesting system Sys communicates at all levels only with the vehicle testing instance FPI and therefore only needs to provide integrity protection procedures for this communication. The disadvantage of this first configuration is that both participating testing instances, i.e., both the vehicle testing instance FPI and the backend testing instance BPI, must be trusted; in particular, this configuration does not guarantee end-to-end integrity protection between the backend testing instance BPI and the requesting system Sys.

[0052] In an alternative configuration of the combination of a vehicle inspection instance (FPI) and a backend inspection instance (BPI), where the requesting system (Sys) is aware of both the vehicle inspection instance (FPI) and the backend inspection instance (BPI), this disadvantage is overcome. As described above, the requesting system (Sys) sends all requests to the vehicle inspection instance (FPI). However, unlike the first configuration, the requesting system (Sys) can specify in the request whether it prefers the inspection to be performed by the vehicle inspection instance (FPI) or by the backend inspection instance (BPI). Furthermore, the vehicle inspection instance (FPI) can explicitly indicate to the requesting system (Sys) in the results notification which inspection instance performed the inspection and determined the result (Erg).Furthermore, end-to-end integrity protection can be implemented between the requesting system Sys and the backend testing instance BPI, using both symmetric and asymmetric integrity protection methods. If such end-to-end integrity protection is in place and the test is always performed by the backend testing instance BPI, for example, because requested by the requesting system Sys, then in this variant the vehicle testing instance FPI serves solely for communication between the requesting system Sys and the backend testing instance BPI. In particular, in this variant, the requesting system Sys does not need to trust the vehicle testing instance FPI.

[0053] Figure 4 shows an example implementation of this second approach. In this implementation, the respective requests from the requesting system Sys to the vehicle testing instance FPI, and from the vehicle testing instance FPI to the backend testing instance BPI, are transmitted unprotected. However, the transmission of the result from the respective testing instance FPI or BPI to the requesting system Sys is protected using digital signatures. As suggested above, in addition to the pure result of the signature verification Erg, the verified data-signature pair (Dat, Sig) and the identity IdPI of the testing instance FPI or BPI that performed the signature verification are also signed and transmitted. To ensure that the requesting system Sys only needs to implement one signature verification procedure, both testing instances FPI and BPI use the same signing procedure, SignFB.The following steps are carried out in detail: The signing instance Sl, equipped with at least an implementation of a signing algorithm Sign and a corresponding asymmetric key pair SIPub, SIPriv, a. signs the data Dat using the signing algorithm Sign and its private key SIPriv, thereby generating the signature Sig, b. transmits the signed data Dat and the signature Sig to the requesting system Sys. The requesting system Sys is equipped with at least the following means.

[0054] - An implementation of a signature verification procedure VerFB for verifying signatures S3 and S4 generated by the joint signing procedure SignFB implemented in the vehicle verification instance FPI and the backend verification instance BPI, and the corresponding public keys FPIPub and BPIPub of the vehicle verification instance FPI and the backend verification instance BPI, to ensure the integrity of the data received by the vehicle verification instance FPI and the backend verification instance BPI, performs the following steps after receiving the data signature pair (Dat, Sig): a. transmits the data signature pair (Dat, Sig) to the vehicle verification instance FPI. The vehicle verification instance FPI, which is equipped with at least the following means

[0055] - an implementation of the common signing algorithm SignFB and a corresponding asymmetric key pair FPIPub, FPIPriv

[0056] - Potentially, (marked by a question mark in Figure 4) an implementation of the signature verification procedure Ver for verifying signatures Sig generated by the signing instance Sl using the signing procedure Sign and the corresponding public key SIPub of the signing instance Sl, performs the following steps after receiving the data-signature pair (Dat, Sig): a. checks whether the verification of the signature Sig contained in the received data-signature pair (Dat, Sig) can be performed locally. If not, it proceeds to step 3.g. b. checks whether it is efficient to perform the signature verification locally. If not, it proceeds to step 3.g. c. calculates the result Erg of the signature verification of the data-signature pair (Dat, Sig) using the signature verification procedure Ver and the public key of the signing instance SIPub. d.e. Assigns its own identity "FPI" to the parameter IdPI, which is to be signed and transmitted along with the result Erg. e. Generates the joint signature S3 of the result Erg of the signature verification, the verified data signature pair (Dat, Sig), and the identity of the verification instance IdPI using the implemented joint signing procedure SignFB and its own private key FPIPriv. f. Transmits the result Erg, the verified data signature pair (Dat, Sig), the identity of the verification instance IdPI, and the generated signature S3 to the requesting system Sys. Then proceeds to step 6a. g. Transmits the data signature pair (Dat, Sig) to the backend verification instance BPI. The backend verification instance BPI is equipped with at least the following means.

[0057] - an implementation of the common signing procedure SignFB, also used by the vehicle inspection authority FPI, and a corresponding asymmetric key pair BPI Pub, BPIPriv,

[0058] - An implementation of the signature verification procedure Ver for verifying signatures Sig generated by the signing instance Sl using the signing procedure Sign and the corresponding public key SIPub of the signing instance Sl, performs the following steps after receiving the data signature pair (Dat, Sig): a. Calculates the result Erg of the signature verification of the data signature pair (Dat, Sig) using the signature verification procedure Ver and the public key of the signing instance SIPub. b. Assigns its own identity "BPI" to the parameter IdPI, which is to be signed and transmitted together with the result Erg. c. Generates the joint signature S4 of the result Erg of the signature verification, the data signature pair (Dat, Sig), and the identity of the verification instance IdPI using the implemented signing procedure SignFB and its own private key BPIPriv. d.The vehicle testing instance (FPI) transmits the result Erg, the verified data signature pair (Dat, Sig), the identity of the testing instance IdPI, and the generated signature S4 to the vehicle testing instance FPI. After receiving the result Erg, the verified data signature pair (Dat, Sig), the identity of the testing instance IdPI, and the signature S4 generated by the backend testing instance BPI, the vehicle testing instance FPI performs the following steps: a. It transmits the result Erg, the verified data signature pair (Dat, Sig), the identity of the testing instance IdPI, and the generated signature S4 to the requesting system Sys. After receiving the result Erg, the verified data signature pair (Dat, Sig), the identity of the testing instance IdPI, and the signature S3 or S4 generated by the testing instance, the requesting system Sys performs the following steps: a.The system checks whether the data signature pair (Dat, Sig) contained in the request matches the verified data signature pair (Dat, Sig) transmitted with the result Erg. If the check fails, exception handling is initiated (not shown in Figure 4). b. - If the signature check was performed by the vehicle verification instance FPI, the system uses the implemented common signature verification procedure VerFB, the stored public key FPIPub of the vehicle verification instance FPI, and the received signature S3 to check the integrity of the received data, i.e., the result Erg, the verified data signature pair (Dat, Sig), and the identity of the verification instance IdPI that performed the check. If the check fails, exception handling is initiated (not shown in Figure 4).

[0059] - If the signature verification was performed by the backend verification instance BPI, the integrity of the received data—i.e., the result Erg, the verified data-signature pair (Dat, Sig), and the identity of the verification instance IdPI—is checked using the implemented common signature verification procedure VerFB, the stored public key BPI Pub of the backend verification instance BPI, and the received signature S4. If the verification fails, exception handling is initiated (not shown in Figure 4).

[0060] - If the identity of an unknown auditing authority was transmitted, exception handling is initiated (not shown in Figure 4). c. uses the transmitted result.

Claims

Patent claims 1. A method for validating a signature (Sig) of at least one signing instance (Sl) for a system (Sys) that requires the result of the signature (Sig) verification, wherein the signing instance (Sl) is equipped with an asymmetric key pair (SIPub, SIPriv) for creating the signature (Sig) of data (Dat) to be signed, characterized in that at least one verification instance (PI, BPI, FPI) is established for verifying signatures (Sig) generated by the at least one signing instance (Sl), wherein, for the purpose of performing the verification, the signature (Sig) to be verified, together with the signed data (Dat), is transmitted from the system (Sys) that requires the result of the signature (Sig) verification to the verification instance (PI, BPI, FPI), after which the verification instance (PI, BPI, FPI) performs the verification of the signature (Sig), and after which the result (Erg) of the verification is transmitted to the requesting system (Sys).

2. Method according to claim 1, characterized in that the verification instance (PI, BPI, FPI) is equipped with at least one signature verification method (Ver, VerB, VerF, VerFB) for verifying signatures (Sig) generated by the signing instance (Sl) using the signing method (Sign) and with the public key (SIPub) of the signing instance (Sl).

3. Method according to claim 1 or 2, characterized in that a request from the system (Sys) to the testing authority (PI, BPI, FPI) including the data signature pair ((Dat, Sig)) to be tested is integrity-protected and / or authenticated.

4. Method according to claim 1, 2 or 3, characterized in that A response from the auditing body (PI, BPI, FPI) to the requesting system (Sys), including the result (Erg) of the audit, is transmitted in an integrity-protected and / or authenticated manner.

5. Method according to one of claims 1 to 4, characterized in that, as part of the transmission of the result (Erg) by the testing authority (PI, BPI, FPI) to the requesting system (Sys), at least a binary indication (TRUE / FALSE) about the test result is transmitted to the latter.

6. Method according to one of claims 1 to 5, characterized in that, as part of the transmission of the result (Erg) by the testing authority (PI, BPI, FPI) to the requesting system (Sys), at least parts of the request underlying the test performed are also transmitted to the latter.

7. Method according to claim 6, characterized in that the parts of the request transmitted back comprise the verified data signature pair (Dat, Sig).

8. Method according to claim 6 or 7, characterized in that a request from the system (Sys) to the testing instance (PI, BPI, FPI) is made unprotected, wherein a response from the testing instance (PI, BPI, FPI) to the requesting system (Sys) including the result (Erg) of the test is integrity-protected and / or authenticated, and wherein the system checks whether the parts of the request transmitted as part of the transmission of the result (Erg) match the request made.

9. Method according to one of claims 1 to 8, characterized in that a trusted instance is used as the testing instance (PI, BPI, FPI).

10. Method according to any one of claims 1 to 9, characterized in that the systems (Sys) are designed as control units in a vehicle environment.

11. Method according to claim 10, characterized in that the test instance (PI) is designed as at least one vehicle test instance (FPI) in a control unit of the respective vehicle.

12. Method according to one of claims 10 or 11, characterized in that the vehicle environment comprises, in addition to the control units of the individual vehicles, at least one vehicle-external server (backend) which is in a communication connection with the vehicles and at least some of their control units.

13. Method according to claim 12, characterized in that the test instance (PI) is configured as at least one backend test instance (BPI) in the vehicle-external server.

14. Method according to claims 11 and 12, characterized in that at least one vehicle testing instance (FPI) and at least one backend testing instance (BPI) are used, wherein the system (Sys) transmits its request including the data signature pair ((Dat, Sig)) to be tested to the vehicle testing instance (FPI), which performs the test, or forwards the request including the data signature pair ((Dat, Sig)) to be tested to the backend testing instance (BPI), which performs the test and transmits the result (Erg) of the test to the vehicle testing instance (FPI).

15. Method according to claim 13, characterized in that the vehicle testing instance (FPI) transmits the result (Erg) together with information about which of the instances (FPI, BPI) performed the test to the requesting system (Sys).

16. Method according to claim 14 or 15, characterized in that The requesting system (Sys) specifies which of the instances should perform the check (FPI, BPI).

17. Method according to claim 14, 15 or 16, characterized in that end-to-end integrity protection is established for the request and / or the transmission of the result (Erg) between the requesting system (Sys) and the backend inspection instance (BPI).

18. Method according to claim 14, characterized in that the vehicle testing instance (FPI) transmits the result (Erg) to the requesting system (Sys) in its own name.

Images