Authenticity and security of the data link layer for automotive communication systems

Abstract

This invention provides a system and method for providing authenticity and data security at the data link layer level for bus-based communication networks within vehicles. [Solution] In the method, a protocol frame for communication between participants in a bus-based communication system within a vehicle according to a protocol includes a header. The header indicates the start of a protocol frame to be communicated between a transmitter and a receiver, and both the transmitter and the receiver are participants in the bus-based communication system. The protocol frame includes an instruction, which indicates the level of authenticity and / or data security of the protocol frame on the data link layer.

Description

Technical Field

[0001] The present disclosure relates to authentication and security on the data link layer for a network in a vehicle network.

Background Art

[0002] In today's vehicles, data integrity and security are essential. In some past functions, such as steering, a physical connection from the steering wheel to the vehicle's wheels was provided. The same applies to the braking function and the transmission function. However, in today's vehicles, such a physical connection no longer exists, and there is an electrical wire or bus that communicates steering commands to the electric power steering. In response to a steering command via the bus, the electric power steering actuates the turning of the wheels corresponding to the turning of the steering wheel.

[0003] By accessing the bus, it may be possible to attempt to take over the vehicle's functions and insert malicious bus communications or commands. The risk of inserted malicious bus commands is further increasing with the improvement of entertainment functions or connectivity provided in today's vehicles.

[0004] In the case of an autonomous vehicle or a self-driving car, this risk is even higher because sensor data for analyzing the surrounding of the vehicle and commands to actuators for controlling the vehicle can be realized as bus communications.

[0005] One approach to reducing this risk is to provide authenticity and security for such bus communications at the data link layer level so as not to burden the upper protocol layer with these authenticity and / or security issues.

Summary of the Invention

Means for Solving the Problems

[0006] According to several possible implementations, a protocol frame for communication between participants in a bus-based communication system within a vehicle according to a protocol may include a header, the header indicating the start of a protocol frame to be communicated between a transmitter and a receiver, both of which are participants in the bus-based communication system, and the protocol frame may include instructions, the instructions configured to indicate the level of authenticity and / or data security of the protocol frame on the data link layer. In a first implementation, the instructions include a first instruction configured to indicate authentication of the protocol frame at the data link layer level.

[0007] In the second implementation, either alone or in combination with the first implementation, the instructions include a second instruction configured to indicate both authentication and data security at the data link layer level for the protocol frame.

[0008] In the third implementation, either alone or in combination with one or more of the first and second implementations, at least one of the directives, the first directive, or the second directive is part of the protocol frame header.

[0009] In the fourth implementation, either alone or in combination with one or more of the first through third implementations, at least one of the directives, the first directive, or the second directive is represented as the payload type of the protocol frame.

[0010] In the fifth implementation, either alone or in combination with one or more of the first through fourth implementations, at least one of the directives, the first directive, or the second directive is represented as a security directive flag or bitfield inside the header.

[0011] In the sixth implementation, either alone or in combination with one or more of the first through fifth implementations, the protocol frame may include downstream security information and a downstream protected payload portion, where the security information indicates the level of protection for the protected payload portion.

[0012] In the seventh implementation, the security information is further configured, either alone or in combination with one or more of the first through sixth implementations, to indicate a virtual channel between the transmitter and the receiver, or at least one of one or more keys.

[0013] In the eighth implementation, the instruction, either alone or in combination with one or more of the first through seventh implementations, indicates whether authentication only or authentication and data protection are applied to the protocol frame.

[0014] In the ninth implementation, either alone or in combination with one or more of the first through eighth implementations, the security information is further configured to indicate a security association that indicates a key to be selected for authentication at the data link layer level for the protocol frame, or for authentication and data security.

[0015] In the tenth implementation, either alone or in combination with one or more of the first through ninth implementations, the protocol frame further includes a security tag, the security tag is configured to verify the authenticity of the protocol frame as the original protocol frame intended to be transmitted from the transmitter to the receiver at the data link layer level, and the security tag is configured to verify the authenticity of the protocol frame at the transmitter on the data link layer or at the receiver on the data link layer.

[0016] In the eleventh implementation, either alone or in combination with one or more of the first through tenth implementations, the frame has a length N used with the Controller Area Network (CAN) standard, the CAN Flexible Data Rate standard, or the CAN Extra Large standard.

[0017] In the twelfth implementation, either alone or in combination with one or more of the first through eleventh implementations, the frame selectively has a length N of 8 bytes, 8 to 64 bytes, or 64 to 2048 bytes.

[0018] According to several possible implementations, a transmitter on the data link layer is configured to participate in a bus-based communication system within a vehicle, wherein the transmitter is configured to generate a header in response to a request from a higher protocol layer, access a key K of k bytes in length, receive a protected payload portion from the higher protocol layer, aggregate additional authentication data, generate a security tag using the key K and the additional authentication data to verify the authenticity of the frame as the original frame to be sent from the transmitter to the receiver at the data link layer level, and generate a protocol frame comprising the header, the protected payload portion, and the additional authentication data, wherein the transmitter is configured to communicate the protocol frame from the transmitter to one or more participants in the bus-based communication system at the data link layer level.

[0019] In the first implementation, the bus-based communication system is a broadcast-based bus system, and therefore all nodes within the bus-based communication system are configured to receive protocol frames communicated by the transmitter.

[0020] In the second implementation, either alone or in combination with the first implementation, the protocol frame further includes instructions configured to indicate the level of authenticity or data security of the protocol frame on the data link layer.

[0021] In the third implementation form, alone or in combination with one or more of the first implementation form and the second implementation form, the instruction includes a first instruction configured to indicate authentication at the data link layer level for the protocol frame.

[0022] In the fourth implementation form, alone or in combination with one or more of the first implementation form to the third implementation form, the instruction includes a second instruction configured to indicate both authentication at the data link layer level for the protocol frame and data security.

[0023] In the fifth implementation form, alone or in combination with one or more of the first implementation form to the fourth implementation form, at least one of the instruction, the first instruction, or the second instruction is part of the header of the protocol frame.

[0024] In the sixth implementation form, alone or in combination with one or more of the first implementation form to the fifth implementation form, at least one of the instruction, the first instruction, or the second instruction is represented as a security instruction flag or bit field inside the header.

[0025] In the seventh implementation form, alone or in combination with one or more of the first implementation form to the sixth implementation form, in the mode of only transmitter authentication, the additional authentication data is the header and the protected payload part.

[0026] In the eighth implementation form, alone or in combination with one or more of the first implementation form to the seventh implementation form, the transmitter in the authenticated encryption mode is further configured to use the key, the protected payload part in plaintext, and the header as additional authentication data to generate a ciphertext for the protected payload part.

[0027] In a ninth implementation form, alone or in combination with one or more of the first to eighth implementation forms, the transmitter is further configured to generate a sequence number of sn bytes downstream of the header, and the transmitter is configured to incorporate the sequence number into the protocol frame at the expense of shortening the protected payload, and the shortened protected payload is shortened by sn bytes compared to the protected payload portion.

[0028] In a tenth implementation form, alone or in combination with one or more of the first to ninth implementation forms, in the authentication-only mode of the transmitter, the additional authentication data includes the header, the sequence number, and the protected payload.

[0029] In an eleventh implementation form, alone or in combination with one or more of the first to tenth implementation forms, the transmitter is configured to generate security information of length si using the key K, and the transmitter is further configured to incorporate the security information into the protocol frame downstream of the header at the expense of shortening the payload, and the shortened payload is shortened by si bytes compared to the protected payload, and the security information indicates the protection level for the protected payload portion.

[0030] In a twelfth implementation form, alone or in combination with one or more of the first to eleventh implementation forms, the transmitter in the authenticated encryption mode is further configured to generate security information of si byte length, and the transmitter is further configured to incorporate the security information into the protocol frame downstream of the header at the expense of shortening the protected payload, and the shortened protected payload is shortened by si + sn bytes compared to the protected payload, and the security information indicates the protection level for the shortened protected payload.

[0031] In the 13th implementation, either alone or in combination with one or more of the 1st through 12th implementations, the additional authentication data includes a header, a sequence number as a nonce, security information, and a shortened, protected payload.

[0032] In the 14th implementation, either alone or in combination with one or more of the first through 13th implementations, the transmitter in authenticated encryption mode is further configured to generate ciphertext using a key, a sequence number as a nonce, a protected payload in plaintext, a header, a serial number, and security information as additional authentication data.

[0033] In the 15th implementation, either alone or in combination with one or more of the 1st through 14th implementations, the transmitter is configured to select key K from a set of keys according to a security association, the security association being represented within the security information of the protocol frame.

[0034] According to several possible implementations, a receiver on the data link layer for participating in a bus-based communication system within a vehicle is configured to receive protocol frames on the data link layer and from a transmitter in accordance with the protocol, and to extract instructions from the protocol frames that are configured to indicate the level of authenticity or data security of the protocol frames on the data link layer.

[0035] In the first implementation, the receiver is further configured to extract a header from the protocol frame, extract a protected payload portion from the protocol frame, access a kilobyte-length key, extract a security tag from the protocol frame downstream of the header, and calculate an authenticity indicator based on the key, additional authenticity data including the header, the security tag, and the protected payload, the authenticity indicator is configured to verify the authenticity of the protocol frame transmitted from the transmitter to the receiver at the data link layer.

[0036] In the second implementation, either alone or in combination with the first implementation, the receiver is further configured to drop a protocol frame if the authenticity indicator fails to verify the authenticity of the protocol frame transmitted from the transmitter to the receiver, and optionally to indicate such lack of authenticity to a higher protocol layer.

[0037] In the third implementation, either alone or in combination with one or more of the first and second implementations, the bus-based communication system is a broadcast-based bus system, and therefore all nodes within the bus-based communication system are configured to receive protocol frames communicated by the transmitter.

[0038] In the fourth implementation, either alone or in combination with one or more of the first through third implementations, the instruction includes a first instruction configured to indicate authentication at the data link layer level for a protocol frame.

[0039] In the fifth implementation, either alone or in combination with one or more of the first through fourth implementations, the instruction includes a second instruction configured to indicate both authentication and data security at the data link layer level for the protocol frame.

[0040] In the sixth implementation, either alone or in combination with one or more of the first through fifth implementations, at least one of the directives, the first directive, or the second directive is part of the protocol frame header.

[0041] In the seventh implementation, either alone or in combination with one or more of the first through sixth implementations, at least one of the directives, the first directive, or the second directive is represented as a security directive flag or bit field inside the header.

[0042] In the eighth implementation, either alone or in combination with one or more of the first through seventh implementations, in the receiver's authenticated decryption mode, the receiver is configured to generate a decrypted payload as an output stream to a higher protocol layer, using the key, the protected payload portion as ciphertext, and additional authentication data, if the authenticity indication indicates the authenticity of the protocol frame transmitted from the transmitter to the receiver.

[0043] In the ninth implementation, the additional authentication data includes a header, either alone or in combination with one or more of the first through eighth implementations.

[0044] In the tenth implementation, the receiver is further configured, either alone or in combination with one or more of the first through ninth implementations, to extract an sn-byte sequence number from the protocol frame.

[0045] In the 11th implementation, either alone or in combination with one or more of the 1st through 10th implementations, the additional authentication data includes a header and a sequence number.

[0046] In the twelfth implementation, either alone or in combination with one or more of the first through eleventh implementations, in the receiver's authenticated decryption mode, the receiver is configured to generate a decrypted payload as an output stream to the higher protocol layer, using a sequence number, a key, a protected payload portion as ciphertext, and additional authentication data, if the authenticity instruction indicates the authenticity of a protocol frame transmitted from the transmitter to the receiver, and the receiver is configured to notify the higher protocol layer of the authenticity instruction.

[0047] In the 13th implementation, either alone or in combination with one or more of the 1st through 12th implementations, the additional authentication data includes a header, a sequence number, and security information.

[0048] In the 14th implementation, either alone or in combination with one or more of the first through 13th implementations, the receiver is further configured to extract security information from the protocol frame downstream of the header, the security information indicating a virtual channel between the transmitter and the receiver, and at least one of the keys to be selected according to a security association to protect the protected payload portion.

[0049] In the 15th implementation, either alone or in combination with one or more of the 1st through 14th implementations, in the receiver authentication and decryption modes, the receiver is configured to generate a decrypted payload as an output stream to the higher protocol layer using a key, a sequence number, a protected payload portion as ciphertext, and additional authentication data, if the authenticity instruction indicates the authenticity of a protocol frame transmitted from the transmitter to the receiver, and the receiver is configured to notify the higher protocol layer of the authenticity instruction.

[0050] According to several possible implementations, the in-vehicle communication network is configured to provide communication at the transport level layer between the transmitter and receiver described herein, using the protocol frames described herein.

[0051] In this specification, the implementation configuration will be described with reference to the attached drawings. [Brief explanation of the drawing]

[0052] [Figure 1A] This is a block diagram showing the bus-based communication system inside the vehicle. [Figure 1B] This diagram shows the communication stack and the virtual channel between the transmitter and receiver on the data link layer, as disclosed in this disclosure. [Figure 1C] This diagram shows the grouping of nodes within a secure zone and security layer entities within a secure zone. Furthermore, it illustrates the secure channels between security layer entities. [Figure 2A] This figure shows an example of a protocol frame using a known protocol used in a vehicle. [Figure 2B] This figure shows an example of a protocol frame that provides authentication for such a protocol frame at the data link layer level. [Figure 2C] This figure shows an example of a protocol frame that provides authenticated encryption of such protocols at the data link layer level. [Figure 3A] This figure shows the generic authentication and / or data security engine (SADSE) for protocol frames at the data link layer level. [Figure 3B] This figure shows the input and output variables of SADSE for authentication only at the data link layer level transmitter. [Figure 3C] This figure shows the input and output variables of SADSE for authentication at the receiver level at the data link layer. [Figure 3D]This figure shows the input and output variables for SADSE for authenticated encryption at the data link layer level in the transmitter. [Figure 3E] This figure shows the input and output variables of SADSE for decoding and authentication at the receiver level at the data link layer. [Figure 4] This figure shows the protocol frame according to the CAN standard. [Modes for carrying out the invention]

[0053] Figure 1A shows an exemplary bus connecting multiple nodes Node1, Node2, ..., Node n. In the example in Figure 1A, the bus is shown as a two-wire bus system, which can preferably be implemented as two differential lines. Of course, other setups are possible. The bus system can be terminated by optional termination resistors T1, T2, which may be intended to reduce reflections on the bus that typically affect signal quality along the bus. Notable examples of bus systems in vehicles are CAN, CAN-FD, CANXL, or LIN networks. While this disclosure focuses on variations of CAN, it will be apparent to those skilled in the art that the teachings of this disclosure are equally applicable to other bus systems.

[0054] It will be understood that the bus shown in Figure 1A can also be arranged in a ring topology. In a ring topology, both ends of the bus are supplied to a single master unit (not shown), thereby forming a bus loop. Individual nodes Node1, 2, ..., n are connected to the bus as described above.

[0055] It should be understood that an in-vehicle network or a bus-based communication system (as shown in Figure 1A) has specific attributes that reflect the requirements for the in-vehicle network. The in-vehicle network facilitates the communication of sensor data to control units by data frames transmitted from sensors or sensor control units to higher-level control units. Useful protocols can be used for data frames or protocol frames communicated between individual nodes or participants in a bus-based communication network.

[0056] In response to or in response to the reception of sensor data, the sensor's control unit or a higher-level control unit can communicate a predetermined action to an actuator coupled to the bus, for example, a braking action to a brake actuator. For example, in the example in Figure 1A, Node1 may represent an angle sensor (not shown) that measures the angle at which a brake paddle is pressed. This angle can be transmitted as a protocol frame to a higher-level ECU, for example, Node2. In response to the reception of the angle value, the ECU can send one or more bus frames to Node n, which is the brake actuator. These bus frames sent from the ECU to the brake actuator can trigger a braking action.

[0057] Bus communications related to braking actions are clearly time-critical and need to be transmitted at high speed. Such real-time requirements are not common in standard communication networks.

[0058] An in-vehicle communication network typically has a clearly defined number of bus participants, which, by default, remain constant throughout the vehicle's lifespan, ignoring vehicle upgrades for a considerable period. Similarly, existing links between individual nodes, and consequently the topology of the bus-based communication system, also remain unchanged throughout the vehicle's lifespan. Such a situation is highly unlikely in a standard computer network. In practice, standard computer networks require the ability to add or remove nodes while the computer network is in operation. Furthermore, it is possible to provide new links or remove links while a standard computer network is operating.

[0059] In bus-based communication systems that control vehicle functions, it is crucial to ensure the authenticity of protocol frames transmitted over the bus. Considering braking actions, when parking a vehicle under control, commands to trigger emergency braking should not be mistaken for gentle braking. For this purpose, demonstrating the authenticity of protocol frames communicated between participants in a bus-based communication system is essential.

[0060] It will be understood that demonstrating the authenticity of protocol frames at the data link layer is important in order to reduce the involvement of higher protocol layers in authenticating time-critical instructions communicated between participants in a bus-based communication system.

[0061] With the increase in entertainment systems and the rise of vehicle-to-vehicle communication available today, vulnerabilities that allow malicious commands or protocol frames to be injected into communication systems are increasing.

[0062] Therefore, it is important to provide data security for protocol frames to prevent the insertion of malicious protocol frames. Providing data security at the data link layer level to demonstrate the authenticity of protocol frames is also appealing. In this way, the involvement of higher protocol layers or software stacks providing security and / or authenticity information becomes unnecessary. It will be apparent to those skilled in the art that data security and authenticity functions can be suitably supported by hardware elements such as transmitters or receivers at the protocol layer. In other words, data security and authenticity functions can be offloaded to dedicated hardware at the data link layer level when these functions are implemented at the data link layer level.

[0063] Figure 1B shows Node1 and Node2 as participants in a bus-based communication system as shown in Figure 1A. Communication between Node1 and Node2 flows through several different layers, which can be classified according to the well-established OSI-ISO layer model. The lowest level layer is the so-called physical layer, represented by PHYS for Node1 and Node2. Each layer in the OSI model can receive commands from higher levels, perform some action at its own level, and trigger tasks at lower levels by forwarding requests to lower levels.

[0064] Instructions to the physical layer are receivable from the data link layer, as indicated by the downward arrow between the PHYS layer and the data link layer. As a function of the layers, the physical layer of Node1 can use a connection or link to Node2 to communicate data to Node2 over the physical layer. Similarly, Node1 can receive data from Node2 via the physical link between Node1 and Node2, and further transfer the received data to the data link layer above the physical layer. This transfer is indicated by the upward arrow between the physical layer and the data link layer of Node1 in Figure 1B. The protocol flow in Node2 is similar to that described for Node1.

[0065] Some existing bus-based communication networks within vehicles do not adhere to the separation of the physical layer and data link layer as proposed in the OSI-ISO model. To reflect this particular example, Figure 1B shows a transmitter S and receiver R extending across the physical layer PHYS and the data link layer.

[0066] A known concept regarding the authenticity of data communications within a vehicle is implemented in the application layer, layer 7 of the OSI-ISO layer model, using software stacks shown as App1 and App2 for Node1 and Node2, respectively, in Figure 1B. To demonstrate authenticated and / or protected communication between two or more participants using the software stacks App@Node1 and App@Node2, it may be preferable to introduce the concept of a virtual channel between Node1 and Node2.

[0067] One example of using a software stack to provide security to an in-vehicle network is SEC OC, which complies with the AUTOSAR standard. S ecure O nBoard CThis is communication. It may be preferable for the OEM to specify the software stack app for Node1 and Node2, giving flexibility to the hardware implementation of Node1 and Node2. As a trade-off, by using a software stack to implement authenticity and / or data security, the real-time requirement for actuator response to commands from the electronic control unit (ECU) to the actuator may no longer be met. This actuator is shown in Figure 1A as Node n participating in the bus-based communication system. For example, consider a braking command sent from the control unit ECU (shown as Node2 in Figure 1A) to a braking actuator, for example to Node n in Figure 1A, as protocol frame 100 (best seen in Figures 2A-2C or Figure 4). If such communication were to be authenticated and secured using a software stack, all layers for each individual node would be involved in this security, which may take too long for reliable braking operation.

[0068] A further drawback of software stack-based authenticity and / or data security solutions may be the fact that the software stack may not be properly designed, which could lead to a reduction in or even a breach of authenticity and / or security capabilities.

[0069] Therefore, depending on the situation, it is appealing to limit the authenticity and / or data security functions to a single layer for individual participants in a communication system, such as Node1 or Node2 in Figure 1B. By limiting the authenticity and / or data security functions to the data link layer, other protocol layers are prevented from being occupied by part of the data integrity and / or data security operation.

[0070] As a further benefit, protocol frames 100 whose authenticity may not be established can already be dropped at the data link layer. That is, if authenticity testing indicates that protocol frame 100 was not intended to be sent from the transmitter to the receiver and / or did not reach the receiver in its original form, the protocol frame 100 can be dropped without further processing. Thus, an attempt to flood one participant in a bus-based communication system with invalid or unauthenticated frames 100 at the data link layer will only affect that one node at the data link layer, while the higher protocol layers can remain unaffected. Such containment of authenticity and / or data security efforts would be impossible with a software stack-based approach to authenticity and / or data security.

[0071] Furthermore, it is preferable to use dedicated hardware elements, namely transmitters and / or receivers on the data link layer that provide authenticity and / or data security as part of the dedicated hardware. This would have the further advantage that such configuration blocks—assuming CAN bus transceivers—can be used as standard circuits without requiring further investigation or adaptation as bus participants or software applications App on participants change over time.

[0072] The following examples of protocol frame 100 illustrate the implementation of different levels of authentication and / or data security on the data link layer with reference to Figures 2A to 2C.

[0073] The left side of Figure 1C shows several exemplary nodes Node1, Node2, Node3, and Node4 connected to a bus to form a bus-based communication network. Some of these nodes are part of a secure zone (SZ). In the example in Figure 1C, Node2, Node3, and Node4 are grouped into the same secure zone (SZ), while Node1 is not. Nodes grouped into the same secure zone (SZ) can communicate with each other in an authenticated mode, or even in an authenticated and encrypted mode, as will be explained in more detail in Figures 3A to 3E. Nodes that do not form part of a secure zone (SZ) may be able to listen to communications between nodes in the secure zone (SZ). In the example in Figure 1C, Node1, which is not part of the SZ, can listen to communications between Node2, Node3, and Node4, but cannot send authenticated messages to these nodes as a member of the secure zone (SZ). If communications between nodes within an SZ are encrypted, nodes that do not belong to a secure zone (SZ) cannot decrypt messages communicated within the secure zone (SZ).

[0074] The right side of Figure 1C further illustrates the concept of the Secure Zone (SZ). The Secure Zone (SZ) can be considered a logical overlay—for example, a security layer—over physical nodes Node2, Node3, and Node4. Security layer entity SLE1 in the security layer is connected to Node2 on the physical layer, security layer entity SLE2 is connected to Node3 on the physical layer, and security layer entity SLE3 is connected to Node4 on the physical layer. Physical Node1 of the bus shown in Figure 1C is not part of the Secure Zone (best seen in the diagram on the left side of Figure 1C), but this physical Node1 can be represented as security layer entity SLE n inside the security layer, and in the example selected in Figure 1C, this security layer entity SLE n is connected to Node1 on the physical layer.

[0075] It may be preferable to arrange communication between individual security layer entities among security layer entities SLE1, SLE2, and SLE3 as a secure channel SC. A secure channel SC provides point-to-point or point-to-multipoint unidirectional communication. It will be understood that a secure channel SC can be viewed as a data link layer representation of a virtual channel at the user level, as shown in Figure 1B.

[0076] The right side of Figure 1C shows the setup of the Secure Channel SC inside the Secure Zone SZ. A This provides unidirectional communication from security layer entity SLE1 to security layer entities SLE2 and SLE3, while the secure channel SC B This provides unidirectional communication from security layer entity SLE2 to security layer entities SLE1 and SLE3, while the secure channel SC CThis provides unidirectional communication from security layer entity SLE3 to security layer entities SLE1 and SLE2. In cases where bidirectional communication between individual security layer entities SLE is required, at least two secure channels SC will be needed. The bus-based communication network shown in Figures 1A and 1C can be static in terms of both the authentication of the communication network and the data security (i.e., encryption) properties of the communication network, with respect to communication between individual nodes among the nodes within the network. In the case of such static authentication behavior or authentication and encryption behavior, the complexity of the protocol frame can be reduced, and it is possible to choose to identify the level of authentication or authentication and encryption level for this secure channel SC using information about the secure channel being used. However, for communication between individual nodes of a bus-based communication network with static authentication and encryption behavior, there is a trade-off in terms of authentication or authentication and encryption flexibility.

[0077] Figure 2A shows an original protocol frame 100 having a total length of N bytes (where N is an integer). The protocol frame 100 may include a header H, a payload P, and an end-of-frame indicator EOF. The header H may have a length of h bytes (where h is an integer less than N). The payload P may have a length of p bytes. The end-of-frame indicator EOF may have a length of eof bytes.

[0078] In Figure 2A, the payload P is shown downstream of the header H, and the end-of-frame (EOF) is shown downstream of both the header H and the payload P. It will be understood that the sum of the lengths of the header H, the payload P, and the end-of-frame instruction is the total length of the protocol frame 100, which is N bytes. Furthermore, it will be understood that the lengths of the individual elements, the header H, the payload P, or the EOF, may be bit lengths that are not common denominators of the full byte length. In such cases, the total length of the protocol frame may remain N bytes, but the individual segments of the protocol frame 100 may have subbyte-level lengths. It can be further noted that, according to the protocol, the total length of the protocol frame 100 may be a number of bits that is not a common denominator of the byte length.

[0079] Header H can be used to indicate the start of protocol frame 100, the frame length N, and the protocol or protocol variation to which it conforms.

[0080] Within Header H, it is possible to indicate rights or priorities related to protocol frame 100. Such options are typically specified in the protocol specification.

[0081] The protocol specification may further provide a first instruction within the frame indicating that authentication at the data link layer level is provided for a given protocol frame. Alternatively, the protocol specification may provide a second instruction within the frame indicating that both authentication and data security at the data link layer level are provided for a given protocol frame. Depending on the situation, it may be preferable to provide a generic instruction within the protocol header H to indicate that authentication at the data link layer level, or both authentication and data security at the data link layer level, is provided for a given frame. A generic instruction for both variations may be preferable to simplify the processing of header H because it requires fewer instructions within header H. As a trade-off for the simplification of header H processing resulting from using a generic instruction within header H, additional space may be required within frame 100 to indicate full-level authentication and data protection at the data link layer for frame 100.

[0082] The payload type pt indication within header H is known in the in-vehicle network. The payload type indication may be suitable for indicating what type of payload is being transmitted within the frame. In the in-vehicle network, different payload types pt for a brake actuator, such as Ethernet frames, original CAN frames, or frames supporting braking commands, can be indicated using the payload type portion pt of header H. Naturally, such a structure would facilitate the processing of different types of frames because, when processing a frame at the data link layer level, it becomes clear early on what type of payload is being transmitted in that frame.

[0083] It may be preferable to implement the first, second, or generic instructions regarding authentication and encryption at the data link layer as a dedicated payload type pt. In this way, the known concept of the payload type is extended to further indicate the level of authentication and / or data security provided for a given frame. If it is decided to implement the generic instructions using a dedicated payload type pt as described above, the processing of header H is simplified, with the trade-off being that more space is required within the frame to indicate full-level authentication and data protection at the data link layer for frame 100.

[0084] It will be understood that such instructions for authenticity or authenticity and data security can be implemented without the involvement of higher protocol layers, as is the case when the software stack provides authenticity or authenticity and data security for a given frame.

[0085] As a further alternative, the protocol specification may introduce security directives that are added as new data fields within the protocol frame 100, preferably within header H. As mentioned earlier, including security directives in header H reduces the frame processing effort required before it becomes clear what level of authenticity and / or security is applied to a given frame 100. Depending on the situation, the protocol may provide security directives that convey the meaning of generic directives, thereby reducing the space required for security directives. In this scenario, a single bit field within frame 100, preferably within header H, would suffice to convey the information of generic directives in a dedicated security directive added to header H as a data field. As a trade-off, as already discussed with respect to generic directives, further information is needed to obtain complete instructions on what level of authenticity and data security is applied to a given frame.

[0086] In Figure 2A, the payload P is shown downstream of the header H, and the end-of-frame portion (EOF) is shown downstream of both the header H and the payload P. This arrangement regarding the upstream-downstream relationship is used throughout this disclosure.

[0087] Furthermore, the protocol may allow for a variable frame length N of the protocol frame 100. For example, the total frame length N can be changed depending on the amount of information transmitted by each instance of the protocol frame 100.

[0088] In a vehicle environment, older devices and newer devices, each adhering to different variations of protocols, are likely to operate simultaneously. For example, a fairly older device, such as an ABS sensor, may communicate according to an earlier variation of the protocol, such as the CAN protocol (CAN stands for Controller Area Network), while a relatively newer device, such as a LiDAR system, may communicate with the electronic control unit using the CAN-FD (CAN-FD stands for Controller Area Network flexible-data rate) standard, or even the CANXL standard. Therefore, it may be useful to indicate different protocol types within the header H, because this can also affect the level of authenticity and / or data protection applied to individual protocol frames 100. Similarly, it may be preferable to indicate both the level of authenticity and / or data security at the data link layer level for a given frame using a payload type indication. For this purpose, a first indication, a second indication, a generic indication, and a security indication can be used.

[0089] Under these circumstances, it may be important to store or encode the total frame length (N bytes or N bits) somewhere within the protocol frame 100. Setting a frame length flag would be one option for encoding the frame length. How this information can be stored in the protocol frame 100 can be obtained from the protocol specification.

[0090] As is well known in the art, and therefore will not be explained further at this time, the end of frame indicator (eof) may further include error checking information.

[0091] Figure 2B shows an example of a protocol frame according to this disclosure. The protocol frame 100 may include a header H similar to the original protocol frame in Figure 2A. Preferably, the header H has a first directive, a second directive, a generic directive, or a security directive relating to authenticity and / or data security at the data link layer level. Alternatively, the header H may include a payload type pt that similarly covers the authenticity and / or data security aspects as described above.

[0092] The protocol frame 100 in Figure 2B has a length of N bytes or N bits, as described above. Unlike standard protocol frames, the frame in Figure 2B includes a protected payload portion PP. The protected payload portion PP is shortened to make room for a security tag SecTag, which may have a length of st bytes. The protocol frame 100 according to this disclosure may optionally include security information SecInf of si bytes (where si is an integer). The security information SecInf may, but is not limited to, be implemented as part of the header H. The protocol frame according to Figure 2B may optionally further include a sequence number SN of length sn. Depending on the circumstances, it may be preferable to place the sequence number SN within the header H. Such an arrangement allows frames containing an incorrect sequence number SN to be dropped earlier than if the sequence number SN were placed downstream of the header H. The lengths st, si, sn, or pp may or may not be a common divisor of the full byte length, as described above with respect to Figure 2A.

[0093] As an alternative, it may be important to transmit a shortened version of the sequence number SN.

[0094] Those skilled in the art will also understand the option of not transmitting any sequence number in frame 100. If this route is chosen, both the transmitter and receiver must recognize a common starting value for the sequence number and then individually count according to a predefined counting scheme. This sequence number can typically be associated with a security association, as will be further discussed with respect to the secret key K.

[0095] Security information SecInf can indicate the level of authentication at the data link layer level for a given frame. Alternatively, security information SecInf can indicate the level of authentication and data security at the data link layer level for a given frame.

[0096] Furthermore, it is possible to use a generic instruction for authentication or encryption at the data link layer level within the header H, in combination with the simplified security information SecInf. The same applies to security instructions. Such a simplified security information SecInf indicates whether a given frame is authenticated only or authenticated and encrypted, while the generic instruction within the header, as described above, would indicate that some level of authentication or data security, and therefore encryption, exists for a given frame.

[0097] In the case of frame 100, for which neither authentication nor data security is provided, it will be understood that the security information SecInf or simplified security information may be set to a selected value indicating that neither authentication nor data security is provided for the given frame. Alternatively, if a generic instruction or security instruction in the header already indicates that authentication or data security is absent for the given frame, the protocol specification may allow the security information SecInf or simplified security information to be omitted.

[0098] It is preferable that the security information SecInf includes some information about the configuration of the SADSE unit to be used for a particular frame 100. Furthermore, the security information SecInf may include information about the secure channel SC between security layer entities SLE1, SLE2, and SLE3 within the exemplary secure zone SZ in Figure 1C. A SC B SC C It may be preferable to include some information about the secure channel, such as the following. In the case of static authentication or static authentication and encryption setups, the secure channel information can be used to find the key K used for authentication and encryption of a given protocol frame 100 communicated between security layer entities (SLEs). To find the key K required for authentication and encryption in such a static setup, it may be considered to omit the generic instructions regarding static authentication and encryption behavior, the first instruction and / or the second instruction, and rely on the secure channel information. In practice, in situations where only authentication is performed, or even where neither encryption nor authentication is performed, it may be further considered to omit some frame elements in the case of static authentication or static authentication and encryption as outlined herein.

[0099] The security tag SecTag can represent an authentication instruction that the protocol frame 100 is intended to be transmitted from the transmitter S to the receiver R at the data link layer level. The security tag SecTag allows for further checking whether the protocol frame 100 has been modified on its way to the receiver R.

[0100] The security tag SecTag is shown downstream of the protected payload portion PP, but this security tag SecTag may also be placed upstream of the protected payload portion PP, or even incorporated into the standard header H, although this is not limited to the security tag SecTag.

[0101] It will be understood that the private key K is required for authentication, encryption, and decryption. Key deployment is not central to this disclosure for several reasons.

[0102] Firstly, in an automotive environment, the number of participants in a bus-based communication system is limited and does not change much throughout the vehicle's lifespan. It may be preferable to use a single key K of length k for all participants in the bus communication system.

[0103] If each individual node, which is connected communicably via a bus communication system, is required to use its own individual key K, then this individual key can be stored in each node of the bus-based communication system during vehicle production. Thus, a first key K1 for communication between Node1 and Node2 can be stored in Node1 and Node2, a second key K2 for communication between Node1 and Node3 can be stored in Node1 and Node3, and so on. It is assumed that the transmitter S and receiver R use the same key K, and therefore decryption, encryption, authentication, and verification are symmetric.

[0104] If more than one key K is used within the system, it may be important to store information about the key K involved in authentication, and / or data security can be stored or indicated in the optional security information field SecInf. It is further optional to use the security information field to indicate whether the current protocol frame 100 is an authenticated-only protocol frame or an authenticated and encrypted protocol frame 100. Naturally, information about which key should be used can also be represented using other data fields within the frame, such as the virtual CAN ID, payload type pt, or receive field.

[0105] Given the relatively long lifespan of vehicles, it may be desirable to have two or more keys K to protect or authenticate and protect communication between selected nodes within a network. More precisely, it may be desirable to change the keys during the vehicle's lifespan. It may be preferable to introduce two or more keys at the communicating nodes, allowing these nodes to change the keys used for authentication and data security. Changing the keys for authentication and / or encryption in this way requires some information about the currently used keys. Such information about the currently used keys will be referred to as a security association. The security association can preferably be stored within the header H, security information SecInf, or simplified security information. The protocol specification may allow the security association to be set to a special value for frames where authentication or data protection is not performed at the data link layer level. Alternatively, the protocol specification may allow the security association to be omitted in such environments.

[0106] The field sequence number SN is an additional optional element in protocol frame 100. The sequence number SN is a one-time integer, also known as a nonce. If the sequence number SN changes without the listening party's knowledge, it helps prevent a replay attack from succeeding. The AUTOSAR standard proposes a similar concept, using its freshness value to prevent replay attacks.

[0107] It will be understood that some of the SADSE algorithms described later may require a nonce of a specific length. Therefore, depending on the situation, it may be important to derive the nonce N from the sequence number SN.

[0108] As the simplest implementation of authentication and / or data security at the data link layer, a scheme can be implemented that performs authentication only using a frame containing a sequence number SN, when replay protection is required. When such protection is not required, the sequence number SN can be omitted, thereby allowing a relatively large protected payload portion PP within the protocol frame 100.

[0109] Depending on the situation, it may be decided to use only one key K for authentication within the system, in which case field security information containing such information about multiple different keys K1, K2, K3, ..., KN to be used can be omitted, thereby enabling a relatively large protected payload portion PP.

[0110] If neither multiple different keys K1, K2, K3, ..., KN nor replay protection are required, the field sequence number SN and security information SecInf can be omitted. This allows for a more expanded protected payload portion PP compared to the protocol frame shown in Figure 2A, in which case only the security tag SecTag reduces the protected payload field PP compared to the standard protocol frame.

[0111] Figure 2C shows an authenticated and encrypted protocol frame 100 according to this disclosure. The protocol frame 100 in Figure 2C includes a header H, an end-of-frame indicator EOF, a security tag SecTag, an optional field sequence number SN, and optional security information SecInf, as described in relation to Figure 2B. The protocol frame in Figure 2C is the same length as the protocol frames in Figures 2A and 2B. As previously stated, the individual frame elements, the header H, the optional sequence number SN, and the total frame length N, may be any integer bytes or any other length that is not a common divisor of the full byte length.

[0112] The protocol frame 100 in Figure 2C contains the ciphertext cipher{PP} of the protected payload PP instead of the protected payload PP itself. The protocol frame in Figure 2C is the same length as the protocol frames in Figures 2A and 2B. As previously mentioned, the individual frame elements, the header H, the optional sequence number SN, and the total frame length N, may be any integer bytes or any other length that is not a common divisor of the full byte length. One preferred method for implementing authenticity and / or data security protection for the protocol frame 100 at the data link layer level is a so-called symmetric authentication and / or data security engine, also known as SADSE, which is implemented as a hardware block and will be described in more detail from now with reference to Figures 3A to 3E. S symmetric a uthentication and / or d ata s ecurity e The solution is to use ngines.

[0113] Figure 3A shows the input and output values ​​for SADSE. The names of the input and output variables for SADSE follow the naming conventions established for block cipher modes in cryptographic literature. SADSE may operate in authenticity-only AO mode, or authenticated encryption ( A uthenticated EIt will be understood that it may operate in (cryption) mode AE. SADSE receives a secret key K, an optional nonce N, an input stream P of length 1, and additional authentication data AAD as input. The key K is preferably a symmetric key of a predetermined length, e.g., 128, 192, or 256 bits. As previously stated, key distribution is not the focus of this disclosure. In practice, corresponding schemes are known, such as MACsec key sharing as defined in IEEE 802.1X-2010. The optional nonce N is typically an integer value used only once. Depending on the circumstances, it may be decided to have the same value of N for two or more protocol frames 100.

[0114] The input stream P has different uses depending on the operating mode of SADSE. Furthermore, as will be described later, the additional authentication data AAD contains some bits of additional data used in authentication.

[0115] SADSE provides an output stream of length le, and can further output a tag T, or alternatively, directly output an authentication instruction AI. The output stream of length le has different uses and meanings depending on the operating mode of SADSE.

[0116] Tag T is calculated based on the input variables used by SADSE and can be thought of as a recalculation of the security tag SecTag defined above. Depending on the situation, it may be preferable for SADSE to directly output the result of a comparison between the security tag SecTag inside the protocol frame 100 and the newly recalculated tag T. This comparison result can be represented by an authenticity indicator AI. That is, the authenticity information AI indicates whether the protocol frame 100 was intended to be sent from a specified transmitter S to a given receiver R (both typically listed in the header H). The authenticity indicator AI further indicates whether the protocol frame 100 is in its original form.

[0117] As can be seen from Figure 3A, it is possible to choose to use an optional sequence number SN as the input for nonce N to SADSE. This may involve deriving nonce N from sequence number SN, as mentioned above. Naturally, using sequence number SN to derive nonce N will simplify the effort required to operate SADSE, because the random number generator increases the complexity of the circuit implementing SADSE. To make sequence number SN useful as nonce N, it is important to estimate the size required for sequence number SN. This answers the question of how long it takes for a given value of SN to be reused when the counter implementing sequence number SN starts counting again from its starting value after reaching the maximum value of the counter.

[0118] -To estimate this, we consider a CAN XL frame in an in-vehicle network (best seen in Figure 4) consisting of a maximum possible payload of 2048 bytes and a minimum payload of 20 bytes. We also consider 32-bit, 37-bit, 44-bit, and 64-bit counter lengths that implement a serial number SN that further functions as a noncember N.

[0119] Such a maximum payload frame would consist of 19 bits of header information, 16,435 bits of payload and CRC information, and 26 bits of acknowledgment and EOF information. At a typical baud rate within the network, a full frame would take 1.7 ms to communicate. Conversely, shorter frames with a 20-byte payload would be communicated much faster.

[0120] The following estimations consider three scenarios: A) a scenario in which a counter SN is used to derive the nonce N for a single channel with the maximum possible traffic on that channel; B) a scenario in which communication is distributed through 512 channels in a round-robin approach, with each channel having its own sequence number SN, and the nonce N is derived from these individual sequence number SNs; and C) a scenario in which a counter SN is used as the nonce N for a single channel with only 30% of the maximum possible traffic. The estimation results can be seen in the table below.

[0121] When implementing the serial number SN as a counter, it will be understood that a 32-bit length is too short in some scenarios. Naturally, scenarios A and C would not be sufficient considering the lifespan of the vehicle.

[0122] Similarly, a 37-bit bit length for a counter that implements the sequence number as nonce N is insufficient for scenarios A and C because 0.5 years for the short frame in scenario A is too short considering the lifespan of a car. The same applies to 1.5 years for the short frame in scenario C.

[0123] In contrast, a 44-bit or 64-bit counter bit length appears sufficient for both short and long frames across all three scenarios. In practice, some parts of the time span are so long that the actual values ​​are not represented and are indicated only by dashes. [Table 1]

[0124] Next, with reference to Figure 3B, we consider SADSE in mode AO, which is authentication only at transmitter S, that is, when authenticating protocol frame 100 as shown in Figure 2A. In this mode, the input stream of length le is not used. The use of key K is the same as described above. SADSE further receives sequence number SN and additional authentication data AAD as inputs.

[0125] The additional authentication data AAD, simply put, contains all the information of protocol frame 100, starting from header H and including the protected payload portion PP. If replay protection is not required, protocol frame 100 may not include the sequence number SN as described above in combination with Figure 2B. As a result of SN not being set, the nonce N can be left at a previously used value, or set to zero or any other suitable value. Naturally, the rules for setting the nonce N must be the same for both the transmitter S and the receiver R.

[0126] It will be understood that the frame compiled by transmitter S may include the generic instructions, first instructions and / or security instructions described above to indicate the level of authentication for the frame 100 compiled by transmitter S.

[0127] If only one generic key K is used as the secret key within a bus-based communication system, the protocol frame 100 does not need to include the security information SecInf field, as described with respect to Figure 2B.

[0128] As already explained with respect to Figure 2B, in situations where replay protection is not required and the generic key K is used in a bus-based communication system, the sequence number SN and security information SecInf fields can be omitted. As stated above, the nonce N can be left at a previously used value, or set to zero or any other suitable value. In this case as well, the rules for setting the nonce N must be the same for the transmitter S and the receiver R in order to authenticate and / or secure the given protocol frame 100.

[0129] In mode AO, which involves authentication only by transmitter S, SADSE outputs a tag T calculated using key K, nonce N, and additional authentication data AAD. Tag T is incorporated into protocol frame 100 as a security tag SecTag, thereby enabling the generation of an authenticated protocol frame 100.

[0130] Next, with reference to Figure 3C, we consider SADSE in the receiver R authentication-only mode at the data link layer level. In the receiver R authentication-only mode, the protocol frame 100 received at receiver R is authenticated as the original protocol frame intended to be transmitted from transmitter S to receiver. In other words, receiver R authenticates protocol frame 100 as shown in Figure 2A. In this mode, a security tag is used as tag T, which replaces the input stream P in Figure 3A. The use of key K and sequence number SN is the same as described above.

[0131] In receiver-only authentication mode AO, the additional authentication data AAD includes all information of protocol frame 100, starting from header H and extending to and including the protected payload portion PP. If replay protection is not required, protocol frame 100 may not include the sequence number SN as described above in combination with Figure 2B. As a result of SN not being set, the nonce N can be left at a previously used value, or set to zero or any other suitable value. Naturally, the rules for setting the nonce N must be the same for both the transmitter S and the receiver R.

[0132] Receiver R is configured to extract instructions from protocol frames. These instructions can be implemented as generic instructions, first instructions, and / or security instructions, as described above, to indicate the level of authentication for frame 100 received at receiver R.

[0133] If only one generic key K is used as the secret key within a bus-based communication system, the protocol frame 100 does not need to include the security information SecInf field, as described with respect to Figure 2B.

[0134] As already explained with respect to Figure 2B, in situations where replay protection is not required and the generic key K is used in a bus-based communication system, the sequence number SN and security information SecInf fields can be omitted. As stated above, the nonce N can be left at a previously used value, or set to zero or any other suitable value. In this case as well, the rules for setting the nonce N must be the same for the transmitter S and the receiver R in order to authenticate and / or secure the given protocol frame 100.

[0135] In mode AO, which involves authentication only at receiver R, SADSE outputs a tag T' calculated using key K, nonce N, and additional authentication data AAD. Tag T' is a recalculation of the security tag SecTag generated at transmitter S.

[0136] By comparing the internal security tag SecTag of the protocol frame 100 calculated in the transmitter S with the newly calculated tag T' in the receiver R, it becomes possible to authenticate whether the protocol frame 100 received in the receiver R is intended to be transmitted from the transmitter S to the receiver R, and further, whether the protocol frame 100 is in its original format.

[0137] It may be preferable for SADSE to directly output an authenticity indicator AI corresponding to the result of comparing the newly calculated tag T' with the security tag SecTag inside the protocol frame 100. If the security tag SecTag is input to SADSE, all information regarding this comparison can be used by SADSE.

[0138] This paper examines the authenticated encryption mode of SADSE, also known as AE mode.

[0139] Referring next to Figure 3D, the AE mode for SADSE in transmitter S is illustrated. As previously mentioned, SADSE receives key K and sequence number SN as input. The protected payload portion PP replaces the input stream of length le. Note that the protected payload portion PP is input as plaintext.

[0140] In AE mode on transmitter S, the additional authentication data AAD includes a header H and optional security information SecInf.

[0141] It will be understood that the frame compiled by transmitter S may include the generic instructions, first instructions, second instructions and / or security instructions described above to indicate the level of authentication and data protection for the frame 100 compiled by transmitter S.

[0142] If replay protection is not required, the protocol frame 100 may not include the sequence number SN as described above in combination with Figure 2B. As a result of SN not being set, the nonce N can be left at a previously used value, or set to zero or any other suitable value. Naturally, the rules for setting the nonce N must be the same for both the transmitter S and the receiver R.

[0143] If only one generic key K is used as the secret key within a bus-based communication system, the protocol frame 100 does not need to include the security information SecInf field, as described with respect to Figure 2B.

[0144] In this case as well, when replay protection is not required and the generic key K is used in a bus-based communication system, the sequence number SN and security information SecInf fields may be omitted. As mentioned above, the nonce N may be left at a previously used value, or it may be set to zero or any other suitable value. It should be noted that the rules for setting the nonce N must be identical on the transmitter S and receiver R in order to authenticate and / or secure a given protocol frame 100.

[0145] In AE mode on transmitter S, SADSE outputs a ciphertext cipher{protected payload PP}, which is the encrypted version of the protected payload PP, as an output stream C of length le. SADSE generates the ciphertext cipher{protected payload PP} based on the nonce N, the protected payload PP, and the additional authentication data AAD.

[0146] In AE mode on transmitter S, SADSE further outputs a security tag SecTag calculated using key K, nonce N, and additional authentication data AAD. The security tag SecTag is incorporated into protocol frame 100, thereby resulting in a protocol frame as described with respect to Figure 2B. As described above with respect to Figures 3B and 3C, the security tag SecTag can be used to authenticate that protocol frame 100 is intended to be transmitted from transmitter S to receiver, and further to authenticate that protocol frame 100 is in its original form.

[0147] In transmitter S, the protected payload PP is replaced with the output ciphertext cipher{PP} and a security tag SecTag is added to the protocol frame 100, resulting in an authenticated and encrypted protocol frame as described with respect to Figure 2C.

[0148] Figure 3E illustrates the AE mode for SADSE in receiver R. As previously mentioned, SADSE receives key K and nonce N as inputs. In receiver R's AE mode, the cipher{PP} of the protected payload portion replaces the input stream of length le. Note that the cipher{PP} of the protected payload portion is the encrypted version of the protected payload portion PP of the same length.

[0149] In AE mode at receiver R, the additional authentication data AAD contains all the information of protocol frame 100, starting from header H and extending to the protected payload portion PP, but excluding the protected payload portion PP. Thus, according to protocol frame 100 as described in Figure 2B, the additional authentication data AAD may include header H and optional security information SecInf.

[0150] If replay protection is not required, the protocol frame 100 may not include the sequence number SN as described above in combination with Figure 2B. As a result of SN not being set, the nonce N can be left at a previously used value, or set to zero or any other suitable value. Naturally, the rules for setting the nonce N must be the same for both the transmitter S and the receiver R.

[0151] The receiver R is configured to extract instructions from the protocol frame. These instructions can be implemented as generic instructions, first instructions, payload type, and / or security instructions, as described above, to indicate the level of authentication and data protection for the frame 100 received at the transmitter S.

[0152] If only one generic key K is used as the secret key within a bus-based communication system, the protocol frame 100 does not need to include the security information SecInf field, as described with respect to Figure 2B.

[0153] In this case as well, when replay protection is not required and the generic key K is used in a bus-based communication system, the sequence number SN and security information SecInf fields may be omitted. As mentioned above, the nonce N may be left at a previously used value, or it may be set to zero or any other suitable value. It should be noted that the rules for setting the nonce N must be identical on the transmitter S and receiver R in order to authenticate and / or secure a given protocol frame 100.

[0154] In AE mode on receiver R, SADSE outputs the protected payload portion PP as an output stream C of length le. SADSE generates a decrypted version of the cipher{PP} based on an optional sequence number SN as the nonce N, the cipher{PP}, and the additional authentication data AAD.

[0155] In AE mode at receiver R, SADSE outputs a tag T' calculated using key K, an optional sequence number as nonce N, and additional authentication data AAD. Tag T' is a recalculation of the security tag SecTag generated at transmitter S.

[0156] By comparing the internal security tag SecTag of the protocol frame 100 calculated in the transmitter S with the newly calculated tag T' in the receiver R, it becomes possible to authenticate whether the protocol frame 100 received in the receiver R is intended to be transmitted from the transmitter S to the receiver R, and further, whether the protocol frame 100 is in its original format.

[0157] It may be preferable for SADSE to directly output an authenticity indicator AI corresponding to the result of comparing the newly calculated tag T' with the security tag SecTag inside the protocol frame 100. However, this would require the security tag SecTag to be accessible to SADSE (not shown in Figure 3E).

[0158] One possible method for implementing SADSE as disclosed herein would be a block cipher mode. A notable example of such a block cipher mode is the AES Galois counter mode.

[0159] For AES-GCM, there are recommendations from the U.S. National Institute of Standards and Technology (NIST) regarding the bit lengths for the input and output values ​​of AES-GCM. Table 1 summarizes these parameters for authentication-only mode AO. [Table 2]

[0160] In authentication-only mode AO, the plaintext stream of le characters is not used, nor is the corresponding ciphertext over the protected payload PP as a plaintext stream, which corresponds to the description of SADSE's AO mode in Figures 3B and 3C.

[0161] With respect to the additional authentication data AAD, the length of 128*a bits indicates that an integer multiple of 128 bits should be selected to optimize the performance of the AES-GCM mode implementing the SADSE of this disclosure. Achieving a multiple of 128 bits is preferably possible by using zero padding. The counter CTR is an internal variable of the AES-GCM and is included for completeness as it is not used in AO mode.

[0162] Table 2 summarizes the bit lengths for the input and output parameters of AES-GCM implementing SADSE. [Table 3]

[0163] Unlike the authentication-only AO mode parameters in Table 1, the authenticated encryption mode AE ​​uses a counter implemented as a 32-bit value.

[0164] The ciphertext {PP} and additional authentication data AAD should be multiples of 128 bits in length to optimize the performance of AES-GCM implementing SADSE. Achieving zero-padding of such bit lengths is a preferred option.

[0165] Figure 4 shows a protocol frame according to the CAN standard. The CAN frame begins with a header H, which is formed by an 11-bit arbitration field followed by a 7-bit control field. Both the arbitration field and the control field are part of a CAN frame with a bit length that does not have a common denominator with the full byte length, as previously described as options for the protocol frame 100 of this disclosure in Figures 2A-2C. Note that the arbitration field can consist of 29 bits, according to the CAN standard and the CAN-FD standard, which are variations of the aforementioned CAN standard.

[0166] The 8-byte data field corresponds to the payload P of the original protocol frame 100 in Figure 2A. The 15-bit CRC field, along with the acknowledgment (Ack) slot bit, the acknowledgment (Ack) delimiter bit, and the 7-bit frame end, corresponds to the frame end portion (EOF) of the protocol frame as described in Figures 2A and 2C.

[0167] In AE mode, if it is desired to adapt the SADSE concept implemented as AES-GCM encryption mode using a single symmetric key K over a CAN network, two bytes of the original payload P can be used as the sequence number SN, and another two bytes can be used as the security tag SecTag, leaving a total of four bytes for the payload portion PP to be protected.

[0168] It may be preferable to set the sequence number SN as the first two bytes of the original payload P, because this allows for earlier detection of sequence number errors than if the two sequence number bytes were shifted further downstream in the original payload P.

[0169] Similarly, moving the security tag SecTag toward the end of the protected payload PP would prevent the protected payload portion from being segmented by the security tag SecTag. If segmented, parsing the CAN frame would become more complex. As an alternative, both the SecTag and the sequence number SN could be shifted toward the beginning of the protected payload portion PP.

[0170] This approach achieves protection against replay attacks while maintaining 50% of the original payload capacity P.

[0171] Table 3 summarizes the input and output parameter lengths for authentication-only mode AO, when the CAN frame includes the security tag SecTag and sequence number SN, for AES-GCM mode using a single generic key K within the CAN system, where the key size is 128 bits and the sequence number SN is 2 bytes. [Table 4]

[0172] In the example in Figure 4, the sequence number has a size of 2 bytes, corresponding to 16 bits. The key length of key K is 128 bits. The additional authentication data consists of a header with a total length of 18 bits and a protected payload PP of 4 bytes, corresponding to 32 bits, which brings the total to 50 bits as shown in Table 3. To achieve efficient calculation of AES-GCM, we consider zero-padding for the remaining 78 bits required to reach the 128-bit total length for AAD.

[0173] It will be understood that if we attempt to omit the sequence number SN in order to increase the available bytes for the protected payload PP to 6 bytes, the length values ​​listed in Table 3 will change further. This additional bit of protected payload comes at the cost of no protection against replay attacks. Of course, in exchange for this, depending on security requirements, we may decide to shorten the security tag SecTag to a size of less than 2 bytes in order to increase the available bytes for the protected payload portion PP.

[0174] Table 4 summarizes the input and output parameter lengths for AE mode when the key size is 128 bits, in the case of AES-GCM mode, which uses a single generic key K within the CAN system using sequence number SN. [Table 5]

[0175] The additional authentication data (AAD) in AE mode consists of a header with a total length of 18 bits. To achieve efficient AES-GCM computation, we consider zero-padding for the remaining bits required to reach the full 64-bit block size for the AAD.

[0176] It will be understood that if we attempt to omit the sequence number SN in order to increase the available bytes for the protected payload PP to 6 bytes, the length values ​​listed in Table 4 will change further. This additional bit of protected payload comes at the cost of no protection against replay attacks. Of course, in exchange for this, depending on security requirements, we may decide to shorten the security tag SecTag to a size of less than 2 bytes in order to increase the available bytes for the protected payload portion PP.

[0177] One variation of implementing SADSE functionality for CAN bus communication systems is to consider block ciphers with shorter block sizes than AES-GCM. Simon and Speck is an example of such a lightweight cipher as defined by the U.S. National Security Agency. Table 5 summarizes the various block and key sizes for the Simon and Speck block cipher family. [Table 6]

[0178] We consider a 64-bit key size for a Simon and Speck block cipher that uses a single generic key K within a CAN system having an 18-bit header size, a sequence number SN, and a 2-byte security tag SecTag.

[0179] Table 6 summarizes the input and output parameter lengths for authentication-only AO mode when the CAN frame includes the security tag SecTag and sequence number SN.

[0180] As can be seen from Table 6, the plaintext stream and ciphertext are 32 bits long, which corresponds to exactly one block size. Therefore, zero padding is not required for these fields as in the case of AES-GCM, and Simon and Speck's operation is more efficient than AES-GCM for CAN frames. [Table 7]

[0181] It will be apparent to those skilled in the art that shortening or omitting the sequence number SN and / or security tag SecTag can increase the protected payload portion PP, but this comes at the cost of a reduced level of protection for the CAN frame.

[0182] The additional authentication data is 50 bytes long, as in the case of AES-GCM described above. This length falls between the size of one block and two blocks of the 32-bit Simon and Speck block size, and therefore requires zero padding.

[0183] Table 7 summarizes the input and output parameter lengths for authenticated encryption modes when the CAN frame includes the security tag SecTag and sequence number SN. [Table 8]

[0184] As can be seen from Table 7, the plaintext stream and ciphertext are 32 bits long, exactly corresponding to one block size. Therefore, zero padding is not required for these fields, as in the case of AES-GCM, and in this respect, Simon and Speck's operation is more efficient than AES-GCM for CAN frames. However, the additional authentication data AAD is shorter than the full block size, as is the case with AES-GCM described in the example above, and therefore requires zero padding.

[0185] The exemplary implementations described above are merely illustrative. Modifications and changes to the configurations and details described herein will be obvious to those skilled in the art. Therefore, it is intended that the scope is limited only by the claims of the pending patent application and not by any specific details presented in the description and explanation of the implementations herein.

Claims

1. A protocol frame (100) for communication between participants in a bus-based communication system within a vehicle according to a protocol, The protocol frame includes a header (H), the header (H) indicating the start of the protocol frame to be communicated between a transmitter (S) and a receiver (R), and both the transmitter (S) and the receiver (R) are participants in the bus-based communication system. The protocol frame includes instructions, which are configured to indicate the level of authenticity or data security of the protocol frame (100) on the data link layer. Protocol frame (100).

2. The instruction includes a first instruction configured to indicate authentication at the data link layer level for the protocol frame (100), The protocol frame (100) according to claim 1.

3. The instructions include a second instruction configured to indicate both authentication and data security at the data link layer level for the protocol frame (100). The protocol frame (100) according to claim 1 or 2.

4. At least one of the above instructions, the first instruction, or the second instruction is is part of the header (H) of the protocol frame (100), This is expressed as the payload type (pt) of the protocol frame (100), or Represented as a security instruction flag or bit field within the header, At least one of ours The protocol frame (100) according to claim 3.

5. The protocol frame (100) is The security information (SI) downstream of the header (H), The protected payload portion (PP) downstream of the header (H), It further includes, The security information (si) indicates the level of protection for the protected payload portion (PP). A protocol frame (100) according to any one of claims 1 to 4.

6. The aforementioned security information is The virtual channel between the transmitter and the receiver, or One or more keys Further configured to show at least one of the following, The protocol frame (100) according to claim 5.

7. The instruction, combined with the security information (si), indicates whether authentication only or authentication and data protection are applied to the protocol frame (100). The protocol frame (100) according to claim 5.

8. The security information (si) is further configured to indicate a security association that indicates a key (K) to be selected for authentication at the data link layer level for the protocol frame (100), or for authentication and data security. The protocol frame (100) according to claim 5 or 6.

9. The protocol frame (100) further includes a security tag (SecTag), The security tag (SecTag) is configured to verify the authenticity of the protocol frame (100) as the original protocol frame intended to be transmitted from the transmitter to the receiver at the data link layer level. The security tag (SecTag) is configured to verify the authenticity of the protocol frame at the transmitter on the data link layer or at the receiver on the data link layer. The protocol frame (100) according to claims 1 to 8.

10. The protocol frame (100) has a length N and is used with the Controller Area Network (CAN) standard, the CAN Flexible Data Rate standard, or the CAN Extra Large standard. The protocol frame (100) according to claims 1 to 9.

11. The protocol frame selectively has a length N of 8 bytes, 8 to 64 bytes, or 64 to 2048 bytes. The protocol frame according to claims 1 to 9.

12. A data link layer transmitter (S) configured to participate in a bus-based communication system within a vehicle, The aforementioned transmitter (S) A header (H) is generated in response to a request from a higher protocol layer. Access the key (K) which is kilobyte long, Upon receiving the payload portion (PP) protected from the aforementioned higher protocol layer, Aggregate additional authentication data (AAD), A security tag (SecTag) for verifying the authenticity of the frame as the original frame transmitted from the transmitter (S) to the receiver (R) at the data link layer level is generated using the key (K) and the additional authentication data (AAD). A protocol frame (100) is generated, which includes the header (H), the protected payload portion (PP), and the additional authentication data (AAD). It is configured in such a way, The transmitter (S) is configured to communicate the protocol frame from the transmitter (S) to one or more participants in the bus-based communication system at the data link layer level. Transmitter (S).

13. The bus-based communication system is a broadcast-based bus system, and therefore all nodes within the bus-based communication system are configured to receive the protocol frame (100) communicated by the transmitter (S). The transmitter (S) according to claim 12.

14. The protocol frame (100) further includes instructions configured to indicate the level of authenticity or data security of the protocol frame (100) on the data link layer. The transmitter according to claim 12 or 13.

15. The above instructions are, A first instruction configured to indicate authentication at the data link layer level for the protocol frame, or A second instruction configured to indicate both authentication and data security at the data link layer level for the protocol frame. including, The transmitter (S) according to claim 14.

16. In the mode for authentication only of the transmitter, the additional authentication data is: The header (H) and, The protected payload portion (PP) and, That is, A transmitter (S) according to any one of claims 12 to 15.

17. In the authenticated encryption mode, the transmitter (S) Key (K) and, The protected payload portion (PP) in plain text, The header (H) as additional authentication data (AAD), It is further configured to use to generate ciphertext for the protected payload portion, The transmitter (S) according to claims 12 to 14.

18. The transmitter (S) is further configured to generate an sn-byte sequence number (SN) downstream of the header (H), The transmitter (S) is configured to incorporate the sequence number (SN) into the protocol frame (100) at the expense of shortening the protected payload, wherein the shortened protected payload is shortened by sn bytes compared to the protected payload portion (PP). A transmitter (S) according to any one of claims 12 to 15.

19. The transmitter (S) is configured to generate security information (SecInf) of length si using the key K. The transmitter (S) is further configured to incorporate the security information into the protocol frame downstream of the header (H) at the expense of shortening the payload, wherein the shortened payload is shortened by si bytes compared to the protected payload (PP). The security information (SecInf) indicates the level of protection for the protected payload portion. A transmitter (S) according to any one of claims 12 to 18.

20. In the authenticated encryption mode, the transmitter is further configured to generate security information of si-byte length. The transmitter is further configured to incorporate the security information into the protocol frame downstream of the header at the expense of shortening the protected payload, wherein the shortened protected payload is shortened by si + sn bytes compared to the original protected payload. The security information indicates the level of protection for the shortened and protected payload. A transmitter according to any one of claims 12 to 14 or claim 17.

Images