Authenticity and security in data link layer for automotive communication system

Abstract

To provide authenticity and data security for bus based communication networks in a vehicle.SOLUTION: There is provided a protocol frame for communication between participants of a communication system, the protocol frame comprising: a header indicating a start of the protocol frame to be communicated between a sender and a receiver, both the sender and the receiver being participants of the bus based communication system; a protected payload portion PP downstream the header; and a security tag SecTag configured to indicate authenticity of the protocol frame as an original protocol frame between the sender and the receiver on data link layer level.SELECTED DRAWING: Figure 2B

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. Conventionally, some functions such as steering were provided by a physical connection from the steering wheel to the vehicle's wheels. The same applies to the braking and gearshift functions. However, in today's vehicles, such a physical connection no longer exists, and instead, an electrical wire or bus is provided to transmit steering commands to the electric power steering. In response to a steering command via the bus, the electric power steering will actuate the rotation of the wheels corresponding to the rotation of the steering wheel.

[0003] If access to the bus is possible, there is a risk that an attempt may be made to deprive the vehicle of its functions and malicious bus communication or commands may be inserted. The risk of malicious bus commands being inserted is further increased by the development of entertainment functions or connectivity brought about by today's vehicles.

[0004] In the case of a vehicle or automobile performing autonomous driving, since sensor data for analyzing the surroundings of the vehicle and commands to actuators for controlling the vehicle can be realized as bus communication, this risk is further increased.

[0005] One way to reduce this risk is to provide authenticity and security for such bus communication at the data link layer level without burdening the upper protocol layer with these authenticity and / or security issues.

Summary of the Invention

Means for Solving the Problems

[0006] Support for the claims shall be considered complete at the time when the examination of the claims has been concluded.

[0007] Embodiments will now be described with reference to the accompanying drawings.

Brief Description of the Drawings

[0008]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 2C

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 4

Embodiments for Carrying Out the Invention

[0009] FIG. 1A shows an exemplary bus connecting a plurality of nodes, namely Node 1, Node 2 to Node n. In the case of the embodiment of FIG. 1A, the bus is shown as a two-wire bus system, which can preferably be implemented as two differential lines. Of course, other configurations are also conceivable. The bus system can be terminated by optional termination resistors T1, T2, and these termination resistors T1, T2 can generally be important for reducing reflections on the bus that affect the signal quality along the bus. Well-known examples of bus systems in vehicles are CAN, CAN-FD, CANXL, or LIN networks. Although the present disclosure focuses on variations of CAN, as will be apparent to those skilled in the art, the teachings of the present disclosure can be similarly applied to other bus systems.

[0010] It will be understood that the bus shown in FIG. 1A can also be arranged in a ring topology, in which case both ends of the bus are supplied to a master unit (not shown), thereby forming a bus loop. The individual nodes, namely Nodes 1, 2 to n, will be coupled to this bus as described above.

[0011] It should be understood here that a vehicle network or a bus-based communication system (such as that shown in FIG. 1A) has specific attributes that reflect the requirements for the vehicle network. The vehicle network supports the communication of sensor data to the control unit by data frames transmitted from a sensor or a control unit of the sensor to a higher-level control unit. A useful protocol can be used for the data frames or protocol frames transmitted between the individual nodes or participating devices of the bus-based communication network.

[0012] In response to or in reply to the reception of sensor data, the control unit of the sensor or the upper-level control unit can transmit a predetermined action, such as a braking action to a brake actuator, to the actuator coupled to the bus. Thus, in the embodiment of FIG. 1A, node 1 can comprise an angle sensor (not shown) that measures the angle to which the brake pedal is depressed. This angle can be transmitted as a protocol frame to an upper-level ECU, such as node 2. In response to the reception of this angle value, the ECU can transmit one or more bus frames to node N, i.e., to the brake actuator. These bus frames transmitted from the ECU to the brake actuator can cause a braking action.

[0013] Obviously, the bus communication related to the braking action is time-critical and must be transmitted at high speed. Such real-time requirements are not common in standard communication networks.

[0014] A vehicle communication network generally has a clearly defined number of bus-attached devices, which, by default, remains constant over the life of the vehicle, ignoring some short-term vehicle upgrades. Similarly, the links existing between individual nodes, and thus the topology of the bus-based communication system, do not change over the life of the vehicle. In the case of a standard computer network, such a situation is highly unlikely to occur. In fact, this is necessary in the case of a standard computer network to allow nodes to be added or removed during the operation of the computer network. Furthermore, during the operation of a standard computer network, new links can be provided or existing links can be removed.

[0015] In a bus-based communication system that controls vehicle functions, it is important to ensure the authenticity of protocol frames transmitted via the bus. Considering the braking action, the command to cause an emergency braking must not be mistaken for the gentle braking when parking the vehicle in a controlled manner. For this reason, the authenticity indication of protocol frames transmitted between the participating devices of the bus-based communication system becomes important.

[0016] It will be understood that the authenticity indication of protocol frames at the data link layer is important for the purpose of reducing the involvement of upper protocol layers in the authentication of time-critical commands transmitted between the participating devices of the bus-based communication system.

[0017] As entertainment systems and vehicle-to-vehicle communications become increasingly available today, malicious commands or protocol frames are becoming more likely to be inserted into the communication system.

[0018] Therefore, it is important to provide data security for protocol frames for the purpose of preventing the insertion of malicious protocol frames. It is also attractive to provide data security at the data link layer level with respect to the authenticity indication of protocol frames. In this way, the involvement of upper protocol layers or software stacks on upper protocol layers that provide security and / or authenticity information becomes unnecessary. As is obvious to those skilled in the art, the functions of data security and authenticity can be preferably supported by hardware elements such as transmitters or receivers on the protocol layer. In other words, when implementing the functions of data security and authenticity at the data link layer level, these functions can be taken over by dedicated hardware at the data link layer level.

[0019] Figure 1B shows nodes 1 and 2, which are subscriber devices of the bus-based communication system shown in Figure 1A. Communication between node 1 and node 2 proceeds in various layers that can be classified according to the well-established OSI-ISO layer model. The lowest layer is the so-called physical layer, which is shown as PHYS for nodes 1 and 2. Each layer in the OSI model can receive instructions from a higher level, perform some action at its own level, and trigger a task at the level below by transferring a request to the level below.

[0020] Instructions to the physical layer can be received 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 layer, the physical layer of node 1 can use a connection or link to node 2 for the purpose of transmitting data on 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 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 node 1 in Figure 1B. The protocol flow at node 2 is the same as that described for node 1.

[0021] A part of the existing bus-based communication network in the vehicle does not conform to the separation of the physical layer and the data link layer as proposed in the OSI-ISO model. To reflect such particularities, in Figure 1B, transmitter S and receiver R are shown as spanning the physical layer PHYS and the data link layer.

[0022] Known concepts regarding the authenticity of data communication in a vehicle are implemented in the application layer on layer 7 of the OSI-ISO layer model using the software stacks shown as App1 and App2 for Node1 and Node2 respectively in Figure 1B. What may be suitable in this case is to introduce the concept of a virtual channel between Node1 and Node2 in order to indicate authentication and / or protected communication between two or more participating devices using the software stacks App@Node1 and App@Node2.

[0023] One example of providing security for an in-vehicle network in a vehicle using a software stack is SEC OC ( S ecure O nBoard C ommunication) according to the AUTOSAR standard. What may be suitable for an OEM is to include the software stack App for Node1 and Node2 in the specification, thereby giving freedom in the hardware implementation of Node1 and Node2. As a trade-off, by implementing authenticity and / or data security using a software stack, real-time requirements can no longer be met regarding the actuator response to a command from an electronic control unit (ECU) to an actuator participating in the bus-based communication system shown as Node n in Figure 1A. For example, consider a braking command transmitted as protocol frame 100 (shown most clearly in Figures 2A - 2C or Figure 4) from the control unit ECU illustrated as Node2 in Figure 1A towards a braking actuator, for example Node n in Figure 1A. If such communication were to be authenticated and protected using a software stack, all layers for each individual node would be involved in this protection, and for a reliable braking operation, such protection could take too much time.

[0024] A further drawback of the solution of authenticity and / or data security by means of a software stack can be that the software stack is not properly designed and its authenticity and / or security functions are degraded or, on the contrary, may be at risk.

[0025] Therefore, depending on the situation, it can be attractive to limit the functions related to authenticity and / or data security to a single layer of individual subscriber devices to the communication system, such as node 1 or node 2 in FIG. 1B. By restricting the functions of authenticity and / or data security to the data link layer, it is possible to prevent other protocol layers from being occupied by part of the operation of data integrity and / or data security.

[0026] As another advantage, a protocol frame 100 for which authenticity may not be established can be discarded already on the data link layer. That is, if it is shown by an authenticity test that the protocol frame 100 was not intended to be transmitted from the transmitter to the receiver and / or did not reach the receiver in its original form, then the protocol frame 100 can be discarded without further processing. Therefore, an attempt to flood a single subscriber device of a bus-based communication system on the data link layer with invalid or unauthenticated frames 100 will only affect this single node on the data link layer, while the upper protocol layers can remain unaffected. In the case of a software stack-based approach to authenticity and / or data security, it would be impossible to confine the action of authenticity and / or data security in this way.

[0027] Even more preferred is to use dedicated hardware elements, i.e., to use the transmitter on the data link layer and / or the receiver on the data link layer that implements authenticity and / or data security as parts of dedicated hardware. This will have further advantages, i.e., when considering a CAN bus transceiver, such a building block can be used as a standard circuit without the need for further investigation or adaptation even if the software application App in the bus participating device or its participating device changes over time.

[0028] Hereinafter, an example of the protocol frame 100 that implements various levels of authentication and / or data security on the data link layer will be described with reference to FIGS. 2A to 2C.

[0029] FIG. 2A shows an original protocol frame 100 having a total length of N bytes, where N is an integer. The protocol frame 100 can include a header H, a payload P, and a frame end indication EOF. The header H can have a length of h bytes, where h is an integer smaller than N. The payload P can have a length of p bytes. The frame end indication EOF can have a length of eof bytes.

[0030] In FIG. 2A, a payload P is shown downstream of a header H, and a frame end portion EOF is shown downstream of the header H and downstream of the payload P. It will be understood that summing the lengths of the header H, the payload P, and the frame end indication results in the total length of N bytes of the protocol frame 100. It should further be understood that the length of each of the individual elements, namely the header H, the payload P, or the EOF, can be of a bit length that cannot be fully represented in units of one complete byte length. In such a case, the total length of the protocol frame can be maintained at N bytes, but the individual segments of the protocol frame 100 can have sub-byte level lengths. It should also be noted that according to the protocol, the total length of the protocol frame 100 can be a number of bits that cannot be fully represented in units of byte length.

[0031] The header H can be used to indicate the start of the protocol frame 100, the length N of the frame, the protocol or protocol variation being complied with.

[0032] Permissions or priorities associated with the protocol frame 100 can be indicated within the header H. Such options are generally shown in the protocol specification.

[0033] In FIG. 2A, a payload P is shown downstream of a header H, and a frame end portion EOF is shown downstream of the header H and downstream of the payload P. This rule regarding the relationship along the flow will be used throughout the present disclosure.

[0034] It is further contemplated that the protocol permits the protocol frame 100 to have a variable frame length N. The total frame length N can be varied, for example, according to the amount of information conveyed by individual instances of the protocol frame 100.

[0035] In a vehicle environment, it is likely that older devices and more recent devices, each following different protocol variations, will operate simultaneously. As an example, a fairly old device, such as an ABS sensor, may communicate according to an earlier variation of a protocol, such as the CAN protocol (CAN is short for Controller Area Network), while a more recent device, such as a LIDAR system, may communicate with an electronic control unit using the CAN-FD (CAN-FD is short for Controller Area Network flexible-data rate) standard or even the CANXL standard. Therefore, it can be useful to indicate various different protocol types within the header H, because the protocol type will also affect the level of authenticity and / or data protection applied to an individual protocol frame 100.

[0036] In such a situation, it may be important that the total frame length in N bytes or N bits is stored or encoded somewhere within the protocol frame 100. Setting a frame length flag would be one option for a technique that enables encoding the frame length. Techniques for enabling storage of this kind of information within the protocol frame 100 can be obtained from the protocol specification.

[0037] The frame end indication EOF can further include error checking information, as is known in the art, and therefore will not be described further here.

[0038] FIG. 2B shows an example of a protocol frame according to the present disclosure. The protocol frame 100 can include a header H similar to the original protocol frame of FIG. 2A. The protocol frame 100 of FIG. 2B has a length of N bytes or N bits as described above. Different from the standard protocol header, the header H of FIG. 2B includes a protected payload portion PP. The protected payload portion PP is shortened to make space for a security tag SecTag that may have a length of st bytes. The protocol frame 100 according to the present disclosure can optionally include security information of si bytes, where si is an integer. The protocol frame according to FIG. 2B can further optionally include a sequence number SN of length sn. Without limitation, the lengths st, si, sn, or pp may or may not be representable in units of one complete byte length as previously described with reference to FIG. 2A.

[0039] The security tag SecTag can represent an authentication indication that the protocol frame 100 was intended to be transmitted from the transmitter S to the receiver R at the data link layer level. Further, it can be checked by the security tag SecTag whether the protocol frame 100 has been modified on the way to the receiver R.

[0040] Although the security tag SecTag is shown downstream of the protected payload portion PP, without limitation, it is equally possible to place it upstream of the protected payload portion PP or even incorporate it within the standard header H.

[0041] It will be understood that a secret key K is required for authentication, encryption, and decryption. The key deployment is not central to the present disclosure for several reasons as follows.

[0042] First, in the automotive environment, the number of subscriber devices in a bus-based communication system is limited and does not change much over the life of the vehicle. What can be suitable is to use one key K of length k for all subscriber devices on the bus communication system.

[0043] If individual nodes communicatively coupled via the bus communication system are to use individual keys K, those individual keys can be stored in respective nodes of the bus-based communication system during vehicle manufacture. That is, a first key K1 for communication between node 1 and node 2 can be stored in node 1 and node 2, a second key K2 for communication between node 1 and node 3 can be stored in node 1 and node 3 respectively, and so on. Here, the premise is that the transmitter S and the receiver R use the same key K, and thus, decryption, encryption, authentication, and verification are symmetric.

[0044] What can become important when two or more keys K are used within the system is that information regarding the key K involved in authentication and / or data security can be stored or indicated in an optional security information field SecInf. A further option is to use the security information field to indicate whether the current protocol frame 100 is an authentication-only protocol frame or an authenticated encryption protocol frame 100.

[0045] The field sequence number SN is a further optional element in the protocol frame 100. The sequence number SN is an integer that is used only once and is also called a nonce. If the sequence number SN is changed in a way that is not known to eavesdroppers, that can help prevent the success of a replay attack. For the purpose of preventing replay attacks, the AUTOSAR standard has proposed a similar concept using a freshness value.

[0046] When replay protection is required, as the simplest implementation of authentication and / or data security on the data link layer, an authentication-only scheme can be implemented using one frame that includes a sequence number SN. If such protection is not required, the sequence number SN can be omitted, thereby increasing the protected payload portion PP within the protocol frame 100.

[0047] Depending on the situation, it may be decided that there is only one key K in the system used for authentication. In that case, the field security information including this type of information regarding the various keys K1, K2, K3... to be used can be omitted, thereby increasing the protected payload portion PP.

[0048] If neither the various keys K1, K2, K3... nor replay protection is required, both the field sequence number SN and the security information SecInf can be omitted, thereby further increasing the protected payload portion PP compared to the protocol frame shown in Figure 2B. In this case, only the security tag SecTag reduces the protected payload field PP compared to the standard protocol frame.

[0049] Figure 2C shows an authenticated encryption protocol frame 100 according to the present disclosure. The protocol frame 100 in Figure 2C includes a header H, a frame end indication EOF, a security tag SecTag, an optional field sequence number SN, and optional security information SecInf, as described with reference to Figure 2B. The protocol frame in Figure 2C is of the same length as the protocol frames in Figures 2A and 2B. As described above, the individual frame elements, the header H, the optional sequence number SN, and the total frame length N can be any integer number of bytes, or any other length that cannot be represented in units of one complete byte length.

[0050] The protocol frame 100 in FIG. 2C includes the ciphertext cipher{PP} of the protection payload PP instead of the protection payload PP. The protocol frame in FIG. 2C is of the same length as the protocol frames in FIGS. 2A and 2B. As described above, the header H, the optional sequence number SN, and the total frame length N, which are individual frame elements, can be any integer number of bytes, or any other length that cannot be represented in units of one complete byte length.

[0051] One preferred method for implementing authenticity and / or data security protection for the protocol frame 100 at the data link layer level is to use a so-called symmetric authentication and / or data security engine, implemented as a hardware block and also referred to as SADSE, which will be described in more detail below with reference to FIGS. 3A - 3E.

[0052] FIG. 3A shows the input values and output values for SADSE. The naming of the input and output variables of SADSE follows the naming rules established for block cipher modes in cryptographic literature. It will be understood that SADSE is operable in an authentication-only AO mode or in an authenticated encryption mode AE. SADSE receives as input the secret key K, the optional nonce N, the input stream P of length le characters, and the auxiliary authentication data AAD. The key K is preferably a symmetric key of a predetermined length, such as 128 bits, 192 bits, or 256 bits, for example. As described above, key distribution is not central to this disclosure. In practice, corresponding schemes such as MACsec Key Agreement defined in IEEE 802.1X - 2010 are known. The optional nonce N is generally an integer value that is used only once. Depending on the situation, it may be decided to have the same value for N for two or more protocol frames 100.

[0053] The input stream P has different uses according to the operating mode of SADSE. The auxiliary authentication data AAD includes some bits of additional data used in authentication, as further described below.

[0054] SADSE can supply an output stream of length le characters and further output a tag T, or alternatively directly output an authentication indication AI. The output stream of length le has different uses and meanings according to the operating mode of SADSE.

[0055] The tag T can be considered to be calculated based on the input variables used by SADSE and to recalculate the security tag SecTag defined as above. Depending on the situation, it may be suitable in the case of SADSE to directly output the comparison result between the security tag SecTag within the protocol frame 100 and the newly calculated tag T. This comparison result can be represented by the authenticity indication AI. That is, the authenticity information AI indicates whether the protocol frame 100 was intended to be sent from the specified transmitter S to the specified receiver R (generally both are described in the header H). Further, the authenticity indication AI indicates whether the protocol frame 100 is in its original form.

[0056] Next, let's consider SADSE in the dedicated authentication mode AO at the transmitter S with reference to Figure 3B. That is, this is the case of authenticating the protocol frame 100 according to Figure 2A. In this mode, the input stream of length le is not used. The use of the key K is the same as before. SADSE further receives the sequence number SN and the auxiliary authentication data AAD as inputs.

[0057] Auxiliary authentication data AAD, to put it simply, includes all the information of protocol frame 100 from the header H to the protected payload part PP. If replay protection is not required, the protocol frame 100 may not include the sequence number SN as described above while using FIG. 2B in combination. As a result of the SN not being set, the nonce N may be left with the previously used value, or it may be set to zero or any other suitable value. Of course, the rules for setting the nonce N must be the same at the transmitter S and the receiver R.

[0058] In a bus-based communication system, if only one general-purpose key K is used as the secret key, the protocol frame 100 may not include the security information SecInf field as described with reference to FIG. 2B.

[0059] As already described with reference to FIG. 2B, in a situation where replay protection is not required and the general-purpose key K is used in a bus-based communication system, the sequence number SN and the security information SecInf field can be omitted. As described above, the nonce N may be left with the previously used value, or it may be set to zero or any other suitable value. Also in this case, the rules for setting the nonce N must be the same at the transmitter S and the receiver R for authenticating and / or protecting a given protocol frame 100.

[0060] In the authentication-only mode AO at the transmitter S, the SADSE outputs a tag T calculated using the key K, the nonce N, and the auxiliary authentication data AAD. The tag T can be incorporated into the protocol frame 100 as the security tag SecTag, thereby generating an authenticated protocol frame 100.

[0061] Next, let's consider the SADSE in the dedicated authentication mode at the data link layer in the receiver R while referring to FIG. 3C. The dedicated authentication mode in the receiver R authenticates the protocol frame 100 received in the receiver R as the original protocol frame intended to be transmitted from the transmitter S to this receiver. In other words, the receiver R authenticates the protocol frame 100 according to FIG. 2A. In this mode, the security tag is used as the tag T instead of the input stream P in FIG. 3A. The use of the key K and the sequence number SN remains the same as before.

[0062] In the dedicated authentication mode AO at the receiver, the auxiliary authentication data AAD includes all the information of the protocol frame 100 from the header H to the protected payload part PP including this part. If replay protection is not required, the protocol frame 100 may not include the sequence number SN as described above while using FIG. 2B in combination. As a result of the SN not being set, the nonce N may be left as the previously used value, or may be set to zero or any other suitable value. Of course, the rule for setting the nonce N must be the same in the transmitter S and the receiver R.

[0063] In a bus-based communication system, if only one general-purpose key K is used as the secret key, the protocol frame 100 may not include the security information SecInf field as described with reference to FIG. 2B.

[0064] As already explained with reference to FIG. 2B, in situations where replay protection is not required and the general-purpose key K is used in a bus-based communication system, the sequence number SN and the security information SecInf field can be omitted. As previously explained, the nonce N may be left at its previously used value, or set to zero or any other suitable value. Also in this case, the rule for setting the nonce N must be the same in the transmitter S and the receiver R in order to authenticate and / or protect a given protocol frame 100.

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

[0066] By comparing the security tag SecTag within the protocol frame 100 calculated at the transmitter S with the newly calculated tag T' at the receiver R, it is possible to authenticate whether the protocol frame 100 received at the receiver R was intended to be transmitted from the transmitter S to the receiver R, and further to authenticate whether the protocol frame 100 is in its original form.

[0067] What may be suitable in the case of SADSE is to directly output an authenticity indication AI corresponding to the comparison result between the newly calculated tag T' and the security tag SecTag within the protocol frame 100. If the security tag SecTag is input to the SADSE, all information for this comparison is available in the SADSE.

[0068] Let's consider the authenticated encryption mode of SADSE, also called the AE mode.

[0069] Here, with reference to FIG. 3D, the AE mode for SADSE in the transmitter S will be described. As described above, SADSE receives the key K and the sequence number SN as inputs. The protected payload part PP serves as an alternative to the input stream of length le. Note that it should be noted that the protected payload part PP is input as plaintext.

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

[0071] If replay protection is not required, the protocol frame 100 may not include the sequence number SN as described above while using FIG. 2B in combination. As a result of the SN not being set, the nonce N may be left as the previously used value, or may be set to zero or any other suitable value. Of course, the rule for setting the nonce N must be the same in the transmitter S and the receiver R.

[0072] In a bus-based communication system, if only one general-purpose key K is used as the secret key, the protocol frame 100 may not include the security information SecInf field as described with reference to FIG. 2B.

[0073] Also in this case, in a situation where replay protection is not required and the general-purpose key K is used in a bus-based communication system, the sequence number SN and the security information SecInf field can be omitted. As described above, the nonce N may be left as the previously used value, or may be set to zero or any other suitable value. Note that it should be noted that the rule for setting the nonce N must be the same in the transmitter S and the receiver R for authenticating and / or protecting a given protocol frame 100.

[0074] In the AE mode at the transmitter S, SADSE outputs the 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.

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

[0076] At the transmitter S, replacing the protected payload PP with the output ciphertext cipher{PP} and adding the security tag SecTag to the protocol frame 100 results in an authenticated encryption protocol frame as described with reference to Figure 2C.

[0077] Next, with reference to Figure 3E, the AE mode for SADSE at the receiver R will be described. As described above, SADSE receives the key K and the nonce N as inputs. In the AE mode of the receiver R, the ciphertext cipher{PP} of the protected payload part serves as the substitute for the input stream of length le. Note that it should be noted that the protected payload ciphertext cipher{PP} is the encrypted version of the protected payload part PP of the same length.

[0078] In the AE mode at the receiver R, the auxiliary authentication data AAD includes all the information of the protocol frame 100 starting from the header H up to, but not including, the protected payload part PP. Thus, according to the protocol frame 100 described in FIG. 2B, the auxiliary authentication data AAD can include the header H and the optional security information SecInf.

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

[0080] In a bus - based communication system, if only one general - purpose key K is used as the secret key, the protocol frame 100 may not include the security information SecInf field as described with reference to FIG. 2B.

[0081] Also in this case, in a situation where replay protection is not required and the general - purpose key K is used in a bus - based communication system, the sequence number SN and the security information SecInf field can be omitted. As described above, the nonce N may be left with its previously used value, or it may be set to zero or any other suitable value. Note that the rules for setting the nonce N must be the same at the transmitter S and the receiver R for authenticating and / or protecting a given protocol frame 100.

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

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

[0084] By comparing the security tag SecTag within the protocol frame 100 calculated at the transmitter S and the newly calculated tag T' at the receiver R, it is possible to authenticate whether the protocol frame 100 received at the receiver R was intended to be transmitted from the transmitter S to the receiver R, and further to authenticate whether the protocol frame 100 is in its original form.

[0085] What may be preferably applicable in the case of SADSE is to directly output an authenticity indication AI corresponding to the comparison result between the newly calculated tag T' and the security tag SecTag within the protocol frame 100. However, for this purpose, it is required that SADSE be able to access the security tag SecTag (not shown in FIG. 3E).

[0086] One possible approach for implementing SADSE in accordance with the present disclosure would be a block cipher mode. A well-known example of such a block cipher mode is the AES Galois counter mode.

[0087] Regarding AES-GCM, there are recommendations by NIST, i.e., the National Institute of Standards and Technology of the United States, regarding the individual bit lengths of the input and output values of AES-GCM. Table 1 summarizes those parameters for the authentication-only mode AO.

Table 1

[0088] In the case of the authentication-only mode AO, the plaintext stream of the le character is not used in the same way as the corresponding ciphertext for the protection payload PP as the plaintext stream, which corresponds to the description of the AO mode of SADSE with reference to FIGS. 3B and 3C.

[0089] Regarding the auxiliary authentication data AAD, 128 * The fact that the length is a bits means that, in order to optimize the performance of the AES-CGM mode implementing the SADSE of the present disclosure, an integer multiple a of 128 bits should be selected. Reaching a multiple of 128 bits can preferably be achieved using zero padding. The counter CTR is an internal variable of AES-GCM and is reproduced for completeness but is not used in the AO mode.

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

Table 2

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

[0092] The ciphertext cipher{PP} and the auxiliary authentication data AAD are preferably multiples of 128-bit length for the optimal performance of AES-GCM implementing SADSE. For the purpose of achieving such a bit length, zero padding is a suitable option.

[0093] FIG. 4 shows a protocol frame according to the CAN standard. The CAN frame starts with a header H formed by an 11-bit arbitration field followed by a 7-bit control field. Both the arbitration field and the control are parts of the CAN frame with bit lengths that cannot be fully represented in units of one full byte length, as already explained as an option for the protocol frame 100 according to the present disclosure in FIGS. 2A-2C. Note that the arbitration field can be made to consist of 29 bits according to the CAN standard and the CAN-FD standard, and it should be noted that these are variations of the CAN standard as described above.

[0094] The 8-byte data field corresponds to the payload P of the original protocol frame 100 according to FIG. 2A. The 15-bit CRC field corresponds to the frame end portion EOF of the protocol frame described with reference to FIGS. 2A-2C, together with the positive response slot bit and the positive response delimiter bit, as well as the 7 bits at the end of the frame.

[0095] If one wants to adapt the SADSE concept implemented as the AES-GCM cipher mode in the AE mode using one symmetric key K via the CAN network, 2 bytes of the original payload P can be used as the sequence number SN, and another 2 bytes can be used as the security tag SecTag, leaving a total of 4 bytes for the protected payload portion PP thereby.

[0096] What can be preferably done in this case is to set the sequence number SN as the first 2 bytes of the original payload P, because an incorrect sequence number will be detected earlier than in the case where the two sequence number bytes are shifted further downstream from the original payload portion P.

[0097] Similarly, when the security tag SecTag is moved towards the end of the protected payload PP, the protected payload part is prevented from being segmented by the security tag SecTag, which would otherwise make the CAN frame parsing more complex. As an alternative, both SecTag and the sequence number SN may be shifted to the start of the protected payload part PP.

[0098] By such an approach, protection against replay attacks is achieved while maintaining 50% of the original payload capacity P.

[0099] For the case of a 128-bit key size and a 2-byte sequence number SN for the AES-GCM mode using one general-purpose key K within the CAN system, Table 3 summarizes the input parameter lengths and output parameter lengths of the authentication-only mode AO for accommodating the security tag SecTag and the sequence number SN within the CAN frame.

Table 3

[0100] In the example of FIG. 4, the sequence number has a size of 2 bytes corresponding to 16 bits. The key length of the key K is 128 bits. The auxiliary 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, thereby reaching a total of 50 bits as shown in Table 3. For the purpose of achieving efficient calculation of AES-GCM, zero-padding is considered for the remaining 78 bits required to reach the total length of 128 bits of the AAD.

[0101] It should be understood that the length values shown in Table 3 would further change if the sequence number SN was omitted to increase the available bytes of the protected payload PP to 6 bytes. Such additional protected payload bits would of course come at the expense of no protection against replay attacks. Obviously, depending on the security requirements, it may be decided to shorten the security tag SecTag to a size less than 2 bytes and instead increase the available bytes of the protected payload portion PP.

[0102] Table 4 summarizes the input parameter lengths and output parameter lengths for the AE mode for the case where the sequence number SN is used and the key size is 128 bits for the AES-GCM mode using one general-purpose key K within the CAN system.

Table 4

[0103] The auxiliary authentication data AAD in the AE mode consists of a header with a total length of 18 bits. Zero-padding is considered for the remaining bits required to reach the total block size of 64 bits for the AAD in order to achieve efficient calculation of AES-GCM.

[0104] It should be understood that the length values shown in Table 4 would further change if the sequence number SN was omitted to increase the available bytes of the protected payload PP to 6 bytes. Such additional protected payload bits would of course come at the expense of no protection against replay attacks. Obviously, depending on the security requirements, it may be decided to shorten the security tag SecTag to a size less than 2 bytes and instead increase the available bytes of the protected payload portion PP.

[0105] When implementing the SADSE function for a CAN bus communication system, considering a block cipher with a block size shorter than AES-CGM is one variation. Simon Speck is an example of such a lightweight cipher defined by the U.S. National Security Agency. Table 5 summarizes various block and key sizes for the Simon and Speck block cipher family.

Table 5

[0106] Let's consider the 64-bit key size for the Simon and Speck block cipher. In this case, one general-purpose key K is used within the CAN system, which has an 18-bit header size, a sequence number SN and a security tag SecTag, each 2 bytes.

[0107] Table 6 summarizes the input and output parameter lengths for the authentication-only AO mode. In this case, the CAN frame contains the security tag SecTag and the sequence number SN.

[0108] As can be seen from Table 6, the plaintext stream and the ciphertext are 32 bits long, which is exactly equivalent to one block size. Therefore, there is no need to perform zero-padding on these fields as in AES-GCM, and the operation of Simon Speck is more efficient for CAN frames than AES-CGM.

Table 6

[0109] As is obvious to those skilled in the art, shortening or omitting the sequence number SN and / or the security tag SecTag can increase the protected payload part PP, but as a trade-off, it reduces the level of protection for the CAN frame.

[0110] The auxiliary authentication data is 50 bits long as in the case of AES-GCM described above, and since this length is between 1 block size and 2 block sizes of the 32-bit Simon and Speck block size, zero-padding is required.

[0111] Table 7 summarizes the input parameter lengths and output parameter lengths for the authenticated encryption mode. In this case, the security tag SecTag and the sequence number SN are included in the CAN frame.

Table 7

[0112] As can be seen from Table 7, the plaintext stream and the ciphertext are 32 bits long, which corresponds exactly to 1 block size. Therefore, there is no need to perform zero-padding on these fields as in the case of AES-GCM. In this regard, the operation of Simon Speck is more efficient for CAN frames than AES-CGM. However, the auxiliary authentication data AAD is shorter than 1 complete block size as in the case of AES-CGM described in the above example, and thus zero-padding is required.

[0113] The above exemplary embodiments are merely illustrative. As will be understood, modifications and variations of the configurations and details described herein will be apparent to those skilled in the art. Accordingly, it is intended here that the invention be limited only by the following claims and not by the specific details presented for the purposes of describing and explaining the embodiments herein.

Claims

1. A protocol frame (100) for communicating between subscribers of a bus-based communication system in a vehicle according to a protocol, said protocol frame (100) comprising: a header (H) indicating the beginning of said protocol frame (100) transmitted between a sender (S) and a receiver (R), both of which are participants in said bus-based communication system; a protected payload portion (PP) downstream of said header (H); a security tag (SecTag) configured to indicate the authenticity of said protocol frame as being an original protocol frame between said sender (S) and said receiver (R) at the data link layer level; A protocol frame (100) including:

2. said protocol frame (100) further comprising security information (SI) downstream of said header (H), said security information (SI) indicating a protection level for said protected payload part (PP); The protocol frame (100) of claim 1.

3. The security information (SI) a virtual channel between the transmitter (S) and the receiver (R); a key (K) used to protect said protected payload part (PP); At least one of The protocol frame (100) of claim 2.

4. The protocol frame (100) further includes an end of frame portion (EOF) indicating the end of the protocol frame (100). The protocol frame (100) according to any one of claims 1 to 3.

5. said protocol frame (100) having a length N as used in the CAN standard, The protocol frame (100) according to any one of claims 1 to 4.

6. The protocol frame (100) optionally includes: 8 bytes, 8 to 64 bytes, or 64 to 2000 bytes, having a length N of The protocol frame (100) according to any one of claims 1 to 5.

7. A transmitter (S) on a data link layer configured to participate in a bus-based communication system in a vehicle, the transmitter (S) comprising: generating a header (H) in response to a request from a higher protocol layer; Access a key K of length k bytes, receiving a protected payload portion (PP) from a higher protocol layer; Integrate supplementary authentication data (AAD), generating a security tag (SecTag) using said key K and said auxiliary authentication data (AAD), said security tag (SecTag) indicating, at said data link layer level, the authenticity of the frame (100) as being the original frame transmitted from said sender (S) to a receiver (R); generating a protocol frame (100) comprising said header (H), said protected payload portion (PP) and said auxiliary authentication data (AAD); It is structured as follows: the transmitter (S) is adapted to transmit the protocol frames (100) from the transmitter (S) to one or more subscribers of the bus-based communication system at the data link layer level; Transmitter (S).

8. In the authentication-only mode of the sender (S), the auxiliary authentication data (AAD) is The header (H); the protected payload portion (PP), That is, A transmitter (S) according to claim 7.

9. The sender (S) further comprises, in the authenticated encryption mode (AE), Regarding the Protected Payload Part (PP) The key (K), said protected payload portion (PP) of plaintext (P); and said header (H) as auxiliary authentication data (AAD); is configured to generate a ciphertext (cipher{PP}) using A transmitter (S) according to claim 7.

10. The transmitter (S) further comprises: configured to generate a sequence number (SN) of sn bytes downstream of said header (H) and to incorporate said sequence number (SN) into said protocol frame (100) at the expense of a shortened protected payload (sPP) shortened by sn bytes compared to said protected payload part (PP), A transmitter (S) according to any one of claims 7 to 9.

11. In the authentication-only mode of the sender (S), the auxiliary authentication data (AAD) is The header (H), The sequence number (SN), and the protected payload (PP), Including, A transmitter (S) according to claim 10.

12. The transmitter (S) a protocol frame (100) configured to generate security information (SI) of length si using said key (K) and to incorporate said security information (SI) downstream of said header (H) into said protocol frame (100) at the expense of a shortened protected payload (sPP) shortened by si bytes compared to said protected payload (PP), said security information (SI) indicating a protection level for said protected payload portion (PP), A transmitter (S) according to any one of claims 7 to 9.

13. The sender (S) further comprises, in the authenticated encryption mode (AE), a protocol frame (100) downstream of the header (H) configured to generate security information (SI) of length si bytes and further configured to incorporate said security information (SI) into said protocol frame (100) at the expense of a shortened protected payload (sPP) shortened by si+sn bytes compared to said protected payload (PP), said security information (SI) indicating a protection level for said shortened protected payload (sPP), A transmitter (S) according to claim 10.

14. The auxiliary authentication data (AAD) The header (H), The sequence number (SN), said security information (SI) and said shortened protected payload (sPP); Including, A transmitter (S) according to claim 13.

15. The sender (S) further comprises, in the authenticated encryption mode (AE), The ciphertext (cipher{sPP}) is The key (K), the sequence number (SN) as a nonce (N), said protected payload (PP) of plaintext (P), and the header (H), the sequence number (SN) and the security information (SI) as auxiliary authentication data (AAD); It is configured to generate using A transmitter (S) according to claim 13 or 14.

16. A receiver (R) on a data link layer for joining a bus-based communication system in a vehicle, said receiver (R) comprising: receiving, on the data link layer, a protocol frame (100) having a length of N bytes from a transmitter (S) according to a protocol; Extracting h bytes of a header (H) from the protocol frame (100); Extracting a protected payload portion (PP) from said protocol frame (100); Access a key (K) of length k bytes, extracting a security tag (SecTag) from said protocol frame (100) downstream of said header (H), Authenticity Indication (AI), The key (K), Auxiliary authentication data (AAD) including said header (H); the security tag (SecTag); and the protected payload (PP), The authenticity indication (AI) is configured to indicate the authenticity of the protocol frame (100) transmitted from the transmitter (S) to the receiver (R) on the data link layer. Receiver (R).

17. said receiver (R) being further configured to discard said protocol frame (100) if said authenticity indication (AI) does not indicate authenticity of said protocol frame (100) transmitted from said sender (S) to said receiver (R) and, optionally, to indicate such lack of authenticity to a higher protocol layer. Receiver (R) according to claim 16.

18. In the authenticated decryption mode (A&D) of the receiver (R), the receiver (R) If the authenticity indication (AI) indicates the authenticity of the protocol frame (100) transmitted from the sender (S) to the receiver (R), The key (K), the Protected Payload (PP) as a ciphertext C, and said auxiliary authentication data (AAD); and generating a decoded payload (DP) as an output stream to a higher protocol layer using the Receiver (R) according to claim 16.

19. The auxiliary authentication data (AAD) includes the header (H). Receiver (R) according to claim 18.

20. The receiver is further configured to extract a sequence number (SN) of sn bytes from the protocol frame (100). Receiver (R) according to any one of claims 16 to 18.

21. The auxiliary authentication data (AAD) The header (H) and The sequence number (SN) Including, Receiver (R) according to claim 20.

22. In the authenticated decryption mode (A&D) of the receiver (R), the receiver (R) If the authenticity indication (AI) indicates the authenticity of the protocol frame (100) transmitted from the sender (S) to the receiver (R), The sequence number (SN), The key (K), the Protected Payload (PP) as a ciphertext C, and said auxiliary authentication data (AAD); to generate a Decoded Payload (DP) as an output stream to a higher protocol layer using The receiver (R) is configured to indicate the authenticity indication (AI) to a higher protocol layer. Receiver (R) according to claim 20 or 21.

23. The receiver is further configured to extract si bytes of security information (SI) downstream of the header (H) from the protocol frame (100); The security information (SI) a virtual channel between the sender (S) and the receiver (R); and A key (K) used to protect said protected payload part (PP), At least one of Receiver (R) according to any one of claims 16 to 18.

24. The auxiliary authentication data (AAD) The header (H), The sequence number (SN), and said security information (SI), Including, Receiver (R) according to claim 23.

25. In the authenticated decryption mode (A&D) of the receiver (R), the receiver (R) If the authenticity indication (AI) indicates the authenticity of the protocol frame (100) transmitted from the sender (S) to the receiver (R), The key (K), The sequence number (SN), the Protected Payload (PP) as a ciphertext C, and said auxiliary authentication data (AAD); to generate a Decoded Payload (DP) as an output stream to a higher protocol layer using The receiver (R) is configured to indicate the authenticity indication (AI) to a higher protocol layer. Receiver (R) according to claim 23 or 24.

26. A communication network in a vehicle configured to provide communication at the transport level layer between a transmitter (S) according to any one of claims 9 to 15 and a receiver (R) according to any one of claims 16 to 25 using a protocol frame (100) according to any one of claims 1 to 8.

Images