Transport layer authenticity and security for automotive communication

Abstract

Transmitter (S) configured to participate in a vehicle-internal network (1), wherein the transmitter (S) is configured to: - Receiving a request to transfer user data (21); - In response, generate a first header (251) in the transport and / or network layer; - Accessing a key K with a length of k bytes, - Generating an authentication tag (233) using the key K and at least the first header (251) as additional authentication data (AAD), wherein the authentication tag (233) is intended to indicate the authenticity of a first frame (25) in the transport and / or network layer as an original frame sent by the sender (S) to a receiver (R), and - Generating the first frame (25) which includes the first header (251), transport layer payload (232) generated using the payload (21), and the authentication tag (233); - Forwarding the first frame (25) to the data link layer, wherein the data link layer generates a second frame (27) on the data link layer and emits the second frame (27) to the vehicle internal network (1), wherein the second frame is a CAN (Controller Area Network) protocol frame.

Description

AREA

[0001] The present disclosure relates to authentication and security in the transport layer or network layer in vehicle networks. BACKGROUND

[0002] In today's vehicles, data integrity and security have become essential. In the past, steering was achieved through a physical connection between the steering wheel and the vehicle's wheels. The same applied to braking and gear shifting. Today's vehicles no longer have this physical connection; instead, an electrical wire or bus communicates the steering command to the electric power steering system. In response to the steering command via the bus, the electric power steering system will rotate the wheels in accordance with the steering wheel's rotation.

[0003] Gaining access to the bus can allow the insertion of malicious bus communication or commands in an attempt to take over a vehicle's functions. The risk of inserting malicious bus commands is further increased with the growing entertainment functionality and connectivity in today's vehicles.

[0004] For autonomous vehicles and cars, the risk is even higher, as sensor data analyzing the car's surroundings, as well as commands to actuators controlling the vehicle, can be transmitted via bus communication. Patent application US 2016 / 0323312A1 describes how secure access to a LAN (local area network) can be designed. In this process, a new participant communicates with an authorization unit using the IEEE 802.1X protocol. The document "Kent, S., et al.: Security Architecture for the Internet Protocol, Network Working Group, Request for Comments 4301, December 2005, pp. 1-5, 9-10, 98" describes security services for the IP (Internet Protocol) layer. In "Kent, S.: IP Authentication Header, Network Working Group, Request for Comments 4302, December 2005, pp. 1-5, 9, 11, 13, 20-21", a header for IP data frames is described. The document "Madson, C., et al.The article "The Use of HMAC-MD5-96 within ESP and AH, Network Working Group, Request for Comments 2403, November 1998" describes the use of an HMAC algorithm together with an MD5 algorithm. Wikipedia describes the OSI model in the article "OSI model, July 22, 2019, URL: https: / / de.wikipedia.org / w / index.php?title=0SI-Modell&oldid=190650220". SUMMARY

[0005] According to one embodiment, a transmitter is configured to participate in an in-vehicle network. The transmitter is configured to receive a request to transmit user data and to generate a first header in the transport and / or network layer in response. It is further configured to access a key K with a length of k bytes and to generate an authentication tag using the key K and at least the first header as additional authentication data. The authentication tag serves to indicate the authenticity of a first frame in the transport and / or network layer as an original frame sent by the transmitter to the receiver.The transmitter is further configured to generate the first frame, which includes the first header, transport layer payload, and authentication tag, and to forward the first frame to the data link layer. The data link layer is configured to generate a second frame and to emit the second frame to the vehicle's internal network. It is understood that multiple second frames, corresponding to the first frame, can also be emitted. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The embodiments are described here with reference to the accompanying drawings. Fig. 1a illustrates an example bus connecting several junctions; Fig. Figure 1b illustrates nodes as participants in a bus on different ISO-OIS layers; Fig. Figure 2 demonstrates the generation of a CAN frame; Fig.Figure 3 illustrates a protocol framework according to the CAN standard; Fig. Figure 4 demonstrates two scenarios that motivate the distribution of the TP-Sec message into some TP-Sec frames; Fig. Figure 5 shows how a security association is derived; Fig. Figure 6 illustrates how security and / or authentication can be established at different layers; Fig. 7a shows input and output variables in a SADSE for authentication with only one sender; Fig. 7b shows input and output variables in a SADSE for authentication only with one receiver; Fig. 7c shows input and output variables in a SADSE for authenticated encryption at a sender; Fig. Figure 7d shows input and output variables in a SADSE for decryption and authentication at a receiver; Fig.Figure 8 shows one embodiment of how data can be distributed across frames. DETAILED DESCRIPTION

[0007] Fig. Figure 1a illustrates an example bus connecting several nodes: node1, node2, ..., noden. In the example from Fig. Figure 1a shows the bus as a two-wire bus system, which can conveniently be implemented as differential lines. Of course, other configurations are also conceivable. The bus system can be terminated with optional terminating resistors T1 and T2, which help to reduce reflections along the bus that typically degrade signal quality. Well-known examples of bus systems in a vehicle are CAN (Controller Area Network), CAN-FD (CAN with Flexible Data Rate), CANXL (CAN X-Large), and LIN (Local Interconnect Network) networks.

[0008] It goes without saying that the in Fig.The bus shown in Figure 1a can also be arranged in a ring topology, in which both ends of the bus are fed to a (not shown) master unit, thus forming a bus loop. In this case, the individual nodes node 1, 2, ..., n are coupled to the bus in a similar way.

[0009] Vehicle networks or bus-based communication systems (as in Fig. (1a) exhibit specific attributes that reflect requirements for in-vehicle networks. The in-vehicle network supports communication of sensor data to a control unit via data frames transmitted from the sensor or a sensor controller to a higher-level control unit. A suitable protocol can be used for the data frames or protocol frames communicated between individual nodes or participants in the bus-based communication network.

[0010] In response to or as a reaction to receiving sensor data, the sensor's controller or the higher-level control unit can send a specific command to an actuator connected to the bus, for example, a braking command to a brake actuator. In the example from Fig. 1a. Node 1 could represent an angle sensor (not shown) that measures the angle at which a brake pedal is depressed. This angle information can be transmitted in (a) a protocol frame to the ECU (Electronic Control Unit) at a higher level, for example, node 2. In response to receiving the angle value, the ECU can send one or more frames over the bus to node n, the brake actuator. These frames sent by the ECU to the brake actuator trigger a braking action.

[0011] It goes without saying that bus communication regarding a braking action is time-critical and must be transmitted quickly. Such real-time requirements are not common in standard communication networks.

[0012] In-vehicle communication networks typically have a well-defined number of bus participants that, by default, remain constant throughout the vehicle's lifetime, barring any vehicle upgrades. Similarly, connections exist between individual nodes, which is why the topology of the bus-based communication system does not change over the vehicle's lifetime. Such a situation is highly unlikely for a standard computer network. In fact, standard computer networks require the ability to add or remove nodes during network operation. Furthermore, new connections can be added or existing connections removed during operation in standard computer networks.

[0013] In in-vehicle networks (IVN), it is important to ensure the authenticity of a protocol frame transmitted over the bus.

[0014] It is understood that specifying the authenticity of a protocol frame in a transport or network layer is of interest in order to reduce the involvement of higher protocol layers in the authentication of time-critical commands communicated between participants in the bus-based communication system.

[0015] As more and more entertainment systems and vehicle-to-vehicle communications become available today, there is an increased vulnerability to injected malicious commands or protocol frameworks.

[0016] It is therefore of interest to provide data security for protocol frames to prevent the injection of malicious protocol frames. Regarding the authentication of protocol frames, it is advantageous to provide data confidentiality at the transport or network layer. This eliminates the need for higher protocol layers or software stacks to provide security and / or authentication information. It is obvious to a professional that data security and authentication functions can be supported by hardware elements, such as a transmitter or receiver. In other words, data security and authentication functions can be delegated to dedicated hardware at the transport or network layer. Of course, data security may not be limited to protocol frames at the transport and / or network layer.Additional security measures can be provided at a higher or lower level without leaving the scope of protection of the invention.

[0017] Fig. Figure 1b illustrates node 1 and node 2 as participants in a bus-based communication system, as shown in Fig. Figure 1a illustrates this. Communication between node 1 and node 2 flows through different layers, which can be categorized according to the well-established OSI / ISO layer model. The lowest layer is the physical layer, designated PHYS for node 1 and node 2. Each layer in the OSI model accepts a command from a higher layer, performs some action at its level, and can trigger tasks at a lower layer by forwarding a request to the layer below it.

[0018] The top layer in the OSI-ISO model is application layer 7, which describes a function of the nodes, abstracting away the details of the communication. An application might be the determination that a braking command should be initiated and sent to another node. The details of how this communication is carried out are not part of the application layer. Instead, the command is passed on to presentation layer 6.

[0019] There are known concepts for the authenticity of data communication in vehicles at the application layer in layer 7 of the OSI-ISO layer model using a software stack, such as App1, App2 for node 1 and node 2 respectively. Fig.1b is specified. It may be practical to introduce a concept of virtual channels between Node 1 and Node 2 to specify authenticated and / or secure communication between two or more participants using the software stacks App@Node1 and App@Node2.

[0020] An example of providing security for vehicle electrical systems using software stacks is SEC-OC (SECure OnBoard Communication) according to the AUTOSAR (AUTomotive Open System Architecture) standard. It can be convenient for automakers to specify the software stack application for node 1 and node 2, allowing flexibility in the hardware implementation of node 1 and node 2. However, as a trade-off, authenticity and / or data security using a software stack may no longer meet real-time requirements for the time between a command from the electronic control unit (ECU) and a response from an actuator, as defined by node n in the standard. Fig. Figure 1a shows the system participating in the bus-based communication system. For example, a braking command is considered, which is sent within a framework from the control unit ECU – designated as node 2 in Fig.1a is shown - at the brake actuator in node n in Fig. 1a is sent. If such communication needs to be authenticated and secured using the software stack, all layers for a single node will be involved, which can take too long for a time-critical braking operation.

[0021] Another disadvantage of a software stack authentication and / or data security solution can stem from improperly designed software stacks, which can degrade or even compromise the authenticity and / or confidentiality functionality.

[0022] A command to the physical layer can be received by the data link layer, as indicated by the downward arrow between the physical layer and the data link layer. As a layer function, the physical layer of node 1 can use a connection or link to node 2 to communicate data at the physical layer to node 2. Under the same token, node 1 can receive data from node 2 via the physical link between node 1 and node 2 and further forward the received data to the data link layer above the physical layer. The upward arrow between the physical layer and the data link layer of node 1 in Fig. 1b specifies this forwarding. The protocol flow in node 2 is analogous to that described for node 1.

[0023] Some existing bus-based communication networks in vehicles do not follow the separation of the physical layer and the data link layer as proposed in the OSI-ISO model. To represent this special case, a transmitter S and a receiver R are used in Fig. 1b is represented as extending across the physical layer PHYS and the data link layer.

[0024] If an authentication and / or encryption function is integrated at lower levels of the OSI-ISO stack, the speed of authentication can increase and / or communication can become more secure because it is less vulnerable to attacks on the software at the nodes.

[0025] Therefore, depending on the circumstances, it is interesting to consider the functionality regarding authenticity and / or data security for a transport and / or network layer of an individual participant in the communication system, such as in node 1 or node 2. Fig.1b. It is possible to integrate these functions even at a lower layer, the data link layer 2. However, the integration of authentication and / or security functionality at data link layer 2 may be limited by the length of the protocol layer frames. The frames provided at the data link layer may be too short to efficiently and securely integrate security and / or authentication information. If each frame at the data link layer carries 8 bits of payload, it would be inefficient to use a large portion of this payload for authentication. In one example, the payload of a classic CAN frame is up to 8 bytes long. Using less than 4 bytes of this payload for authentication would increase vulnerability to brute-force attacks.

[0026] In modern CAN bus architectures, frames of varying lengths can be transmitted over the bus. In particular, the modern CAN FD and CANXL protocols support longer CAN frames. This would make it possible to integrate security and / or authentication data at the data link layer without sacrificing too much efficiency. However, shorter CAN frames will also appear on the bus. Firstly, older devices that only support classic CAN will still be in use. Furthermore, it is undesirable to have long frames occupying the bus for extended periods. Urgent messages cannot be transmitted quickly if a few long messages interfere with bus communication among other participants. Accordingly, the average frame length will likely be limited.

[0027] Accordingly, we propose integrating the security and / or authentication functions at the transport layer and / or the transport layer.

[0028] Frames for which no authenticity is established can be discarded at the receiver's transport or network layer. If an authenticity test shows that a protocol frame did not originate from the specific sender and / or does not arrive at the receiver in its original form, the frame can be discarded without further processing. Flooding a participant in the bus-based communication system with invalid or unauthenticated frames should only affect that single node at the transport or network layer, while higher protocol layers remain unaffected. Such a limitation of authenticity and / or data security could not be implemented for a software-stacked approach to authenticity and / or data security.

[0029] Furthermore, it is practical to use dedicated hardware elements. Specifically, a sender in the transport and / or network layer and / or a receiver in the transport and / or network layer can implement authenticity and / or data security as a dedicated hardware element. This would have the further advantage that such a component could be used as a standard circuit without requiring further modifications if bus participants or software applications change over time.

[0030] Now, with attention to Fig.Figure 2 demonstrates the generation of a CAN frame. The client 20, which is an application in ISO / OSI layer seven, transmits TP data 21 to the TPsec engine 22. The TP data 21 can comprise a sequence of bits, which may be an encoded special instruction. The TPsec engine 22 generates a TPsec message 23, which includes a TPsec tag 231, the payload TP data 232, and an authentication tag 233.

[0031] The TPsec tag 231 can include a sequence number, a secure channel ID, and cryptographic information. The cryptographic information defines, for example, which cipher suites are used or which mode is employed.

[0032] The utility TP data 232 is generated by encoding the TP data 21 using, for example, AES (Advanced Encryption Standard).

[0033] The authentication tag 233 can represent an authentication indication that the CAN-TP frame 25 should be transmitted from a sender S to a receiver R. In some embodiments, the authentication tag 233 also allows verification of whether the transmitted frame has been modified on its way to the receiver. The CAN-TP frame 25 is also referred to as the first frame.

[0034] While the security tag authentication tag 233 is shown downstream of the utility TP data 232, it can also be located upstream of the utility TP data 232 or even be integrated into the standard header H.

[0035] It is understood that a secret key K is necessary for authentication, encryption, and decryption. Key development is not the focus of this disclosure for several reasons:

[0036] Firstly, in an automotive environment, the number of participants in a bus-based communication system is limited and hardly changes over the vehicle's lifetime. It can be practical to use a key K of length k for all participants in the bus communication system.

[0037] If individual nodes connected via the bus communication system were to use an individual key, this individual key could be stored in the respective nodes of the bus-based communication system during vehicle production. There could be a first key K1 for communication between node 1 and node 2, stored at both nodes, and a second key K2 for communication between node 1 and node 3, stored at both nodes, and so on. It is assumed that the sender S and receiver R use the same key K, therefore decryption, encryption, authentication, and verification should be symmetrical.

[0038] If more than one key K is used within the system, it may be useful to have information regarding the key(s) K involved in authentication and / or data security stored or specified in an optional security information field (not shown here), SecInf. Another option is to use the security information field to indicate whether the given protocol frame 100 is an authenticated protocol frame only or an authenticated and encrypted protocol frame 100.

[0039] The TP-Sec-Tag 231 field is another optional element. It can contain the sequence number 72, which is a once-used integer also known as a nonce. If the sequence number 72 changes in a way unknown to an listening party, it helps prevent replay attacks from succeeding.

[0040] The simplest implementation of authentication and / or data security at the data link layer is a scheme with authentication only, using a frame including the sequence number in the TP-Sec tag 231 if replay protection is required. If such protection is not necessary, the TP-Sec tag 231 can be omitted, allowing for larger TP data 232.

[0041] The TP-Sec message 23 is passed to the CAN-TP unit 24 and generates one CAN-TP frame 25 or several CAN-TP frames 25.1, ..., 25.n, where n is an integer greater than one. The generation of the CAN-TP frame can be performed according to the ISO 15765-2 standard, also known as ISO-TP. The protocol allows the transport of messages that exceed the maximum payload of eight bytes of classic CAN frames. ISO-TP can prepend one or more metadata bytes to the payload in a classic 8-byte CAN frame, thereby reducing the payload to seven or fewer bytes per frame. ISO-TP segments longer messages into multiple frames, adding metadata that allows the receiver to interpret individual frames and assemble them into a complete message packet. It can support up to 2 32Each message packet carries bytes of payload data. The metadata is referred to as protocol control information, or PCI (Protocol Control Information). The PCI is one, two, or three bytes. The initial field is four bits long, specifying the frame type and implicitly describing the PCI length.

[0042] The CAN-TP frame 25 contains the TP payload 252, which includes the CAN-TP header 251, the TP-Sec tag 231, the payload TP data 232, and the authentication data 233. The CAN-TP header 251 contains the PCI protocol control information.

[0043] If the TP-Sec message 23 becomes too long to be transmitted over the CAN bus in a single CAN frame, multiple CAN-TP frames 25.1 to 25.n are produced, where n is an integer greater than one. Each of the multiple CAN-TP frames has a CAN-TP header 251. Each frame carries a portion of the totality of the TP-Sec tag 231, the payload TP data 232, and the authentication tag 233. In the example from Fig. 2. The first CAN-TP frame 25.1 carries the TP-Sec tag 231 and the first part of the payload TP data 232. The second CAN-TP frame 25.2 carries the second part of the payload TP data 233. The last CAN-TP frame 25.n carries at least part of the payload TP data 232 and the authentication tag 233.

[0044] The CAN transfer block 26 generates a CAN frame 27, which can also be referred to as a second frame. The CAN frame 27 comprises a header 272, payload 272, which carries the TP payload 252, and a frame end part EOF. Fig.Figure 3 illustrates a protocol frame according to the CAN standard. The CAN frame begins with a header H containing an 11-bit arbitration field, followed by a 7-bit control field. Both the arbitration field and the control field are parts of the CAN frame with a bit length comparable to a full byte. It is noted that the arbitration field can be 29 bits long according to the CAN and CAN-FD standards, which are variants of the CAN standard, as mentioned earlier.

[0045] The 8-byte data field corresponds to the payload P of an original protocol frame. A 15-bit CRC field, together with an acknowledgment slot bit, an acknowledgment limit bit, and 7 bits of a frame end, corresponds to the frame end part EOF of the protocol frame.

[0046] In a vehicle environment, simultaneous operation of older and newer devices using different protocol variants is likely. For example, older devices, such as ABS sensors, might communicate using an early variant of the protocol, such as the classic CAN protocol, while newer devices, such as a LiDAR system, might communicate with an electronic control unit using the CAN FD standard or even the CANXL standard. It can therefore be useful to specify the different protocol types in the header H, as this would affect the level of authenticity and / or data security applicable to a single protocol frame. In such circumstances, it may be important to know that the total frame length of N bytes or bits is stored or encoded elsewhere within the protocol frame.Setting a frame length flag would be one option for how the frame length could be encoded. How such information could be stored in the protocol frame can be found in the protocol specification.

[0047] The framework end indication EOF may also include fault checking information as is known in the technology and is therefore not explained further at this time.

[0048] Now back to Fig. 2. The payload 272 of the CAN frame is taken from the CAN-TP frame 25 or from one of the CAN-TP frames 25.1 to 25.n. The payload 272 is referred to as TP payload. In cases with multiple CAN-TP frames, each of the CAN-TP frames 27.1 to 27.n carries payload 272.1, 272.2, or 272.n from one of the CAN-TP frames 25.1, 25.2, ..., 25.n.

[0049] The bits of the CAN frame are output as a voltage-level signal (V29) to the wires on a CAN bus. The CAN bus can, for example, consist of two copper wires, designated CAN_HIGH and CAN_LOW. ISO 11898-2, also known as high-speed CAN (bit speeds up to 1 Mb / s on CAN, 5 Mb / s on CAN-FD), uses a linear bus terminated at each end with 120 Ω resistors.

[0050] A high-speed CAN signaling system sets the CAN high wire to 5 V and the CAN low wire to 0 V when a dominant (0) signal is transmitted, and does not set either wire to a dominant (1) signal. Designating "0" as dominant gives priority on the bus to nodes with lower ID numbers. The dominant differential voltage is a nominal 2 V. The termination resistor passively returns the two wires to a nominal differential voltage of 0 V. The dominant common-mode voltage must be within 1.5 to 3.5 V of a common-mode voltage, and the recessive common-mode voltage must be within ±12 V of a common-mode voltage. The dashed line indicates the voltage on the CAN high wire, and the solid line indicates the voltage on the CAN low wire.

[0051] If the participant is a receiver, the information flow goes in the opposite direction, from the bottom to the top. Fig.2 to its upper side. The receiver receives a signal 29, converts the signal 29 into digital values, and extracts the CAN frame 27 or the CAN frames 27.1, ..., 27.n from the digital values ​​in the data link layer. The CAN frames 27, 27.1, ..., 27.n are forwarded to the upper layers, the network layer and the transport layer, where the CAN frames 27 are transformed into TP frames 27. From the TP frames 27, the CAN TP header 251, the TPsec tag 231, the payload TP data, and the authentication tag 233 are extracted. The extracted data is fed into an authentication unit, which verifies the authentication. If the payload TP data is encrypted, it is decrypted.

[0052] Fig.Figure 4 demonstrates two scenarios that motivate the distribution of the TP-Sec message into several TP-Sec frames. It is understood that there may be more scenarios in which splitting the TP-Sec message is helpful. In the first scenario, the data length of the TP-Sec message is greater than the maximum length of the respective payload data of a CAN frame of the specific CAN protocol, which could be, for example, classic CAN, CAN-FD, or CANXL. In this case, the data of the TP-Sec message is split into several CAN-TP frames, so that each underlying CAN frame can be filled up to its maximum length.

[0053] In the second scenario, the data length of the TP-Sec message 23 is smaller than the maximum length of any given payload of a CAN frame in the specific CAN protocol. However, in the car, it is desirable to send only small chunks of data on the CAN bus to allow other devices to send their messages between these smaller CAN frames. In this case, the CAN-TP message is also split, so that each CAN frame carries a portion of the CAN-TP message's data. Each CAN frame is smaller than the maximum frame length allowed by the specific CAN protocol.

[0054] Fig. Figure 5 illustrates how a security association is derived. Fig.Figure 5 shows the CAN-TP-Sec message 23, the CAN-TP frame 25, and the CAN frame 27. As before, the CAN-TP-Sec message comprises a TP-Sec tag 231, the payload TP data 232, and the authentication tag 233. The CAN-TP frame 25 comprises the CAN-TP header 251 and the CAN-TP data that includes the CAN-TP-Sec message. The security association is established between at least two TP clients and is created by concatenating the CAN ID as part of the CAN header and the TP-Sec tag 231.

[0055] Fig. Figure 6 illustrates how security and / or authentication can be established at different layers. Four TP clients in the transport layer and two CAN participants in the data link layer are shown in Fig.Figure 6 shows that the two CAN participants are connected via a safe CAN channel. An example of such a safe CAN channel is disclosed in the simultaneously attached German patent application DE 10 2019 004 790.7, which was filed on July 11, 2019.

[0056] TP Client 1 and TP Client 2 are connected to CAN participant A because they connect to the same node, allowing them to forward and receive messages and frames between the units in the transport and data link layers. Similarly, TP Clients 3 and 4, along with CAN participant B, belong to a different node. TP Clients 3 and 4 can each forward and receive frames and messages to and from CAN participant B.

[0057] As a first option, a security association can be established between two TP clients. In this example, a security association exists between TP clients 2 and 3, and another security association exists between TP clients 1 and 4. The maximum byte length is 2. 32 and the overhead is produced per TP frame.

[0058] As a second option, the safety association can be established in the data link layer between CAN nodes. Here, the maximum length depends on the CAN standard and is 6, 64, or 2048 bytes. The overhead must be applied for each CAN frame. Furthermore, it is possible to combine both safety associations by establishing them in only one layer—the transport layer and the data link layer.

[0059] The following are examples of Protocol Framework 100 that implement different levels of authentication and / or data security in the data link layer, with reference to Fig. 7a-7e will be discussed.

[0060] A practical way to implement authentication and / or data security protection for protocol frameworks is to use so-called symmetric authentication and / or data security engines, which are implemented as hardware blocks and are also referred to as SADSE, as now described in relation to Fig. 7a-7d will be explained in more detail.

[0061] Fig.Figure 7a shows input and output values ​​for a SADSE. The naming of the SADSE's input and output variables follows a naming convention established for block cipher modes in cryptographic literature. It is understood that a SADSE can operate in AO mode (AO: Authenticity Only) or in AE mode (Authenticated Encryption). Fig. Figure 7a will demonstrate the AE mode. The SADSE accepts a secret key K, a nonce N, an input stream P of length le symbols, and additional authentication data AAD as input. The outputs are an output stream ciphertext C of length le symbols and a tag T.

[0062] The key K is conveniently a symmetric key of a certain length, e.g., 128, 192, or 256 bits. As mentioned earlier, key distribution is not the focus of this disclosure. In fact, corresponding schemes are known, such as the MACsec key agreement defined in IEEE 802.1X-2010. In some implementations, multiple keys can be used, and a SecInfo data field 72 selects which of the multiple keys is used.

[0063] The nonce is typically an integer value used only once. Depending on the circumstances, one can choose to have the same value for N for more than one generation of the SADSE output. In situations where replay protection is not necessary and the generic key K is used in the bus-based communication system, the sequence number 72 and the security information (SecInf) fields can be omitted.

[0064] The additional authentication data includes the CAN-TP header and may also include parts of the TP data 21 or the complete TP data 21.

[0065] The input stream P is fed in via TP data 21. The plaintext P is encrypted using the key. The result of the encryption is output as the ciphertext C.

[0066] Tag T is calculated based on the inputs used by SADSE. Tag T indicates whether it was intended that protocol frame 100 be sent from the named sender S to the given receiver R (both of which are typically named in the header H).

[0067] A serial number 71 specifies a unique number for the TP data 21 to be transported. The TP data 21 itself is entered into the SADSE as plaintext. The CAN TP header 251 adds additional authentication data AAD to the SADSE input. The cipher output C is used as the payload TP data 232, and the tag T is used as the authentication tag 233. Accordingly, the TP data 21 is transmitted over the bus in encrypted form. The serial number 71 and the Sec info 72 are written to the TPsec tag 231.

[0068] Now, with attention to Fig. 7b considers that the SADSE at sender S is in AO mode with authentication only, in order to authenticate a CAN-TP frame. In this mode, the input stream P is not used. The use of the key K is the same as before. The SADSE also receives the sequence number 72 and the additional authentication data AAD as input.

[0069] The additional authentication data includes the CAN-TP header 251 and can further (in Fig. 7 (not shown) parts of the TP data 21 or the complete TP data 21. If replay protection is not necessary, the protocol frame 100 may not include sequence number 72, as above in combination with Fig. As discussed in section 2b, since serial number 72 is not set, the nonce N can be left at its previously used value, set to zero, or set to any other practical value. If used, the nonce N must be identical on both the transmitter and receiver.

[0070] If only a generic key K is used as the secret key within the bus-based communication system, the CAN-TP frame 25 may not include the security info (SecInf) field.

[0071] In circumstances where replay protection is not necessary and the generic key K is used in the bus-based communication system, the sequence number 72 and the security info (SecInf) fields 72 can be omitted. As explained above, the nonce N can be left at its previously used value, set to zero, or to any other practical value. Fig. Option 7b is shown where neither serial number 71 nor Sec-Inf 72 is used. The TPsec tag 231 is not used or padded, e.g., with zeros.

[0072] If the SADSE outputs a tag T, which is calculated using the key K, the nonce N, and the additional authentication data AAD as a basis for calculation, the tag T is used in the authentication tag 233 of the CAN-TP frame.

[0073] Now, with attention to Fig.7c assumes that the SADSE at the receiver is in authentication-only mode. The receiver receives CAN frames 27.1, 27.2, 27.3 and generates CAN-TP frames from them. Fig.Figure 7c shows how the contents of a CAN-TP frame 25.1 are used to generate authentication. The SADSE receives a nonce from the TPsec tag 231, which is a serial number. If the TPsec tag 231 contains Sec-Info data, this data is used to select a key K from several keys. If only one key is used, no Sec-Info data is used at the receiver. The transmitted authentication tag 233 is fed to the tag input T of the SADSE, while the CAN-TP header is entered into the input for additional authentication data. The SADSE calculates a tag T' based on the key K and the nonce N. The authentication identification AI output by the SADSE indicates whether the calculated T' is equal to the input tag T. If so, the CAN-TP frame 27.1 is considered authentic. Fig. For alternative 7c not shown, the calculated day T' is output.

[0074] The receiver-only authentication mode authenticates a CAN-TP frame received by the receiver as an original protocol frame intended to be sent from sender S to the receiver. In other words, the receiver authenticates a CAN-TP frame according to Fig. 2.

[0075] In AO mode with receiver-only authentication, the additional authentication data AAD includes all information from the CAN-TP frame 25, starting with the CAN-TP header 251, and optionally a portion of the payload TP data 232 or the entire payload TP data 232. If replay protection is not required, the protocol frame 100 may not include sequence number 71, as described above in combination with Fig. As discussed in 7b. Consequently, since 71 is not set, the nonce N can be left at the previously used value or set to zero or any other practical value.

[0076] A comparison of the received security tag T within the CAN-TP frame 27.1 with the newly calculated tag T' at the receiver allows authentication as to whether the received CAN-TP frame 27.1 was intended for transmission from the sender to the receiver. If the payload TP data 232 was also used to calculate the tag T at the sender and the tag T' at the receiver, the authentication information AI indicates whether the protocol frame 100 is in its original form.

[0077] It can be useful for the SADSE to directly output an authenticity indicator (AI) that corresponds to the result of comparing the newly calculated tag T' with the security tag SecTag within protocol frame 100. Provided that the security tag SecTag is input into the SADSE, all the information for this comparison is available to the SADSE.

[0078] Now, a mode with authenticated encryption of SADSE, also known as AE mode, is considered.

[0079] Now, with attention to Fig. Section 7d describes an AE mode for the SADSE at the receiver. The SADSE receives a key K, a nonce N, a ciphertext C, a tag T, and additional authentication data AAD. The inputs for the key K, the nonce N, the tag T, and the additional authentication data AAD are provided to the SADSE according to the embodiment described above. Fig. 7c. In addition, the inputs for the cipher are derived from the received user TP data 231, which are derived from the decryption of the TP data 21 in the SADSE at the sender.

[0080] In AE mode at receiver R, the SADSE outputs the plaintext P. The SADSE generates the decrypted version of the cipher C based on the cipher CC and the key K.

[0081] In AE mode at receiver R, the SADSE can output a tag T' calculated using the key K, the optional sequence number as nonce N, and the additional authentication data AAD. Tag T' is a recalculation of the security tag SecTag generated at sender S. In this embodiment, the SADSE outputs a comparison value AI, indicating the result of the comparison between the received tag T and the tag T' calculated at the receiver. It can be practical for the SADSE to directly output an authentication value AI, indicating the result of comparing the newly calculated tag T' with the security tag SecTag within the CAN-TP frame 27. The authentication value can be, for example, "verified" or "not verified."

[0082] One possible way to implement SADSE according to the present disclosure would be a block cipher mode. A well-known example of such a block cipher mode is AES-GCM (Galois counter mode).

[0083] For AES-GCM, NIST, the National Institute for Standards and Technology in the USA, has issued a recommendation regarding the respective bit lengths for the input and output values ​​of AES-GCM. These parameters are summarized in Table 1 for AO mode with authentication only. Table 1: Size in bits Variables for the SADSE, which is implemented using AES-GCM with symmetric cipher E using the key K, mode AO with authentication only. Key K 128, 192 or 256 Sequence number 72 96 counter - Additional authentication data AAD 128*a plain text - Authentication tag 128 Code C -

[0084] For the AO mode with authentication only, the plaintext stream of le symbols and the corresponding ciphertext about the payload PP to be protected are not used as a plaintext stream, which is relevant to the discussion of the AO mode of the SADSE with regard to Fig. 7b and Fig. 7c corresponds.

[0085] With reference to the additional authentication data AAD, the length of 128*a bits is intended to indicate that an integer multiple of 128 bits should be chosen to optimize the performance of the AES-GCM mode implementing the SADSE of this disclosure. Achieving a multiple of 128 bits can conveniently be accomplished without padding. The counter CTR is an internal variable of the AES-GCM and is included for completeness, as it is not used in the AO mode.

[0086] Table 2 summarizes the respective bit lengths for input and output parameters of the AES-CGM, which implements SADSE. Table 2: Size in bits Variables for the SADSE, which is implemented using AES-GCM with symmetric cipher E using the key K in mode AE ​​with authenticated encryption Key K 128, 192 or 256 Sequence number 72 96 counter 32 Additional authentication data AAD 128*a plain text 128*p Authentication tag 128 Code C 128*p

[0087] Unlike the parameters in Table 1 for the AO mode with authentication only, the AE mode with authenticated encryption uses the counter, which is implemented as a 32-bit value.

[0088] For optimal performance of the AES-GCM that implements SADSE, the ciphertext C and the additional authentication data AAD should have a length multiple of 128 bits. Zero padding is a practical option for achieving such a bit length.

[0089] Fig. Figure 8 shows an example of how a CAN-TP frame 25 can be forwarded to the data link layer to form a CAN frame 27. The CAN-TP frame 25 comprises a CAN-TP header 251 of 2 to 6 bytes and payload data, which includes a TPsec tag 231, payload TP data 232 of 2011 to 2016 bytes, and an authentication tag 233 of 16 bytes. The TPsec tag 231 consists of the serial number of 12 bytes and the SecInfo of 2 to 3 bytes. The payload TP data consists of several payload parts P1, P2, ..., Pn.

[0090] In version 1, v1, a CANXL frame 27 is created in the data link layer, comprising a CAN header 271, the payload 272 (a copy of frame 25 above), and a file extension 273. Here, the contents of the TP frame 25 are transmitted in a single frame. In version 2, v2, the contents of the TP frame 25 are split across multiple CANXL frames 27.1, 27.2, ..., 27.n. Each of these frames 27.1, 27.2, ..., 27.n comprises a header 271, payload of 512 bytes, and an end-of-file tag 273. Frame 27.1 contains the SecTag 231 and the payload part P1 as payload, frame 27.2 contains P2 as payload, and frame 27.n contains the payload part Pn and the authentication tag 233.

[0091] First, frame 27.1 is sent, then frame 80 from another sender, then frame 27.2, followed by frame 81 from yet another sender. Finally, frame 27.n is transmitted across the network. The smaller frames 27.1 through 27.n allow the smaller frames 80 and 81 from other senders to be transmitted in a timely manner. Frame 80 carries 8 bytes of payload, while frame 81 carries 64 bytes of payload.

[0092] The embodiments described above are for illustrative purposes only. It is understood that modifications and variations of the arrangements and the details described herein will be apparent to a person skilled in the art. Therefore, the intention is to be limited only by the scope of protection of the pending patent claims and not by the specific details presented here in the description and explanation of the embodiments. The embodiments are described using CAN standards, but other protocols can be used as well. Reference symbol list 1 in-vehicle network 20 Client 21 TP data message 22 TPsec engine 23 TP-Sec message 24 CAN-TP unit 25, 25.1 ... 25.n CAN TP frame (first frame) 26 CAN transfer block 27 CAN frames (second frame) 29 Voltage level signal 231 TP-Sec-Tag 232 user TP data 233 Authentication Tag 251 CAN-TP header (first header) 271 Header (second header) 272 TP usage data 273 End of file

Claims

[1] Transmitter (S) configured to participate in an in-vehicle network (1), the transmitter (S) being configured to: - receiving a request to transmit payload data (21); - generating, in response thereto, a first header (251) in the transport and / or network layer; - Accessing a key K with a length of k bytes, - generating an authentication tag (233) using the key K and at least the first header (251) as additional authentication data (AAD), wherein the authentication tag (233) is intended to indicate an authenticity of a first frame (25) in the transport and / or network layer as an original frame sent from the sender (S) to a receiver (R), and - generating the first frame (25) comprising the first header (251), transport layer payload data (232) generated using the payload data (21), and the authentication tag (233); - forwarding the first frame (25) to the link layer, wherein the link layer generates a second frame (27) on the link layer and emits the second frame (27) to the in-vehicle network (1), wherein the second frame is a CAN (Controller Area Network) protocol frame. [2] Transmitter (S) according to claim 1, wherein the payload data (21) or parts of the payload data (21) are also used as additional authentication data (AAD). [3] Transmitter (S) according to claim 1 or 2, wherein the transmitter (S) is further configured to generate a ciphertext (C;232) for the transport layer payload (232) using: - the key (K), - the user data (21); and - the header (H), as additional authentication data (AAD). [4] Transmitter (S) according to one of claims 1 to 3, wherein the transmitter (S) is further configured to: - Generating a sequence number (SN) of sn bytes; - and to integrate the sequence number (SN) into the first frame (25). [5] Transmitter (S) according to one of claims 1 to 4, wherein the transmitter (S) is configured to: - Receiving safety information (SI) of length si, - and selecting, while accessing the key K, the key K from several keys depending on the security information (SI). [6] Transmitter (S) according to claim 5, wherein the transmitter (S) is further configured to: - Include the safety information (SI) in the first frame (25). [7] Transmitter (S) according to one of claims 1 to 6, wherein the first frame (25) is generated according to ISO-15765-2. [8] Receiver (R) configured to participate in an in-vehicle network (1), the receiver (R) being configured to: - receiving a second frame (27) in the link layer, - extracting received payload data (272) from the second frame (27), wherein the second frame is a CAN (Controller Area Network) protocol frame, - forwarding the received payload data (272) to the network and / or transport layer as a first frame (25), - extracting a first header (251) from the first frame (25) in the network and / or transport layer, - Accessing a key K with a length of k bytes, - performing an authentication check using the key K and at least the first header (251) as additional authentication data (AAD) to indicate an authenticity of a first frame (25) as an original frame sent from a sender (S) to a receiver (R). - Extracting transport layer payload data (232) from the first frame (25). [9] Receiver (R) according to claim 8, wherein the authentication check further uses the transport layer payload (232) or a portion of the transport layer payload (232). [10] Receiver (R) according to one of claims 8 to 9, further configured to generate a plaintext (P;21) using: - of the key K; - the transport layer payload (232) as ciphertext; and - the first header (251), as additional authentication data (AAD). [11] Receiver (R) according to one of claims 8 to 10, further configured to: - Extracting a sequence number (SN) of sn bytes from the first frame (25). [12] Receiver (R) according to one of claims 8 to 11, wherein the transmitter (S) is configured to: - extracting security information (SI) from the first frame (25), selecting, while accessing the key K, the key K from several keys depending on the security information (SI). [13] Receiver (R) according to one of claims 8 to 12, wherein the first frame (25) is extracted according to ISO-15765-2. [14] A method for participating in an in-vehicle network (1), the method comprising the following steps: - receiving a request to transmit payload data (21); - generating, in response thereto, a first header (251) in the transport and / or network layer; - Accessing a key K with a length of k bytes, - generating an authentication tag (233) using the key K and at least the first header (251) as additional authentication data (AAD), wherein the authentication tag (233) is intended to indicate an authenticity of a first frame (25) in the transport and / or network layer as an original frame sent from the sender (S) to a receiver (R), and - generating the first frame (25) comprising the first header (251), transport layer payload (232) using the payload (21), and the authentication tag (233); - forwarding the first frame (25) to the link layer, wherein the link layer generates a second frame (27) on the link layer and emits the second frame (27) to the in-vehicle network (1), wherein the second frame is a CAN (Controller Area Network) protocol frame. [15] A method for participating in an in-vehicle network (1), the method comprising the following steps: - receiving a second frame (27) in the link layer, the second frame being a CAN (Controller Area Network) protocol frame, - extracting received payload data (272) from the second frame (27), - forwarding the received payload data (272) to the network and / or transport layer as a first frame (25), - extracting a first header (251) from the first frame (25) in the network and / or transport layer, - Accessing a key K having a length of k bytes, performing an authentication check using the key K and at least the first header (251) as additional authentication data (AAD) to indicate an authenticity of a first frame (25) as an original frame sent from a sender (S) to a receiver (R).

Images