Method for integrity-protected use of services
By transmitting unsigned requests and verifying signed responses, the method addresses resource constraints in vehicle components, ensuring response authenticity and integrity while reducing computational burden and preventing attacks.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- MERCEDES BENZ GROUP AG
- Filing Date
- 2025-10-20
- Publication Date
- 2026-06-04
AI Technical Summary
Less powerful components in vehicle ecosystems, such as control units, struggle to efficiently generate and manage asymmetric key pairs and digital signatures due to resource constraints, making it difficult to ensure the integrity and authenticity of request-response communications.
The requesting instance transmits an unsigned request message and temporarily stores the request payload, allowing the responding instance to generate a signed response payload and signature, which the requester then verifies using the responder's public key, ensuring the response's authenticity without needing to sign the request.
This method reduces resource requirements for the requester, ensuring the response payload's authenticity and integrity without the need for the requester to generate signatures, while mitigating replay and timing attacks through additional security measures like timestamps and unpredictable identifiers.
Smart Images
Figure EP2025080243_04062026_PF_FP_ABST
Abstract
Description
[0001] Mercedes-Benz Group AG
[0002] Procedures for the integrity-protected use of services
[0003] The invention relates to a method for the integrity-protected use of services of a requested / responding instance (RESP), to which a requesting instance (REQ) transmits a request message and receives a response message from the requested / responding instance (RESP).
[0004] Modern vehicles are part of a large, interconnected vehicle ecosystem. The electronic control units (ECUs) installed in the vehicles are a key component of this ecosystem. Another central part of this ecosystem is the so-called backend, a server (usually owned by the OEM) to which the vehicles are connected via the internet. Communication between individual ECUs within a vehicle is often protected against data loss, for example, using the SecOC (Secure Onboard Communication) standardized by AUTOSAR. Communication between vehicle ECUs and other participants in the vehicle ecosystem, especially the backend, is currently secured using established standard protocols (mostly TLS, sometimes IPSec). In some situations, such as for certain services or applications, the basic protection provided by standardized protocols is insufficient; in these cases, additional security mechanisms are employed.at the application level.
[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 that is to sign data is equipped with such an individual key pair. The private key is known only to that signing instance, while the public key is distributed to all instances that are to be able to verify signatures generated by the signing instance.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 to be signed and its own private key. The result of signing specific data with a specific private key is a signature. To verify the validity of a signature, the verifying instance requires the signing instance's public key, the signature itself, and the signed data. The result of the verification is a Boolean value (TRUE or FALSE). This verification process confirms the integrity of the signed data.
[0006] Participants in a vehicle ecosystem often communicate with each other using a request-response pattern. In this pattern, one participant, acting as the requester, sends a request message to another participant, acting as the responder. Upon receiving the request, the responder processes it and then sends a response message back to the first participant, containing the result of the second participant's processing of the request. This communication pattern is widely used, for example, in client-server architectures.
[0007] The request is a task assigned to the responder by the requester, and the responder signals its completion with a response. Depending on the task and its processing status, the response can contain various pieces of information, such as the (final) result of the completed task, a simple indication (TRUE / FALSE) of task completion, or an indication that the task cannot currently be completed. This document therefore distinguishes between the request message (request / response), which refers to the complete message, and the core content of the request (request payload), which contains the actual task or the result of its processing.It is therefore assumed that every request / response contains a request payload / response payload and may also contain further data, e.g., for transmission or for securing the transmission.
[0008] A request-response communication process can have different effects. It can be a simple query of information that has no effect on the responder's state, similar to an HTTP GET request. Examples of such state-preserving requests would be querying the time, temperature, or the number of passengers in the vehicle. However, a request-response communication process can also change the responder's state, similar to an HTTP POST request. An example of such a state-changing task would be setting the time on the responder and subsequently sending confirmation of the change to the requester.
[0009] Depending on the data contained in the request payload and / or response payload, and the impact the communication process has or could have on the requester and / or responder, different protection requirements arise for the request and / or response. If a request payload and / or response payload contains confidential data, it must be protected against unauthorized interception during transmission, for example, by encryption. If a request triggers potentially security-critical processes at the responder, the responder must be able to verify, before processing the received request payload, that it actually originates from the requester and that it has not been manipulated during transmission.
[0010] Often, however, the requester only wants to receive specific non-confidential information from the responder, and the generation of this information by the responder must not pose any security risks to the responder, particularly not altering its state. The requester also wants to ensure that the response payload contained in the received response truly originates from the responder and that this response payload is the result of processing its previously submitted request, i.e., its request payload. The goal in this case is therefore to ensure the authenticity of the responder's response payload and its relationship to the previously transmitted request payload, whereby the authenticity and confidentiality of the request payload and the confidentiality of the response payload are irrelevant. This scenario is the focus of the method according to the invention.
[0011] This goal—ensuring the authenticity of the response payload and its relationship to the previously transmitted request payload—can be achieved in a straightforward manner using the digital signatures described above. During the provisioning phase, both the requester and the responder are each equipped with their own asymmetric key pair. Subsequently, both the requester and the responder are provided with the other's public key. During operation, the requester's request payload (and potentially other request data) is signed with its private key, and the request, containing at least this signature in addition to the request payload, is then transmitted to the responder.Upon receiving the request, the responder verifies the correctness of the received data, and in particular the correctness of the request payload, using the received signature and the requester's public key. If the verification is successful, the request payload is processed, and the result of this processing is generated, forming the response payload. Before being sent to the requester, the response payload (and any additional data within the response) is signed with the responder's private key. The response, containing the response payload, the signature generated in this way, and any additional data, is then transmitted to the requester. After receiving the response, especially the signed data and the signature it contains, the requester verifies its correctness, and in particular the correctness of the response payload, using the responder's public key.If this check is successful, the requester assumes that the received response payload was generated by the responder and can use the information it contains accordingly. Such a procedure is described, for example, by WO 2014 / 138494 A1.
[0012] The secure link between the received response payload and the previously transmitted request payload can be achieved, for example, by ensuring that each request sent by a requester is marked with the requester's identity and a unique identifier, such as a sequential number or a timestamp containing the current date and sufficiently accurate time. Furthermore, the requester's identity, along with this unique identifier, is included in the corresponding (signed) response generated by the responder. By comparing the identity and identifier in the sent request with those in the received response, the requester can determine whether the response payload belongs to the previously transmitted request payload. It is crucial to sign the identity and identifier during transmission to prevent their undetected manipulation.
[0013] Vehicle ecosystems can include everything from large servers to small, low-powered control units, making them extremely heterogeneous. This means, in particular, that the components within the ecosystem can vary significantly in terms of their performance (computing power, storage, etc.). Depending on the method used, operations with asymmetric keys can be comparatively resource-intensive, both in terms of computing power and storage requirements. This can be especially true for generating asymmetric key pairs and for signing, i.e., creating digital signatures.
[0014] As mentioned above, the signing instance must be equipped with a private key, which is part of a key pair. Ideally, the key pair is generated by the signing instance itself, and the private key is then stored securely within this instance and never leaves it. All of this—generating asymmetric key pairs, securely storing the private key in a read-only and tamper-proof manner, and generating digital signatures in a secure environment using the private key—requires certain capabilities from the control unit, which are not always present, especially in less powerful control units.This means, in particular, that the obvious procedure described above, in which all communication between the requester and the responder, especially the request payload, is integrity-protected, cannot be efficiently implemented by many control units acting as requesters because they cannot efficiently perform all the associated tasks (generating a key pair, securely storing the private key, generating digital signatures in a secure environment). Verifying digital signatures, on the other hand, is much easier to implement, since no key pair needs to be generated and no private key needs to be stored and used in a read- and tamper-proof manner.In summary, generating signatures poses certain challenges, particularly for less powerful components in the vehicle ecosystem, and not all components, especially not all control units, can implement this function efficiently. Therefore, it is advantageous to solve the task described above in a way that eliminates the need for the requester to generate digital signatures.
[0015] WO 2024 / 206 861 A1 describes an approach in which an authentication device communicates with a responding system via an intermediary. Keys or signatures are used for this purpose.
[0016] In the “Handbook of Applied Cryptography” by Menezes, AJ et al., CRC Press 1997, ISBN: 0-8493-8523-7, pages 403 to 405 and pp. 428 to 430, various types of signature verification are described. This includes a challenge-response procedure using a random number. German patent DE 10 2019 114 844 A1 extends this by additionally using the random number in the response message.
[0017] German patent DE 102020 003 328 A1 describes the combination of a challenge-response procedure with a timestamp. This includes not only the time but also the date to ensure its uniqueness.
[0018] From DE 102015202 936 A1 it is known to monitor the time span until the response in a challenge response procedure.
[0019] Therefore, the object of the present invention is to provide a solution in which the requesting instance (Requester) does not have to sign its request message transmitted to the requested / responding instance (Responder), but in which it can still ensure that the reply message subsequently received by it relates to the previously sent request, and that the received reply message actually originates from the requested / responding instance (Responder) and has not been manipulated during transmission.
[0020] 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 are described in the dependent claims.
[0021] The method according to the invention serves for the integrity-protected use of services of a requested / responding instance (responder), to which a requesting instance (requester) transmits a request message (request) and from which the requesting instance (requester) receives a response message (response).
[0022] Naturally, the requester knows the request it is transmitting to the responder; in particular, it can temporarily store the request, or parts of it, especially the core content (request payload), locally after transmission to the responder. As long as the signature generated by the responder to protect the integrity of the transmitted response payload includes not only the response payload itself but also the underlying request payload, integrity protection during transmission from the requester to the responder is unnecessary. The basic idea, therefore, is that the requester should not sign the request, or at least the request payload—that is, the core content of the request.According to the invention, the requesting instance transmits at least the core content of the request unsigned in the request message to the requested / responding instance and temporarily stores at least the core content of the request locally.
[0023] Following receipt of the request message, the queried / responding instance generates a content core of the response based on the core content of the request. The responder then signs the combination of at least the generated content core of the response and the received content core of the request with its private key. The responder then sends the requester a response message containing at least the generated content core of the response and the generated signature. This response message does not include the co-signed content core of the request or any other data content transmitted in the request message that is known to the requester.After receiving the response message containing the response payload, optional additional data, and the signature, the requester reconstructs the data presumably signed by the responder from the received response payload, the received optional additional signed data unknown to the requester, the original cached request payload, and the optional data content known to the requester, e.g., cached data.
[0024] The request message always includes the core content of the request, i.e., the request payload. At least this is cached by the requester. Optionally, the request message can also include other data, which can be cached in whole or in part.
[0025] Depending on which of the aforementioned data were transmitted, the responder now signs the core content of the response it generates (the response payload), the request payload transmitted to it (which is always cached by the requester), and optionally, any additional data transmitted to it by the requester (data content). Additional data generated by the responder can also be optionally signed. In that case, however, this data must be part of the response message.
[0026] The response message now contains the signature as well as at least all signed data that is unknown to the requester, i.e., not cached by them or that they cannot generate themselves. The requester can therefore reconstruct the presumably signed data from the response message and from information they have cached or can generate.
[0027] The correctness of this supposedly signed data is then checked against the received signature using the responder's public key stored in the requester. If the verification fails, exception handling can be initiated, such as discarding the response message, generating an alert, creating a log entry, or similar actions.
[0028] Although it is generally sufficient to transmit the request payload unsigned for the implementation of the procedure, it is still advisable to refrain from signing all data contained in the request message.
[0029] According to a highly advantageous embodiment of the invention, this is also provided to completely eliminate the resources required for signature processing in the requester, which, according to a preferred embodiment, can be a control unit in a vehicle. According to an advantageous embodiment of the method, the combination can include additional data that is also signed and that is taken into account when temporarily storing parts of the request and / or when generating the response, as well as during reconstruction. Thus, additional data beyond the response payload and the request payload can also be included in the signature generation process.
[0030] The combination of data before signing can be configured in any way, as long as the participating instances know the corresponding combination rule. However, it is particularly advantageous if the combination is executed as a concatenation, i.e., as a simple sequence of the data. In that case, it is sufficient for both instances to know the order.
[0031] Using the described method according to the invention, the requester is able to ensure that the received response payload actually originates from the responder and that it was created based on the request payload contained in the request. However, it cannot verify whether the response was created for the previously transmitted request or for another request containing the same request payload. Likewise, the requester cannot determine whether the response was created "on its behalf" or on behalf of a third party who transmitted an "equivalent" request to the responder. The requester also cannot determine the time at which the response payload was created.
[0032] Whether these limitations of the solution according to the invention are relevant or not depends on the method used by the responder to form the corresponding response payload for a received request payload.
[0033] If this process is a stateless function whose result depends solely (functionally) on the request itself, meaning that for two identical request payloads the same response payload is always generated, regardless of when the request payload is received or the response payload is generated, and especially regardless of the current state of the responder, then it is irrelevant to the requester at what time or on whose behalf the response payload was generated by the responder.Since the same response payload is always generated for the same request payload, and the authenticity of the received response payload as well as the equality of the sent request payload and the request payload used by the responder to determine the response payload can be ensured by the solution according to the invention described above, no further measures need to be taken to ensure that the received response belongs to the previously transmitted request.
[0034] Examples of such stateless functions are mathematical addition, where the values to be added are contained in the request payload, or the service for verifying a signature described in the unpublished German patent application with file number 10 2024 001 630.9, where the signed data and the signature are part of the request payload and the public key used by the responder for signature verification is stored in the responder, whereby this function can only be considered stateless as long as this key is fixed and is not changed.
[0035] However, if the method used by the responder to generate the corresponding response payload for a received request payload depends on the point in time at which the responder determines the response payload for the request payload (e.g., depending on the responder's changing state), then it is possible for an attacker to generate and send a response payload for the same request payload from the responder at a different time than desired by the requester (e.g., an earlier time). This is possible due to the unauthenticated request payload. The attacker could then send this response payload to the requester as the responder's supposedly newly generated response payload after the requester has sent a request with the identical request payload.Since the response payload was correctly signed by the responder (even if at an earlier time), the requester cannot detect that the response payload was generated at an earlier time and therefore might contain an outdated value. Therefore, further measures are necessary to prevent the described attack. The described attack can be considered a variant of the replay attack, although strictly speaking, no replay takes place here, since the attacker does not intercept and cache a response payload requested by the requester, but rather actively has the responder generate the request payload at a time determined by the attacker.
[0036] Examples of such time-dependent procedures for determining the response payload for a request payload include determining the number of people in the vehicle, determining the currently playing radio station, determining the list of stored contacts, or determining the current time of the responder.
[0037] The approach described above as the obvious solution aims to ensure a secure relationship between the received response payload and the previously transmitted request payload by associating each request transmitted by a requester with its identity and a unique identifier, e.g.The method of signature-based authentication, where a request is identified by a sequential number or a timestamp containing the current date and sufficiently accurate time, and the identity of the requester along with this unique identifier of the request is included in the corresponding (signed) response generated by the responder, does not work in the case of an unsigned request. This is because, due to the lack of a signature, every sender of a request can freely choose the identity contained in the request, and an attacker can predict the unique identifiers of future requests sent by the requester with a certain probability. This probability is high when using ascending numbers as identifiers and lower, but still significant, when using a timestamp as identifiers.Due to the predictability of the unique identifiers, an attacker can, at an early stage, generate and sign a sufficient number of matching responses to the expected requests from the responder. If the requester then sends a request for which the attacker has already generated and signed a response from the responder at an earlier time, the attacker can send the requester this previously generated response instead of the current response expected by the requester.
[0038] To overcome this weakness, security mechanisms other than those proposed in the obvious solution are needed. Two such mechanisms are proposed below as alternative or complementary developments of the method according to the invention. In the first variant, a unique identifier for the request can be omitted; instead, or additionally, the responder adds a current timestamp, representing the responder's current time, to the generated response before transmission. According to a preferred embodiment of the idea, this timestamp can include the current date and time. The responder then signs the timestamp along with the other data to be signed, in particular the response payload. After receiving the response, the requester checks both the signature and the timestamp. If the timestamp is current, the requester can verify that the response is valid.If the timestamp is recent enough, the data contained in the response, especially the response payload, will be used by the requester. If the timestamp is too old, exception handling, as described above, will be initiated.
[0039] This method only works, however, if both the responder and the requester have sufficiently synchronized clocks. Many control units, however, do not have clocks that know the current time and date. In this case, an alternative security mechanism is required, which, in principle, can also be used in addition to the timestamp.
[0040] One problem with using sequential numbers or timestamps as unique identifiers for requests is their predictability. This allows an attacker to pre-generate responses to the requester's expected requests from the responder. If the identifier were unique and unpredictable for the attacker, they would be unable to estimate the identifiers of future requests and thus could not generate meaningful responses from the responder in advance.
[0041] The second method involves the requester adding a unique, unpredictable identifier to the request message and temporarily storing it. The responder then signs this identifier. This identifier can be transmitted as part of the response message, in which case the requester verifies its validity based on the identifier it already knows and has stored. Alternatively, the identifier can be omitted from the response message. In this case, the requester uses the stored identifier to construct a presumably signed data and then verifies the validity of the received signature. In both methods, exception handling, as described above, is initiated if the verification fails.
[0042] A decisive advantage is that, according to a highly advantageous further development of the inventive method, the identifier is regenerated for each query. This virtually eliminates predictability by an attacker.
[0043] In a favorable implementation of the method, a random number can be used as the identifier. Preferably with a length of at least 64 bits, ideally more.
[0044] Preferred non-predictable identifiers are therefore sufficiently long random numbers, for example, 128 bits long, which can be generated using true random number generators or pseudo-random number generators. Note that if a sufficiently large random number is used as a unique identifier, collisions can be virtually eliminated even when requests are submitted by different requesters, thus making it unnecessary to include the requester's identity in the request.
[0045] The advantage of this approach over using sequential numbers or timestamps as request identifiers is that an attacker can no longer predict which identifier the requester will use in the future and therefore cannot have the responder generate matching responses "in advance." However, an attacker still has various options for delaying the processing of a request and / or the transmission of the response. For example, an attacker can block the transmission of the request generated by the requester to the responder for a certain period of time, thus causing the responder to send a signed response to the requester at a later time than the requester expected.
[0046] To enable the requester to reliably assess the timing of the received response payload, a stopwatch or timer can be started when the request is transmitted to the responder. This timer stops as soon as the requester receives the response. The recorded time is then compared to a predefined threshold representing the typical time it takes for a response message to arrive. If the measured or determined time exceeds the threshold, exception handling, as described above, is initiated.
[0047] This estimation can be reliably performed if an identifier unpredictable by the attacker, such as the described random number, is used. Therefore, execution with a stopwatch is ideally combined with the use of this unique, unpredictable identifier. This prevents an attacker from generating meaningful responses in advance. It is proposed to use an unpredictable value as the unique identifier, equip the requester with a timer, start this timer at the beginning of the request transmission to the responder, and stop it immediately after the requester receives the response. The timer value is then interpreted as the upper limit for the age of the response.
[0048] Further advantageous embodiments of the method according to the invention can also be seen from the exemplary embodiments which are described in more detail below with reference to the figures.
[0049] This shows:
[0050] Fig. 1 shows a possible implementation of the method according to the invention;
[0051] Fig. 2 shows a possible implementation of a variant of the invention.
[0052] Method using two synchronized clocks and a timestamp in the response; and
[0053] Fig. 3 shows a possible implementation of a variant of the inventive method using a random number as a unique identifier and a stopwatch.
[0054] Figure 1 shows an exemplary implementation of the method according to the invention. In the preparation phase (provisioning), which is not shown in Figure 1, the responder (RESP) is equipped with an asymmetric key pair ((RESPPub, RESPPriv)) and a corresponding signing method (Sign). The responder's (RESP) public key (RESPPub) is stored in the requester (REQ). Furthermore, the requester (REQ) is equipped with a signature verification method (Ver) that can be used to verify signatures (S) generated using the signing method (Sign). No secret, in particular no separate asymmetric key pair, is stored in the requester (REQ).
[0055] The method variants described here in detail using the exemplary implementations are—as already mentioned at the outset—about the fact that the requester only wants to receive specific non-confidential information from the responder, and that the generation of this information by the responder does not pose any security risks for the responder, so that, in particular, its state is not altered. However, the requester wants to be sure that the response payload contained in the received response actually originates from the responder, and that this response payload is the result of processing its previously submitted request, i.e., its request payload. The goal in this case is therefore to ensure the authenticity of the responder's response payload and the relationship of this response payload to the previously transmitted request payload, whereby the authenticity and confidentiality of the request itself are irrelevant.
[0056] In this process, the request payload (ReqPL) of the requester (REQ) is not authenticated upon transmission to the responder (RESP), meaning it does not need to be signed. This eliminates the need for resource-intensive signing capabilities by the requester (REQ), such as a control unit in a vehicle. After receiving the request (Req) containing the request payload (ReqPL), the responder (RESP) generates the response payload (RespPL) for the request payload (ReqPL). The responder (RESP) then calculates the signature (S) of the combination of the response payload (RespPL), the underlying request payload (ReqPL) used to generate the response payload (RespPL), and any other relevant data, using the signing algorithm (Sign) and the private key (RESPPriv). The response (Resp), containing the response payload (RespPL) and the digital signature (S), but not the request payload (ReqPL), is then transmitted to the requester (REQ).To verify the integrity of the received data, especially the generated response payload (RespPL), the requester (REQ) uses the locally stored (in this example, complete) request (Req), as indicated by the dashed line. The following steps are performed in detail:
[0057] 1. The requester (REQ), equipped with at least the public key (RESPPub) of the responder (RESP) and an implementation of a signature verification procedure (Ver) for signatures generated by the responder (RESP) using the signing procedure (Sign) implemented therein, a. generates the request (Req) containing at least the request payload (ReqPL), b. stores the generated request (Req) (in this example completely) locally (indicated by the Store function), c. transmits the request (Req) to the responder (RESP).
[0058] 2. The responder (RESP), equipped with at least an implementation of a signing procedure (Sign) and a corresponding asymmetric key pair (RESPPub, RESPPriv), a. generates the response payload (RespPL) for the received request payload (ReqPL) (indicated by the function RespGen), whereby the response payload (RespPL) can depend on data other than the request payload (ReqPL), as indicated by the three dots, b. creates the signature (S) of the generated response payload (RespPL) and the received request payload (ReqPL) using the implemented signing procedure (Sign) and its own private key RESPPriv, whereby further data can also be signed, as indicated by the three dots, c.transmits the response (Resp), which contains at least the generated response payload (RespPL) and the signature (S), to the requester (REQ), whereby the request payload (ReqPL) underlying the generation of the response payload (RespPL) is not part of the response (Resp), but all data that is part of the additional data signed in the previous step and is not part of the received request (Req) is part of the response (Resp).
[0059] 3. After receiving the response (Resp), which contains at least the generated response payload (RespPL) and the signature (S), the requester (REQ) performs the following steps: a. determines the data (SData) presumably signed by the responder (RESP) from the received response (Resp) and the locally stored request (Req) (indicated by the function DetSData ("determine SData")), whereby the presumably signed data (SData) may include, in addition to the response payload (RespPL) and the request payload (RespPL), further data from the response (Resp) or request (Req), b. checks whether the data identified by the responder (RESP) that is presumably signed (SData) corresponds to the data actually signed by the responder (RESP) by verifying the correctness of the received signature (S) for the presumably signed data (SData) using the signature verification procedure (Ver) and the stored public key (RESPPub) of the responder (RESP).If the check fails, exception handling is initiated (not shown in Figure 1). c. uses the transmitted response payload (RespPL).
[0060] Figure 2 shows a variant of the procedure in which the requester (REQ) and the responder (RESP) are each additionally equipped with a clock (ClockREQ, ClockRESP), and the requester (REQ) also defines a threshold value that specifies the upper limit for the recency or freshness of the responses (Resp) accepted by the requester (REQ). When creating the signature (S), the responder (RESP) adds a timestamp (TStamp) containing the current date and time of the responder (RESP), generated using the local clock (ClockRESP), to the data to be signed and subsequently to the response (Resp) to be sent.After receiving the response (Resp), generating the data (SData) presumably signed by the responder (RESP), and verifying the signature (S), the requester (REQ) checks the freshness of the received response (Resp) (indicated by the CheckFreshness function) by comparing the received timestamp (TStamp) with a timestamp generated using the local clock (ClockREQ) containing the current date and time of the requester (REQ). If the discrepancy exceeds the predefined threshold (Threshold), exception handling is initiated (not shown in the figure); otherwise, the received response payload (RespPL) is used by the requester (REQ).
[0061] Figure 3 shows a variant of the procedure in which, starting from the basic variant according to Figure 1, the Requester (REQ) is additionally equipped with a random number generator (RNG) and a stopwatch or timer (Ti). The Requester (REQ) also defines a threshold value, which denotes the upper limit for the freshness of the responses (Resp) accepted by the Requester (REQ). Before forming the Request (Req), the Requester (REQ) uses the random number generator (RNG) to generate a new random number (rn), which is included in the Request (Req) as a unique identifier. Immediately before transmitting the Request (Req) to the Responder (RESP), the Requester (REQ) starts the timer (Ti) (indicated by the Start function).After receiving the request (Req) and generating the response payload (RespPL) for the received request payload (ReqPL), the responder (RESP) adds the random number (rn) received as part of the request (Req) to the data to be signed when creating the signature (S). Therefore, the data to be signed contains, in addition to the response payload (RespPL) and the request payload (ReqPL), at least the received random number (rn). The response (Resp), which contains at least the response payload (RespPL) and the signature (S), is then transmitted to the requester (REQ). The response (Resp) does not necessarily have to contain the random number (rn) required for signature verification (S), as this is part of the request (Req) stored locally at the requester (REQ).Immediately after receiving the response (Resp), the requester (REQ) stops the timer (Ti) (indicated by the Stop function). Subsequently, after generating the data (SData) presumably signed by the responder (RESP) and verifying the signature (S), the requester (REQ) checks the freshness of the received response (Resp) (indicated by the CheckFreshness function) by comparing the value of the previously stopped timer (Ti) with the predefined threshold (Threshold). If this threshold (Threshold) is exceeded, exception handling is initiated (not shown in the figure); otherwise, the received response payload (RespPL) is used by the requester (REQ).
Claims
Mercedes-Benz Group AG Patent claims 1. A method for the integrity-protected use of services of a requested / responding instance (RESP), to which a requesting instance (REQ) transmits a request message (Req) and receives a response message (Resp) from the requested / responding instance (RESP), characterized in that the requesting instance (REQ) transmits at least the content core of the request (ReqPL) unsigned in the request message (Req) to the requested / responding instance (RESP) and temporarily stores at least the content core of the request (ReqPL) locally, after which the requested / responding instance (RESP) generates a content core of the response (RespPL) from the content core of the request (ReqPL) upon receiving the request message (Req).whereupon the requested / responding instance (RESP) signs a combination of at least the generated content core of the response (RespPL) and the received content core of the request (ReqPL) with its private key (RESPPriv), whereupon the requested / responding instance (RESP) transmits at least the generated content core of the response (RespPL) and the generated signature (S) to the requesting instance (REQ) as parts of the response message (Resp), whereupon the requesting instance (REQ) reconstructs the data (SData) presumably signed by the requested / responding instance (RESP) from the transmitted response message (Resp) containing at least the content core of the response (RespPL) and the parts of the request message (Req) containing at least the content core of the request (ReqPL) that are temporarily stored in the requesting instance (REQ).and whereupon the requesting instance (REQ) uses a public key (RESPPub) stored in the requesting instance (REQ) of the requested / responding instance (RESP) to verify the signature (S) contained in the received response message (Resp), whereby in the case of a negative, An exception will be sought.
2. Method according to claim 1, characterized in that the combination includes further data which are co-signed and which are taken into account when temporarily storing parts of the request and / or when forming the response and when reconstructing.
3. Method according to claim 1 or 2, characterized in that the combination is carried out as concatenation.
4. Method according to one of claims 1 to 3, characterized in that, in addition to the content core of the response (RespPL), a current timestamp (TStamp) is generated by the requested / responding instance (RESP), which is co-signed by the requested / responding instance (RESP) and transmitted as part of the response message (Resp), after which the requesting instance (REQ) checks the timestamp (TStamp) for its validity upon receipt, and in the event of a negative check, exception handling is initiated.
5. Method according to claim 4, characterized in that the timestamp (TStamp) includes date and time.
6. Method according to claim 4 or 5, characterized in that clocks (ClockRESP; Clock REQ) of the requested / responding instance (RESP) and the requesting instance (REQ) are used for generating and verifying the timestamp (TStamp).
7. Method according to any one of claims 1 to 6, characterized in that the requesting instance (REQ) extends the request message (Req) by a unique identifier. The unpredictable identifier (rn) is extended and temporarily stored, whereby the requested / responding instance (RESP) co-signs this identifier (rn) and transmits it as part of the response message (Resp), after which the requesting instance (REQ) checks the identifier (rn) for correctness upon receipt, in the case of a negative check, exception handling is initiated.
8. Method according to any one of claims 1 to 6, characterized in that the requesting instance (REQ) extends the request message (Req) by a unique, unpredictable identifier (rn) and temporarily stores this identifier, wherein the requested / responding instance (RESP) co-signs this identifier (rn), after which, upon receiving the response message (Resp), the requesting instance (REQ) uses the temporarily stored identifier (rn) to form the data (SData) presumably signed by the requested / responding instance (RESP) and subsequently checks the correctness of the received signature (S), wherein, in the event of a negative check, exception handling is initiated.
9. Method according to claim 7 or 8, characterized in that the identifier (rn) is regenerated for each request.
10. Method according to claim 7, 8 or 9, characterized in that the identifier (rn) comprises a random number.
11. Method according to claim 10, characterized in that the random number (rn) has a length of at least 64 bits.
12. Method according to any one of claims 1 to 11, characterized in that the requesting instance (REQ) has a stopwatch (Ti) which is started when the transmission of the request message (Req) to the requested / responding instance (RESP) begins, and which is stopped immediately after receiving the response message (Resp) from the requested / responding instance (RESP), wherein In the event that such a determined time period exceeds a threshold, an exception procedure will be initiated.
13. Method according to one of claims 1 to 12, characterized in that the requesting instance (REQ) is designed as a control unit in a vehicle and the requested / responding instance (RESP) is designed as a vehicle-external server.