Procedure 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 equipped with an asymmetric key pair (SIPub, SIPriv) for creating the signature (Sig) from data (Dat) to be signed. The invention is characterized in that at least one verification instance (PI, BPI, FPI) is established, which is equipped with all the necessary means for verifying signatures (Sig) generated by the at least one signing instance (SI), wherein, to carry out the verification, the signature (Sig) to be verified, together with the signed data (Dat), is sent from the system (Sys) for which the signature (Sig) is intended to the verification instance (PI).BPI, FPI), after which the verification authority (PI, BPI, FPI) carries out the verification of the signature (Sig), and after which the result (Erg) of the verification is transmitted to the requesting system (Sys).

Description

The invention relates to a method for validating a signature of at least one signing entity for a system which requires the result of checking the signature, wherein the signing entity is equipped with an asymmetric key pair for creating the signature of data.In our increasingly digitized world, security plays an increasingly important role in information technology (IT security). Namely, many systems communicate with each other over networks, and secure communication is relevant to all kinds of networked systems. This essentially includes communication partners requiring options to ensure that they communicate with that entity with which they wish to communicate and not with one which just specifies that they are "correct" or the data originates from that entity from which they are intended to originate and are not actually introduced into the network by a third party. This combination uses signatures which are typically generated using data with a secret part of a key pair and can be checked by the communication partner with the public part of the same key pair.This plays a decisive role not only, but above all also in the field of CarlT security, i.e. safety in communicating vehicle systems, since such systems or control units are frequently also responsible for safety-relevant functions in the vehicles. Namely, modern vehicles are typically part of a large vehicle ecosystem. In particular, the control units installed in the vehicles belong to this vehicle ecosystem. A further central part of this ecosystem is the so-called backend, a (generally OEM-dedicated) vehicle-external server to which the vehicles are connected via the Internet. The communication between individual control units within a vehicle is often integrity-protected, for example using the SecOC (Secure Onboard Communication) method standardized by AUTOSAR. The communication between vehicle control units and other participants of the vehicle ecosystem, in particular the backend, is currently secured with the aid of known standard methods (mostly TLS, sometimes IPSec). In some situations, for example for some services and applications, the basic protection ensured by standardized methods is not sufficient; in these cases, additional safety mechanisms are used.An important component of many such security mechanisms used in the vehicle ecosystem are digital signatures. Digital signatures are based on asymmetric cryptography (for example. RSA, ECC). In asymmetric cryptography, key pairs consisting of a public key and a private key are used in each case. Each instance intended to sign data, referred to herein as the "signing instance", is equipped with such an individual key pair, the private key being intended to be known only to this signing instance and the public key being distributed to all instances intended to be able to check signatures generated by the signing instance, referred to herein as "checking instances". Ideally, the key pair is generated by the signing entity itself, the private key is then stored in this signing entity in a read-protected manner and no longer leaves it, wherein the public key is distributed to the checking entities in a manipulation-protected manner and stored there in a manipulation-protected manner. For signing data, the signing entity requires this data and its own private key. The result of signing certain data with a certain private key is a so-called digital signature. For checking the correctness of a signature, the checking entity requires the public key of the signing entity, the signature and the signed data. The result of the test is then a truth value TRUE, FALSE. Here, checking the correctness of a signature is synonymous with checking the integrity of the signed data.For signature verification, a verification entity thus requires, in addition to the signature and the data, an implementation of the signature verification method matching the signing method used in signing and the public key matching the private key used in signing.A vehicle ecosystem may include both large servers and small low-performance control units, and vehicle ecosystems are therefore extremely heterogeneous, which means in particular that the participants of the ecosystem may differ greatly with regard to their performance (computing power, memory, etc.). Depending on the method used, operations with asymmetric keys may be comparatively resource intensive, both concerning the computing power and the memory. This can apply in particular both for signing, i.e. generating digital signatures, and for checking digital signatures. One consequence of this is that many control units, in particular low-performance control units, cannot implement "all conceivable" signature checking methods efficiently and must be limited to a few signature checking methods, frequently to a single signature checking method. In some control units, no signature checking methods at all can be implemented; in such a case, integrity protection must be ensured exclusively with the aid of symmetrical methods. At the same time, the participants of the vehicle ecosystem often have to be able to check signatures generated by signing entities located outside the own vehicle ecosystem, which is a problem since the vehicle manufacturer in this case has no or only little influence on which signing method the outside signing entity uses.As already mentioned above, the public key of the signing entity is required for checking the signature, which public key has to be transmitted to the checking entity in a tamper-proof manner and stored there in a tamper-proof manner. Both require certain capabilities of the control device, which are not always present in particular in the case of low-performance control devices.Since the service life of the vehicles and thus of the installed control units can amount to several decades, it can become advantageous or even necessary in this time, for example from a security point of view, to use a different signing method and / or a different asymmetric key pair from a specific signing entity for signing data. For example, it may be recommended by certain authorities, for example the Federal Office for Security in Information Technology (BSI), to no longer use a certain cryptographic method or a certain key length from a certain point in time. If the requirements of this authority are to be complied with, it is necessary to carry out the change in good time and to use a new signing method and / or key pair corresponding to the requirements. A changeover to a new signing method and / or new key pair at the signing entity may also be necessary because, for example, the originally used signing method and / or the originally used key length no longer correspond to the prior art and are generally regarded as not sufficiently secure.The use of another signing method and / or another private key by the signing entity has the consequence that each checking entity must likewise perform adaptations by having to implement a signature checking method matching the new signing method and / or having to equip the checking entity with the new public key of the signing entity matching the private key used during signing. These adaptations also require certain capabilities of the control device, which are not always present in particular in the case of low-power control devices.In summary, it can be said that checking signatures poses certain challenges to, in particular, low-performance participants and not all participants can efficiently implement this function, in particular in the range and flexibility offered. This now applies, for example, in a vehicle ecosystem primarily to the control units already discussed above.From the prior art, e.g. from WO 2014 / 199 128 A1, approaches are known in which devices delegate the signing of data, i.e. the creation of a signature, to another more powerful instance. See also, for example, "Proxy Signatures for Delegating Signing Operation" https: / / dl.acm.org / doi / pdf / 10.1145 / 238168.238185 (retrieved on 20.3.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 (retrieved on 20.3.2024)With respect to the further prior art, reference may be made to U.S. Pat. No. 2022 / 0 069 602 A1. This describes an encrypted authentication of a user at a charging station. The authorisation is requested via a central mobility service provider and then checked by the latter and confirmed in the case of a positive check.The object of the present invention is to specify a method for validating a signature of at least one signing entity for a system which has to check the signature, which method is improved in that the flexibility is increased when using the signature, and in that it also enables reliable signature checking, in the sense described above, in particular of low-performance systems or devices.According to the invention, this object is achieved by a method having the features in claim 1 and here in particular in the characterizing part of claim 1.Further advantageous embodiments and developments of the method are specified in the dependent claims dependent thereon.The method according to the invention therefore proposes that, in addition to the signing entity equipped with a signing method and a matching asymmetric key pair, which creates signatures for an ecosystem using this key pair, at least one checking entity is present. Thus, there is the ecosystem in which signature checks are performed, i.e. the at least one checking instance capable of checking the correctness of the signatures issued by the signing instance. This fact is now exploited by a system interested in checking a signature, called a requesting system here, in that it does not itself check the signature using the public key of the signing entity, but delegates this task to the checking entity. The checking entity checks the signature and transmits to the requesting system the result of the checking, e.g. a truth value such as TRUE or FALSE. A comparatively low-performance system with little computing and / or storage capacity can thus also obtain a reliable test result.Due to the delegation of the signature check to a checking entity, no signature checking method for checking signatures generated by the signing entity has to be implemented in the requesting system; in particular, the system does not have to store and use a public key of the signing entity in a manipulation-protected manner. This saves on the one hand capacities in the system and on the other hand the signing entity can thus always use the most reliable signing methods and key lengths corresponding to the prior art in coordination with the checking entity, independently of the requesting systems, with little effort for the signing process, without having to adapt the requesting systems which wish to check the signature. This enables a genuine safety advantage and also allows the latest technology to be used for long-lived systems, such as vehicle control devices, for these systems without having to install new checking methods and / or keys in the system itself in a secure way. This is a decisive advantage above all in the case of a large number of devices located in the field, in particular if these also originate from different device generations.According to the invention, it is provided that, as part of the transmission of the result by the test entity to the requesting system, at least parts of the request on which the test is based are also transmitted to the requesting system.Preferably, the returned portions of the request may comprise the checked data-signature pair.In this case, the request of the system to the test entity can then even be effected unprotected. The response of the test entity including the result of the test is then integrity-protected and / or authenticated and contains, as explained above, at least parts of the request on which the test is based. After receiving the response, the system can thus check whether the parts of the request that are transmitted during the transmission of the result match the request that is made.An advantageous embodiment of the method provides, in this case, furthermore, for the checking entity to be equipped at least with a signature checking method for checking signatures generated by the signing entity with the aid of the signing method and with the public key of the signing entity.The checking entity can also perform the checking of signatures generated with different private keys, in particular of signatures generated by different signing entities. For this purpose, the checking entity must have implemented the corresponding signature checking methods and must be equipped with the associated public keys of the signing entities. In order to be able to perform a meaningful signature check, the checking entity must be informed, in addition to the signed data and the signature, of which signing method and which private key has been used during the signing operation. For this purpose, the potentially usable key pairs must receive unique identifiers with the aid of which they can be identified. The unique identifier of the private key used in the signing process must then be communicated to the requesting system together with the signature, the requesting system in turn then transmits this identifier together with the signed data and the signature to the checking entity in the event of a request. If the signing method used in signing does not emerge unambiguously from the other transmitted data, for example the signature or the unique identifier of the public key, this information must likewise be transmitted to the checking entity.The security of the requesting system can significantly depend on the knowledge of whether the signature to be checked is correct, that is to say on the correctness of the check carried out by the checking entity of the signature transmitted to said checking entity. In order that an attacker cannot manipulate, e.g., exchange, the request made to the test entity, i.e., for example, the transmitted data signature pair, unnoticed, it is helpful to transmit the request to the test entity in an integrity-protected manner. Accordingly, according to a very advantageous development of the method according to the invention, it is provided that the request of the system to the test entity including the data-signature pair to be tested is made integrity-protected and / or authenticated.On the other hand, it is also important that an attacker cannot falsify or manipulate the result of the test carried out by the test instance unnoticed on the way from the test instance to the requesting system. A further very advantageous embodiment therefore provides that the response of the test instance to the requesting system including the result of the test is integrity-protected and / or authenticated.Both in the case of the request and in the case of the response, known asymmetric methods, for example digital signatures, or symmetric methods, for example, can be used to ensure the integrity or authenticity. Message Authentication Codes (MAC) may be used.In this case, it can be advantageous to include in the message of the result of the test to the requesting system Sys not only the binary result of the test per se (TRUE / FALSE) but also the complete request or parts of the request, i.e. for example the tested 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 checking entity can be dispensed with, because on the basis of the result communicated to it containing the request on which the signature checking is based, in particular the checked data-signature pair, the requesting system can determine whether the communicated result results from the checking of the originally placed request by comparing the data contained in the original request with the data from the request contained in the integrity-protected result, for example the checked data-signature pair. Dispensing with the integrity-protected transmission of the request can significantly simplify the implementation of the requesting system, since an integrity-protected transmission usually requires a secret stored in the transmitter, in this case the requesting system, in a read-protected manner, for example a private key, which can be dispensed with in the case of dispensing with the integrity protection.In order for the requesting system to be able to rely on the result of the checking of the signature reported by the checking entity, the requesting system must trust the checking entity. According to a very advantageous embodiment of the method, the test entity should therefore be a trusted entity from the perspective of the requesting system.As already mentioned above several times, the method can be used particularly advantageously in a vehicle ecosystem. In this case, it is then provided that the systems are designed as control units in a vehicle environment which, in addition to the control units of the individual vehicles, comprises at least one vehicle-external server, the aforementioned backend, which is in a communication connection with the vehicles and at least some of their control units.In such an application, it may be advantageous and provided that the test instance is designed as a vehicle test instance in a special control device provided for this purpose, for example as part or module of this control device of the respective vehicle. The test can then be offered to the other control units installed in the same vehicle or also to the other subsystems / modules of the same control unit. The vehicle buses can be used to transmit the requests and to communicate the results, which has the advantage of rapid response of the requests, that is to say rapid performance of the signature check. In-vehicle integrity protection mechanisms, especially, can also be used. Basic Integrity Assurance Mechanisms, such as. SecOC can be used directly to protect the integrity of the requests and / or the results. A control device, in particular a control device or module of a control device specifically designed for signature checking, can be designed in an optimized manner in accordance with this task, so that the capacity problem that otherwise frequently occurs in control devices is thus of no consequence here.In an alternative or particularly preferably also supplementary embodiment of the method according to the invention, the checking of signatures can also be realized by a vehicle-external server (backend) or a subsystem thereof, which has the advantage that the backend has much larger resources and much higher flexibility compared to a control device, which in particular allows a larger number of offered signature checking methods and / or used key lengths and, if necessary, a faster and simpler recording of further signature checking methods and / or used key lengths.These two approaches can be combined advantageously by setting up a test entity both in the vehicle and in the backend and carrying out the signature test by one or the other test entity as the case may be, as a result of which the advantages of both types of test entities can be used.For this purpose, it can now be provided that the system transmits its request, including the data signature pair to be checked, to the vehicle checking entity which carries out the check or forwards the request, including the data signature pair to be checked, for checking to the backend checking entity which carries out the check and transmits the result of the check to the vehicle checking entity.The system or control device is thus always available the vehicle test entity as a response partner. The communication between these two partners is therefore possible within the vehicle in a simple efficient and protected manner. After receiving the request, the vehicle checking entity checks whether it can perform the requested checking itself, in particular whether it has implemented the required signature checking method and is in possession of the required public key of the signing entity. If so, the vehicle test instance checks whether it is more efficient to perform the test itself or to delegate it to the backend test instance. If this is not the case, the test is delegated immediately to the backend test instance. In this case, the vehicle test entity appears as a requesting system compared to the backend test entity. If the test is carried out by the vehicle test entity, the situation described above occurs with a requesting system and a test entity. If the test is carried out by the backend test instance, the vehicle test instance receives the request from the requesting system and then forwards this request in turn as a "requesting system" to the backend test instance.There are now various possibilities with regard to the result. Thus, in a first variant, it can be provided that the vehicle test instance transmits the result together with information about which of the instances has carried out the test to the requesting system. According to a very advantageous embodiment, it can also be provided that an end-to-end integrity protection is set up for the request and the transmission of the result between the system and the back-end test instance. The vehicle test entity thus remains in the transmission chain, but without obtaining a possibility for intervention in the data traffic.Furthermore, according to a very advantageous development, it can be provided that the requesting system specifies which of the instances is to carry out the check. The system or control device therefore reserves the right here to select the test instance.According to another approach, however, it could also be provided that the vehicle test instance always transmits the result to the requesting system in its own name. This therefore has no knowledge of whether the vehicle checking entity or the backend checking entity has checked the signature. In this embodiment of the combination of a vehicle test instance and a backend test instance, the requesting system and the backend test instance need not know anything from each other, the requesting system makes all requests to the vehicle test instance, which also returns all results. If integrity protection methods are used, the integrity of the received request or of the received result must be checked by the vehicle checking entity and then, when forwarding the request or the result to the respective receiver, newly protected with the integrity protection method used between the vehicle checking entity and the receiver, for example provided with a signature or a message authentication code. In this embodiment, in particular no end-to-end integrity protection is thereby ensured.Further advantageous embodiments of the method according to the invention are also evident from the remaining dependent dependent claims and become clear on the basis of the exemplary embodiments which are described in more detail below with reference to the figures.The following are shown: FIG. 1 shows a diagram of a first embodiment of the method according to the invention; FIG. 2 shows a diagram of a diagram of a first embodiment of the method according to the invention having a plurality of signing instances; FIG. 3 shows a diagram of a diagram with an exemplary vehicle-related implementation of two test instances in a first embodiment of the method according to the invention; and FIG. 4 shows a diagram of a diagram with an exemplary vehicle-related implementation of two test instances in a second embodiment of the method according to the invention.The illustration in FIG. 1 shows a possible embodiment of the method in which a signature Sig generated by the signing entity SI for data Dat is transmitted from a system Sys to a checking entity PI and is checked there with the aid of a dedicated service implemented by the checking entity PI. The dashed arrow and the cloud symbolise that the data Dat and the signature Sig are transmitted to the requesting system Sys decoupled from the actual checking process and from one another but before the checking process. Since the signature Sig is generated by the signing entity SI, it originates in the signing entity SI. The data Dat to be signed, on the other hand, do not necessarily have to originate from the signing entity SI; they can be transmitted from any point in the ecosystem to the requesting system Sys.If more than one signing instance SI is used, then the scheme, for the example of two signing instances SI 1 and SI 2, would be as depicted in FIG. 2 analogously to the representation in FIG. 1. In the case of two signing entities SI 1, SI 2 using the same signing method Sign, each with two and one key pair and one requesting system Sys, the expression is as follows. It should be noted that the checking entity PI must keep three public keys available in order to be able to check all signatures generated by the signing entities SI 1, SI 2. The unique identifiers of the keys result from the identity of the signing instance SI 1, SI 2 and the serial number of the key pair within the respective signing instance SI 1, SI 2.FIG. 3 shows a first exemplary implementation of the combination of a vehicle test instance FPI and a backend test instance BPI. In this case, the data are protected from integrity during the transmission from one communication partner to the other, wherein the communication between the requesting system Sys and the vehicle test entity FPI is protected with the aid of symmetrical message authentication codes and the communication between the vehicle test entity FPI and the backend test entity BPI is protected with the aid of asymmetrical digital signatures. In this case, the following steps are carried out in detail. 1. the signing entity SI a equipped with at least one implementation of a signing method Sign and a matching asymmetric key pair SIPub, SIPriv signs the data Dat with the aid of the signing method Sign and its private key SIPriv and generates the signature Sig, b. transmits the signed data Dat and the signature Sig to the requesting system Sys 2. the requesting system Sys equipped with at least the following meansan implementation of a method for generating a message authentication code MAC and a matching symmetric key MKey, which it shares with the vehicle checking entity FPI and with the aid of which the communication with the vehicle checking entity FPI is integrity protected, after the receipt of the data signature pair (Dat, Sig), carries out the following steps by a. generating, with the aid of the method for generating a message authentication code MAC and the symmetric key MKey, a message authentication code M1 for the received data signature pair (Dat, Sig), b. transmitting the data signature pair (Dat, Sig) and the generated message authentication code M 1 to the vehicle test entity FPI.3. The vehicle test entity FPI, which is equipped with at least the following meansan implementation of a vehicle signing method SignF and a matching asymmetric key pair FPIPub, FPIPrivpotentially (marked in FIG. 3 by question marks) an implementation of the signature checking method Ver for checking signatures Sig generated by the signing method Sign used by the signing instance SI and the matching public key SIPub of the signing instance SIan implementation of the method for generating a message authentication code MAC and the matching symmetric key MKey, which it shares with the requesting system Sys and with the aid of which the communication with the requesting system Sys is integrity protectedan implementation of a signature checking method VerB for checking signatures S2 generated in the backend checking instance BPI and the matching public key BPIub of the backend checking instance BPI for ensuring the integrity of the data received from the backend checking instance BPI, after the data signature pair (Dat, Sig) and the message authentication code M1 have been received, carries out the following steps by a. checking with the aid of the checking function for message authentication codes CheckMAC derived from the method for generating a message authentication code MAC, the integrity of the received data-signature pair (Dat, Sig) of the stored symmetrical key MKey and the received message authentication code M 1. If the check fails, an exception treatment is initiated (not shown in FIG. 3 ). b. Checks whether the checking of the signature Sig contained in the received data-signature pair (Dat, Sig) can be carried out locally. If this is not the case, the method continues with step 3.g. c. checks whether it is efficient to carry out the signature check locally. If this is not the case, the method continues with step 3.g. d. the result Erg of the signature check of the data-signature pair (Dat, Sig) using the signature checking method Ver and the public key SIPub of the signing entity SI. e. generates a message authentication code M2 for the calculated result Erg. f. the result Erg and the generated message authentication code M2 are transmitted to the requesting system Sys using the method for generating a message authentication code MAC and the symmetric key MKey. Subsequently, the method moves to step 6 a. g. generates the signature S 1 of the data-signature pair (Dat, Sig) nusing the implemented vehicle signing method SignF and the own private key FPIPriv, i.e. transmits the data-signature pair (Dat, Sig) and the generated signature S 1 to the backend checking entity BPI.4. The backend checking entity BPI, which is equipped with at least the following meansan implementation of a back-end signing method SignB and a matching asymmetric key pair BPIub, BPIriv,an implementation of the signature checking method Ver for checking signatures Sig generated by the signing instance SI and the matching public key SIPub of the signing instance SI,an implementation of a signature checking method VerF for checking signatures S 1 generated in the vehicle checking entity FPI and the matching public key FPIPub of the vehicle checking entity FPI for ensuring the integrity of the data received from the vehicle checking entity FPI, after the receipt of the data signature pair (Dat, Sig) and the signature S 1, carries out the following steps by a. checking with the aid of the implemented signature checking method VerF, the integrity of the received data-signature pair (Dat, Sig) of the stored public key FPIPub of the vehicle checking entity FPI and of the received signature S 1. If the check fails, an exception treatment is initiated (not shown in FIG. 3 ). b. calculates the result Erg of the signature check of the data-signature pair (Dat, Sig) with the aid of the signature checking method Ver and the public key SIPub of the signing entity SI. c. generates the signature S 2 of the result Erg with the aid of the implemented signing method SignB and the own private key BPPriv. d. transmits the result Erg and the generated signature S 2 to the vehicle checking entity FPI.5. After receiving the result Erg and the signature S2, the vehicle checking entity FPI performs the following steps a. checks the integrity of the received result Erg with the aid of the implemented signature checking method VerB, the stored public key BPIub of the backend checking entity BPI and the received signature S2. If the test fails, an exception treatment is initiated (not shown in FIG. 3 ). b. the method proceeds to step 3.e. 6.The requesting system Sys, after the receipt of the result Erg and the message authentication code M2, carries out the following steps a. checks the integrity of the received result Erg with the aid of the checking function for message authentication codes CheckMAC derived from the method for generating a message authentication code MAC, the stored symmetrical key MKey and the received message authentication code M2. If the test fails, an exception treatment is initiated (not shown in FIG. 3 ). b. uses the transmitted result Erg.The embodiment described with reference to FIG. 3 has the advantage that the requesting system Sys communicates only with the vehicle test entity FPI at all levels and therefore in particular only has to keep integrity protection methods ready for this communication. The disadvantage of this first embodiment is that both participating test entities, i.e. both the vehicle test entity FPI and the back-end test entity BPI, must be trusted; in particular, no end-to-end integrity protection is ensured between the back-end test entity BPI and the requesting system Sys in this embodiment.In an alternative embodiment of the combination of a vehicle test instance FPI and a backend test instance BPI, in which the requesting system Sys knows both the vehicle test instance FPI and the backend test instance BPI, this disadvantage is eliminated. As above, the requesting system Sys also makes all requests to the vehicle test instance FPI. In contrast to the first embodiment, however, the requesting system Sys can specify, as part of the request, whether it would like to have carried out the test as far as possible by the vehicle test entity FPI or necessarily by the backend test entity BPI. Furthermore, the requesting system Sys can be explicitly indicated to the vehicle test entity FPI as part of the result message which test entity has carried out the test and determined the result Erg. Furthermore, an end-to-end integrity protection can be implemented between the requesting system Sys and the back-end checking instance BPI, wherein both symmetrical and asymmetrical integrity protection methods can be used. If end-to-end integrity protection is provided in this way and if the checking is always carried out by the back-end checking entity BPI, for example because the requesting system Sys requires this, the vehicle checking entity FPI in this variant serves exclusively for the communication between the requesting system Sys and the back-end checking entity BPI, in particular in this variant the requesting system Sys does not have to trust the vehicle checking entity FPI.FIG. 4 shows an exemplary implementation of this second embodiment. In this case, the respective requests are transmitted unprotected by the requesting system Sys to the vehicle test instance FPI and also from the vehicle test instance FPI to the backend test instance BPI. The transmission of the result from the respective checking entity FPI or BPI to the requesting system Sys is, on the other hand, protected with the aid of digital signatures, wherein, as proposed above, in addition to the pure result of the signature checking Erg, the checked data-signature pair (Dat, Sig) and the identity IdPI of the checking entity FPI or BPI carrying out the signature checking are also signed and transmitted. In order that the requesting system Sys only needs to implement a signature checking method, the same signing method SignFB is used by both checking entities FPI and BPI. In this case, the following steps are carried out in detail: 1. the signing entity SI a equipped with at least one implementation of a signing method Sign and a matching asymmetric key pair SIPub, SIPriv signs the data Dat with the aid of the signing method Sign and its private key SIPriv and generates the signature Sig, b. transmits the signed data Dat and the signature Sig to the requesting system Sys 2. the requesting system Sys equipped with at least the following meansan implementation of a signature checking method VerFB for checking signatures S3 and S4 generated in the vehicle checking instance FPI and in the backend checking instance BPI and using the matching public keys FPIPub and BPIPub of the vehicle checking instance FPI and the backend checking instance BPI to ensure the integrity of the data received from the vehicle checking instance FPI and from the backend checking instance BPI, performs the following steps by a. after the data signature pair (Dat, Sig) has been received, transmits the data signature pair (Dat, Sig) to the vehicle test entity FPI.3. The vehicle test entity FPI, which is equipped with at least the following meansan implementation of the common signing method SignFB and a matching asymmetric key pair FPIPub, FPIPrivpotentially (marked in FIG. 4 by question marks) an implementation of the signature checking method Ver for checking signatures Sig generated by the signing method Sign used by the signing entity SI and the matching public key SIPub of the signing entity SI, after the receipt of the data signature pair (Dat, Sig) performs the following steps a. checking whether the checking of the signature Sig contained in the received data signature pair (Dat, Sig) can be carried out locally. If this is not the case, the method continues with step 3.g. checks whether it is efficient to carry out the signature check locally. If this is not the case, the method continues with step 3.g. c. calculates the result Erg of the signature check of the data-signature pair (Dat, Sig) with the aid of the signature checking method Ver and the public key of the signing entity SIPub. d. assigns the parameter IdPI to be signed and transmitted together with the result Erg the own identity "FPI". e. generates the common signature S 3 of the result Erg of the signature check, of the checked data-signature pair (Dat, Sig) and the identity of the checking entity IdPI using the implemented shared signing method SignFB and the own private key FPIPriv. f. transmit the result Erg, the checked data-signature pair (Dat, Sig), the identity of the checking entity IdPI and the generated signature S 3 to the requesting system Sys. The method then proceeds to step 6 a. g. transmits the data signature pair (Dat, Sig) to the backend checking entity BPI.4. The backend checking entity BPI, which is equipped with at least the following meansan implementation of the common signing method SignFB also used by the vehicle checking entity FPI and a matching asymmetric key pair BPIub, BPIriv,an implementation of the signature checking method Ver for checking signatures Sig generated by the signing instance SI and the matching public key SIPub of the signing instance SI, after the receipt of the data-signature pair (Dat, Sig), carries out the following steps a. calculates the result Erg of the signature checking of the data-signature pair (Dat, Sig) using the signature verification method Ver and the public key of the signing entity SIPub. b. assigns the parameter IdPI to be signed and transmitted together with the result Erg the own identity "BPI". c. generates the common signature S 4 of the result Erg of the signature verification, the data-signature pair (Dat, Sig) and the identity of the verification entity IdPI using the implemented signing method SignFB and the own private key BPIriv. d. transmits the result Erg, the checked data-signature pair (Dat, Sig), the identity of the test instance IdPI and the generated signature S4 to the vehicle test instance FPI.5. After receiving the result Erg, the checked data-signature pair (Dat, Sig), the identity of the checking entity IdPI carrying out the checking and the signature S 4 generated by the backend checking entity BPI, the vehicle checking entity FPI performs the following steps a. transmits the result Erg, the checked data-signature pair (Dat, Sig), the identity of the checking entity IdPI and the generated signature S 4 to the requesting system Sys. 6.The requesting system Sys, after receiving the result Erg, the checked data-signature pair (Dat, Sig), the identity of the checking entity IdPI carrying out the checking and the signature S3 or S4 generated by the checking entity, carries out the following steps a. checking whether the data-signature pair (Dat, Sig) contained in the request matches the checked data-signature pair (Dat, Sig) transmitted with the result Erg. If the test fails, an exception treatment is initiated (not shown in FIG. 4 ). b.if the signature checking has been carried out by the vehicle checking entity FPI, the integrity of the received data, that is to say the result Erg, the checked data-signature pair (Dat, Sig) and the identity of the checking entity IdPI carried out the checking, checks with the aid of the implemented common signature checking method VerFB, the stored public key FPIPub of the vehicle checking entity FPI and the received signature S3. If the test fails, an exception treatment is initiated (not shown in FIG. 4).if the signature checking has been carried out by the backend checking entity BPI, the integrity of the received data, that is to say the result Erg, of the checked data-signature pair (Dat, Sig) and the identity of the checking entity IdPI carried out the checking, checks with the aid of the implemented common signature checking method VerFB, the stored public key BPIPub of the backend checking entity BPI and the received signature S4. If the test fails, an exception treatment is initiated (not shown in FIG. 4).If the identity of an unknown test instance has been transmitted, an exception treatment is initiated (not shown in FIG. 4).c. uses the transmitted result Erg.

Claims

Method for validating a signature (Sig) of at least one signing entity (SI) for a system (Sys) which requires the result of checking the signature (Sig), wherein the signing entity (SI) is equipped with an asymmetric key pair (SIPub, SIPriv) for creating the signature (Sig) of data (Dat) to be signed, wherein at least one checking entity (PI, BPI, FPI) is established for checking signatures (Sig) generated by the at least one signing entity (SI), wherein, for carrying out the checking, the signature (Sig) to be checked together with the signed data (Dat) is established by the system (Sys), which requires the result of the checking of the signature (Sig) to the checking entity (Pl. BPI, FPI), according to which the checking entity (PI, BPI, FPI) carries out the checking of the signature (Sig), and according to which the result (Erg) of the checking is transmitted to the requesting system (Sys), characterized in that, as part of the transmission of the result (Erg) by the checking entity (PI, BPI, FPI) to the requesting system (Sys), at least parts of the request on which the checking is based are also transmitted to the requesting system (Sys).Method according to Claim 1, characterized in that the checking entity (PI, BPI, FPI) is equipped at least with a signature checking method (Ver, VerB, VerF, VerFB) for checking signatures (Sig) generated by the signing entity (SI) with the aid of the signing method (Sign) and with the public key (SIPub) of the signing entity (SI).Method according to Claim 1 or 2, characterized in that a request from the system (Sys) to the checking entity (PI, BPI, FPI) including the data-signature pair ((Dat, Sig)) to be checked is made integrity-protected and / or authenticated.Method according to Claim 1, 2 or 3, characterized in that a response of the checking entity (PI, BPI, FPI) to the requesting system (Sys) including the result (Erg) of the checking is carried out with integrity protection and / or authentication.Method according to one of Claims 1 to 4, characterized in that, as part of the transmission of the result (Erg) by the test entity (PI, BPI, FPI) to the requesting system (Sys), at least one binary indication (TRUE / FALSE) about the test result is transmitted to the latter.Method according to one of Claims 1 to 5, characterized in that the parts of the request transmitted back comprise the checked data-signature pair (Dat, Sig).Method according to one of Claims 1 to 6, characterized in that a request from the system (Sys) to the test entity (PI, BPI, FPI) is effected in unprotected fashion, wherein a response from the test entity (PI, BPI, FPI) to the requesting system (Sys) including the result (Erg) of the test is effected in an integrity-protected and / or authenticated fashion, and wherein the system checks whether the parts of the request which are transmitted as part of the request match the request which is made within the scope of the transmission of the result (Erg).Method according to one of Claims 1 to 7, characterized in that a trusted entity is used as the checking entity (PI, BPI, FPI)Method according to one of Claims 1 to 8, characterized in that the systems (Sys) are designed as control units in a vehicle environment.Method according to Claim 9, characterized in that the test entity (PI) is designed as at least one vehicle test entity (FPI) in a control device of the respective vehicle.Method according to either of Claims 9 and 10, 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.Method according to Claim 11, characterized in that the checking entity (PI) is designed as at least one backend checking entity (BPI) in the vehicle-external server.Method according to Claims 10 and 11, characterized in that at least one vehicle checking entity (FPI) and at least one back-end checking entity (BPI) are used, wherein the system (Sys) transmits its request, including the data signature pair (Dat, Sig)) to be checked, to the vehicle checking entity (FPI) which carries out the check or forwards the request, including the data signature pair (Dat, Sig)) to be checked, to the back-end checking entity (BPI) which carries out the check and transmits the result (Erg) of the check to the vehicle checking entity (FPI).Method according to Claim 12, characterized in that the vehicle checking entity (FPI) transmits the result (Erg) to the requesting system (Sys) together with information about which of the entities (FPI, BPI) has carried out the checking.Method according to Claim 13 or 14, characterized in that the requesting system (Sys) specifies which of the instances is intended to carry out the check (FPI, BPI).Method according to Claim 13, 14 or 15, characterized in that an end-to-end integrity protection is set up for the request and / or the transmission of the result (Erg) between the requesting system (Sys) and the backend checking entity (BPI).Method according to Claim 13, characterized in that the vehicle checking entity (FPI) transmits the result (Erg) in its own name to the requesting system (Sys).

Images