Method and device for a serial bus system

Abstract

The invention relates to a method, for example a computer-implemented method, for a serial bus system, comprising: providing a first functionality, which is configured to execute a security protocol associated with layer 2 of the ISO / OSI layer model, and processing information of the serial bus system, for example at least one component of the serial bus system, using the first functionality.

Description

[0001] R.417584

[0002] - 1 -

[0003] title

[0004] Method and apparatus for a serial bus system

[0005] State of the art

[0006] The disclosure relates to a method for a serial bus system.

[0007] The disclosure relates to a device for a serial bus system.

[0008] Disclosure of the invention

[0009] Some examples refer to a procedure, for example a computer-implemented procedure, for a serial bus system, comprising: providing a first functionality configured to execute a safety protocol associated with Layer 2 of the ISO / OSI model; and processing information from the serial bus system, for example, from at least one component of the serial bus system, using the first functionality. This allows, in some examples, the efficient execution of safety protocol functions for the serial bus system, for example, for at least one bus participant.

[0010] In some examples, the serial bus system is of the Controller Area Network type CAN, extra large, CAN XL, for example, according to or based on ISO 11898-1:2024. In some examples, the serial bus system may also be of the CAN FD (Controller Area Network with Flexible Data-Rate) type. In some examples, the bus system is configured to process data frames of type CAN XL and / or CAN FD, at least temporarily.

[0011] In some examples, the security protocol is of type Media Access Control Security, MACsec, for example according to or based on IEEE 802.1AE.R.417584

[0012] - 2 -

[0013] In some examples, the procedure is designed to have:

[0014] Providing an abstraction layer for the security protocol, wherein the abstraction layer is configured for at least one of the following elements: a) receiving at least some of the information from the serial bus system (e.g., CAN XL data frames or parts thereof), or b) processing at least some of the information from the serial bus system using the first functionality (e.g., functions for security, for example, according to MACsec), whereby the processed information is received, or c) outputting the processed information, and, optionally, at least temporarily using the abstraction layer to process at least some of the information from the serial bus system according to the security protocol.

[0015] In some examples, the procedure is provided to include at least one of the following elements: a) at least temporary processing of header data of at least one data frame of the serial bus system, or b) encryption of at least part of the information, or c) decryption of at least part of the information, or d) execution of authentication associated with at least part of the information.

[0016] In some examples, the method is provided to include at least one of the following elements: a) Transforming at least some of the information, for example from a format associated with the bus system, such as a data format (e.g., the format of a CAN XL data frame or a CAN FD data frame), into a format compatible with the security protocol (e.g.,MACsec) associated format, for example data format, for example mapping at least part of the information, for example from the format associated with the bus system into the format associated with the security protocol, thereby obtaining transformed information, or b) processing the transformed information using the first functionality, thereby obtaining processed information, or c) transforming at least part of the processed information into the format associated with the bus system, for example mapping at least part of the processed information into the format associated with the bus system. R.417584.

[0017] - 3 -

[0018] In some examples, the transformation, for example mapping, involves transforming, for example mapping, at least one of the following elements, for example from the format associated with the bus system, for example data format, into the format associated with the security protocol, for example data format: a) an element of type Priority ID, for example having 11 bits, or b) an element of type RRS, for example having 1 bit, or c) an element of type Format, for example having 3 bits, for example characterizing at least one of c1) an IDE, Identifier Extension Flag, bit, or c2) an FDF, FD Frame flag, bit, or c3) an XLF, XL Frame flag, bit, or d) an element of type Service Data Unit, SDU, Type, SDT, for example having 8 bits, or e) an element of type Simple Extended Content flag, SEC, for example having 1 bit, or f) an element of type Data Length Code, DLC,for example, having 11 bits, or g) an element of type Virtual CAN ID, VCID, for example having 8 bits, or h) an element of type Acceptance Field, AF, for example having 32 bits, or i) an element of type Data, for example characterizing payload data, for example having a length encoded by the element of type DLC, for example a maximum of 2048 bytes.

[0019] In some examples, the format associated with the security protocol includes at least one of the following elements: A) a field for a destination address, or B) a field for a source address, or C) a field for data, for example, payload data.

[0020] In some examples, the procedure is designed to: Map at least some, for example all, of the following elements to the target address field: a) the Priority ID element, or b) the RRS element, or c) the Format element, or d) the Service Data Unit (SDU), Type (SDT) element, or e) the Simple Extended Content flag (SEC) element, or f) the Data Length Code (DLC) element, or g) the Virtual CAN ID (VCID) element.

[0021] In some examples, the procedure is provided to include at least one of the following elements: a) Filling a predefinable area, for example comprising five bits, of the target address field with an R.417584

[0022] - 4 -

[0023] a) a predefinable first value, for example 0, for example 00000b, or b) mapping the element of type Acceptance Field, AF, to the field for the source address, or c) filling a predefinable range, for example having sixteen bits, of the field for the source address, with a predefinable second value, for example 0, for example 0000000000000000b, or d) mapping the element of type Data, for example payload, to the field for the data, for example payload.

[0024] In some examples, the procedure is designed to: optionally, for example based on initial configuration information, A) map at least one of the following elements to the target address field: a) the element of type Priority ID, or b) the element of type Virtual CAN ID, VCID, or B) map at least one predefinable third value, for example instead of at least one of the elements, to the target address field.

[0025] In some examples, it is stipulated that the processed information must contain at least one of the following elements: a) protected, for example encrypted, user data, or b) a header, for example header data, of the security protocol, for example a security tag, for example SecTag, or c) a checksum, for example cryptographic, for example Integrity Check Value, ICV.

[0026] In some examples, it is provided that the mapping of at least part of the processed information into the format associated with the bus system includes: mapping at least one of the elements a) user data, or b) header, or c) checksum into a user data field of a data frame for the bus system.

[0027] In some examples, the procedure is designed to have:

[0028] Providing supplementary header data, wherein the supplementary header data includes at least one of the following elements: a) an element of type AddOn-Type, AOT, for example having 3 bits, or b) an element of type Simple Extended Content, SEC, for example having 1 bit, or c) an element of type Version Number, VN, for example having 3 bits, or d) an element of type EP, for example having 1 bit, or e) an element R.417584

[0029] - 5 -

[0030] of type EV, for example having 1 bit, or f) an element of type "reserved", for example for future use, for example having 7 bits, and, optionally, processing the supplementary header data, for example combining the supplementary header data with the header, for example integrating the supplementary header data into the header.

[0031] In some examples, the procedure is designed to have:

[0032] Receiving a data frame for the bus system, for example an unsecured CAN XL data frame, processing at least some of the information from the received data frame according to the security protocol, forming, based at least on parts of the data frame (for example an unsecured one) and on the processing of, at least partially secured data frames (for example an at least partially secured CAN XL data frame), for the bus system, and optionally, sending the at least partially secured data frame.

[0033] In some examples, the procedure is designed to include at least one of the following elements: a) generating a header according to the security protocol, for example a MACsec header, or b) generating a checksum according to the security protocol, for example a MACsec checksum, for example Integrity Check Value, or c) encrypting data, for example user data.

[0034] In some examples, the procedure is designed to have:

[0035] Receiving a data frame for the bus system, for example, a CAN XL data frame, which may be at least partially secured; processing at least some of the information from the received data frame according to the security protocol; constructing, based on at least parts of the data frame (which may be at least partially secured) and on the processing of an unsecured data frame (for example, an unsecured CAN XL data frame) for the bus system; and optionally, outputting the unsecured data frame. R.417584

[0036] - 6 -

[0037] In some examples, the processing is intended to include at least one of the following elements: a) evaluating a header according to the security protocol, for example a MACsec header, or b) checking a checksum according to the security protocol, for example a MACsec checksum, for example Integrity Check Value, or c) decrypting encrypted data, for example user data.

[0038] Some examples relate to a device for a serial bus system, wherein the device is configured to perform the method according to the disclosure.

[0039] Some examples refer to a bus participant for a serial bus system, wherein the bus participant has at least one device according to the disclosure.

[0040] Some examples refer to a computer-readable storage medium comprising instructions which, when executed by a computer, cause it to perform the procedure according to the disclosure.

[0041] Some examples relate to a computer program, comprising instructions that, when the program is executed by a computer, cause it to carry out the procedure according to the disclosure.

[0042] Some examples refer to a data structure, for example a computer-implemented data structure, comprising at least one of the following elements: a) a field for a destination address, or b) a field for a source address, or c) a field for data, or d) user data, or b) header, or c) checksum.

[0043] Some examples refer to a data carrier signal that transmits and / or characterizes the computer program according to the disclosure and / or the data structure according to the disclosure.

[0044] Some examples refer to a use of the method according to the disclosure and / or the device according to the disclosure and / or the bus participant according to the disclosure and / or the computer-readable R.417584

[0045] - 7 -

[0046] Storage medium according to the disclosure and / or computer program according to the disclosure and / or data structure according to the disclosure and / or data carrier signal according to the disclosure for at least one of the following elements: a) enabling the use of the security protocol for the bus system, for example for CAN XL and / or CAN FD, or b) using, for example reusing, a MACsec method for CAN XL and / or CAN FD, or c) mapping information of a data frame according to CAN XL and / or CAN FD to input information and / or at least one data format for the security protocol, for example MACsec, or d) securing CAN XL, for example by means of MACsec, or e) securing information of a CAN XL data frame associated with at least one control field, for example Control Field, for example securing a CAN XL header, or f) reducing complexity, for example by avoiding Ethernet tunneling,or g) reduce overhead, for example by avoiding Ethernet tunneling, or h) integrate MACsec functionality into a bus participant for CAN XL and / or CAN FD, or i) optionally include or exclude a CAN XL Priority ID and / or a Virtual CAN Network ID (VCID) from authentication, for example, MACsec-based authentication, or j) add one or more functionalities associated with CANsec, for example, to a MACsec header, or k) enable a representation, for example, of current CANsec functionality and / or specifications, using MACsec, for example, a MACsec implementation.

[0047] Further features, applications, and aspects arise from the following description of aspects of the disclosure, which are depicted in the figures of the drawing. All described or depicted features, individually or in any combination, constitute the subject matter of the disclosure, irrespective of their compilation in the claims or their cross-reference, and irrespective of their formulation or...

[0048] Representation in the description or in the drawing.

[0049] The drawing shows:

[0050] Fig. 1 schematically shows a flowchart, R.417584

[0051] - 8 -

[0052] Fig. 2 schematically a block diagram, Fig. 3 schematically a flowchart, Fig. 4 schematically a flowchart, Fig. 5 schematically a block diagram, Fig. 6 schematically a block diagram, Fig. 7 schematically a flowchart, Fig. 8 schematically a flowchart, Fig. 9 schematically a flowchart, Fig. 10 schematically a block diagram, Fig. 11 schematically a flowchart, Fig. 12 schematically a flowchart, Fig. 13 schematically a block diagram, Fig. 14 schematically a block diagram, Fig. 15 schematically a block diagram, Fig. 16 schematically a block diagram, Fig. 17 schematically a block diagram, Fig. 18 schematically a block diagram, Fig. 19 schematically a block diagram, R.417584

[0053] - 9 -

[0054] Fig. 20 schematically shows a block diagram,

[0055] Fig. 21 schematically shows a block diagram,

[0056] Fig. 22 schematically shows aspects of uses,

[0057] Fig. 23 schematically shows a block diagram,

[0058] Fig. 23 schematically shows a block diagram,

[0059] Fig. 23 schematically shows a block diagram,

[0060] Fig. 23 schematically shows a block diagram.

[0061] Some examples, e.g., Fig. 1, 2, relate to a method, for example, a computer-implemented method, for a serial bus system 10, comprising: providing 100 a first functionality FUN-1 configured to execute a security protocol SEC-PROT associated with layer 2 of the ISO / OSI model, for example, operating at layer 2; and processing 102 information 1-10 of the serial bus system 10, for example, at least one component 12a, 12b, ... of the serial bus system 10, using the first functionality FUN-1. In some examples, this makes it possible to efficiently execute functions of the security protocol SEC-PROT for the serial bus system 10, for example, for at least one bus participant 12a, 12b, ... of the serial bus system 10. In some examples, more than the two bus participants 12a, 12b shown here as an example in Fig. 2 may also be provided.

[0062] In some examples, Fig. 2, at least temporarily one or more aspects of the method according to the disclosure are carried out by a device 200, or the device 200 causes at least one bus participant 12a, 12b, ... to carry out at least temporarily one or more aspects of the method according to the disclosure. R.417584

[0063] - 10 -

[0064] In some examples, Fig. 2, the serial bus system 10 is of type Controller Area Network CAN, extra large, CAN XL, for example according to or based on ISO 11898-1:2024.

[0065] In some examples, the serial bus system 10 can also be of type CAN FD (Controller Area Network with Flexible Data-Rate).

[0066] In some examples, Fig. 2, the bus system 10 is designed to process data frames of type CAN XL and / or type CAN FD, at least temporarily.

[0067] In some examples, Fig. 2, the security protocol SEC-PROT is of type Media Access Control Security, MACsec, for example according to or based on IEEE 802.1 AE.

[0068] In some examples, Fig. 3, the method is provided to include: providing an abstraction layer WL for the SEC-PROT security protocol, wherein the abstraction layer WL is configured for at least one of the following: a) receiving at least part 1-10' of the information 1-10 of the serial bus system 10 (e.g., CAN XL data frames or parts thereof), or b) processing at least part 1-10' of the information of the serial bus system using the first functionality FUN-1 (e.g., having security functions, for example, according to MACsec, such as encryption and / or decryption and / or generating and / or checking checksums, etc.).), whereby processed information 1-10" is obtained, or c) output 110c of the processed information 1-10", and, optionally, at least temporarily use 112 of the abstraction layer WL to process at least a part 1-10' of the information 1-10 of the serial bus system 10 according to the security protocol SEC-PROT.

[0069] In some examples, Fig. 3, the principle according to the disclosure can be used for data processing in a first communication direction, for example associated with sending, e.g., CAN XL, data frames. R.417584

[0070] - 11 -

[0071] In some examples, Fig. 3, the principle according to the disclosure can be used for data processing in a second communication direction, for example associated with receiving, e.g., CAN XL, data frames.

[0072] In some examples, Fig. 3, the principle according to the disclosure, for example according to, but not limited to, aspects of Blocks 110 and 112, can be used for data processing in both communication directions (sending and / or receiving). Further details on the application of the principle according to the disclosure to different communication directions are described below, inter alia, with reference to Figs. 11 and 12.

[0073] In some examples, Fig. 1, it is provided that the method, for example the processing 102, includes at least one of the following elements: a) at least temporary processing 102a of header data of at least one data frame of the serial bus system 10, or b) encryption 102b of at least one part 1-10' (Fig. 2) of the information 1-10, or c) decryption 102c of at least one part 1-10' of the information 1-10, or d) execution 102d of an authentication associated with the at least one part 1-10' of the information 1-10.

[0074] In some examples, Fig. 4, 5, it is provided that the method includes at least one of the following elements: a) Transform 120 (Fig.

[0075] 4) at least a part 1-10' of the information 1-10, for example from a format associated with the bus system 10, for example data format, DF-10 (e.g. format of a CAN XL data frame) into a format associated with the security protocol (e.g. MACsec) SEC-PROT, for example data format, DF-SEC-PROT, for example mapping 120a of the at least a part 1-10' of the information, for example from the format DF-10 associated with the bus system 10 into the format DF-SEC-PROT associated with the security protocol SEC-PROT, thereby obtaining transformed information 1-1, or b) processing 122 the transformed information 1-1 using the first functionality FUN-1, thereby obtaining processed information I-2, or c) transforming 124 at least a part of the processed information I-2 into the format associated with the bus system 10 DF-10,R.417584

[0076] - 12 -

[0077] for example mapping 124a of at least part of the processed information I-2 into the format DF-10 associated with the bus system 10.

[0078] In some examples, Fig. 4, 5, the transform 120, for example mapping 120a, has: transform 120', for example mapping 120a', at least one of the following elements, for example from the format DF-10 associated with the bus system 10, for example data format, into the format DF-SEC-PROT associated with the security protocol SEC-PROT, for example data format: a) an element e1 of type Priority ID, for example having 11 bits, or b) an element e2 of type RRS, for example having 1 bit, or c) an element e3 of type Format, for example having 3 bits, for example characterizing at least one of c1) an IDE, Identifier Extension Flag, bit, or c2) an FDF, FD Frame flag, bit, or c3) an XLF, XL Frame flag, bit, or d) an element e4 of type Service Data Unit, SDU, Type, SDT, for example having 8 bits, or e) an element e5 of type Simple Extended Content flag, SEC,for example, having one bit, or f) an element e6 of type Data Length Code, DLC, for example having 11 bits, or g) an element e7 of type Virtual CAN ID, VCID, for example having 8 bits, or h) an element e8 of type Acceptance Field, AF, for example having 32 bits, or i) an element e9 of type Data, for example characterizing user data, for example having a length encoded by the element of type DLC, for example a maximum of 2048 bytes. This allows, in some examples, the optional processing of at least a subset of the elements e1, e2, ..., e9 using the first functionality FUN-1, for example using at least one MACsec function.

[0079] In some examples, Fig. 5, the DF-SEC-PROT format associated with the SEC-PROT security protocol has at least one of the following elements: A) a field f1 for a destination address, or B) a field f2 for a source address, or C) a field f3 for data, for example, payload data.

[0080] In some examples, Fig. 4, 6, the method is provided to: Map at least some, for example all, of the following elements to the field f1 for the target address: a) the element e1 of type Priority ID, or b) the element e2 of type RRS, or c) the element e3 of type R.417584

[0081] - 13 -

[0082] Format, or d) the element e4 of type Service Data Unit, SDU, Type, SDT, or e) the element e5 of type Simple Extended Content flag, SEC, or f) the element e6 of type Data Length Code, DLC, or g) the element e7 of type Virtual CAN ID, VCID.

[0083] In some examples, Fig. 6, 7, the method is provided to include at least one of the following elements: a) Filling 130 a predefinable range, for example having five bits, of the field f1 for the destination address, with a predefinable first value W-1, for example 0, for example 00000b, or b) Mapping 132 the element e8 of type Acceptance Field, AF, to the field f2 for the source address, or c) Filling 134 a predefinable range, for example having sixteen bits, of the field f2 for the source address, with a predefinable second value W-2, for example 0, for example 00000000000000000b, or d) Mapping 136 the element e9 of type Data, for example user data, to the field f3 for the data, for example user data.

[0084] In some examples, Fig. 8, the method is provided to: optionally, for example based on a first configuration information I-CFG-1, A) map 140 at least one of the following elements to the field f1 for the destination address: a) the element e1 of type Priority ID, or b) the element e7 of type Virtual CAN ID, VCID, or B) map 142 at least one predefinable third value W-3, for example instead of at least one of the elements e1 , e7, to the field f1 for the destination address.

[0085] In some examples, Fig. 2, it is provided that the processed information I-2 contains at least one of the following elements: a) protected, for example encrypted, user data l-2a, or b) a header l-2b, for example header data, of the security protocol SEC-PROT, for example a security tag, for example SecTag, see also Fig. 20, or c) a checksum I-2c, for example cryptographic, for example Integrity Check Value, ICV.

[0086] In some examples, Fig. 4, it is provided that the mapping 124a of at least part I-2' of the processed information into the DF-10 format associated with the bus system 10 has: mapping 124a' at leastR.417584

[0087] - 14 -

[0088] One of the elements a) user data l-2a, or b) header l-2b, or c) checksum I-2c into a data field for user data of a data frame for the bus system 10. In this way, in some examples, information or parts thereof processed by means of at least one MACsec function, see the first functionality FUN-1 (Fig. 2), can be integrated into a CAN XL data frame, for example for transmission via the bus system 10 (Fig. 2), e.g. as an at least partially secured CAN XL data frame.

[0089] In some examples, Figs. 9, 10, 20, the method includes: providing supplementary header data HD-ext, wherein the supplementary header data HD-ext includes at least one of the following elements: a) an element e10 of type AddOn-Type, AOT, for example having 3 bits, or b) an element e11 of type Simple Extended Content, SEC, for example having 1 bit, or c) an element e12 of type Version Number, VN, for example having 3 bits, or d) an element e13 of type EP, for example having 1 bit, or e) an element e14 of type EV, for example having 1 bit, or f) an element e15 of type "reserved", for example for future use, for example having 7 bits, and, optionally, processing 152 (Fig. 9) the supplementary header data HD-ext, for example combining (e.g. concatenating) 152a of the supplementary header data HD-ext with the header l-2b, see Fig.20, for example, integrate the supplementary header data HD-ext into the header l-2b. In this way, the supplementary header data can be aggregated with the header l-2b, for example for a joint transmission, for example using at least one CAN XL data frame. Further details and aspects of the supplementary header data HD-ext are described below with reference to Fig.

[0090] 20 is stated.

[0091] In some examples, Fig. 11, the method is provided to: receive 160 (for example, from a higher layer according to the ISO / OSI layer model) an, for example, unsecured, data frame DR-unsec for the bus system 10, for example, an unsecured CAN XL data frame; process 162 at least some information l-DR-unsec of the received data frame DR-unsec according to the security protocol SEC-PROT (for example, using the first functionality FUN-1, Fig. 2); and generate 164, based on at least parts of the, for example, unsecured, R.417584

[0092] - 15 -

[0093] Data frame DR-unsec and on the processing 162, of an at least partially secured data frame DR-sec, for example an at least partially secured CAN XL data frame, for the bus system 10, and optionally, sending 166 of the at least partially secured data frame DR-sec, for example to another layer, for example a physical, for example bit transmission layer, e.g. layer 1, e.g. for a transmission of the at least partially secured data frame DR-sec via the bus system 10.

[0094] In some examples, Fig. 11, it is provided that the method, for example the processing 162, includes at least one of the following elements: a) forming 162a a SEC-PROT-HEAD header according to the SEC-PROT security protocol, for example a MACsec header (e.g. SecTag), or b) forming 162b a SEC-PROT-CS checksum according to the SEC-PROT security protocol, for example a MACsec checksum, for example Integrity Check Value (ICV), or c) encrypting 162c data, for example user data.

[0095] The process described above as an example according to Fig. 11, or individual aspects thereof, can be carried out at least temporarily in some examples in or by a bus participant 12a (Fig. 2) for the bus system 10, or by a device 200 associated with it, wherein the bus participant 12a can, for example, transmit information at least partially securely by means of, for example, MACsec in the form of one or more CAN XL (or CAN FD) data frames via the bus system 10.

[0096] The following are described with reference to Fig. 12, according to further examples, aspects that can be carried out when receiving such CAN XL data frames that are at least partially secured (e.g. by MACsec), for example in and / or by and / or for a bus participant 12b (Fig. 2).

[0097] In some examples, Fig. 12, the method is provided to include: Receiving 170 of a data frame DR-sec, for example, at least partially secured, for the bus system 10, for example, a CAN XL data frame, for example, at least partially secured, from a physical layer or from an R.417584

[0098] - 16 -

[0099] Bus medium, processing 172 at least some information l-DR-sec of the received data frame DR-sec according to the security protocol SEC-PROT, forming 174 based at least on parts of the, for example at least partially secured, data frame DR-sec and on the processing 172, of an, for example unsecured, data frame, for example an unsecured CAN XL data frame, DR-unsec' for the bus system 10, and optionally, output 176 of the, for example unsecured, data frame DR-unsec', for example to a higher layer or a target system (not shown).

[0100] In some examples, Fig. 12, it is provided that the processing 172 includes at least one of the following elements: a) Evaluating 172a a SEC-PROT-HEAD header according to the SEC-PROT security protocol, for example a MACsec header, or b) Checking 172b a SEC-PROT-CS checksum according to the SEC-PROT security protocol, for example a MACsec checksum, for example Integrity Check Value (ICV), or c) Decrypting 172c encrypted data, for example user data.

[0101] In some examples, both variants, as shown in Figures 11 and 12, can use the principle according to the disclosure, e.g., the principle of the abstraction layer WL (Figure 2), to transform, for example, CAN XL-related information from a corresponding data format DF-10 into a data format DF-SEC-PROT suitable for the security protocol SEC-PROT, e.g., MACsec, and vice versa, which enables flexible processing of information from or for CAN XL data frames using the security protocol SEC-PROT, e.g., MACsec.

[0102] MACsec enables, for example, both sending and receiving data frames.

[0103] Some examples, Fig. 2, 13, relate to a device 200 for a serial bus system 10, wherein the device 200 is configured to perform the method according to the disclosure.

[0104] In some examples, Fig. 13, it is provided that the device 200 comprises: a computing device (“computer”) 202 comprising at least one computing core 202a, one of the computing device 202R.417584

[0105] - 17 -

[0106] associated storage device 204 for at least temporary storage of at least one of the following elements: a) data DAT, or b) computer program PRG, for example for executing the procedure according to the disclosure, or c) data structure DS.

[0107] In some examples, the data DAT or information content of the data structure DS is associated with at least one of the following elements: a) information for the provision 100 (Fig. 1) of the first functionality FUN-1, or b) at least some of the information 1-1, or I-2, or 1-10 or information derivable therefrom, or c) information that is organized at least temporarily in the form of at least one of the data formats DF-10, DF-SEC-PROT.

[0108] In other examples, the memory device 204 includes volatile memory (e.g., main memory (RAM)) 204a, and / or non-volatile (NVM) memory (e.g., flash EEPROM) 204b, or a combination thereof or with other memory types not explicitly mentioned.

[0109] Further examples, Fig. 13, relate to a computer-readable storage medium SM, comprising instructions PRG which, when executed by a computer 202, cause it to execute the method according to the disclosure.

[0110] Further examples, Fig. 13, relate to a computer program PRG, comprising instructions which, when the program PRG is executed by a computer 202, cause it to execute the method according to the disclosure.

[0111] Some examples, Fig. 13, refer to a data structure DS, for example a computer-implemented data structure, comprising at least one of the following elements: a) a field f1 for a destination address, or b) a field f2 for a source address, or c) a field f3 for data, or d) user data I-2a, or b) header I-2b, or c) checksum I-2c.R.417584

[0112] - 18 -

[0113] Further examples, Fig. 13, relate to a data carrier signal DCS that characterizes and / or transmits the computer program PRG according to the disclosure and / or the data structure DS according to the disclosure. The data carrier signal DCS is, for example, interchangeable via an optional data interface 206 of the device 200, for example via the bus system 10 (Fig. 2).

[0114] Some examples, Fig. 2, refer to a bus participant 12a, 12b, ... for a serial bus system 10, for example CAN XL and / or CAN FD, wherein the bus participant 12a, 12b, ... has at least one device 200 according to the disclosure.

[0115] Some examples, Fig. 2, relate to a serial bus system 10 with at least one device 200 according to the disclosure. In some examples, the serial bus system 10 can be used, for example, in a vehicle (not shown), such as a motor vehicle, and / or in another product, such as a robot or a manufacturing device or the like.

[0116] Further examples and aspects are described below, which in some cases can be combined individually or in any combination with at least one of the aspects and examples described above.

[0117] The principle according to the disclosure allows, in some examples, the realization of an abstraction layer WL (see also block 110 according to Fig. 3), for example a "wrapper layer" for the security protocol SEC-PROT, e.g. MACsec, which in some examples makes it possible to use MACsec to secure CAN XL (e.g. CAN XL data frames, see Fig. 16, 17, 18, 19, or CAN FD data frames, see Fig. 23, 24, 25, 26), e.g. as an alternative solution to CANsec.

[0118] In some examples, the principle according to the disclosure can thus be used to provide an alternative security solution to the conventional CANsec protocol, which may, for example, also be amenable to standardization or specification. R.417584

[0119] - 19 -

[0120] The principle, as disclosed, makes it possible to reduce or avoid the overhead associated with some conventional approaches based on Ethernet frame tunneling. Furthermore, in some examples, CAN XL frame fields (e.g., in addition to the payload, which can be encrypted using the first functionality FUN-1) can also be secured using MACsec and thus protected against manipulation.

[0121] The principle according to the disclosure is also generally applicable in some examples, e.g. to all CAN XL frames or data frames and / or CAN FD frames, and has a higher level of security than some conventional approaches, because, for example, a CAN XL header can also be protected in some examples using the SEC-PROT security protocol.

[0122] Fig. 14 shows, as a further example, a CAN XL bus system 10a in which two bus participants 12a and 12b are connected to each other via a bus medium 12. Element 13 symbolizes a functionality according to the principle of disclosure, for example, implementable by means of the device 200, for bus participant 12a, and element 14 symbolizes a functionality according to the principle of disclosure, for example, implementable by means of the device 200, for bus participant 12b. Element 15 symbolizes a connectivity association, for example, a Connectivity Association (e.g., "CA"), which in some examples may be associated with configuration information l-CFG. For example, the configuration information l-CFG can describe, for example, specify at least one aspect of communication between the bus participants 12a and 12b according to the connectivity association 15.

[0123] Based on the example in Fig. 14, the following describes a scenario, as found in some examples, in which secure communication takes place between bus participants 12a and 12b. In some examples, both bus participants 12a and 12b belong to the Connectivity Association (CA) 15. The CA 15 can be described in some examples as an architectural element that allows participants to be grouped together, for example, for the security protocol SEC-PROT or MACsec, enabling them to communicate with each other in a protected manner (e.g., from other participants (not shown) outside the CA 15). Part of this CA 15 can be found in some examples. R.417584

[0124] - 20 -

[0125] This could also include a set of configuration options, see element l-CFG in Fig. 14, which can be configured statically (at least partially) or negotiated dynamically between participants 12a and 12b. Finally, in some examples, the bus system 10a in Fig. 14 may contain additional participants (not shown), for example, as "normal" bus participants (i.e., outside of CA 15) or as members of CA 15. Within CA 15, members 12a and 12b can securely send messages to the remaining members of CA 15 and / or verify messages received within CA, for example, using one or more functions of the SEC-PROT security protocol. In some examples, the MACsec security protocol can be used for such secure communication or for message verification, as mentioned above.

[0126] In some examples, Fig. 14, the bus participants 12a, 12b each have an element or entity 13, 14 that, for example, implements at least some aspects according to the disclosure, for example, implementable by means of at least some aspects of the device 200 (Fig. 13). In some examples, the elements 13, 14 are configured to process messages in a respective communication stack (not shown) of the participants 12a, 12b, for example, to add information for security in the sending direction, for example, according to an application of MACsec using the principle according to the disclosure (and, if necessary, to encrypt information such as at least payload data), and / or to check information for security in the receiving direction, for example, according to an application of MACsec using the principle according to the disclosure (and, if necessary, to verify the security).

[0127] Information such as, for example, decrypting encrypted user data).

[0128] In some examples, elements 13, 14 according to Fig. 14 can, for example, exhibit at least one functionality of an entity referred to as "SecY" in MACsec.

[0129] Fig. 15 schematically shows aspects of an internal structure of element 13 from Fig. 14 according to some examples, here using the example of a communication direction "sending", i.e. for example for sending at least one data frame by the bus participant 12a (Fig. 14) via the R.417584

[0130] - 21 -

[0131] Bus medium 12. Element 14 according to Fig.14 may, in some examples, have a structure identical or at least comparable to element 13.

[0132] Element e20 according to Fig. 15 symbolizes aspects of a MACsec functionality (e.g., also the first functionality FUN-1 according to Figs. 1, 2), for example, at least partially realizable by the device 200 or by a "SecY" entity according to MACsec, for example, for sending (and / or receiving). Element e21 symbolizes first aspects of data processing for element 13 according to the disclosure, and element e22 symbolizes second aspects of data processing for element 13 according to the disclosure.

[0133] In some examples, Fig. 15, at least one interface of element e20 may be designed according to or based on the IEEE 802.1 AE standard [Figure 8.2].

[0134] In some examples, Fig. 15, element e21 is configured to process inputs for element 13, e.g., CAN XL data DR-unsec associated with a Logical Link Control, i.e., CAN XL LLC data, e.g., without a security function, for example, to transform them into a suitable format for element e20, e.g., to map or represent them (and / or vice versa, e.g., for receiving). Element e21 can, for example, receive one or more CAN XL data frames from a higher layer (not shown), e.g., via a connection, e.g., temporary input, e21a.

[0135] In some examples, Fig. 15, the element e22 is configured to provide outputs of the element 13 at its connection, e.g. temporary output, e22a, for example by receiving corresponding outputs e20a of the element e20 (e.g. present in the data format DF-SEC-PROT) through the element e22 and adapting them to a predefined format, e.g. CAN XL Frame Format, i.e. a data format DF-10 for CAN XL data frames, for example by means of a mapping of the corresponding information.

[0136] In some examples, Fig. 15, the configuration information l-CFG described above with reference to Fig. 14 can be supplied to elements e21, e22, e.g., the signal e23a. In some examples, Fig. 15, R.417584

[0137] - 22 -

[0138] Information associated with a priority between elements e20, e21, e22 is exchangeable, see signal e23b, e.g., transmittable from element e21 to element e20 and / or element e22. In some examples, Fig. 15, information associated with a priority regarding a source address and / or destination address is exchangeable between elements e20, e21, e22, see signal e23c, e.g., transmittable from element e21 to element e20 and / or element e22 (and / or vice versa, for example in the case of receiving).

[0139] The signal e23d symbolizes an exchange of information to be sent between elements e20 and e21, according to some examples, e.g., from element e21 to element e20. The signal e23e symbolizes an exchange of user data between elements e20 and e21, according to some examples, e.g., from element e21 to element e20. The signal e23f symbolizes an optional exchange of further data associated with the 10a bus system, e.g., CAN or CAN XL data, between elements e21 and e22, according to some examples.

[0140] In some examples, using configuration 13 according to Fig. 15, at least some aspects 160, 162, 164, 166 according to Fig. 11 can be realized, for example, where element e20 executes aspects of a MACsec protocol, and where elements e21, e22, for example, realize aspects of transforming or mapping information, e.g., from a CAN XL data format DF-10 to a format DF-SEC-PROT for the MACsec protocol (e.g., also an information flow from element e21 to element e20, e.g., signals e23b, e23c, e23d, e23e) and / or vice versa (e.g., also an information flow from element e20 to element e22, e.g., signals e20a) according to some examples.

[0141] In some examples, the signals e20a include at least one of the following elements: SecTAG (e.g., header information according to MACsec), or encrypted data, or checksum, e.g., ICV; see also elements 12-a, 12-b, 12-c according to Fig. 2.

[0142] In some examples, Fig. 15, a reception direction can be represented, e.g., analogously to the illustration of element 13 according to Fig. 15, e.g., also with the elements e20, e21, e22 and the associated ones, above under R.417584

[0143] - 23 -

[0144] Referring to the signals e23a, e23b described in Fig. 15, the receiving direction in some examples differs from the transmitting process described above (e.g., from left to right in Fig. 15) only by a processing direction in the sense of receiving (i.e., from right to left in Fig. 15). In other words, in some examples, at least some aspects 170, 172, 174, 176 according to Fig. 12 can be realized at least temporarily using configuration 13 according to Fig. 15.

[0145] For example, according to some examples, for receiving, element e22 according to Fig. 15 forms an input component, e.g. for receiving a MACsec-secured CAN XL data frame DR-sec at the terminal e22a (operating as an input for receiving, e.g.), while element e20 operates in a receive mode (e.g. for decrypting encrypted payload data of the received MACsec-secured CAN XL data frame and / or for checking a checksum, etc.), and while element e21 outputs, e.g. in the form of CAN XL information DR-unsec' (e.g. with checked checksum and / or decrypted payload data) to at least one higher level based on the information generated by element e20 in the receive mode at its terminal e21a.

[0146] In some examples (Fig. 15), both elements e21 and e22 use information from a CAN XL header to be processed. In some examples, this information from the CAN XL header can be communicated to element e20 either by encoding it into the destination (e.g., "Destination") and source (e.g., "Source") address fields (see signal e23c). Alternatively or additionally, in other examples, elements e21 and e22 can directly exchange the information from the CAN XL header to be processed (see signal e23f), potentially eliminating the need for back-and-forth mapping of the fields to the destination and source addresses.

[0147] Fig. 16 schematically shows aspects e30 of transforming information from a DF-10 data format of bus system 10, e.g., from a sphere of a CAN XL data frame, to a DF-SEC-PROT data format, as accessible to MACsec processing, e.g., by element e20 according to Fig. 15, according to some examples. Fig. 17 shows a representation comparable to Fig. 16 with further optional details according to some examples. R.417584

[0148] - 24 -

[0149] For example, a CAN XL data frame, e.g., a CAN XL MAC frame, begins with a Start of Frame (SOF) bit and ends with a 7-bit End of Frame (EOF) field, see Fig. 17. However, in some examples at the LLC level, not all frame fields of the MAC layer are yet present. In the example figure provided according to Figs. 16 and 17, LLC fields are shown hatched.

[0150] In some examples, Figs. 15, 16, 17, the element e21 can be configured to process at least one of the following elements, for example fields, of a CAN XL MAC frame: a) Priority ID (11 bits), or b) RRS (1 bit), or c) Format (3 bits; IDE, FDF, XDF), or d) SDT (8 bits), or e) SEC (1 bit; value e.g. 1), or f) DLC (11 bits), or g) VCID (8 bits), or h) AF (32 bits), or i) Data (e.g. byte length encoded in the DLC field, max. e.g. 2048 bytes), e.g. also the elements e1, e2, ... according to Fig. 5.

[0151] In some examples, the processing of the aforementioned fields, for example elements e1, e2, (Fig. 5), can serve to transform the relevant information e1 , e2, ... to the fields f1 , f2, f3 of an Ethernet frame, for example to map, i.e. e.g. destination address or ...

[0152] Destination Address f1 (48 Bit), Source Address f2, e.g. Source Address (48 Bit), User Data f3, e.g. User Data.

[0153] In some examples, the exact mapping (illustration) of the input fields of the CAN XL data frame to the output fields f1, f2, f3 for MACsec, e.g. including an order of the fields / bits, is not important, i.e., different orders can be used in different examples.

[0154] However, below, a useful mapping example, as shown in Fig. 17, is described for clarification. The fields Priority ID, RRS, Format (IDE, FDF, XDF), SDT, SEC, DLC, and VCID together have a length of 43 bits and can therefore be completely mapped to the Destination Address, field f1 (Fig. 17) in some examples. In these examples, field f1 thus remains, for example, 5 bits free, which can be filled with a constant (e.g., 0) in some examples. The AF field is R.417584

[0155] - 25 -

[0156] For example, it is 32 bits long and can therefore be completely mapped to the source address, field f2, in some examples. This leaves, for example, 16 bits free, which can also be filled with a constant (e.g., also 0).

[0157] Further examples illustrate different implementations of the principle as disclosed, where, for example, additional information can be inserted into a header. For this additional information, the 16 and 5 bits of fields f1 and f2 available in the example above can be used, for instance, instead of filling these 16 and 5 bits with a constant.

[0158] Figure 17 also shows another option, as shown in some examples, for mapping the fields of the CAN XL data frame with the DF-10 data format to the f1 field of the Destination Address. CANsec specifies a use case where individual fields of the header are excluded from authentication. This is relevant in some routing applications, where, for example, header fields of a data frame can change on a path from a source to a destination. Specifically, in some examples, the Priority ID and / or the VOID can be excluded from authentication. The principle according to the disclosure also supports this optional exclusion from authentication, for example, based on a corresponding configuration that is part of the CA configuration l-CFG (Figure 17).14) - a distinction is made between whether the fields (Priority ID and / or VOID) of the data frame should be mapped, or whether constant placeholders (e.g., 0) should be written into field f1 instead of the Priority ID and / or VOID information. This option is symbolized in Fig. 17 by the optional multiplexer device MUX and the arrows e31 (Priority ID and / or VOID information), e32 (e.g., constant values), and e33 (control of the multiplexer device MUX based on the CA configuration l-CFG).

[0159] Optionally, as shown in Fig. 17, in some examples, configuration information I-CFG (Fig. 14) of the CA 15 can also be mapped to field f2 of the DF-SEC-PROT data format for, e.g., MACsec; see element e34.R.417584

[0160] - 26 -

[0161] In some examples, the actual payload, called “Data field” in CAN, can be transferred into the Ethernet user data, see field f3.

[0162] In some examples (Figs. 16, 17), after mapping the information of the CAN XL data frame from the DF-10 format (which in some examples can be performed by element e21 according to Fig. 15), processing of at least one of the fields f1, f2, f3, e.g., according to MACsec, can be carried out, for example, by element e20 according to Fig. 15. After processing by element e20 (e.g., "MACsec entity"), the output e20a of element e20 can be mapped, e.g., again, to a CAN XL frame. In some examples, an inverse process to the mapping from the DF-10 format to the DF-SEC-PROT format can be used, which is described below with reference to the illustration in Figs. 18, 19.

[0163] Fig. 18 schematically shows aspects e40 of transforming information from a DF-SEC-PROT data format of the security protocol, e.g., MACsec, to the DF-10 data format, as used for a CAN XL data frame, according to some examples. Fig. 19 shows a representation comparable to Fig. 18 with further optional details according to some examples. Element e41 symbolizes a header, such as can be obtained by MACsec processing of element e20, e.g., a SecTag according to MACsec; see also element 1-2b according to Fig. 20. Element e42 symbolizes secured data, for example, encrypted user data. Element e43 symbolizes a checksum, e.g., ICV.

[0164] In some examples, Figs. 18, 19, the information contained in field f1, which is associated with the Destination Address, is split, for example mapped, into the fields: Priority ID, RRS, Format (IDE, FDF, XDF), SDT, SEC, DLC and VCID, see arrows e44. For example, the AF field e8 is extracted from the Source Address or the associated field f2, see arrow e45.

[0165] In some examples, additional information, e.g., extended header information, can optionally be extracted from field f2; see arrow e46 in Fig. 19 and arrow e34 in Fig. 17. (See R.417584 for some examples.)

[0166] - 27 -

[0167] The extended header information can be mapped, for example, to the beginning of the data field e9 (Fig. 18) of the DF-10 data format.

[0168] In some examples, Figs. 18, 19, an output e20a (Fig. 15) of element e20 (e.g., MACsec SecY entity) contains protected payload e42, the MACsec header e41 (e.g., the SecTAG), and a checksum e43, e.g., a cryptographic checksum (ICV). These three outputs e41, e42, e43 can be mapped to the data field e9 of the CAN XL frame in some examples. A mapping in the following order is advantageous because it also corresponds to a transmission sequence in some examples: SecTAG, Secure Data, ICV.

[0169] In some examples, Fig. 2, the abstraction layer WL for the SEC-PROT security protocol can be implemented relatively simply, for example, with little complexity. This is done, for instance, to ensure that a security solution based on the principle of disclosure, e.g., for CAN XL, differs as little as possible from a conventional security solution for Ethernet, such as MACsec, and / or remains as lean as possible with regard to the transmitted data. In this case, additional header fields can be omitted in some examples. If, in such relatively simple examples, several or all CANsec functionalities (e.g., a "routing" application, i.e., excluding the Priority ID / VCID from authentication) are to be supported, information for these CANsec functionalities can be included in the CA configuration, e.g., I-CFG according to Fig.14, be integrated, for example, instead of a provision for additional header fields.

[0170] In some other examples, Fig. 2, the abstraction layer WL for the SEC-PROT security protocol can be implemented in a comparatively complex manner, whereby, for example, the aforementioned, e.g., extended, CANsec functionalities (e.g., the “routing” application) are inserted into a frame to be transmitted via an additional header section (see also the aforementioned supplementary header data HD-ext, Fig. 9). In some examples, e.g., according to the mapping mentioned above, e.g., Figs. 16, 17, 18, 19, such an additional header section can be, for example, up to 16+5 bits long, see also the values ​​W-1, W-2 according to Fig. 6. This results in the following fields in some examples, R.417584

[0171] - 28 -

[0172] which can be transmitted in a CAN XL LLC Data Field, as shown in Fig.

[0173] 20 shown:

[0174] For example, see Fig. 20, the additional header information can have 16 bits, e.g. organized in the form of the following fields: a) AOT (e.g. 3 bits), or b) SECN (e.g. 1 bit), or c) VN (e.g. 3 bits), or d) EP (e.g. 1 bit), or e) EV (e.g. 1 bit), or f) Reserved (e.g. 7 bits), see also the HD-ext element according to Fig. 20.

[0175] In further examples, Fig. 20, the header data l-2b of the SEC-PROT security protocol, for example a security tag, for example SecTag (e.g. having 64 or 128 bits), can be provided by MACsec, e.g. organized in the form of the following fields: a) EtherType (e.g. 16 bits; value e.g. 0x88e5), or b) TCI & AN (e.g. 8 bits), or c) SL (e.g. 8 bits), or d) PN (e.g. 32 bits), or e) SCI (e.g. 64 bits; optional).

[0176] In further examples, in addition to the header information or header data l-2b (Fig. 20) and the extended header data HD-ext, a payload, i.e., user data and optionally a MACsec trailer (e.g., in the form of the checksum ICV; e.g., 128 bits), can be transmitted in the CAN XL LLC Data Field, e.g., also Fig. 19.

[0177] Thus, in some examples, all CANsec-specific fields can be covered using the principle according to the disclosure, and, for example, 7 bits remain available for future extensions. Therefore, some examples can provide a complete representation of the current CANsec specification while simultaneously using, for example, the MACsec implementation. The corresponding combination of header data l-2b, HD-ext for this is shown in Fig. 20.

[0178] In other examples, it is also possible to design the additional header information HD-ext (Fig. 20) to be larger than 16 bits, e.g. to achieve a total of 32 bits, which in some examples allows for quadlet alignment (i.e. a 4-byte alignment), which can be advantageous when processing the corresponding data, e.g. using software.

[0179] For example, the additional header information HD-extR.417584 can be used for this purpose.

[0180] - 29 -

[0181] As shown in Fig. 20, 16 more bits, e.g., reserved, can be added, each with a value of 0. However, it should be noted that in some examples, e.g., when using MACsec as a security protocol, these additional bits may not be fully secured by MACsec functionality in a transmitter. Therefore, in some examples, it may be necessary to leave at least some of these additional bits reserved.

[0182] In some examples, a code may be provided, for instance in a data frame for bus system 10 (Fig. 2), which can serve to signal to a receiver whether the data frame is protected by a disclosure-based method or, if applicable, by another security solution operating at ISO / OSI layer 2. In these examples, the receiver can thus be explicitly informed whether, for example, it should perform a security check based on the disclosure principle. In some examples, there are several possibilities for this signaling (e.g., labeled as "signaling of a security element"), for example in a CAN XL data frame.

[0183] In some examples, the protocol is signaled via an Ether-Type field in an Ethernet protocol stack. To enable this “Ethernet-native” detection, the WL abstraction layer could be adapted according to the disclosure in some, possibly less preferred, examples, which may, however, deviate from a “CAN XL-native” approach.

[0184] In some examples, such as CAN XL, the use of a security extension is encoded in the frame data via a Simple Extended Content (SEC) bit field and the AddOn-Type (AOT) field, instead of the EtherType field. Since the conventional MACsec frame format does not support these fields, this variant can be implemented generically in some examples, for example, using the extended header data HD-ext described above with reference to Fig. 20.

[0185] In further examples, the following encoding is proposed for efficient encoding of the use of the principle according to the disclosure, with CAN XL-native signaling using AOT and SEC frame fields: In some examples, the SEC bit field in the CAN XL header is set to “1”R.417584

[0186] - 30 -

[0187] The SEC bit is set to announce an extension function, analogous to a conventional use of the SEC bit field. The CAN XL stack now expects the 3-bit AOT field followed by the 1-bit SEC field at the beginning of the actual CAN XL data. The value of the AOT field encodes the extension function used. Currently, AOT = 010b is used for CANsec. The SECN bit, for example, encodes a subsequent, further extension function (i.e., "0" means no further extension follows, while "1" indicates an additional extension is used).

[0188] Since a security protocol, e.g., Security Protocol, is logically a first extension in a CAN XL stack in some examples, the SECN bit is e.g. “0”.

[0189] In some examples, it is suggested, for instance in a CiA working group, to specify the AOT value for a procedure as “100” in binary, according to the principle of disclosure. In this case, for example, the MACsec EtherType from a standard MACsec header can be used and interpreted twice. This superposition, as shown in some examples, is illustrated in Fig. 21. This works, for example, because the bit sequence “0b1000” corresponds to the first 4 bits of the MACsec EtherType (“0x88e5”).

[0190] In other words, in some examples the procedure has at least one of the following elements: a) signaling an extension function by setting the SEC field to "1", or b) signaling the use of a procedure according to the principle of disclosure by setting the AOT value to "100" in binary, i.e., "0b100".

[0191] Some examples, Fig. 22, relate to a use 300 of the method according to the disclosure and / or the device 200 according to the disclosure and / or the bus participant 12a, 12b, ... according to the disclosure and / or the computer-readable storage medium SM according to the disclosure and / or the computer program PRG according to the disclosure and / or the data structure DS according to the disclosure and / or the data carrier signal DCS according to the disclosure for at least one of the following elements: a) enabling 301 the use of the SEC-PROT security protocol for the bus system 10, for example for CAN XL and / or CAN FD, or b) using 302, for example reusing, a MACsec method for R.417584

[0192] - 31 -

[0193] CAN XL and / or CAN FD, or c) mapping 303 information of a data frame according to CAN XL and / or CAN FD to input information and / or at least one data format for the SEC-PROT security protocol, for example MACsec, or d) securing CAN XL, for example by means of MACsec, or e) securing 304 information of a CAN XL data frame associated with at least one control field, for example Control Field, for example securing a CAN XL header, or f) reducing 306 complexity, for example by avoiding Ethernet tunneling, or g) reducing 307 overhead, for example by avoiding Ethernet tunneling, or h) integrating 308 MACsec functionality into a bus participant 12a, 12b, ...for CAN XL and / or CAN FD, or i) optionally including or excluding (for example, excluding) 309 a CAN XL Priority ID and / or a Virtual CAN Network ID, VCID, in an authentication, for example, MACsec-based, or j) adding 310 one or more functionalities associated with CANsec, for example, to a MACsec header, or k) enabling 311 a representation, for example, of a current CANsec functionality and / or specification using MACsec, for example, a MACsec implementation.

[0194] Further examples and aspects relating to the processing of information from or for CAN FD data frames are described below, with reference to Figures 23 to 26. In some examples, the processing of the information in question can be carried out, at least temporarily and at least partially, by means of the device 200 (see Figures 2, 13) or by means of at least one of the elements 13, 14 according to Figure 14, e.g., also the elements e20, e21, e22 according to Figure 14.

[0195] 15.

[0196] Fig. 23 schematically shows aspects e30a of a transformation of information from a data format of the bus system 10, in this case e.g. from a sphere of a CAN FD data frame, to a data format DF-SEC-PROT, as is the case with MACsec processing, e.g. by element e20 according to Fig.

[0197] 15 is accessible, according to some examples. R.417584

[0198] - 32 -

[0199] For example, Fig. 23 shows aspects of mapping fields e50, e51, ... of a CAN FD FBFF LLC data frame to Ethernet frame fields f1, f2, f3, according to some examples. In some examples, such a mapping can be used, for example, by element e21 according to Fig. 15, when aspects of a (for example, previously unsecured) CAN FD data frame (see also element DR-unsec from Fig. 15) are to be transformed into a DF-SEC-PROT data format, which enables, for example, the processing of one or more functions according to MACsec, for example, by element e20 according to Fig. 15. For example, the element e20 can generate outputs e20a based on the information supplied to it, for example mapped, e.g. from fields e50, e51, ... of the CAN FD FBFF data frame, which are mapped to at least the fields f1 , f3 in the manner symbolized by the arrows e60, e61, e62 in Fig. 23.

[0200] In some examples, Fig. 23, information from at least one of the following elements can be mapped to field f1: a) element e50, for example associated with a Base Identifier of the CAN FD FBFF data frame, or b) element e51, for example associated with at least one element from IDE, FDF of the CAN FD FBFF data frame, or c) element e52, for example associated with an element res of the CAN FD FBFF data frame, or d) element e53, for example associated with an element BRS of the CAN FD FBFF data frame, or e) element e54, for example associated with an element DLC of the CAN FD FBFF data frame.

[0201] In some examples, Fig. 23, information from the data field, e.g. containing payload data, see element e55, can be mapped to the field f3, see the arrow e63.

[0202] In some examples, Fig. 23, e.g. similar to the configuration according to Figs. 16, 17, a multiplexer device MUX can be installed in the element e30a according to Fig.

[0203] 23 is provided, which, for example, based on a CA configuration (e.g., the information l-CFG according to Fig. 14), can control whether information from element e50 or, for example, other information such as constant values, see the "Const." block according to Fig. 23, is mapped into field f1, see arrow e60.R.417584

[0204] - 33 -

[0205] In some examples, Fig. 23, a mapping of element e52 into the field f1 is optional.

[0206] In some examples, Fig. 23, it is possible that one or more predefinable values, for example (e.g. further) constant values, e.g. having a length of 29 bits or 30 bits, are mapped into the field f1, see the arrow e61.

[0207] In some examples, Fig. 23, it may be possible to map at least parts of the CA configuration and / or further information into field f2, see arrow e62 according to Fig. 23, e.g. at least similar to arrow e34 according to Fig. 17.

[0208] In some examples, Fig. 23, processing at least some of the information associated with fields f1, f2, f3 according to Fig. 23, for example by element e20 according to Fig. 15, results in elements f1, f2, e41, e42, e43 according to Fig. 25. It is noted that in some examples, the processing of the information associated with the CAN FD FBFF data frame according to Fig. 23 is at least similar to the processing of the information associated with a CAN XL data frame according to Figs. 16, 17, the respective information content depending in some examples on the specific elements e1, e2, ... (Fig. 16) or e50, e51, ... of the data frames in question.

[0209] Figure 25 shows that even when processing at least some of the information associated with fields f1, f2, f3 according to Figure 23, elements f1, f2, e41, e42, e43 (possibly with correspondingly modified content) are obtained, the information of which, according to Figure 25, is mapped in some examples to elements e50, e51, ... of a (now, for example, at least partially secured) CAN FD FBFF data frame (see also element DR-sec according to Figure 15), see the arrows e70, e71, e72 and block e40a. For example, information from field f1 according to Figure 25 is mapped to at least some of the fields e50, e51, e52 (e.g., optionally), e53, e54. For example, information from field f2 according to Figure 25 is mapped to at least field e55. For example, information from at least some of the elements e41, e42, e43 according to Fig. 25 is mapped at least to field e55. R.417584

[0210] - 34 -

[0211] Fig. 24 schematically shows aspects e30b of a transformation of information from a data format of the bus system 10, in this case e.g. from a sphere of a CAN FD data frame, to a data format DF-SEC-PROT, as is the case with MACsec processing, e.g. by element e20 according to Fig.

[0212] 15 is accessible, according to some examples.

[0213] For example, Fig. 24 shows aspects of mapping fields e50, e51a, e51b, ... of a CAN FD FEFF LLC data frame to Ethernet frame fields f1, f2, f3, according to some examples. In some examples, such a mapping can be used, for example, by element e21 according to Fig. 15, when aspects of a (for example, previously unsecured) CAN FD data frame (see also element DR-unsec from Fig. 15) are to be transformed into a DF-SEC-PROT data format, which enables, for example, the processing of one or more functions according to MACsec, for example, by element e20 according to Fig. 15. For example, the element e20 can generate outputs e20a based on the information supplied to it, for example mapped, e.g. from the fields e50, e51 a, e51 b, ... of the CAN FD FEFF data frame, which are mapped to at least one of the fields f1 , f3 in the manner symbolized in Fig. 24 by at least one of the arrows e64, e65, e66.

[0214] In some examples, Fig. 24, information from at least one of the following elements can be mapped to field f1: a) element e50, for example associated with a Base Identifier of the CAN FD FEFF data frame, or b) element e51a, for example associated with at least one IDE element of the CAN FD FBFF data frame, or c) element e51b, for example associated with an Identifier Extension element of the CAN FD FBFF data frame, or d) element e51c, for example associated with an FDF element of the CAN FD FBFF data frame, or e) element e52 (e.g., optional), for example associated with a res element of the CAN FD FEFF data frame, or f) element e53, for example associated with a BRS element of the CAN FD FEFF data frame, or g) element e54, for example associated with a DLC element of the CAN FD FEFF data frame. R.417584

[0215] - 35 -

[0216] In some examples, Fig. 24, information from the data field, e.g. containing payload data, see element e55, can be mapped to the field f3, see arrow e67.

[0217] In some examples, Fig. 24, e.g. similar to the configuration according to Figs. 16, 17, 23, a multiplexer device MUX can be provided in element e30b according to Fig. 24, which can control, e.g. based on a CA configuration (e.g. the information l-CFG according to Fig. 14 or block "CA Conf." according to Fig. 24), whether information from element e50 or e.g. other information such as constant values, see the block "Const." according to Fig. 24, is mapped into field f1, see arrow e64.

[0218] In some examples, Fig. 24, a mapping of element e52 into the field f1 is optional.

[0219] In some examples, Fig. 24, it is possible for one or more predefinable values, for example (e.g., further) constant values, e.g., having a length of 11 bits or 12 bits, to be mapped into field f1, see arrow e65 (here, for example, less than the 29 or 30 bits given as an example according to Fig. 23, arrow e61, e.g., due to a space requirement given in the configuration according to Fig. 24, e.g., for the Identifier Extension, see field e51b, according to Fig. 24, which, for example, in the configuration according to Fig.

[0220] 23 is not available).

[0221] In some examples, Fig. 24, it may be possible to map at least parts of the CA configuration and / or further information into field f2, see arrow e66 according to Fig. 24, e.g. at least similar to arrow e34 according to Fig. 17 or to arrow e62 according to Fig. 23.

[0222] In some examples, Fig. 24, processing at least some of the information associated with fields f1, f2, f3 according to Fig. 24, for example by element e20 according to Fig. 15, results in elements f1, f2, e41, e42, e43 according to Fig. 26. It is noted that in some examples, the processing of the information associated with the CAN FD FEFF data frame according to Fig. 24 is at least similar to the processing of the information associated with a CAN XL data frame according to Figs. 16, 17.

[0223] - 36 -

[0224] and / or to the processing of the information associated with the CAN FD FBFF data frame according to Fig. 23, wherein the respective information content in some examples depends on the specific elements e1, e2, ... (Fig. 16) or e50, e51, ... or e50, e51a, ... of the data frames in question.

[0225] Fig. 26 shows that even when processing at least part of the information associated with the fields f1, f2, f3 according to Fig. 24, elements f1, f2, e41, e42, e43 (possibly with correspondingly modified content) are obtained, the information of which, according to Fig. 26, in some examples is transferred to the elements e50, e51a, e51b, ... of a (now, for example, at least partially secured) CAN FD FEFF data frame (see also element DR-sec according to Fig. 26).

[0226] 15) are shown, see arrows e73, e74, e75 and block e40b.

[0227] For example, information from field f1 according to Fig. 26 is mapped to at least some of the fields e50, e51a, e51b, e51c, e52 (e.g., optionally), e53, e54. For example, information from field f2 according to Fig. 26 is mapped to at least field e55. For example, information from at least some of the elements e41, e42, e43 according to Fig. 26 is mapped to at least field e55.

[0228] In some examples, Fig. 23, e.g., according to ISO 11898-1:2024, a res bit (see element e52) is part of the LLC format field in CAN FD data frames. The LLC format field contains, for example, IDE, FDF, and the res bit. Optionally, the res bit can be omitted in some examples (i.e., not protected by a security protocol, e.g., MACsec), for example, because it is an integral part of the CAN FD frame format. Thus, in some examples, a deviation would invalidate a MAC frame. This is because, according to ISO 11898-1, the res bit for CAN FD frames is fixed at 0 (dominant) in some examples. However, the standard further specifies, for example, that a receiver can accept frames with res bit = 1 (recessive) and, in some examples, should report an error. This handling is not always implemented in at least some examples. Therefore, in some examples, it may be that, for example,Conventional implementations accept frames with the res-bit = 1 on a receive side, whereas in some examples, such a frame would be discarded according to the disclosure, e.g., by the functionality FUN-1 secured with MACsec. For this reason, some examples provide an optional exclusion, e.g., so that changes to the res-bit still work, e.g., R417584.

[0229] - 37 -

[0230] as described in the CAN standard, e.g. without being discarded by a data link layer.

[0231] In some examples, e.g., Fig. 23, one or more of the following fields can be processed – as already described above, at least partially, with reference to Fig. 23 ff. – e.g., for a mapping to the DF-SEC-PROT data format: a) Base ID (e.g., having 11 bits), or b) Extended ID (e.g., having 18 bits; e.g., in the case of a CAN FD FEFF frame), or c) Format (e.g., having 2 or 3 bits; e.g., IDE, FDF, (optional) res), or d) BRS (e.g., having 1 bit), or e) DLC (e.g., having 4 bits), or f) Data (e.g., payload data, e.g., having a byte length as encoded in the DLC field, e.g., having a maximum of 64 bytes).

[0232] In some examples, e.g. Fig. 23, as already described above at least partially with reference to Fig. 23 ff., one or more fields f1, f2, f3 of an Ethernet frame can be obtained as output of the mapping described above as an example: a) Destination Address (e.g. having 48 bits), or b) Source Address (e.g. having 48 bits), or c) User Data.

[0233] In some examples, Fig. 23, for an actual function of, for example,

[0234] For MACsec-based processing of CAN FD data frame information, a precise mapping (e.g., as shown in the figure) of the input fields e50, e51, e52, ... to the output fields f1, f2, f3, including an order of the fields and / or bits, is not essential. However, for clarity, a sensible mapping according to some examples is shown above with reference to Figures 23 and 24, including the arrows e60, e61, e52, ... .

[0235] In some examples, the fields Base ID, Extended ID, Format, and DLC together are, for example, a) 18 bits long (e.g., in one case for FBFF frame format, res excluded), or b) 19 bits long (e.g., in one case for FBFF frame format, res included), or c) 36 bits long (e.g., in one case for FEFF frame format, res excluded), or d) 37 bits long (e.g., in one case for FEFF frame format, res included). Thus, in some examples (Figs. 23, 24), the aforementioned fields Base ID, Extended ID, Format, and DLC can be completely mapped to the Destination Address, field f1. In some examples, R.417584

[0236] - 38 -

[0237] Field f1 then has, for example, 30, 29, 12, or 11 free bits (Oe according to case a), b), c), d), see above), whereby these free bits can be filled with at least one constant (e.g., "0") in some examples, see arrows e61 according to Fig. 23 and e65 according to Fig. 24. In some examples, the source address, e.g., field f2, remains unused in this mapping e60, e61 or e64, e65 and can, for example, be filled with at least one further constant (e.g., 0).

[0238] Figures 23 and 24 also illustrate further options for mapping at least some CAN fields to the destination address, field f1, according to some examples. CANsec specifies, for example, a use case where individual header fields are excluded from authentication. This is relevant in some examples, such as routing applications, where header fields of a frame can change on the way from the source to the destination. Specifically, the Base ID and / or Extended ID can be excluded from authentication. In some examples, this exclusion from authentication can also be provided for, for example, by differentiating—based on a corresponding configuration that can be part of the CA configuration—whether the actual frame fields (e.g., Base ID / Extended ID) should be mapped, see arrows e60 and e64, or instead, for example, constant placeholders (e.g., "0").The optional mapping of, for example, Base ID and / or Extended ID or - instead of Base ID and / or Extended ID - at least a constant, as described above, can be controlled in some examples by the multiplexer device MUX, for example, as already described, based on at least a part of the CA configuration.

[0239] Since, as described above, the res bit may be part of the LLC format according to the specification in some examples, but in some implementations this LLC bit is not always present at the LLC layer, this res bit can be optionally removed from the mapping in some examples, as explained in the examples described above, e.g. the "optional" blocks between element e52 and arrow e60 according to Fig. 23 or between element e52 and arrow e64 according to Fig. 24.R.417584

[0240] - 39 -

[0241] In some examples, Fig. 23, the actual payload, e.g. user data, called "Data field" in CAN, can be mapped into the Ethernet user data, e.g., transferred, e.g., arrow e63.

[0242] After processing the information mapped as described above, e.g., in fields f1, f2, f3 according to Figures 23 and 24, e.g., by a MACsec entity, such as element e20 according to Figure 15, the output e20a of the MACsec entity e20 can, in some examples, be mapped back to a CAN FD data frame, e.g., arrows e70, e71, e72 according to Figure 25 or arrows e73, e74, e75 according to Figure 26. In some examples, this mapping, e.g., arrows e70, e71, e72 according to Figure 25 or arrows e73, e74, e75 according to Figure 26, runs analogously, i.e., "backwards," to the mapping described above with reference to Figures 23 and 24. e60, e61, e62, e63 (Fig. 23) or e64, e65, e66, e67 (Fig. 24). This means that in some examples, the Destination Address, field f1, is further divided into Base ID, Extended ID, Format (IDE, FDF, res, BRS) and DLC.

[0243] Alternatively or additionally, in some examples (Fig. 15), e.g., element e21 can pass the CAN header data directly to element e22 (see element e23f). Thus, element e22 does not need to decode the relevant data from the Destination Address, field f1.

[0244] In some examples, Figs. 25, 26, output e20a (Fig. 15) of the MACsec entity, element e20, provides, for example, protected user data e42 (e.g., "User Data"), a MACsec header (the SecTAG) e41, and a cryptographic checksum (ICV) e43. In some examples, Figs. 25, 26, these three outputs, SecTAG e41, Secure Data e42, and ICV e43, are mapped, for example, to the Data field e55 of the CAN FD frame. A mapping in the aforementioned order is advantageous, for example, because in some examples this also corresponds to a transmission sequence: SecTAG, Secure Data, ICV.

Claims

R.417584 - 40 - Claims 1. Method, for example a computer-implemented method, for a serial bus system (10), comprising: providing (100) a first functionality (FUN-1) configured to execute a security protocol (SEC-PROT) associated with layer 2 of the ISO / OSI layer model, processing (102) information (1-10) of the serial bus system (10), for example at least one component (12a, 12b, ...) of the serial bus system (10), using the first functionality (FUN-1).

2. Method according to claim 1, wherein a) the serial bus system (10) is of type Controller Area Network extra large, CAN XL, for example according to or based on ISO 11898-1:2024 and / or of type CAN FD, and / or wherein b) the security protocol (SEC-PROT) is of type Media Access Control Security, MACsec, for example according to or based on IEEE 802.1 AE.

3. A method according to at least one of the preceding claims, comprising: providing (110) an abstraction layer (WL) for the security protocol (SEC-PROT), wherein the abstraction layer (WL) is configured for at least one of the following elements: a) receiving (110a) at least a part (1-10') of the information (1-10) of the serial bus system (10), or b) processing (110b) the at least part (1-10') of the information (1-10) of the serial bus system (10) by means of the first functionality (FUN-1), whereby processed information (1-10") is obtained, or e) outputting (110c) the processed information (1-10'), and, optionally, at least intermittently using (112) the abstraction layer (WL) to process the at least part (1-10') of the information (1-10) of the serial bus system (10) according to the security protocol (SEC-PROT).R.417584 - 41 - 4. Method according to at least one of claims 2 to 3, wherein the processing (102) comprises at least one of the following elements: a) at least temporary processing (102a) of header data of at least one data frame of the serial bus system (10), or b) encryption (102b) of at least one part (1-10') of the information (1-10), or c) decryption (102c) of at least one part (1-10') of the information (1-10), or d) execution (102d) of authentication associated with at least one part (1-10') of the information (1-10).

5. A method according to at least one of the preceding claims, comprising at least one of the following elements: a) transforming (120) at least a part (1-10') of the information (1-10), for example from a format associated with the bus system (10), for example data format, (DF-10) into a format associated with the security protocol (SEC-PROT), for example data format, (DF-SEC-PROT), for example mapping (120a) the at least part (1-10') of the information (1-10), for example from the format associated with the bus system (10) (DF-10) into the format associated with the security protocol (SEC-PROT) (DF-SEC-PROT), thereby obtaining transformed information (1-1), or b) processing (122) the transformed information (1-1) by means of the first functionality (FUN-1), thereby obtaining processed information (I-2).or c) transform (124) at least part (I-2') of the processed information (I-2) into the format (DF-10) associated with the bus system (10), for example mapping (124a) of at least part (I-2') of the processed information (I-2) into the format (DF-10) associated with the bus system (10).

6. The method of claim 5, wherein the transform (120), for example mapping (120a), comprises: transform (120'), for example mapping (120a'), at least one of the following elements, for example from the format associated with the bus system (10), for example data format, (DF-10), into the format associated with the security protocol (SEC-PROT), for example data format, (DF-SEC-PROT): a) an element (e1) of type Priority ID, for example having 11 bits, or b) an element (e2) of type RRS, for example having 1 bit, or c) an element (e3) of type Format, for example having 3 bits, R.417584 - 42 - for example, characterizing at least one of c1) an IDE, Identifier Extension Flag, bit, or c2) an FDF, FD Frame flag, bit, or c3) an XLF, XL Frame flag, bit, or d) an element (e4) of type Service Data Unit, SDU, type, SDT, for example having 8 bits, or e) an element (e5) of type Simple Extended Content flag, SEC, for example having 1 bit, or f) an element (e6) of type Data Length Code, DLC, for example having 11 bits, or g) an element (e7) of type Virtual CAN ID, VCID, for example having 8 bits, or h) an element (e8) of type Acceptance Field, AF, for example having 32 bits, or i) an element (e9) of type Data, for example characterizing payload data, for example having a length encoded by the element (e6) of type DLC, for example a maximum of 2048 bytes,where, for example, the format (DF-SEC-PROT) associated with the security protocol (SEC-PROT) has at least one of the following elements: A) a field (f1) for a destination address, or B) a field (f2) for a source address, or C) a field (f3) for data, for example, payload data.

7. The method of claim 6, comprising: mapping (120b) at least some, for example all, of the following elements to the field (f1) for the target address: a) the element (e1) of type Priority ID, or b) the element (e2) of type RRS, or c) the element (e3) of type Format, or d) the element (e4) of type Service Data Unit, SDU, Type, SDT, or e) the element (e5) of type Simple Extended Content flag, SEC, or f) the element (e6) of type Data Length Code, DLC, or g) the element (e7) of type Virtual CAN ID, VCID.

8. Method according to at least one of claims 6 to 7, comprising at least one of the following elements: a) filling (130) a predefinable area, for example comprising five bits, of the field (f1) for the destination address, with a predefinable first value (W-1), for example 0, for example 00000b, or b) mapping (132) the element (e8) of type Acceptance Field, AF, to the field (f2) for the source address, or c) filling (134) a predefinable area, for example comprising sixteen bits, of the field (f2) for the source address, with a predefinable second value (W-2), for example 0, for example 0000000000000000b, or d) mapping - 43 - (136) of the element (e9) of type data, for example payload, to the field (f3) for the data, for example payload.

9. Method according to at least one of claims 6 to 8, comprising: optionally, for example based on an initial configuration information (l-CFG-1), A) map (140) at least one of the following elements to the field (f1) for the destination address: a) the element (e1) of type Priority ID, or b) the element (e7) of type Virtual CAN ID, VCID, or B) map (142) at least one predefinable third value (W-3), for example instead of at least one of the elements (e1 , e7), to the field (f1) for the destination address.

10. Method according to at least one of claims 5 to 9, wherein the processed information (I-2) comprises at least one of the following elements: a) protected, for example encrypted, user data (I-2a), or b) a header (I-2b), for example header data, of the security protocol (SEC-PROT), for example a security tag, for example SecTag, or c) a checksum (I-2c), for example cryptographic, for example Integrity Check Value, ICV.

11. Method according to claim 10, wherein the mapping (124a) of at least one part (I-2') of the processed information (I-2) into the format (DF-10) associated with the bus system (10) comprises: mapping (124a') at least one of the elements a) user data (I-2a), or b) header (I-2b), or c) checksum (I-2c) into a user data field of a data frame for the bus system (10).

12. The method of claim 11, comprising: providing (150) supplementary header data (HD-ext), wherein the supplementary header data (HD-ext) comprises at least one of the following elements: a) an element (e10) of type AddOn-Type, AOT, for example comprising 3 bits, or b) an element (e11) of type Simple Extended Content, SEC, for example comprising 1 bit, or c) an element (e12) of type Version Number, VN, for example comprising 3 bits, or d) an element (e13) of type EP, for example comprising 1 bit, or e) an element (e14) of type EV, for example comprising 1 bit, or f) an element (e15) of type "reserved", for example for future use, for example R.417584 - 44 - having 7 bits, and, optionally processing (152) the supplementary header data (HD-ext), for example combining (152a) the supplementary header data (HD-ext) with the header (l-2b), for example integrating (152b) the supplementary header data (HD-ext) into the header (l-2b).

13. Method according to at least one of the preceding claims, comprising: receiving (160) a data frame (DR-unsec), for example an unsecured one, for the bus system (10), for example an unsecured CAN XL data frame, processing (162) at least some information (1-DR-unsec) of the received data frame (DR-unsec) according to the security protocol (SEC-PROT), forming (164) based on at least parts of the data frame (DR-unsec), for example an unsecured one, and on the processing (162) of a data frame (DR-sec) that is at least partially secured, for example an CAN XL data frame that is at least partially secured, for the bus system (10), and optionally, transmitting (166) the data frame that is at least partially secured.

14. Method according to claim 13, wherein the processing (162) comprises at least one of the following elements: a) forming (162a) a header (SEC-PROT-HEAD; l-2b) according to the security protocol (SEC-PROT), for example a MACsec header, or b) forming (162b) a checksum (SEC-PROT-CS; l-2c) according to the security protocol (SEC-PROT), for example a MACsec checksum, for example Integrity Check Value, or c) encrypting (162c) data, for example user data.

15. Method according to at least one of the preceding claims, comprising: receiving (170) a data frame (DR-sec), for example at least partially secured, for the bus system (10), for example a CAN XL data frame, for example at least partially secured; processing (172) at least some information (1-DR-sec) of the received data frame (DR-sec) according to the security protocol (SEC-PROT); forming (174) based on at least parts of the data frame (DR-sec), for example at least partially secured; and processing (172) a data frame (DR-unsec), for example R.417584 - 45 - of an unsecured CAN XL data frame, for the bus system (10), and optionally, output (176) of the, for example, unsecured, data frame (DR-unsec').

16. Method according to claim 15, wherein the processing (172) comprises at least one of the following elements: a) evaluating (172a) a header (SEC-PROT-HEAD; l-2b) according to the security protocol (SEC-PROT), for example a MACsec header, or b) checking (172b) a checksum (SEC-PROT-CS; l-2c) according to the security protocol (SEC-PROT), for example a MACsec checksum, for example Integrity Check Value, or c) decrypting (172c) encrypted data, for example user data.

17. Device (200) for a serial bus system (10), wherein the device (200) is configured to perform the method according to at least one of the preceding claims.

18. Bus participant (12a, 12b, ...) for a serial bus system (10), wherein the bus participant (12a, 12b, ...) comprises at least one device (200) according to claim 17.

19. Computer-readable storage medium (SM) comprising instructions (PRG) which, when executed by a computer (202), cause it to execute the method according to at least one of claims 1 to 16.

20. Computer program (PRG) comprising instructions which, when the program (PRG) is executed by a computer (202), cause it to execute the method according to at least one of claims 1 to 16.

21. Data structure (DS), for example, a computer-implemented data structure, comprising at least one of the following elements: a) a field (f1) for a destination address, or b) a field (f2) for a source address, or c) a field (f3) for data, or d) user data (I-2a), or b) header (I-2b), or c) checksum (I-2c).

22. Data carrier signal (DCS) that transmits and / or characterizes the computer program (PRG) according to claim 20 and / or the data structure (DS) according to claim 21. R.417584 - 46 - 23. Use (300) of the method according to at least one of claims 1 to 16 and / or the device (200) according to claim 17 and / or the bus participant (12a, 12b, ...) according to claim 18 and / or the computer-readable storage medium (SM) according to claim 19 and / or the computer program (PRG) according to claim 20 and / or the data structure (DS) according to claim 21 and / or the data carrier signal (DCS) according to claim 22 for at least one of the following elements: a) enabling (301) the use of the security protocol (SEC-PROT) for the bus system (10), for example for CAN XL and / or CAN FD, or b) using (302), for example reusing, a MACsec method for CAN XL and / or CAN FD, or c) mapping (303) information from a data frame according to CAN XL and / or CAN FD to input information and / or at least one data format (DF-SEC-PROT) for the security protocol (SEC-PROT), for example MACsec, or d) Securing (304) CAN XL,for example by means of MACsec, or e) securing (305) information associated with at least one control field, for example Control Field, of a CAN XL data frame, for example securing a CAN XL header, or f) reducing (306) complexity, for example by avoiding Ethernet tunneling, or g) reducing (307) overhead, for example by avoiding Ethernet tunneling, or h) integrating (308) MACsec functionality into a bus participant (12a) for CAN XL and / or CAN FD, or i) selectively including or excluding (309), for example excluding, a CAN XL Priority ID and / or a Virtual CAN Network ID, VCID, from an authentication, for example MACsec-based, or j) adding (310) one or more functionalities associated with CANsec, for example to a MACsec header, or k) enabling (311) a, for example complete, Presentation of, for example, a current,CANsec functionality and / or specification using MACsec, for example a MACsec implementation.

Images