SECURE COMMUNICATION THROUGH THE IMPLEMENTATION OF A PRIORITY MESSAGE QUEUE MANAGEMENT SYSTEM

Abstract

The described techniques address problems related to the compatibility and cost-efficiency of onboard networks. For example, they can utilize Ethernet-based security protocols without the need to exchange separate key agreement messages, thus meeting the stringent startup time requirements for real-time control systems. Additionally, a membership tracking solution can be implemented, allowing each node within a membership group to request or "challenge" other nodes in the same group to verify their online status, and this online status can be maintained over time. Finally, a transmission queue management process is described that deletes pending messages only after it has been determined that every intended receiver node has received the message, thereby providing atomicity.Held messages can then be retransmitted according to a transmission schedule.

Description

TECHNICAL FIELD

[0001] The disclosure relates generally to the use of secure data communication and, in particular, to the use of secure communication that utilizes locally stored key counter values ​​according to a real-time bus key distribution system to eliminate the need for dedicated key agreement messages. The disclosure also relates to the use of live membership groups to provide an additional layer of security by adding data to scheduled secure messages transmitted between nodes within membership groups without using dedicated secure messages for this purpose. Additionally, the disclosure relates to the use of a process for utilizing responses from nodes within groups to manage message transmission queues and achieve atomicity within such groups. BACKGROUND

[0002] Controller Area Network (CAN), Controller Area Network Flexible Data-Rate (CAN FD), Controller Area Network Extra Long (CAN XL), and Ethernet communication protocols are currently the dominant networks / protocols implemented for communication in onboard vehicle systems, utilizing an accompanying electrical / electronic (E / E) architecture. However, these conventional approaches have several drawbacks, particularly regarding the communication overhead required to distribute shared session keys used for authentication, encryption, and decryption of secure messages within the network.

[0003] Additionally, conventional communication protocols like CAN, CAN FD, and CAN XL utilize a concept known as "atomic transmission." This communication technique ensures that every receiving node actually receives a message. For example, CAN can implement an error mechanism that causes a node to destroy the frame if it detects an error. A sender then retransmits the frame, and this process can be repeated until all nodes have received the frame. This feature is incredibly useful for enabling robust systems, although designing such systems with higher-layer software is very difficult because such systems are typically complex, resource-intensive, and slow.To this end, it is noted that CAN-based protocols support atomic transmission in this way at a lower network layer, generally using hardware implementations, and rely on an acknowledgment bit field (ACK) in a transmitted frame that is modified by the receivers of the secured message.

[0004] Attempts to integrate atomic transmission functionality into Ethernet-based protocols have been insufficient, as Ethernet-based nodes simply discard faulty frames (e.g., CRC check failures) and leave it to higher-level software applications to resolve the issue. Other attempts to integrate atomic transmission functionality into Ethernet-based architectures involve the use of high-availability seamless redundancy (HSR) topologies. However, each of these Ethernet-based atomicity solutions either focuses on the higher-level software application or relies on a specific ring-based architecture and message redundancy, resulting in significant complexity, time-based limitations, and costs, and making them unsuitable for real-time control system applications that require fast and robust measurements. BRIEF DESCRIPTION OF THE DRAWINGS / FIGURES

[0005] The accompanying drawings, which are included herein and form part of the description, illustrate the aspects of the present disclosure and, together with the description, further serve to explain the principles of the aspects and to enable a person skilled in the art to manufacture and use the aspects. Fig. 1A illustrates the use of a conventional key agreement message protocol for low-priority frameworks; Fig. 1B illustrates the use of a conventional key agreement message protocol for high-priority frameworks; Fig. 2A illustrates an example node architecture according to one or more embodiments of the disclosure; Fig. 2B illustrates an example session key generator according to one or more embodiments of the disclosure; Fig. 2C illustrates an example of a received Freshness Value (FV) protocol according to one or more embodiments of the disclosure; Fig. Figure 3 illustrates an example system of interconnected nodes containing defined safety zones, according to one or more embodiments of the disclosure; Fig. 4A illustrates an example format of a received secure message according to one or more embodiments of the disclosure; Fig. 4B illustrates an example format of a transmitted secure message according to one or more embodiments of the disclosure; Fig. Figure 5 illustrates an example of the use of a hardware-based solution for utilizing freshness values ​​according to one or more embodiments of the disclosure; Fig. Figure 6 illustrates an example implementation of a hardware-based implementation for adapting the secure messaging system to an existing conventional system according to one or more embodiments of the present disclosure; Fig. 7A and Fig. 7B illustrates example process flows according to one embodiment of the disclosure; Fig. Figure 8 illustrates example formats for secure messages used to request and respond to online status verification requests according to one or more embodiments of the disclosure; Fig. 9A and Fig. 9B illustrates example process flows according to one embodiment of the disclosure; Fig. Figure 10 illustrates a conventional HSR (High-availability Seamless Redundancy) ring topology that attempts to provide atomicity for Ethernet-based networks; Fig. 11 illustrates another example node architecture according to one or more embodiments of the disclosure; Fig. 12A and Fig. 12B illustrate block diagrams of a message queue management system based on acknowledgments received from other nodes according to an embodiment of the disclosure; Fig. Figures 13A-13D illustrate examples of the register contents of different nodes within the same group to support atomicity according to one embodiment of the disclosure; and Fig. Figure 14 illustrates an example process flow according to one embodiment of the disclosure.

[0006] The exemplary aspects of this disclosure are described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference symbol. SUMMARY

[0007] Here too, conventional communication protocols and electrical / electronic (E / E) architectures exhibit various disadvantages, particularly regarding processing power, overhead, and the time required to generate the shared keys necessary for authentic and secure communication across the network. For example, a typical E / E architecture used for communicating secure messages, as discussed further herein, might comprise a system of interconnected "nodes" that could represent any suitable type of device within a network designed to send and receive secure messages, such as sensors, electronic control units, actuators, electromechanical components, and so on.The number of interconnected nodes in such systems can be on the order of dozens or hundreds, and each node can transmit and receive secure messages to other nodes within the interconnected system.

[0008] The underlying network supporting the system of interconnected nodes can be implemented as part of any suitable system type that utilizes secure communication, such as an onboard network, industrial-grade networks like those used in production lines, and so on. For example, an interconnected system of nodes can comprise groups of nodes that communicate securely over a connected transmission bus to enable a real-time control system. Such a real-time control system can utilize the communication of sensor data, control data, or other data and may include components that could pose a significant safety risk in the event of a failure. Therefore, specific operating parameters must be considered to ensure robust, secure communication within such systems.

[0009] For example, any node in such a real-time control system can be reset at any time (e.g., if an internal watchdog timer is triggered), resulting in the loss of all data in the node's volatile memory (RAM). Furthermore, after startup (or restart), a node must be able to resume communication very quickly, i.e., within a few milliseconds, to receive and send messages (e.g., sensor data, actuator commands, etc.) to other nodes on the bus. Messages must also be protected against manipulation by an attacker and may need to be encrypted to prevent an attacker from viewing the message content. A node should also be protected against retransmission attacks (i.e., when an attacker takes a copy of a message sent on the bus and retransmits it later to try to trick the receiving nodes into responding).Additionally, cryptographic systems for secure message transmission must change the keys when they are “exhausted” (i.e., have been used too often), and each group of nodes involved in secure communication must agree on the same values ​​for a replacement key.

[0010] For this purpose, it is noted that secure messages are generated before transmission by a node using one or more shared keys, also known as shared secrets or cipher keys, which generally do not change during the lifetime of the nodes. The shared keys are typically stored in each node's local memory and provided as input to a cryptographic block that implements a cryptographic function such as a key derivation function (KDF). The cryptographic block also receives input in the form of a counter value, which may change over time, as well as any other suitable inputs used to ensure the uniqueness of the keys generated in this way.The cryptographic block can thus output one or more session keys for each set of inputs that contains at least the shared key and a counter value. These session keys can be used to authenticate and / or encrypt the secured messages. Therefore, if symmetric encryption is implemented, the node receiving the secured message uses the same session key as the node that sent the secured message.

[0011] However, shared keys and session keys should not be transmitted unencrypted (i.e., in plaintext), as this poses a significant security risk because the pre-shared keys are exposed to potential attackers. To prevent the transmission of keys in plaintext, conventional communication protocols and E / E architectures use a system called key agreement. This process ensures that the nodes involved in secure communication agree to use the same session key (via a key agreement protocol) and that the nodes agree on a new session key when the key is exhausted or otherwise needs to be updated. Thus, a node that has been restarted and has forgotten all the details of previous keys cannot retransmit messages using an old session key.

[0012] Thus, a monotonically increasing sequence number is typically used to prevent the repetition of messages where the key has not changed; this can alternatively be referred to as the freshness value (FV). This is achieved via the current Ethernet standard protocol MKA (MACsec Key Agreement). However, this leads to problems when implemented as part of secure real-time control systems. In particular, the protocol execution takes too long, and a restarted node has to wait far too long for consensus to be reached on a new session key before the node can receive and send secure messages again (i.e., a large number of messages have to be exchanged between a group of nodes and a central key server).

[0013] For example, and now to the Fig. 1A and Fig. In 1B, blocks A, B, C, and D represent high-priority frames according to a key agreement communication protocol, such as MACsec. If communication is interrupted, for example, if a node is reset, the key messages must be transmitted from each node to other nodes in the system to ensure synchronization between all nodes in a group. Thus, the blocks at the bottom of Fig. 1A represents the key distribution messages when the secure messages have a lower priority. In this case, it is shown that no secure communication can take place between nodes B, C, and D until a new key message has been distributed to each of nodes B, C, and D. This increases the latency of the secure communication and is therefore undesirable for communication of lower-priority secure messages. This also leads to a problem for higher-priority communication, as shown in Fig. 1B shown. In particular, illustrated Fig. 1B. The introduction of latency results from the need to distribute the key messages to each of the communicating nodes A, B, C, and D. Therefore, conventional key agreement protocols are not suitable for nodes connected via a transmission bus for use in real-time control systems, as such latency can pose significant security risks.

[0014] The embodiments further described herein are designed to solve this problem by achieving key agreement without the exchange of separate key agreement messages, and consequently satisfy the stringent start-up time requirements for real-time control systems. This is achieved, as discussed in more detail below, by using a group-wide key counter, wherein each node stores in its non-volatile memory the last value of this counter observed across the most recently received secured message. This counter value increments monotonically, and the nodes maintain synchronization by transmitting this counter value (or a representation of the counter value) in each secured message.

[0015] The counter can alternatively be referred to here as the key counter, since it (along with a pre-shared key, also stored in non-volatile memory) is used by the cryptographic block to derive one or more session keys, as described above. Because different nodes in a communication group can use the same cryptographic function, the same key counter and the same shared key result in the same session key. Thus, when nodes synchronize to the same group-wide key counter, the nodes agree to use the same session key.

[0016] Here too, each secured message contains the key counter, or more precisely, a representation (e.g., a section of bits) of the key counter, to allow receiving nodes to determine the group-wide key counter value using their local copies, which are stored in non-volatile memory. This simplifies key agreement because the key counter rarely changes. Thus, including a section of the key counter, such as a predetermined lower number of truncated bits, is sufficient for each receiving node to verify that the counter value used by the sending node (and transmitted in the secured message) matches the key counter stored locally at the receiving node.And because the key counter representation is carried in every secured message, there is no need for any separate key agreement messages. In other words, the key agreement is implicitly included in every secured message, and therefore there is no delay from waiting for consensus between nodes, as is the case with traditional systems.

[0017] Additionally, the embodiments described herein can extend the use of key counters and pre-shared keys to protect against weak replay attacks by implementing a live membership tracking solution. This live membership tracking solution defines one or more membership groups, which may contain the total number of interconnected nodes within a system or a subset of such nodes. Once groups of nodes are defined, any node within a group can at any time request or "challenge" other nodes within the same group to check their online status. In other words, a challenging node in the group can request other nodes to respond to a challenge request.Such challenge requests can be made using a representation of a query value encoded in the secured message and can be contained in any field of the secured message. Advantageously, the representation of the query value can be a small field (e.g., a single bit), and thus the challenge requests can be easily added to secured messages intended for transmission during typical inter-node communications. For example, the representation of the query value can be added as a field or any suitable section to a secured message that is generated and transmitted during typical secured message communications between interconnected nodes in the same membership group. This has the advantage that challenge requests do not need to be transmitted as part of separate, dedicated messages.

[0018] The representation of the query value can be used by any node in the membership group to identify that an online status check has been requested by any node that issued such a challenge. Each node in the membership group can thus maintain a log of query values ​​(e.g., a bit sequence) corresponding to each node's challenge requests in local memory. In this way, each node in the membership group keeps track of every other node's challenge requests, correlated with each requesting node via a dedicated, predetermined bit position in the bit sequence for each node in the membership group. In response to such challenge requests, each node can transmit a secure message containing the answers (e.g.,(in a field or other part of the secured message), which encodes its currently locally stored bit sequence that identifies a currently locally stored log of a responding node of challenge query values ​​from all other nodes in the membership group. Thus, and similarly to how the query value is represented above, the encoded responses can also be relatively small (e.g., a single bit sequence) and added to the next secured message to be transmitted between nodes in a membership group. Therefore, responses to challenge requests do not require the use of separate, dedicated messages.As further detailed below, the use of challenge requests and responses as part of typical secure message communications advantageously enables improved security without adversely affecting message bandwidth.

[0019] Each node that has requested a challenge can thus verify whether a node is online by identifying whether an encoded value has been set in the secured message that corresponds to the predefined bit position of the requesting node. The encoded value at this bit position is then compared to a predefined value (e.g., "1") and assigned, via the reserved bit position, to the node that previously requested the challenge. The encoded value contained in this bit position therefore represents a positive response to the challenge. If this is not the case, the secured message may not be accepted because the online status check request was not acknowledged by the responding node.The use of membership groups and the ability to execute such challenge requests, in combination with the use of the counter values ​​and pre-shared keys discussed above, can be particularly useful, as this provides an additional layer of security to protect against weak retrigger attacks. This is the result of using the counter validation schemes discussed herein, which ensure that the bit sequence cannot be tampered with.

[0020] Furthermore, the embodiments described herein can utilize group tracking solutions to enable a message queue management system that can be implemented to facilitate Ethernet-based atomicity for real-time control systems. For example, nodes in an interconnected network can transmit messages in a queue according to an Ethernet PHY-level collision avoidance (PLCA) scheme. The queued messages can, for example, be assigned different priority levels according to a transmission scheduling system, which may be identified, for example, according to the IEEE 802.1Q and 802.1AS standards for time-sensitive networking (TSN).

[0021] As further detailed herein, each node can maintain multiple registers that are updated as messages are transmitted and received between the various nodes in the group. Transmitted messages can include an acknowledgment field containing a coded value indicating an acknowledgment from each node that received the message. Thus, nodes receiving a message respond by including a coded value in the acknowledgment field of the next message scheduled for transmission, thereby confirming that the node has received the message. A node can use the acknowledgments from one or more received messages in this way to verify which nodes have actually received a transmitted message.The node that transmitted the message can then delete it from its transmission queue only after verifying (using acknowledgments from the other nodes) that each of the other nodes in the group has received the message. Otherwise, if an acknowledgment from one or more of the intended recipient nodes is missing, a transmitting node can retain the message in the queue instead of deleting it. Due to the use of the PLCA scheme, the message held in the queue is then retransmitted according to the established transmission schedule. In this way, the use of atomic transmission can be extended to applications with Ethernet-based communication protocols, such as 10BASE-T1S and 10BASE-T1L. DETAILED DESCRIPTION

[0022] The following description sets forth numerous specific details to provide a thorough understanding of the aspects of this disclosure. However, it will be clear to those skilled in the art that the aspects, including structures, systems, and procedures, can be practiced even without these specific details. The description and presentation herein are the common means used by those who are experienced or knowledgeable in the field to most effectively communicate the content of their work to other skilled workers. In other examples, known procedures, processes, components, and circuits have not been described in detail so as not to make aspects of the disclosure unnecessarily unclear.

[0023] The embodiments herein are presented in separate sections for ease of explanation. Section I relates to the use of secure communications that utilize locally stored key counter values ​​according to a real-time bus key distribution system, eliminating the need for dedicated key agreement messages. Section II relates to the use of live membership groups to provide an additional layer of security. Section III focuses on an additional group tracking solution that enables a message queue management system, which can be implemented, for example, to facilitate Ethernet-based atomicity for real-time control systems.Although these embodiments are discussed separately, it should be noted that any of the embodiments described in Sections I, II, or III can be combined with one another, and that any of the architectures, communication protocols, and / or techniques described in one of the sections are also applicable to the embodiments described in the other sections. For example, any of the embodiments described herein with respect to Section I may optionally include the use of live membership tracking features, as described in Section II, as an additional layer of security to protect against weak replay attacks.As an additional example, each of the embodiments described herein with reference to Section III may optionally include the use of the real-time bus key distribution system described in Section I to ensure the secure transmission of messages in an interconnected network of nodes that may form part of a real-time control system. I. Secure communication using locally stored key counter values

[0024] As discussed in more detail below, the embodiments described herein can be implemented according to any suitable communication architecture that utilizes a transmission bus to facilitate secure communication between a system of interconnected nodes. The transmission bus can, for example, be implemented according to a so-called "multi-drop" scheme. In other words, although the embodiments described herein can function according to a point-to-point communication architecture, they may be particularly useful for use in a point-to-multipoint communication architecture.Furthermore, although not limited to use in real-time control systems, the embodiments described herein can be advantageously implemented as part of systems that have increased requirements for security, timing and robustness compared to conventional node-based communication networks.

[0025] For example, using a vehicle-based real-time control system as an example, the nodes in such systems can control safety-critical components like steering, braking, and acceleration. Consequently, it is crucial that secure messages are sent and received between these nodes with low latency, that nodes quickly return to the system after a reset, and that nodes within the system are not affected while waiting for reset nodes to come back online. Furthermore, due to heightened security requirements and to defend against reverse engineering attempts, a real-time control system must be resilient against malicious attacks that might attempt to gain unauthorized access to keys or other system information.

[0026] Such an attack includes, for example, so-called "repeat attacks," which can encompass "strong" and "weak" repeat attacks. The embodiments described in this section are primarily aimed at preventing strong repeat attacks, which cause secured messages to be resent to other nodes out of order. To prevent such attacks, conventional systems use a "freshness value" (FV) to prevent the same (legitimate) message from being sent repeatedly and forcing receivers to respond at an invalid time. These conventional systems, which incorporate the Controller Area Network (CAN) bus and multi-drop Ethernet communication protocols such as 10BASE-T1S and 10BASE-T1L, result in frames being transmitted out of order due to priority queues.Thus, such conventional systems have introduced an "acceptance window," which, although it still allows retrigger attacks, restricts such attacks to a specific window to limit this possibility. The primary drawback of such a system, however, is that the window can be relatively large (e.g., 1 second), which reduces the possibility of retrigger attacks but does not eliminate them entirely.

[0027] Other attacks include denial-of-service attacks using key agreement messages. As mentioned above, using conventional key agreement protocols requires a substantial number of such messages to be transmitted across the network, scaling quadratically with the number of nodes. It is therefore possible to exploit the use of such a large number of messages to maliciously trigger a key reunification process that disrupts bus traffic. Furthermore, such attacks can be used to trigger multiple key reunifications to completely halt secure data traffic.

[0028] Additional attacks involve the reuse of Secure Channel Indicator (SCI) values, the details of which are discussed further herein to break assumptions about nonce reuse. For example, a malware-infected node can use SCI values ​​assigned to another node and force the device to send messages that could reuse a nonce value, thereby implicitly revealing the session key. Furthermore, attacks can include denial-of-service attacks on a key agreement server, which can drive the server offline with a bus-off attack, preventing the server from issuing new keys.

[0029] The embodiments described herein address these problems in order to increase the robustness of real-time control systems against such attacks. To this end, the embodiments further described herein do not use key agreement messages and can instead operate independently of a key agreement server. Thus, instead of a centralized key agreement system, the embodiments described herein can maintain a locally stored copy of the counter values, which would conventionally be derived from a central server. Again, a representation of the counter value can be transmitted as part of each secured message, which can be used by a receiving node to validate the counter and verify the secured message. A. Node architecture

[0030] Fig. Figure 2A illustrates a node architecture according to one or more embodiments of the disclosure. The node 200 can be identified with any suitable component type and can represent a node in a system of interconnected nodes, wherein such a system is in Fig. Figure 3 illustrates and is discussed further below. For example, node 200 can be identified with a part of an electronic control unit (ECU), a sensor, an actuator, a host, etc. The various nodes in such an interconnected system may differ in type and / or function, although each node may share a common functionality, as discussed herein with respect to node 200. Thus, each node in the system of interconnected nodes may be configured to transmit and / or receive secure messages in the same manner as described herein with respect to node 200.

[0031] The 200th node, as it is called in Fig. Figure 2A can represent a node in the system of interconnected nodes designed to communicate over a bus according to a multi-connection scheme, as discussed herein. Such a multi-connection scheme may, for example, be part of an onboard E / E architecture, as discussed above, which may include a CAN bus architecture or another suitable onboard E / E architecture. The system of interconnected nodes can support the communication of secure messages according to any suitable system type, such as a real-time control system that may be implemented in a vehicle.Thus, node 200 can be one of any number of suitable nodes that communicate with each other by transmitting and receiving secure messages via data interface 210, which can be coupled to a bus and / or be part of a bus used as part of any suitable point-to-point or multi-point scheme. Data interface 210 can include any number and / or any type of data interface to facilitate the exchange of secure messages between node 200 and any number of other nodes within the system of interconnected nodes.

[0032] Node 200 can transmit and / or receive secure messages, as discussed herein, to communicate with other nodes within the system of interconnected nodes using any suitable number and / or type of communication protocols and accompanying operating modes. For example, Node 200 can be configured to receive and send secure messages according to communication protocols using Authenticated-Encryption Galois / Counter Mode (AES-GCM), Counter with CBC-MAC Modes (CCM), communication protocols using operating modes implementing the ShangMi 4 (SM4) cipher, any suitable type of Ethernet communication protocol (e.g., multidrop Ethernet communication protocols such as 10BASE-T1S, 10BASE-T1L, the Ethernet MACsec standard, etc.).), all suitable onboard network protocols such as a Controller Area Network (CAN) communication protocol, a Controller Area Network Flexible Data-Rate (CAN FD) communication protocol, a Controller Area Network Extra Long (CAN XL) communication protocol, all suitable communication protocols that implement operating modes with authenticated encryption with associated data (AEAD), etc.

[0033] Here too, node 200 (like every other node in the interconnected system) is designed to transmit secure messages to other nodes and to receive secure messages transmitted by other nodes via data interface 210. Thus, although every node in the interconnected system of nodes (which in turn contains node 200) is designed to perform both transmission and reception functions, the term "transmission node" is used herein when referring to a node that is currently transmitting a secure message and / or performing functions related to such secure message transmissions, while the term "receiving node" is used herein when referring to a node that is currently receiving a secure message and / or performing functions related to such secure message receptions.

[0034] To perform secure message communications, node 200 includes a session key generator 202, a non-volatile memory 204, a volatile memory 206, and a secure message handler 208. These components are in Fig. 2A is illustrated as separate units, with their respective functions described separately for ease of explanation. However, each of the components of node 200 can be integrated or otherwise combined. Node 200 may also include additional or alternative components, as described herein in relation to Fig. Figure 2A shows and discusses the following. Furthermore, while node 200 is shown and described herein in relation to the use of non-volatile memory 204 and volatile memory 206, this is only an example and not a limitation. Any of the data stored in non-volatile memory 204 and volatile memory 206 may additionally or alternatively be stored in other memories, which may be part of node 200 or components external to node 200. For example, any of the data illustrated in the figures as being stored in volatile memory may alternatively be stored in non-volatile memory, and vice versa. However, it is known that certain types of static data, such as secret keys, may be advantageously stored in non-volatile memory to ensure their security.Furthermore, it may be of interest to ensure the persistence of static data, such as secret keys, in the event that a node goes offline and returns to the bus, as can happen when a node is restarted.

[0035] Furthermore, node 200 is shown and discussed herein in relation to the execution of the functions of both secure message transmission and secure message reception, although it is understood that node 200 may comprise separate components to perform each respective function, or alternatively, a combination of such components to selectively implement both functions independently. Thus, the secure message handler 208 may represent an encoder, a decoder, or a combination of both an encoder and a decoder to facilitate node 200 operating according to each of the aforementioned modes of operation.

[0036] The Secure Message Handler 208 can comprise any suitable number and / or any suitable type of components, an example of such components being given in Fig. Figure 2A is shown as an example and is not limited to this. For example, the secure message handler 208 may include a communication circuit 208.1, which may be coupled to the data interface 210 and thus to the associated bus of the system of interconnected nodes, as discussed herein. Thus, the data interface 210 may include any suitable implementation of components for this purpose, such as wires, buses, and / or respective terminals, ports, pins, etc. The communication circuit 208.1 may be implemented as any suitable hardware component that enables communication between the node 200 and other nodes within the system of interconnected nodes, as further discussed herein, via the data interface 210. Thus, the communication circuit 208.1. Send secure messages to and from data interface 210 according to any suitable number and / or type of communication protocols, such as those discussed herein. For this purpose, the communication circuit 208.1 may include hardware components, software components, or combinations thereof, typically associated with components designed to perform data communications. For example, the communication circuit 208.1 may include any suitable number of connectors, drivers, transmit and / or receive buffers, switches, etc.

[0037] The processing circuit 208.2 can comprise any suitable number and / or any suitable type of dedicated hardware components, such as a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), dedicated logic, and / or other circuitry, etc. The processing circuit 208.2 can be implemented as one or more processors and / or cores capable of executing computer-readable instructions stored in the program memory 208.3 to perform one of the various functions discussed in more detail herein. Although the processing circuit 208.2 in Fig. Since 2A is illustrated as a unit separate from the session key generator 202, it is therefore to be understood that the processing circuit 208.2 can facilitate the operation of the session key generator 202 as further discussed herein, and thus the session key generator 202 and the processing circuit 208.2 comprise the same component(s) in some embodiments.

[0038] The program memory 208.3 can comprise any suitable type of non-volatile, computer-readable medium, such as volatile memory, non-volatile memory, or combinations thereof. To the extent that the Node 200 implements software-based solutions to perform the various functions discussed herein, this can be achieved, for example, via the processor circuit 208.2, which executes instructions stored in the program memory 208.3. B. Safe zones

[0039] Here too, node 200 can represent one of several nodes that form a system of interconnected nodes. Fig. Figure 3 illustrates an example of such a system of interconnected nodes, comprising a total of X nodes. Node 200 can be connected to any of the nodes N1-N1. X be identified, and each of the nodes N1-N X can transmit and receive secured messages in a similar manner to Node 200, as discussed herein.

[0040] The system of interconnected nodes 300 (hereinafter also referred to simply as System 300) can contain any number of suitable safety zones (SZ), of which for the sake of simplicity are referred to as Fig. Figure 3 shows three secure zones, represented as SZ-A, SZ-B, and SZ-C. These secure zones can be defined according to any of the communication protocols discussed herein, and nodes with System 300 can identify the intended recipients of secure messages transmitted and received within these secure zones using a Secure Channel Indicator (SCI) field, as further explained below.

[0041] With continued reference to Fig. Each of the safe zones in turn comprises a respective group of nodes. For example, the safe zone SZ-A of the system comprises 300, as shown in Fig. Figure 3 shows nodes N1, N2, and N3. Safe zone SZ-B includes nodes N3 and N4, and safe zone SZ-C includes nodes N3 and N4. XThe embodiments discussed herein can implement the transmission and reception of a secure message within a defined secure zone, within which the transmission node and the intended recipients of the secure message form a part. However, the embodiments are not limited to use with a system that includes such secure zones and can be implemented as part of any suitable communication system, i.e., with or without the use of secure zones. C. Key generation and management

[0042] To enable the use of secure messages, node 200, as well as every other node in system 300, stores a set of shared keys based on secure zones when secure zones are used. In other words, each node in system 300 stores a shared key, which can alternatively be called a secret key or shared secret, in non-volatile (NVM) storage. Fig. 2A illustrates this using node 200, which includes a non-volatile memory 204 designed to store a common key for each secure zone of which node 200 is a member within system 300. Thus, node 200 can be identified with node N3, as shown in Fig. Figure 3 is shown for clarity, since node N3 is a member of each of the secure zones SZ-A, SZ-B, and SZ-C. Thus, in this case, node 200 stores three shared keys A, B, and C in the non-volatile memory 204. Of course, node 200 can store additional or fewer shared keys, depending on the number of secure zones to which node 200 belongs. Therefore, in one embodiment, each node is designed to store any suitable number M of shared keys in its non-volatile memory, where M is greater than or equal to the number of secure zones to which the node belongs. For example, node 200 can store one shared key per secure zone, as shown in Figure 3. Fig. 2A is shown, although this is only an example and not a limitation, since node 200 can store any suitable number of shared keys per secure zone.

[0043] Thus, the NVM 204 can be implemented as any suitable type of non-volatile memory that is large enough to store a suitable number of shared keys. Each of the shared keys can represent a predetermined bit sequence or another suitable coded numeric value of a suitable length. Each node within the same secure zone therefore stores the same shared key in its respective NVM, which is used for transmitting and receiving secure messages for that secure zone, but not for other secure zones. For example, nodes N1 and N2 can only store shared key A for secure zone A, while node N2 can only store shared key B for secure zone B.The secret key is generally static and does not change during the operating lifetime of a node. It can therefore be flashed, written, stored, etc., as part of an initial manufacturing process. Alternatively, the shared keys can be written to the NVM 204 via node 200 or another suitable device. To ensure security, the shared keys are not included in the secure messages communicated between nodes and are only accessible to each node via its respective NVM or otherwise known, and thus unknown to other nodes in the System 300.

[0044] In any case, the "permanent" shared keys are used to facilitate the generation of temporary session keys, which can simply be referred to here as session keys and are used to send and receive secure messages within the same secure zones. To this end, we will now refer to... Fig. Reference is made to section 2B, which provides additional details regarding the session key generator 202, as described in Fig. Figure 2A shows that the session keys are generated using a key derivation function (KDF), which is a specific cryptographic function according to the particular communication protocol implemented by node 200. The use of KDFs is generally known, and therefore, for the sake of brevity, further details regarding the KDF operation are not described here.

[0045] Like the shared keys, the session keys can represent a bit sequence or other suitable coded numeric value of any appropriate length. In any case, once generated, the 208.2 processing circuit can use a separate session key for each security zone to create each secure message transmitted to other nodes within the same security zone, and also use the same session key to authenticate and / or decrypt secure messages received from nodes within the same security zone. Thus, the 208.2 processing circuit can execute any suitable type of cryptographic function that uses the generated session keys as cryptographic keys to create the secure messages.

[0046] Additionally, it can be particularly advantageous to implement one session key for authentication purposes and a second for encryption purposes on a single node, since some cryptographic functions require different keys for authentication and encryption. It is further noted that in some alternative implementations, an individual session key can be assigned to each node participating in a secure zone. In such a scenario, the key derivation function (KDF) can be performed (i.e., transmitted and / or received) for each secured message. This can be done without disadvantage, especially when the KDF is executed via hardware.

[0047] It is noted that the Session Key Generator 202 can implement any suitable type of KDF to generate any suitable number of session keys from each respective common key. That is, the Session Key Generator 202 is designed to generate a respective temporary session key for each of the secure zones using a respective common key and a respective key counter value according to a respective cryptographic function. Furthermore, each group of nodes within a secure zone for transmitting a secure message, as discussed further herein, comprises a plurality of fields, one of which includes a representation of the respective counter value used to generate the session key used to create the secure message.Further details regarding the content and format of the secured messages are discussed below.

[0048] The 208.1 communication circuit is also designed to transmit secure messages to each group of nodes according to the secure zone to which each receiving node belongs. Therefore, although multiple session keys can be generated from a single common key, the same session keys are used to conduct secure communications to and from nodes within the same secure zone at any given time. Thus, for communication with nodes within each secure zone, the KDF receives as inputs the common key for that secure zone and a counter value. Each KDF can also receive additional inputs, as shown in Fig. Figure 2B shows that any suitable values ​​can be selected to ensure that the generated session keys are unique for each secured zone. For example, the additional inputs to the KDF can include an SCI value, a nonce (a number used only once), and so on. As a result, the same common key can be used to generate multiple session keys per zone by modifying a different input to the KDF in each case.

[0049] In any case, it is important to note that the same KDF algorithm repeatedly generates the same session key from the same inputs. Thus, as further detailed below, other nodes can be configured with the same KDFs and shared keys to authenticate and / or decrypt secured messages using their own session keys and inputs, which should then match the session keys used when the secured message was generated by the sending node (i.e., before it was received by the receiving node).

[0050] Although the session keys are described herein as being used to transmit secure messages to all other receiving nodes per secure zone, this is for illustrative purposes only. In particular, the session keys described herein can be implemented to generate secure messages that can be authentication-only messages or, alternatively, both authentication- and encryption-related messages. For example, for the various AES-GCM-based protocols (used in MACsec), an integrity check value (ICV) is calculated according to their respective algorithms. For authenticated-only secure messages, the ICV is calculated without the encrypted data, and for authenticated and encrypted secure messages, the ICV is calculated alongside the encrypted data.Messages used solely for authentication can be particularly useful in scenarios where a message must first be read to quickly perform a specific control action or execute a command without first decrypting the payload of the secured message. The embodiments discussed herein can implement any suitable algorithm for computing the ICVs, including well-known techniques. In accordance with these cryptographic functions used to generate the ICV, the inputs typically include a key (e.g., the session key), a counter value (e.g., the key counter value), the plaintext of the message (if present), and a current freshness value (FV) carried in the secured message.

[0051] In any case, the ICV can be generated based on the specific cryptographic algorithm used to compute the ICV, using either the same key as the key used for encrypting data (i.e., the encrypted payload) or a different key. In both cases, the keys used to generate the ICV information and for data encryption can include the sending node's locally stored session keys, which in turn can, in various embodiments, include the same session keys or different session keys identified by the key counter(s) for a particular secure zone.For authentication purposes, a sending node can use its locally stored session key to calculate the ICV, while for authenticated and encrypted secured messages, the sending node can use its locally stored session key (or keys) to calculate the ICV and the encrypted payload. For both types of secured messages, the ICV is verified via the receiving node to authenticate the secured message, as discussed further herein.

[0052] Thus, embodiments include any suitable number of session keys generated from the same common key and KDF, using a different key counter value (or other different inputs) to generate each distinct session key in this way. Alternatively, the session key generator 202 can generate any suitable number of distinct session keys per secured zone using the same inputs and KDF, but a different common key, to generate each distinct session key in this way.

[0053] To give an illustrative example, the session key generator 202 can be designed to generate two separate temporary session keys from each stored common key, according to the same cryptographic function. Thus, the same key counter value can be used to generate different session keys from the same common key by varying other inputs to the KDF. Continuing this example, the first of these temporary session keys can enable a receiving node to decrypt the secured message, while the second can enable a receiving node to authenticate the secured message.In other words, the nodes within each secure zone can operate according to a predetermined scheme such that specific session keys are used for authentication, encryption, or both authentication and encryption of secured messages.

[0054] Again, a variable relating to the generation of different session keys from the same common key is the key counter value, which can also be referred to herein as the counter value. Thus, each receiving node must ensure that its session key was generated with the same key counter value as the sending node, otherwise the receiving node cannot authenticate and / or decrypt the secured message. In this way, the embodiments described herein advantageously allow nodes to synchronize their key counter values, and therefore their session keys, without the use of key messages.

[0055] Therefore, it is useful to now provide additional details on the conventional use of key counter values. It should be noted that conventional systems use a centralized server, control plane, host, etc., to manage a global counter value, which, as discussed above, must be transmitted to the nodes as part of the key agreement messages. However, the embodiments of the present disclosure recognize that, alternatively, the session keys can be managed and derived locally, thus eliminating the need for communication with a centralized entity for key agreement.

[0056] For this purpose, each node in the System 300 can contain any number of suitable counters, each counter being associated with a common key, as in Fig. Figure 2B shows that the counters can be implemented as any suitable hardware components, software components, or combinations thereof, enabling the generation of unique counter values ​​that can be represented as any number of suitable bits. For example, each counter can be implemented to generate a monotonically increasing counter value that is incremented in response to one or more predefined conditions being met, which may be the result of a "rekeying" event. Such a rekeying event may occur, for example, in response to any suitable number of conditions, which may be voluntary or triggered by a security alert. For instance, a node may perform a rekeying when a number of secured messages with a respective session key is transmitted that exceeds a predetermined number of messages (i.e.,"Session key exhaustion"), when a predetermined time period has elapsed, at every system startup, etc. To give another example, the rekey conditions can include a security alert that can be detected by a centralized server, another node, a host processor, etc. The security alert can be sent to node 200 via data interface 210 or another suitable data interface, explicitly instructing node 200 to perform a rekey process.

[0057] Thus, the processing circuit 208.2 of node 200 can periodically perform a re-keying process according to the various conditions discussed above. In one embodiment, the processing circuit 208.2 can implement a rate limiter designed to restrict the number of re-keying operations within a given period. This can, for example, include a prioritization-based system that can be implemented via node 200. Such a system can, for example, incorporate watchdog reset loops and include storing one or more priority markers in the NVM 204, the presence of which overrides the triggering of the re-keying process. For example, the non-volatile memory can store such a marker that is indicative of an event which, if present, overrides the re-keying process. Thus, the processing circuit 208.2. While the priority marker is stored in NVM 204, no rekey operation is performed, even if one of the aforementioned conditions is met. The priority marker can be cleared after a predetermined time period, after the event has ended, etc., so that the key counter is not incremented while the priority marker is set.

[0058] In some embodiments, the processing circuit 208.2 (e.g., via the execution of instructions stored in the program memory 208.3) can implement a stable memory algorithm, alternatively called an atomic memory algorithm, to perform the recoding process. Stable memory is a classification of computer data storage technology that guarantees atomicity for each given write operation and enables the creation of software that is robust against some hardware and power failures. To be considered atomic, a memory subsystem, when rereading a section of the disk that has just been written to, should return either the written data or the data that was on that section of the disk before the write operations. Stable memory algorithms generally aim to eliminate corrupted data in memory.For this purpose, the data is stored multiple times or with an error correction code, ensuring that the most recent, undamaged value can always be read. Using such a robust storage algorithm can be particularly useful in preventing a power outage or malfunction during the increment process from resulting in a corrupted key counter value.

[0059] In such a case, the session key generator 202 stores the updated (i.e., incremented) key counter value in non-volatile memory, for example, by overwriting the previous key counter value for that shared key with a new key counter value. The session key generator 202 also creates an updated temporary session key from the respective shared key and the incremented key counter value according to the KDF, as shown in Fig. Figure 2B shows that session keys are generated via the KDF from the shared keys and the current key counter values ​​(as well as other inputs), with both the shared keys and the counter key values ​​stored in NVM 204. Since rekeying events can be security zone-specific, this is addressed in Figure 2B. Fig. 2A is illustrated by the fact that the key counter for security zone B is incremented, while the key counter values ​​for security zones A and C are not incremented.

[0060] For example, and how in Fig. As shown in Figure 2A, the NVM 204 can store any suitable number of key counter values ​​correlated with each of the stored shared keys. In this way, the NVM 204 stores a separate shared key and key counter value for each of the secure zones. That is, the key counter values ​​can differ between the various secure zones, although the value of each key counter can be synchronized between the nodes within each secure zone, as discussed further herein.

[0061] A representation of this key counter value can be included in any secured message in unencrypted form, i.e., "in plaintext." Therefore, as discussed in more detail below, each receiving node can verify the validity of the key counter value by comparing the key counter value representation in the received secured message with the receiving node's locally stored key counter value. Since each node in the system can store 300 key counter values ​​in this way, a receiving node can determine whether a counter value calculated from the counter value representation contained in the secured message matches the locally stored counter value.

[0062] If not, the receiving node can increment and overwrite its locally stored key counter value to match the counter value used to generate the session key and the secured message, until the secured message has been verified as discussed in detail below. That is, before updating the locally stored key counter value in this way, the receiving node can validate the key counter value represented in the secured message by generating a session key (via its session key generator) from the calculated counter value (i.e., the counter value representation sent in the secured message). This temporary session key is then used at the receiving node to verify a corresponding Integrity Check Value (ICV) included in the secured message.In other words, representing the counter value in the secured message allows a receiving node to derive a temporary session key, which is used to validate the counter value used by the sending node to generate the session key used to create the secured message. This process is described in more detail below.

[0063] Here too, the session keys generated by the session key generator at any given time are considered temporary and can be changed when the key counter values ​​are incremented, as described above. Thus, the volatile memory 206 is designed to store each of the session keys generated by the session key generator 202. The temporary session keys can be overwritten or deleted when updated session keys are generated (e.g., when the counter value is incremented), as discussed above.

[0064] The secured messages can also be transmitted using a sequence number representation. In some embodiments, the sequence number may include a freshness value (FV), such as the freshness value defined according to one of the communication protocols described herein. Although referred to herein as freshness values, sequence numbers are not limited to freshness values ​​as defined in any particular communication protocol or standard and may include a bit sequence or other suitable coded numeric value of any appropriate length, which can be used to enhance security by preventing a re-attack.

[0065] Thus, the freshness value is also a changing, temporary value, and therefore the volatile memory 206 can also store the most recent freshness value for each transmission node, which is correlated with each session key (and in turn the key counter value), as in Fig. Figure 2A shows that, as a security measure, the processing circuit 208.2 can increment the freshness value after each transmitted secure message and after each received secure message. That is, the freshness value can have an initial, predetermined value (e.g., 1) that is incremented by a transmit node when each secure message is transmitted, and also by a receive node when each secure message is received.

[0066] It should be noted that the secure messages may arrive at a receiving node out of order; that is, the buffering scheme used by a transmitting node typically sends a higher-priority message before a lower-priority message. Thus, conventional systems typically accept out-of-order messages but use a "window" so that replayed messages must be relatively recent, in the hope that this provides sufficient protection against such attacks. Furthermore, conventional systems use multiple sequence numbers at each transmitting node (one for each secure channel), and the transmitting node then ensures that within each of its secure channels, the sequence numbers are transmitted in the correct order.

[0067] Due to the use of key counter values ​​as described herein, the embodiments discussed here extend this conventional use of freshness values ​​in several ways. First, each receiving node stores a log of previously received freshness values ​​contained in previously received and accepted secure messages, correlated with each sending node, secure zone, and current key counter value. The number of logged freshness values ​​stored in this way can be any suitable number, depending on the specific application.

[0068] Additional details regarding the protocol of received freshness values ​​are in Fig. Figure 2C illustrates that each key counter value is correlated with its previously received freshness value numbers for each sending node and per secure zone. Thus, the received FV protocol comprises 208.1, as shown in Fig. Figure 2C shows a set of logged freshness values ​​per node, since each node in this example is part of only one secure zone. However, this is just an example and not a limitation, and the received FV protocol 208.1 can store any suitable number of freshness values ​​for each transmitting node, based on the number of secure zones each node is a member of. For example, if node N4 was also part of secure zone A, the received FV protocol 208.1 would also store a log of the freshness values ​​received by node N4 via secure zone A (not shown).

[0069] Thus, the receiving node uses the freshness value in each received secured message to determine whether a current secured message has already been received from a specific sending node. To do this, the receiving node references the stored set of logged freshness values ​​for that particular sending node, which can be identified by the transmitted SCI value, as discussed below. If a newly received secured message does not have a freshness value greater than the last recorded freshness value, the secured message is discarded as a repetition. It is important to note that the first received secured message is always accepted by the receiving node, i.e., before the history of previously received freshness values ​​is available.

[0070] Second, when the local key counter value is changed (i.e., during a rekeying process where the key counter value is incremented), the transmitting node resets the freshness value (for the specific secure zone for which the key counter was reset) to an initial, predetermined value (e.g., 1). The receiving node is designed to recognize the initial freshness value in a secured message received after such an event. Thus, after a rekeying event, the receiving node can continue to store any predetermined number of the most recently received freshness values ​​for previously used key counter values, ensuring that older secured messages still in the priority queues (and therefore with old counter values) are still validated even if the receiving node is already using a new key counter value.Alternatively, freshness values ​​stored in this way can be deleted after a predetermined period of time has elapsed since the use of a new key counter value. This allows a receiving node to continue receiving and accepting secure messages even after a re-encryption, and it will accept the first message transmitted after the re-encryption.

[0071] Freshness values ​​can serve different purposes for the sending and receiving nodes. For example, a sending node can compare the incremented freshness value after sending a secure message with a predetermined freshness threshold to determine whether a threshold number of secure messages has been sent, thus triggering the rekeying process as described above. Since the sending node generates and stores a different session key for each secure channel, for instance, it can use the freshness value to count messages using the session key—that is, the number of secure messages transmitted per session key.When the freshness value for a particular secure zone reaches a predetermined threshold, the sending node can increment the key counter as part of a rekeying process as described above.

[0072] Thus, the predetermined threshold can be a value per node or a value that represents a sum over any suitable number of nodes, such as those within the same secure zone. In other words, if the same session key is used in all other transmission nodes in the same secure zone, a quota can be set for this threshold such that the quota for all nodes in the secure zone is less than one session key exhaustion counter (i.e., the predetermined threshold).

[0073] In one embodiment, the exhaustion counter can be implemented in the KDF used to generate session keys, using the transmission node ID (or SCI), so that each transmission node has unique session keys. In this case, a transmission node's exhaustion count can be identified using its own session key, reducing the number of rekey generation processes because the quota is not shared between multiple nodes.

[0074] Thus, the KDF implemented by the session key generator 202 can optionally be used as part of the additional inputs, as in Fig. Figure 2B shows that a secure channel identifier (SCI) is received, which is unique across the entire system. The concept of a secure channel and carrying a secure channel identifier is part of the Ethernet MACsec standard, as well as other communication standards, and is discussed further below. D. Secure message format and communication protocol

[0075] Fig. 4A illustrates a secure message format and an associated processing schedule according to one or more embodiments of the disclosure. The secure message, as shown in Fig. As shown in Figure 4A, the communication protocol can be transmitted according to any suitable communication protocol and can form a communication protocol frame 400 comprising any number of suitable fields. Again, the communication protocol, and thus the associated communication protocol frame 400, can be, as in Fig. As shown in Figure 4A, the communication protocol frame 400 can be identified with any suitable type of communication protocol that can be implemented to facilitate the communication of secure messages over a multipoint bus architecture. For example, the communication protocol frame 400 can be identified with a CAN communication protocol frame, a CAN FD communication protocol frame, a CAN XL communication protocol frame, an Ethernet communication protocol frame (e.g., multidrop Ethernet such as 10BASE-T1S, 10BASE-T1L), etc.

[0076] In any case, the Communication Protocol Frame 400 can be identified by a secure message generated by a sending node using a temporary session key for a specific security zone, as discussed herein with respect to node 200. The Communication Protocol Frame 400 may contain additional, fewer, or alternative fields, as described in Fig. Figure 4A shows this. For example, the communication protocol frame 400 includes a header 402, a SCI 404, a representation of the counter value (CNT) 406 used to generate the secured message, a freshness value 408, a payload 410, an ICV 412, and an end-of-frame identifier (EOF) 414. The communication protocol frame 400 can then be received by a receiving node as a secured message, which is either accepted or rejected, as discussed below.

[0077] A secure channel within a secure zone comprises a single writer and multiple readers, thus identifying a secure zone that includes nodes within the system of interconnected nodes designated as receivers of a secure message. A Secure Communication Identity (SCI) value can be identified via various communication protocols, such as the CAN XL communication protocol and the Ethernet MACsec standard. For example, according to the MACsec standard, the secure zone is defined by the shared key, and this SCI is used to identify a transmitting node. For instance, the SCI can be used as one of the inputs to the Key Distribution Function (KDF) to generate unique session keys for each sender.

[0078] Each secure channel is thus identified with a respective SCI and is unique within the physical and logical network. Therefore, the secure zones are SZ-A, SZ-B, and SZ-C, as shown in Fig. Figure 3 shows each of the following, defined by a separate and unique SCI. The processing circuit 208.2 of node 200 is designed to generate the secured message, which includes an SCI value indicating which of the secure zones the secured message is intended for; that is, the SCI identifies the secure channel and thus the receivers within the secure zone to which the message is sent. It is assumed that the communication protocol frame 400 is received by a receiving node located in the same secure zone as the transmitting node, which is again specified by the SCI value. Another use of the SCI is to avoid the windowing problem for out-of-order freshness values.This means that different SCIs can be used for different priorities, ensuring they are in the correct order within the same SCI (and therefore the FV is attached to an SCI and not a transmission node). The SCI can also be used at the application level to identify a subset of receiving nodes within a secure zone.

[0079] The representation of counter value 406 (also referred to herein as CNT 406) can include the entire key counter value used by the transmission node to generate the session key, or alternatively, a truncated portion of the key counter value. For example, CNT 406 can include a predetermined number of lower-order bits (e.g., 4, 6, 8, etc.) of the full-length key counter value that CNT 406 represents.

[0080] Thus, a receiving node (e.g., the processing circuit 208.2) can determine whether its local key counter value, stored in the NVM 204, matches the CNT 406 by comparing either the entire stored key counter value for the secure zone, as specified by the SCI, or alternatively, the truncated portion of the CNT 406. Comparing only the truncated lower significant bits of the counter value in this way is sufficient because the key counter value does not change frequently, e.g., only in response to the rekeying conditions, as specified herein.

[0081] Continuing this example, if the receiving node's locally stored key counter value is determined to be consistent with the key counter value derived from CNT 406, it can leave its locally stored key counter value unchanged, determine that the key counter value represented by CNT 406 is valid, and accept the secure message. Additionally or alternatively, if the receiving node's locally stored key counter value is determined to be consistent with the value derived from CNT 406, the receiving node can determine that the key counter value represented by CNT 406 is "provisionally" valid, i.e., subject to further verification processes.

[0082] For example, the receiving node's processing circuit 208.2 can be designed to validate the key counter value represented by the CNT 406 by verifying the secured message in various ways. Thus, upon verification of the message, the key counter value derived from the CNT 406 is determined to be valid, and the secured message is accepted. The verification might, for example, involve the receiving node calculating a session key from the key counter value derived from the CNT 406.Therefore, the session key generated in this way should match the session key used by the sending node to generate the secured message, and should also match the session key stored locally at the receiving node if the key counter value derived from CNT 406 matches the locally stored key counter value of the receiving node. Thus, the receiving node can verify the message using the session key generated from the key counter value derived from CNT 406, which is used to decrypt the contents of the secured message in order to derive and verify an ICV, as discussed in more detail below.

[0083] However, if the locally stored key counter value of the receiving node is smaller than the key counter value derived from CNT 406, this means that the locally stored key counter value is outdated, and the receiving node performs a rekeying process to update the locally stored key counter value by overwriting the current key counter value with a new key counter value that corresponds to the key counter value represented by CNT 406.Additionally, for the session keys assigned to the current secure zone (as specified via the SCI), the receiving node, after verifying the validity of the counter value via the ICV validation process described above, generates an updated session key from the updated key counter value and overwrites its previously stored session key with the updated one, which should now match the session key used by the sending node to generate the secure message.

[0084] In other words, the receiving node's processing circuit 208.2 is designed to update the locally stored key counter value to match the calculated key counter value derived from CNT 406 when the locally stored key counter value is less than the calculated key counter value, but not to update the locally stored key counter value if the two key counter values ​​already match. Thus, and as discussed below, validating the key counter value represented by CNT 406 can involve verifying the secured message based on processing one or more fields of the secured message.This may involve, for example, either using a currently stored session key or generating an updated session key from the relevant shared key stored in the non-volatile memory of the receiving node, as applicable, and then using the session key (or the updated session key, as applicable) for secure message verification, as further discussed in detail below.

[0085] Furthermore, if the locally stored key counter value of the receiving node is determined to be greater than that derived from CNT 406, the receiving node can retain its locally stored key counter value unchanged, conditionally determine that the key counter value represented by CNT 406 is invalid, and conditionally reject the secured message. Thus, the receiving node's processing circuit 208.2 is designed to determine that the key counter value represented by CNT 406 is invalid and conditionally reject the secured message if the key counter value calculated from CNT 406 is less than the locally stored key counter value, as this is indicative of a retry attack, an outdated message, or a corrupted message.

[0086] The conditional rejection of the key counter value is discussed below and may, for example, include a further determination as to whether the key counter value derived from the CNT 406 in the secured message is nevertheless within a predetermined timeframe, which may alternatively be referred to herein as the "grace period." In some embodiments, this grace period may represent a predetermined time interval (e.g., 500 ms, 1 second, etc.) such that older key counter values ​​are accepted within the grace period. Thus, the grace period may represent the age of the derived key counter value since the receipt of the last (different) key counter. Additionally or alternatively, the grace period may be determined based on a number of freshness values ​​associated with the derived key counter value.In this way, communication is not interrupted for a certain period after a rekeying event occurs. However, after this grace period, messages with old derived key counter values ​​can be rejected, thus reducing the risk of retrigger attacks.

[0087] Thus, the receiving node accepts or rejects the secured message in each case based on the specific validity of the key counter value, which is calculated from CNT 406. Again, the secured message verification process implemented by the receiving node can use additional techniques to perform key counter value validation in order to determine whether the message should be accepted. For example, the secured message might contain a sequence number field that is included in the Fig. 4A and Fig. Figure 4B shows the freshness value (FV) as 408. The freshness value may also be included in unencrypted form as part of the secured message, as discussed further herein. The representation of the freshness value, which may alternatively be referred to herein as FV 408, may include the entire freshness value used (and stored) by the transmitting node when the secured message is generated, or alternatively, a truncated portion of the freshness value, such as a predetermined set of less significant bits. Thus, as an additional layer of security, a receiving node can verify that the freshness value in a received secured message matches the freshness value stored in the receiving node's volatile memory (i.e., after the FV has been incremented upon receiving the secured message).If this is not the case, the message may be discarded, as the secured message could be part of a retrigger attack and / or the secured message was sent out of order. Further details on the use of freshness values ​​are provided below in relation to the [relevant section / document]. Fig. 7A and Fig. 7B discussed.

[0088] Payload 410 can be encrypted via the sending node's 2080.2 processing circuit using the session key. This encryption process can be performed according to any suitable cryptographic function, including well-known cryptographic functions. Again, the secured messages discussed herein can, in various scenarios, consist of either authentication messages only or authenticated and encrypted messages. Payload 410 can thus consist of either plaintext, which is part of a pure authentication message (or can be omitted), or alternatively, data encrypted via the sending node, i.e., ciphertext.

[0089] Furthermore, the Communication Protocol Frame 400 includes a field containing an ICV 412, which is generated by the sending node's processing circuit 208.2. The ICV can be computed according to any suitable techniques, including well-known techniques defined according to any of the communication standards discussed herein. For example, the ICV can comprise a bit sequence of a predetermined length, computed by the processing circuit 208.2 based on a suitable cryptographic function, such as a cyclic redundancy check (CRC) or a hash-based message authentication code (HMAC). The ICV can thus be computed by executing a suitable cryptographic function, as described above, using the current key counter value and / or the plaintext of the payload 410 as inputs.The ICV can include data that represents a dedicated field, or data that represents a combination of data from other fields of the secured message 400, such as in . Fig. 4A shown. For example, the ICV can include any suitable combination of the header 402 (including a security tag), the full key counter value represented by CNT 406, the plaintext payload 410 or the ciphertext payload 410, etc.

[0090] The ICV 412 can be transmitted in plaintext as part of the secured message, although the payload 410 must first be decrypted by the receiving node in order to calculate and verify the ICV using the same cryptographic function that the transmitting node used to generate the ICV 412. For this purpose, the receiving node can calculate the session key (for that particular security zone) using the locally stored key counter value, which corresponds to the calculated key counter value derived from the CNT 406. These key counter values ​​(either initial or during re-encryption) should also match if the key counter value derived from the CNT 406 is valid.In other words, and as mentioned above, the stored key counter value of the receiver node may already match the one used by the sending node, or it may be updated to match the one used by the sending node by the receiver node performing a rekeying process to update its key counter value, depending on the case.

[0091] In any case, once the receiving node generates a temporary session key from the key counter value calculated from CNT 406, this should match the session key used by the sending node to generate the secured message before it was received at the receiving node. This generated session key should also match the locally stored session key at the receiving node, provided that the key counter value used by the sending node to generate the secured message is the same as the one stored locally at the receiving node. That is, since the same KDF, the same key counter value, and the same shared key are used by both the sending and receiving nodes, identical session keys will be generated in each case.The receiving node can then use the generated temporary session key to decrypt the payload 410 and utilize the same cryptographic function used by the transmitting node to calculate the ICV. The receiving node can then compare the ICV calculated in this way with the ICV 412 to determine whether the calculated key counter value derived from the CNT 406 is valid. If the ICVs match, the receiving node can verify the secured message and accept it. If the ICVs do not match, the receiving node can reject the message because the secured message is not verified and therefore the key counter value is not validated.

[0092] Fig. Figure 4B illustrates another secured message format and an associated processing timeline according to one or more embodiments of the disclosure. The secured message format, as described in Fig. As shown in 4B, the message format and fields are identical to those in Fig. 4A shown. Thus, each of the fields 452, 454, 456, 458, 460, 462 and 464 can be identified with the same analogous fields 402, 404, 406, 408, 410, 412 and 414 of the secured message, as shown in Fig. 4A shown. The secure message format, as shown in Fig. 4B is shown, but can be identified with a subsequent secured message sent by the receiving node, as discussed above, after receiving the secured message, as shown in Fig. 4A is shown, and the transmission occurs. Thus, after receiving and accepting the secured message, the receiving node can, as shown in Fig. 4A shows storing the freshness value (or a portion thereof) in its volatile memory, as above and in relation to Fig. 2C is discussed. The receiving node can then increment this freshness value when transmitting a subsequent message and also store this incremented freshness value in its volatile memory, as in Fig. 2A is shown. This is shown in Fig. 4B illustrated using field FV+1 458.

[0093] Thus, the receiving node can become a sending node and send the secured message, as in Fig. Figure 4B shows this. To do so, the (now) sending node can access a session key from its volatile memory according to the current key counter value and the secure zone corresponding to the receiving node(s) of the sent secure message. As part of this process, the sending node can calculate the ICV and encrypt the payload to produce the payload 460. The sending node also calculates the current SCI based on the secure zone of the receiving node(s) of the secure message, as well as the counter value representation CNT 456, which is based on the current key counter value used to calculate the session key for that particular secure zone, as discussed above.Once the information for each of these fields has been calculated, the transmitting node assembles the secured message as discussed above and transmits it, repeating the process for each of the receiving nodes in System 300 as required. E. Examples of hardware implementation

[0094] Fig. Figure 5 illustrates the use of a hardware-based solution for utilizing freshness values ​​according to one or more embodiments of the disclosure. Fig. Figure 5 shows the communication protocol framework 400. Fig. 4A, which encompasses a variety of fields. The 400 communication protocol framework is identified by a secured message generated by a sending node. It should be noted that if the freshness values ​​are generated via a software-based approach as described above, the sending node can reorder secured messages, which are then received out of order by each of the receiving nodes. Although the acceptance window with respect to retrigger attacks may allow receiving nodes to accept such messages, the use of a software-based approach consumes a significant processing overhead.

[0095] Thus, the in relation to Fig. The solution described in section 5 allows a sending node to generate the freshness messages "on the fly" instead of buffering and reordering them, which is the conventional way freshness messages are transmitted. To achieve this, the sending node can implement any suitable timer mechanism. For example, each transmitting node can use a timer that references a tick time, which represents a predetermined timer value, such as 10 microseconds, 5 microseconds, and so on. Thus, the freshness value can still be a bit sequence, but these bits can comprise a binary representation of a number of "ticks," with each tick corresponding to a predetermined tick time. This eliminates the need for the transmitting node to store the freshness values ​​for each freshness message being transmitted, as described in section 5. Fig. 2A shows that the timer ticks faster than the message transmission time. In this context, it should be noted that a freshness value should never be reused for two messages. Thus, the freshness value discussed here can generally be implemented as any suitable type of monotonically increasing counter and, as shown in relation to Fig. 5 discussed, for example, a tick timer, a single sequence number counter, etc.

[0096] Using a timestamp for the secure channel (FV) can be advantageous in systems where secure messages are not reordered by the buffer scheme at the sending node, thus requiring only one secure channel. This might be the case, for example, if secure messages are generated during transmission (i.e., in hardware connected to a communication protocol engine). This reduces the memory and processing overhead associated with multiple secure channels. In this way, the hardware-based solution simplifies the secure message index (SCI) to a single fixed channel on the transmitting node side, as the use of the timestamp ensures that the FV always increases with each secure message.

[0097] Thus, for the in Fig. In Figure 5, the hardware-based solution shown allows the transmission nodes to use a fixed SCI value that corresponds to a unique device address for that specific transmission node. This SCI value is therefore unique throughout the entire system 300. As a result of this modification, the receiving node can additionally or alternatively store the SCI value in its non-volatile memory 204 and / or volatile memory 206, as shown in Figure 5. Fig. 2C shows how to store data as shown in Table 500. Table 500, for example, represents a mapping of SCI values ​​(i.e., unique transmit node addresses) to previously transmitted freshness values ​​(i.e., timestamps). Table 500 can be stored in the form of a lookup table to facilitate such a hardware-based solution. Table 500 can contain a unique SCI value corresponding to each transmit node from which the receive node is configured to receive secured messages, with the following for simplicity: Fig. 5 seven values ​​are shown, since Table 500 can store any suitable number of SCI and FV values ​​for received coded messages, depending on the application.

[0098] The receiving node can thus implement a hardware-based solution (e.g., via the processing circuit 208.2) designed to scan the data entries in table 500 until a matching SCI value for SCI 404 is found. For this table entry (i.e., SCI 5 in this example), the table should contain a previous freshness value that is less than the current FV 408. If the FV 408 is less than the corresponding previous FV in table 500 for SCI 5, the receiving node can reject the message, as it is likely a retry attack. It should be noted that if the table is not large enough to store the required number of entries, further customization can be outsourced for software management (e.g., using a hash table).

[0099] Fig. Figure 6 illustrates a further hardware-based implementation for adapting the secure messaging system to an existing conventional system according to one or more embodiments of the present disclosure. The Fig. Architecture 600, shown in Figure 6, demonstrates that the embodiments described herein are protocol-independent. That is, the use of counter value representations within secured messages and the session keys discussed herein can be implemented independently of any existing architecture and communication protocol. For example, Architecture 600 incorporates an existing Engine 602, which may include any suitable type of conventional communication engine for use with a real-time control system. Some examples of the existing Engine 602 might include a CAN bus engine, an Ethernet protocol engine, and so on, as well as any of the communication protocols discussed herein. Although in Fig. Figure 6 shows a single engine, but architecture 600 can include any suitable number of different engines simultaneously, e.g. a CANbus engine and an Ethernet engine.

[0100] Architecture 600 is implemented as an Advanced eXtensible Interface (AXI) bus architecture and includes TX and RX plaintext queues for buffering transmitted messages communicated within the specific system in which the existing Engine 602 is implemented. Traditionally, the existing Engine 602 controls the AXI coupled to the TX queue and the transmit buffer 604. Thus, the existing Engine 602 is designed to receive messages from the transmit buffer 604 and send these messages with an unencrypted payload according to a suitable communication protocol, such as those discussed herein.Furthermore, the existing Engine 602 is typically directly coupled to the AXI and the RX queue storage, and thus the existing Engine 602 can provide received messages with unencrypted payloads to the RX queue storage for delivery to other nodes in the system.

[0101] However, Architecture 600 additionally includes an Accelerated Real-Time Security Engine (ARTIS) 610 and a Multiplexer 612. The ARTIS 610 can be implemented as any suitable dedicated hardware component, such as a microcontroller, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), system-on-a-chip (SoC), dedicated logic, and / or other circuitry, etc. The ARTIS 610 is designed to perform all or some of the functions discussed herein with respect to the sending and receiving nodes, such as reading the representation of the key counter value contained in the secure messages, deriving the required session keys, performing encryption, authentication, and decryption, etc.The ARTIS 610 can be advantageously implemented in hardware rather than software to eliminate the need for reordering secured messages and thus minimize latency. This effectively reduces the window of opportunity for retrigger attacks to such a short period that the risk of retrigger attacks is essentially eliminated.

[0102] Architecture 600 also includes a multiplexer 612, which is controlled by the ARTIS engine 610 via the control signal 601. Thus, the ARTIS control engine 610 is designed to dynamically switch the operation of the system in which it is implemented (e.g., System 300) between unsecured and secured message operation. For example, the lower path of the multiplexer 612 can be selected to route plaintext data from the transmit buffer 604 to the existing engine 602, and in this operating mode, the ARTIS engine 610 can also route the received plaintext data to the RX queue memory.

[0103] However, the upper path of Mux 612 can be selected when operating in a cryptographic mode. In this mode, plaintext messages are routed from the transmit buffer to the ARTIS engine 610 and used by the ARTIS engine 610 to generate encrypted payloads that are included as part of the secure messages, as discussed herein. In this mode of operation, the secure messages are also routed to the RX queue memory and distributed to other receive nodes in the system, but as secure messages (versus unsecured messages generated by the existing machine 602). In this way, the 600 architecture allows the simultaneous operation of an existing, unsecured message transmission system with the secure message transmission system implementations discussed herein. F. Example process flows

[0104] The Fig. 7A and Fig. Figure 7B illustrates process flows used by sending and receiving nodes to send and receive secure coded messages according to one or more embodiments of the present disclosure. With reference to the Fig. 7A and Fig. 7B The process flows can comprise a procedure that is executed by and / or otherwise connected to any suitable number and / or type of components, such as one or more processors (processing circuits), hardware components, executed instructions (e.g., software components), or combinations thereof. The components can be connected to one or more components of node 200, as discussed herein. Flows 700 and 750 can contain alternative or additional blocks, which are described in the Fig. 7A and Fig. 7B is not shown for brevity and can be performed in a different order than shown. Furthermore, some blocks may be optional.

[0105] In particular, it delivers Fig. 7A Additional details regarding the process implemented by a sending node in the creation and transmission of a secure message. Fig. Section 7B provides additional details regarding the process implemented by a receiving node to validate key counter values ​​in a received secured message in order to accept or reject the secured message.

[0106] Referring first to Fig. 7A The process flow 700 can be implemented via any of the nodes discussed herein, such as any of the nodes contained in system 300, if secure message transmission is performed. This can include, for example, node 200, as described herein in relation to Fig. 2A was discussed.

[0107] Process flow 700 begins with the transmission (block 702) of a secured message. The secured message can be formatted according to any suitable communication protocol and contain any suitable number of fields, such as the communication frames mentioned herein in relation to the Fig. 4A-4B were discussed.

[0108] During the transmission of the secure message, process flow 700 includes incrementing (block 704) the freshness value across the transmission node. This can, for example, involve processing circuit 208.2, which increments the locally stored freshness value (e.g., FV.A, FV.B, FV.C, etc.) based on the specified secure zone according to the intended receiving node(s), as shown in Fig. Figure 2A shows that the freshness value incremented in this way can be correlated with one or more session keys for this particular safe zone, as discussed herein.

[0109] Process flow 700 further includes the sending node determining (block 706) whether a condition for re-keying is met. These conditions can include any suitable predetermined conditions which, if met, cause the key counter to be incremented, as discussed further herein, assuming that a priority marker, if implemented, is not set. Such conditions can include, for example, a number of secured messages transmitted with a given session key exceeding a predetermined number, the expiration of a predetermined time period, each system reboot, the receipt of a security alert request, and so on.

[0110] As an illustrative example regarding session key exhaustion, determining whether the number of transmitted messages secured with a given session key has exceeded a predetermined number of messages can involve determining (Block 706) whether the current (now incremented) freshness value exceeds a predetermined threshold. This predetermined threshold can be chosen as any suitable value that triggers a rekeying process due to session key exhaustion, as discussed herein. For example, the freshness threshold can be several million or several billion.

[0111] Thus, when a rekeying condition is met (e.g., the incremented freshness value exceeds the predetermined threshold), the sending node (block 708) performs a local rekeying of the key counter values. Using the secured zone A from above as an example, which is assumed to be used for the current secured message transmission, this might involve the session key generator 202 incrementing key counter A.1 (block 708) and overwriting NVM 204 with this new, updated key counter value (e.g., a key counter A.1+1, not shown). Additionally, when a rekeying event occurs, the transmitting node might reset its locally stored freshness value, which is transmitted in the next secured message, to its predetermined or default value (e.g., 1), which is then incremented for subsequently transmitted messages as described herein.

[0112] Process flow 700 also includes resetting (block 710) the freshness value for the secured zone to a default or initial value, which in this example is 0. Thus, continuing from the previous example, the freshness value FV.A would be reset to 0 (or another suitable initial value).

[0113] Process flow 700 further includes generating (block 712) an updated session key from the incremented key counter value. Using secured zone A as an example, this can involve session key generator 202 calculating session key A.2 from the common key A and the incremented key counter value according to the KDF, as shown in Fig. 2B shown. The previous session key A.1, as shown in Fig. Session key A.1, as shown in 2A, can then be overwritten with the updated session key A.2 or otherwise invalidated for future secure transmissions. For example, the updated session key A.2 can be stored in a new location in volatile memory 206 or overwrite the contents of session key A.1.

[0114] Process flow 700 can include the creation (block 714) of a secured message. This can include, for example, processing circuit 208.2, which creates a secured message, as discussed herein, with any suitable number of fields. The secured message can be created in this way by either using the original session key (e.g., session key A.1) if the freshness value (block 706) was determined to be less than the threshold, or alternatively, by using the updated session key (e.g., session key A.2) if the freshness value (block 706) was determined to be greater than the threshold, and thus the key counter and the session key were updated.In any case, the secured message can be generated using the current session key to encrypt the payload of the secured message, to transmit the secured message as an authentication-only message, or to transmit the secured message as both an authentication and an encrypted message. Again, the session key can be one of several (e.g., one is used for authentication and another for encryption). In such a case, process flow 700 can be extended to selectively update any suitable number of session keys that have the same freshness value.

[0115] Process flow 700 can include queuing (block 716) the generated secured message. This can, for example, include communication circuit 208.1, which adds the secured message to a queue buffer for transmission (block 702) in the appropriate order based on a message transmission priority. Alternatively, if a hardware-based solution as above is used with regard to Fig. If step 5 is implemented, then the use of a queue buffer may not be necessary, and the secured message can be transmitted (block 702) when it is created (block 714). Process flow 700 can thus be repeated for each secured message transmission across a transmission node, with process flow 700 applying to each subsequent secured message transmission.

[0116] With reference to Fig. 7B The process flow 750 can be implemented via any of the nodes discussed herein, for example, via one of the nodes contained in system 300, if a secure message transmission is received. This can, for example, be the one discussed herein with respect to Fig. 2A discussing node 200 includes, if it acts as a receiving node.

[0117] Process flow 750 begins with the receipt (block 752) of a secured message. Here too, the secured message can be formatted according to any suitable communication protocol and include any suitable number of fields, such as the communication frames contained therein in relation to the Fig. 4A-4B were discussed.

[0118] Process flow 750 further includes determining (block 754) whether the message counter, e.g., the key counter value represented by the CNT 406 as discussed herein, is smaller than the locally stored key counter value corresponding to the secured zone to which the secured message was sent and received. This determination may, for example, involve comparing the representation of the key counter value encoded by the CNT 406 with the locally stored key counter value for the same secured zone. For instance, the CNT 406 may represent a predetermined number of least significant bits of the key counter value used to generate the encoded message by the sending node prior to reception. In such a case, the determination (block 754) may involve a comparison via processing circuit 208.2. The determination may include a comparison between the same corresponding predetermined number of least significant bits of the locally stored key counter value for the current secure zone. Alternatively, if the total key counter value is represented by the CNT 406, the determination (block 754) may include a comparison, via processing circuit 208.2, between the total locally stored key counter value and the total key counter value represented by the CNT 406 for the current secure zone.

[0119] In any case, if it is determined that the key counter value derived from the CNT 406 is less than the locally stored key counter value for this secure zone, then process flow 750 includes the conditional approval or rejection of the derived key counter value. For example, process flow 750 includes a further determination of whether (block 755) the key counter value derived from the CNT 406 is within the predetermined grace period, as specified above. This grace period can also represent a time elapsed since the receipt of the last distinct key counter value and can additionally or alternatively be calculated based on the freshness values ​​associated with the key counter value derived from the CNT 406.

[0120] If the key counter value derived from CNT 406 falls outside this grace period, the process includes rejecting (block 756) the secured message. That is, in such a case, the receiving node determines that the key counter value represented by CNT 406 is invalid and therefore rejects the secured message, as this is indicative of a retry attack, an outdated message, or a corrupted message.

[0121] If the key counter value derived from CNT 406 is within the grace period (Block 755, Y) or if the key counter value derived from CNT 406 is not less than the locally stored key counter value for this secure zone (Block 754, N), process flow 750 continues and includes a further determination (Block 758) as to whether the opposite condition is true, i.e., whether the key counter value derived from CNT 406 is greater than the locally stored key counter value for this secure zone. If this is not the case, it means that the key counter value derived from CNT 406 matches the locally stored key counter value for this secure zone, and process flow 750 continues accordingly.

[0122] However, if the value derived from CNT 406 is greater than the locally stored key counter value for this secure zone, then the locally stored key counter value is, as mentioned above, outdated. Consequently, the left branch of process flow 750 corresponds to a conditional local (i.e., at the receiving node) rekeying process. That is, the receiving node can only update its locally stored key counter value in such a case if the key counter value represented in CNT 406 is determined to be valid through an additional message verification process.

[0123] For example, if the receiving node determines (Block 758, Y) that the locally stored key counter value is outdated, process flow 750 includes generating (Block 760) a temporary session key. To do this, the receiving node uses the full-length key counter value that was used by the sending node to generate the received secured message. Thus, if CNT 406 represents a truncated portion of the full-length key counter value used by the sending node to generate the secured message, the receiving node can derive the full length of the key counter value through a computational process. For example, the receiving node (e.g., processing circuit 208.2) can combine the untruncated portion (e.g., the higher-order bits) of the locally stored key counter value with the remaining truncated portion of the full-length key counter value (e.g.,link the low-order bits), which is represented by the CNT 406.

[0124] Once the full length of the key counter value is derived from CNT 406, the process for generating (block 760) the temporary session key is identical to that used by both the receiving and sending nodes to generate the locally stored session key. Thus, the receiving node uses the same KDF and other inputs that the sending node used (or should have used) to generate the temporary session key. Specifically, the full key counter value is used as one of the inputs for the KDF, along with the receiving node's locally stored shared key corresponding to the current secure zone.

[0125] In this way, the entire length of the key counter value calculated in this manner can be validated by using the temporary session key to decrypt the payload of the secured message, calculating the ICV value, and then comparing the calculated ICV value with the ICV 412 contained in the secured message. Thus, the ICVs only match (Block 762, Y) if the key counter value used to generate the secured message is valid. If this is not the case (Block 762, N), process flow 750 includes the receiving node rejecting the secured message (Block 756).

[0126] If the ICVs match, the receiving node (block 764) stores an updated key counter value in NVM 204 and overwrites the current key counter value, so that the locally stored key counter value now matches the valid full-length key counter value derived from CNT 406. This key counter value was then used by the sending node to generate the session key, which in turn was used to generate the current secured message. For example, if the receiving node previously set the key counter A.1 as in Fig. If 2A has been shown to be stored, then after this process both the receiving node and the sending node would store the key counter A.1+1.

[0127] Additionally, process flow 750 includes storing (block 766) the temporary session key generated from the full-length key counter value (block 760), which was derived from CNT 406 as described above, as the updated local session key of the receiving node. For example, if the receiving node previously stored the session key A.1, as in Fig. As shown in 2A, after this process the receiving node and the sending node would both store the session key A.2, which is generated using the key counter A.1+1, as shown in Fig. 2B shown.

[0128] Process flow 750 further includes updating (block 768) the local freshness value to match the one received in the secure message. For example, if the receiving node previously had the freshness value FV.A as in Fig. If 2A has been shown to be stored, after this process both the receiving node and the sending node would store the freshness value FV.A+1. Additionally, the receiving node can store the received FV protocol 206.1 as shown in Fig. Update 2C to store the FV from the secured message A.2 in correlation with the key counter value and the secure zone, as shown above.

[0129] The process flow 750 further includes accepting the secured message as the last step in the process, since the key counter value has been validated and the freshness value has been updated as a result of the local rekeying process.

[0130] As mentioned above, if the receiving node determines (block 758, N) that the key counter value derived from the CNT 406 matches the locally stored key counter value for this secure zone, then process flow 750 proceeds accordingly. This involves validating the key counter value derived from the CNT 406 based on a comparison of ICVs. Specifically, the receiving node can generate the session key from the key counter value derived from the CNT 406, or alternatively, use the locally stored session key to decrypt the payload content, calculate the ICV, and then determine (block 770) whether the ICVs match. If they do not, the secured message is rejected.

[0131] Otherwise, the process continues to determine (block 772) whether the freshness value contained in the secured message is greater than the locally stored freshness value for the sending node and the secure zone, e.g., as in the log of the FVs in Fig. 2C is shown. If so, the receiving node rejects the secured message. If not, the process flow includes updating (block 768) the locally stored FV with the FV contained in the secured message, as discussed above, and accepting (block 776) the secured message. Process flow 750 can thus be repeated for each secured message received via a receiving node, with process flow 750 applying to each subsequent secured message received. II. Secure communication using live membership tracking

[0132] Repetition attacks can also include both strong and weak types. As discussed in Section I above, strong repetition attacks can involve a node that legitimately receives a message once (i.e., accepts a validated secured message) and then, at a later time, accepts another, maliciously generated secured message from an attacker. Such strong repetition attacks can, for example, allow an attacker to store a previously sent secured message "disable immobilizer" and then resend that message at a later time. The use of the real-time bus key distribution system described in Section I aims to eliminate, or at least significantly reduce, the possibility of such strong repetition attacks.

[0133] This section, however, provides additional embodiments that can be used in addition to and / or in combination with the embodiments described above in Section I as an additional security measure against weak replay attacks. Weak replay attacks are related to techniques that aim to disconnect or otherwise force a node offline for a certain period of time in order to exploit the lack of knowledge of other nodes. For example, a weak replay attack can be carried out by partitioning the bus in a system used for secure communication. As a result, a target node cannot then receive the secure message originally transmitted by other nodes and instead receives the secure message when it is brought back online at a later time that is useful to an attacker.In a real-time control system used in an automotive environment, for example, a node may not receive a transmitted secure message "unlock door" and instead receive the same message if an attacker forwards the message to unlock the door while driving.

[0134] Weak replay attacks pose specific security problems with respect to a disconnected node that has been reset. For example, a receiving node, as described above, accepts... Fig. As described in Section 7B, after resetting, when a node comes back online, secured messages from other nodes are received with a key counter value greater than the locally stored key counter value of the receiving node. This allows an attacker to initiate a weak replay attack by partitioning the network, resetting a node, and then replaying old secured traffic from other nodes. The embodiments described in this section solve this problem by using live membership groups. In particular, the embodiments described in this section extend the real-time bus key distribution system described in Section I to determine which nodes are currently online, i.e., "live".A reset node may therefore refuse to accept secured messages from non-members or from members of the same group who have not checked their online status, even if a secured message would otherwise be accepted in accordance with, for example, the rules in Section I above regarding . Fig. The process described in 7B would have been assumed to be 750.

[0135] The groups of members discussed herein can comprise any suitable number of nodes within the system of interconnected nodes, as described above in Section I. This can, for example, include the entire system of interconnected nodes 300, as described above in relation to Fig. Figure 3 shows and discusses this. Alternatively, the groups of members can comprise a smaller subset of the system of interconnected nodes 300. Thus, the system of interconnected nodes 300 can comprise any suitable number of membership groups, each containing any suitable number of nodes as part of its respective membership group. The membership groups can include nodes that overlap with other membership groups, such as the safe zones discussed above. Thus, the membership groups can be defined according to any suitable grouping of nodes, which may be the same as or different from the safe zones discussed herein. If the groups of members are different from the safe zones, the groups of members and the safe zones can simultaneously form part of the system of interconnected nodes 300.In any case, the groups of members, as discussed herein, may be predetermined with respect to the system of interconnected nodes 300, and thus each node 200, as described herein, may be designed to operate using this information, as discussed below. A. Format for secure messages regarding live membership

[0136] Fig. Figure 8 illustrates example formats of secured messages used to request and respond to online status verification requests, according to one or more embodiments of the disclosure. The secured message formats, as described in Fig. The fields shown in Figure 8 can correspond to secured messages transmitted and received according to any suitable communication protocol and can form communication protocol frames comprising any suitable number of fields. Communication protocol frames 800 and 850 can include several fields that are also contained in communication protocol frames 400 and 450, as above in relation to the Fig. 4A and Fig. 4B shown and discussed. Thus, as mentioned above in Section I, the communication protocol frameworks 800 and 850 can also be identified with any suitable type of communication protocol that can be implemented to facilitate the communication of secure messages over a multipoint or point-to-point bus architecture.

[0137] The communication protocol frame 800 can, for example, correspond to a communication frame identified by a secure message that is initially transmitted via node 200 when it acts as a transmission node. To support the use of live membership according to the embodiments provided in this section, the processing circuit 208.2 is thus designed to generate the communication protocol frame 800, which is transmitted via the communication circuit 208.1 as described in Section I above. In the context of the groups of members discussed in this section, a node requesting online verification from other nodes may alternatively be referred to herein as a "challenging" node, and a request for online verification may alternatively be referred to herein as a "challenge request" or simply a "challenge."Additionally, any node that receives a secure message containing an online verification request from other nodes and then responds to that request can alternatively be called a "responding" node. It should also be noted that, although the concepts of challenging and responding nodes are separated here for brevity and ease of explanation, a node can function as both a challenging and a responding node simultaneously. The interaction between challenging and responding nodes, as well as their functions, are discussed further below.

[0138] It should be noted that the embodiments described in this section utilize typical data traffic occurring in a system of interconnected nodes. That is, the embodiments described in this section can implement the use of additional information, encoded and added to the secure messages, as discussed in Section I above, to both request online verification from other nodes and respond to such requests. Thus, requests for online verification (i.e., challenges) and responses to such requests can be made through the ordinary transmission of secure messages between nodes. This has the advantage that the online status of nodes can be checked without the use of special messages, so that the challenges and the responses to them do not burden the communication bandwidth.

[0139] To this end, the 800 communication protocol framework includes an RSVP field 802, as shown, which comprises a representation of a query value. The query value can thus be represented as any suitable coded value indicating whether a node is requesting online status verification from other nodes within a membership group. It should be noted that the query value can be coded in an indiscriminate manner by any node in the membership group; that is, a challenge request using the query value can utilize a secure message transmitted to multiple interconnected nodes, for example, via the multidrop scheme discussed herein.

[0140] For example, the query value can include different predefined values ​​depending on whether a node requests online verification from other nodes in the same membership group. That is, the query value can be identified with a predefined default value representing a node that is not requesting online verification. Alternatively, in such a case, the content of the RSVP field 802 can be left blank and / or the RSVP field 802 cannot be included in the communication protocol frame 800 if no online verification request is made. Thus, if a node requests online verification from other nodes, the query value can include a predefined value that is recognized by other receiving nodes in the membership group.

[0141] To give an illustrative example, the query value can include any suitable coded value that uniquely identifies the sending node requesting an online verification request from other nodes. This unique identifier can include any suitable value known to the other nodes in the membership group through an initial configuration and setup process. For example, if node 200 is identified as node 5, the query value can be a coded representation of "5" when node 200 requests an online verification request from other nodes, and can otherwise be set to "0".

[0142] To provide another illustrative example, the RSVP field 802 can contain a one-bit binary value set to one value (e.g., 1) when a challenging node requests online verification from other nodes, and to another value (e.g., 0) otherwise. Thus, the query value does not need to identify the challenging node itself, but can instead simply identify that the challenging node is requesting online verification from other nodes. In such a case, any responding node can determine the identity of node 200, from which the secured message was received, in any appropriate manner.This identification can be achieved, for example, by identifying data that may be contained in other fields of the communication protocol framework 800, which are filled in via node 200 during the transmission of each secured message according to the specific communication protocol used.

[0143] It is further noted that, although the communication protocol frameworks 800, 850 in Fig. Figure 8 shows the use of a dedicated RSVP field 802 to provide the representation of the query value; this is only an example and not a limitation. In other embodiments, the representation of the query value may be contained in an alternative field of the communication protocol frames 800, 850, so that the dedicated RSVP field 802 is not required. For example, the representation of the query value may be contained in part of the header 452 or form part of the payload 410.

[0144] The communication protocol frameworks 800 and 850 also include a Response Field (RESP) 804, which is populated by a responding node in a subsequently transmitted secure message. The RESP 804 field can contain coded data that provides a suitable indication of whether a node in the membership group has responded positively to an online status verification request transmitted by other challenging nodes. As mentioned above for the RSVP 802 field, the coded data contained in the RESP 804 field can be, as in Fig. As shown in Figure 8, the data can be contained in an alternative field of the communication protocol frames 800 and 850, so that the dedicated RESP field 804 is not required. For example, the encoded data contained in RESP field 804 can be included in part of header 452 or form part of payload 410.

[0145] For example, RESP field 804 can contain any suitable type of mapping that uniquely identifies each node in the membership group. For example, and with reference to Fig. 8. A membership group can comprise 16 nodes within the system of interconnected nodes 300. Each of these 16 nodes can be uniquely identified in any suitable way known to the other nodes, as mentioned above. The RESP field 804 can thus comprise a bit sequence (e.g., a bit array) where the position of each bit in the bit sequence corresponds to each respective node in the membership group. In other words, each bit in the bit sequence is identified with another node in the membership group by a respective predetermined bit position within the bit sequence. For the in Fig. In the example communication protocol frame 850 shown in Figure 8, the rightmost bit position corresponds to node 0 and the leftmost bit to node 15.

[0146] Thus, each bit position in RESP field 804 corresponds to a value indicating whether each node has responded positively to an online status check request from one or more other nodes in the membership group. The predetermined bit position of the RESP field therefore corresponds to each of the nodes that have requested an online status check. Thus, each node in the membership group that receives an online status request from other nodes can set the bit value for the bit position assigned to each respective challenging node to a different predetermined value (e.g., "1"). In this way, the value of each bit in RESP field 804 is based on a value set by each node in response to a challenge request from any other node in the membership group. Therefore, and with further reference to Fig. 8 indicates that the Communications Protocol Framework 850 states that nodes 5, 10 and 14 have requested online verification from each node in the membership group.

[0147] To populate RESP field 804, each node in the membership group can maintain a log of online verification requests received from other nodes. For example, node 200 can maintain an online verification request log 207 as part of volatile memory 206, as shown in Fig. 2A shown, or alternatively, as part of non-volatile memory 204 (not shown). Thus, each responding node can store in the online verification request protocol 207 a bit sequence or other suitable set of coded values ​​corresponding to RESP field 804. For example, the online verification request protocol 207 can store a bit sequence identical to RESP field 804, where each bit position in the locally stored bit sequence represents an indication of whether each node in the membership group has requested an online verification request. This, in turn, is determined by the representation of the query value included in the secured message transmitted by each node (e.g., via RSVP field 802).

[0148] Again using the example for Fig. The convention shown in Figure 8 assumes that a node has received an online verification request via secure messages received from each of the identified nodes 5, 10, and 14. These secure messages can be received over a period of time, and thus the processing circuit 208.1 can update the contents of the locally stored online verification request log 207 as each secure message is received. The number of secure messages that can be received in this way before the next scheduled secure message with the populated RESP field 804 is generated can be any threshold value based on the configuration, available bandwidth, the number of nodes in the membership group, etc. In any case, the processing circuit 208.1 for each secured message received with a representation of the query value indicating that a challenge request has been made (e.g., via the RSVP field 802), the contents of the locally stored online verification request log 207 to represent each of these pending requests.

[0149] Therefore, the local bit sequence stored in the online verification request protocol 207, before a node populates RESP field 804 in response to these online verification requests, can contain the same content of RESP field 804 as in Fig. Figure 8 shows that when a node in the membership group sends the secured message to respond to pending challenges, the node (e.g., via processing circuit 208.2) copies the contents of the online verification request log 207 into the RESP field 804, as shown in Figure 8. Fig. Figure 8 shows that when the secured message is transmitted with this populated RESP field 804, the responding node (e.g., via the processing circuit 208.2) is configured to reset the contents of its locally stored online verification request log 207 to a predetermined initial state. This predetermined state may include a state indicating that there are currently no pending online verification requests from other nodes. For example, the locally stored online verification request log 207 may be reset to store a bit sequence consisting entirely of zeros. Therefore, and continuing the example, if there are no pending online status verification challenge requests, each node in the membership group can transmit its respective RESP field containing all zeros, i.e., the current contents of the locally stored online verification request log 207.

[0150] Again, each node in the membership group can operate in the same way as node 200, as described above regarding Fig. 2A is described. To give an illustrative example with regard to the 850 communication protocol framework, node 200 can receive several secured messages over time. From these secured messages, challenge requests for online verification are received from nodes 5, 10, and 14 via their respective secured messages. Thus, node 200 can receive the secured messages in any suitable way (e.g., via a bus such as the multi-bus described above) through the communication circuit 208.1, where the secured messages are then processed by the processing circuit 208.1, as discussed in more detail herein, to accept or reject them.

[0151] Although this section uses a single responding node as an example for the sake of simplicity, it's important to note that each node receiving a challenge message can respond to such requests individually. While referred to as "responding," in this context, it's important to understand that each responding node is not required to transmit a dedicated secured message in response to such requests. Instead, each responding node can populate its own RESP field 804 as part of the next scheduled secured message to be transmitted. To make the contents of RESP field 804 available for online verification, each node can modify the contents of its locally stored online verification request protocol 207 (e.g., via processing circuit 208.2) when additional secured messages are received.Thus, the content of the Online Verification Request protocol 207 indicates at a given time which nodes have requested an Online Verification Request that is currently pending (i.e., waiting for a response via the occupation of RESP field 804 in a transmitted secure message).

[0152] Thus, continuing the present example, each responding node can populate the RESP field 804 when generating the next scheduled secure message, which is transmitted to and received by each of the nodes in the membership group, including nodes 5, 10, and 14. In this way, the secure message itself is not generated as a response to receiving online verification requests across multiple secure messages. Rather, the RESP field 804 is populated as part of the generation of the next scheduled secure message, which is transmitted in response to receiving online verification requests from one or more challenging nodes. This allows a responding node to simultaneously respond to a challenge request from any number of nodes (e.g.,All nodes in the membership group that have received an online verification request will respond via a single transmitted secure message. By using the existing secure message scheduling architecture and eliminating the need for dedicated messages to be sent in this manner, the speed at which nodes can respond to online verification requests is significantly faster (e.g., a few hundred microseconds such as 100, 200, 300 microseconds, etc.), especially for hardware implementations like those discussed above in Section I. Furthermore, this advantage is leveraged for the live membership implementations described in this section by ensuring that all responding nodes can respond to a challenge no later than their shortest frame time plus their latency (typically < 20 ms).This advantageously enables extremely fast detection of offline nodes, which is particularly useful for real-time control systems and other safety-critical systems, such as those used in automotive applications.

[0153] And because each responding node only responds to an online verification request via the populated RESP field 804 if that node is online, the RESP field 804 in every secured message received via a challenging node allows the challenging node to infer (i.e., determine) the online status of every responding node within the membership group. To provide an illustrative example, if secured messages containing the RESP field 804 are lost, the requesting node (i.e., the node that sent the challenge request) must request the online status verification again to confirm an offline status. With the CAN XL protocol, messages are not lost by default (i.e., the protocol itself resends messages corrupted by noise).In an Ethernet-based system, a requester can infer that a node is offline if a threshold number of challenge requests (e.g., two, three, etc.) remain unanswered.

[0154] In addition to the conclusion described above that a node is online, a node requesting online verification from other nodes can implement further verification based on the content of RESP field 804. For example, if a secure message containing the content of RESP field 804 is transmitted, every node in the membership group receives the secure message, which includes both nodes that have made an online verification request and nodes that have not. Thus, each node that made the online verification request (e.g., nodes 5, 10, and 14 in the example above) can determine, based on the content of RESP field 804 filled in by each responding node, whether every node in the membership group has responded positively to these requests.

[0155] To give an example, the communication circuit 208.1 of node 200 is designed to receive secured messages from each node in the membership group with a populated RESP field 804 based on previous online status verification requests. The receiving node (previously a challenging node) can then determine, based on the contents of RESP field 804, whether each node in the membership group that responded to a previous verification request is online. For example, and continuing the example provided above, node 5 can compare the contents of the bit at node 5's position with a predetermined value (e.g., the bit value 1) to determine whether a responding node in the membership group correctly identified its online status in response to the request.Continuing this example, if, after transmitting a secured message requesting online verification, a node in the membership group responds with a secured message containing a "1" in that bit position in RESP field 804, then Node 5 would determine that that node is online and active. Otherwise, Node 5 would determine that the responding node is indeed offline and either malfunctioning or that the message is being sent from an unauthenticated source, such as an attacker attempting a weak replay attack. Alternatively, Node 5 might determine that the secured message was lost / corrupted with the challenge request or that the secured message was lost / corrupted with the responding node's reply (however, as mentioned above, this generally does not occur with CAN XL).

[0156] The comparison of the contents of RESP field 804 can be performed in any suitable manner, which may include software-based execution via the processing circuit 208.2 (or one or more other suitable processors) executing instructions in program memory 208.3 (or other suitable memory). However, given the example of the one-bit encoding format of RESP field 804, it may be particularly advantageous to compare the contents of RESP field 804 using a hardware-based solution, such as logic gates, and / or other suitable hardware to determine an online status indication of the responding nodes. Such hardware may be implemented, for example, as part of the communication circuit 208.1, the processing circuit 208.2, etc.

[0157] It is further noted that each node in the membership group can function in this way, i.e., by sending online verification requests to other nodes via the query value representation, responding to these requests using RESP field 804, and verifying whether each node is online based on the content of RESP field 804. For example, each challenging node in the membership group can determine whether other nodes within the membership group are online. This is facilitated by the challenging node (e.g., via processing circuit 208.2) determining, for each received secured message, whether a bit in the bit sequence corresponds to the predetermined bit position for the challenging node.The challenging node thus verifies whether a responding node is online, based on whether the value of this predetermined bit position correctly indicates that the challenging node had previously requested the online status verification. In this way, the encoded value of the predetermined bit position for the challenging node can represent a value (e.g., "1") that indicates a positive response from each responding node to the previous online status verification request.

[0158] In any case, each node in the membership group can accept or reject a secured message based on the response to a previously transmitted online status verification request. Again, such a response can include the completed content of RESP field 804. Thus, the decision to accept a secured message can be based on the inferred online status of a node that transmitted a secured message with the content completed in response to an online status verification request as described above. Alternatively, the decision to accept a secured message can be based on the online status of a node determined by the completed content of a specific bit or other suitable mapping in RESP field 804, indicating that the challenging node previously sent an online status verification request.In this way, each node in the membership group can determine whether to accept secured messages, based on whether each responding node is online. This conditional acceptance of secured messages in this manner is further discussed below in relation to [reference to relevant section]. Fig. 9B discussed in more detail.

[0159] Regardless of how the online status of other nodes is determined, embodiments include the node 200 maintaining a log of the online status of other nodes in the membership group in any suitable manner. For example, each node in the membership group may maintain an online status log with respect to other nodes in the membership group. For this purpose, the node 200 may store an online status log 209 as part of the volatile memory 206, as shown in Fig. 2A shown, or alternatively comprise as part of the non-volatile memory 204 (not shown). Thus, each node in the membership group can store in the online status log 209 a bit sequence or other suitable set of values ​​that correspond to the current online status of each node in the membership group at a given time. For example, the online status log 209 can store a bit sequence similar to the online verification request log 207, where each bit position in the locally stored bit sequence corresponds to an indication of whether each node in the membership group is currently online (e.g., a '1') or offline (e.g., a '0').

[0160] In one embodiment, each node in the membership group (e.g., via the processing circuit 208.2) is configured to determine the current online status of every node in the membership group based on any suitable number of received secured messages. For example, if each secured message is received by each of the responding nodes, an online status determination can be made based on each received secured message. This determination can, for example, involve an accumulation of bit values ​​received by each responding node that correspond to the contents of the RESP field. To provide an illustrative example, node 5 can send a secured message requesting online verification from every node in the membership group via the contents of the RSVP field 802.Each of the other 15 nodes in the membership group can then transmit secure messages containing filled-in contents of RESP field 804, which includes bit 5 in the RESP field, as in . Fig. 8 (and possibly additional bits) are shown, set to a value of "1", representing an affirmative response to the online challenge request from node 5. Thus, when each of these secured messages is received by the other nodes, node 5 can accumulate the bit values ​​from the same predetermined bit position in RESP field 804 that corresponds to node 5 in each secured message. When the bit values ​​are accumulated in this way, they are then allocated to a predetermined bit position corresponding to each node within the online status log 209. Therefore, when each of the other 15 nodes is determined to be online, the online status log 209 contains a bit value of "1" at a predetermined bit position corresponding to each of the other 15 nodes.In this way, the content of the online status protocol node 209 corresponds to an accumulation of bit values ​​from the RESP field 804 in a number of received secured messages.

[0161] Additionally, embodiments include the provision that the value of each bit in the online status log 209 is reset to a predetermined value when suitable conditions are met. For example, the bit values ​​of the online status log 209 can be reset periodically or when a number of secured messages are rejected that exceeds a threshold. To provide another example, the bit values ​​of the online status log 209 can be reset after a threshold time has elapsed since the bit value of one or more nodes was updated. In this way, the online status of each node in the membership group can be maintained via the contents of the online status log 209.Once a bit value of the online status protocol 209 is reset in this way, a node in the membership group can then make another request for online verification of other nodes in the membership group via another transmitted secure message by filling in the RSVP field 802 as described above. To provide an illustrative example, a node can issue another request for an online verification challenge during the reset period, thus maintaining a continuous "online" status that is periodically updated. In this way, the online status can be used to accept / reject messages, preventing a gap in the status that would lead to lost secure messages.

[0162] Furthermore, it should be noted that online status check requests can be particularly useful when a challenging node is reset and comes back online, although the implementations are not limited to this specific scenario. Online status check requests can be sent by any node within the membership group at any suitable time, for example, triggered by the fulfillment of one or more conditions. For instance, an online node in the membership group can periodically (e.g., every 100 ms, every 500 ms, etc.) transmit online status check requests to determine the status of the bus and / or other nodes in the membership group.

[0163] This can be particularly useful as a diagnostic tool. For example, if no nodes respond to a challenge, the challenging node may determine that no other nodes in the membership group are currently online and / or that the transmitted secure message containing the challenge has been lost. Furthermore, if a particular node in the membership group does not respond with a positive response in RESP field 804, it can be determined that the node is offline or that its response has been lost. If, in addition, traffic continues to be observed from nodes identified as offline, these nodes are likely being spoofed through repeated traffic.

[0164] Again, the implementations of live membership discussed in this section can be used to implement any of the communication protocols mentioned above in Section I. However, the implementations of live membership discussed in this section can offer particular advantages when used according to Ethernet or Ethernet-based protocols. This is because CAN XL provides atomicity, so when a frame is marked as sent, every online node has successfully received the frame. This atomicity greatly facilitates the detection of offline nodes, as no challenges are lost. It should be noted, however, that Ethernet protocols do not provide atomicity in this respect, and thus frames are routinely discarded. As a result, management algorithms must handle the missing frames, which are typically retransmitted.The implementations of live membership described in this section advantageously enable Ethernet implementations that eliminate or reduce the complexity of such management algorithms by checking the online status of other nodes in a membership group and maintaining a status log of this information. B. Process flows of live membership

[0165] The Fig. Figures 9A-9B illustrate process flows used by nodes to send and receive secure messages according to one or more embodiments of the present disclosure. With reference to the Fig. 9A-9B can comprise process flows that are executed by and / or otherwise associated with any suitable number and / or type of components, such as one or more processors (processing circuits), hardware components, executed instructions (e.g., software components), or combinations thereof. The components can be associated with one or more components of node 200, as discussed herein, and can represent software-based implementations, hardware-based implementations, or combinations thereof.

[0166] In particular, Fig. 9A provides additional details regarding the process implemented by a node to generate and transmit a secure message. Fig. Section 9B contains additional details about the process implemented by a node to accept or reject a received secured message and, if applicable, to respond to challenge requests. It should be noted that the process flow in Section 900 can be identified as the transmission of a secured message via a challenging node or a responding node, or alternatively, a node can act as both a challenging and a responding node simultaneously.

[0167] Furthermore, process flow 950 can be identified as the receiving and optionally sending of a secure message by a challenging node or a responding node. Again, a node can act as both a challenging and a responding node simultaneously. For example, a challenging node might later receive a secure message from a responding node, so process flow 950 refers to receiving a secure message from a node that responds to the previous challenge request. Thus, processes 900 and 950 can contain alternative or additional blocks that are included in the Fig. 9A and Fig. The steps in section 9B are not shown for brevity and can be performed in a different order than shown. Furthermore, some blocks may be optional, depending on the specific function of a node at a given time.

[0168] Referring first to Fig. 9A The process flow 900 can be implemented via any of the nodes discussed herein, such as any of the nodes contained in system 300, if secure message transmission is performed. This can, for example, include node 200, as described herein in relation to Fig. 2A was discussed. Process flow 900 can contain multiple blocks that are executed in the same way as process flow 700, as discussed above in Section I with regard to Fig. 7A is discussed. For brevity, these common blocks are represented by the sub-flow 700.1 block, as in the Fig. 7A and Fig. Figure 9A illustrates that process flow 900 demonstrates that a node can transmit a secure message using a process (block 902) that is part of subflow 700.1. Furthermore, blocks 902, 914, and 916 are considered analogous blocks to blocks 702, 714, and 716. Therefore, the functionality of blocks 902, 914, and 916 may be the same as, or substantially similar to, that previously described in relation to blocks 702, 714, and 716. For brevity, only the differences between these functional blocks will be discussed in detail.

[0169] As in Fig. As shown in 9A, both arrows pointing towards the Fig. The subflow shown in 7A, 700.1, is summarized into a single arrow for the sake of simplicity. Thus, the secured message continues to be used for process flow 900 based on the same conditions as in [reference missing]. Fig. The subflow shown in Figure 7A generates block 700.1 (block 914). However, process flow 900 contains additional blocks 914.1 and 914.2, which are identified with the generation (block 914) of the secured message.

[0170] For example, the generation (block 914) of the secured message includes, as in Fig. Figure 9A shows the generation (block 914.1) of a query value representation. As discussed above, this can include any suitable query value indicating whether the node is requesting an online verification request from other nodes in the membership group. For example, a query value representation can include a binary value or an encoded value that identifies the node, which can form part of the RSVP field 802, as discussed above.

[0171] The generation (block 914) of the secured message, as in Fig. As shown in 9A, this also includes the generation (block 914.2) of one or more coded values ​​which (when set) indicate responses to current requests (i.e., challenges) for online verification from other nodes in the membership group. Thus, although this is in the Fig. Not shown in block 9A for the sake of simplicity, before transmitting (block 902) the secured message with its own challenge requests, the node has received secured messages from other nodes challenging it with their own challenge requests. Again, and as discussed above, the coded values ​​provided in the secured message can include any suitable values ​​set by the (currently sending) node and represent an affirmative response to each pending challenge request received from other nodes in the membership group. For example, the generation (block 914.2) of one or more coded values ​​can include populating RESP field 804 in response to these online verification requests, as discussed above.The RESP field 804 can be filled, for example, by the node copying the contents of the local online verification request log 207 into the RESP field 804, as shown herein.

[0172] Once the secured message is generated (block 914), it can be queued (block 916) and transmitted (block 902) to the bus, for example, as shown herein. After the secured message has been transmitted (block 902), the node can then reset the contents of the local online verification request log 207 to a predetermined state (e.g., all zeros) (block 904), which remains in that state until additional challenges are received before the transmission (block 902) of the next secured message. It should be noted, however, that resetting (block 904) the contents of the local online verification request log 207 is optional, as it does not occur if the node does not respond to pending challenge requests via the population of the RESP field 804.

[0173] Let us now turn Fig. 9B, the process flow 950 can be implemented via any of the nodes discussed herein, for example, via any of the nodes contained in system 300, when a secured message is received. This can, for example, be the one discussed herein with respect to Fig. The discussed nodes in section 2A comprise 200. Process flow 950 can contain multiple blocks that are executed in the same way as process flow 750, as described above in Section I with regard to Fig. 7B is discussed. For brevity, these common blocks are represented by the subflow 750.1 block, as in the Fig. 7B and Fig. Figure 9B illustrates that process flow 950 demonstrates that a node can receive a secured message using a process (block 952) that includes subflow 750.1. Furthermore, blocks 952, 976, and 956 are considered analogous blocks to blocks 752, 776, and 765, respectively. Therefore, the functionality of blocks 902, 914, and 916 may be the same or substantially similar to that previously described in relation to blocks 752, 776, and 765. For brevity, only the differences between these functional blocks will be discussed in detail.

[0174] Subflow 750.1 provides various criteria that define the acceptance of a secured message, as discussed above in relation to Section I. For process flow 950, two paths are shown: the upper path is identified with a challenging node receiving a response, and the lower path is identified with a responding node receiving a challenge request. It should be noted that both paths can be executed simultaneously by the same node, for example, if a node is receiving other challenge requests and checking responses to its own.

[0175] In any case, process flow 950 modifies the criteria by which a node can accept secured messages (block 976), based on a determination (block 954) of whether a responding node indicates that it is currently online, which may be a response to a previous online verification request issued by a challenging node. Thus, the determination (block 954) can be performed by hardware or software, as mentioned above, and may, for example, determine whether a node has responded positively to a previous request by setting a predetermined bit in response field 804. If the online status request is not verified (block 954, no), the secured message is rejected. Otherwise, the secured message is accepted (block 976). In either case, process flow 950 may include updating (block 958) the online status log.This can also include, for example, the challenging node updating the online status log 209, as discussed in this section.

[0176] It is also noted that the determination (Block 954) of whether a node is online may involve determining the online status of a node within an acceptance window, which may correspond to any suitable threshold period. For example, the acceptance (Block 976) of secured messages may be made dependent on whether the online status has been confirmed recently enough (Block 954, Yes), even if a particular secured message does not contain a response. Such a determination may be included as part of the online determination, as shown in Block 954. As an illustrative example, a challenging node may not transmit secured messages very frequently, so additional secured messages that occur before a previous challenge request is sent may not contain a response to an immediately pending challenge.

[0177] The process flow 950 may, in addition or as an alternative to accepting (block 976) the secured message, include a further determination (block 960) as to whether the secured message contains an online verification request (i.e., a challenge request). This determination (block 960) may, for example, involve identifying a representation of a query value contained in the secured message, such as the RSVP field 802, as specified herein. If not, the process flow 950 follows the same path as described above to update the online status log (if necessary) (block 958) and repeat this process for subsequently received secured messages.

[0178] However, if the secured message contains an online verification request, process flow 950 includes updating (block 962) the online verification request log, as described above with reference to online verification request log 207. Process flow 950 can then proceed to block 914, as shown and discussed above with reference to process flow 900. In this case, a secured message can be generated, for example, by populating RESP field 804 with the contents of online verification request log 207. Naturally, the secured message generated in this way can also contain a challenge request from other nodes via the representation of the query value, as described herein. III. Priority Message Queue Management

[0179] As mentioned above, CAN-based networks can implement atomicity, although conventional CAN-based atomicity also has several drawbacks. For example, CAN-based communication can suffer from the so-called "double reception problem." This means that receiving nodes can accept a frame 1 bit before a transmitting node has completed its transmission. Consequently, an error in the last bit of the frame end (EOF, End-Of-Frame) triggers a retransmission of the frame, and a frame is received twice. Additionally, offline nodes are simply ignored.

[0180] Furthermore, Ethernet-based networks generally do not provide atomicity, as most Ethernet-based protocols only implement CRC and internal symbol encoding checks. If these fail, such Ethernet-based solutions simply discard the frame and rely on a higher layer (e.g., TCP) to resend it. Nevertheless, there have been attempts to extend atomicity to Ethernet-based networks using a topology known as a "ring," with one such example in Fig. 10 is shown.

[0181] For example, it illustrates Fig. 10. A conventional high-availability seamless redundancy (HSR) ring topology, which can be defined according to the International Electrotechnical Commission (IEC) 62439. In an HSR ring implementation, outgoing frames are duplicated and sent to two terminals. Input terminals forward frames to an opposite output terminal and discard duplicates. However, HSR ring implementations require a specific topology, the use of a scheme for transmitting duplicate messages, and the achieved atomicity is vulnerable to the robustness of the connections between the individual terminals, with the failure of any terminal connection resulting in a loss of atomicity for the entire system.

[0182] Thus, the embodiments described in this section overcome these disadvantages by using a defined solution for tracking groups and leveraging a defined transmission scheme. This transmission scheme is implicitly included in the Ethernet MACsec standard and therefore provides a reliable basis for enabling group-wide atomicity in such networks. For example, when an Ethernet MACsec standard is implemented, a node can transmit pending messages according to an Ethernet PHY-level collision avoidance (PLCA) scheme. FIFO buffers can be implemented for this purpose, acting as transmission queues to facilitate message transmission during each node's transmission time.This means that the MACsec standard requires a “sequential” delivery of frames, as otherwise the sequencing of packet numbers leads to security errors, since the communication frames appear as repetitive attacks.

[0183] In general, such transmission scheduling systems use, for example, four or eight FIFO queues, each identified with a different priority class, to separate messages according to their relative urgency. For example, the IEEE 802.1Q and 802.1AS standards for time-sensitive networks (TSN) define eight different priorities for this purpose. Additionally, 10BASE-T1S implements real-time scheduling using PLCA and employs a round-robin algorithm. Thus, and as discussed below, nodes operating according to a PLCA transmission scheduling scheme transmit the frame at the top of the highest-priority FIFO queue whenever transmission is possible.

[0184] Furthermore, as discussed below, the embodiments described in this section can utilize coded responses contained in an acknowledgment field to verify that each node has received a transmitted message. A sending node can then delete a message from a FIFO queue only if every designated receiver node of a transmitted message has received the message, which can be determined based on the contents of the acknowledgment field. If not every node has received the message, a node can retain the message in the FIFO queue for retransmission according to the PLCA transmission scheduling scheme. In this way, the embodiments described in this section achieve Ethernet-based atomicity, which would otherwise be costly, complex, and unsuitable for real-time control system applications.And since the embodiments described in this section can facilitate atomic broadcasting for PLCA broadcast planning schemes, the embodiments in such scenarios may alternatively be referred to herein as the use of an ABP (Atomic Broadcast for PLCA) protocol.

[0185] It should be noted that the embodiments described in this section can facilitate the communication of both secure and unsecured messages, both of which are simply referred to as "messages" in this section. For example, and as further discussed in detail below, the authentication or authentication and encryption techniques described herein are optional, and if they are not used, the messages may include unsecured messages. However, if the authentication or authentication and encryption techniques described herein are implemented, the messages may include secure messages. The embodiments described herein can support atomicity for both secure and unsecured messages. A. Node architecture and operation

[0186] Fig. Figure 11 illustrates another example of a node architecture according to one or more embodiments of the disclosure. Node 1100 may contain similar components to node 200, as shown in Fig. 2A shown. Thus, all statements concerning node 200, as described in Sections I and II, are applicable to node 1100 described in this section, with differences in its operation, configuration, and / or components being discussed in more detail below. For example, node 1100 can also be identified by any suitable component type and represent a node in a system of interconnected nodes, such as any of the nodes N1-N X , as in Fig. 3 discussed, although the use of the respective connectivity mappings, as in Fig. Figure 3 is shown, but is optional. Node 1100 can be identified with part of an electronic control unit (ECU), a sensor, an actuator, a host, etc., and the various nodes in such an interconnected system may differ in type and / or function, although each node may share common functionality. Thus, each node in the system of interconnected nodes can be configured to send and / or receive messages according to any suitable communication protocol, as further discussed herein.

[0187] Furthermore, the operation of node 1100 as part of an interconnected system of nodes can be described in more detail herein as part of a group of nodes, and the atomicity of the communicated messages is described with respect to the same group. However, the embodiments are not limited to node 1100 being part of a single group, and node 1100 can be operated according to any suitable number of such groups, the embodiments described in more detail in this section being understood as applicable to the nodes within the same group.

[0188] Here too, node 1100 can represent a node in an interconnected network of nodes. This can comprise a system of interconnected nodes designed to communicate over a bus according to a multi-connection scheme discussed herein. Such a multi-connection scheme can, for example, be part of an onboard E / E architecture discussed above, which may include an Ethernet architecture or another suitable onboard E / E architecture. If an Ethernet architecture is implemented, the nodes described in the embodiments in this section can implement any suitable type of Ethernet communication protocol, such as 10BASE-T1S or 10BASE-T1L.For example, Node 1100 can transmit and / or receive messages as discussed herein to communicate with other nodes within the system of interconnected nodes using any number and / or any type of communication protocols and accompanying operating modes. For example, Node 1100 can be configured to receive and transmit messages according to any suitable type of Ethernet communication protocol (e.g., multidrop Ethernet communication protocols such as 10BASE-T1S, 10BASE-T1L, the Ethernet MACsec standard, etc.).

[0189] Here too, node 1100 can be part of a group of interconnected nodes, which can represent the entire interconnected system of nodes or a subset (e.g., a group) thereof. In any case, node 1100 (like every other node in the same group) is designed to transmit messages to other nodes and to receive messages transmitted by other nodes via data interface 1110. Although every node in the group (containing node 1100) is designed to perform both transmit and receive functions, the term "transmit node" is used herein to refer to a node that is currently transmitting a message and / or performing functions related to such message transmissions.The term "receiving node" is used herein to refer to any node that is currently receiving a message and / or performing any functions related to such message reception.

[0190] A group of nodes can support message communication according to any suitable type of control system, such as a real-time control system that might be implemented in a vehicle. Thus, node 1100 can be one of any number of suitable nodes in a group that communicate with each other over an interconnected network by transmitting and receiving messages via data interface 1110. These nodes can be connected to, and / or form part of, a network, bus, etc., used as part of any suitable point-to-point or multi-point scheme. Data interface 1110 can include any number and / or any type of data interface to facilitate message exchange between node 1100 and any number of other nodes within the group.

[0191] To perform message communications, node 1100 includes a non-volatile memory 1104, a volatile memory 1106, a message handler 1108, and a transmission queue 1162. These components are in Fig. 11 are illustrated as separate units, with their respective functions described separately for ease of explanation. However, each of the components of node 1100 can be integrated or otherwise combined. Node 1100 may also include additional or alternative components, as described herein in relation to Fig. 11 have been shown and discussed.

[0192] Thus, the message handler 1108 can represent an encoder, a decoder, or a combination of an encoder and a decoder to facilitate the operation of the node 1100 according to any suitable communication protocols as discussed herein. The message handler 1100 can comprise any suitable number and / or any suitable type of components, an example of such components being given in Fig. Figure 11 is shown as an example and is not limited to this. For instance, the message handler 1108 may include a communication circuit 1108.1, which may be coupled to the data interface 1110 and thus to the associated network of interconnected nodes of the system as discussed herein. The data interface 1110 may therefore include any suitable design of components for this purpose, such as wires, buses, and / or respective terminals, connections, pins, etc.

[0193] The communication circuit 1108.1 can be implemented as any suitable hardware component that enables communication between node 1100 and other nodes within a group of nodes, as further discussed herein, via the data interface 1110. Thus, the communication circuit 1108.1 can send messages to and receive messages from the data interface 1110 according to any suitable number and / or type of communication protocols, such as those discussed herein. For this purpose, the communication circuit 1108.1 can include hardware components, software components, or combinations thereof, typically associated with components designed to perform data communications. For example, the communication circuit 1108.1 can include any suitable number of connectors, drivers, transmit and / or receive buffers, switches, and so on.

[0194] The processing circuit 1108.2 can comprise any number and / or any type of dedicated hardware components, such as a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), dedicated logic, and / or other circuitry, etc. The processing circuit 1108.2 can be implemented as one or more processors and / or cores capable of executing computer-readable instructions stored in the program memory 1108.3 to perform one of the various functions discussed in more detail in this section.

[0195] The program memory 1108.3 can comprise any suitable type of non-volatile, computer-readable medium, such as volatile memory, non-volatile memory, or combinations thereof. Insofar as the node 1100 implements software-based solutions to perform the various functions described in this section, this can be achieved, for example, by the processor circuit 1108.2 executing instructions stored in the program memory 1108.3.

[0196] The FIFO management block 1108.4 can represent any suitable combination of dedicated hardware, processors, an application-specific integrated circuit (ASIC), etc. Although in Fig. As illustrated in Figure 11 as a separate component, embodiments include the FIFO management block 1108.4, which is either separate from or integrated as part of the processing circuit 1108.2. Thus, insofar as the node 1100 implements hardware-based solutions to perform the various functions discussed in this section, this can be achieved, for example, via the processor circuit 1108.2 and / or the FIFO management block 1108.4.

[0197] The node 1100 can also include a transmission queue 1162, which in various embodiments can contain any suitable arrangement and / or configuration of any suitable type of memory designed to store messages or secured messages before their transmission. For example, the transmission queue 1162 can include a set of databases, which can include any suitable type of memory such as buffers (e.g., first-in-first-out (FIFO) buffers, as shown), a configuration of memory addresses, etc.

[0198] In one embodiment, messages can be stored at specific positions within the message transmission queue 1162 before their transmission. That is, the messages stored in the transmission queue 1162 can be the same as those subsequently transmitted to the network via the communication circuit 1108.1 using the data interface 1110. Thus, the messages stored in the transmission queue 1162 can be the same as those subsequently transmitted to the network via the communication circuit 1108.1 using the data interface 1110. Fig. The messages shown in Figure 11, which are stored in the FIFO buffers, comprise the entirety (e.g., the same message) of a message that is generated before its transmission. Alternatively, the messages stored in the FIFO buffers can be, as in Fig. Figure 11 shows that the contents and / or a section of a secured message to be transmitted later may be included, for example, a payload (e.g., if authentication and optional encryption are to be performed) or other suitable information such as one of the fields of the secured message to be transmitted. The messages stored in the FIFO buffers, as shown in Fig. The examples shown in 11 can represent any suitable content in such a scenario, which is then converted into a secure message during transmission, as discussed herein.

[0199] To give another example, the messages stored in the FIFO buffers can be, according to Fig. 11. Represent the content of unsecured messages that can be generated before transmission, for example, if security measures such as authentication and encryption are not implemented. In this scenario, the Fig. The messages shown in Figure 11, which are stored in the FIFO buffers, may also contain the entirety (e.g., the same message) of an unsecured message generated before its transmission, or any suitable portion thereof. The embodiments are described in this section primarily under the assumption that the messages are not secured using the various techniques described in Sections I and II above, in order to reduce the complexity of the security measures and their impact on the atomicity of the group of nodes; however, this is to be understood only as an example and not as a limitation.

[0200] In one embodiment, each FIFO buffer can be identified with a different message priority class, with the most urgent messages being transmitted using the messages stored in the next transmission slot for FIFO buffer 0, less urgent messages being transmitted using messages stored in the next transmission slot for FIFO buffer 1, and so on. Thus, the FIFO buffers can be configured as shown in Fig. Figure 11 shows how to store messages defined according to these different priority classes, such as those defined according to the IEEE 802.1Q or 802.1AS Time-Sensitive Networking Standards (TSN). Thus, with reference to Fig. As an example, Figure 11 shows a current transmission plan that defines scheduled message transmissions for node 1100 in the order of messages AH based on the priority class of each FIFO buffer and the messages stored in those buffers. It should be noted, however, that this assumes a higher-priority message (e.g., a message assigned to FIFO buffer 0) is not stored before the transmission of the last message H. If a new message is created and stored before the last message H is transmitted, the transmission of a scheduled lower-priority message can be postponed in favor of the higher-priority message transmission, although this scenario is not shown for the sake of simplicity.

[0201] Here too, the transmission of messages in this manner (i.e., using the messages stored in the message transmission queue 1162) can be carried out according to any suitable techniques, including known techniques. For example, as mentioned above, Ethernet standards such as 10BASE-T1S and 10BASE-T1L can define a secure message transmission schedule, and thus the node 1100 can perform message transmissions according to these or other suitable protocols that define such transmission scheduling schemes. Thus, the communication circuit 1108.1 can be designed to transmit the messages to the network according to any suitable transmission schedule by accessing the messages stored in the FIFO buffers and then transmitting the messages via any suitable communication protocol, such as an Ethernet communication protocol.Continuing this example, the transmission scheduling scheme can be implemented according to the Ethernet PHY Level Collision Avoidance (PLCA) scheme, which also defines an order of transmission slots (e.g., transmission possibilities) between the different nodes in a group. Thus, it is important to note that the PLCA scheme not only defines the prioritization of messages and a transmission plan based on this message prioritization, but also a transmission order for each node within a group, as discussed below.

[0202] Regardless of how the messages are scheduled for transmission, node 1100 can first generate the messages that are to be optionally secured and then transmitted as messages as discussed herein. Thus, the secure message handler 1108 is designed to generate one or more messages that are stored in the FIFO buffers of the transmission queue 1162 before being transmitted according to a suitable communication protocol. For example, the processing circuit 1108.2 can execute instructions stored in the program memory 1108.3 to generate each respective message transmission stored in the transmission queue 1162 according to the 10BASE-T1S or 10BASE-T1L communication protocol, for example. In this way, the processing circuit 1108.2. Each message is generated and stored in a respective FIFO buffer based on the priority class of the message to be transmitted before its transmission. The messages are then transmitted to the other nodes in the group according to the transmission plan (e.g., according to an Ethernet PLCA scheme) via the communication circuit 1108.1 and the data interface 1110.

[0203] After each message transmission, node 1100 can selectively delete the message from the respective FIFO buffer if predetermined conditions are met. For example, and as further discussed herein, node 1100 can delete the message stored in the FIFO buffer during its next transmission opportunity only if it is determined that every intended receiving node of the message has received the previously transmitted message. This functionality is discussed in more detail below and can be implemented via software, hardware, or a combination thereof. For example, the processing circuit 1108.2 can execute instructions stored in the program memory 1108.3 to enable this functionality. As another example, a portion or all of this functionality can be achieved via dedicated hardware, such as the FIFO management block 1108.4.

[0204] To determine which intended nodes have received a transmitted message, the embodiments described in this section can utilize a system in which nodes within a group use inline acknowledgments for received messages. In other words, each node within the same group is configured to enter coded values ​​into an acknowledgment field, which is then transmitted as part of each node's next scheduled message transmission. This acknowledgment field can include any suitable dedicated field of the messages communicated between the nodes in the group. For example, if an Ethernet-based protocol such as 10BASE-T1S or 10BASE-TI1L is implemented, the acknowledgment field can be part of an Ethertype field of an Ethernet communication frame, which may contain protocol information.The data contained in such an Ethertype field can, for example, serve to "concatenate" a message with other Ethertypes, such as MACsec. The use of Ethertypes in this way is well known, so further discussion is unnecessary.

[0205] The acknowledgment field can comprise any suitable number of bits, such as a bit array, with each number of bits being identified with a maximum number of nodes in a group. For example, the acknowledgment field can be a 32-bit field, alternatively referred to herein as the "AckTAG" field, thus supporting a group of up to 32 nodes with atomicity. Naturally, the acknowledgment field can have any suitable number of such bits and be a dedicated field, or it can form part of any suitable section of a communication frame in addition to or instead of the Ethertype field. For example, the acknowledgment field can be part of the header, payload, etc., of an Ethernet frame or any other message type according to any suitable communication protocol.

[0206] To support atomicity, node 1100 can include any suitable number of registers, which are in Fig. 11 are shown as stored in volatile memory 1106, this being understood as an example and not as a limitation. The various registers are in Fig. Figure 11 shows the ACKOUT register, ACKD register, and GROUP register. Each of the ACKOUT, ACKD, and GROUP registers can have a number of bits equal to those in the acknowledgment field (e.g., 32 bits). Additionally, in Fig. Figure 11 shows a single set of these registers for the sake of simplicity. However, the embodiments include node 1100, which is optionally part of more than one group of nodes. In such a case, node 1100 can store a separate set of the ACKOUT, ACKD, and GROUP registers for each such group, the functionality described herein for a single group being extended by replicating this process for each of these groups.

[0207] The contents of each of the ACKOUT, ACKD, and GROUP registers can include any suitable type of coded values, such as bit values, that can be updated when messages are transmitted and received between the different nodes in a group. The format and contents of the GROUP register can thus be a function of the specific implementation of how the contents of the ACKD register are updated. For example, the embodiments described in this section assume that the group of nodes is known to all participating nodes and that a coded value representing this grouping can be identified in the GROUP register, which is stored by each node in the same group.The GROUP register can therefore contain any suitable coded value that is the same for every node in the group relative to the current node, and is used to determine whether all nodes in a group have acknowledged a transmitted message. The contents of the GROUP register can thus remain the same during message communication within a group of nodes (relative to each node, but can represent a different coded value per node), but can be updated to indicate changes in group membership (e.g., when additional nodes are added to or removed from the group).

[0208] Additionally, the ACKOUT register contains any suitable type of coded values ​​(e.g., bit positions) that track each node's acknowledgment of received messages. These acknowledgments are then included in each node's next transmitted message to identify that the node has received the message from each other node. The ACKD register contains any suitable types of coded values ​​(e.g., bit positions) that track which nodes have transmitted their acknowledgment of a previously transmitted message (i.e., by recording their ACKOUT register contents). In other words, the contents of the ACKOUT register are updated by a receiving node to confirm that messages have been received from every other node in the group, thus indicating to each sending node that its previously transmitted message has been received.The contents of the ACKD register are updated by each node upon receiving the next transmitted message, which contains the updated contents of the ACKOUT register and thus indicates which nodes have acknowledged the last transmitted message from the sending node. Further detailed examples of the contents and updates of these registers are given below in relation to the... Fig. 13A-13D provided.

[0209] Thus, as discussed below, the messages transmitted from node 1100 to the network can include the acknowledgment field containing the contents of the ACKOUT register. Each node receiving the transmitted message then updates its own ACKOUT register to confirm that the message has been received, and this process continues for each node in the group as each node transmits its next message according to the transmission schedule. In this way, when a transmission node is scheduled to transmit its next message, the acknowledgment field received in the last message should indicate that every node in the group has received the last message, as explained in more detail below.

[0210] For example, and as discussed in more detail below, node 1100 can use the contents of the registers and the acknowledgment field in received messages to determine whether each node has received a transmitted message. Node 1100 can use this determination to selectively delete the message from a corresponding FIFO buffer during that node's next transmission opportunity. For example, processing circuit 1108.2 can be configured to selectively delete a message stored in a corresponding FIFO buffer after a message has been transmitted to the network. This selective deletion can be based, for example, on an indication of whether each of the other nodes has received the message.And as discussed above, this information can, for example, be based on the coded values ​​within the acknowledgment field contained in each message transmitted to the network by each of the other nodes that received the message.

[0211] For this purpose, reference is now made to the Fig. Reference is made to Figures 12A-12B, which illustrate block diagrams of a message queue management system based on received acknowledgments from other nodes, according to one embodiment of the disclosure. Here, too, the FIFO buffer management discussed in this section can be performed by the processing circuit 1108.2, which executes instructions stored in the program memory 1108.3, as a hardware component such as the FIFO management block 1108.4 or combinations thereof. Thus, both for Fig. 12A as well as for Fig. 12B assumes that there are a total of 6 nodes that are part of the same group. Of course, embodiments contain a larger or smaller number of nodes than shown, with 6 nodes being used for the sake of simplicity.

[0212] Thus, and with reference first to Fig. 12A are the FIFO buffers part of the transmission queue 1162 of node 1100, as in Fig. Figure 11 shows the FIFO buffers on the left side of the diagram. Fig. 12A represents an example configuration of the contents of the FIFO buffers prior to the transmission of a message A, which includes the highest priority and is therefore the next message to be transmitted according to the transmission schedule. Fig. Figure 12A also illustrates the content of several different messages transmitted to the network by the six different nodes. In this example, node 1100 represents node 1, and nodes 2-6 represent the nodes that receive the message and respond with an acknowledgment in their own messages. For example, the message A block represents the message first transmitted by node 1100, using the content of the corresponding message stored in the FIFO buffer. Thus, message A also contains an acknowledgment field, which is discussed in more detail below.

[0213] Continuing this example, each "RESP" block following message block A represents a message received by node 1100, which was transmitted to the network by each of the other 5 nodes after node 1100 transmitted message A. Each of these received messages contains an encoded value representing an acknowledgment by each respective node that message A was received, via the contents of the acknowledgment field, which in turn contains the contents of each responding node's ACKOUT register. As an example, and as discussed below, this acknowledgment could be a single bit value within the acknowledgment field, or some other predetermined value set for a predetermined bit position in the acknowledgment field corresponding to that of node 1100.

[0214] Thus, node 1100 receives messages from each of nodes 2-6, as shown, and collects the acknowledgment contained in each of these separate messages, as shown in Fig. Figure 12A shows that the message can be stored, for example, in the ACKD register. It is noted that the order in which messages from nodes 2-6 are received by node 1100 can be defined according to any suitable schedule. For example, Ethernet PLCA defines a "round-robin" order, which allows each of nodes 2-6 to respond in turn. Thus, the Fig. Figure 12A shows the sequence to simplify the explanation that this type of round-robin order is used.

[0215] Therefore, and using the order of the messages as in Fig. As shown in Figure 12A, as an example, once node 1100 receives the message from node 6, this marks the end of the current transmission round by each of the other nodes 2-6. Thus, node 1100 can now determine during its next transmission opportunity that each of nodes 2-6 has received the transmitted message A, which was transmitted during the last transmission opportunity. Therefore, node 1100, as shown in Figure 12A, can determine that each of nodes 2-6 has received the transmitted message A, which was transmitted during the last transmission opportunity. Fig. As shown in 12A, delete message A from the FIFO buffers, as shown on the right side of Fig. Figure 12A illustrates this. Furthermore, node 1100 can then transmit the next message B using the corresponding message from the FIFO buffer, which in this example is assumed to be the next message to be transmitted according to the transmission schedule. In this way, node 1100 is designed to delete message A stored in the FIFO buffer when the encoding value of the acknowledgment field, which is included in every message sent to the network by each of the other nodes 2-6, indicates that each of nodes 2-6 has received message A. In other words, node 1100 only deletes message A from the FIFO buffer when it is confirmed that every other receiving node of message A in the group has actually received the message.

[0216] In Fig. 12B shows the same FIFO buffers, nodes, and messages as above in relation to Fig. 12A shown and discussed. Fig. However, message 12B, transmitted by node 3, does not contain an encoded value confirming that message A has been received. In this case, node 1100 cannot verify whether each of nodes 2-6 has received message A and therefore does not delete message A at its next transmission opportunity, but instead retains message A in the FIFO buffer, as shown on the right side of Fig. Figure 12B shows this. This can also be determined via the coded value in the acknowledgment field of the message received by node 3, which, as mentioned above, does not indicate this acknowledgment. In other words, node 1100 retains message A in the FIFO buffer if the coded value of the acknowledgment field, which is included in every message sent to the network by nodes 2-6, indicates that at least one of nodes 2-6 did not receive message A.

[0217] If message A is held in the FIFO buffers in this way, node 1100 is thus configured to retransmit message A (e.g., via communication circuit 1108.1) to the network according to the transmission plan. This is described in Fig. Figure 12B illustrates this, where message A is retransmitted by node 1100 after messages have been received from each of nodes 2-6. It should be noted that node 1100 does not necessarily have to retransmit the message after having previously transmitted the same message. For example, although this is the case in Fig. While 12B shows that message A has high priority, this may not be true for a lower priority message. As an illustrative example, if the transmission of message A in Fig. If message 12B were replaced by one of the lower-priority messages, such as message B, then message A could be transmitted before message B is transmitted again, depending on the transmission schedule and the next message ready for transmission based on its relative urgency compared to other messages. In any case, for applications implementing a PLCA scheme, retaining the message in the FIFO buffer after transmission ensures automatic retransmission of the same message according to the transmission schedule.

[0218] If node 1100 detects that one or more of nodes 2-6 have not received a transmitted message, this can have various causes. For example, in Ethernet-based protocols, a node that receives the transmitted message might discard it, which can occur at a higher network layer. Another example is that a node receives the message, but its response is lost because it is also discarded. Thus, in the latter case, it is possible that a node receives and responds to the message transmitted by node 1100, but node 1100 does not receive the acknowledgment of this response.

[0219] In this scenario, a retransmitted message is a duplicate of the previously transmitted message, with a responding node receiving both messages. However, Ethernet-based standards such as MACsec also implement a packet number field (PN) that can be included in any transmitted message and is used to uniquely identify each message transmission to prevent retransmission attacks. Since the message stored in the FIFO buffer is retransmitted as the same message, the retransmitted message will have the same PN as the initially transmitted message. Consequently, a receiving node detects any subsequently received message as a duplicate and discards the message as part of the MACsec handling protocol.In this way, each retransmitted message has the same PN as a previously transmitted message, thus causing other nodes that received the initially transmitted message to identify the retransmitted message as a duplicate and discard the retransmitted message.

[0220] Additionally, the message can contain supplementary information that makes it easier for other nodes to identify the message as a duplicate. For example, node 1100 can generate additional coded values ​​as part of the message generation process. These values ​​can be included as part of a suitable dedicated field within the message, header, payload, etc. For example, the additional coded values ​​can be added as part of the acknowledgment field, as discussed herein. These additional coded values ​​can, for example, specify a FIFO numeric value that identifies in which FIFO buffer the retransmitted message was stored (e.g., 0-N, as in [reference]). Fig. (shown in Figure 11). Furthermore, the additional coded values ​​can indicate that the retransmitted message is a retransmission by using a sequence number. For example, the additional coded values ​​can include a predetermined number of bits that specify the message's FIFO buffer. The coded values ​​can also include a sequence number with any suitable number of bits, which, for example, can be a single bit value sufficient for this purpose. Thus, each time a node retransmits the same message, this sequence number can be toggled from its previous state. For example, a node can transmit an initial message with the sequence number set to 0, the next retransmission of the same message as 1, the next retransmission of the same message again as 0, and so on.In this way, the state of the sequence number bit can be used by the receiving node to identify the message as original or as a retransmission via such a binary specification.

[0221] Thus, each node can store an additional register or other suitable set of coded values ​​indicating the transfer state of every other node's FIFO. For example, node 1100 can store this information in the node FIFO state register, as shown in Fig. Figure 11 shows that the FIFO state register can thus have a size equal to the maximum number of nodes in the group multiplied by the maximum number of FIFO buffers (e.g., 128 bits for a system with 32 nodes and 4 FIFOs). A receiving node can therefore identify duplicates by assigning the additional coded values ​​and the sequence number contained in a received message to the receiving node's FIFO state buffer associated with the node sending the message. If the FIFO number and sequence number match the current FIFO state bit value corresponding to a retransmitted message, the receiving node can then discard the message as a duplicate. B. Examples of PLCA-based transmissions with atomicity

[0222] The Fig. Figures 13A-13D illustrate examples of the register contents of different nodes within the same group to support atomicity according to one embodiment of the disclosure. For each of the example scenarios, as they relate to the Fig. As discussed in 13A-13D, it is assumed that there are four nodes in a group, referred to herein as nodes 0-3. It is also assumed that each of these nodes 0-4 transmits its next scheduled message (e.g., the next message in the FIFO queue) according to a transmission slot based on a sequence or cycle of node transmissions. Again, such a schedule can be defined according to the PLCA scheme used in these examples. Thus, for each of the Fig. 13A-13D: Node 0 first transmits a message B0, then Node 1 transmits a message B1, then Node 2 transmits a message B2, and then Node 3 transmits a message B3. This represents a complete transmission cycle, with the process repeating when Node 0 either begins transmitting a new message C0 (if all other nodes have indicated that message B0 has been received) or retransmits the same message B0 (if it is determined that one of the other nodes 1-3 has not received message B0).

[0223] Additionally, the node embodiments described herein can function such that each node in the group is prompted to use its transmission capability, even if no application frames (e.g., messages) are to be sent. In such a case, a node can transmit the acknowledgment field as the message being transmitted. Such a message might, for example, include a header corresponding to a "null" frame, which, according to the ABP-PDU, has no EtherType. A receiving node in this scenario must not forward such null frames to the application, as they only contain the acknowledgment field data to facilitate the atomicity discussed herein.

[0224] The execution of the selective deletion of messages from the FIFO queue, as described above with respect to node 1100 in Fig. As described in Section 11, this is further discussed in detail with respect to node 0 as the first sending node in a transmission plan and can be identified with node 1100, as discussed, for example, herein. It should be noted, however, that each of the other nodes 1-3 can be configured in the same way as node 0. For example, each of nodes 0-3 can contain its own ACKOUT, ACKD, and GROUP registers, which are updated with respect to node 0 as discussed herein, and each of nodes 0-3 can also selectively delete messages from its own queues when each node is in turn to transmit its respective messages. In other words, each of nodes 0-3 can function in the same way as the others to ensure atomicity across the entire group of nodes.

[0225] Additionally and with regard to the in the Fig. Regarding the examples shown in Figures 13A-13D, it should be noted that, for the sake of simplicity, only a portion of the ACKOUT, ACKD, and GROUP registers, as well as the acknowledgment field "A," is shown. For example, the ACKOUT, ACKD, and GROUP registers, along with the acknowledgment field A, could have a number of bits equal to the maximum number of nodes that can be supported in a group, such as 32 bits, thus supporting atomicity for a group of up to 32 nodes. And, as discussed below, each bit in the acknowledgment field, as well as the ACKOUT, ACKD, and GROUP registers, can be identified by a predetermined bit position corresponding to each node in the group. Thus, for the sake of simplicity, in the Fig. 13A-13D only show the relevant section of the ACKOUT, ACKD and GROUP registers and the confirmation field A.

[0226] Additionally, it should be noted that the acknowledgment field, as well as the ACKOUT and ACKD registers, implement a node numbering scheme that starts at the MSB and continues to the LSB. The GROUP register contains a coded value across all nodes 0-3, selected according to the node numbering scheme. This has been done for the sake of simplicity, as these examples implement shift registers to update the contents of the ACKD registers, which are then compared to the contents of the GROUP register to determine whether all other nodes have received the sent message, as discussed below.

[0227] The specific encoding type implemented for each of the ACKOUT, ACKD, and GROUP registers, as well as for the Acknowledge field A, is provided for ease of explanation and shown as a non-restrictive and illustrative example. Additionally, the use of shift registers for the ACKD register is also provided as an example, not a restriction. Any suitable coded values ​​can be implemented according to an appropriate bit-encoding scheme to achieve the same results as those shown here with respect to the Fig. to achieve the same result as discussed in sections 13A-13D. For example, instead of using shift registers as discussed in detail below, the contents of any of the ACKOUT, ACKD, and GROUP registers can be updated using any suitable alternative techniques, such as toggling specific bit positions, to achieve the same result as the examples discussed in relation to the Fig. 13A-13D were discussed using the bit-shifting process.

[0228] Let us now turn Fig. Figure 13A shows the relevant contents of the ACKOUT, ACKD, and GROUP registers for node 0 at various stages of the PLCA transmission cycle. It is assumed that the initial transmission of message B0 occurs after an acknowledgment that nodes 1-3 have received a previously transmitted message A0 (not shown). This is indicated by the field "D" next to the contents of the ACKD register 1110 in the lower left section of Figure 13A. Fig. Figure 13A illustrates that the contents of the FIFO buffer (i.e., message A0) are deleted before message B0 is transmitted. Therefore, before message B0 is transmitted, the contents of the ACCD register are identical to the contents of the GROUP register, i.e., 1110, since the match between the contents of these two registers is used as the condition for deleting the previously transmitted message A0 from the FIFO queue of node 0. Thus, the contents of the GROUP register correspond to a mask, which, for the sake of simplicity, represents a coded value in this example that corresponds to the expected contents of the ACCD register when each of the other nodes 1-3 has acknowledged the transmission of the message from node 0 since the last transmission opportunity from node 0.

[0229] Furthermore, it should be noted that for the purposes of the Fig. Examples 13A-13D discussed how the encoding of ACKD and GROUP with the shift register implementation reflects the order of the PLCA cycle (and not the node number). Again, any suitable encoding and update schemes can be used for each node to track whether transmitted messages have been received from other nodes and to acknowledge the receipt of messages from other nodes. Consequently, in the Fig. In the examples shown in 13A-13D, the last shifted bit reflects the previous node in the PLCA cycle, and each bit is therefore "relative" to the current node. Consequently, and as mentioned above, this means that the coded value for the GROUP register in one node does not necessarily correspond to the same coded value contained in the GROUP register for another node. In any case, each node can still perform selective message deletion or retransmission, as discussed herein, by comparing the contents of its ACKD register with the contents of its GROUP register during its next transmission opportunity.

[0230] Thus, during its transmission slot, node 0 first compares the contents of the ACKD register with the GROUP register. If they are the same, node 0 deletes the last transmitted message, as this means that the other nodes 1-3 have acknowledged node 0's last transmitted message. Otherwise, node 0 keeps the message in the FIFO buffer and retransmits the last message, as discussed further here. In the event that the contents of the ACKD register and the contents of the GROUP register are the same, after deleting the previously transmitted message from the FIFO buffer, node 0 also creates the acknowledgment field to be transmitted with the message stored in the FIFO queue by copying the contents of the ACKOUT register into the acknowledgment field of the message to be transmitted (e.g., frame).This informs the other nodes 1-3 that their previously transmitted messages from the last transmission cycle (not shown) have been received. Node 0 then retains the message at least temporarily in the FIFO, e.g., until its next transmission slot, as discussed herein. It is acknowledged that comparing the contents of the ACKD and GROUP registers is valid as long as the encoding scheme for the ACKD and GROUP registers is the same (shifted bits vs. setting the bit position of a node).

[0231] This is in Fig. Figure 13A shows the initial content 0111 of the ACKOUT register of node 0. In this example, the ACKOUT register content uses a nomenclature indicating that nodes 1-3 in the group of nodes 0-3 must acknowledge the messages. In other words, to ensure atomicity within the group of nodes 0-3, the ACKOUT register tracks which of the other nodes must receive a message and be acknowledged by node 0, in the same way that each of the other nodes 1-3 must acknowledge the message transmitted by node 0. Thus, the ACKOUT register indicates that messages transmitted by nodes 1, 2, and 3 must be acknowledged, but not by node 0, since node 0 is the same node. When copying the contents of the ACKOUT register into the acknowledgment field A in the B0 message, as shown in Figure 13A, the ACKOUT register content is automatically updated. Fig. As shown in Figure 13A, the contents of the ACKOUT register are cleared to 0000 because node 0 is the first node in the transmission cycle and has just confirmed receipt of the transmitted messages from the other nodes 1-3 by copying the contents of the ACKOUT register into the acknowledgment field that is transmitted in message B0.

[0232] After transmitting message B0, node 0 then updates the contents of the ACKD register, as shown in Fig. Figure 13A shows the contents of the acknowledgment field, i.e., 0111, which is also the previous state of the ACKOUT register. This can be achieved, for example, by performing a bit-shift operation to insert a 0 bit on the MSB side of the ACKOUT register, as shown. Since each of the other nodes 1-3 transmits its own messages B1, B2, B3 during its own transmission slots, and each node performs a similar process, it follows that the acknowledgment field indicates the contents of each node's ACKOUT register. Since, in turn, each bit position in the acknowledgment field transmitted by the other nodes 1-3 corresponds to one of the nodes 0-3, each of the nodes 1-3 can acknowledge receipt of message B0 by setting the leftmost bit in the transmitted acknowledgment field to 1, as shown. Fig. Figure 13A shows that, for example, the acknowledgment field of each received message can contain a "D-th" bit corresponding to node D, which requested acknowledgment of the previously transmitted message, which is the leftmost bit in the Fig. In example 13A, the D-th bit corresponds to node 0. However, the position of the D-th bit within the acknowledgment field is a different bit position for the other nodes 1-3, which these other nodes use to also determine that their transmitted messages have been acknowledged by other nodes.

[0233] Thus, and using node 0 as an example, when node 0 receives each of the messages B1, B2, B3 from the other nodes 1-3, it shifts this D-th bit (the leftmost bit in this example, corresponding to the bit position for receiving node 0) to the MSB side of the ACKD register, as shown in Fig. Figure 13A shows that if a valid message is missing for a given PLCA transmit slot, node 0 may assume that the acknowledgment field contains a predetermined set of values, such as all zeros (i.e., no acknowledgments). Thus, the initial contents of the ACKD register change from 0111 to 1011, then to 1101, and finally to 1110 once the last message B3 is received, indicating that node 3 has acknowledged receipt of message B0.

[0234] Node 0 can then compare the contents of the ACKD register at the end of the transmission cycle with the coded values ​​represented in the GROUP register, which should match if all other nodes 1-3 have acknowledged receipt of message B0. In this case, since the contents of the ACKD register match those of the GROUP register, node 0 can delete the message from the FIFO queue and transmit the next message C0. In this way, node 0 (e.g., via message handler 1108) is configured to determine whether each of the other nodes 1-3 has received message B0 by checking, for each message B1, B2, and B3 transmitted to the network, whether a bit in the acknowledgment field with a predetermined bit position, identified with node 0, indicates an acknowledgment of message B0 transmitted to the network.

[0235] Similarly, when node 0 receives each of the messages B1, B2, and B3 from nodes 1, 2, and 3 respectively, it updates the contents of its ACKOUT register as shown to acknowledge receipt of each message B1, B2, B3 by setting the bit position corresponding to each of nodes 1-3 to "1" upon receipt. The transmitting nodes 1-3 can be identified in this way, for example, by using encoded data in the message, such as the message source address (SA). Thus, node 0 can refer from the SA to any suitable correlation of nodes to SAs, such as a table, which may be stored in non-volatile memory 1104 or volatile memory 1106. Alternatively, node 0 can identify the node transmitting the message based on the sequence of the PLCA transmit slots.

[0236] Thus, and with continued reference to Fig. As an example in 13A, after receiving message B1 from node 1, node 0 sets the contents of the ACKOUT register to 0100, where the position of bit "1" corresponds to node 1 (i.e., the bit positions in the ACKOUT register correspond from MSB to LSB to node 0, node 1, node 2, and node 3). This can be achieved, for example, by node 0 searching for the transmitting node 1-3, which is denoted S in this example. Thus, node 0 sets the "S-th" bit of the ACKOUT register to confirm to node S (in this example, node 1) that message B1 has been received. This process is repeated by node 0 to set the bits of the ACKOUT register to confirm the receipt of each of the messages B1, B2, and B3.Thus, the end result in this example is that the content of the ACKOUT register is 0111 when the last message in the transmission cycle is received and acknowledged by node 0, at which point the transmission cycle is restarted at node 0.

[0237] Let us now turn Fig. Figure 13B shows the contents of the ACKOUT and ACKD registers for each of the nodes 0-3 in the group during the various stages of the PLCA transmission cycle. As discussed above with respect to node 0, each of the nodes 0-3 can update the contents of its ACKOUT register when messages are received from other nodes to acknowledge receipt of those messages. The contents of the ACKOUT register are copied into the acknowledgment field in each message transmitted within the transmission cycle, as shown. For example, node 0 transmits message B0, which is received by each of the nodes 1-3, which may contain the acknowledgment field 0111. Consequently, the ACKOUT register of nodes 1-3 is updated so that the MSB, which in turn has a position corresponding to node 0, is updated from a "0" to a "1".This process is then repeated for each node in the group throughout the entire transmission cycle, as shown in . Fig. Figure 13B shows this. Thus, each node in the group is designed to acknowledge the receipt of messages from other nodes in the group by using the acknowledgment field to update its own ACKOUT field, which is then copied into the acknowledgment field and included as part of the next message transmitted by each node. In this way, the use of the acknowledgment field can serve as an intrinsic function of each node in the group to acknowledge the receipt of messages from other nodes.

[0238] Additionally, each of nodes 0-3 can update the contents of its ACKD register when it receives messages from other nodes indicating that their last transmitted message has been acknowledged by those nodes. For example, and as in Fig. As shown in Figure 13B, each node updates the contents of its ACKD register when messages are received from other nodes, based on the contents of the acknowledgment field in each received message, as discussed above for node 0. Furthermore, at the end of the transmission cycle, i.e., when each node is ready to transmit its next scheduled message, that node can compare the contents of its ACKD register with the contents of its GROUP register, as shown. If the contents match for each node, each node can, during its current transmission slot, delete the message from the FIFO queue corresponding to the previous transmission slot. This is done in each case in Fig. 13B is marked by the notation "D", after which each node transmits a new message from a different FIFO queue. The ACKD and ACKOUT registers are then reset to their predetermined values ​​of 0111 and 0000 respectively, as shown above. Fig. 13A is specified for node 0.

[0239] If a node does not receive confirmation from all other nodes in the group that its previously transmitted message has been received, the node can keep the message in the FIFO buffer, which is then retransmitted. Such scenarios are discussed further below in relation to the Fig. 13C and Fig. 13D discussed in more detail.

[0240] Fig. Figure 13C illustrates an example scenario that follows the same PLCA transmission sequence as in the Fig. 13A and Fig. Figure 13B shows that node 0 is referenced as the first transmission node in this sequence. In the Fig. In the example shown in Figure 13C, however, node 2 does not receive message B0 transmitted by node 0. This could be because message B0 was lost, corrupted, etc. Thus, the ACKOUT registers of nodes 1 and 3 indicate that message B0 was received from node 0, but node 2 does not update its ACKOUT register accordingly. When node 2 transmits message B2, the content of its ACKOUT register, which is copied into the acknowledgment field, is "0101". That is, the leftmost bit position, which is identified with node 0, is a 0 instead of a 1, unlike nodes 1 and 3, which received message B0.

[0241] When node 0 receives message B2 from node 2, the contents of the ACKD register at node 0 are shifted bitwise to the right, with a 0 instead of a 1, resulting in 0101. Since the additional message B3 is received from node 3, this causes the ACKD register at node 0 to contain the value 1010 instead of the value 1110 encoded in the GROUP register. When node 0 is ready to transmit a message at its next transmission opportunity, the comparison of the GROUP register and the ACKD register results in a mismatch for node 0, and thus node 0 does not erase the previously transmitted message. Instead, node 0 retransmits message B0, as shown. This is denoted in the figures as "R" (retransmit) in contrast to the "D" (erase) notation.It should be noted that other nodes 1-3 can delete their messages and transmit new messages, since only node 2 has not received message B0 from node 0.

[0242] The process of node 0 retransmitting message B0 in this manner can be repeated until node 2 confirms receipt of message B0 through the content of the acknowledgment field in a subsequent message transmitted by node 2. Otherwise, the process can be repeated until other intervening actions are performed, such as a notification from components of the parent system that node 2 has been taken offline. This can be implemented, for example, by an error counter assigned to each node, which can be stored in the volatile or non-volatile memory of each node and indicates the number of sequentially failed acknowledgments.This can cause the coded value for the GROUP register to be updated for each node to indicate which other nodes are online, with subsequent message acknowledgment performed by comparing the ACKD register with the updated contents of the GROUP register. Again, the shift register execution of the ACKD register depends on this, as described in relation to... Fig. Sections 13A-13D discuss how the contents of the GROUP register in a node depend on the node's placement within the PLCA sequence. In this case, each node can contain its own coded value in the GROUP register to reflect its placement within the PLCA cycle.

[0243] With reference to Fig. Figure 13D shows a scenario in which node 1 transmits a message B1, but the message is not received by any of the other nodes 0, 2, or 3. This could be due, for example, to bus noise corrupting the message and preventing it from reaching the other nodes. In this scenario, nodes 0, 2, and 3 do not update their ACKOUT registers to indicate that message B1 has been received, and thus the bit position in the ACKOUT register corresponding to node 1 (the second bit from the left, as shown in Figure 1) remains unchanged. Fig. (as shown in Figure 13D) corresponds to a value of 0. Thus, each of nodes 2, 3, and 0 retransmits its respective messages A2, A3, and B0 as retransmissions in this scenario of the previously transmitted messages, with an acknowledgment field indicating the contents of the ACKOUT register before transmission in each case. That is, each of nodes 2, 3, and 0 moves the 0 values ​​from the acknowledgment field in each of the subsequently received messages A2, A3, and B0 into its respective ACKD registers, causing the nodes to retransmit their messages because the contents of the ACKD register do not match their GROUP register, indicating that not all nodes have acknowledged their previously transmitted message. Additionally, node 1 also retransmits the lost message B1 because node 1's ACKD register contains the value 0000, indicating that no other nodes have acknowledged the previously transmitted message B1. C. An example process flow

[0244] Fig. Figure 14 illustrates an example process flow according to one embodiment of the disclosure. With reference to Fig. 14. The process flow 1400 may comprise a procedure that is executed by and / or otherwise associated with any suitable number and / or type of components, such as one or more processors (processing circuits), hardware components, executed instructions (e.g., software components), or combinations thereof. The components may be associated with one or more components of node 1100, as discussed herein. The flow 1400 may contain alternative or additional blocks, which are omitted for brevity in the Fig. 14 are not shown, and can be carried out in a different order than shown. For example, additional messages can be generated and stored in parallel (e.g., simultaneously with) the transmission of other messages according to the transmission plan, although the generation and storage of messages is shown before transmission for the sake of simplicity. Furthermore, some blocks may be optional. Additionally, all statements made regarding the operation of node 1100 are also applicable to the process flow as described herein with respect to Fig. 14 is being discussed.

[0245] As in Fig. As shown in Figure 14, the process flow 1100 can be implemented via any of the nodes discussed herein, such as any of the nodes contained in the system 300, such as in Fig. 3 is shown when a message transmission is performed.

[0246] Process flow 1400 begins with the generation (block 1402) of one or more messages. This can, for example, include the generation of unsecured messages, which are subsequently converted into secure messages for transmission, as discussed herein. Alternatively, it can include the generation (block 1402) of one or more messages as secure messages. As another example, it can include the generation (block 1402) of one or more messages as unsecured messages, which are then transmitted as unsecured messages. In both cases, the generation of the messages can include the generation of the coded values ​​of the acknowledgment field, as discussed above.

[0247] Process flow 1400 further includes storing (block 1404) each of the messages in a transmission queue, which may, for example, include transmission queue 1162. This may also include storing the generated messages in a FIFO buffer based on the priority class of each message, as discussed herein.

[0248] Process flow 1400 further includes the transmission (block 1406) of the next message stored in the transmission queue according to a suitable transmission plan. The transmitted message may include the acknowledgment field, as discussed above.

[0249] The process flow 1400 further includes determining (block 1408) whether an acknowledgment has been received from the other nodes to which the message was transmitted (block 1406). This can, for example, include determining whether the message received by each of the other nodes contains an encoded value representing an acknowledgment (e.g., the contents of the node's ACKOUT register) that the message has been received, as described above in relation to the Fig. 12A and Fig. 12B, for example, is discussed.

[0250] If it is determined that an acknowledgment has been received from the other nodes to which the message was transmitted, then process flow 1400 continues with block 1412. In this case, process flow 1400 includes deleting (block 1412) the message stored in the buffer. Furthermore, after deleting (block 1412) the message in this way, process flow 1400 includes transmitting (block 1406) the next message according to the transmission schedule.

[0251] However, if it is determined that no acknowledgment has been received from the other nodes to which the message was transmitted, then process flow 1400 continues with block 1410. In this case, the message is held in the buffer (block 1410). Process flow 1400 then also includes the transmission (block 1406) of the next message according to the transmission plan. This may involve retransmitting (block 1406) the message contained in the buffer as the next transmitted message or as a subsequently transmitted message based on the message priority, as discussed herein. EXAMPLES

[0252] The techniques of this revelation can also be described in the following examples. Example 1. A node in a system of interconnected nodes designed to communicate over a network, wherein the node comprises: a plurality of buffers, each of the plurality of buffers being assigned a different message priority class; a processing circuit designed to generate and store a message in one of the plurality of buffers based on a message priority class of the message;and a communication circuit designed to transmit the message to the network using a transmission plan according to an Ethernet PHY-level collision avoidance (PLCA) scheme, wherein the processing circuit is designed to selectively delete the message stored in one of the plurality of buffers after the message has been transmitted to the network, based on an indication of whether each of a plurality of other nodes coupled to the network has received the message, wherein the indication is based on an encoded value of an acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes. Example 2. The node from Example 1, where the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the multitude of other nodes indicates an acknowledgment. Example 3. The node from any combination of Examples 1-2, wherein the processing circuit is designed to delete the message stored in one of the plurality of buffers when the coded value of the acknowledgment field contained in each respective message sent to the network by each of the plurality of other nodes indicates that each of the plurality of other nodes has received the message. Example 4. The node of any combination from Examples 1-3, wherein the processing circuit is designed to retain the message stored in one of the plurality of buffers if the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes indicates that at least one of the plurality of other nodes has not received the message. Example 5. The node of any combination from Examples 1 to 4, wherein the communication circuit is designed to retransmit the message to the network according to the transmission plan if the message is held in one of the multiple buffers. Example 6. The node of any combination from Examples 1 to 5, wherein the retransmitted message causes nodes from the multitude of other nodes that received the message to identify the retransmitted message as a duplicate and discard the retransmitted message. Example 7. The node of any combination of Examples 1-6, wherein the retransmitted message contains one or more coded values ​​indicating (i) one of the plurality of buffers in which the retransmitted message has been stored, and (ii) that the retransmitted message is a retransmission, and wherein the retransmitted message causes nodes from the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate by means of the one or more coded values. Example 8. Node of any combination of Examples 1-7, wherein the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes comprises a bit sequence, and wherein the processing circuit is designed to determine whether each of the plurality of other nodes has received the message by determining, for each respective message transmitted to the network by each of the plurality of other nodes, whether a bit in the bit sequence with a predetermined bit position identified with the node indicates an acknowledgment of the message transmitted by the node to the network. Example 9. The node of any combination of Examples 1-8, wherein: the acknowledgment field contained in each respective message transmitted to the network by each respective node comprises a bit sequence containing a plurality of bits, a predetermined bit position of each of the plurality of bits is identified with a respective of the plurality of other nodes, and the coded value of the acknowledgment field corresponds to a predetermined bit position identified with the node. Example 10. The node of any combination of Examples 1-9, wherein the communication circuit is designed to transmit the message to the network via an Ethernet communication protocol. Example 11. The node of any combination of Examples 1 to 10, wherein the Ethernet protocol includes a 10BASE-T1S or a 10BASE-T1L Ethernet protocol. Example 12. Computer-implemented procedure for a node in a system of interconnected nodes designed to communicate over a network, wherein the procedure comprises: generating a message; storing the message in one of several buffers based on a message priority class of the message; transmitting the message to the network using a transmission plan according to an Ethernet PHY-level collision avoidance (PLCA) scheme; and selectively deleting, after the message has been transmitted to the network, the message stored in one of the plurality of buffers, based on an indication of whether each of a plurality of other nodes coupled to the network has received the message, wherein the indication is based on an encoded value of an acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes. Example 13. Procedure according to Example 12, wherein the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the multitude of other nodes indicates an acknowledgment. Example 14. Procedure according to any combination of Examples 12-13, wherein selective deletion includes: deleting the message stored in one of the plurality of buffers when the coded value of the acknowledgment field contained in each respective message sent to the network by each of the plurality of other nodes indicates that each of the plurality of other nodes has received the message. Example 15. Procedure according to any combination of Examples 12-14, wherein selective deletion includes: retaining the message stored in one of the multiple buffers if the coded value of the acknowledgment field contained in each respective message sent to the network by each of the multiple other nodes indicates that at least one of the multiple other nodes has not received the message. Example 16. Procedure according to any combination of Examples 12-15, further comprising: when the message is held in one of the plurality of buffers, retransmission of the message to the network according to the transmission plan. Example 17. Method according to any combination of Examples 12 to 16, wherein the retransmitted message causes nodes from the plurality of other nodes that received the message to identify the retransmitted message as a duplicate and discard the retransmitted message. Example 18. The node of any combination of Examples 12-17, wherein the retransmitted message contains one or more coded values ​​indicating (i) one of the plurality of buffers in which the retransmitted message has been stored, and (ii) that the retransmitted message is a retransmission, and wherein the retransmitted message causes nodes from among the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate by virtue of the one or more coded values. Example 19. A method according to any combination of Examples 12 to 18, wherein the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes comprises a bit sequence, and further comprising: determining whether each of the plurality of other nodes has received the message by determining, for each respective message sent to the network by each of the plurality of other nodes, whether a bit in the bit sequence with a predetermined bit position identified with the node indicates an acknowledgment of the message sent to the network by the node. Example 20. Method according to any combination of Examples 12-19, wherein: the acknowledgment field contained in each respective message transmitted to the network by each respective message comprises a bit sequence containing a plurality of bits, a predetermined bit position of each of the plurality of bits is identified with a respective of the plurality of other nodes, and the coded value of the acknowledgment field corresponds to a predetermined bit position identified with the node. Example 21. Method according to any combination of Examples 12 to 20, wherein transmitting the message to the network includes: transmitting the message to the network via an Ethernet communication protocol. Example 22. Method according to any combination of Examples 12 to 21, wherein the Ethernet protocol comprises a 10BASE-T1S Ethernet protocol or a 10BASE-T1L. CONCLUSION

[0253] Although specific embodiments have been illustrated and described herein, it should be understood that any arrangement designed to achieve the same purpose can replace the specific embodiments shown. This disclosure is intended to encompass all adaptations or variations of different embodiments. Combinations of the above embodiments and other embodiments not specifically described herein will be obvious to the person skilled in the art upon review of the above description.

[0254] It should also be noted that specific terms used in the description and claims may be interpreted in a very broad sense. For example, the terms "circuit" or "circuit arrangement" used herein are to be interpreted in a sense that includes not only hardware, but also software, firmware, or any combination thereof. The term "data" may be interpreted to include any form of representational data. The term "information" may include, in addition to any form of digital information, other forms of information representation. The term "entity" or "unit" may, in embodiments, include any device, apparatus, circuit, hardware, software, firmware, chips or other semiconductors, as well as logical units or physical implementations of protocol layers, etc.Furthermore, the terms "coupled" or "connected" can be interpreted in a broad sense that includes not only direct but also indirect coupling.

[0255] It should also be noted that the methods disclosed in the description or in the claims may be implemented by a device which has means for carrying out each of the respective steps of these methods.

[0256] Although specific embodiments have been illustrated and described herein, it will be clear to the person skilled in the art that a multitude of alternative and / or equivalent embodiments can replace the specific embodiments shown and described without departing from the scope of this disclosure. This disclosure is intended to cover all adaptations or variations of the specific embodiments discussed herein.

Claims

[1] Node in a system of interconnected nodes designed to communicate over a network, wherein the node comprises: a multitude of buffers, each of which is assigned to a different message priority class; a processing circuit designed to generate and store a message in one of the multiple buffers based on a message priority class of the message; and a communication circuit designed to transmit the message to the network using a transmission plan according to an Ethernet PHY Level Collision Avoidance (PLCA) scheme, wherein the processing circuit is designed to selectively delete the message stored in one of the plurality of buffers after the message has been transmitted to the network, based on an indication of whether each of a plurality of other nodes coupled to the network has received the message, wherein the indication is based on an encoded value of an acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes. [2] Node according to claim 1, wherein the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes indicates an acknowledgment. [3] Node according to claim 1 or 2, wherein the processing circuit is designed to delete the message stored in one of the plurality of buffers when the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes indicates that each of the plurality of other nodes has received the message. [4] Node according to one of the preceding claims, wherein the processing circuit is designed to retain the message stored in one of the plurality of buffers when the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes indicates that at least one of the plurality of other nodes has not received the message. [5] Node according to claim 4, wherein the communication circuit is designed to retransmit the message to the network according to the transmission plan if the message is retained in one of the plurality of buffers. [6] Node according to claim 5, wherein the retransmitted message causes nodes from the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate and to discard the retransmitted message. [7] Node according to claim 6, wherein the retransmitted message contains one or more coded values ​​indicating (i) one of the plurality of buffers in which the retransmitted message has been stored, and (ii) that the retransmitted message is a retransmission, and wherein the retransmitted message causes nodes from the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate by means of the one or more coded values. [8] Node according to any of the preceding claims, wherein the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes comprises a bit sequence, and wherein the processing circuit is designed to determine whether each of the plurality of other nodes has received the message by determining, for each respective message sent to the network by each of the plurality of other nodes, whether a bit in the bit sequence with a predetermined bit position identified with the node indicates an acknowledgment of the message transmitted by the node to the network. [9] Knot according to any one of the preceding claims, wherein: the acknowledgment field, which is included in each respective message transmitted from each respective node to the network, comprises a bit sequence containing a large number of bits, a predetermined bit position of each of the multitude of bits is identified with a respective other node, and The coded value of the confirmation field corresponds to a predetermined bit position that is identified with the node. [10] Node according to any of the preceding claims, wherein the communication circuit is designed to transmit the message to the network via an Ethernet communication protocol. [11] Node according to claim 10, wherein the Ethernet protocol comprises a 10BASE-T1S or a 10BASE-T1L Ethernet protocol. [12] Computer-implemented method for a node in a system of interconnected nodes designed to communicate over a network, the method comprising: Generating a message; Storing the message in one of a variety of buffers based on a message priority class of the message; Transmitting the message to the network using a transmission plan according to an Ethernet PHY-level collision avoidance scheme (PLCA); and Selective deletion, after transmission of the message to the network, of the message stored in one of the multiple buffers based on an indication of whether each of a multiple of other nodes connected to the network has received the message, the information is based on a coded value of an acknowledgment field contained in each respective message transmitted to the network by each of the multitude of other nodes. [13] Method according to claim 12, wherein the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes indicates an acknowledgment. [14] Method according to claim 12 or 13, wherein the selective deletion comprises: Delete the message stored in one of the multiple buffers when the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the multiple other nodes indicates that each of the multiple other nodes has received the message. [15] Method according to any one of claims 12 to 14, wherein the selective deletion comprises: Retain the message stored in one of the multiple buffers if the coded value of the acknowledgment field contained in each respective message transmitted to the network by each of the multiple other nodes indicates that at least one of the multiple other nodes has not received the message. [16] The method of claim 15, further comprising: If the message is retained in one of the multiple buffers, the message is retransmitted to the network according to the transmission plan. [17] Method according to claim 16, wherein the retransmitted message causes nodes from the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate and to discard the retransmitted message. [18] Node according to claim 17, wherein the retransmitted message contains one or more coded values ​​indicating (i) one of the plurality of buffers in which the retransmitted message has been stored, and (ii) that the retransmitted message is a retransmission, and wherein the retransmitted message causes nodes from the plurality of other nodes that have received the message to identify the retransmitted message as a duplicate by means of the one or more coded values. [19] Method according to any one of claims 12 to 18, wherein the acknowledgment field contained in each respective message transmitted to the network by each of the plurality of other nodes comprises a bit sequence, and further comprising: Determine whether each of the multitude of other nodes has received the message by determining, for each respective message transmitted to the network by each of the multitude of other nodes, whether a bit in the bit sequence with a predetermined bit position identified with the node indicates an acknowledgment of the message transmitted by the node to the network. [20] Method according to any one of claims 12 to 19, wherein: the acknowledgment field, which is included in each respective message transmitted from each respective node to the network, comprises a bit sequence containing a large number of bits, a predetermined bit position of each of the multitude of bits is identified with a respective other node, and The coded value of the confirmation field corresponds to a predetermined bit position that is identified with the node. [21] Method according to any one of claims 12 to 20, wherein transmitting the message to the network comprises: Transmitting the message to the network via an Ethernet communication protocol. [22] Method according to claim 21, wherein the Ethernet protocol comprises a 10BASE-T1S Ethernet protocol or a 10BASE-TI1L protocol.

Images