Method for replaying a protected message and replay unit

Abstract

Method and replay unit for sending a protected message to a recipient device to be tested via a message system, wherein the replay unit is connected via the message system with the device to be tested, the replay unit is configured to receive a protected first message to be replayed, to remove a first counter value from the protected first message and to generate a second authentication code by means of a second counter value, an encryption algorithm and a key, and the replay unit is configured to generate a protected second message by adding the second counter value and the second authentication code to the first message, and the replay unit is further configured to send the protected second message to the recipient device to be tested via the message system.

Description

Technical Field

[0001] The present invention relates to a method and a replay unit for sending recorded protected messages to a receiving device to be tested, particularly a control unit to be tested, via a messaging system. Background Technology

[0002] In the field of bus simulation for testing control units, such as in the automotive industry, the focus is on simulating the bus communication of one or more control units as realistically as possible. The manipulation of bus communication is also important in the field of control unit (ECU) protection.

[0003] Here, bus communication can be simulated either through "real-time" simulation in a test environment (e.g., using dSPACE Ltd.'s MicroAutobox, VEOS, or SCALEXIO products for offline simulation or hardware-in-the-loop (HIL) simulation) or through bus communication recorded via replay.

[0004] In the simplest case, for the communication specifications used in vehicles, the transmitted signals are sent as the only payload data in bus messages or network messages.

[0005] However, the new standards (AUTOSAR ≥ 4.2.1 and FIBEX ≥ 4.1.2) extend this to provide additional authentication or protection for payload data (see, for example, secure vehicle communications, encrypted PDUs, transport layer security, IPsec (Internet Protocol Security)).

[0006] Data generated in the control unit or within the scope of bus simulation is often recorded for testing purposes so that it can be replayed later. Currently, the recorded bus communications can be replayed without modification to simulate correct bus communications for one or more receiving control units.

[0007] For example, bus communication can be logged using tools from dSPACE Ltd. (Bus Navigator or Autera). These tools are also typically capable of replaying the logged and saved bus communications.

[0008] The new encryption and authentication algorithms in the standards mentioned above are designed to prevent so-called replay attacks. Therefore, bus communication protected by these algorithms cannot be easily used to stimulate control units by means of simple replay.

[0009] Typically, protected messages recorded in a vehicle or simulated using a simulator for testing purposes contain information consisting of a header, payload data, a monotonically increasing counter value, and an encrypted authentication code.

[0010] The problem with replay is that while the payload data may be correct, the counter value of the recorded data may not match the counter value of the control unit being tested (because the counter is monotonically increasing, it cannot be changed). Even if the counter value can be reset, the authentication code value (also known as the authentication key) created for authentication will no longer match the counter value, because the encrypted authentication key value consists of a value determined based on the payload data and the counter value.

[0011] If this problem has occurred in the early stages of development, authentication is typically disabled in the receiving control unit. However, in this case, the authentication can no longer be tested.

[0012] A solution to this problem is described in PCT application with official application number PCT / EP2020 / 053254. According to the application, the authentication code and counter value are removed from the protected message and replaced with newly determined values.

[0013] The difficulty lies in the fact that messages are sent in serialized form on a bus or network. In serialized form, a message consists only of data, without information about the type of data or the location of data within the message. Therefore, without deserialization, it is unclear which data needs to be replaced. Converting the complete message from serialized form into a deserialized and decoded message that fully identifies the data to be replaced is time-consuming and computationally expensive. Summary of the Invention

[0014] In this context, the objective of this invention is to provide a method and replay unit that improve upon the prior art.

[0015] This task is solved using the method and replay unit mentioned at the beginning, wherein the method has the following steps:

[0016] • Provide a protected and still serialized first message from a protected first message packet for processing in the replay unit, wherein the first message is given by the payload of the message packet and itself has payload data, a first counter value, and a first authentication code, wherein the following information is stored in or provided to the replay unit (i.e., the information is stored in a memory configured for the replay unit, or the replay unit can access information stored in the test environment):

[0017] o At least a portion of the communication description used for the receiving device to be tested and / or the algorithm used for data interpretation,

[0018] o The second counter value used for the receiving device to be tested,

[0019] o The information used for encryption and the corresponding key,

[0020] • With the help of the playback unit (R):

[0021] o In the first message: by identifying the location of the payload data or the location of the first authentication code in the first message and removing at least the first authentication code and, if necessary, the first counter value from the first message, the amount of data given by the serialized message is reduced.

[0022] The reduced first message is deserialized and a protected second message is created by adding a second counter value or, if necessary, replacing the first counter value with the second counter value; and a second authentication code is created and added, using the second counter value, the information for encryption, and the key, and when using a communication description or information obtained by applying an algorithm for data interpretation.

[0023] • Serialize the protected second message and send the corresponding message packets to the receiving device to be tested.

[0024] The core of the method according to the invention is that, using the replay unit according to the invention, the recorded protected message is manipulated before replay in such a way that the receiving device assumes the recorded protected message is a correct message. This is achieved by reducing the data of the still serialized first message, so that the first message to be replayed does not need to be completely deserialized and decoded for manipulation purposes. Generally, messages are serialized and then sent via the messaging system in the form of "message packets." Generally, "serialization" refers to encoding data and organizing it into message packets to be sent on the messaging system, the message packets having a header, payload, and trailer; or "deserialization" refers to the reverse process.

[0025] In this application, serialization or deserialization typically involves only a portion of the process, namely the serialization or deserialization of messages located within the payload of message packets sent via a messaging system. In the "serialization" considered here, information about the classification of data is removed from the message, or information about the classification of data is added during "deserialization."

[0026] For example, data about physical values ​​in a message in deserialized and interpreted form might look like this:

[0027] Temperature 24°C

[0028] Speed ​​123 km / h

[0029] Height 320 ü.nN

[0030] Authentication code 345678 → Correct.

[0031] For example, the encoded form of deserialized data is:

[0032] Temperature 10

[0033] Speed ​​B24

[0034] Height 8AF

[0035] Authentication code 835D.

[0036] After serialization, the message content (payload) will be given by the following: 10B248AF835D.

[0037] The replay tool (replay unit) according to the invention identifies and separates the individual components of a message even before deserialization, and thus reduces the amount of data to be deserialized and decoded.

[0038] Preferably, based on information included in the communication description and information specified by the user for encryption, a new incrementing counter value and a new and appropriate authentication code (authentication code) corresponding to the payload data, counter value, and encryption algorithm are generated for replaying. The information for encryption depends on where the invention is employed or what protection mechanism exists (e.g., SecOC or IPSec). The information for encryption includes, for example, the encryption algorithm and possibly other information related to the encryption algorithm, such as where the algorithm is applied (bits or bytes). Using this information, a new complete message is generated, or the original (outdated due to the old counter value / authentication code) first message is reprocessed into a second message, which is received by the receiving device (i.e., the (control) unit to be tested).

[0039] The current counter value used for the control unit to be tested (e.g., in the form of a so-called freshness value or serial number) is usually global and therefore known to the test environment (i.e., the HIL simulator or an offline simulator or a host connected to the simulator).

[0040] In order to enable the manipulation of the protected first message for the creation of the protected second message in general, the communication description (e.g., at least part of the communication matrix, also known as the K-matrix) or the algorithm for interpreting the data obtained in the message is stored in the replay unit, so that the counter value and authentication code can be identified in the message.

[0041] In a first exemplary embodiment, payload data identification is performed using a lookup table extracted from the communication description, wherein the lookup table contains at least the message ID, the location of the payload data, and the length of the payload data. If necessary, the lookup table also contains information about the position of a counter within the protected and still serialized first message. Other information about the K-matrix, such as sender, receiver, initial value, data type, trigger, CompuMethod, etc., is ignored.

[0042] Preferably, a lookup table is automatically created from the communication description before implementing the method steps according to the invention listed above, and stored in the replay unit or in a test environment accessed by the replay unit. The entries in the lookup table are particularly preferably sorted according to the frequency of message occurrence, so that frequently occurring messages are listed in particularly quick-access positions in the table. The frequency of messages can be derived, for example, from information in a communication matrix, or can be dynamically adjusted during the method based on statistics of message arrivals. Such statistics are particularly meaningful for service-based communication. Another possibility for creating the lookup table using the communication description is to first generate executable communication code for simulation using the communication description, and then deserialize the first message type for each message ID, either only the first message or, in the case of multiplexed messages, the first message type, to determine the position of the MAC in the deserialized first message or this first deserialized message type, and at least store this information in the lookup table created in this manner.

[0043] In a second exemplary embodiment, the first authentication code is identified by searching the serialized data of the message packet using an algorithm for data interpretation. Here, the algorithm for data interpretation is provided by a suitable algorithm for identifying encrypted information, wherein such identification is performed, for example, by searching for a continuous value with maximum entropy.

[0044] The identification of encrypted information is based on the premise that all current encryption methods generate the largest possible entropy value (i.e., the largest possible "disorder") of the encrypted information. This is to prevent decryption through a statistical test (n-Gramme). Therefore, to identify encrypted information, it is only necessary to use a symbol window (preferably a symbol window of a predetermined size corresponding to the length of the authentication code) to search only the payload data of the still serialized first message for a continuous value with the maximum entropy.

[0045] If the locations of the authentication code and payload data are static, that is, fixed and predetermined for each message, then it is not necessary to continuously perform a search for the authentication code for each message, but only once for each message identity.

[0046] In this embodiment, a lookup table may also be preferably provided from which the location of the payload data can be determined without prior costly searching or deserialization.

[0047] If the algorithm used for data interpretation, i.e., the algorithm used to identify authentication codes, is implemented in the hardware of the messaging system, for example, directly in or after the controller, which receives message packets sent via the messaging system and has already partially decomposed them, further time savings are achieved. This controller can be a commercial controller (e.g., Infineon Aurix) or can be implemented in an FPGA, for example, in a so-called soft core, where the algorithm for data interpretation can then be implemented in the remaining area of ​​the FPGA. However, the algorithm for data interpretation can also be integrated into an additional FPGA or ASIC so that it can be applied to messages extracted from message packets by the controller. Similarly, the controller is not necessarily considered here as part of the replay unit, but rather as part of the test environment and can be manipulated by the replay unit.

[0048] The advantage of additionally utilizing algorithms for data interpretation is that implementing the algorithms in hardware makes additional time savings possible.

[0049] In another embodiment of the invention, the second counter value is given by the current counter value of the control unit to be tested. In an alternative embodiment, the second counter value may be predetermined by the user or calculated according to a predetermined algorithm for counter calculation.

[0050] The replay unit preferably contains all the components and / or modules necessary to generate these values ​​and their subsequent combination. Specifically, it includes log file import, K-matrix import, deserialization / serialization, counter value generation, and encryption algorithms. Alternatively, however, the components and / or modules may be provided only with the necessary information for the replay unit's use, and implemented elsewhere, for example, in a test environment, rather than within the replay unit.

[0051] The components and modules mentioned above are known individually as part of different bus simulation software (e.g., RTI CAN MM, FlexRay configuration package, Ethernet configuration package, or bus manager) or bus experimental software (bus navigator). Unlike existing technologies, where payload data is generated from offline or real-time models in typical use cases, the method according to the invention extracts this payload data from log files, splits it using the identification features according to the invention, and reassembles it with new content.

[0052] In one embodiment of the invention, the payload data, first counter value, and first authentication code of a message are distributed across at least two message packets for transmission (e.g., the payload of the first message packet contains the authentication code, while the payload of the second message packet contains the message's counter value and payload data). In another embodiment of the invention, a message packet (as the payload of the message packet) contains the entire message having payload data, a counter value, and an authentication code.

[0053] The security mechanism used determines whether a message containing payload data, a counter value, and an authentication code is sent in a single message packet or distributed across two or more message packets. For example, in SecOC, this is often the former, while in IPsec, it is sometimes the latter. The important point here is that a message protected by a specific first authentication code is configured for replay purposes with a current second authentication code and a corresponding second counter value, which replaces the outdated first authentication code and the outdated first counter value.

[0054] The receiving device is provided by the actual control unit (e.g., in HIL testing), or by the virtual control unit if bus communication should be tested within a virtual protection zone.

[0055] Virtual protection here refers to testing control units without specific hardware by using an offline simulator to simulate a control unit network (and its environment, such as vehicles and traffic conditions). The offline simulator also mimics the temporal behavior and communication of the control unit network. The virtual control unit is essentially a preliminary stage of the software implementation of the control unit and usually already contains the final sequence code. However, the virtual control unit does not yet require the actual hardware of the control unit, although future operating systems are often simulated, and the actual planned behavior is mimicked based on timing and triggering information defined for functionality. Thus, the virtual control unit can, for example, connect to the simulated bus.

[0056] Depending on the requirements, the messaging system is provided by a bus communication system or network, or a combination of bus systems and networks, particularly through an automotive messaging system, where the messaging system either exists in reality or is simulated within a virtual protection environment. Combinations of virtual control units with real-world messaging systems or real-world control units with simulated messaging systems are also possible through appropriate testing environments.

[0057] In another embodiment of the invention, the payload data of the protected first message is also encrypted using the first counter value, and is first decrypted in the playback unit, and then encrypted again using the encryption and second counter values. Which parts of the message are decrypted and encrypted is preferably also included in the information used for encryption.

[0058] In one embodiment of the method according to the invention, the method is applied to so-called services (Dienste) which are transmitted in protected messages, and thus also enables so-called service discovery, such as replay of network services and / or system services.

[0059] Preferably, it is possible to intentionally introduce errors during manipulation, i.e., when creating the protected second message. For example, the information used for encryption may include additional information to create a protected second message for testing purposes, such that the protected second message should be recognized as erroneous by the receiving device. This also allows for testing of security mechanisms.

[0060] This task is also solved by a playback unit according to the invention for implementing the method according to the invention.

[0061] The replay unit according to the present invention extends the functionality of prior art replay units in the following ways: the transmitted message no longer consists solely of stored messages, but is almost entirely composed of newly generated or reprocessed messages; the transmitted message partially contains old information (particularly payload data), but is altered with new information (authentication code and / or counter value), thereby allowing the old information to be accepted or selectively discarded by the receiving device; wherein relevant parts of the message have been identified before deserialization; and the alteration requires minimal time cost and computational power for deserialization and decoding.

[0062] Preferably, the replay unit is designed as an (additional) unit for a HIL simulator (in the form of hardware with corresponding software) and / or for a simulator for virtual protection (as a pure software unit or an additional program).

[0063] This invention enables the efficient recording of protected communications within a vehicle and their use for subsequent protection, such as in HIL, but also in virtual protection. Attached Figure Description

[0064] The invention will now be explained in more detail with reference to the accompanying drawings.

[0065] To illustrate, see the diagram:

[0066] Figure 1 A protected message is displayed.

[0067] Figure 2 This diagram illustrates secure vehicle communication according to AUTOSAR 4.2.1.

[0068] Figure 3 This diagram illustrates a common control unit communication method when using protected communication.

[0069] Figure 4 This illustrates the storage of transmitted data using a data logger.

[0070] Figure 5a The method according to the invention is shown in the case of using the extracted lookup table.

[0071] Figure 5b The method according to the invention is illustrated when using an algorithm for data interpretation.

[0072] Figure 6 The process of the algorithm used for data interpretation is shown. Detailed Implementation

[0073] The following description of the present invention pertains to Secure In-Vehicle Communication (SecOC), but may also be applied to other methods.

[0074] In the context of authentication within SecOC, the transmission over the medium changes compared to unprotected message transmission because, in addition to payload data, other data is now transmitted in the message. This additional data allows the receiver to verify the validity of the received data. The original PDU (Protocol Data Unit) containing only payload data is now known as a "protected PDU."

[0075] Figure 1 This illustrates the structure of such a protected message. In protected communication according to the SecOC standard of AUTOSAR and FIBEX, a "protected PDU" is transmitted. This "protected PDU" consists of a payload data PDU that is still unencrypted (but mostly encoded), a counter value Z, and an encrypted authentication code MAC. The payload data PDU is unencrypted, but without knowledge of the communication description, such as in the form of a so-called K matrix or communication matrix, and because the data in the message is still serialized, information about where and what data (counter value Z (also called "Freshness Value" in SecOC), authentication code MAC, and payload data PDU) can be found is lacking. Interpreting the data without this information is costly.

[0076] In addition to the unencrypted payload data (now called PDU or "real PDU"), the protected message also contains a counter value Z (also called the "freshness value") and an authentication code ("Message Authentication Code" MAC). This MAC is an encrypted value calculated using a key algorithm, a key K, the payload data PDU, and the counter value Z. This process... Figure 2 As shown in the diagram, the counter value Z is a continuous, monotonically increasing counter value. At the sender, the counter value Z and the information / data in the payload data PDU are used to generate the authentication code MAC. Thus, the sender creates a message with the payload data PDU, the counter value Z, and the authentication code MAC. At the receiver, the authentication code MAC and the counter value Z are checked, and based on this check, it is determined whether the message is valid or whether the use of the payload data is permitted.

[0077] Figure 3 This illustrates normal control unit communication when using secure communication.

[0078] In the send-control unit (sender), the application software generates the user data PDU (f(x)) to be transmitted. Additionally, there is a module ZG for generating the counter value and a generator for the authentication code MAC. In a lower software layer, serialization occurs, and here, COM configuration (communication description, e.g., in the form of a K matrix) determines which data in the message to be transmitted, or which data in the corresponding message packet NP to be transmitted, represents the counter value Z, and which data represents the authenticator MAC. This message is then "packed" accordingly and transmitted as message packet NP by the appropriate controller on the bus / network. On the bus / network, without knowledge of the K matrix or without a suitable algorithm for data interpretation, it is impossible to distinguish the data contained in the serialized message packet NP between the user data PDU, the counter value Z, and the authenticator MAC.

[0079] When testing control units, such as when using HIL for real-time testing or using an offline simulator for virtual protection, there is usually information about the K-matrix or the K-matrix is ​​present.

[0080] exist Figure 3 In this process, the receiving control unit (receiver) receives the message and evaluates it in the reverse order of the sender. Based on the authentication code check, the receiving control unit determines whether the received payload data PDU is used for the application, i.e., whether the corresponding function f(x) in the receiver-control unit is used for the application.

[0081] If the communication between control units is intended for subsequent playback, the communication is intercepted on the bus or mirrored in the network via a switch or test access point. This is in Figure 4As shown in the diagram. For recording, a data logger D is typically used, which collects data on a large-capacity memory. Storage is performed without interpreting the data.

[0082] In the case of unprotected communication, the data used to stimulate the receiving control unit can be sent directly to the receiving control unit with more or less unchanged (possibly with timestamps), and the receiving control unit cannot detect the stimulus (Replay, i.e., a pure replay / re-enhancing of the recorded message).

[0083] However, in the case of protected communication, since the message will be detected as outdated by a monotonic counter in the receive control unit, the recorded data can no longer be used without further manipulation. However, simply changing the counter will not guarantee success, as the counter value is included in the calculation of the authentication code (MAC) along with the payload data.

[0084] Figure 5a An exemplary embodiment of the method according to the invention is shown, utilizing the playback unit R according to the invention.

[0085] The recorded data (protected message) is read from the large-capacity memory D. This data is serialized data (Serial.Data), i.e., completely uninterpreted data, in which it is unclear where the signals are located and how they are encoded. At the beginning of the method according to the invention, a significantly smaller lookup table LT is generated from the (very large) communication matrix Com-Marix present in or read in the playback device R. This lookup table contains the message ID, the location of the payload data, and the length of the payload data. Based on the information extracted from the lookup table LT, all data except the payload data PDU of the message, i.e., in particular the signals of the first counter value Z1 and the first authentication code MAC1, is discarded. The remaining still serialized data (Serial.Data) must be deserialized to obtain the payload data PDU so that it can be reused in the message to be sent, since the payload data PDU is included in the calculation of the authentication code. However, here the amount of data to be deserialized is reduced to the payload data PDU compared to the data of the complete message. The signals for the second counter value Z2 and the second authentication code MAC2 are also regenerated in the playback device R, as in the control unit or in the bus simulation in the HIL simulator or offline simulator. Here, the second counter value Z2 and the key K are provided by the user, for example. The valid message is reassembled from the payload data PDU, which is then transmitted as message packets NP after complete serialization via a bus or network.

[0086] Figure 5b Another embodiment of the invention is shown below. Figure 5aThe differences between the methods described in the text are as follows:

[0087] To identify the position of specific message components within the still-serialized message, Algorithm A for data interpretation is applied. This algorithm A determines the position of encrypted data within the message by identifying consecutive values ​​with maximum entropy. Therefore, the encrypted authentication code (MAC) can be identified and discarded, further reducing the amount of data in the message. In a further step, the remaining data of the message is deserialized, and counter Z1 is identified and removed. The method then proceeds as follows... Figure 5a Continue as before.

[0088] Figure 6 The process of Algorithm A used for data interpretation is described. To identify encrypted information, a symbol window is used to search for a continuous value with maximum entropy within the serialized message data. It is not necessary to predetermine the size of the symbol window used to search for the first authentication code. In principle, the search can be performed using symbol windows of different sizes. However, in practice, it is preferred to use only a specific authentication code length (e.g., AES = 128 bits) as the length of the symbol window. Figure 6 The entropy is calculated for each window listed in the table. The window with the largest calculated entropy is assumed to be where the authentication code MAC1 is located.

[0089] If there happen to be two windows with the same entropy size, a decision can be made by reapplying the algorithm to other messages with the same ID.

[0090] Another embodiment of the invention involves selectively manipulating the signals for the counter value Z and the authentication code MAC to test the protection measures in the receiver control unit. This allows the system to operate with the correct counter value Z but with an incorrect authentication code MAC, or vice versa.

[0091] In security mechanisms other than SecOC, messages containing payload data, counter values, and authentication codes may not be sent in a single message packet, but rather distributed across multiple message packets, such as in IPsec or encrypted PDUs. The method according to the invention can also be applied to such methods. Therefore, slight modifications to the counter value may be necessary. In IPsec, the counter value (referred to there as the sequence number) does not necessarily need to be monotonically increasing, but must instead lie within a specific window (“sliding window”) of the sequence number.

Claims

1. A method for sending a recorded protected message to a receiving device to be tested via a messaging system, wherein, The message is sent using serialized message blocks, and the method includes the following steps: A protected and still serialized first message in a message packet (NP) is provided for processing in the replay unit (R), wherein the first message is given by the payload of the message packet (NP) and itself has payload data (PDU), a first counter value (Z1), and a first authentication code (MAC1), wherein the following information is provided to the replay unit (R): At least a portion of the communication description (Com-Matrix) for the receiving device to be tested and / or an algorithm (A) for data interpretation. The second counter value (Z2) is used for the receiving device to be tested. The information used for encryption and the corresponding key (K) With the help of the playback unit (R): In the first message: The amount of data in the serialized message (Serial.data) is reduced by identifying the location of the payload data (PDU) or the location of the first authentication code (MAC1) and removing at least the first authentication code (MAC1) from the protected and serialized first message; The reduced first message is deserialized and a protected second message is created by adding a second counter value (Z2) or replacing the first counter value (Z1) with the second counter value (Z2); a second authentication code (MAC2) is created and added, in the case of using the second counter value (Z2), the information for encryption and the key (K), and in the case of using the communication description (Com-Matrix) or the information obtained by applying the algorithm (A) for data interpretation. The protected second message is serialized and the corresponding message packet (NP) is sent to the receiving device to be tested.

2. The method according to claim 1, wherein, Remove the first counter value (Z1) from the protected and serialized first message.

3. The method according to claim 1, wherein, Payload data is identified using a lookup table (LT) created from the communication description, wherein the lookup table (LT) contains the message ID, the location of the payload data (PDU), and the length of the payload data (PDU).

4. The method according to claim 1, wherein, The first authentication code is identified by searching the serialized data (Serial.data) of the message using the algorithm (A) for data interpretation, wherein the algorithm (A) for data interpretation is based on the identification of encrypted information by identifying a continuous value with maximum entropy.

5. The method according to claim 4, wherein, The algorithm is implemented in hardware.

6. The method according to any one of claims 1 to 5, wherein, A message is distributed across multiple message packets (NPs) for transmission.

7. The method according to any one of claims 1 to 5, wherein, The receiving device is a real control unit or a virtual control unit, and the messaging system is provided by a real or simulated bus communication system or a real or simulated network or a combination of a bus system and a network.

8. The method according to claim 7, wherein, The messaging system is provided by the vehicle messaging system.

9. The method according to any one of claims 1 to 5, wherein, The second counter value (Z2) is given by the current counter value of the receiving device to be tested, or by a counter value predetermined by the user or by an automatically calculated counter value.

10. The method according to any one of claims 1 to 3, wherein, The payload data (PDU) of the protected first message is also encrypted using the first counter value (Z1), and the payload data (PDU) is decrypted in the replay unit (R), and the payload data is encrypted again using the encryption and the second counter value (Z2).

11. The method according to any one of claims 1 to 5, wherein, The information used for encryption also includes information for creating a protected second message for testing purposes, such that the protected second message should be recognized as erroneous by the receiving device.

12. A playback unit (R) configured to implement the method according to any one of claims 1 to 11.

13. The playback unit (R) according to claim 12, wherein, The replay unit (R) is designed as a unit for hardware-in-the-loop simulators and / or for simulators used in virtual protection.

14. The playback unit (R) according to claim 13, wherein, The unit used for the hardware-in-the-loop simulator and / or the simulator used for virtual protection is an additional unit.

Images