DE102021001095A1 - Counter-based method for recognizing lost and re-imported messages - Google Patents

Abstract

The invention relates to a counter-based method for recognizing lost and re-imported messages, in which a receiver and a transmitter are each equipped with a communication unit with which they can send and receive messages, with a total counter with a predetermined total length both at the transmitter and at the Receiver is held, with these synchronize before the beginning and with the sender and receiver agree on a number of low-order bits of the total counter to be transmitted before the messages are sent. The sender adds the agreed number of low-order bits of its previously incremented total counter to the new message to be sent, with the receiver reconstructing the total counter belonging to the received message from the total counter value stored locally at the receiver and the low-order bits received by using a trunk counter the higher-order bits of the total counter with the transferred lower-order bits if the value of the local value of the lower-order bits is less than or equal to the transferred value, or otherwise the rump counter is incremented beforehand. The sender and the receiver have implemented an integrity protection method which generates an integrity stamp for the message, which is based on the user data and the total counter of the sender, the receiver calculating the integrity stamp of the received message taking into account the reconstructed counter. The invention provides that, in the event that there is no match, the integrity stamp is checked several times until a match has been achieved or a predetermined number of iterative executions has been achieved, in each iterative execution the said body counter incremented and with the lower-order ones transmitted Bits is concatenated, the newly reconstructed counter being used as a basis for the respective recalculation and checking of the integrity stamp.

Description

The invention relates to a counter-based method for recognizing lost and re-imported messages according to the type defined in more detail in the preamble of claim 1.

This invention is in the field of CarlT security for vehicles. It describes a counter-based method to protect against replay attacks when using an insecure communication channel with limited transmission capacity.

There are many applications in which vehicles are remotely controlled by people, for example remote controlled parking or the like. In a general remote control process, a target system (e.g. a vehicle) is controlled as a receiver with the aid of a control unit, e.g. a smartphone as a transmitter via a communication channel (e.g. Bluetooth). The control unit sends messages containing control information (control messages) via the communication channel to the target system and thus influences the target system, for example its behavior, for example its mechanical movement, for example its speed and direction. At the same time, the target system can in turn send messages to the control unit, for example with information about its status, for example about the correctly or incorrectly received control messages, but does not necessarily have to.

1. 1. aktuell sein, d.h., ein durch die Steuerungseinheit erteilter Befehl muss zeitnah (mit niedriger Latenz (Verzögerungszeit)) am Zielsystem angekommen und dort verarbeitet sein,
2. 2. mit einer hohen Frequenz verschickt werden, damit das Zielsystem kontinuierlich (aktuelle) Steuerungsinformationen erhält und dadurch die Gewissheit hat, dass die Steuerungsseite ihre Rolle wahrnimmt, d.h., das Zielsystem kontrolliert und bspw. die Steuerung nicht ausgefallen ist,
3. 3. integritätsgeschützt sein, damit das Zielsystem eine während der Übertragung stattgefundene Veränderung einer Steuerungsnachricht, verlorengegangene oder mehrfach versendete Steuerungsnachrichten erkennen kann.

If a system, for example a moving system, for example a vehicle, for example by a person, is remote-controlled in real time, then the functional reliability (safety) is of particular importance, since the movement of the system may result in property damage or even people could be injured. This results in several central requirements for the protocol used for remote control. The messages containing the control information must:

1. 1. be up-to-date, i.e. a command issued by the control unit must arrive promptly (with low latency (delay time)) at the target system and be processed there,
2. 2. are sent with a high frequency so that the target system continuously receives (current) control information and thus has the certainty that the control side is performing its role, i.e. the target system is checking and, for example, the control has not failed,
3. 3. Be integrity-protected so that the target system can recognize a change in a control message that has taken place during the transmission, or control messages that have been lost or that have been sent several times.

From the desired low latency and high frequency, it follows on the one hand that it is advantageous to send short, easy-to-process control messages for which both generation in the control system, transmission to the target system and processing in the target system require little time. On the other hand, it is so that many of the technologies in question for such control protocols, for example Bluetooth Low Energy [BLE], are particularly efficient when using very short messages and this results in an upper limit for a meaningful size of the control messages.

Depending on the situation, adequate protection of the integrity of the control messages can be achieved in two ways. If it is assumed that the control messages only have to be protected against technical errors, e.g. transmission errors, but not against (intentional) manipulation, a non-tamper-proof procedure such as a CRC (e.g. CRC-32 or CRC- 64) used.

If, on the other hand, it is assumed that the control messages could possibly be manipulated by an attacker during the transmission, then they should be cryptographically authenticated. From the desired low latency, high frequency and short length of the control messages, it follows that control messages should sensibly be secured by symmetric cryptographic methods, in particular symmetric authentication mechanisms such as HMAC, which require significantly fewer resources in almost every respect compared to asymmetric cryptographic methods , even if, in principle, asymmetrical authentication mechanisms such as digital signatures can also be used for this.

Another aspect of the integrity protection is lost or multiple sent control messages. Both can be the result of a technical error as well as the result of deliberate manipulation by an attacker and should be able to be recognized by the target system.

Since the systems are often controlled by people and thus visually monitored, there is generally no need for permanent feedback from the target system to the control unit; a unidirectional protocol can be used for the time of control, which means that the requirement for control messages sent at a high frequency can be met much easier, since the sender (the control unit) does not have to wait for a response from the receiver (the target system) but rather the Can send control messages one after the other at times that are too close together, possibly even at fixed equidistant times.

Since the control unit does not have to receive any feedback from the recipient, in particular no acknowledgments of receipt for control messages that have been sent, the control unit cannot re-send lost messages because it does not always know whether a message has arrived or has been lost.

In order to ensure replay protection or to be able to detect the loss of control messages in the target system, a so-called nonce is added to all messages according to the state of the art, which may only occur once in the entire life cycle of the communication relationship. One of the three in the not previously published is often used to determine the nonce DE 10 2020 003 328 of 06/30/2020 "Time stamp-based procedure for protection against replay attacks" are used: Challenge-Response, monotonically increasing counter, time stamp.

The first method, challenge-response, is not suitable for the environment described here, since unidirectional communication is assumed and therefore no challenge can be transmitted from the target system to the control unit. The third method, time stamp, is also unsuitable for the environment described here, since the messages are sent at very short intervals, potentially in the millisecond range, and the clocks of the two systems would have to be very precisely coordinated so that communication could function robustly.

The remaining method, which uses a monotonically increasing counter as a nonce, does the job well by and large. This means that control messages that have been lost or that have been sent multiple times can be recognized by the target system. Furthermore, a monotonically growing counter can be combined well with both non-tamper-proof (such as CRC) and tamper-proof integrity protection methods (such as HMAC). The only problem that arises in this context is the space in the message that the meter needs. A counter i. d. Usually represented by a non-negative integer, the binary representation of which is encoded in the message as a bit sequence of fixed length, which may have leading zeros. For example, with a counter length of eight bits, the counter value 15 is represented by the bit sequence 00001111 and the counter value 254 by the bit sequence 11111110. Since a large number of messages have to be transmitted during the control process due to the high frequency, a counter, which, for example, should lead to unambiguous nonces over the entire service life of the system, may require several bytes (three-four). In short messages, for example 20 byte long, three or four bytes, which cannot be used for the transmission of user data (control information), play a major role. If you consider that some of the messages are required for an authentication stamp, e.g. 10 bytes for an abbreviated MAC, then a total of only 10 bytes at most remain for user data. If three-four bytes of this are used for the counter, only six-seven bytes remain for user data.

Like many other protocols, e.g. also the widespread TLS, a control protocol typically consists of two phases. In the first phase, the initialization phase ("handshake" in TLS), the details of the protocol to be used in the second phase, the operating phase (control phase, control process), and its Negotiated parameters or start values for certain variables. These details can be, for example, the protocol version to be used, the agreement of the exact message formats to be used in the control phase, the negotiation of common symmetric cryptographic keys, the coordination of the length and a common start value of the counter to be used for protection against replay attacks and the definition concern other protocol parameters.

If new cryptographic keys are negotiated in a secure manner for each new control process, the start value for the counter can be the same, for example or typically 0, for each control process. However, if the same key is used for several control processes, for example for the entire service life of the control system or for the entire service life of the target system, the counter contained in the individual control messages must not be repeated and must be explicitly agreed between the communication partners at the beginning. In this case, the counter is sensibly stored persistently by one of the communication partners after the end of a control process and is securely transmitted to the other side during the initialization phase before the next control process. It can therefore be assumed that at the beginning of the control process both partners are in possession of the same counter, i.e. they know its value and it is the same.

Compared to the control phase, the initialization phase is less time-critical, since no control process, for example no movement of the target system, takes place during this time. So can in this phase, for example, longer messages are exchanged bidirectionally and / or asymmetric cryptography, for example for negotiating a common symmetric key, is used. The actual control process takes place in the subsequent control phase; In this phase, the messages are short and, as a rule, only symmetric cryptography can be used.

To save transmission resources, uses "Security Protocols for Sensor Networks. Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, JD Tygar, Wireless Networks 8, 521-534, Kluwer Academic Publishers, 2002 “hereinafter referred to as [SNEP], a counter shared between sender and receiver that does not transmit but instead on both sides (sender, recipient) and is incremented simultaneously after each message: "Second, like many cryptographic protocols it uses a counter, but we avoid transmitting the counter value by keeping state at both end points." And further: "However, Sending the randomized data over the RF channel requires more energy. So we construct another cryptographic mechanism that achieves semantic security with no additional transmission overhead. Instead, we rely on a shared counter between the sender and the receiver for the block cipher in counter mode (CTR) (as we discuss in Section 6). Since the communicating parties share the counter and increment it after each block, the counter does not need to be sent with the message. To achieve two party authentication and data integrity, we use a message authentication code (MAC) ".

If the check of the MAC fails with [SNEP], it is assumed that messages must have been lost and an attempt is made to determine the counter value that matches the received message by trial and error and thus to synchronize the value of the counter on both sides again. If this fails, the counter value is synchronized using a dedicated protocol. "In case the MAC does not match, the receiver can try out a fixed, small number of counter increments to recover from message loss. In case the optimistic re-synchronization fails, the two parties engage in a counter exchange protocol, which uses the strong freshness protocol described below. "

When using a counter as a nonce to protect against replay attacks, the counters encoded as a bit sequence contained in successive messages differ only by one, i.e. hardly any. Most of the bits contained in the counters of consecutive messages, usually the "left" (more significant) More Significant Bits (MS bits), will therefore usually be the same, and their transmission is therefore redundant in most cases. If one could assume that the communication channel is absolutely reliable, i.e. that no control messages are lost or repeatedly transmitted and the control messages always arrive at the target system in the order in which they were sent, an initialization phase would have to set a common start value for the counter has been, no more counters are transmitted in the individual control messages, the determination of the counter belonging to a control message could be done completely implicitly by simply counting up (incrementing) the counter with each received control message. This is how it works at [SNEP].

In practice, however, messages can be lost. Assuming that at most one message can be lost in a row, it is sufficient to transfer only one bit (the lowest significant least significant bit, LS bit) of the counter in order to always be able to determine the associated counter for all lost messages. If a maximum of two or three messages can be lost in a row, two of the less significant bits (LS bits) of the counter must be transmitted. With a maximum of four to seven possible consecutive lost messages there are three LS bits, etc. In the general case, one can say that with k transmitted LS bits, the associated counters of up to (2 ^k - 1) consecutive lost messages can be correctly determined . It is important to transmit an "optimal" number of LS counter bits with the control messages in order, on the one hand, to always correctly reconstruct the complete counter used by the sender when forming the integrity stamp (e.g. CRC or MAC) by the receiver and then for to be able to use the checking of the integrity stamp, but on the other hand not to use too much space in the control messages for the LS bits of the counter.

In the general state of the art, it is proposed, analogously to [SNEP], to store the counter on both sides, ie at the sender and at the receiver, and to increment it synchronously, but in contrast to [SNEP], a certain number of Less Significant bits (LS bits) of the counter to be transmitted with each message. This portion of the counter bit sequence contained in each message N is referred to as N.ÜbertrZähler and its length, i.e. the number of bits transmitted, which is the same for all messages within a control process, is referred to as the transfer counter length.

A message N therefore consists of the concatenation of user data and the transmitted LS bits of the counter, i.e. N = N.Nutzdaten II N.ÜbertrZähler. After receiving the message N '= N'. User data II N '. Transfer counter, the Receiver then the counter N 'belonging to N'. Total counter from the successfully reconstructed counter E total counter belonging to the last correctly received (and possibly checked) message, stored internally at receiver E, and the LS counter received as part of the new message N ' Bits N'.TransferCounter of the total counter N'.TotalCounter belonging to the new message.

1. 1. Inkrementiere den Wert des beim Empfänger lokal gespeicherten Zählers E.GesZähler um 1, so dass E.GesZähler := E.GesZähler +1
   1. a. Sind keine Steuerungsnachrichten seit dem Empfang der letzten korrekten Steuerungsnachricht verlorengegangen und ist die Nachricht unverändert in der korrekten Reihenfolge beim Empfänger angekommen, so ist jetzt N'.GesZähler = E.GesZähler, da die Steuerungseinheit den Wert ihres lokal abgelegten Zählers vor der Bildung der Nachricht N ebenfalls inkrementiert hat.
2. 2. Bestimme ausgehend von der Bitfolge E.GesZähler und der Anzahl der zu übertragenden Bits ÜbertrZählerLänge die beiden Bitfolgen E.RumpfZähler und E.ÜbertrZähler, so dass E.GesZähler = E.RumpfZähler II E.ÜbertrZähler
3. 3. Prüfe, ob der so ermittelte lokale Wert E.ÜbertrZähler kleiner oder gleich dem empfangenen Wert N'.ÜbertrZähler ist, also ob E.ÜbertrZähler ≤ N'.ÜbertrZähler
   1. a. Wenn ja, wird angenommen, dass es seit dem Empfang der letzten korrekten Steuerungsnachricht durch das Zielsystem zu keinem Überlauf im Bereich der übertragenen LS-Bits aufgrund potentiell verlorengegangener Steuerungsnachrichten gekommen ist, der Gesamtzähler der empfangenen Nachricht N'.GesZähler wird direkt gebildet: N'.GesZähler := E.RumpfZähler II N'.ÜbertrZähler
   2. b. Wenn nein, wird angenommen, dass es seit dem Empfang der letzten korrekten Steuerungsnachricht durch das Zielsystem zu einem Überlauf im Bereich der übertragenen LS-Bits aufgrund potentiell verlorengegangener Steuerungsnachrichten gekommen ist, der Rumpf des lokal abgelegten Zählers wird vor der Bildung des Gesamtzählers der empfangenen Nachricht N'.GesZähler um eins erhöht:
      • N'.RumpfZähler := E.RumpfZähler +1
      • N'.GesZähler := N'.RumpfZähler II N'.ÜbertrZähler

It is also proposed in the general prior art that the sender N = N. User data || N.ÜbertrZähler increments the locally stored counter S.TotalCounter and the recipient the value of the total counter N'.TotalCounter belonging to a received message N 'from the locally stored value of the total counter E.TotalCounter = E.RumpfZähler II E.TransferCounter and the received The value of the transfer counter N '. Transfer counter reconstructed as follows. Without loss of generality, only the case is considered in which the sender increments the counter before the message is created, i.e. the start value of the counter increased by one, e.g. negotiated in the initialization phase, is used to create the first message as the counter value . Alternatively, the counter could also be incremented after a message has been sent, in which case the first control message would be formed with the same value of the counter as the negotiated start value.

1. 1. Increment the value of the counter E.TotalCounter stored locally at the receiver by 1, so that E.TotalCounter: = E.TotalCounter +1
   1. a. If no control messages have been lost since the last correct control message was received and the message has arrived unchanged in the correct order at the recipient, N'.GesCounter = E.GesCounter, since the control unit reads the value of its locally stored counter before the message was created N has also incremented.
2. 2. On the basis of the bit sequence E.TotalCounter and the number of bits to be transmitted, TransferCounterLength, determine the two bit sequences E.RumpfZähler and E.TubertrZähler, so that E.TotalCounter = E.RumpfZähler II E.TransferCounter
3. 3. Check whether the local value E.OverCounter determined in this way is less than or equal to the received value N'.TransferCounter, i.e. whether E.TransferCounter ≤ N'.TransferCounter
   1. a. If so, it is assumed that there has been no overflow in the area of the transmitted LS bits since the last correct control message was received by the target system due to potentially lost control messages, the total counter of the received message N '. Total counter is formed directly: N' .TotalCounter: = E.RumpfCounter II N'.TransferCounter
   2. b. If not, it is assumed that since the last correct control message was received by the target system, there has been an overflow in the area of the transmitted LS bits due to potentially lost control messages N'.Total counter increased by one:
      • N '. Body counter: = E. Body counter +1
      • N'.TotalCounter: = N'.RumpfZähler II N'.TransferCounter

1. (1) sich Nachrichten während der Übertragung weder aus technischen Gründen noch durch Manipulation verändern,
2. (2) Nachrichten in der richtigen Reihenfolge beim Empfänger ankommen,
3. (3) Nachrichten nicht mehrfach versendet werden und (4) nicht mehr als (2^{ÜbertrZählerlänge}-1) Nachrichten hintereinander verlorengehen,

so kann mit Hilfe des oben beschriebenen Verfahrens der zu einer Nachricht N' gehörende Zähler N'.GesZähler immer korrekt rekonstruiert werden (so dass N'.GesZähler = N.GesZähler) und damit die Nummer der empfangenen Nachricht eindeutig bestimmt werden. Insbesondere kann vom Empfänger so erkannt werden, ob und ggf. wie viele Nachrichten verlorengegangen sind. Die von ÜbertrZählerLänge abhängige maximale Anzahl hintereinander verlorengegangener Nachrichten, die vom Empfänger korrekt rekonstruiert werden können, wird mit MaxRekonstr(ÜbertrZählerLänge) bezeichnet, also MaxRekonstr(ÜbertrZählerLänge) := (2^{ÜbertrZählerlänge} - 1).Assume that

1. (1) Messages change during transmission neither for technical reasons nor through manipulation,
2. (2) Messages arrive at the recipient in the correct order,
3. (3) Messages are not sent more than once and (4) no more than (2 transfer ^{counter length} -1) messages are lost one after the other,

Thus, with the aid of the method described above, the counter N'.GesCounter belonging to a message N 'can always be correctly reconstructed (so that N'.GesCounter = N.GesCounter) and thus the number of the received message can be clearly determined. In particular, the recipient can thus recognize whether and, if so, how many messages have been lost. The maximum number of consecutive lost messages that can be correctly reconstructed by the recipient, which depends on the ÜberertrZählerLänge, is referred to as MaxRekonstr (TransferCounterLength), i.e. MaxRekonstr (TransferCounterLength): = (2 ^{TransferCounter length} - 1).

1. 1. E.GesZähler > N'.GesZähler kann wegen der Art der Berechnung von N'.GesZähler aus E.GesZähler und N'.ÜbertrZähler nicht vorkommen.
2. 2. Ist E.GesZähler = N'.GesZähler, so handelt es sich bei der empfangenen Nachricht N' um die erwartete Nachricht N.
3. 3. Ist E.GesZähler < N'.GesZähler, so handelt es sich bei der Nachricht N' um eine bislang nicht empfangene Nachricht N, es sind jedoch (N'.GesZähler - E.GesZähler) Nachrichten verlorengegangen.

It is suggested to use the value of the total counter N'.TotalCounter = N'.TotalCounter (E.TotalCounter, N'.TransferCounter) determined by the recipient in order to determine whether and, if so, how many messages have been lost. For this purpose, the total counter E.TotalCounter stored at the receiver and the reconstructed total counter of the received message N'.TotalCounter are compared with one another.

1. 1. E.TotalCounter>N'.TotalCounter cannot occur because of the type of calculation of N'.TotalCounter from E.TotalCounter and N'.TotalCounter.
2. 2. If E.TotalCounter = N'.TotalCounter, the received message N 'is the expected message N.
3. 3. If E.TotalCounter <N'.TotalCounter, the message N 'is a message N that has not yet been received, but (N'.TotalCounter - E.TotalCounter) messages have been lost.

It is further proposed, at the end of all checks, to assign the reconstructed value of the total counter of the message N'.TotalCounter to the locally stored total counter of the receiver E.GesCounter, i.e. E.GesCounter: = N'.TotalCounter. E.TotalCounter thus corresponds again to the value of the successfully reconstructed total counter of the last received message, so that the recipient is again in the state that allows him to correctly reconstruct the total counter of the next received message.

Furthermore, it is proposed to use the total counter N'.GesCounter of the received message N ', reconstructed according to the method described first, to identify any number of messages that have been lost or that have been transmitted several times or that have arrived in the wrong order. For this purpose, it is proposed to transmit an integrity stamp IntStemp of the message with each message in addition to the user data and the transmitted LS bits of the counter, this integrity stamp IntStemp using an integrity protection method INT depending on the user data to be transmitted N. user data and the total at Transmitter stored counter S.GesZähler is formed, i.e. N.IntStemp: = INT (N.Nutzdaten, S.GesZähler), with the integrity protection method INT e.g. a non-cryptographically secure integrity protection method such as CRC or a cryptographically secure e.g. symmetrical authentication method such as e.g. HMAC is used. The transmitted message thus has the form N = N.Nutzdaten II N.ÜbertrZähler || N.IntStemp, where e.g. N.IntStemp: = CRC (N.Nutzdaten || S.TotalCounter) or N.IntStemp: = AUTH (symmKey, N.Nutzdaten || S.TotalCounter), where AUTH is a cryptographically secure one of the two The symmetric authentication method implemented by partners and symmKey is a symmetric key that is known to both the sender and the recipient. In order to save space in the message, if a cryptographically secure symmetric authentication method is used, not the entire integrity stamp but only part of it, e.g. the first (higher-value, most significant) k, e.g. ten, bits can be used as part of the message N.IntStemp.

In general, asymmetrical authentication procedures, e.g. digital signatures, which are then transmitted as IntStemp, can also be used as INT. In the context described here, however, these should play a lesser role, since the typical digital signature (e.g. 2048 with RSA or 256 with ECC-256) is at least as large as the typical MAC (e.g. 256 with HMAC-SHA-256) And above all, in order to be able to be successfully checked by the recipient, a complete digital signature must always be available to the recipient and must therefore be transmitted completely as part of the message, the transmission of only part of the integrity stamp, as possible and usual in the symmetrical case, not possible is.

1. 1. Rekonstruiere den Gesamtzähler der empfangenen Nachricht N' N'.GesZähler bspw. nach dem oben beschriebenen Verfahren 1.
2. 2. Berechne den Integritätsstempel N'.IntStemp' := INT(N'.Nutzdaten, N'.GesZähler) nach dem mit dem Sender vereinbarten Verfahren INT, bspw. als
   1. a. N'.lntStemp' := CRC(N'.Nutzdaten || N'.GesZähler) oder
   2. b. N'.lntStemp' := AUTH(symmKey, N'.Nutzdaten || N'.GesZähler)

It is also proposed that after receiving the message N '= N'.Nutzdaten II N'.ÜbertrZähler || N'.lntStemp to determine whether the received message has been changed during transmission or whether messages have been lost or have been sent several times or have arrived in the wrong order, the recipient should carry out the following steps.

1. 1. Reconstruct the total counter of the received message N 'N'. Total counter, for example using method 1 described above.
2. 2. Calculate the integrity stamp N'.IntStemp ': = INT (N'.Nutzdaten, N'.TotalCounter) according to the INT method agreed with the sender, e.g. as
   1. a. N'.lntStemp ': = CRC (N'. user data || N'.total counter) or
   2. b. N'.lntStemp ': = AUTH (symmKey, N'. user data || N'.total counter)

• 3.Vergleiche den berechneten Integritätsstempel N'.IntStemp' mit dem empfangenen Integritätsstempel N'.IntStemp.
  • a.Falls N'.IntStemp' == N'.IntStemp
    1. i. ERFOLG :=TRUE
  • b.Falls N'.lntStemp' # N'.IntStemp
    1. i. ERFOLG := FALSE

At this point, the representation assumes the use of a symmetrical procedure such as CRC or HMAC without loss of generality.

• 3. Compare the calculated integrity stamp N'.IntStemp 'with the received integrity stamp N'.IntStemp.
  • a.If N'.IntStemp '== N'.IntStemp
    1. i. SUCCESS: = TRUE
  • b.If N'.lntStemp '# N'.IntStemp
    1. i. SUCCESS: = FALSE

If the two integrity stamps are not the same, i.e. if SUCCESS = FALSE, then the counter N'.TotalCounter reconstructed according to the method first described above does not correspond to the counter S.TotalCounter used by the sender, so the message has changed or it has changed during the transmission has been changed, or a message that has arrived in the wrong order has been received, or since the last correctly received message was received, more than MaxRekonstr (TransferCounterLength) messages have been lost. In this case, exception handling can be initiated, for example the control process can be aborted and then the values of the total counter on both sides, i.e. S.TotalCounter and E.TotalCounter, are synchronized again outside of the control process.

If the two integrity stamps are the same, i.e. if SUCCESS = TRUE, then the counter N'.TotalCounter reconstructed according to method 1 corresponds to the counter S.TotalCounter used by the sender, which means that the message has arrived unchanged and in the correct order at the recipient and it N'.TotalCounter - E.TotalCounter ≤ MaxRekonstr (TransferCounterLength) messages have been lost since the last message was received.

If SUCCESS = TRUE, it is also proposed, at the end of all checks, to assign the reconstructed and INT-checked value of the total counter of the message N'.GesCounter to the locally stored total counter of the recipient E.GesCounter, i.e. E.GesCounter: = N'.GesCounter.

As described above, there can be several reasons for the failure of the integrity check carried out after the reconstruction of the total counter N'.TotalCounter with INT, e.g. CRC or AUTH, e.g. a change in the message during transmission, too many lost messages, etc. In the event that messages could have been lost, an attempt is made in [SNEP] to find the counter that matches the received message by successively incrementing the shared counter stored at the recipient multiple times, if necessary, and then performing a renewed authentication check and, if successful, to accept the message and then adjust the counter at the recipient accordingly.

The object of the present invention now consists in specifying an improved method.

This object is achieved by the method with the features in claim 1. Advantageous refinements and developments are specified in the dependent claims.

The inventive counter-based method for recognizing lost and re-imported messages provides that a receiver E or a target system ZS and a transmitter S or a control unit SE are each equipped with a communication unit with which they can send and receive messages, with the sender sends control messages to the recipient. A total counter S.TotalCounter, E.TotalCounter with a predetermined total length GesZählerLänge of more than 0 bits is provided in each case to identify lost and possibly re-imported messages, which are held at both the sender S and the receiver E, whereby before the start of a message comprising the messages During the control process, the communication partners synchronize the start value to be used for the total counters S.TotalCounter, E.TotalCounter, whereby the sender and receiver agree on a number of TransferCounterLength of the lower-order bits of the total counter transmitted with the messages, which are between zero and the total length GesZählerLength of the two total counters, with the sender incrementing its total counter S.GesZähler and the user data of the new message to be sent the agreed number of low-order bits LS bits of its previous increment before the creation of a new message to be sent erten total counter, the recipient after receiving the message reconstructs the total counter N'.GesZähler belonging to the received message N 'from the value of a trunk counter E.RumpfZähler of the total counter stored locally at the receiver E and the received low-order bits. For this purpose, the body counter is either concatenated directly with the transmitted lower-order bits if the local value of the lower-order bits is less than or equal to the transmitted value, or it is otherwise incremented beforehand, as described above. The rump counter itself contains a number of more significant bits of the total counter E. Total counter of the receiver, which results from the total length E. Total length counter minus the transmitted number N '. Transfer counter length of the lower value bits.

Both the sender and the receiver have implemented an integrity protection procedure, according to which the sender generates an integrity stamp N.IntStemp for the message N, which is based on the user data N. User data and the total counter S.TotalCounter of the sender, and this integrity stamp of the message adds. At the receiver, the integrity stamp N'.IntStemp received with the received message N 'is calculated according to the agreed or specified integrity protection method, taking into account the reconstructed counter.

According to the invention, it is provided that in the event that there is no match, the verification of the integrity stamp is run through several times until a match is achieved or a predetermined number n of iterative executions or loops i has been achieved, with i in each iterative execution i the The body counter determined above is incremented and concatenated with the transmitted lower-order bits. The thus newly reconstructed counter is used for the respective recalculation and verification of the Based on the integrity stamp. In the event that the specified number n of iterative executions i is reached, it is concluded that a message was changed during the transmission, that there are too many failed messages, that messages have been replayed or that messages have arrived in the wrong order.

1. 1. Initialisierung
   1. a. Rekonstruiere N'.GesZähler nach dem oben zuerst beschriebenen Verfahren
   2. b. N'.RumpfZähler(1) := N'.RumpfZähler
   3. c. i := 1, ERFOLG := FALSE
2. 2. Schleife
   1. a. Wiederhole
      1. i. N'.GesZähler(i) := N'.RumpfZähler(i) || N'.ÜbertrZähler
      2. ii. N'.lntStemp(i) := INT(N'.Nutzdaten, N'.GesZähler(i))
      3. iii. falls N'.IntStemp(i) # N'.IntStemp
         • N'.RumpfZähler(i+1) := N'.RumpfZähler(i) + 1
         • i := i + 1
         • andernfalls
         • ERFOLG := TRUE
         • N'.GesZähler := N'.GesZähler(i)
         • Abbruch der Schleife
   2. b. bis i > n

In the method according to the invention, assuming lost but not changed messages, it can be assumed that the received transfer counter length LS bits of the counter matching the message are correct, i.e. match the received message N '. It is therefore proposed, unlike in [SNEP], not successively increment the entire total counter determined for the received message after an unsuccessful integrity check, but instead increment the total counter by incrementing the body N ', body counter and that determined during the reconstruction of the total counter of N' Subsequent assembly of the new N'.TotalCounter to be tried out from the new incremented N'.RumpfZähler and the unchanged received N'.TransferCounter to be successively newly formed and then to try out its suitability with INT by performing the following steps: (n stands for the maximum number of attempts to be carried out, n = 1 thus corresponds to the above-described one-time test of the reconstructed total counter with INT; i represents the respective iterative execution or loop).

1. 1. Initialization
   1. a. Reconstruct N'.totalcount using the method first described above
   2. b. N'.RumpCounter (1): = N'.RumpCounter
   3. c. i: = 1, SUCCESS: = FALSE
2. 2nd loop
   1. a. Repeat
      1. i. N'.TotalCounter (i): = N'.RumpCounter (i) || N'.Transfer counter
      2. ii. N'.lntStemp (i): = INT (N'. user data, N'.total counter (i))
      3. iii. if N'.IntStemp (i) # N'.IntStemp
         • N'.RumpCounter (i + 1): = N'.RumpCounter (i) + 1
         • i: = i + 1
         • otherwise
         • SUCCESS: = TRUE
         • N'.TotalCounter: = N'.TotalCounter (i)
         • Termination of the loop
   2. b. until i> n

The value of SUCCESS can then be used to read off whether a suitable total counter for N 'could be found.

If SUCCESS = FALSE, none of the successively determined counters N'.TotalCounter (i) corresponds to the counter S.TotalCounter used by the sender, the message has changed during the transmission or it has been changed or there is one in the wrong one Sequence of received messages or more than MaxRekonstr (TransferCounterLength, n) messages have been lost since the last correctly received message (a definition for MaxRekonstr (TransferCounterLength, n) is given below). In this case, exception handling can be initiated, e.g. the control process can be aborted and then the values of the total counters on both sides, i.e. S.TotalCounter and E.TotalCounter, can be synchronized again outside of the control process.

If SUCCESS == TRUE, the message N 'is unchanged and arrived at the recipient in the correct order, i contains the number of attempts at the end, where i was the successful attempt, N'.TotalCounter = N'.TotalCounter (i ) the correct total counter matching N 'and the number of messages that have been lost one after the other since the last correct message was received is then given by (N'.TotalCounter (i) - E.TotalCounter).

If SUCCESS = TRUE, it is also proposed, at the end of all checks, to assign the successfully determined value of the total counter of the message N'.GesCounter to the locally stored total counter of the recipient E.GesCounter, i.e. E.GesCounter: = N'.GesCounter.

It is clear that the method just described with n successive attempts of n different total counter values can only be used meaningfully if the exchanged messages are integrity-protected by means of INT and an integrity stamp is transmitted. Without this integrity protection, it would not be possible to determine whether a specific total counter matches a received message or not.

• •Durch die Übertragung nur eines Teils des Zählers wird Platz in der Nachricht gespart, was insb. bei Verwendung sehr kurzer Nachrichten, wie sie oft zur Echtzeitsteuerung verwendet werden, von großer Bedeutung sein kann.
• •Es kann ein beliebig großer Zähler verwendet werden, so dass es keine Security-Einbußen gibt.
• •Durch sukzessives ausprobieren mehrerer Gesamtzähler, also sukzessives Inkrementieren des Zählerrumpfes und nachfolgende Integritätsprüfungen unter Nutzung des neuen Gesamtzählers nach erfindungsgemäßen Verfahren, kann die Robustheit gegen verlorengegangene Nachrichten weiter erhöht werden.

The invention provides the following advantages:

• • The transmission of only part of the counter saves space in the message, which can be of great importance, especially when using very short messages, as are often used for real-time control.
• • Any size counter can be used so that there is no loss of security.
• By successively trying out several total counters, ie successive incrementing of the counter body and subsequent integrity checks using the new total counter according to the method according to the invention, the robustness against lost messages can be further increased.

The maximum number of consecutive lost messages that the protocol can still "cope with" in that the total counter belonging to a received message can still be successfully determined depends both on the number of LS bits transmitted by the counter, i.e. on the transfer counter length, as well as on the maximum number of attempts n to be carried out. The recipient can successfully determine the total counter of a message N 'after a maximum of (n * 2 ^{TransferCounterLength} -1) (n> = 1, TransferCounterLength> = 0) consecutive lost messages. This value is called MaxRekonstr (TransferCounterLength, n), i.e. MaxRekonstr (TransferCounterLength, n): = (n * 2 ^{TransferCounterLength} - 1).

Note that n = 1 corresponds to the case of the protocol without integrity protection, i.e. without the use of INT, and the case of the protocol with integrity protection with exactly one attempt. In both cases, the total counter of a message can be ^{correctly determined for up to (2 transfer counter length} - 1) messages that were lost one after the other. TransferCounterLength = 0 means that the total counter of a message can be correctly determined if up to n messages were lost in a row. n = 1 (exactly one attempt) and transfer counter length = 0 (no transmitted LS bits) means that the total counter of the following message can no longer be determined if a message is lost.

MaxRekonstr (TransferCounterLength, n) can be increased by increasing TransferCounterLength and / or by increasing n. The larger n or TransferCounterLength, the more lost messages can be tolerated by the protocol. Both the increase in n and the increase in TransCounterLength lead to a higher consumption of resources, but in different ways. The larger n is, the more IntStemp test attempts the recipient has to carry out, so an increase in n primarily loads the computing power of the recipient and thus increases the time span between the sending of the message by the sender and the processing of the information contained in its user data by the recipient. On the other hand, an increase in TransferCounterLength leads to a reduction in the space that is available for the transmission of the user data in the message. A suitable, coordinated selection of values for n and transfer counter length can be used to select a setting for the protocol that is particularly suitable for the intended application environment and the task to be solved.

Assume that it has been specified for the protocol that a counter of counter-length bits is required in order to be protected against replay attacks for a sufficiently long time. The question arises of how many of its LS bits have to be transmitted with the message, i.e. how large the ÜtransCounterLength has to be, and how many IntStemp test attempts n have to be carried out at the maximum in order to have a sufficient probability of the sender generating the Integrity stamp used as a nonce counter on the receiving end without errors.

At least two upper limits can be set for the size of MaxRekonstr (TransferCounterLength, n). As noted above, the communication channel is believed to be unreliable and messages can be lost. By specifying a technology (e.g. BLE), a technology-dependent upper limit can be specified for the loss of how many consecutive messages will be accepted by the technology before the connection on the lower layer is broken or the loss of how many consecutive messages is so unlikely with the technology used that this value is accepted as an upper limit and that the rare event that more consecutive messages are lost is accepted. This upper limit determined by the technology used is referred to as MaxNachrVerlTechn.

A second upper limit is always given by the application, for example by the target system. It can always be stipulated how many consecutive control messages the application or target system can cope with before it cancels the control process, for example for safety reasons. If, for example, messages are sent every 50 ms and the application has set a timeout of two seconds, the target system will abort the control process after 40 consecutive control messages have failed. This application-dependent number of messages is referred to as MaxNachrVerlAnw.

Now, as a first approximation, an indirect upper limit for OvertrailerLength and n can be determined by choosing OvertransCounterLength and n in such a way that, if TransferCounterLength> 0, always MaxRekonstr (TransferCounterLength - 1, n) <MaxVerlNachr and, if n> 1, always MaxRekonstr (TransferCounterLength, n -1) <MaxVerlNachr applies, where MaxVerlNachr is defined as follows MaxVerlNachr: = MIN {MaxVerlNachrTechnr, MaxVerlNachrTechnr, MaxVerlNachrTechnr , where MIN denotes the smallest element of a finite set of integers.

If, for example, MaxVerlNachrTechn = 24 and MaxVerlNachrAnw = 40, if n = 1 is selected, the maximum number of bits required for coding MaxVerlNachr = 24 is transmitted, in this case because of (1 * 2 ^5-1 -1 <24 ≤ 1 * 2 ^6-1 - 1), i.e. a maximum of five bits, i.e. MaxTransferCounterLength (n = 1) = 5. With n = 2, due to (2 · 2 ^4-1 - 1 <24 ≤ 2 · 2 ^5-1 -1) transfer a maximum of four bits, i.e. MaxÜbertrZählerLänge (n = 2) = 4 and with n = 3 because (3 * 2 ^{3 - 1} - 1) <24 ≤ 3 * 2 ^4-1 -1) transfer a maximum of three bits. The transmission of more bits makes no sense, since these are never required for the reconstruction of the counter, because the control process will be aborted earlier because MaxVerlNachrTechn or MaxVerlNachrAnw is exceeded. However, it can make perfect sense to actually transfer less than MaxÜbertrZählerLänge (n) of the LS bits of the counter in order to save space in the message, for example.

It is also proposed to keep the two variables MaxNachrVerlTechn and MaxNachrVerlAnw persistent in one of the two systems or in both systems. In the initialization phase, the MaxVerlNachr value is negotiated by, for example, first determining the minimum MaxVerlNachr of the two values on the respective side (control unit, target system) and then the minimum of the two minima as the starting point for determining the value of MaxRekonstr (TransferCounterLength, n ) is taken. It is proposed that the values to be used during the control phase for TransferCounterLength and n are negotiated during the initialization phase and that they are always selected so that, if TransferCounterLength> 0, MaxRekonstr (TransferCounterLength - 1, n) <MaxVerlNachr and, if n> 1, always MaxRekonstr (transfer counter length, n - 1) <MaxVerlNachr applies.

1. 1. Je weniger Zählerbits übertragen werden, also je kleiner ÜbertrZählerLänge ist, desto mehr Platz gibt es in der Nachricht für Nutzdaten, insb. bspw. für ggf. safetyrelevante Steuerungsinformationen enthaltende Nutzdaten. Auf diese Weise können präzisere Steuerungsbefehle in der Steuerungsnachricht kodiert werden, wodurch die Qualität der Steuerung, insb. deren Sicherheit, erhöht wird.
2. 2. Je weniger Zählerbits (bei einer festen maximalen Anzahl n von ausprobierten Gesamtzählerwerten) übertragen werden, desto kleiner sind die „Pausen“ zwischen empfangenen Nachrichten, die vom Zielsystem akzeptiert werden. Wird eine „Pause“ zu groß, schlägt die Gesamtzählerbestimmung für die erste nach der „Pause“ empfangene Steuerungsnachricht fehl, weil der zu dieser Nachricht gehörende Gesamtzähler vom Zielsystem anhand der zu wenigen empfangenen Bits (und eines ggf. zu kleinen n) nicht bestimmt werden kann und der Steuerungsvorgang daraufhin abgebrochen wird.

Under the reasonable assumption that the target system goes into a safe state after a certain time without receiving control messages ("timeout") or when receiving a control message for which no suitable total counter can be determined, it can be said that the smaller the transfer counter length, That is, the number of LS bits transmitted by the counter is selected, ie the fewer LS bits that are transmitted with each control message, the more precise and, in particular, more reliable (in the sense of safety, “more reliable”) the control is. There are two reasons:

1. 1. The fewer counter bits are transmitted, that is, the smaller the ÜberertrZählerLänge is, the more space there is in the message for user data, in particular, for example, for user data that may contain security-relevant control information. In this way, more precise control commands can be encoded in the control message, whereby the quality of the control, in particular its safety, is increased.
2. 2. The fewer counter bits (with a fixed maximum number n of tried total counter values) that are transmitted, the smaller the “pauses” between received messages that are accepted by the target system. If a "pause" is too large, the total counter determination for the first control message received after the "pause" fails because the total counter belonging to this message is not determined by the target system based on the few received bits (and possibly too small n) and the control process is then aborted.

1. 1. die Qualität der in den Steuerungsnachrichten enthaltenen Steuerungsinformation (je weniger Zählerbits übertragen werden, desto mehr Platz gibt es in den Steuerungsnachrichten für die Übertragung hochwertigerer Steuerungsinformationen) und
2. 2. die maximale Anzahl von hintereinander ausgefallenen Steuerungsnachrichten, die das Zielsystem bereit zu akzeptieren ist (je weniger Zählerbits übertragen werden und je weniger Integritätsprüfungsversuche n maximal durchgeführt werden, desto weniger ausgefallene Nachrichten werden akzeptiert)

Based on this consideration, the value of MaxVerlNachrAnw defined above can be influenced by at least two of the following goals:

1. 1. the quality of the control information contained in the control messages (the fewer counter bits are transmitted, the more space there is in the control messages for the transmission of higher quality control information) and
2. 2. the maximum number of consecutive failed control messages that the target system is ready to accept (the fewer counter bits are transmitted and the fewer integrity check attempts n maximum are carried out, the fewer failed messages are accepted)

On the other hand, the more counter bits are transmitted and the larger n is, the more robust the control process, because in this way the total counter of the message can be successfully determined by the target system even if there is a large number of consecutive failed control messages, which prevents the control process from being aborted .

It is also proposed to keep a variable MinUsedLength persistently in one of the two systems or in both systems (control unit, target system). The value of this variable describes how many bits are at least required for the transmission of user data, e.g. control information. This ensures that the quality of the transmitted user data, for example the control information, does not reach a certain level defined by MinNutzdLänge falls below. Assuming that the user data and the transmitted part of the counter share a part of the message of fixed length, this variable implicitly also limits the number of counter bits to be transmitted. Thus, the value of MinNutzdLänge can be used in addition to the value of MaxVerlNachr to determine or further limit the value of TransferCounterLength during the initialization phase.

The variables MaxVerlNachrTechn, MaxVerlNachrAnw and MinNutzdLänge are assigned estimated values that reflect the knowledge and experience that were available at the time these values were assigned. However, the assessment of the optimal values for MaxVerlNachrTechn, MaxVerlNachrAnw and MinNutzdLänge can change over time. If the variables MaxVerlNachrTechn, MaxVerlNachrAnw and MinNutzdLänge can be updated in the respective systems (control unit, target system), this should also be done. This may also change the meaningful value ranges for TransferCounterLength and n. On the other hand, these updates cannot be made equally quickly and cost-effectively on both sides (e.g. an update of a control unit (smartphone app) is much easier than an update of the target system (vehicle control unit)). Among other things, it is therefore possible that the values assigned to the variables MaxVerlNachrTechn, MaxVerlNachrAnw and MinNutzdLänge on the respective pages are different.

1. 1. Von einem außerhalb der beiden Systeme (Steuerungseinheit, Zielsystem) liegenden, bspw. zentralen, Drittsystem wird festgestellt, dass der als optimal angesehene Wert für eine der mindestens drei persistenten Variablen sich geändert hat und daraufhin dieser neue als optimal angesehene Wert dem jeweiligen System (Steuerungseinheit, Zielsystem) mitgeteilt wird, worauf dieses den Wert der betroffenen Variable auf den neuen zu diesem Zeitpunkt als optimal angesehenen Wert aktualisiert.
2. 2. Von einem der beiden Systeme (Steuerungseinheit, Zielsystem) wird, bspw. eigenständig, festgestellt, dass der als optimal angesehene Wert für eine der mindestens drei in dem System abgelegten persistenten Variablen sich geändert hat. Daraufhin wird dieser neue als optimal angesehene Wert der betroffenen Variable zugewiesen.

It is also proposed that the at least three persistent variables MaxVerlNachrTechn, MaxVerlNachrAnw, MinNutzdLänge be updated in the respective systems (control unit, target system), the updates being made between the control processes. These updates can be made in two ways.

1. 1. From a, for example, central, third-party system located outside of the two systems (control unit, target system), it is determined that the value considered optimal for one of the at least three persistent variables has changed and then this new value considered optimal has changed for the respective system (Control unit, target system) is communicated, whereupon it updates the value of the variable concerned to the new value considered optimal at this point in time.
2. 2. One of the two systems (control unit, target system) establishes, for example independently, that the value that is regarded as optimal has changed for one of the at least three persistent variables stored in the system. This new value, which is considered optimal, is then assigned to the variable concerned.

With the at least three variables MaxVerlNachrTechn, MaxVerlNachrAnw, MinNutzdLänge, the possible number of counter bits to be transmitted, TransferCounterLength and the maximum number of total counter values n to be tested, are restricted in various ways, but not precisely defined. It is suggested to persistently store the value TransferCounterLength in one of the two systems (control unit, target system) or in both systems and the maximum number of total counter values to be tried out in the target system and to check in each initialization phase whether the stored values meet all requirements with regard to the meet three restrictive variables MaxVerlNachrTechn, MaxVerlNachrAnw, MinNutzdLänge.

The variables MaxVerlNachrTechn, MaxVerlNachrAnw and MinNutzdLänge implicitly define a sensible upper limit for the number of bits to be transmitted in the counter and the maximum number of total counters to be tested, thus ensuring that no obviously unnecessary counter bits are transmitted or that no obviously unsuitable total counters are tried out become.

Due to the coordinated setting of the number of bits to be transmitted in the counter and the number of total counters to be tried out, the protocol can be adapted to the respective situation and the space in the message can be optimally used or the computational effort on the part of the recipient can be reduced. By choosing a slightly larger number of total counters n to be tried out and a slightly smaller number of transmitted LS bits, the disadvantage arising from a large n, namely the increased computational requirements at the receiver, may only be relatively seldom occurring case of actually lost messages becomes effective, while a larger number of transmitted LS bits has an adverse effect on each transmitted message.

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• DE 102020003328 [0011]

Claims (8)

Counter-based method for recognizing lost and replayed messages, in which a receiver and a sender are each equipped with a communication unit with which they can send and receive messages, the sender sending messages to the recipient, with one to recognize lost and possibly re-imported messages Total counter with a predetermined total length of more than 0 bits is used, which is held both at the sender and at the receiver, the sender and the receiver synchronizing the start value to be used for the total counter before the start of a control process comprising the messages, with the sender and before the messages are sent, the receiver agrees on a number of low-order bits of the total counter transmitted together with the user data of the messages, which is between 0 and the total length of the total counter, with one before the formation In the new message to be sent, the sender increments its total counter, the sender adding the agreed number of the lower-order bits of its previously incremented total counter to the user data in the new message to be sent, the recipient using the total counter belonging to the received message from the total counter stored locally at the recipient The value of the total counter and the received low-order bits are reconstructed by concatenating a trunk counter, which comprises a number of high-order bits of the total counter of the receiver, which results from the total length of the total counter minus the transferred number of low-order bits, directly with the transferred low-order bits , if the value of the local value of the lower-order bits is less than or equal to the transmitted value of the lower-order bits, or if this is not the case, the body counter is first incremented and then concatenated with the lower-order bits, whereby the sender and the recipient has implemented an integrity protection method by the sender generating an integrity stamp for the message, which is based on the user data and the total counter of the sender, and adding this integrity stamp to the message, the recipient adding the integrity stamp of the received message according to the agreed or specified integrity protection method calculated taking into account the reconstructed counter, characterized in that if there is no match, the verification of the integrity stamp is run through several times until a match has been achieved or a predetermined number of iterative executions has been achieved, said rump counter being incremented or in each iterative execution incremented again and concatenated with the transmitted lower-order bits, the total counter thus newly reconstructed pulling the respective recalculation and checking of the integrity stamp round is placed, and in the event that the predetermined number of iterative executions is reached, a message changed during transmission, too many failed messages, replayed messages or messages that have arrived in the wrong order are concluded. Procedure according to Claim 1 , characterized in that, in the event that the iterative executions are aborted due to a recognized match, the total counter of the receiver is set to the value of the reconstructed counter in the case of the match. Procedure according to Claim 1 or 2 , characterized in that a non-cryptographically secure integrity protection process, a cryptographically secure symmetrical authentication process or a cryptographically secure asymmetrical authentication process is used as the integrity protection process. Procedure according to Claim 3 , characterized in that CRC, HMAC, DSA or ECDSA is used as the integrity protection procedure. Method according to one of the Claims 1 to 4th , characterized in that the message sent by the sender has the general form N = N.Nutzdaten || N.TransferCounter || N.IntStemp accepts. Method according to one of the Claims 1 to 5 , characterized in that the sender and / or the receiver holds one or more of three variables MaxVerINachrTechn, MaxVerlNachrAnw, MinNutzdLänge persistently, the value MaxVerlNachr being determined from the values of the one or more variables, with the number of low-order bits transmitted, TransferCounterLength the restriction given by MinUsableLength is always met, and the number of low-order bits transferred, TransferCounterLength and the number of attempts n are always selected so that, if TransferCounterLength> 0, MaxRekonstr (TransferCounterLength - 1, n) <MaxVerlNachr and, if n > 1, always MaxRekonstr (transfer counter length, n - 1) <MaxVerlNachr applies. Procedure according to Claim 6 , characterized in that the number of low-order bits transmitted and the number of specified attempts are selected so that the maximum conceivable number of consecutive lost messages is recognized, so that MaxRekonstr (TransferCounterLength, n) ≥ MaxVerlNachr applies. Procedure according to Claim 6 or 7th , characterized in that the three variables MaxVerlNachrTechn, MaxVerlNachrAnw, MinNutzdLänge can be updated, whereby the update can be carried out externally by a third-party system or by the system itself based on the observation of the environment and the conditions and learning from the past.