DEVICES AND METHODS FOR GENERATING AND AUTHENTICATION CHECKING AT LEAST ONE DATA PACKET TO BE TRANSMITTED IN A BUS SYSTEM (BU), IN PARTICULAR OF A MOTOR VEHICLE

Description

[0001] The invention relates to devices and methods for (transmitter-side) generating and (receiver-side) authentication checking of at least one data packet to be transmitted in a bus system (BU), in particular of a motor vehicle.

[0002] DE 10 2017 125826 A1, EP 3 432 511 A1, DE 10 2014 113111 A1 and DE 10 2015 015361 A1 disclose encryption systems.

[0003] The following publications concern secure transmission of messages: [1] W. Zimmermann, R. Schmidgal Bus systems in vehicle technology, 4th edition, Vieweg + Teubner 2011 [2] AUTOSAR Specification of Secure Onboard Communication,

[0004] Release 4.3.1, www.autosar.com [3] Yang, G., Zhu, B., Suder, V., Aagaard, MD, Gong, G: The SIMECK Family of Block Ciphers, In Cryptographic Hardware and Embedded Systems-CHES 2011 (pp. 342-357). 2015 Springer Berlin Heidelberg. pdf at eprint.iacr.org

[0005] Message Authentication Codes (MACs) (the German term "Nachrichtenauthentisierungscode" is used here, as in Wikipedia, for example) can be used to ensure the integrity of a transmitted message, similar to a checksum. In the case of an encrypted MAC (CMAC), this can only be calculated on the receiver side if a cryptographic key is known. A receiving bus node that also possesses this key can thus verify the authenticity of a message's content. The message itself is transmitted unencrypted along with a MAC or CMAC.

[0006] An object of the invention is to efficiently implement secure communication in a bus system of a vehicle.

[0007] The problem is solved by the subject matter of the independent patent claims, in particular on the transmitter side and the receiver side, as a method and device, respectively. Embodiments of the invention can efficiently enable secure communication in a network in a vehicle. The method can, for example, efficiently enable authentication of a replay-proof transmitted message authentication code (CMAC) in the receiver of a data packet.

[0008] Some particularly advantageous embodiments of the invention are specified in the subclaims and the description.

[0009] According to embodiments of the invention, the count value can be, for example, a value generated with a counter, which represents, for example, the number of messages sent and / or received via the bus system so far, in particular since the last restart of the bus system (which can be implemented particularly easily, for example, in software), or a timer value of at least one timer, which is available in particular from several or all bus participants (which can increase security, in particular when the same time / timer values ​​are available from several bus participants).

[0010] According to embodiments according to the invention, a receiver-side authentication check can in particular use a threshold value when comparing a current received message count and a previous received message count, which threshold value is preferably set to a higher value after a restart of the bus system than in normal operation, which can optimize security depending on the situation.

[0011] The bus system, in particular a CAN bus or a CAN-FD bus or a LIN bus or an SPI bus or an Ethernet bus, or an I2C bus can be provided for communication between ECUs.

[0012] Further features and advantages of some advantageous embodiments of the invention will become apparent from the following description of exemplary embodiments of the invention with reference to the drawings. The drawing shows, by way of example, some possible embodiments of the invention, in a simplified and schematic manner: Fig. 1 a motor vehicle with a network according to the invention in the form of a bus system with several bus participants, Fig. 2 a structure of a data packet to be transmitted that can generally be used in a conventional bus system, and the generation of parts of the data packet, Fig. 3 in a conventional bus system, possible values ​​of messages and message authentication codes contained in four data packets, as well as truncated actuality values ​​transmitted in data packets, for example, Fig. 4 Steps and devices of an embodiment according to the invention (transmitter and receiver side), Fig. 5 in an embodiment according to the invention, exemplary values ​​of messages and message authentication codes contained in four data packets, as well as intermediate values ​​of the calculations not transmitted in data packets, for example.

[0013] Fig. 1 shows schematically simplified to some embodiments of the invention, how generally in a network (e.g. a bus BU, in particular a CAN bus and / or LIN bus and / or other bus system) in a motor vehicle (e.g. car or truck) data packets DP1, DP2, DP3, DP4 (e.g. in particular PDUs or Protocol Data Units or in particular in a CAN bus also frames, in particular data frames) are transmitted from a bus participant SG7 sending the data packets DP1, DP2, DP3, DP4 to a bus participant SG6 of the bus system BU (with several bus participants / ECU SG1 - SG10) receiving the data packets DP1, DP2, DP3, DP4, which data packets DP1, DP2, DP3, DP4 are used, for example, to control a motor Mot (connected to a bus participant) or door opener TOeff1, Toeff2 or to Can be used to transmit data from a sensor, etc.

[0014] The structure of data packets DP1, DP2, DP3, DP4 is described as an example of a network in the form of a CAN bus in de.wikipedia.org / wiki / Controller_Area_Network.

[0015] Fig. 2 illustrates in general and simplified terms the use of message authentication codes (Message Authentication Codes) MAC (abbreviated to CMAC) for a sending bus participant SG7 to ensure the integrity of a transmitted data packet DP1, DP2, DP3, e.g. similar to a checksum, i.e. to enable the authentication check of the transmitted data packets DP1, DP2, DP3, DP4 at their receiving bus participant SG6.

[0016] A Message Authentication Code (MAC), known e.g. from de.wikipedia.org / wiki / Message_Authentication_Code ) is generated from the message MSG (e.g. the user data to be transmitted and / or the DATA field in a data packet) with the length M bytes (bytes, for example, each comprising 8 bits; M, for example, = 8), namely with a (e.g. symmetric) encryption method f (e.g. AES-128) using a secret key KEY (known to the sending bus participant SG7 and the receiving bus participant SG6) and a freshness value FV (e.g. in the form of a (message) counter or timestamp), thus simplifying: MAC = f MSG , FV , Key

[0017] For example, the following is transmitted from a sending bus participant SG7 to a receiving bus participant SG6 in a data packet DP1 (or DP2 or DP3 or DP4 or DP0): the (payload) message MSG of byte length M itself (e.g. unencrypted), as well as a freshness value FV truncated (to the byte length F), referred to as truncated freshness value or TFV after truncation (e.g. unencrypted), as well as a message authentication code MAC truncated (to the byte length N) (reference symbol Trunc) (referred to as CMAC after this truncation).

[0018] M, F, N are natural numbers, e.g. fixed values ​​for all data packets.

[0019] A transmitted message authentication code CMAC truncated (to length N) cannot be calculated without knowledge of the cryptographic key Key.

[0020] A receiving bus participant who also has this key can use the received truncated message authentication code CMAC to check the content of a message MSG for authenticity.

[0021] If data packets DG1, DG2, DG3 with the same message content MSG were transmitted repeatedly, the result would always be the same message authentication code MAC and thus also the same shortened transmitted message authentication code CMAC.

[0022] To avoid such repetitions (replay attack), the message can contain a constantly changing value (truncated timeliness value TFV), such as a sufficiently long counter (counter of the data packets DP1, DP2, DP3), timestamp (of sending a message) or random value FV, or truncated TFV.

[0023] A common method for authentication is Secure Onboard Communication (SecOC), which is described in the source [2] [Autosar] mentioned above and is used, for example, for secure real-time communication in the vehicle via CAN.

[0024] The standard SecOC procedure according to [2] provides for the resource-efficient authentication of messages (PDUs) for critical data, as well as ensuring their timeliness to protect against replay attacks. Symmetric encryption is used primarily for both the sending (TX-ECU, in Fig. 1 SG7) and the receiving RX-ECU (in Fig.1 SG-6), in particular the standard algorithm AES-128. The classic CAN bus and the CAN-FD extension are also particularly suitable as a communication medium.

[0025] Fig. 2 shows a schematic representation according to [2] for generating an authentic message using a cryptographic authenticator function. To be robust against replay attacks, the freshness value (FV) must change with each transmission, even if the message MSG is unchanging. Therefore, FV is often a monotonic counter with a sufficiently long word length, or a timestamp that represents the global time known to several or all bus participants. In this representation, both the freshness value and the calculated MAC are truncated for efficiency reasons.

[0026] In the classic CAN bus with a maximum of 8 bytes per message, Fig. 2 proceed, for example with lengths [M, F, N] = [4, 1, 3], in order not to exceed the maximum number of data bytes 8 (of a data packet DP1).

[0027] Truncation in particular requires that the receiving bus node maintain the unabridged freshness values ​​(FV), i.e., longer monotonic counters or timestamps, up-to-date or synchronized with the sending bus node. This can be problematic, for example, during a startup process (of the bus system). If the CMAC in the receiving bus node is different from the transmitted value, the entire message is discarded as inauthentic.

[0028] The alternative option of completely omitting truncation avoids problems with synchronization, but this requires a higher bandwidth or transmission time on the bus.

[0029] Fig. 3 shows in a table (copied here for simplification) an example of a standard SecOC procedure with the following lengths of the parts of a data packet DP1 in bytes: M = 4, F = 1, N = 3, and with an encryption method f (="Authenticator") in the form of AES-128, as well as with a cryptographic key Key = 0x2b7e151628aed2a6abf7158809cf4f3c. MSG Count = FV MAC TFV, CMAC 0x0000000 0 0x000000 0 0 0x 7df76b 0clab899b33e42f047b91b 546f 0x 00 7df76 b 0x0000000 0 0x000000 0 1 0x 57127d 4034b1bebfaef466b9c772 6fc6 0x 01 57 1 27 d 0x0000000 0 0x000001 0 0 0x a07335 21fefc4ce22b1981d3ec0d f91c <h2 style=";text-align:left;direction:ltr">0x<h2 style=";text-align:left;direction:ltr"> 00 <h2 style=";text-align:left;direction:ltr"> a0733 5 0x0000000 0 0x000001 0 1 <h2 style=";text-align:left;direction:ltr">0x<h2 style=";text-align:left;direction:ltr"> 82f46d <h2 style=";text-align:left;direction:ltr"> 70b372b9b226db1e6142f1 9a8b 0x 01 82f46 d

[0030] The transmitted message MSG is "0x00000000" in each case; the actuality values ​​(e.g., counter of the number of the sent data packet DP1, DP2, DP3, DP4) FV and the message authentication codes MAC and the abbreviated message authentication codes CMAC are as shown.

[0031] The example in Fig. 3 shows for the constant message MSG = 0 different values ​​of the shortened message authentication codes CMAC (with the length N = 3 bytes each), which are caused by the change of the freshness value FV (counter or timestamp).

[0032] This effectively prevents replay attacks, and authenticity is ensured by the knowledge of the secret key in both the sending and receiving bus nodes. Truncation ensures that only the lower byte of TFV is transmitted (because F = 1), ensuring the information about the higher bytes of FV is secured through additional synchronization.

[0033] In addition to a monotonic counter, a timestamp encoding global time, e.g., the number of seconds since January 1, 2019, is also suitable as a freshness value. This resolution would be suitable for messages that are to be authenticated or time-locked in a second cycle; the timestamp would only overflow after approximately 136 years.

[0034] Due to the frequency tolerances of common oscillators, sufficient synchronicity of the global time in the network must be ensured frequently by additional communication, even when using timestamps.

[0035] Methods and devices according to the invention show alternative procedures for this purpose.

[0036] Embodiments of the invention are described below.

[0037] Fig. 4 shows some embodiments of the invention, how (in step S1) a bus participant SG7 sending (a data packet such as DP1) can generate a message authentication code CMAC, which is also to be included in the data packet DP1, from the (payload) message MSG to be included in the data packet DP1 before sending, how (in step S2) a data packet DP1 (containing in particular or only the message MSG and the message authentication code CMAC) can be transmitted from a (DP1, DP2, DP3, DP4 etc.) sending bus participant SG7 to a (DP1, DP2, DP3, DP4 etc.) receiving bus participant SG6 via a network, in particular a (CAN etc.) bus system BU, how (in step S3) a bus participant SG6 receiving (a data packet such as DP1) can generate a message authentication code CMAC from the message MSG contained in the received data packet DP1 and the (also contained in DP1)

[0038] Message authentication code CMAC can be used to perform an authentication check of the data packet DP1.

[0039] In step S1Before sending the message MSG (payload data) to be included in the data packet DP1, a bus participant SG6 (a data packet such as DP1) generates a message authentication code CMAC, which is also included in the data packet DP1, by an encrypted message code CMAC1 is generated from the message MSG using a first encryption method (BC1) implemented in a first encryption device BC1 by means of a first key K1, an encrypted count value CPYH is generated from a count value Count++ (in particular a counter of sent / received messages DP1, DP2, DP3, DP4 or a timer value of a timer) using a second encryption method (BC2) implemented in a second encryption device BC2 by means of a second key K2, a message authentication code CMAC (to be transmitted via the bus system BU) is generated from the encrypted message code CMAC1 and from the encrypted count value CPYH by means of an "exclusive-OR" (= X-OR) operation X with an (XOR) operation device X.

[0040] Formulas to clarify the encryption (before sending a data packet) on the part of the sending bus participant SG7 can be, for example, the following: CMAC 1 = BC 1 MSG , K 1 CYPH = BC 2 Count , K 2 CMAC = CMAC 1 ⊕ CYPH

[0041] An embodiment of the invention can be implemented on the transmitter side as a method or device according to S1.

[0042] An embodiment of the invention can be implemented on the receiver side as a method or device according to S3.

[0043] An embodiment of the invention can also be implemented as a method or device according to S1+S2+S3 in combination.

[0044] In step S1, the generation of a replay-proof CMAC in the sender is proposed. BC1, for example, is a block cipher algorithm for generating a CMAC1 from an M-byte MSG message with a key K1. BC2, for example, is a block cipher algorithm with a key K2 and a counter that increments upon each transmission, with a block length N that is equal to the length of the CMAC1, for example, N = 4, BC1 = AES, BC2 = SIMECK.

[0045] In step S2 The (one or more) data packets DP1 generated in this way (containing in particular or only the message MSG and the message authentication code CMAC) are transmitted from a (DP1, DP2, DP3, DP4, etc.) sending bus subscriber SG6 to a (DP1, DP2, DP3, DP4, etc.) receiving bus subscriber SG6 via a network, in particular a (CAN, etc.) bus system BU.

[0046] In step S3The authentication check of the data packet DP1 can be carried out by a bus participant SG6 receiving a data packet such as DP1 from the message MSG contained in the received data packet DP1 and the message authentication code CMAC (also contained in DP1) with a further first encryption device BC1 (e.g. the same as the BC1 in the transmitter SG7), an XOR linking device X, a decryption device BC2 -1< (BC2 to the power of minus one working inversely to the encryption device BC2) and a comparison device VG (e.g. taking into account a threshold value of e.g. 1 or 2 or 3 or 4 or 5 or more for a count value difference RX-Count[n] minus RX-Count[n-1 ]).

[0047] In step 3, an encrypted message code CMAC1 is generated from the message MSG contained in the data packet DP1 received (from the receiving bus subscriber SG6) by the first encryption device BC1 (another one, e.g. working in the same way as BC1 at the sender) using the key K1 (secret, e.g. asymmetric or symmetric and / or the same as that known at the sender SG7). The intermediate value CIPH is generated from the message authentication code CMAC contained in the received data packet DP1 and the encrypted message code CMAC1 using an (XOR) linking device X.

[0048] From the intermediate value CIPH, a current received message count value RX-Count[n] is generated by a decryption device BC2 -1< (BC2 to the power of minus one, for example, works inversely to the encryption device BC2), from which a previous received message count value RX-Count[n-1] (n= number of the currently received message DP1, so currently n=1) is subtracted by a subtraction device Sub (correspondingly determined for the data packet DP0 received before the data packet DP1).

[0049] The difference between the current received message count RX-Count[n] and the previous received message count RX-Count[n-1] is compared by a comparison device VG with one or with a threshold value S, and if the difference is one or less than the threshold value S, the received data packet DP1 is defined as authenticated, but if the difference is greater than one or greater than the threshold value S, the received data packet DP1 is defined as unauthenticated.

[0050] The step S3 or the devices in Fig. 4 Below is a schematic representation of the authentication of a replay-proof CMAC in the receiver SG6. BC1, for example, is a block cipher algorithm for generating a CMAC1 from an MSG message with the key K1. BC2, for example, is a block cipher algorithm with the key K2. The current receive counter RX-Count[n] is checked, for example, against the last receive value RX-Count[n-1] for a tolerance range 0 < RX-Count < S that is acceptable for authentication.

[0051] The threshold value S can be set to a higher value (e.g. S = 2...5) than in normal operation (e.g. S = 1) during or after restart, in particular reboot (e.g. of the network / bus system BU).

[0052] The encryption device BC1 and the encryption device BC2 can, in particular, be different from one another or can also be the same. The encryption methods BC1, BC2 can, in particular, be different from one another or can also be the same. The keys K1, K2 can, in particular, be different from one another or can also be the same. On the part of several or all bus participants (e.g. SG6, SG7), the encryption device BC1 and the encryption device BC2 are expediently the same, the encryption methods BC1, BC1 are the same, the keys k1 and the keys k2 are the same, in particular if symmetric encryption is used; if, however, asymmetric encryption is used, the encryption and decryption on the part of all participants are expediently compatible with one another.

[0053] Formulas to illustrate the encryption, decryption and authentication check on the part of the receiving bus participant SG6 can be, for example, the following: CMAC 1 = BC 1 MSG , K 1 CYPH = CMAC ⊕ CMAC 1 RX − Count = BC 2 − 1 CYPH , K 2

[0054] Instead of the more conventional procedure discussed in accordance with Fig. 2-3 used for the actuality value or freshness value "FV", the reference symbol "Count++" is used to distinguish the count value in the description of exemplary embodiments according to the invention.

[0055] For example, a counter that increments at each transmission can be used to generate the count value Count++, with e.g. a block length N equal to the length of the transmitted message authentication code CMAC1, e.g. N = 4, BC1 = AES, BC2 = SIMECK an encrypted count value CYPH.

[0056] Fig. 5 shows an example of the values ​​in a table (copied here for simplification) which can be used for methods and / or devices according to an embodiment of the invention, e.g. Fig 4 in data packets DP1, DP2, DP3, DP4 each contain the message MSG, the message authentication code CMAC, the encrypted message code CMAC1 (not contained in DP1), the count value Count++ (not contained in DP1) and the intermediate value CIPH (not contained in DP1): M = 4, N = 4, BC1: AES-128, BC2: SIMECK32 [3] K1 = 0x2b7e151628aed2a6abf7158809cf4f3c K2 = 0x1918111009080100

[0057] The MSG CMAC1 Count CIPH CMAC 0x00000000 0x0c6bf77d 0x00000000 0x20dd44f0 0x2cb6b38d 0x00000000 0x0c6bf77d 0x00000001 0x2b3ec7e7 0x2755309a 0x00000000 0x0c6bf77d 0x00000100 0x8a48dfef 0x86232892 0x00000000 0x0c6bf77d 0x00000101 0x1a54d0ef 0x163f2792

[0058] Example in Fig. 5 For a constant message MSG=0, as expected, it also shows constant CMAC1 values, which are not transmitted, however. However, different CMAC values ​​result from changes in the counter value (Count+++) of a message counter (on the part of a sending bus device SG7 for data packets DP1, DP2, DP3, DP4 sent by it (e.g., since the last bus reset and / or via the data bus, etc.), and / or on the part of a receiving bus device SG6 for data packets DP1, DP2, DP3, DP4 received by it (e.g., since the last bus reset and / or via the data bus), or a timer.

[0059] The CMAC values ​​are transmitted, effectively preventing replay attacks, and authenticity is ensured by the knowledge of the secret key in both the sender and the receiver. In contrast to, for example, Fig. 2 , 3With a common procedure, the counter is not truncated, so no additional synchronization is necessary.

[0060] Due to the longer counter and CMAC values ​​in the method according to the invention compared to the standard SecOC method, security against brute-force attacks can be increased. Furthermore, a freely selectable tolerance S can be specified in the receiver, which allows a tolerance for counter deviations during bootup, for example, so that a counter deviation greater than 1 is permissible immediately after bootup.

[0061] A possible additional advantage is the potential savings in computing time for constant messages, which is often the case in automotive or IoT applications. The message-dependent CMAC1, for example, can then be calculated in advance, while the counter-dependent value CIPH can be used, for example, with a lightweight block cipher method with lower runtime and resource requirements.

[0062] A common standard CMAC algorithm BC1 is currently AES-128, which is supported in hardware by larger controllers. Depending on the networks used or on-ECU communication (LIN, CAN, CAN-FD, SPI, I2C) [1], various LW block cipher algorithms can be considered for the various µCs. Examples include algorithms from the SIMECK family [3]: µC M N BC1 BC2 Classic CAN 4 4 AES SIMECK32 (4 byte block support) CAN-FD (1) 8 4 AES SIMECK64 (8 byte block support) CAN-FD (2) 60 4 AES SIMECK64

[0063] Abbreviations used can have the following meaning: BCBlockcipher Algorithmus CAN, CAN-FDController Area Network, CAN Flexible Datarate CMACCryptographic Message Authentication Code Count"Freshness"-Counter CYPHCiphertext HSMHardware Security Module LINLean Information Network LWLightweight MSGMessage SecOCSecure Onboard Communication

Claims

1. Method for generating (K1, K2, BC1, BC2, X) at least one data packet (DP1, DP2, DP3, DP4) to be transmitted in a bus system (BU), in particular of a motor vehicle (Kfz), wherein (S1) before transmitting the at least one data packet (DP1) containing the message (MSG) to be included in the data packet (DP1) a bus subscriber (SG7) transmitting the data packet (DP1) uses a first encryption apparatus (BC1) to generate a message authentication code (CMAC) that is likewise to be included in the data packet (DP1), the message authentication code (CMAC) being generated by - using a first encryption method (BC1) to generate an encrypted message code (CMAC1) from the message (MSG) by means of a first key (K1), characterized in that - a second encryption method (BC2) is used to generate an encrypted count (CYPH) from a count (Count++) by means of a second key (K2), and - a logic operation (X) is used to generate the message authentication code (CMAC) to be transmitted from the encrypted message code (CMAC1) and from the encrypted count (CYPH), wherein the message authentication code (CMAC) to be transmitted is generated from the encrypted message code (CMAC1) and from the encrypted count (CYPH) by way of a logic "Exclusive-Or" operation (X).

2. Method according to Claim 1, characterized in that the count (Count++) is either a value, generated using a counter (Za), that represents the number of messages (DP1, DP2, DP3, DP4) transmitted and / or received via the bus system (BU) hitherto, in particular since the last restart of the bus system (BU), or a timer value, of at least one timer (Ti), that is available in particular on multiple or all bus subscribers (SG1..SG10).

3. Method for authentication checking (K1, K2, BC1, X, BC2-1 , Sub, VG) at least one data packet (DP1, DP2, DP3, DP4) received via a bus system (BU), in particular of a motor vehicle (Kfz), in particular a data packet (DP1, DP2, DP3, DP4) that was previously generated (SG7) according to one of the preceding claims, wherein (S3) a bus subscriber (SG6) receiving at least one data packet (DP1) - uses a first encryption method (BC1) to generate an encrypted message code (CMAC1) from the message (MSG) contained in the received data packet (DP1) by means of a first key (K1), - generates an intermediate value (CIPH) from the transmitted message authentication code (CMAC) also contained in the received data packet (DP1) and from the generated encrypted message code (CMAC1) using a logic device (X), characterized in that - a decryption device (BC2-1) is used to generate a current received message count (RX-Count [n]) from the intermediate value (CIPH) by way of a decryption (BC2-1), - the current received message count (RX-Count [n]) is compared (VG; S) with a preceding received message count (RX-Count [n-1]) determined for a data packet (DP0) received before the data packet (DP1), - the difference between the current received message count (RX-Count [n]) and the preceding received message count (RX-Count [n-1]) is taken as a basis for defining the received data packet (DP1) as authenticated or as unauthenticated, wherein the message authentication code (CMAC) to be transmitted was generated from the encrypted message code (CMAC1) and from the encrypted count (CYPH) by way of a logic "Exclusive-Or" operation (X).

4. Method according to the preceding claim, wherein the difference between the current received message count (RX-Count [n]) and the preceding received message count (RX-Count [n-1]) is taken as a basis for defining the received data packet (DP1) as authenticated or as unauthenticated by regarding the received data packet DP1 as unauthenticated only if the difference is greater than one or greater than a threshold value (S), the threshold value (S) preferably being set to a higher value (S = 2 ... 5) after a restart of the bus system (BU) than in other normal operation (S = 0; S = 1).

5. Method according to either of the two preceding claims, wherein a logic Exclusive-Or operation (X) is used to generate an intermediate value (CIPH) from the transmitted message authentication code (CMAC) also contained in the received data packet (DP1) and from the generated encrypted message code (CMAC1) using a logic device (X).

6. Method according to one of the preceding claims, characterized in that multiple bus subscribers (SG1..SG10) of the bus system (BU), in particular a bus subscriber (SG6) receiving a data packet (DP1) and a bus subscriber (SG7) transmitting a data packet (DP1), use the same first encryption method (BC1) and / or the same first key (K1) and / or the same second encryption method (BC2) and / or the same second key (K2).

7. Method according to one of the preceding claims, characterized in that multiple bus subscribers (SG1..SG10) of the bus system (BU), in particular a bus subscriber (SG6) receiving a data packet (DP1) and a bus subscriber (SG7) transmitting a data packet (DP1), derive the second key (K2) from the result CMAC1 of the first encryption method (BC1).

8. Method according to Claim 1 or 2-6, characterized in that a timer value (Count++) representing time information relating to the global time is securely (authentically, confidentially) distributed in the network from one subscriber (e.g. SG7) to all other subscribers (SG1..SG10).

9. Apparatus comprising a first encryption apparatus (BC1), a second encryption apparatus (BC2), and a logic device (X), in particular for carrying out the method according to one of the preceding claims, for generating (K1, K2, BC1, BC2, X) at least one data packet (DP1, DP2, DP3, DP4) to be transmitted in a bus system (BU), in particular of a motor vehicle (Kfz), wherein a first encryption apparatus (BC1) is provided by a bus subscriber (SG7) transmitting the data packet (DP1) and is designed so as, before transmitting the at least one data packet (DP1), to generate from the message (MSG) to be included in the data packet (DP1) a message authentication code (CMAC) that is likewise to be included in the data packet (DP1) to be transmitted, wherein, for this purpose, on the transmitting bus subscriber (SG7): - the first encryption apparatus (BC1) is designed to use a first encryption method (BC1) to generate an encrypted message code (CMAC1) from the message (MSG) by means of a first key (K1), characterized in that - a second encryption apparatus (BC2) is designed to use a second encryption method (BC2) to generate an encrypted count (CYPH) from a count (Count++) by means of a second key (K2), and - a logic device (X) is designed to generate the message authentication code (CMAC) from the encrypted message code (CMAC1) and from the encrypted count (CYPH) by way of a logic operation (X), wherein the message authentication code (CMAC) to be transmitted is generated from the encrypted message code (CMAC1) and from the encrypted count (CYPH) by way of a logic "Exclusive-Or" operation (X).

10. Apparatus comprising a first encryption apparatus (BC1), a second encryption apparatus (BC2), and a logic device (X), in particular according to the preceding claim and in particular for carrying out the method according to one of the preceding method claims, for authentication checking (k1, k2, BC1, X, BC2-1, Sub, VG) at least one data packet (DP1, DP2, DP3, DP4) obtained via a bus system (BU), in particular of a motor vehicle (Kfz), wherein (S1) on a bus subscriber (SG6) receiving at least the data packet (DP1) - a first encryption apparatus (BC1) is designed to use a first encryption method (BC1) to generate an encrypted message code (CMAC1) from the message (MSG) contained in the received data packet (DP1) by means of a first key (K1), - a logic device (X) is designed to generate an intermediate value (CIPH) from the generated encrypted message code (CMAC1) and from the message authentication code (CMAC) contained in the received data packet (DP1), characterized in that - a decryption device (BC2-1) is designed to determine a current received message count (RX-Count [n]) for the current data packet (DG1) from the intermediate value (CIPH), - a comparison apparatus (VG) is designed to take the difference (Sub) between the current received message count (RX-Count [n]) and a preceding received message count (RX-Count [n-1]) determined for a data packet (DP0) received before the data packet (DP1) as a basis for defining the received data packet (DP1) as authenticated or as unauthenticated.

11. Apparatus according to either of the two preceding claims, characterized in that the bus system is a CAN bus or a CAN FD bus or a LIN bus or an SPI bus or an I2C bus and / or is provided for communication between ECUs.