Node in system of interconnected nodes communicating over network and corresponding method

Abstract

A node in a system of interconnected nodes communicating over a network and a corresponding method are provided. The described techniques address issues related to compatibility and cost effectiveness of in-vehicle networks. For example, the described techniques may utilize a secure Ethernet-based protocol without the need to exchange separate key agreement messages, and thus meet the strict start time requirements of a real-time control system. Further, a member tracking solution may be implemented in which each node within a group of members may request or "challenge" other nodes of the same group to verify their online state, and the online state may be maintained over time. Finally, a transport queue management process is described that deletes queued messages only upon determining that each intended receiving node has received a message, thereby providing atomicity. The reserved queuing message may then be retransmitted according to the transmission schedule.

Description

Technical Field

[0001] This disclosure generally relates to the use of secure data communication, and more specifically, to the use of secure communication based on a real-time bus key distribution system that utilizes locally stored key counter values ​​to eliminate the need for dedicated key negotiation messages. This disclosure also relates to using real-time member groups to provide an additional layer of security by adding data to scheduled secure messages for transmission between nodes within the member group, without using dedicated secure messages for this purpose. Furthermore, this disclosure relates to the use of responses from nodes within the group to manage message transmission queues and achieve atomic processing within such groups. Background Technology

[0002] Controller Area Network (CAN), Controller Area Network Flexible Data Rate (CAN FD), Controller Area Network Very Long (CAN XL), and Ethernet communication protocols are currently the main networks / protocols used for automotive in-vehicle communication, utilizing the accompanying electrical / electronic (E / E) architecture. However, these conventional methods have various drawbacks, particularly regarding the communication overhead required for distributing shared session keys used for authenticating, encrypting, and decrypting secure messages within the network.

[0003] Furthermore, common communication protocols such as CAN, CAN FD, and CAN XL utilize a concept known as "atomic broadcasting," a communication technique that ensures each receiving node actually receives the message. For example, CAN can implement an error mechanism so that when a node sees an error, it destroys the frame. The transmitter then retransmits the frame, and this process can be repeated until all nodes have received the frame. This feature is a very useful property for promoting robust systems; however, designing such systems using higher-level software is very difficult because such systems are typically complex, resource-intensive, and slow. Therefore, it is noted that CAN-based protocols often use hardware implementations to support this type of atomic broadcasting at lower network layers and rely on the acknowledgment (ACK) bit field in the transmitted frame, which is modified by the receiver of the secure message.

[0004] However, attempts to incorporate atomic broadcast functionality into Ethernet-based protocols are insufficient because Ethernet-based nodes simply discard bad frames (e.g., those with failed CRC checks) and allow higher-level software applications to resolve the issue. Other attempts to incorporate atomic broadcast functionality into Ethernet-based architectures include using High Availability Seamless Redundancy (HSR) topologies. However, each of these Ethernet-based atomicity solutions either focuses on higher-level software applications or relies on specific ring-based architectures and message redundancy, introducing significant complexity, time-based limitations, and cost, making them less suitable for real-time control system applications requiring fast and robust measurements. Summary of the Invention

[0005] Similarly, conventional communication protocols and electrical / electronic (E / E) architectures have various drawbacks, particularly regarding the processing power, overhead, and time required to generate the shared keys needed to ensure trusted and secure communication across the network. For example, a typical E / E architecture for transmitting secure messages, as further discussed herein, may include a system of interconnected “nodes,” which can represent any suitable type of device within a network configured to transmit and receive secure messages, such as sensors, electronic control units, actuators, electromechanical components, etc. The number of interconnected nodes in such a system can be on the order of tens or hundreds, and each node can transmit secure messages to and receive secure messages from other nodes within the interconnected system.

[0006] The underlying network supporting the interconnected node system can be implemented as part of any suitable type of system utilizing secure communication, such as, for example, in-vehicle networks, industrial-based networks such as those used in production lines, etc. For instance, an interconnected node system could include groups of nodes that communicate securely via a connected broadcast bus to facilitate real-time control systems. Such real-time control systems can utilize the communication of sensor data, control data, or other data, and may include components that could represent significant safety risks in the event of a failure. Therefore, specific operating parameters need to be considered to ensure robust and secure communication within such systems.

[0007] For example, any node in such a real-time control system could be reset at any time (e.g., if an internal watchdog timer is triggered), and all data in the node's volatile memory (RAM) would be lost. Furthermore, after a node starts up (or restarts), it must be able to resume communication very quickly—within milliseconds—to receive messages from other nodes on the bus and send messages to other nodes on the bus (e.g., sensor data, actuator commands, etc.). Additionally, messages must be protected from tampering by attackers, and messages may also need to be encrypted to prevent attackers from seeing their contents. Nodes should also be protected against replay attacks (i.e., an attacker obtains a copy of a message sent on the bus and then retransmits it later in an attempt to induce the receiving node to take action against it). Furthermore, the cryptographic system used for secure message transmission and reception must change the key when it becomes "exhausted" (i.e., has been used too frequently), and each group of nodes participating in secure communication needs to agree on the same value for replacing the key.

[0008] Therefore, it should be noted that secure messages are generated by the nodes before transmission using one or more shared keys, which may also be referred to as shared secrets or secret keys, and typically remain unchanged throughout the node's lifetime. The shared keys are usually stored in each node's local memory and provided as input to a cryptographic block that implements cryptographic functions such as key derivation functions (KDFs). The cryptographic block also receives input in the form of a counter value that can vary over time, as well as any other suitable input used to ensure the uniqueness of the key generated in this manner. Thus, for each set of inputs including at least the shared key and the counter value, the cryptographic block can output one or more session keys, which can be used for authentication and / or encryption of the secure message. Therefore, when symmetric encryption is implemented, the node receiving the secure message utilizes the same session key as the node transmitting the secure message.

[0009] However, shared keys and session keys should not be transmitted unencrypted (i.e., in plaintext), as doing so exposes the pre-shared key to potential attackers, posing a significant security risk. Therefore, to prevent the plaintext transmission of keys, conventional communication protocols and E / E architectures utilize a system called key negotiation. This process ensures that nodes participating in secure communication agree to use the same session key (via a key negotiation protocol), and that when the key is exhausted or needs to be updated, the nodes agree on a new session key. Therefore, a node that has restarted and forgotten all the details of its previous key cannot replay messages using the old session key.

[0010] Therefore, monotonically increasing sequence numbers are typically used to prevent message replay without a change in the key; alternatively, this could be called a freshness value (FV). This is implemented via the current Ethernet standard MKA (MACsec key negotiation) protocol. However, this introduces problems when implemented as part of a secure real-time control system. Specifically, the protocol takes too long to complete, and restarted nodes must wait too long to establish consensus on the new session key before they can receive and send secure messages again (i.e., a large number of messages must be exchanged between a set of nodes and a central key server).

[0011] For example, now go to Figure 1A and Figure 1B Blocks A, B, C, and D represent high-priority frames according to a key negotiation communication protocol (e.g., MACsec). In the event of a communication interruption, such as when a node is reset, key messages need to be transmitted from every node in the system to the other nodes to ensure synchronization among all nodes in the group. Therefore, Figure 1AThe bottom block represents the key distribution message when the security message is of low priority. In this case, it shows that secure communication cannot occur between nodes B, C, and D until a new key message is distributed to each of nodes B, C, and D. This increases the latency of secure communication, making communication of lower-priority security messages undesirable. This also introduces problems with higher-priority communication, such as... Figure 1B shown. Specifically, Figure 1B The diagram illustrates the latency introduced by the need to distribute key messages to each of communication nodes A, B, C, and D. Therefore, conventional key negotiation protocols are unsuitable for nodes connected on a broadcast bus used in real-time control systems, as such latency could introduce significant security risks.

[0012] The implementation described further herein aims to address this problem by enabling key negotiation without exchanging separate key negotiation messages, thus meeting the stringent start-time requirements of real-time control systems. As discussed in further detail below, this is achieved using a group-range key counter, where each node stores in its non-volatile memory the latest value of the counter as observed via the last received security message. This counter value monotonically increases, and the nodes maintain synchronization by transmitting the counter value (or a representation of the counter value) in each security message.

[0013] As mentioned above, the counter can alternatively be referred to herein as a key counter because it is used by the cryptographic blocks (along with the pre-shared key, also stored in non-volatile memory) to derive one or more session keys. Since different nodes in a communication group can utilize the same cryptographic function, the same key counter and the same shared key produce the same session key. Therefore, when nodes synchronize to the same group-wide key counter, the nodes effectively agree to use the same session key.

[0014] Similarly, each security message includes a key counter, or more precisely, a representation of the key counter (e.g., a portion of its bits), enabling receiving nodes to use their local copies to establish group-wide key counter values, also stored in non-volatile memory. This facilitates key negotiation because the key counter rarely changes. Therefore, including a portion of the key counter—such as a lower, predetermined number of truncated bits—is sufficient for each receiving node to verify whether the counter value used by the transmitting node (and sent in the security message) matches the key counter stored locally at the receiving node. And because the key counter representation is carried in each security message, no separate key negotiation message is required. In other words, key negotiation is implicit in each security message, thus avoiding the latency caused by waiting for consensus among nodes, as is the case in conventional systems.

[0015] Furthermore, the implementation described herein can extend the use of key counters and pre-shared keys to protect against weak replay attacks via a real-time member tracking solution. This real-time member tracking solution defines one or more member groups, which may include the entire number of interconnected nodes within the system or a subset of such nodes. Once a member group is defined, each node within the member group can at any time request or “challenge” other nodes within the same member group to verify its online status. In other words, a challenging node in the member group can request other nodes to respond to a challenge request. Such a challenge request can be made via a representation using a query value encoded in a secure message and can be included in any field of the secure message. Advantageously, the representation of the query value can be a small field (e.g., a single bit), and therefore the challenge request can be easily added to a secure message to be transmitted in typical inter-node communication. For example, the representation of the query value can be added as a field or any suitable portion of a secure message generated and transmitted in typical secure message communication between interconnected nodes in the same member group. This advantageously avoids the need to transmit the challenge request as part of a separate, dedicated message.

[0016] Each node in the member group can use a representation of the query value to identify which node has requested online state verification from which such a challenge has been issued. Therefore, each node in the member group can maintain a log of query values ​​(e.g., bit strings) corresponding to each node's challenge request via local storage. In this way, each node in the member group tracks an indication of each other's challenge requests, which is associated with each requesting node via a dedicated predefined bit string position for each node in the member group. In response to such a challenge request, each node can transmit a security message that includes a response encoded in its current local storage bit string (e.g., in a field or other part of the security message) identifying the responding node's current local storage log of challenge query values ​​from all other nodes in the member group. Therefore, and in a similar manner to that indicated above for the representation of the query value, the encoded response can also be relatively small (e.g., a bit string) and added to the next security message to be transmitted between nodes in the member group. Thus, a separate dedicated message is not required for the response to the challenge request. As further detailed below, using challenge requests and responses as part of typical secure messaging communication advantageously allows for enhanced security without adversely impacting message transmission and reception bandwidth.

[0017] Therefore, each node that has requested a challenge can verify its online status by identifying whether it has already set an encoded value in the security message corresponding to a predetermined bit position of the requesting node. The encoded value at that bit position is then compared to a predetermined value (e.g., "1") and associated with the previously challenged node by preserving the bit position. Thus, the encoded value contained in that bit position represents an affirmative response to the challenge. If this is not the case, the security message may not be accepted because the request for online status verification has not been acknowledged by the responding node. The ability of member groups to use and execute such challenge requests, combined with the use of counter values ​​and pre-shared keys discussed above, can be particularly useful, as this provides an additional layer of security against weak replay attacks. This is a result of utilizing the counter verification scheme discussed in this paper, which ensures that the bit string cannot be manipulated.

[0018] Furthermore, the implementation described herein can leverage a group tracking solution to implement a message queue management system, which can be implemented to facilitate Ethernet-based atomicity in real-time control systems. For example, nodes in an interconnected network can transmit queued messages according to an Ethernet Physical Layer Collision Avoidance (PLCA) scheme. The queued messages can be associated with different levels of priority, for example, according to a transmission scheduling system that can be identified, for example, according to the IEEE 802.1Q and 802.1AS Time-Sensitive Networking (TSN) standards.

[0019] As further detailed herein, each node can maintain several registers that are updated as messages are transmitted and received among the nodes in the group. Transmitted messages may include an acknowledgment field containing an encoded value indicating the acknowledgment of each node that received the message. Thus, a node receiving a message responds by including an encoded value in the acknowledgment field of the next message scheduled for transmission, indicating that the node has received the message. Nodes can thus use acknowledgments from one or more received messages to verify which nodes actually received the transmitted message. The transmitting node can then remove the message from its transmission queue only if it has verified (using acknowledgments from other nodes) that each of the other nodes in the group has received the message. Otherwise, if acknowledgments from one or more of the intended recipient nodes of the message are lost, the transmitting node can retain the message in the queue instead of deleting it. Due to the use of the PLCA scheme, the message retained in the queue will subsequently be retransmitted according to the established transmission schedule. In this way, the use of atomic broadcasts can be extended to applications using Ethernet-based communication protocols such as 10BASE-T1S and 10BASE-T1L. Attached Figure Description

[0020] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various aspects of this disclosure and, together with the specification, further serve to explain the principles of the aspects and enable those skilled in the art to manufacture and use the aspects.

[0021] Figure 1A The use of a standard key negotiation message transmission and reception protocol for low-priority frames is illustrated;

[0022] Figure 1B The use of a standard key negotiation message transmission and reception protocol for high-priority frames is illustrated;

[0023] Figure 2A An example node architecture according to one or more embodiments of this disclosure is shown;

[0024] Figure 2B An example key session generator according to one or more embodiments of this disclosure is shown;

[0025] Figure 2C An example of a freshness value (FV) log received according to one or more embodiments of this disclosure is shown;

[0026] Figure 3 An example system of interconnected nodes including defined security domains according to one or more embodiments of this disclosure is shown;

[0027] Figure 4A Example formats of received security messages according to one or more embodiments of this disclosure are shown;

[0028] Figure 4B Example formats of security messages transmitted according to one or more embodiments of this disclosure are shown;

[0029] Figure 5 An example use of a hardware-based solution for utilizing a freshness value according to one or more embodiments of this disclosure is shown;

[0030] Figure 6 Examples of hardware-based implementations of a secure messaging system adapted to existing conventional systems, according to one or more embodiments of this disclosure, are shown.

[0031] Figure 7A and Figure 7B An example processing flow according to an embodiment of this disclosure is shown;

[0032] Figure 8 An example format of a security message for requesting and responding to an online status verification request, according to one or more embodiments of this disclosure, is shown;

[0033] Figure 9A and Figure 9B An example processing flow according to an embodiment of this disclosure is shown;

[0034] Figure 10 This illustrates a conventional high availability seamless redundancy (HSR) ring topology that attempts to provide atomicity for Ethernet-based networks;

[0035] Figure 11 Another example node architecture is shown according to one or more embodiments of this disclosure;

[0036] Figure 12A and Figure 12B A block diagram of a message queue management system based on acknowledgments received from other nodes, according to an embodiment of this disclosure, is shown.

[0037] Figures 13A to 13D Examples of register contents for various nodes within the same group supporting atomicity, according to embodiments of this disclosure, are shown; and

[0038] Figure 14 An example processing flow according to an implementation of this disclosure is shown.

[0039] Example aspects of this disclosure will be described with reference to the accompanying drawings. Elements that first appear in the drawings are generally indicated by the leftmost numeral in the corresponding reference numerals. Detailed Implementation

[0040] Numerous specific details are set forth in the following description to provide a thorough understanding of various aspects of this disclosure. However, it will be apparent to those skilled in the art that these aspects, including structures, systems, and methods, can be practiced without these specific details. The descriptions and representations herein are common means by which those experienced or skilled in the art most effectively communicate the substance of their work to others of similar skill. In other instances, well-known methods, processes, components, and circuit systems have not been described in detail to avoid unnecessarily obscuring aspects of this disclosure.

[0041] For ease of explanation, the embodiments described herein are presented in separate sections. Section I relates to the use of locally stored key counter values ​​for secure communication according to a real-time bus key distribution system that eliminates the need for dedicated key negotiation messages. Section II relates to the use of real-time member groups to provide an additional layer of security. Section III relates to an additional group tracking solution for implementing a message queue management system, which can be implemented to facilitate Ethernet-based atomicity, for example, in real-time control systems. Although these embodiments are discussed separately, it should be noted that any embodiments described in Sections I, II, or III can be combined with each other, and any architecture, communication protocol, and / or technology described in any section is also applicable to embodiments described in other sections. For example, any embodiment described herein with respect to Section I may optionally include the use of a real-time member tracking implementation as described in Section II as an additional layer of security against weak replay attacks. As an additional example, any embodiment described herein with respect to Section III may optionally include the use of a real-time bus key distribution system as described in Section I to ensure secure transmission of messages in an interconnected network of nodes that may form part of a real-time control system.

[0042] I. Secure communication using locally stored key counter values

[0043] As discussed in further detail below, the implementations described herein can be implemented according to any suitable communication architecture that utilizes a broadcast bus to facilitate secure communication between interconnected node systems. For example, a broadcast bus can be implemented according to a scheme known as "multi-drop". In other words, while the implementations described herein can function according to a point-to-point communication architecture, they can be particularly well-suited for use in point-to-multipoint communication architectures. Furthermore, although not limited to use in real-time control systems, the implementations described herein can be advantageously implemented as part of such systems, which require greater considerations regarding security, timing, and robustness compared to conventional node-based communication networks.

[0044] For example, and using a vehicle-based real-time control system as an example, nodes in such a system can control safety-critical components such as vehicle steering, braking, and acceleration. Therefore, it is crucial that security messages between these nodes are sent and received with minimal latency, that nodes quickly return to online after a reset, and that nodes in the system are not adversely affected while waiting for reset nodes to return to online. Furthermore, due to increasing considerations regarding security and resistance to reverse engineering attempts, real-time control systems need to resist malicious attacks that might attempt to gain unauthorized access to keys or other system information.

[0045] For example, one such attack includes a so-called "replay attack," which can include both "strong" and "weak" replay attacks. The implementations in this section primarily relate to preventing strong replay attacks, which force security messages to be retransmitted out of order to other nodes. To protect against such attacks, conventional systems utilize a "freshness value" (FV) to prevent the replay of the same (legitimate) message, forcing the receiver to act on it at an invalid time. These conventional systems, including Controller Area Network (CAN) buses and multi-point branch Ethernet communication protocols such as 10BASE-T1S and 10BASE-T1L, result in out-of-order frame transmission due to priority queuing. Therefore, such conventional systems employ an "acceptance window," which, while still allowing replay attacks, limits such attacks to the window in an attempt to limit the possibility. However, a major drawback of such systems is that the window can be relatively large (e.g., 1 second), thus reducing but not eliminating the possibility of exposure to replay attacks.

[0046] Other attacks include denial-of-service attacks that exploit key negotiation messages. As mentioned above, the use of a regular key negotiation protocol requires the transmission of a large number of such messages within the network, scaling quadratically with the number of nodes. Therefore, it is possible to exploit the use of such a large number of messages to maliciously trigger key renegotiation processes, thereby disrupting bus traffic. Furthermore, such attacks can be used to trigger multiple key renegotiations to cause a complete halt to secure traffic.

[0047] Additional attacks include the reuse of Secure Channel Indicator (SCI) values—details of which are discussed further in this paper—to break the assumption about the reuse of random numbers. For example, a malware-infected node can use an SCI value assigned to another node and force the device to send messages that can reuse random values, thus implicitly leaking the session key. Furthermore, attacks can include denial-of-service attacks on key negotiation servers, which can leverage bus shutdown attacks to force the server offline, thereby preventing the server from issuing new keys.

[0048] The implementation described herein addresses these issues to increase the robustness of real-time control systems against such attacks. To this end, the implementation described further herein does not utilize key negotiation messages but can operate independently of the key negotiation server. Therefore, instead of using a centralized key negotiation system, the implementation described herein can maintain a locally stored copy of the counter values ​​typically derived from a central server. Similarly, a representation of the counter values ​​can be transmitted as part of each security message, which can be used by the receiving node to verify the counter and validate the security message.

[0049] A. Node Architecture

[0050] Figure 2AA node architecture according to one or more embodiments of this disclosure is illustrated. Node 200 can identify any suitable type of component and can represent a node in a system of interconnected nodes, such a system... Figure 3 The following is illustrated and further discussed below. For example, node 200 may identify a portion of an electronic control unit (ECU), sensor, actuator, host, etc. Various nodes having such an interconnected system may differ in type and / or function, although each node may have common functions as discussed herein with respect to node 200. Therefore, each node in the interconnected node system may be configured to transmit and / or receive security messages in the same manner as described herein with respect to node 200.

[0051] like Figure 2A Node 200 shown may represent a node in an interconnected node system configured to communicate on a bus according to a multipoint branching scheme, as discussed herein. For example, such a multipoint branching scheme may be part of an automotive E / E architecture as described above, which may include a CAN bus architecture or other suitable automotive E / E architecture. The interconnected node system may support the communication of safety messages according to any suitable type of system, such as a real-time control system that can be implemented in a vehicle. Therefore, node 200 may be one of any suitable number of nodes communicating with each other via a data interface 210 that may be coupled to and / or form part of a bus used as part of any suitable type of point-to-point or multipoint branching scheme. Data interface 210 may include any suitable number and / or type of data interfaces to facilitate the exchange of safety messages between node 200 and any suitable number of other nodes within the interconnected node system.

[0052] Node 200 can transmit and / or receive security messages as discussed herein to communicate with other nodes within the interconnected node system using any suitable number and / or type of communication protocols and accompanying operating modes. For example, Node 200 can be configured to receive and transmit security messages according to the following communication protocols: a communication protocol utilizing Authentication Encryption Galois / Counter Mode (AES-GCM)-SIV operation (the counter has a CBC-MAC operation mode (CCM)); a communication protocol utilizing an operation mode implementing the national cryptographic standard 4 (SM4); any suitable type of Ethernet communication protocol (e.g., multi-point branch Ethernet communication protocols such as 10BASE-T1S, 10BASE-T1L, Ethernet MACsec standard, etc.); any suitable vehicular network protocol such as Controller Area Network (CAN) communication protocol, Controller Area Network Flexible Data Rate (CAN FD) communication protocol, Controller Area Network Very Long (CAN XL) communication protocol, any suitable communication protocol implementing Authentication Encryption with Related Data (AEAD) operation mode, etc.

[0053] Similarly, node 200 (and every other node in the interconnected system) is configured to transmit security messages to and receive security messages transmitted by other nodes via data interface 210. Therefore, although each node in the interconnected node system (which again includes node 200) is configured to perform both transmission and reception functions, the term "transmitting node" is used herein to refer to any node currently performing the transmission of security messages and / or performing any function related to such transmission, while the term "receiving node" is used herein to refer to any node currently receiving security messages and / or performing any function related to such reception.

[0054] To perform secure message communication, node 200 includes a session key generator 202, non-volatile memory 204, volatile memory 206, and a secure message processor 208. These components are... Figure 2A The nodes are shown as separate entities, with their corresponding functions described individually for ease of explanation. However, any components of node 200 may be integrated with each other or otherwise combined. Node 200 may also include components as described herein. Figure 2AThose additional or alternative components are shown and discussed. Furthermore, although node 200 is shown and described herein with respect to the use of non-volatile memory 204 and volatile memory 206, this is done by way of example and not limitation. Any data stored in non-volatile memory 204 and volatile memory 206 may be additionally or alternatively stored in other memories, which may be part of node 200 or external to node 200. For example, any data shown in the figures as stored in volatile memory may alternatively be stored in non-volatile memory, and vice versa. However, it should be recognized that certain types of static data, such as secret keys, may be advantageously stored in non-volatile memory to ensure their security. Furthermore, ensuring the persistence of static data such as secret keys may be of interest in cases where the node is offline and returns to the bus, such as in the event of a node reboot.

[0055] Furthermore, while node 200 is shown and discussed herein in relation to performing both secure message transmission and reception, it should be understood that node 200 may include separate components to perform each corresponding function, or alternatively, combinations of such components to selectively and independently implement both functions. Thus, secure message processor 208 may represent an encoder, a decoder, or a combination of both to facilitate node 200's operation according to any of these foregoing operating modes.

[0056] The security message processor 208 may include any suitable number and / or type of components, in Figure 2A Examples of such components are shown by way of example, not limitation. For example, the security message processor 208 may include communication circuitry 208.1, which may be coupled to the data interface 210 and thus to an accompanying bus of the interconnect node system as discussed herein. Therefore, the data interface 210 may include any suitable implementation of components for this purpose, such as, for example, wires, buses and / or corresponding terminals, ports, pins, etc. The communication circuitry 208.1 may be implemented to enable communication between node 200 and other nodes within the interconnect node system via the data interface 210, as further discussed herein. Therefore, the communication circuitry 208.1 may transmit and receive security messages to and from the data interface 210 according to any suitable number and / or type of communication protocols—such as those discussed herein. For this purpose, the communication circuitry 208.1 may include hardware components, software components, or combinations thereof, typically associated with components configured to perform data communication. For example, the communication circuitry 208.1 may include any suitable number of ports, drivers, transmit and / or receive buffers, switches, etc.

[0057] The processing circuitry 208.2 may include any suitable number and / or type of dedicated hardware components, such as microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), system-on-a-chip (SoCs), dedicated logic and / or other circuit systems, etc. The processing circuitry 208.2 may be implemented as one or more processors and / or cores that can execute computer-readable instructions stored in program memory 208.3 to perform any of the various functions discussed in further detail herein. Therefore, although the processing circuitry 208.2 in… Figure 2A While shown as a separate entity from the session key generator 202, it should be understood that the processing circuitry 208.2 can facilitate the operation of the session key generator 202, as discussed further herein, and therefore the session key generator 202 and the processing circuitry 208.2 may include the same components in some embodiments.

[0058] Program memory 208.3 may include any suitable type of non-transitory computer-readable medium, such as volatile memory, non-volatile memory, or a combination thereof. To the extent that node 200 implements a software-based solution to perform the various functions discussed herein, this can be achieved, for example, by executing instructions stored in program memory 208.3 via processor circuitry 208.2.

[0059] B. Security Domain

[0060] Similarly, node 200 can represent one of several nodes that form an interconnected node system. Figure 3 An example of such an interconnected system is shown, comprising a total of X nodes. Node 200 can be identified as nodes N1 to N. x Any node, and nodes N1 to N x Each node in the system can transmit and receive security messages in a manner similar to that of node 200 discussed in this paper.

[0061] The interconnected node system 300 (also referred to as system 300 in this document) can include any suitable number of security domains (SZs), for the sake of brevity, Figure 3 Three are shown, denoted as security domains SZ-A, SZ-B, and SZ-C. These security domains can be defined according to any communication protocol as discussed herein, and nodes having system 300 can identify the intended recipients of secure messages transmitted and received within these security domains by using the Secure Channel Indicator (SCI) field, as discussed in further detail below.

[0062] Continue to refer to Figure 3 Each security domain comprises a corresponding group of nodes. For example, ... Figure 3The security domain SZ-A of the system 300 shown includes nodes N1, N2, and N3. Security domain SZ-B includes nodes N3 and N4, and security domain SZ-C includes nodes N3 and N4. X The implementations discussed herein can realize the transmission and reception of secure messages according to a specific security domain, within which the transmitting node and the intended recipient of the secure message form a part. However, the implementations are not limited to their use of systems that include such security domains, and can be implemented as part of any suitable communication system (i.e., with or without using a security domain).

[0063] C. Key Generation and Management

[0064] In order to use secure messages, when using a security domain, node 200 and every other node in system 300 store a set of shared keys on a security domain basis. In other words, each node in system 300 stores the shared key in non-volatile (NVM) memory, which may alternatively be referred to as a secret key or shared secret. Now let's move on to... Figure 2A This is illustrated by a node 200 including non-volatile memory 204, which is configured to store the shared key for each security domain of a member within system 300. Therefore, for ease of explanation, node 200 can be identified as follows: Figure 3 Node N3, as shown, is a member of each of security domains SZ-A, SZ-B, and SZ-C. Therefore, in this case, node 200 stores three shared keys A, B, and C in non-volatile memory 204. Of course, node 200 can store additional or fewer shared keys based on the number of security domains in which node 200 is a member. Therefore, in this implementation, each node is configured 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 security domains in which the node is a member. For example, node 200 could store one shared key for each security domain, such as... Figure 2A As shown, although this is an example and not a limiting approach, node 200 can store any suitable number of shared keys for each security domain.

[0065] Therefore, NVM 204 can be implemented with any suitable type of non-volatile memory of any suitable size for storing any suitable number of shared keys. Each shared key can represent a pre-signal string or other suitable encoded value of any suitable length. Thus, each node within the same security domain stores the same shared key in its corresponding NVM, which is used for the transmission and reception of secure messages in that security domain, but not for other security domains. For example, nodes N1 and N2 can store only shared key A for security domain A, while node N2 can store only shared key B for security domain B. The secret key is typically static and does not change during the operational lifetime of the node, and can therefore be flashed, written, stored, etc., as part of the initial manufacturing process. Alternatively, the shared key can be written to NVM 204 via node 200 or another suitable device. To ensure security, the shared key is not included in the secure messages transmitted between nodes and is only accessed or otherwise known by each node via its corresponding NVM, and is therefore unknown to other nodes in system 300.

[0066] In all cases, the "permanent" shared key is used to facilitate the generation of temporary session keys, which may simply be referred to as session keys in this document, and are used to transmit and receive secure messages within the same security domain. For this purpose, refer now to... Figure 2B It provides information on such Figure 2A Additional details about the session key generator 202 shown are provided below. Session keys are generated using key derivation functions (KDFs), where a KDF represents a specific cryptographic function based on a specific communication protocol implemented by node 200. The use of KDFs is generally known, therefore, for the sake of brevity, additional details regarding KDF operations are not described herein.

[0067] Similar to a shared key, a session key can represent a bit string of any suitable length or other suitable encoded value. In any case, once generated, processing circuitry 208.2 can use the corresponding session key for each security domain to generate each secure message transmitted to other nodes within the same security domain, and also uses the same session key to authenticate and / or decrypt secure messages received from nodes within the same security domain. Therefore, processing circuitry 208.2 can execute any suitable type of cryptographic function that uses the generated session key as an encryption key to generate secure messages.

[0068] Additionally, implementing a single session key at one node for authentication and a second session key for encryption can be particularly advantageous, as some cryptographic functions require different keys for authentication and encryption. It should also be noted that in some alternative implementations, separate session keys can be assigned to each node participating in the security domain. In such scenarios, a key derivation function (KDF) can be executed (i.e., transmitted and / or received) for each secure message. Specifically, for hardware-based KDF implementations, this can be performed without penalty.

[0069] Note that the session key generator 202 can implement any suitable type of KDF to generate any suitable number of session keys from each corresponding shared key. That is, the session key generator 202 is configured to generate a corresponding temporary session key for each in the security domain using the corresponding shared key and the corresponding key counter value according to the corresponding cryptographic function. Furthermore, for the transmission of secure messages for each group of nodes within the security domain, each corresponding secure message includes multiple fields, as discussed further herein, one of which includes a representation of the corresponding counter value used to generate the session key for generating the secure message. Additional details regarding the content and format of the secure messages are discussed further below.

[0070] The communication circuit 208.1 is also configured to transmit secure messages to each node group based on the security domain to which each receiver node belongs. Therefore, although multiple session keys can be generated from a single shared key, the same session key is used at any given time to perform secure communication to and from nodes within the same security domain. Thus, for communication to nodes within each security domain, the KDF receives the shared key of that security domain and a counter value as input. Each KDF can also receive, for example, Figure 2B The additional inputs shown can be any suitable value chosen to ensure that the generated session key is unique for each security domain. For example, additional inputs to KDF can include SCI values, random numbers (numbers used only once), etc. Therefore, by modifying different inputs to KDF in each case, multiple session keys can be generated for each region using the same shared key.

[0071] In any case, it should be noted that the same KDF algorithm will repeatedly generate the same session key from the same input. Therefore, and as will be described in further detail below, other nodes can be configured with the same KDF and shared key to authenticate and / or decrypt secure messages using their own session keys and inputs, which should then be matched with the session key used when the secure message is generated by the transmitting node (i.e., before it is received by the receiving node).

[0072] Although the session key is described herein as being used to transmit secure messages to all other receiving nodes in each security domain, this is merely an example and for ease of illustration. Specifically, the session key described herein can be implemented to generate secure messages, which may represent authentication-only messages, or alternatively, both authentication and encrypted messages. For example, for various AES-GCM-based protocols (used in MACsec), an Integrity Check Value (ICV) is calculated according to their respective algorithms. For authentication-only secure messages, the ICV is calculated without encrypted data, and for both authentication and encrypted secure messages, the ICV is calculated in parallel with the encrypted data. Authentication-only messages may be particularly useful, for example, in scenarios where it is necessary to read the message first to quickly execute specific controls or commands without first decrypting the payload of the secure message. Any suitable algorithm, including known techniques, can be implemented to calculate the ICV, as discussed herein. Depending on these cryptographic functions used to generate the ICV, the input typically includes a key (e.g., a session key), a counter value (e.g., a key counter value), the plaintext of the message (if present), and the current freshness value (FV) transmitted in the secure message.

[0073] In any case, based on the specific cryptographic algorithm used to calculate the ICV, the ICV can be generated using the same key or a different key as the key used to encrypt the data (i.e., the encrypted payload). In either case, the key used to generate the ICV and the key used for data encryption can include a session key stored locally by the transport node. In various implementations, this session key can again include the same or a different session key, identified by a key counter for a specific security domain. Therefore, for authentication purposes, the transport node can utilize its locally stored session key to calculate the ICV, while for authenticated and encrypted secure messages, the transport node can use its locally stored session key to calculate the ICV and the encrypted payload. For both secure message types, authentication of the secure message is established by verifying the ICV via the receiving node, as discussed further herein.

[0074] Therefore, implementations include generating any suitable number of session keys from the same shared key and KDF, wherein each distinct session key is generated in this manner using different key counter values ​​(or other different inputs). Alternatively, session key generator 202 can generate any suitable number of distinct session keys for each security domain using the same input and KDF but a different shared key, thereby generating each distinct session key in this manner.

[0075] To provide an illustrative example, session key generator 202 can be configured to generate two corresponding temporary session keys from each corresponding stored shared key according to the same cryptographic function. Therefore, by changing other inputs to the KDF, different session keys can be generated from the same shared key using the same key counter value. Continuing the example, the first of the temporary session keys generated in this way enables the receiving node to decrypt a secure message, while the second temporary session key generated in this way enables the receiving node to authenticate a secure message. In other words, nodes within each security domain can function according to a predetermined scheme, such that a particular session key is used for authentication, encryption, or both authentication and encryption of secure messages.

[0076] Similarly, one variable relating to the generation of different session keys from the same shared key is the key counter value, which may also be referred to herein as the counter value. Therefore, each receiving node needs to ensure that its session key is generated with the same key counter value as the transmitting node; otherwise, the receiving node will be unable to authenticate and / or decrypt secure messages. In this way, the implementation described herein advantageously enables nodes to synchronize their key counter values, and thus their session keys, without using key messages.

[0077] Therefore, additional details regarding the conventional use of key counter values ​​are now provided cautiously. Note that conventional systems use centralized servers, control planes, hosts, etc., to maintain global counter values, which need to be transmitted via nodes as part of the key negotiation message as described above. However, embodiments of this disclosure recognize that session keys can alternatively be maintained and derived locally, thereby eliminating the need to communicate with a centralized entity for key negotiation.

[0078] Therefore, each node in system 300 can include any suitable number of counters, one counter per shared key, such as... Figure 2BAs shown. The counter can be implemented as any suitable hardware component, software component, or combination thereof, enabling the generation of a unique counter value that can be represented as any suitable number of bits. For example, each counter can be implemented to generate a monotonically increasing counter value that increments in response to the satisfaction of one or more predefined conditions, which could be the result of a "re-keying" event. Such a re-keying event can occur, for example, in response to any suitable number of conditions, which can be autonomous or triggered by security alerts. For example, a node can perform a re-keying event when the number of secure messages transmitted with the corresponding session key exceeds a predetermined number of messages (i.e., the session key is "exhausted"), when a predetermined time period expires, or upon each system startup. To provide another example, the re-keying condition 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 other suitable data interface, explicitly instructing node 200 to perform the re-keying process.

[0079] Therefore, the processing circuit 208.2 of node 200 can periodically perform key update processing according to the various conditions described above. In an implementation, the processing circuit 208.2 can implement a rate limiter configured to limit the number of key update operations within a specific time period. This can include, for example, a priority-based system that can be implemented via node 200. For example, such a system could consider a watchdog reset loop and include storing one or more priority flags in NVM 204 whose presence overrides the triggering of key update processing. For example, non-volatile memory could store such flags indicating an event that overrides key update processing when present. Therefore, when the flag is stored in NVM 204, the processing circuit 208.2 will not perform a key update operation despite any of the aforementioned conditions being met. The priority flags can be cleared after a predetermined time period, once the event ends, etc., so that the key counter does not increment when the priority flags are set.

[0080] In some implementations, processing circuitry 208.2 may (e.g., via executing instructions stored in program memory 208.3) implement a stable storage algorithm, which may alternatively be called an atomic storage algorithm, to perform key update processing. Stable storage is a category of computer data storage techniques that guarantees the atomicity of any given write operation and allows for the writing of software that is robust to certain hardware and power failures. For something to be considered atomic, when reading back a portion of the disk that was just written, the storage subsystem should return the written data or the data that was on that portion of the disk before the write operation. Stable storage algorithms are generally designed to eliminate corrupted data in storage devices. To this end, data is stored more than once, or error-correcting codes are used so that the most recent uncorrupted value can always be read. Using such a stable storage algorithm can be particularly helpful in preventing power failures or transient disturbances during incrementing processes from leading to corrupted key counter values.

[0081] In this scenario, the session key generator 202 stores the updated (i.e., incrementing) key counter value in non-volatile memory, for example, by overwriting the previous key counter value of the shared key with a new key counter value. The session key generator 202 also generates an updated temporary session key from the corresponding shared key and the incrementing key counter value according to the KDF, such as... Figure 2B As shown. Therefore, a session key is generated via KDF from the shared key and the current key counter value (along with other inputs), where both the shared key and the counter key value are stored in NVM 204. Since key update events can be security domain specific, this... Figure 2A This is illustrated by incrementing the key counter for security domain B while not incrementing the key counter values ​​for security domains A and C.

[0082] For example, and as Figure 2A As shown, NVM 204 can store any suitable number of key counter values, associated with each of the stored shared keys. In this way, NVM 204 stores a corresponding shared key and a corresponding key counter value for each security domain. That is, the key counter values ​​can differ between different security domains; however, the value of each key counter can be synchronized between nodes within each security domain, as discussed further in this paper.

[0083] The representation of the key counter value can be included in each secure message in an unencrypted form, i.e., "plaintext". Therefore, and as discussed further in detail below, each receiving node can verify the validity of the key counter value by comparing the key counter value representation in the received secure message with the key counter value stored locally at the receiving node. Because each node in system 300 can store the key counter value in this manner, the receiving node can determine whether the counter value calculated based on the counter value representation included in the secure message matches the locally stored counter value.

[0084] 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 secure message, awaiting verification of the secure message, as discussed in further detail below. That is, before updating the locally stored key counter value in this way, the receiving node can verify the key counter value represented in the secure 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 secure message). This temporary session key is then used at the receiving node to verify the corresponding integrity check value (ICV) contained in the secure message. In other words, the representation of the counter value in the secure message allows the receiving node to derive a temporary session key used to verify the counter value used by the transmitting node to generate the session key for generating the secure message. This process is described in further detail below.

[0085] Similarly, session keys generated by the session key generator at any time are considered temporary and can be changed as the key counter value increments as described above. Therefore, volatile memory 206 is configured to store each of the session keys generated via session key generator 202. As described above, temporary session keys can be overwritten or deleted when an updated session key is generated (e.g., when the counter value increments).

[0086] The representation of a sequence number can also be used to transmit security messages. In some implementations, the sequence number may include a freshness value (FV), such as a freshness value defined according to any communication protocol as described herein. However, although referred to herein as a freshness value, the sequence number is not limited to the freshness value defined in any particular communication protocol or standard, and may include a bit string or other suitable encoded numerical value of any appropriate length, which can be used to enhance security measures by preventing replay attacks.

[0087] Therefore, the freshness value is also a changing, temporary value, and thus the volatile memory 206 can also store the latest freshness value of each transmission node associated with each session key (and thus the key counter value), such as Figure 2AAs shown. As a security measure, the processing circuit 208.2 can increment the freshness value after transmitting each security message and after receiving each security message. That is, the freshness value can have an initial predetermined value (e.g., 1), which is incremented by the transmitting node when transmitting each security message and also by the receiving node when receiving each security message.

[0088] It should be noted that security messages may arrive at the receiving node out of order; that is, the buffering scheme used by the transmitting node will typically send higher-priority messages before lower-priority messages. Therefore, conventional systems typically accept out-of-order messages but use a "window," so replayed messages will need to be relatively recent, hopefully providing sufficient protection against such attacks. Furthermore, conventional systems use multiple sequence numbers at each transmitting node (one per security channel), and the transmitting node then ensures that the sequence numbers are transmitted sequentially within each of its security channels.

[0089] By using the key counter value as described herein, the implementation discussed herein extends this conventional use of freshness values ​​in several different ways. First, each receiving node stores a log containing previously received and accepted freshness values ​​from previously received and accepted security messages, these freshness values ​​being associated with each transmitting node, security domain, and current key counter value. The number of freshness values ​​recorded in this manner can be any suitable number depending on the specific application.

[0090] exist Figure 2C Additional details about the received freshness values ​​in the logs are shown below. Figure 2C This shows that each key counter value is related to its previously received freshness value for each transmission node and each security domain. Therefore, as... Figure 2C The received FV log 208.1 shown includes a set of freshness values ​​for each node, because in this example, each of the nodes is part of only one security domain. However, this is by way of example and not a limitation, and the received FV log 208.1 can store any suitable number of freshness values ​​for each transmitting node based on the number of security domains in which each node is a member. For example, if node N4 is also part of security domain A, the received FV log 208.1 will also store a log of freshness values ​​received from node N4 via security domain A (not shown).

[0091] Therefore, the receiving node uses the freshness value in each received security message to determine whether a current security message from a specific transmitting node has been received. To do this, the receiving node refers to a group of freshness values ​​stored by that specific transmitting node, which can be identified via the transmitted SCI value, as discussed further below. If a newly received security message does not have a freshness value greater than the freshness value of the last record, the security message is discarded as a replay. Note that the first received security message is always accepted by the receiving node, i.e., before the history of previously received freshness values ​​becomes available.

[0092] Secondly, when the local key counter value is changed (i.e., during a key update process where the key counter value is incremented), the transmitting node resets the freshness value (for the specific security domain where the key counter is reset) to an initial predetermined value (e.g., 1). The receiving node is configured to recognize the initial freshness value in security messages received after such an event occurs. Therefore, after a key update event, the receiving node can continue to store any suitable predetermined number of the last received freshness values ​​for the previously used key counter value, so that even after the receiving node has moved to using a new key counter value, older security messages (and therefore with older counter values) that are still working in their own way through the priority queue are still verified. Alternatively, the freshness values ​​stored in this way can be deleted after a predetermined period of time following the use of the new key counter value. In this way, the receiving node can still receive and accept security messages across key update events and will accept the first message transmitted after the key update process has occurred.

[0093] Freshness values ​​can be used for different purposes by both transmitting and receiving nodes. For example, a transmitting node can compare an incrementing freshness value with a predetermined freshness threshold after transmitting a secure message to determine whether a threshold number of secure messages have been transmitted, thereby triggering the key update process as described above. For instance, because the transmitting node generates and stores different session keys for each secure channel, it can use the freshness value to count messages using the session key, i.e., the number of secure messages transmitted for each session key. When the freshness value of a specific security domain reaches a predetermined threshold, the transmitting node can increment the key counter as part of the key update process as described above.

[0094] Therefore, for example, the predetermined threshold can include a value for each node or a value representing the sum of nodes across any suitable number of nodes, such as nodes within the same security domain. In other words, a quota can be established for this threshold such that the sum of the quotas for all nodes in the security domain is less than the exhaustion count of the session key (i.e., the predetermined threshold) when all other transport nodes in the same security domain use the same session key.

[0095] In one implementation, the exhaustion counter can be implemented using the transport node ID (or SCI) in the KDF used to generate the session key, ensuring a unique session key for each transport node. In this case, the exhaustion count of a transport node can be identified using its own session key, reducing the number of key update processes since the quota is not shared among several nodes.

[0096] Therefore, the KDF implemented by the session key generator 202 can optionally receive a secure channel identifier (SCI) as, for example... Figure 2B The additional input shown is a subset of the inputs that is unique throughout the system. The concept of secure channels and the carrying of secure channel identifiers are part of the Ethernet MACsec standard and other communication standards, and are discussed further below.

[0097] D. Security message formats and communication protocols

[0098] Figure 4A The security message format and accompanying processing timeline according to one or more embodiments of this disclosure are shown. Figure 4A The security messages shown can be transmitted according to any suitable communication protocol and can constitute a communication protocol frame 400 including any suitable number of fields. Similarly, the communication protocol and therefore... Figure 4A The accompanying communication protocol frame 400 shown can be identified by any suitable type of communication protocol, which can be implemented to facilitate the communication of secure messages via a multi-point branch bus architecture. For example, the communication protocol frame 400 can be identified by a CAN communication protocol frame, a CAN FD communication protocol frame, a CAN XL communication protocol frame, an Ethernet (e.g., multi-point branch Ethernet such as 10BASE-T1S, 10BASE-T1L) communication protocol frame, etc.

[0099] In any case, communication protocol frame 400 can be identified by a secure message generated by the transmitting node using a temporary session key for a specific security domain, as discussed herein with respect to node 200. Communication protocol frame 400 may include, for example... Figure 4A Additional, fewer, or alternative fields are shown. For example, communication protocol frame 400 includes a header 402, SCI 404, a representation of a counter value (CNT) 406 for generating a security message, a freshness value 408, a payload 410, ICV 412, and an end-of-frame (EOF) identifier 414. Communication protocol frame 400 can then be received by the receiving node as a security message, which is either accepted or rejected, as discussed further below.

[0100] A secure channel within a secure domain comprises a single writer and multiple readers, and thus identifies the secure domain as a system of interconnected nodes that are the intended recipients of secure messages. The 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 domain is defined by a shared key, and the SCI is used to identify the transmitting nodes. For instance, the SCI can be used as one of the inputs to a KDF to generate a unique session key for each transmitter.

[0101] Therefore, each secure channel is identified by a corresponding SCI and is unique in both the physical and logical networks. Thus, as... Figure 3 The security domains SZ-A, SZ-B, and SZ-C shown are each defined by a separate and unique SCI. The processing circuitry 208.2 of node 200 is configured to generate a security message that includes an SCI value indicating which security domain the security message is intended for; that is, the SCI identifies the secure channel and, consequently, the recipient within that security domain to which the message is transmitted. Assuming that communication protocol frame 400 is received by a receiving node in the same security domain as the transmitting node, this is again indicated by the SCI value. Another use of SCI is to avoid the window problem of out-of-order freshness values. That is, different SCIs can be used with different priorities, making them ordered within the same SCI (and thus the FV is attached to the SCI rather than the transmitting node). SCI can also be used at the application level to identify subgroups of receiving nodes within a security domain.

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

[0103] Therefore, the receiving node (e.g., processing circuitry 208.2) can determine whether its local key counter value stored in NVM 204 matches CNT 406 by comparing the entire key counter value stored in the security domain indicated by SCI, or alternatively by comparing the truncated portion of CNT 406. In this way, comparing only the truncated lower significant bits of the counter value is sufficient, since the key counter value does not change frequently, for example, only in response to key update conditions as described herein.

[0104] Continuing this example, if it is determined that the key counter value stored locally by the receiving node matches the key counter value derived from CNT 406, the receiving node can retain its locally stored key counter value as is, determine that the key counter value represented by CNT 406 is valid, and accept the security message. Alternatively or additionally, when the key counter value stored locally by the receiving node is determined to match the key counter value derived from CNT 406, i.e., upon undergoing further verification processing, the receiving node can determine that the key counter value represented by CNT 406 is "temporarily" valid.

[0105] For example, the processing circuitry 208.2 of the receiving node can be configured to verify the key counter value represented by CNT 406 by verifying the security message in various ways. Therefore, when verifying a message, the key counter value derived from CNT 406 is determined to be valid, and the security message is thus accepted. Verification may include, for example, the receiving node calculating a session key based on the key counter value derived from CNT 406. Therefore, when the key counter value derived from CNT 406 matches the key counter value locally stored at the receiving node, the session key generated in this way should match the session key used by the transmitting node to generate the security message, and should also match the session key locally stored at the receiving node. Therefore, message verification can be performed by the receiving node via a session key generated based on the key counter value derived from CNT 406, which is used to decrypt the contents of the security message to derive and verify the ICV, as discussed in further detail below.

[0106] However, if the key counter value stored locally by the receiving node is less than the key counter value derived from CNT 406, this means that the locally stored key counter value has expired, and the receiving node performs a key update process to update the locally stored key counter value by overwriting the current key counter value with a new key counter value that matches the key counter value represented by CNT 406. Additionally, for the session key associated with the current security domain (as indicated via SCI), when verifying the validity of the counter value via the aforementioned ICV verification process, the receiving node generates an updated session key based on the updated key counter value and overwrites its previously stored session key with the updated session key. This updated session key should now match the session key used by the transmitting node to generate the secure message.

[0107] In other words, the receiving node's processing circuitry 208.2 is configured 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 key counter value derived from CNT 406; however, it does not update the locally stored key counter value when the two key counter values ​​already match. Therefore, and as further discussed below, verifying the key counter value represented by CNT 406 can include verifying the security message based on one or more fields of the processed security message. This can include, for example, generating an updated session key using the currently stored session key or based on a corresponding shared key stored in the receiving node's non-volatile memory, as appropriate, and then using the session key (or the updated session key, as appropriate) for security message verification, as discussed in further detail below.

[0108] Furthermore, if it is determined that the key counter value stored locally by the receiving node is greater than the key counter value derived from CNT 406, the receiving node can retain its locally stored key counter value as is, conditionally determine that the key counter value represented by CNT 406 is invalid, and conditionally reject the security message. Therefore, when the key counter value calculated from CNT 406 is less than the locally stored key counter value, the receiving node's processing circuitry 208.2 is configured to determine that the key counter value represented by CNT 406 is invalid and conditionally reject the security message, as this indicates a replay attack, an expired message, or a corrupted message.

[0109] The conditional rejection of key counter values ​​is further discussed below, and may include, for example, a further determination of whether the key counter value derived from CNT 406 in the security message is still within a predetermined time frame, which may alternatively be referred to herein as a "grace period". In some implementations, the grace period may represent a predetermined time period (e.g., 500ms, 1 second, etc.) such that an old key counter value is accepted within the grace period. Thus, the grace period may represent the duration of existence of a key counter value derived since the last (different) key counter was received. Additionally or alternatively, the grace period may be determined based on the number of freshness values ​​associated with the derived key counter value. In this way, communication is not interrupted for a specified period of time after the key update event has occurred. However, once the grace period has expired, messages with old derived key counter values ​​may be rejected, thereby reducing the risk of replay attacks.

[0110] Therefore, in each case, the receiving node accepts or rejects the secure message based on the validity determined by the key counter value calculated from the CNT 406. Similarly, the secure message verification process implemented by the receiving node can utilize additional techniques to perform key counter value verification to determine whether to accept the message. For example, the secure message may contain a sequence number field, which... Figure 4A and Figure 4B The value is shown as Freshness Value (FV) 408. The Freshness Value can also be included as part of the security message in unencrypted form, 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 generating the security message, or alternatively, a truncated portion of the Freshness Value, such as a predetermined set of less significant bits. Therefore, as an added layer of security, the receiving node can verify whether the Freshness Value in the received security message matches the Freshness Value stored in the receiving node's volatile memory (i.e., after FV has been incremented upon receiving the security message). If not, the message can be discarded because the security message may be part of a replay attack and / or the security message was sent out of order. The following discusses… Figure 7A and Figure 7B Further details regarding the use of freshness values ​​will be discussed.

[0111] The payload 410 can be encrypted using the session key via the processing circuitry 208.2 of the transmitting node. This encryption process can be performed using any suitable cryptographic function, including known cryptographic functions. Similarly, in various scenarios, the security message discussed herein may include an authentication-only message or may include both authentication and encryption messages. Therefore, the payload 410 may include plaintext (or omit it) as part of an authentication-only message, or alternatively, data already encrypted via the transmitting node, i.e., ciphertext.

[0112] Furthermore, the communication protocol frame 400 includes a field containing ICV 412, which is generated by the processing circuitry 208.2 of the transmitting node. ICV can be calculated using any suitable technique, including known techniques defined according to any communication standard discussed herein. For example, ICV may comprise a bit string of a predetermined length, which is calculated by the processing circuitry 208.2 based on any suitable cryptographic function such as, for example, Cyclic Redundancy Check (CRC) or Hash-based Message Authentication Code (HMAC). Therefore, as described above, ICV can be calculated by performing an appropriate cryptographic function using the current key counter value and / or plaintext of payload 410 as input. ICV may comprise data representing a dedicated field or a combination of data representing data from other fields of the secure message 400, such as... Figure 4A As shown. For example, ICV may include any suitable combination of header 402 (including a security tag), a full key counter value represented by CNT 406, plaintext payload 410 or ciphertext payload 410, etc.

[0113] ICV 412 can be transmitted in plaintext as part of a secure message, although payload 410 needs to be decrypted by the receiving node first to compute and verify the ICV using the same cryptographic function generated by the transmitting node for ICV 412. For this purpose, the receiving node can compute the session key (for that specific security domain) using a locally stored key counter value corresponding to the computed key counter value derived from CNT 406. Similarly, when the key counter value derived from CNT 406 is valid, these key counter values ​​(initial or during key updates) should match each other. In other words, and as stated above, the key counter value stored by the receiving node may already match the key counter value used by the transmitting node, or may be updated to match the key counter value used by the transmitting node, depending on the circumstances, via a key update process performed by the receiving node.

[0114] In any case, once the receiving node generates a temporary session key based on the key counter value calculated from CNT 406, this should match the session key used by the transmitting node to generate the secure message before it is received at the receiving node. Assuming the key counter value used by the transmitting node to generate the generated secure message is the same as the key counter value stored locally at the receiving node, the generated session key should also match the session key stored locally at the receiving node. That is, because the transmitting and receiving nodes use the same KDF, key counter value, and shared key, this will produce the same session key output in every case. The receiving node can then use the generated temporary session key to decrypt payload 410 and calculate the ICV using the same cryptographic function used by the transmitting node. Therefore, the receiving node can compare the ICV calculated in this way with ICV 412 to determine that the calculated key counter value derived from CNT 406 is valid, and thus verify the secure message when the ICV matches, and therefore accept the secure message. When the ICV does not match, the receiving node can reject the message because the secure message has not been verified, and therefore the key counter value has not been verified.

[0115] Figure 4B Another security message format and accompanying processing timeline are shown according to one or more embodiments of this disclosure. For example... Figure 4B The security message format shown is similar to the one shown in terms of message format and fields. Figure 4A The same as shown. Therefore, each of fields 452, 454, 456, 458, 460, 462, and 464 can be used as follows: Figure 4A The security messages shown are identified by the same similar fields 402, 404, 406, 408, 410, 412, and 414. However, as... Figure 4B The security message format shown can be used as discussed above by the receiving node upon receiving a message such as... Figure 4A The security message shown is used to identify subsequent security messages transmitted after the security message. Therefore, in receiving and accepting such... Figure 4A When a security message is displayed, the receiving node can store the freshness value (or a portion thereof) in its volatile memory, as shown above and regarding... Figure 2C The above is discussed. Then, the receiving node can increment this freshness value as it transmits subsequent messages, and also store this incremented freshness value in its volatile memory, such as... Figure 2A As shown. This is in Figure 4B It is shown in the form of FV+1 field 458.

[0116] Therefore, a receiving node can become a transmitting node and transmit secure messages, such as... Figure 4BAs shown. To this end, the (current) transmitting node can access the session key from its volatile memory based on the current key counter value and the security field corresponding to the recipient node of the transmitted secure message. As part of this process, the transmitting node can calculate the ICV and encrypt the payload to generate payload 460. The transmitting node also calculates the current SCI based on the security field of the recipient node of the secure message and the counter value representation CNT 456, which is based on the current key counter value used to calculate the session key for that particular security field, as described above. Once the information in each of these fields has been calculated, the transmitting node assembles and transmits the secure message, as described above, wherein this process is repeated as needed for each of the receiving nodes in system 300.

[0117] E. Hardware Implementation Examples

[0118] Figure 5 The use of a hardware-based solution for utilizing freshness values ​​is illustrated according to one or more embodiments of this disclosure. Figure 5 Showing from Figure 4A The communication protocol frame 400 includes multiple fields. The communication protocol frame 400 is identified by a security message generated via a transmitting node. Note that if the freshness value is generated via a software-based method as described above, the transmitting node can reorder the security messages, which are then received out of order by each of the receiving nodes. Although an acceptance window regarding replay attacks could allow receiving nodes to accept such messages, the use of a software-based method incurs considerable processing overhead.

[0119] Therefore, regarding Figure 5 The described solution enables transport nodes to alternatively generate security messages "dynamically," rather than buffering and reordering—the conventional approach to transmitting security messages. For this purpose, transport nodes can implement any suitable type of timer mechanism. For example, each transport node can utilize a timer that represents a predetermined timer value such as 10 microseconds, 5 microseconds, etc., for a tick time. Therefore, the freshness value can still represent a bit string, but these bits can include a binary representation of multiple "clock cycles," where each clock cycle corresponds to a predetermined clock cycle. Figure 2A As shown, this eliminates the need for the transmitting node to store the freshness value for each transmitted security message, assuming the timer counts faster than the message transmission time. In this regard, it should be noted that the freshness value should never be reused for two messages under any circumstances. Therefore, the freshness value discussed herein can generally be implemented as any suitable type of monotonically increasing counter, and as per [the relevant information]... Figure 5 The items discussed may include, for example, clock cycle timers, single sequence number counters, etc.

[0120] Using timestamps for FV can advantageously support systems where security messages are not reordered by buffering schemes at the transport node, and therefore the transport node only needs one security channel. This could be, for example, a case where the security message is generated during its transmission (i.e., done in the hardware linked to the communication protocol engine). This reduces the storage and processing overhead associated with multiple security channels. In this way, hardware-based solutions allow SCI to be simplified to a single fixed channel on the transport node side, as the use of timestamps ensures that FV is always incremented for each security message.

[0121] Therefore, for such Figure 5 The hardware-based solution shown allows the transmitting node to utilize a fixed SCI value corresponding to the unique device address of that specific transmitting node. Therefore, this SCI value is unique throughout the entire system 300. As a result of this modification, the receiving node can additionally or alternatively configure its... Figure 2C Data as shown in Table 500 is stored in the non-volatile memory 204 and / or volatile memory 206. For example, Table 500 represents a mapping from SCI values ​​(i.e., unique transmitting 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 may include unique SCI values ​​corresponding to each transmitting node from which the receiving node is configured to receive security messages; for simplicity, in... Figure 5 The table shows seven SCI values ​​because Table 500 can store any appropriate number of SCI and FV values ​​for the encoded messages received based on a specific application.

[0122] Therefore, the receiving node can implement a hardware-based solution (e.g., via processing circuitry 208.2) configured to scan the data entries in table 500 until a matching SCI value is found for SCI 404. For that table entry (i.e., SCI 5 in this example), the table should contain previous freshness values ​​smaller than the current FV 408. If FV 408 is smaller than the corresponding previous FV in table 500 for SCI 5, the receiving node can reject the message, as it is likely a replay attack. Note that if the table is not large enough to store the necessary number of entries, further matching can be managed by software (e.g., using a hash table).

[0123] Figure 6 This illustration shows another hardware-based implementation of a secure messaging system adapted to existing conventional systems, according to one or more embodiments of this disclosure. For example... Figure 6The architecture 600 shown demonstrates that the implementation described herein is protocol-agnostic. That is, the representation of counter values ​​and the use of session keys within secure messages, as discussed herein, can be implemented independently of existing architectures and communication protocols. For example, architecture 600 includes an existing engine 602, which can include any suitable type of conventional communication engine for use with a real-time control system. Some examples of existing engines 602 may include a CAN bus engine, an Ethernet protocol engine, etc., and any communication protocol discussed herein. Although in Figure 6 The diagram shows a single engine, but Architecture 600 can include any suitable number of different engines, such as a CAN bus engine and an Ethernet engine.

[0124] By way of example, architecture 600 is implemented as an Advanced Scalable Interface (AXI) bus architecture and also includes TX and RX plaintext queue memories for buffering transmission messages carried within the specific system in which the Existing Engine 602 is implemented. Typically, the Existing Engine 602 controls the AXI coupled to the TX queue memory and the transmission buffer 604. Therefore, the Existing Engine 602 is configured to receive messages from the transmission buffer 604 and transmit these messages with unencrypted payloads according to any suitable communication protocol, such as those discussed herein. Furthermore, the Existing Engine 602 is typically directly coupled to the AXI and RX queue memories, and thus the Existing Engine 602 can provide received messages with unencrypted payloads to the RX queue memory for delivery to other nodes in the system.

[0125] However, architecture 600 also includes an Accelerated Real-Time Security (ARTIS) engine 610 and a multiplexer 612. 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. ARTIS engine 610 is configured to perform any or more of the functions discussed herein with respect to the transmit and receive nodes, such as, for example, reading the key counter value representation contained in the secure message, deriving the required session key, performing encryption, authentication, and decryption, etc. ARTIS 610 can advantageously be implemented in hardware rather than software to eliminate the need for secure message reordering and thus minimize latency. This advantageously reduces the window for replay attacks to such a small time period that the risk of replay attacks is essentially eliminated.

[0126] Architecture 600 also includes a multiplexer 612, which is controlled by the ARTIS engine 610 via control signal 601. Therefore, the ARTIS control engine 610 is configured to dynamically change the operation of the system in which it is implemented (e.g., system 300) between insecure and secure message transmission / reception operations. For example, a lower path of multiplexer 612 can be selected to route plaintext data from transmit buffer 604 to the existing engine 602, and in this operating mode, the ARTIS engine 610 can also route received plaintext data to the RX queue memory.

[0127] However, when operating in cryptographic mode, the upper path of multiplexer 612 can be selected. In this mode, plaintext messages are routed from the transport buffer to ARTIS engine 610 and used by ARTIS engine 610 to generate encrypted payloads that are included as part of secure messages, as discussed herein. In this operating mode, secure messages are also routed to the RX queue store and distributed to other receiving nodes in the system, but as secure messages (as opposed to insecure messages generated by the existing engine 602). In this way, architecture 600 allows concurrent operation of existing insecure messaging systems with secure messaging implementations as discussed herein.

[0128] F. Example Processing Flow

[0129] Figure 7A and Figure 7B This illustration shows a processing flow for transmitting and receiving securely encoded messages by transmitting and receiving nodes according to one or more embodiments of this disclosure. (Refer to...) Figure 7A and Figure 7B The processing flow may include methods executed and / or otherwise associated with any suitable number and / or type of components such as one or more processors (processing circuitry), hardware components, executed instructions (e.g., software components), or combinations thereof. Components may be associated with one or more components as discussed herein, such as node 200. Flows 700, 750 may include, for the sake of brevity, […]. Figure 7A and Figure 7B The alternative or additional boxes are not shown, and can be executed in a different order than those shown. Furthermore, some boxes may be optional.

[0130] Specifically, Figure 7A Additional details are provided regarding the processing implemented by the transport node when generating and transmitting secure messages. Figure 7B Additional details are provided regarding the processing implemented by the receiving node for verifying the key counter value in the received security message to accept or reject the security message.

[0131] First refer to Figure 7AWhen performing secure message transmission, processing flow 700 can be implemented via any of the nodes discussed herein, such as any node included in system 300, for example. This can include, for example, any node discussed herein. Figure 2A The node under discussion is 200.

[0132] Processing flow 700 begins with the transmission of a security message (box 702). The security message can be formatted according to any suitable communication protocol and includes any suitable number of fields, such as those described herein. Figures 4A to 4B The communication frames discussed.

[0133] When transmitting a security message, processing flow 700 includes incrementing a freshness value via the transmitting node (box 704). This may include, for example, processing circuitry 208.2 incrementing a locally stored freshness value (e.g., FV.A, FV.B, FV.C, etc.) based on a specific security domain corresponding to the intended recipient node, such as... Figure 2A As shown. Therefore, the freshness value that increments in this way can be associated with one or more session keys used for that particular security domain, as discussed in this paper.

[0134] Processing flow 700 also includes determining (block 706) whether key update conditions have been met. These conditions may include any suitable predetermined conditions that, when met, cause the key counter to increment, as discussed further herein, assuming that a priority flag (if implemented) is not set. Such conditions may include, for example, the number of security messages transmitted using the corresponding session key exceeding a predetermined number of messages, the expiration of a predetermined time period, each system startup, receiving a security alert request, etc.

[0135] As an illustrative example of session key exhaustion, determining whether the number of secure messages transmitted using the corresponding session key has exceeded a predetermined number of messages may include determining (box 706) whether the current (now increasing) freshness value exceeds a predetermined threshold. This predetermined threshold can be chosen as any suitable value that triggers key update processing due to session key exhaustion, as discussed herein. For example, the threshold freshness value could be in the millions or billions.

[0136] Therefore, if a key update condition is met (e.g., the incremented freshness value exceeds a predetermined threshold), the transport node performs local key update processing (box 708) on the key counter value. Thus, using security domain A above as an example, which is assumed to be used for the current secure message transmission, this could include session key generator 202 incrementing (box 708) key counter A.1 and overwriting NVM 204 with this new, updated key counter value (e.g., key counter A.1 + 1, not shown). Furthermore, when a key update event occurs, the transport node can reset its locally stored freshness value, transmitted in the next secure message, to its predetermined or default value (e.g., 1), and then increment that value for subsequent transmitted messages as described herein.

[0137] Processing flow 700 also includes resetting the freshness value of the security domain (box 710) back to the default or initial value, which is 0 in this example. Therefore, continuing with the previous example, the freshness value FV.A will be reset to 0 (or other suitable initial value).

[0138] Processing flow 700 also includes generating (box 712) an updated session key from an incrementing key counter value. This may include, using security domain A as an example, the session key generator 202 calculating session key A.2 from shared key A and the incrementing key counter value based on the KDF, as shown below. Figure 2B As shown. Then, the updated session key A.2 can be used to overwrite... Figure 2A The previous session key A.1 shown may be invalidated for future secure transmissions in any way. For example, the updated session key A.2 may be stored in a new location in volatile memory 206, or the contents of session key A.1 may be overwritten.

[0139] Processing flow 700 may include generating (box 714) a secure message. This may include, for example, processing circuitry 208.2 generating a secure message with any suitable number of fields as discussed herein. If it is determined (box 706) that the freshness value is less than a threshold, the secure message may be generated in this manner using the original session key (e.g., session key A.1), or alternatively, when it is determined (box 706) that the freshness value is greater than the threshold, an updated session key (e.g., session key A.2) may be used, thereby updating the key counter and the session key. In any case, the current session key may be used to generate the secure message to encrypt the payload of the secure message, transmit the secure message as an authentication-only message, or transmit the secure message as an authentication and encryption message. Again, the session key may be one of several keys (e.g., one for authentication and another for encryption). In this case, processing flow 700 may be extended to selectively update any suitable number of session keys corresponding to the same freshness value.

[0140] Processing flow 700 may include queuing the generated security messages (box 716). This may include, for example, communication circuitry 208.1 adding the security messages to a queuing buffer for transmission in an appropriate order based on message sending / receiving priorities (box 702). Alternatively, if as described above regarding... Figure 5 Implementing a hardware-based solution as discussed eliminates the need for a queuing buffer and allows the transmission of security messages (box 702) as security messages are generated (box 714). Therefore, a repetitive processing flow 700 can be transmitted for each security message transmitted via the transmission node, with the processing flow 700 applied to each subsequent security message transmission.

[0141] Now refer to Figure 7B When receiving a security message transmission, processing flow 750 can be implemented via any of the nodes discussed herein, such as any node included in system 300, for example. This can include, for example, when used as a receiving node, as discussed herein. Figure 2A The node under discussion is 200.

[0142] Processing flow 750 begins with receiving (box 752) a security message. Similarly, the security message can be formatted according to any suitable communication protocol and include any suitable number of fields, such as those described herein. Figures 4A to 4B The communication frames discussed.

[0143] Processing flow 750 further includes determining (box 754) whether a message counter, such as a key counter value represented by CNT 406 as discussed herein, is less than a locally stored key counter value corresponding to the security domain where the security message is sent and received. This determination may include, for example, comparing a representation of the key counter value encoded by CNT 406 with a locally stored key counter value for the same security domain. For example, CNT 406 may represent a predetermined number of least significant bits of a key counter value used by the transmitting node to generate an encoded message before it is received. In this case, the determination (box 754) may then include a comparison via processing circuitry 208.2 between the same predetermined number of least significant bits corresponding to the locally stored key counter value for the current security domain. Alternatively, if the entire key counter value is represented by CNT 406, the determination (box 754) may include a comparison via processing circuitry 208.2 between the locally stored entire key counter value and the entire key counter value represented by CNT 406 for the current security domain.

[0144] In any case, if it is determined that the key counter value derived from CNT 406 is less than the key counter value locally stored in the security domain, the processing flow 750 includes conditionally approving or rejecting the derived key counter value. For example, as described above, the processing flow 750 includes further determining (box 755) whether the key counter value derived from CNT 406 is within a predetermined grace period. Again, this grace period may represent the time period that has elapsed since the last distinct key counter value was received, and may additionally or alternatively be calculated based on a freshness value associated with the key counter value derived from CNT 406.

[0145] If the key counter value derived from CNT 406 is outside the grace period, the process includes rejecting (box 756) the security message. That is, in this case, the receiving node determines that the key counter value represented by CNT 406 is invalid and therefore rejects the security message because this indicates a replay attack, an expired message, or a corrupted message.

[0146] If the key counter value derived from CNT 406 is within the grace period (box 755, Yes) or the key counter value derived from CNT 406 is not less than the locally stored key counter value of the security domain (box 754, No), the process 750 continues and includes another determination regarding whether the opposite condition is true (box 758), i.e., the key counter value derived from CNT 406 is greater than the locally stored key counter value of the security domain. If this is not the case, it means that the key counter value derived from CNT 406 matches the locally stored key counter value of the security domain, and the process 750 proceeds accordingly.

[0147] However, if the key counter value derived from CNT 406 is greater than the locally stored key counter value for that security domain, the locally stored key counter value expires, as described above. Therefore, the leftmost branch of processing flow 750 corresponds to conditional local (i.e., at the receiving node) key update processing. That is, in this case, the receiving node can update its locally stored key counter value only if it is determined via additional message verification processing that the key counter value represented in CNT 406 is valid.

[0148] For example, when the receiving node determines that the locally stored key counter value has expired (box 758, Yes), process flow 750 includes generating (box 760) a temporary session key. To do this, the receiving node uses the full-length key counter value that the transmitting node used to generate the received security message. Therefore, where CNT 406 represents the truncated portion of the full-length key counter value used by the transmitting node to generate the security message, the receiving node can derive the full length of the key counter value through computation. For example, the receiving node (e.g., processing circuitry 208.2) can concatenate the untruncated portion (e.g., the most significant bits) of the locally stored key counter value with the remaining truncated portion (e.g., the least significant bits) of the full length of the key counter value represented by CNT 406.

[0149] Once the full length of the key counter value is obtained from CNT 406, the process for generating (box 760) the temporary session key is the same as that used for generating a locally stored session key by both the receiving node and the transmitting node. Therefore, the receiving node uses the same KDF and the transmitting node uses (or should have already used) other inputs to generate the temporary session key. Specifically, the full key counter value, along with the shared key corresponding to the current security domain stored locally by the receiving node, is used as one of the inputs to the KDF.

[0150] In this way, the full length of the key counter value calculated in this manner can be verified by using a temporary session key to decrypt the payload of the secure message, calculating the ICV value, and then comparing the calculated ICV value with the ICV 412 contained in the secure message. Therefore, the ICV will only match if the key counter value used to generate the secure message is valid (box 762, Yes). If it does not match (box 762, No), the processing flow 750 includes the receiving node rejecting the secure message (box 756).

[0151] Therefore, when ICVs match, the receiving node stores (box 764) the updated key counter value in NVM 204, overwriting 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. Similarly, this key counter value is used by the transmitting node to generate the session key, and further to generate the current security message. For example, if the receiving node previously stored key counter A.1, such as... Figure 2A As shown, after this processing, both the receiving node and the transmitting node will store the key counter A.1+1.

[0152] Additionally, processing flow 750 includes storing (box 766) a temporary session key generated (box 760) based on the full-length key counter value derived from CNT 406 as described above, as an updated local session key for the receiving node. For example, if the receiving node previously stored such... Figure 2AGiven the session key A.1, after this processing, both the receiving node and the transmitting node will store the session key A.2 generated using the key counter A.1+1, as shown. Figure 2B As shown.

[0153] Processing flow 750 also includes updating (box 768) the local freshness value to match the freshness value received in the security message. For example, if the receiving node previously stored, such as Figure 2A The freshness value FV.A shown indicates that after this processing, both the receiving node and the transmitting node will store a freshness value of FV.A+1. Additionally, as shown... Figure 2C As shown, the receiving node can update the received FV log 206.1 to store the FV from the security message A.2 associated with the key counter value and security domain, as described above.

[0154] Processing flow 750 also includes receiving a security message as the final step in the process, since the key counter value has been verified and the freshness value has been updated as a result of the local key update process.

[0155] As described above, when the receiving node determines (box 758, no) that the key counter value derived from CNT 406 matches the key counter value stored locally in the security domain, processing flow 750 proceeds accordingly. This includes verifying the key counter value derived from CNT 406 based on an ICV comparison. Specifically, the receiving node can generate a session key based on the key counter value derived from CNT 406, or alternatively, use the locally stored session key to decrypt the payload content, calculate the ICV, and then determine (box 770) whether the ICVs match. Again, if they do not match, the security message is rejected.

[0156] Otherwise, the process continues to determine (box 772) whether the freshness value contained in the security message is greater than the freshness value stored locally by the transport node and the security domain, for example, such as Figure 2C The FV is shown in the log. If so, the receiving node rejects the security message. If not, the processing flow includes updating the locally stored FV with the FV contained in the security message (box 768), as described above, and accepting the security message (box 776). Therefore, processing flow 750 can be repeated for each security message received via the receiving node, wherein processing flow 750 is applied to each subsequent security message received.

[0157] II. Secure communication utilizing real-time member tracking

[0158] Similarly, replay attacks can include both strong and weak types. As discussed in Part I above, a strong replay attack can involve a node legitimately receiving a message once (i.e., accepting a verified secure message) and then subsequently accepting another maliciously generated secure message from an attacker. For example, such a strong replay attack could allow an attacker to store a previously sent "disable anti-theft device" security message and then send that same message at a later time. The use of the real-time bus key distribution system described in Part I is designed to eliminate or at least significantly reduce the likelihood of such strong replay attacks.

[0159] However, this section provides additional implementations as supplementary security measures against weak replay attacks, which can be used in conjunction with and / or in combination with those additional uses described in Section I above. Weak replay attacks are associated with techniques designed to disconnect or otherwise force a node offline for a period of time to exploit other nodes' lack of knowledge of this. For example, a weak replay attack can be performed by partitioning the bus in a system used for secure communication. As a result, the target node is subsequently unable to receive the initially transmitted secure message from other nodes, but instead receives the secure message later when it comes back online at a time useful to the attacker. For example, in a real-time control system used in an automotive environment, a node might not receive the transmitted secure "unlock door" message, but instead receives the same message when an attacker forwards the message to unlock the door while driving.

[0160] Weak replay attacks raise specific security issues regarding disconnected nodes that have been reset. For example, and as mentioned above... Figure 7B As described, upon reconnecting to the network after a reset, the receiving node will accept security messages from other nodes that have a key counter value greater than the key counter value stored locally by the receiving node. This allows an attacker to launch a weak replay attack by partitioning the network, resetting nodes, and then replaying old secure traffic from other nodes. The implementation described in this section addresses this problem by using real-time member groups. Specifically, the implementation described in this section enhances the real-time bus key distribution system described in Part I to discover which nodes are currently online, i.e., "active". Therefore, a reset node can refuse to accept security messages from non-members whose online status has not been verified, or from members in the same group, even if, according to, for example, the above regarding... Figure 7B In the processing flow 750 described in Part I, the security message would normally be accepted.

[0161] The member groups discussed herein can include any suitable number of nodes within an interconnected node system as described in Section I above. This can include, for example, those mentioned above. Figure 3The entire interconnect node system 300 is shown and discussed. Alternatively, member groups may include smaller subsets of the interconnect node system 300. Thus, the interconnect node system 300 may include any suitable number of member groups, each with any suitable number of nodes as part of its respective member group. Member groups may include nodes that overlap with other member groups, such as security domains as described above. Thus, member groups can be defined according to any suitable node grouping, which may be the same as or different from the security domains discussed herein. When a member group differs from a security domain, both the member group and the security domain may simultaneously form part of the interconnect node system 300. In any case, member groups as discussed herein may be predetermined relative to the interconnect node system 300, and therefore each node 200 as described herein may be configured to operate using this information, which is further deprecated below.

[0162] A. Real-time member security message format

[0163] Figure 8 Example formats of security messages for requesting and responding to online status verification requests, according to one or more embodiments of this disclosure, are shown. Figure 8 The security message format shown can correspond to security messages transmitted and received according to any suitable communication protocol, and can constitute a communication protocol frame including any suitable number of fields. Communication protocol frames 800 and 850 may include, and are also included in, several fields in communication protocol frames 400 and 450, as described above. Figure 4A and Figure 4B As shown and discussed above in section I, communication protocol frames 800, 850 can also be identified by any suitable type of communication protocol, which can be implemented to facilitate secure message communication via multi-point branch or point-to-point bus architectures.

[0164] Communication protocol frame 800 may, for example, correspond to a communication frame identified by a security message, which is initially transmitted via node 200 when acting as a transmission node. Therefore, to support the use of real-time members as discussed in the embodiments provided in this section, processing circuitry 208.2 is configured to generate communication protocol frame 800, which is transmitted via communication circuitry 208.1, as described in section I above. In the context of the member group discussed in this section, a node requesting online verification from other nodes may alternatively be referred to herein as a “challenge” node, and a request for online verification may alternatively be referred to herein as a “challenge request” or simply “challenge.” Additionally, any node that receives a security message including an online verification request from other nodes and then responds to that request may alternatively be referred to as a “response” node. It should also be noted that although the concepts of challenge node and response node are separated herein for the purposes of brevity and ease of explanation, a node can function as both a challenge node and a response node simultaneously. The interaction between challenge nodes and response nodes and their functions are further discussed below.

[0165] It should be noted that the implementations described in this section utilize typical traffic occurring in a system of interconnected nodes. That is, the implementations described in this section can implement the use of additional information encoded and added to security messages, as discussed in Section I above, to request online verification from other nodes and to respond to such requests. Therefore, requests for online verification (i.e., challenges) and responses to such requests can occur through the normal transmission of security messages between nodes. This advantageously allows for the verification of a node's online status without the use of dedicated messages, ensuring that challenges and responses do not burden communication bandwidth.

[0166] To this end, communication protocol frame 800 includes an RSVP field 802 as shown in the figure, which includes a representation of the query value. Therefore, the query value can be represented as any suitable encoded value indicating whether a node is requesting online status verification from any other node within the member group. It should be noted that the query value can be encoded in an indiscriminate manner by any node in the member group; that is, a challenge request using the query value can be delivered via, for example, a secure message transmitted to multiple interconnected nodes through a multi-point branching scheme as discussed herein.

[0167] For example, depending on whether a node requests online verification from other nodes in the same member group, the query value can include different predetermined values. That is, the query value can be identified by a default predetermined value indicating that a node is not requesting an online verification request. Alternatively, in this case, the content of the RSVP field 802 may be left blank, and / or the RSVP field 802 may not be included in the communication protocol frame 800 when no online verification request is made. Therefore, when a node requests an online verification request from other nodes, the query value can include predetermined values ​​recognized by other receiving nodes in the member group.

[0168] To provide an illustrative example, the query value may include any suitable encoded value that uniquely identifies the transport node requesting the online verification request from other nodes. This unique identifier may include any suitable value known to other nodes in the member group through the initial configuration and setup process. For example, if node 200 is identified as node 5, the query value may represent the encoded representation of "5" when node 200 is requesting the online verification request from other nodes, and otherwise may be set to "0".

[0169] To provide another illustrative example, RSVP field 802 could contain a single binary value that is set to a value (e.g., 1) when the challenging node is requesting online verification from another node, and otherwise set to a different value (e.g., 0). Therefore, the query value does not need to identify the challenging node, but can simply identify that the challenging node is requesting an online verification request from another node. In this case, each responding node can determine the identity of the node 200 from which it receives the security message in any suitable manner. This identification can be performed, for example, by identifying data that may be contained in other fields of the communication protocol frame 800, which are populated by node 200 as each security message is transmitted according to the specific communication protocol used.

[0170] Therefore, it should also be noted that, although in Figure 8 The diagram illustrates that communication protocol frames 800 and 850 use a dedicated RSVP field 802 to provide a representation of the query value, but this is by way of example and not limitation. In other embodiments, the representation of the query value may be included in an alternative field of the communication protocol frames 800 and 850, thus eliminating the need for the dedicated RSVP field 802. For example, the representation of the query value may be included in a portion of header 452 or form part of payload 410.

[0171] Communication protocol frames 800 and 850 also include a Response (RESP) field 804, which is filled by the responding node in a subsequently transmitted security message. The RESP field 804 may include encoded data indicating whether a node in the member group has affirmatively responded to any appropriate indication of an online status verification request transmitted from other challenging nodes. As described above with respect to the RSVP field 802, ... Figure 8 As shown, the encoded data contained in the RESP field 804 can be included in an alternative field of the communication protocol frames 800 and 850, thus eliminating the need for a dedicated RESP field 804. For example, the encoded data contained in the RESP field 804 can be included in a portion of the header 452 or form a portion of the payload 410.

[0172] The RESP field 804 can include, for example, any suitable type of mapping that uniquely identifies each node in the member group. For example, and refer to... Figure 8 The member group may include 16 nodes within the interconnected node system 300. As mentioned above, each of these 16 nodes can be uniquely identified in any suitable manner known to the other nodes. Therefore, the RESP field 804 may include a bit string (e.g., a bit array), where the position of each bit in the bit string corresponds to each corresponding node in the member group. In other words, each bit in the bit string identifies a different node in the member group through a corresponding predefined bit position within the bit string. For example, Figure 8 The example communication protocol frame 850 shown has the rightmost bit corresponding to node 0 and the leftmost bit corresponding to node 15.

[0173] Therefore, each bit position in the RESP field 804 corresponds to a value indicating whether each corresponding node has affirmatively responded to an online status verification request from one or more other nodes in the member group. Thus, the predetermined bit positions in the RESP field correspond to each of the nodes that have requested online status verification. Therefore, each node in the member group that receives an online status verification request from other nodes can set the bit value of the bit position associated with each corresponding challenging node to a different predetermined value (e.g., "1"). In this way, the value of each bit in the RESP field 804 is based on the value set by each node in response to a challenge request from any other node in the member group. Therefore, and continuing to refer to... Figure 8 Communication protocol frame 850 indicates that nodes 5, 10, and 14 have requested online verification from each node in the member group.

[0174] To populate the RESP field 804, each node in the member group can maintain a log of online verification requests received from other nodes. For example, node 200 may include an online verification request log 207, as such... Figure 2AThis is part of the volatile memory 206 shown, or alternatively, part of the non-volatile memory 204 (not shown). Therefore, each responding node can store a bit string or other suitable set of encoded values ​​corresponding to the RESP field 804 in the online verification request log 207. For example, the online verification request log 207 can store the same bit string as the RESP field 804, where each bit position in the locally stored bit string corresponds to an indication of whether each node in the member group has requested an online verification request. Similarly, this is determined by the representation of the query value contained in the security message transmitted by each node (e.g., via the RSVP field 802).

[0175] Again, and using, as Figure 8 The convention shown in the example assumes that a node has received an online verification request via security messages received from each of the identified nodes 5, 10, and 14. These security messages may be received over a period of time, and therefore processing circuitry 208.2 may update the contents of the locally stored online verification request log 207 upon receiving each security message. The number of security messages that can be received in this manner before generating the next scheduled security message using the padded RESP field 804 can be any threshold number of security messages based on configuration, available bandwidth, number of nodes in a member group, etc. In any case, for each security message received with a representation of a query value indicating (e.g., via the RSVP field 802) a challenge request, processing circuitry 208.2 accumulates the contents of the locally stored online verification request log 207 to represent each of these incomplete requests.

[0176] Therefore, before the node populates the RESP field 804 in response to these online verification requests, the local bit string stored in the online verification request log 207 may include... Figure 8 The same content is shown in the RESP field 804. As a result, when a node in the member group transmits a security message in response to an incomplete challenge, the node copies the contents of the online verification request log 207 (e.g., via processing circuitry 208.2) into the RESP field 804, as shown. Figure 8As shown. Furthermore, once the security message is transmitted using the padded RESP field 804, the responding node is configured (e.g., via processing circuitry 208.2) 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 online verification requests from other nodes awaiting processing. For example, the locally stored online verification request log 207 could be reset to store a string of all zeros. Therefore, continuing with this example, when there are no pending challenge requests for online status verification, each node in the member group can transmit its corresponding RESP field with all zeros, i.e., the current contents of its locally stored online verification request log 207.

[0177] Similarly, each node in the member group can be related to the above about Figure 2A Node 200 operates in the same manner as described herein. To provide an illustrative example regarding communication protocol frame 850, node 200 may receive several security messages over time. Based on these security messages, challenge requests for online authentication are received from nodes 5, 10, and 14 via the corresponding security messages. Therefore, node 200 may receive security messages via communication circuitry 208.1 in any suitable manner (e.g., via a bus such as the multipoint branch bus described above), and then process the security messages via processing circuitry 208.2 to accept or reject them as discussed further in detail herein.

[0178] Therefore, although a single responding node can be used as an example throughout this section for ease of explanation, it should be noted that each node receiving the challenge message can respond to such a request individually. Although referred to as a "response," it should be understood in this context that each responding node does not need to transmit a dedicated security message in response to such a request. Instead, each responding node can populate its own RESP field 804 as part of the next scheduled security message to be transmitted. Again, to provide the content of the RESP field 804, each node can modify the content of its locally stored online verification request log 207 upon receiving an additional security message (e.g., via processing circuitry 208.2). Thus, the content of the online verification request log 207 at any given time indicates which nodes have requested currently incomplete online verification requests (i.e., awaiting a response via the population of the RESP field 804 in the transmitted security message).

[0179] Therefore, and continuing this example, each responding node can populate the RESP field 804 when generating the next scheduled security message, which is transmitted to and received by each of the nodes in the member group, including nodes 5, 10, and 14. In this way, the security message itself is not generated in response to receiving an online verification request via several security messages. Instead, in response to receiving an online verification request from one or more challenging nodes, the RESP field 804 is populated as part of the generation of the next scheduled security message to be transmitted. In this way, a responding node can simultaneously respond to challenge requests from any number of nodes (e.g., all nodes) in the member group from which it has received online verification requests via a single transmitted security message. By using existing security message scheduling architectures and without needing to send dedicated messages in this manner, nodes can respond to online verification requests very quickly (e.g., hundreds of microseconds, such as 100, 200, 300 microseconds, etc.), especially for hardware implementations such as those discussed above in Part I. Taking advantage of this further, in the real-time member implementation described in this section, all responding nodes can respond to a challenge no later than their shortest period frame time plus their delay (typically <20ms). This advantageously allows for 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.

[0180] Furthermore, because each responding node responds to an online verification request only if it is online via a padded RESP field 804, the RESP field 804 in each security message received by the challenging node allows the challenging node to infer (i.e., determine) the online status of each responding node within the group. To provide an illustrative example, if a security message containing the RESP field 804 is lost, the requesting node (i.e., the node that issued the challenge request) will need to re-request online status verification to confirm its offline status. For the CAN XL protocol, messages are not lost by default (i.e., the protocol itself will retransmit messages corrupted by noise). For Ethernet-based systems, if a threshold number of challenge requests (e.g., two, three, etc.) are not answered, the requester can infer that a node is offline.

[0181] However, in addition to the inference of node online status as described above, a node requesting online verification from other nodes can perform additional verification based on the content of the RESP field 804. For example, once a security message including the content of the RESP field 804 is transmitted, each node in the member group receives that security message, including the node that requested the online verification request and the node that did not request the online verification request. Therefore, each node that requested the online verification request (e.g., nodes 5, 10, and 14 in the example above) can then determine whether each node in the member group has responded affirmatively to these requests via the content of the RESP field 804 populated by each responding node.

[0182] For example, the communication circuit 208.1 of node 200 is configured to receive a security message from each node in the member group, with the RESP field 804 populated based on a previous online status verification request. The receiving node (previously the challenging node) can then determine whether each node in the member group that responded to the previous verification request is online based on the content of the RESP field 804. For example, and continuing the example provided above, node 5 can compare the content of the bit at node 5's location with a predetermined value (e.g., a bit value of 1) to determine whether the responding node in the member group has correctly identified its online status in response to the request. Continuing this example, if a node in the member group responds with a security message that includes a "1" at that bit position in the RESP field 804 after transmitting a security message requesting online verification, node 5 will determine that the node is online and active. Otherwise, node 5 will determine that the responding node is actually offline and faulty, or that the message was sent by an untrusted source, such as an attacker attempting a weak replay attack. Alternatively, node 5 can determine whether a security message with a challenge request is lost / corrupted or a security message with a response from a responding node is lost / corrupted (however, for CAN XL, as mentioned above, this typically does not occur).

[0183] The comparison of the contents of the RESP field 804 can be performed in any suitable manner, which may include a software-based implementation of processing circuitry 208.2 (or other suitable processor) that executes instructions from program memory 208.3 (or other suitable memory). However, given the example of the single-bit encoded format of the RESP field 804, it may be particularly advantageous to use a hardware-based solution, such as logic gates and / or any other suitable hardware, to compare the contents of the RESP field 804 to determine the online status indication of the responding node. Such hardware may, for example, be implemented as part of communication circuitry 208.1, processing circuitry 208.2, etc.

[0184] It should also be noted that each node in a member group can function in such a way that it sends online verification requests to other nodes via a representation of the query value, responds to these requests using the RESP field 804, and verifies whether each node is online based on the content of the RESP field 804. For example, each challenging node in a member group can determine whether other nodes within the member group are online. This is facilitated by the challenging node (e.g., via processing circuitry 208.2) determining whether a bit in the bit string received for each security message corresponds to a predefined bit position of the challenging node. Thus, the challenging node verifies whether the responding node is online based on whether the value of that predefined bit position correctly indicates that the challenging node has previously requested online status verification. In this way, the encoded value of the predefined bit position of the challenging node can represent a value (e.g., "1") indicating an affirmative response from each responding node to a previous online status verification request.

[0185] In any case, each node in the member group can accept or reject a security message based on its response to a previously transmitted online status verification request. Again, such a response may include padding in the RESP field 804. Therefore, the decision to accept a security message can be based on the node's inferred online status, which has transmitted a security message with padding in response to the online status verification request as described above. Alternatively, the decision to accept a security message can be based on the node's online status, determined via padding in the RESP field 804 indicating that the challenging node previously sent an online status verification request, or other suitable mapping. In this way, each node in the member group can determine whether to accept a security message based on the determination of whether each corresponding responding node is online. See below. Figure 9B Let's discuss this conditional acceptance of security messages in more detail.

[0186] Regardless of how the online status of other nodes is determined, the implementation includes node 200 maintaining a log of the online status of other nodes in the member group in any suitable manner. For example, each node in the member group may maintain an online status log relative to other nodes in the member group. To this end, node 200 may include an online status log 209 as such Figure 2A This is part of the volatile memory 206 shown, or alternatively, part of the non-volatile memory 204 (not shown). Therefore, each node in the member group can store in the online status log 209 a bit string or other suitable set of values ​​mapped to the current online status of each node in the member group at a specific time. For example, the online status log 209 can store a bit string similar to the online verification request log 207, where each bit position in the locally stored bit string corresponds to an indication of whether each node in the member group is currently online (e.g., "1") or offline (e.g., "0").

[0187] In this implementation, each node in the member group is configured (e.g., via processing circuitry 208.2) to determine the current online status of each node in the member group based on any suitable number of received security messages. For example, the online status determination can be based on each security message received when each security message is received from each responding node. This determination may include, for example, the accumulation of bit values ​​corresponding to the content of the RESP field received from each responding node. To provide an illustrative example, node 5 may transmit a security message requesting online verification from each node in the member group via the content of the RSVP field 802. Then, each of the other 15 nodes in the member group may transmit a security message including the padding content of the RESP field 804, the padding content of the RESP field 804 including, for example, Figure 8 Bit 5 (and possibly additional bits) in the RESP field shown is set to the value "1", which indicates an affirmative response to node 5's online challenge request. When each of these security messages is received from other nodes, node 5 can thus accumulate bit values ​​from the same pre-defined bit position in the RESP field 804 corresponding to node 5 in each security message. As bit values ​​are accumulated in this way, they are then mapped to pre-defined bit positions 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 equal to "1" at the pre-defined bit position corresponding to each of the other 15 nodes. In this way, the content of the online status log 209 node corresponds to the accumulation of bit values ​​from the RESP field 804 in multiple received security messages.

[0188] Additionally, the implementation includes resetting the value of each bit in the online status log 209 to a predetermined value in response to the fulfillment of any suitable condition. For example, the bit values ​​of the online status log 209 may be reset periodically, or when the number of rejected security messages exceeds a threshold number. To provide another example, the bit values ​​of the online status log 209 may be reset after a threshold time period has elapsed since the bit values ​​of one or more nodes have been updated. In this way, the online status of each node in the member group can be maintained via the content of the online status log 209. Once the bit values ​​of the online status log 209 are reset in this manner, a node in the member group can then perform another request for online verification from a node in the member group via another transmitted security message by filling in the RSVP field 802 as described above. To provide an illustrative example, a node may issue another request for online verification challenge midway through the reset period, resulting in a continuous “online” status that is periodically refreshed. In this way, the online status can be used to accept / reject messages to prevent gaps in the status from causing security messages to be discarded.

[0189] Furthermore, it should be noted that online status verification requests can be particularly useful when a challenge node is reset and re-enters the network, although the implementation is not limited to this specific scenario. Online status verification requests can be sent from any node within the member group at any suitable time, which can be triggered, for example, in response to the fulfillment of one or more conditions. For instance, online nodes in the member group can periodically (e.g., every 100ms, every 500ms, etc.) transmit online status verification requests to determine the status of the bus and / or other nodes in the member group.

[0190] This can be particularly useful, for example, as a diagnostic tool. For instance, if no node responds to a challenge, the challenging node can determine that no other node in the member group is currently online and / or that the transmitted security message with the challenge was lost. Furthermore, if a specific node in the member group does not respond via the lack of a positive response in the RESP field 804, it can be determined that the node is offline or its response was lost. Additionally, if traffic is still observed from nodes identified as offline, these nodes are likely being spoofed using replay traffic.

[0191] Similarly, the use of the real-time membership implementation discussed in this section can implement any communication protocol as described in Section I above. However, the real-time membership implementation discussed in this section can offer specific advantages when used according to Ethernet or Ethernet-based protocols. This is because CAN XL provides atomicity, and therefore, if a frame is marked as sent, each online node has successfully received the frame. Atomicity thus makes detecting offline nodes much easier, as the challenge does not disappear. However, it should be noted that Ethernet protocols do not provide atomicity in this respect, and therefore frames are often dropped. Therefore, management algorithms need to handle lost frames, which are typically retransmitted. The real-time membership implementation described in this section advantageously allows for Ethernet implementations that eliminate or reduce the complexity of such management algorithms by verifying the online status of other nodes in the membership group and maintaining a status log of this information.

[0192] B. Real-time Member Processing Flow

[0193] Figures 9A to 9B This illustration shows a processing flow for a node to transmit and receive security messages, according to one or more embodiments of this disclosure. (Refer to...) Figures 9A to 9BThe processing flow may include methods executed 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. Components may be associated with one or more components of node 200 as discussed herein, and may represent a software-based implementation, a hardware-based implementation, or a combination thereof.

[0194] Specifically, Figure 9A Additional details are provided regarding the processing implemented by the nodes for generating and transmitting secure messages. Figure 9B Additional details are provided regarding the handling implemented by the nodes for accepting or rejecting received security messages and, where applicable, responding to challenge requests. It should be noted that the process 900 can be identified by transmitting security messages via a challenging node or a responding node, or alternatively, a node can function as both a challenging node and a responding node simultaneously.

[0195] Furthermore, processing flow 950 can be identified by receiving and optionally transmitting a security message by either a challenging node or a responding node. Similarly, in either case, a node can function as both a challenging node and a responding node simultaneously. For example, a challenging node can later receive a security message from a responding node, making processing flow 950 about receiving a security message from a node that responded to a previous challenge request. Therefore, flows 900 and 950 can include, for simplicity purposes, […]. Figure 9A and Figure 9B The alternative or additional boxes are not shown, and can be executed in a different order than those shown. Furthermore, some boxes may be optional depending on the specific function of the node at a given time.

[0196] First refer to Figure 9A When performing secure message transmission, processing flow 900 can be implemented via any of the nodes discussed herein, such as any node included in system 300, for example. This can include, for example, any node discussed herein. Figure 2A The node 200 under discussion. Processing flow 900 may include elements related to the above regarding... Figure 7A The processing flow discussed in Part I is executed in the same way as several boxes in 700. For the sake of brevity, these common boxes are represented by, for example... Figure 7A and Figure 9AThe sub-process 700.1 is shown in block 900. Therefore, process flow 900 illustrates how a node can use the processing as part of sub-process 700.1 to transmit (block 902) a security message. Furthermore, blocks 902, 914, and 916 are considered similar to blocks 702, 714, and 716, respectively. Therefore, the functions of blocks 902, 914, and 916 can be the same as or substantially similar to the functions previously described with respect to blocks 702, 714, and 716. For brevity, only the differences between these functional blocks will be discussed in further detail.

[0197] like Figure 9A As shown, for ease of explanation, as Figure 7A The two arrows leading out of subprocess 700.1 shown have been merged into a single arrow. Therefore, it is still based on... Figure 7A The same condition for sub-process 700.1 shown is that processing flow 900 generates (box 914) a security message. However, processing flow 900 includes additional boxes 914.1 and 914.2, which are identified by the generation of a security message (box 914).

[0198] For example, such as Figure 9A The generation of the security message shown (box 914) includes the generation of a representation of the query value (box 914.1). As described above, this can include any suitable query value indicating whether a node is requesting an online verification request from other nodes in the member group. For example, the representation of the query value can include a binary or encoded value that identifies the node, which can form part of the RSVP field 802 as described above.

[0199] like Figure 9A The generation of the security message shown (box 914) also includes generating (box 914.2) one or more encoded values ​​that indicate (when set) a response to a current request (i.e., a challenge) for online authentication from any other node in the member group. Therefore, although for ease of explanation, in Figure 9A Not shown, but a node may have already received a security message from other nodes challenging a node with its own challenge request before transmitting (box 902) a security message with its own challenge request. Similarly, and as described above, the encoded values ​​provided in the security message may include any suitable value set by the (currently transmitting) node and represent an affirmative response to each incomplete challenge request received from other nodes in the member group. For example, the generation of one or more encoded values ​​(box 914.2) may include populating the RESP field 804 in response to these online verification requests, as described above. The RESP field 804 may be populated, for example, by the node copying the contents of the local online verification request log 207 to the RESP field 804, as described herein.

[0200] Once a security message is generated (box 914), it can be queued (box 916) and transmitted (box 902) to, for example, a bus, as described herein. After transmitting the security message (box 902), the node can then reset (box 904) the contents of its local online authentication request log 207 to a predetermined state (e.g., all zeros), which it will remain in until it receives an additional challenge before transmitting (box 902) the next security message. However, it should be noted that resetting (box 904) the contents of the local online authentication request log 207 is optional, as this will not occur if the node does not respond to any incomplete challenge requests via the filling of the RESP field 804.

[0201] Now go to Figure 9B When a security message is received, processing flow 950 can be implemented via any of the nodes discussed herein, such as any node included in system 300, for example. This can include, for example, the nodes discussed herein. Figure 2A The node 200 under discussion. Processing flow 950 may include elements related to the above regarding... Figure 7B The processing flow 750 discussed in Part I is executed in the same way as several boxes. For the sake of brevity, these common boxes are represented by, for example... Figure 7B and Figure 9B The sub-process 750.1 is shown in block 950. Therefore, process flow 950 shows that a node can use the processing incorporated into sub-process 750.1 to receive (block 952) a security message. Furthermore, blocks 952, 976, and 956 are considered similar to blocks 752, 776, and 765, respectively. Therefore, the functions of blocks 902, 914, and 916 can be the same as or substantially similar to the functions previously described with respect to blocks 752, 776, and 765. For brevity, only the differences between these functional blocks will be discussed in further detail.

[0202] Sub-process 750.1 provides various criteria for limiting the acceptance of security messages, as discussed above in section I. For processing flow 950, two paths are shown, where the upper path identifies the challenge node that receives the response, and the lower path identifies the response node that receives the challenge request. Note that, for example, when a node receives other challenge requests and verifies the response to its own challenge request, these two paths can be executed simultaneously by the same node.

[0203] In any case, process 950 modifies the criterion for accepting (box 976) a security message based on a determination of whether the responding node indicates it is currently online (box 954). This determination can be made in response to a previously issued online verification request from the challenging node. Therefore, as described above, the determination can be performed via hardware or software (box 954), and can be made, for example, by setting a pre-defined flag in response field 804 to determine whether the node has affirmatively responded to the previous request. Thus, if the online status request is not verified (box 954, no), the security message is rejected. Otherwise, the security message is accepted (box 976). In either case, process 950 may include updating (box 958) the online status log. Again, this may include, for example, the challenging node updating the online status log 209, as discussed in this section.

[0204] It should also be noted that determining whether a node is online (box 954) can include determining the node's online status within an acceptance window, which can correspond to any suitable threshold time period. For example, even when a particular security message does not contain a response, the acceptance of a security message (box 976) can be conditional on whether the online status has been recently acknowledged (box 954, yes). As shown in box 954, such a determination can be included as part of the online determination. As an illustrative example, a challenging node may not transmit security messages very frequently, so an additional security message that occurs before sending a previous challenge request may not include a response to an immediately following incomplete challenge.

[0205] Processing flow 950 may additionally or alternatively include, upon receiving (box 976) a security message, further determining (box 960) whether the security message includes an online verification request (i.e., a challenge request). This determination (box 960) may include, for example, identifying a representation of the query value contained in the security message, such as RSVP field 802, as described herein. If the security message does not include an online verification request, processing flow 950 follows the same path as described above to update (box 958) the online status log (if necessary) and repeats this process for subsequently received security messages.

[0206] However, if the security message includes an online verification request, then process flow 950 includes updating (box 962) the online verification request log, as described above regarding online verification request log 207. Process flow 950 can then proceed to box 914, as shown and discussed above regarding process flow 900. In this case, the security message can be generated, for example, by populating the RESP field 804 with the contents of the online verification request log 207. Of course, the security message generated in this way can also contain challenge requests from other nodes represented by query values, as described herein.

[0207] III. Priority Message Queue Management

[0208] As mentioned above, CAN-based networks can achieve atomicity; however, conventional CAN-based atomicity also has various drawbacks. For example, CAN-based communication can suffer from the so-called "double-receive" problem. That is, the receiving node can receive a frame one bit before the transmitting node has completed its transmission. Therefore, an error in the last bit of the End-of-Frame (EOF) triggers a frame retransmission, and the frame is received twice. Additionally, offline nodes are simply ignored.

[0209] Furthermore, Ethernet-based networks typically lack atomicity because most Ethernet-based protocols only implement CRC and internal symbol encoding checks. When these fail, such Ethernet-based solutions simply discard the frame and rely on higher layers (such as TCP) to retransmit it. Nevertheless, attempts have been made to extend atomicity to Ethernet-based networks using topologies known as "rings," one example of which is... Figure 10 As shown in the image.

[0210] For example, Figure 10 This illustrates a conventional High Availability Seamless Redundancy (HSR) ring topology as defined by the International Electrotechnical Commission (IEC) 62439. In an HSR ring implementation, output frames are duplicated and sent to both ports. The input port passes the frame to the corresponding output port, discarding duplicate frames. However, the HSR ring implementation requires a specific topology, uses a duplicate message transmission scheme, and its atomicity is susceptible to the robustness of the interconnections between each port; a failure in any port connection will result in a loss of atomicity for the entire system.

[0211] Therefore, the implementation described in this section overcomes these drawbacks by utilizing a defined group tracking solution and a defined transmission scheduling scheme. This transmission scheduling scheme is implicit in the Ethernet MACsec standard, thus providing a reliable basis for enabling group-wide atomicity in such networks. For example, when implementing the Ethernet MACsec standard, nodes can transmit queued messages according to the Ethernet PHY-Level Collision Avoidance (PLCA) scheme. For this purpose, a FIFO buffer can be implemented, which acts as a transmission queue to facilitate message transmission during each node's transmission opportunity. That is, the MACsec standard requires "ordered" frame delivery because otherwise, packet numbering could lead to security errors due to communication frames exhibiting replay attacks.

[0212] Typically, such transmission scheduling systems utilize, for example, four or eight FIFO queues, each identifying a different priority category to separate messages based on their relative urgency. For instance, the IEEE 802.1Q and 802.1AS Time-Sensitive Networking (TSN) standards define eight different priority levels for this purpose. Additionally, 10BASE-T1S uses PLCA for real-time scheduling and employs a "round-robin" algorithm. Therefore, and as further discussed below, nodes operating under a PLCA transmission scheduling scheme will transmit frames at the front of the highest-priority FIFO queue at each transmission opportunity.

[0213] Furthermore, and as discussed further below, the implementation described in this section can utilize an encoded response included in the acknowledgment field to verify that each node has received the transmitted message. In doing so, the transmitting node can only remove the message from the FIFO queue if each intended recipient node of the transmitted message has received it, which can be determined based on the content of the acknowledgment field. If each node has not yet received the message, the node can retain the message in the FIFO queue for retransmission according to the PLCA transmission scheduling scheme. In this way, the implementation described in this section achieves Ethernet-based atomicity that would otherwise be expensive, complex, and unsuitable for real-time control system applications. And because the implementation described in this section can facilitate atomic broadcasting for PLCA transmission scheduling schemes, the implementation in such a scenario may alternatively be referred to herein as using the ABP (Atomic Broadcast for PLCA) protocol.

[0214] It should be noted that the implementations described in this section can facilitate communication between both secure and insecure messages, which are simply referred to as "messages" in this section. For example, and as discussed in further detail below, the authentication-only technology or authentication and encryption technology described herein is optional, and when not used, messages may include insecure messages. However, when the authentication-only technology or authentication and encryption technology described herein is implemented, messages may include secure messages. The implementations described herein can support the atomicity of both secure and insecure messages.

[0215] A. Node Architecture and Operation

[0216] Figure 11 Another example node architecture according to one or more embodiments of this disclosure is shown. Node 1100 may include... Figure 2AThe node 200 shown is a similar component. Therefore, any statements about node 200 as described in Parts I and II apply to node 1100 as described in this part, with differences in operation, configuration, and / or components discussed in further detail below. For example, node 1100 can also identify any suitable type of component and can represent a node in an interconnected node system, such as... Figure 3 The nodes N1 to N discussed in the article X Any node, however, as Figure 3 The use of the corresponding connectivity associations shown is optional. Node 1100 may be identified as part of an electronic control unit (ECU), sensor, actuator, host, etc., and various nodes having such an interconnected system may differ in type and / or function; however, each node may have common functions. Therefore, each node in the interconnected node system can be configured to transmit and / or receive messages according to any suitable communication protocol, as discussed in further detail herein.

[0217] Furthermore, the operation of node 1100, which is part of a system of interconnected nodes, can be further described herein as part of a group of nodes, and the atomicity of messages transmitted is described relative to the same group. However, the implementation is not limited to node 1100 being part of a single group, and node 1100 can operate according to any suitable number of such groups, wherein the implementation described in further detail in this section is to be understood as applicable to nodes within the same group.

[0218] Similarly, node 1100 can represent a node in an interconnection network of nodes. This can include a system of interconnected nodes configured to communicate on a bus according to a multi-point branching scheme, as discussed herein. For example, such a multi-point branching scheme can be part of an automotive E / E architecture as described above, which may include an Ethernet architecture or other suitable automotive E / E architecture. When implementing an Ethernet architecture, the nodes described in the embodiments of 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 interconnected node system using any suitable number and / or 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., multi-point branching Ethernet communication protocols such as 10BASE-T1S, 10BASE-T1L, Ethernet MACsec standard, etc.).

[0219] Similarly, node 1100 may be part of a group of interconnected nodes, which may represent the entire interconnected node system or a subset thereof (e.g., a group). In any case, node 1100 (and each other node in the same group) is configured to transmit messages to and receive messages transmitted by other nodes via data interface 1110. Thus, although each node in the group (including node 1100) is configured to perform both transmission and reception functions, the term "transmitting node" is used herein to refer to any node currently performing message transmission and / or performing any function related to such message transmission. The term "receiving node" is used herein to refer to any node currently receiving messages and / or performing any function related to such message reception.

[0220] A group of nodes can support message communication according to any suitable type of control system, such as a real-time control system that can be implemented in a vehicle, for example. Therefore, node 1100 can be one of any suitable number of nodes in the group that communicate with each other via an interconnection network by transmitting and receiving messages via data interface 1110, and node 1100 can be coupled to a network, bus, etc., and / or form part of a network, bus, etc., which serves as part of any suitable type of point-to-point or multipoint branching scheme. Data interface 1110 can include any suitable number and / or type of data interfaces to facilitate message exchange between node 1100 and any suitable number of other nodes within the node group.

[0221] To perform message communication, node 1100 includes non-volatile memory 1104, volatile memory 1106, a message processor 1108, and a transmission queue 1162. These components are... Figure 11 The nodes are shown as separate entities, with their corresponding functions described individually for ease of explanation. However, any components of node 1100 may be integrated with each other or otherwise combined. Node 1100 may also include components as described herein. Figure 11 Those additional or alternative components are shown and discussed.

[0222] Therefore, message processor 1108 can represent an encoder, a decoder, or a combination of both to facilitate the operation of node 1100 according to any suitable communication protocol as discussed herein. Message processor 1100 may include any suitable number and / or type of components, Figure 11Examples of such components are shown by way of example and not limitation. For example, message processor 1108 may include communication circuitry 1108.1, which may be coupled to data interface 1110, and thus to an accompanying network of interconnect node systems as discussed herein. Therefore, data interface 1110 may include any suitable implementation of components for this purpose, such as, for example, wires, buses and / or corresponding terminals, ports, pins, etc.

[0223] The communication circuit 1108.1 can be implemented as any suitable hardware component enabling communication between node 1100 and other nodes within a set of nodes via data interface 1110, as further discussed herein. Therefore, the communication circuit 1108.1 can transmit and receive messages from 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 may include hardware components, software components, or combinations thereof, typically associated with components configured to perform data communication. For example, the communication circuit 1108.1 may include any suitable number of ports, drivers, transmit and / or receive buffers, switches, etc.

[0224] The processing circuitry 1108.2 may include any suitable number and / or type of dedicated hardware components, such as microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), system-on-a-chip (SoCs), dedicated logic and / or other circuit systems. The processing circuitry 1108.2 may be implemented as one or more processors and / or cores that can execute computer-readable instructions stored in program memory 1108.3 to perform any of the various functions discussed in further detail throughout this section.

[0225] Program memory 1108.3 may include any suitable type of non-transitory computer-readable medium, such as volatile memory, non-volatile memory, or a combination thereof. To the extent that node 1100 implements a software-based solution to perform the various functions discussed throughout this section, this can be achieved, for example, by executing instructions stored in program memory 1108.3 via processing circuitry 1108.2.

[0226] The FIFO management box 1108.4 can represent any suitable combination of dedicated hardware, processors, application-specific integrated circuits (ASICs), etc. Although in Figure 11While shown as separate components, implementations include the FIFO management box 1108.4 being separated from or integrated into the processing circuitry 1108.2. Therefore, the extent to which node 1100 implements a hardware-based solution to perform the various functions discussed throughout this section can be achieved, for example, via the processing circuitry 1108.2 and / or the FIFO management box 1108.4.

[0227] In various implementations, node 1100 may also include transmission queue 1162, which may include any suitable arrangement and / or configuration of any suitable type of memory configured to store messages or security messages prior to transmission. For example, transmission queue 1162 may include a set of databases, which may include any suitable type of storage device, such as buffers (e.g., first-in-first-out (FIFO) buffers as shown), memory address configurations, etc.

[0228] In one implementation, a message may be stored in a specific location within transmission queue 1162 before its transmission. That is, a message stored in transmission queue 1162 may be the same as a message subsequently transmitted to the network via communication circuit 1108.1 using data interface 1110. Therefore, messages stored in the FIFO buffer, such as... Figure 11 The message shown can include the entirety of a message generated prior to its transmission (e.g., the same message). Alternatively, the message stored in the FIFO buffer, such as... Figure 11 The message shown may represent the content and / or a portion of a security message to be transmitted later, and therefore may include, for example, a payload (e.g., if authentication and optional encryption are to be performed) or other suitable information, such as any fields of the security message to be transmitted. In this case, the data stored in the FIFO buffer, such as... Figure 11 The message shown can represent any suitable content, which is then converted into a security message during transmission, as discussed in this article.

[0229] To provide yet another example, the data stored in the FIFO buffer, such as... Figure 11 The message shown can represent the content of an insecure message that may be generated before its transmission, for example, when security measures such as authentication and encryption are not implemented. In this scenario, the message stored in the FIFO buffer, such as... Figure 11 The message shown may also include all (e.g., the same as the insecure message) or any suitable portion thereof of an insecure message generated prior to its transmission. Throughout this section, implementations are primarily described assuming that the various techniques described in Parts I and II above are not used to protect messages to reduce the complexity of security measures and their impact on the atomicity of the node group; however, this is done by way of example rather than limitation.

[0230] In the implementation, each FIFO buffer can identify a different message priority category, where the most urgent messages are transmitted using messages stored in the next transmission slot of FIFO buffer 0, less urgent messages are transmitted using messages stored in the next transmission slot of FIFO buffer 1, and so on. Therefore, as... Figure 11 The FIFO buffer shown can store messages defined according to these different priority categories, such as messages defined according to, for example, the IEEE 802.1Q or 802.1AS Time-Sensitive Networking (TSN) standards. Therefore, and referring to the example... Figure 11 The current transmission schedule can limit the scheduled message transmission for node 1100 based on the priority category of each FIFO buffer and the messages stored in those buffers in the order of messages A to H. However, it should be noted that this assumes that no higher-priority messages (e.g., messages assigned to FIFO buffer 0) are stored before the transmission of the last message H. In the case where new messages are generated and stored before the transmission of the last message H, the transmission of lower-priority scheduled messages can be postponed to support the transmission of higher-priority messages; however, this scenario is not shown for ease of explanation.

[0231] Similarly, message transmission in this manner (i.e., using messages stored in transmission queue 1162) can be performed according to any suitable technique, including known techniques. For example, and as mentioned above, Ethernet standards such as 10BASE-T1S and 10BASE-T1L can define secure message transmission scheduling, and therefore node 1100 can perform message transmission according to these or other suitable protocols that define such a transmission scheduling scheme. Thus, communication circuit 1108.1 can be configured to transmit messages to the network according to any suitable transmission schedule by accessing messages stored in a FIFO buffer and then transmitting the messages via any suitable communication protocol such as, for example, the Ethernet communication protocol. Continuing this example, the transmission scheduling scheme can be implemented according to an Ethernet Physical Layer Collision Avoidance (PLCA) scheme, which also defines the order of transmission slots (e.g., transmission opportunities) between the individual nodes in the group. Therefore, it should be noted that the PLA scheme defines not only message priority and transmission scheduling based on that message priority, but also the transmission order of each node within the group, as discussed further below.

[0232] Regardless of how messages are scheduled for transmission, node 1100 can first generate a message to be optionally protected and then transmit it as such, as discussed herein. Therefore, the secure message processor 1108 is configured to generate one or more messages, which are stored in a FIFO buffer of transmission queue 1162 before transmission according to any suitable communication protocol. For example, processing circuitry 1108.2 can execute instructions stored in program memory 1108.3 to generate each corresponding message stored in transmission queue 1162 for transmission according to, for example, a 10BASE-T1S or 10BASE-T1L communication protocol. In this way, processing circuitry 1108.2 can generate each message before its transmission and store it in the corresponding one of the FIFO buffers based on the priority category of the message to be transmitted. The message is then transmitted to other nodes in the group via communication circuitry 1108.1 and data interface 1110 according to the transmission schedule (e.g., according to an Ethernet PLAC scheme).

[0233] After each message transmission, when predetermined conditions have been met, node 1100 may selectively delete the message from the corresponding FIFO buffer. For example, and as further discussed herein, node 1100 may delete the message stored in the FIFO buffer during its next transmission opportunity only if it is determined that each intended recipient node of the message has received the previously transmitted message. This function will be discussed in more detail below and can be implemented via software, hardware, or a combination thereof. For example, processing circuitry 1108.2 may execute instructions stored in program memory 1108.3 to facilitate this function. As another example, part or all of this function may be implemented via dedicated hardware such as, for example, a FIFO management box 1108.4.

[0234] To determine which nodes are expected to receive the transmitted message, the implementation in this section can utilize a system in which nodes within a group use online acknowledgments of received messages. In other words, each node within the same group is configured to populate an acknowledgment field with an encoded value and then transmit it as part of each node's next scheduled message transmission. This acknowledgment field can include any suitable dedicated field for the message being transmitted between nodes in the group. For example, if an Ethernet-based protocol such as 10BASE-T1S or 10BASE-T1L is implemented, the acknowledgment field can be part of the Ethernet type field of the Ethernet communication frame, which can contain protocol information. For example, data contained in such an Ethernet type field can be used to "link" the message to other Ethernet types, such as MACsec. The use of Ethernet types in this way is generally known and therefore requires no further discussion.

[0235] The acknowledgment field can include any suitable number of bits, such as a bit array, where each bit is identified by the maximum number of nodes in the group. For example, the acknowledgment field can include a 32-bit field, which may alternatively be referred to herein as the "AckTAG" field, and thus can support groups of up to 32 nodes with atomicity. Of course, the acknowledgment field can have any suitable number of such bits and can be part of a dedicated field or any suitable portion of a communication frame other than or in place of the Ethernet type field. For example, the acknowledgment field can include part of the header, payload, etc., of an Ethernet frame or other type of message according to any suitable communication protocol.

[0236] To support atomicity, as an example rather than a limitation, node 1100 can be included in Figure 11 The diagram shows any suitable number of registers stored in volatile memory 1106. Various registers are shown in... Figure 11 The diagram 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 the number of bits in the acknowledgment field (e.g., 32 bits). Additionally, for ease of explanation, in... Figure 11 The diagram shows a single set of these registers. However, implementations may include node 1100 as part of more than one set of nodes. In this case, node 1100 may store a separate set of ACKOUT, ACKD, and GROUP registers for each such set, where the functionality described herein for a single set is extended by repeating the process described herein for each of these sets.

[0237] The contents of each of the ACKOUT, ACKD, and GROUP registers can include any suitable type of encoded value, such as bit values, which can be updated as messages are transmitted and received between different nodes in the group. Therefore, the format and contents of the GROUP register can vary depending on the specific implementation of how the contents of the ACKD register are updated. For example, the implementation described in this section assumes that the node group is known among all participating nodes, and that an encoded value representing that group can be identified in the GROUP register, which is stored by each node in the same group. Therefore, the GROUP register can contain any suitable encoded value that is the same for each node in the group relative to the current node, used to determine whether all nodes in the group have acknowledged the transmitted message. Thus, during message communication, the contents of the GROUP register can remain the same across a group of nodes (relative to each node, but can represent different encoded values ​​for each node), but can be updated to indicate (e.g., when an additional node is added or removed from the group) changes to group membership.

[0238] Additionally, the ACKOUT register contains any suitable type of encoded value (e.g., bit positions) that tracks each node's acknowledgment of received messages, and this is then included in each node's next transmitted message to identify that the node has received messages from each other. The ACKD register contains any suitable type of encoded value (e.g., bit positions) that tracks which nodes have transmitted their acknowledgments of previously transmitted messages (i.e., via the contents of the ACKOUT register that include them). In other words, the contents of the ACKOUT register are updated by the receiving node to acknowledge receipt of messages from each other in the group, and thus indicate to each transmitting node that its previously transmitted messages have been received. The contents of the ACKD register are updated by each node upon receiving the next transmitted message, including the updated contents of the ACKOUT register, and thus indicating which nodes acknowledged the last transmitted message from the transmitting node. The following is about... Figures 13A to 13D Further detailed examples of the contents of these registers and updates are provided.

[0239] Therefore, and as further discussed below, a message transmitted from node 1100 to the network may include an acknowledgment field containing the contents of the ACKOUT register. Each node receiving the transmitted message then updates its own ACKOUT register to acknowledge receipt of the message, 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 transmitting node is scheduled to transmit its next message, the acknowledgment field received in the last message should indicate that each node in the group has received the last message, as further discussed below.

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

[0241] Therefore, now refer to Figures 12A to 12BThis illustrates a block diagram of a message queue management system based on acknowledgments received from other nodes, according to an embodiment of this disclosure. Similarly, the FIFO buffer management processing discussed in this section can be executed by processing circuitry 1108.2 that executes instructions stored in program memory 1108.3, as a hardware component such as FIFO management box 1108.4, or a combination thereof. Therefore, for Figure 12A and Figure 12B Both assume a total of 6 nodes forming part of the same group. Of course, the implementation may include a number of nodes greater or less than the number shown; for ease of explanation, 6 nodes are used.

[0242] Therefore, and first refer to Figure 12A The FIFO buffer is part of the transmission queue 1162 of node 1100, such as Figure 11 As shown. Figure 12A The FIFO buffer on the left represents an example configuration of the contents of the FIFO buffer before transmitting message A, which includes the highest priority and therefore includes the next message to be transmitted according to the transmission schedule. Figure 12A The content of several different messages transmitted to the network by six different nodes is also shown. In this example, node 1100 represents node 1, and nodes 2 through 6 represent nodes that receive the messages and respond with acknowledgments in their own messages. For example, message block A represents the message first transmitted by node 1100 using the content of the corresponding message stored in a FIFO buffer. Therefore, message A also contains an acknowledgment field, which will be discussed in further detail below.

[0243] Continuing this example, each "RESP" block following message A represents a message received by node 1100, which was transmitted to the network by each of the other five nodes after node 1100 transmitted message A. Each of these received messages contains an encoded value indicating that each corresponding node acknowledges receipt of message A by means of the contents of an acknowledgment field, which again includes the contents of each responding node's ACKOUT register. As an example, and as discussed further below, the acknowledgment may include a single bit value within the acknowledgment field or other predetermined values ​​set for predetermined bit positions in the acknowledgment field corresponding to bit positions in node 1100.

[0244] Therefore, node 1100 receives messages from each of nodes 2 to 6 as shown in the figure, and as... Figure 12AThe accumulation shown includes acknowledgments in each of these individual messages, which may, for example, be stored in the ACKD register. Note that the order in which node 1100 receives messages from the other nodes 2 through 6 can be defined by any suitable scheduling. For example, Ethernet PLCA defines a “polling” order that allows each of nodes 2 through 6 to respond sequentially. Therefore, as Figure 12A The order shown assumes the use of this type of polling sort for ease of interpretation.

[0245] Therefore, and using such Figure 12A The message order shown is for example; once node 1100 receives a message from node 6, this signifies the end of the current round of transmission for each of the other nodes 2 through 6. Therefore, node 1100 can now determine during its next transmission opportunity that each of nodes 2 through 6 has received the transmitted message A transmitted during the last transmission opportunity. Thus, and as... Figure 12A As shown, node 1100 can then delete message A from the FIFO buffer, such as Figure 12A As shown on the right. Furthermore, node 1100 can then use the corresponding message from the FIFO buffer to transmit the next message B, which in this example is assumed to be the next scheduled message to be transmitted according to the transmission schedule. In this way, node 1100 is configured to delete message A stored in the FIFO buffer when the encoded value of the acknowledgment field contained in each message transmitted to the network by each of the other nodes 2 to 6 indicates that each of nodes 2 to 6 has received message A. In other words, node 1100 deletes message A from the FIFO buffer only when each of the other receiving nodes in the acknowledgment group has actually received message A.

[0246] Now go to Figure 12B , indicating that it is related to the above about Figure 12A The same FIFO buffers, nodes, and messages are shown and discussed. However, for Figure 12B The message transmitted by node 3 failed to contain an acknowledgment value indicating that message A was received. In this case, because node 1100 cannot verify that each of nodes 2 through 6 has received message A, node 1100 does not delete message A during its next transmission opportunity, but instead retains message A in the FIFO buffer, such as... Figure 12B As shown on the right. Similarly, this can be determined by the fact that the encoded value in the acknowledgment field of the message received from node 3 does not indicate that the acknowledgment has been received, as described above. In other words, when the encoded value in the acknowledgment field of each message transmitted to the network by nodes 2 to 6 indicates that at least one of nodes 2 to 6 has not received message A, node 1100 retains message A in the FIFO buffer.

[0247] Therefore, when message A is held in the FIFO buffer in this manner, node 1100 is configured (e.g., via communication circuit 1108.1) to retransmit message A to the network according to the transmission schedule. This is in Figure 12B As shown, after a message is received from each of nodes 2 through 6, node 1100 retransmits message A. Note that node 1100 may not necessarily retransmit the message after a previous transmission of the same message. For example, although in Figure 12B This is shown for high-priority message A, but this may not be true for lower-priority messages. As an illustrative example, if... Figure 12B If message A is replaced by a lower-priority message such as message B, then message A may be transmitted before message B is retransmitted, depending on the specific transmission schedule and the next message prepared for transmission based on its relative urgency compared to other messages. In any case, for applications implementing the PLCA scheme, keeping the message in a FIFO buffer after its transmission ensures that the same message is automatically retransmitted according to the transmission schedule.

[0248] Furthermore, when node 1100 determines that one or more of nodes 2 through 6 have not received the transmitted message, this can be for various reasons. As an example, for Ethernet-based protocols, the node receiving the transmitted message may discard it, which can be done via a higher network layer. As another example, a node may receive the message, but its response may be lost because it is also discarded. Therefore, in the latter case, there may be a scenario where a node receives a message transmitted by node 1100 and responds, but node 1100 does not receive an acknowledgment of that response.

[0249] In this scenario, the retransmitted message is a duplicate of the previously transmitted message, with the responding node receiving both messages. However, Ethernet-based standards such as MACsec also implement a Packet Number (PN) field, which can be included in each transmitted message and used to uniquely identify each message transmission to prevent replay attacks. Therefore, because 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, the receiving node will detect any subsequently received message as a duplicate and discard it, as part of the MACsec processing protocol. In this way, any retransmitted message will have the same PN as the previously transmitted message, thus causing other nodes that received the initially transmitted message to identify the retransmitted message as a duplicate and discard it.

[0250] Additionally, the message may contain supplementary information that facilitates other nodes in recognizing the message as a duplicate. For example, as part of message generation, node 1100 may generate additional encoded values ​​that are included as part of any suitable dedicated fields in the message, header, payload, etc. For example, the additional encoded values ​​may be added as part of an acknowledgment field as discussed herein. For example, these additional encoded values ​​may indicate the FIFO value in which FIFO buffer the retransmitted message is stored (e.g., as...). Figure 11 (shown as 0 to N). Furthermore, additional encoded values ​​can be used to indicate whether a retransmitted message is a retransmission via the use of a sequence number. For example, the additional encoded value can include a predetermined number of bits that can indicate the FIFO buffer of the message. The encoded value can also include a sequence number with any suitable number of bits sufficient for this purpose, which can be, for example, a single bit value. Thus, the sequence number can switch from its previous state each time a node transmits the same message. For example, a node can transmit an initial message with a sequence number set to 0, the next retransmission of the same message with a sequence number of 1, the next retransmission of the same message again with a sequence number of 0, and so on. In this way, the receiving node can use the state of the sequence number bits to identify a message as an original message or a retransmission message via such a binary indication.

[0251] Therefore, each node can store an additional register or other suitable set of encoded values ​​indicating the transmission status of each FIFO of each other node. For example, node 1100 can store this information in the node FIFO status register, such as... Figure 11 As shown. Therefore, the size of the FIFO status register can be equal to the maximum number of nodes in the group multiplied by the maximum number of FIFO buffers (e.g., 128 bits for a 32-node and 4-FIFO system). Thus, the receiving node can identify duplicate messages by mapping the additional coded values ​​and sequence number included in the received message to the FIFO status buffer of the receiving node associated with the node that transmitted the message. When the FIFO number and sequence number match the current FIFO status bit values ​​corresponding to the retransmitted message, the receiving node can then discard the message as a duplicate.

[0252] B. Examples of atomic PLCA-based transmissions

[0253] Figures 13A to 13D Examples of register contents for various nodes within the same group supporting atomicity are shown according to embodiments of this disclosure. For example, regarding... Figures 13A to 13DIn each of the example scenarios discussed, it is assumed that there are four nodes in the group, referred to herein as nodes 0 through 3. It is also assumed that each of these nodes 0 through 3 transmits its next scheduled message (e.g., the next FIFO queued message) according to a transmission time slot based on the order of node transmissions or a cyclical transmission schedule. Similarly, such a scheduling can be defined according to the PLCA scheme used in these examples. Therefore, for Figures 13A to 13D In each of the following sequences, node 0 first transmits message B0, then node 1 transmits message B1, then node 2 transmits message B2, and then node 3 transmits message B3. This represents a complete transmission cycle, at which point the process repeats because node 0 begins transmitting a new message C0 (if all other nodes indicate that message B0 has been received) or retransmits the same message B0 (if it is determined that none of the other nodes 1 through 3 have yet received message B0).

[0254] Additionally, as described in this implementation, a node can function by requiring each node in the group to use its transmission opportunity, even if there is no application frame (e.g., a message) to be transmitted. In this case, the node can transmit an acknowledgment field as a message transmitted by the node in this situation. For example, such a message may include a header corresponding to an “empty” frame that has no Ethernet type after the ABP PDU. The receiving node in this scenario may not deliver such empty frames to the application because these empty frames only carry acknowledgment field data to facilitate atomicity as discussed herein.

[0255] As mentioned above Figure 11 The implementation of selectively deleting messages from the FIFO queue described for node 1100 is discussed in further detail with respect to node 0, which is the first transmission node in the transmission schedule, and can be identified, for example, as node 1100 discussed herein. However, note that each of the other nodes 1 through 3 can be configured in the same way as node 0. For example, each of nodes 0 through 3 may include corresponding ACKOUT, ACKD, and GROUP registers, which are updated as discussed herein with respect to node 0, and each of nodes 0 through 3 can also selectively delete messages from its own queue when it is each node's turn to transmit its corresponding message. In other words, each of nodes 0 through 3 can operate in the same way as each other to ensure the atomicity of the entire node group.

[0256] Furthermore, and regarding such Figures 13A to 13DThe example shown should be noted that, for ease of explanation, only a portion of the ACKOUT, ACKD, and GROUP registers and the acknowledgment field A is shown. For example, the ACKOUT, ACKD, and GROUP registers and the acknowledgment field A can have a number of bits equal to the maximum number of nodes that can be supported in the group, such as, for example, 32 bits, which would therefore support the atomicity of groups with up to 32 nodes. Furthermore, as discussed further below, each bit in the acknowledgment field and in the ACKOUT, ACKD, and GROUP registers can identify a predefined bit position corresponding to each node in the group. Therefore, for the sake of brevity, in Figures 13A to 13D Only the ACKOUT, ACKD, and GROUP registers, as well as the relevant parts of the acknowledgment field A, are shown.

[0257] Additionally, it should be noted that the acknowledgment field, along with the ACKOUT and ACKD registers, implements a node numbering scheme that starts at the MSB and proceeds to the LSB. The GROUP register contains the encoded values ​​for all nodes 0 through 3 selected according to the node numbering scheme. This is done for ease of explanation, as in these examples a shift register is implemented to update the contents of the ACKD register, and then the contents of the ACKD register are compared with the contents of the GROUP register to determine whether all other nodes have received the transmitted message, as discussed further below.

[0258] However, for ease of explanation, specific types of encoding for any implementation of the ACKOUT, ACKD, and GROUP registers, as well as the acknowledgment field A, are provided and shown as non-restrictive and illustrative examples. Additionally, the use of a shift register for the ACKD register is provided by way of example, not limitation. Any suitable encoded value can be implemented according to any suitable bit encoding scheme to achieve the results described herein. Figures 13A to 13D The results discussed are the same. For example, instead of using shift registers as discussed in further detail below, any suitable alternative technique can be used to update the contents of any of the ACKOUT, ACKD, and GROUP registers, such as by using bit shifting to switch specific positions to produce results related to... Figures 13A to 13D The examples discussed yielded the same results.

[0259] Now go to Figure 13A This illustrates the contents of the ACKOUT, ACKD, and GROUP registers of node 0 at different stages of the PLCA transmission cycle. It is assumed that the initial transmission of message B0 occurs after nodes 1 through 3 receive acknowledgments of previously transmitted message A0 (not shown). This is via... Figure 13AThe “D” field next to the leftmost and bottommost ACKD register content 1110 indicates that the contents of the FIFO buffer (i.e., message A0) were removed before message B0 was transmitted. Therefore, before transmitting message B0, the contents of the ACKD register were the same as the contents of the GROUP register (i.e., 1110), because the match between the contents of these two registers was used as a condition for removing the previously transmitted message A0 from node 0's FIFO queue. Thus, the contents of the GROUP register correspond to a mask, which, in this example for ease of explanation, represents the encoded value that matches the expected contents of the ACKD register when each of the other nodes 1 through 3 has acknowledged the transmission of a message from node 0 since node 0's last transmission opportunity.

[0260] In addition, it should be noted that regarding Figures 13A to 13D The example discussed uses a shift register implementation to encode the ACKD and GROUP registers in a manner that reflects the order of the PLCA cycle (rather than the number of nodes). Similarly, any suitable encoding and update scheme can be used for each node to track whether a transmitted message has been received by other nodes and to acknowledge receipt of messages from other nodes. As a result, for... Figures 13A to 13D In the example shown, the last bit of the shift reflects the previous node in the PLCA cycle, and therefore each bit is "relative" to the current node. Thus, and as mentioned above, this means that the encoded value in the GROUP register of one node may not necessarily be equal to the same encoded value contained in the GROUP register of another node. In any case, each node can still perform selective deletion or retransmission of messages as discussed herein by comparing the contents of its ACKD register with the contents of its GROUP register during its next transmission opportunity.

[0261] Therefore, during its transmission slot, Node 0 first compares the contents of the ACKD register with the GROUP register, and if these registers are equal, Node 0 deletes the last transmitted message, as this means that other nodes 1 through 3 have acknowledged Node 0's last transmitted message. Otherwise, Node 0 retains the message in the FIFO buffer and retransmits the last message, as discussed further herein. If the contents of the ACKD and GROUP registers are equal, after deleting the previously transmitted message from the FIFO buffer, Node 0 also generates an acknowledgment field to be transmitted along 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., a frame). This indicates to other nodes 1 through 3 that they have received their previously transmitted message from the last transmission cycle (not shown). Node 0 then retains the message in the FIFO, at least temporarily, for example, until its next transmission slot, as discussed herein. Of course, acknowledging the contents of the ACKD and GROUP registers is valid, provided that the encoding scheme used for the ACKD and GROUP registers is consistent with the same implementation (shifted bits and set node bit positions).

[0262] This is Figure 13A The initial content 0111 of the ACKOUT register for node 0 is shown. In this example, the content of the ACKOUT register uses the naming convention of nodes 1 through 3 that indicate which of the group of nodes 0 through 3 needs to have its messages acknowledged. In other words, to ensure atomicity between the groups of nodes 0 through 3, the ACKOUT register tracks which of the other nodes needs to receive and acknowledge the message transmitted by node 0 in the same way that each of the other nodes 1 through 3 needs to acknowledge the message transmitted by node 0. Therefore, the ACKOUT register indicates that messages transmitted from nodes 1, 2, and 3 need to be acknowledged, not node 0, because node 0 is the same node. Figure 13A As shown, when the contents of the ACKOUT register are copied to the acknowledgment field A in message B0, the contents of the ACKOUT register are then cleared to 0000 because node 0 is the first node in the transmission loop and has just acknowledged receiving transmission messages from other nodes 1 to 3 by copying the contents of the ACKOUT register to the acknowledgment field of the transmission in message B0.

[0263] When transmitting message B0, node 0 will then... Figure 13AThe contents of the ACKD register shown are updated to 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 shift 0 bits on the MSB side of the ACKD register, as shown. Since each of the other nodes 1 through 3 transmits its own messages B1, B2, B3 during its own transmission slot, and each node performs similar processing, this results in an acknowledgment field indicating the contents of each node's ACKOUT register. Similarly, because each bit position in the acknowledgment field transmitted by the other nodes 1 through 3 corresponds to one of nodes 0 through 3, each of nodes 1 through 3 can acknowledge the receipt of message B0 by setting the leftmost bit in the transmitted acknowledgment field to 1, as shown. Figure 13A As shown. For example, the acknowledgment field of each received message may contain the "D"th bit corresponding to the node D requesting acknowledgment of a previously transmitted message, where the "D"th bit is... Figure 13A The leftmost bit in the example shown corresponds to node 0. However, the position of the "D" bit in the acknowledgment field is different for the other nodes 1 through 3, which use this bit position to similarly determine that the message they are transmitting has been acknowledged by other nodes.

[0264] Therefore, and using node 0 as an example, when node 0 receives each of messages B1, B2, B3 from other nodes 1 to 3, node 0 shifts the "D" bit (in this example, the leftmost bit, which corresponds to the bit position of the receiving node 0) to the MSB side of the ACKD register, as follows. Figure 13A As shown. If a valid message is missing for a given PLCA transmission slot, node 0 can assume that the acknowledgment field is a predetermined set of values, such as, for example, all zeros (i.e., no acknowledgment). Therefore, once the last message B3, indicating that node 3 has acknowledged receipt of message B0, is received, the initial content of the ACKD register changes from 0111 to 1011, then to 1101, and finally to 1110.

[0265] Similarly, node 0 can then compare the contents of its ACKD register at the end of the transmission cycle with the encoded value represented in the GROUP register, which should match each other when all other nodes 1 through 3 have acknowledged receipt of message B0. In this case, because the contents of the ACKD register match the contents of the GROUP register, node 0 can remove the message from the FIFO queue and transmit the next message C0. In this way, node 0 (e.g., via message processor 1108) is configured to determine whether each of the other nodes 1 through 3 has received message B0 by determining whether the bit in the acknowledgment field with a predetermined bit position identifying node 0 indicates acknowledgment of message B0 transmitted to the network for each message B1, B2, and B3 transmitted to the network by the other nodes 1 through 3.

[0266] Similarly, when node 0 receives each of messages B1, B2, and B3 from nodes 1, 2, and 3 respectively, node 0 updates the contents of its ACKOUT register, as shown, by setting the corresponding bit position of each of nodes 1 to 3 to "1" upon receiving each message to acknowledge receipt of each message B1, B2, and B3. Transmitting nodes 1 to 3 can be identified in this way, for example, by using coded data in the message such as the message source address (SA). Therefore, node 0 can reference any suitable correlation from the SA to the SA, such as a table that can be stored, for example, in non-volatile memory 1104 or volatile memory 1106. Alternatively, node 0 can identify the node transmitting the message based on the order of the PLCA transmission slots.

[0267] Therefore, and continue to refer to Figure 13A As an example, after receiving message B1 from node 1, node 0 sets the contents of its ACKOUT register to 0100, where the position of the "1" bit corresponds to node 1 (i.e., the bit positions in the ACKOUT register from MSB to LSB correspond to nodes 0, 1, 2, and 3). This can be achieved, for example, by node 0 performing a lookup of transmission nodes 1 through 3, which is represented as S in this example. Therefore, node 0 sets the "S" bit of the ACKOUT register to acknowledge receipt of message B1 to node S (node ​​1 in this example). This process is repeated by node 0 to set the bits of the ACKOUT field to acknowledge receipt of each of messages B1, B2, and B3. Thus, the final result in this example is that when node 0 receives and acknowledges the last message in the transmission loop, the contents of the ACKOUT register are 0111, and the transmission loop restarts at node 0.

[0268] Now go to Figure 13BThe diagram illustrates the contents of the ACKOUT and ACKD registers of each of nodes 0 through 3 in the group during various stages of the PLCA transmission cycle. As discussed above regarding node 0, when a message is received from another node, each of nodes 0 through 3 can update the contents of its ACKOUT register to acknowledge the receipt of these messages, where the contents of the ACKOUT register are copied to the acknowledgment field of each message transmitted within the transmission cycle, as shown. For example, node 0 transmits message B0 received by each of nodes 1 through 3, which may include an acknowledgment field 0111. Therefore, the ACKOUT registers of nodes 1 through 3 are updated such that the MSB, again corresponding to the position of node 0, is updated from "0" to "1". Then, as... Figure 13B As shown, this process is repeated for each node in the group throughout the transmission cycle. Therefore, each node in the group is configured to acknowledge receipt of a message from other nodes in the group by updating its own ACKOUT field using an acknowledgment field, which is then copied to the acknowledgment field and included as part of the message in the next transmission for each node. In this way, the use of the acknowledgment field can be used as an inherent operation for each node in the group to acknowledge receipt of messages from other nodes.

[0269] Additionally, each of nodes 0 through 3 can update the contents of its ACKD register when it receives a message from other nodes indicating that their last transmitted message has been acknowledged by those nodes. For example, and as... Figure 13B As shown, when a message is received from another node, each node updates the contents of its ACKD register 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, when each node is ready to transmit the next scheduled message, it can compare the contents of its ACKD register with the contents of its GROUP register, as shown. For each node, when the contents match, each node can remove the message from the FIFO queue corresponding to the previous transmission slot during its current transmission slot. This is as follows in each case... Figure 13B The diagram shows the message indicated by the symbol "D". Each node then transmits a new message from another FIFO queue. The ACKD and ACKOUT registers are then reset to their predetermined values ​​of 0111 and 0000, respectively, as shown above. Figure 13A This refers to node 0.

[0270] Similarly, 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 retain the message in the FIFO buffer and then retransmit it. The following is about... Figure 13C and Figure 13DLet's discuss this scenario in more detail.

[0271] Figure 13C It shows that following and Figure 13A and Figure 13B The example scenario shows the same PLCA transmission order, where node 0 is referenced as the first transmission node in that order. However, in Figure 13C In the example shown, node 2 did not receive message B0 transmitted from node 0. This could be because message B0 was dropped, corrupted, or something similar. Therefore, the ACKOUT registers of nodes 1 and 3 indicate that message B0 from node 0 has been received, but node 2 does not update its ACKOUT register in this way. Therefore, when node 2 transmits message B2, the content copied to the acknowledgment field of its ACKOUT register is "0101". That is, unlike nodes 1 and 3 which received message B0, the leftmost bit identifying node 0 is 0 instead of 1.

[0272] Therefore, when node 0 receives message B2 from node 2, the content of the ACKD register at node 0 is shifted right with 0 instead of 1, resulting in 0101. When the additional message B3 is received from node 3, this causes the ACKD register at node 0 to be 1010, instead of the value 1110 encoded in the GROUP register. As a result, when node 0 is ready to transmit a message during its next transmission opportunity, the comparison between the GROUP register and the ACKD register causes a mismatch at node 0, and therefore node 0 does not delete the previously transmitted message. Instead, node 0 retransmits message B0, as shown. This is represented in the attached figure as "R" (retransmission) relative to the "D" (delete) symbol. Note that other nodes 1 through 3 can delete their messages and transmit new messages because only node 2 did not receive message B0 from node 0.

[0273] The process of retransmitting message B0 by node 0 in this manner can be repeated until node 2 acknowledges receipt of message B0 by means of the content of the acknowledgment field in a message subsequently transmitted from node 2. Otherwise, this process can be repeated until other intervention actions are taken, such as an indication from a higher-level system component that node 2 has gone offline. This can be implemented, for example, by an error counter associated with each node, which can be stored in the volatile or non-volatile memory of each node and indicates the number of acknowledgments missed in sequence. This can result in updating the coded value of the GROUP register for each node to reflect which other nodes are online, where subsequent message acknowledgments are performed via a comparison of the updated contents of the ACKD register and the GROUP register. Similarly, for reference... Figures 13A to 13DThe shift register implementation of the ACKD register discussed here means that 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 encoded value in the GROUP register to reflect its placement within the PLCA cycle.

[0274] Now refer to Figure 13D This illustrates a scenario where node 1 transmits message B1, but the message is not received by any of the other nodes 0, 2, or 3. For example, this could be due to bus noise corrupting the message and preventing it from reaching 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 therefore the corresponding bit positions in node 1's ACKOUT register (e.g., ...) are as follows. Figure 13D The second bit from the left (as shown) remains at a value of 0. Therefore, each of nodes 2, 3, and 0 transmits its corresponding messages A2, A3, and B0 as a retransmission of previously transmitted messages in this scenario, with the acknowledgment field indicating the contents of the ACKOUT register prior to transmission in each case. That is, each of nodes 2, 3, and 0 shifts the 0 value of the acknowledgment field from each of the subsequently received messages A2, A3, and B0 into their respective ACKD registers, causing nodes to retransmit their messages because the contents of their ACKD registers do not match their GROUP registers, indicating that none of the nodes have acknowledged their previously transmitted messages. Additionally, node 1 also retransmits the lost message B1 because node 1's ACKD register contains 0000, indicating that no other node has acknowledged the previously transmitted message B1.

[0275] C. Example Processing Flow

[0276] Figure 14 An example processing flow according to an embodiment of this disclosure is shown. (Refer to...) Figure 14 Process 1400 may include methods executed and / or otherwise associated with any suitable number and / or type of components such as one or more processors (processing circuitry), hardware components, executed instructions (e.g., software components), or combinations thereof. Components may be associated with one or more components as discussed herein with node 1100. Process 1400 may include, for the sake of brevity, in… Figure 14 The alternatives or additional boxes not shown may be performed in a different order than those shown. For example, additional messages may be generated and stored in parallel with the transmission of other messages (e.g., simultaneously with other messages) according to the transmission schedule; however, for ease of explanation, message generation and storage are shown as occurring before transmission. Furthermore, some boxes may be optional. Additionally, any statements made regarding the operation of node 1100 also apply as described herein. Figure 14The processing flow discussed.

[0277] like Figure 14 As shown, when performing message transmission, as Figure 3 As shown, the processing flow 1100 can be implemented via any of the nodes discussed herein, such as any node included in system 300 for example.

[0278] Processing flow 1400 begins with the generation of one or more messages (box 1402). This may include, for example, generating insecure messages that are subsequently converted into secure messages for use in transmissions as discussed herein. Alternatively, this may include generating (box 1402) one or more messages as secure messages. As yet another example, this may include generating (box 1402) one or more messages as insecure messages for transmission as insecure messages. In either case, message generation may include the generation of encoded values ​​for acknowledgment fields, as described above.

[0279] Processing flow 1400 also includes storing each message (box 1404) in a transmission queue, which may, for example, include transmission queue 1162. Similarly, this may include storing the generated messages in a FIFO buffer based on the priority category of each message, as discussed herein.

[0280] Processing flow 1400 also includes transmitting (box 1406) the next message stored in the transmission queue according to any suitable transmission schedule. The transmitted message may include an acknowledgment field, as described above.

[0281] Processing flow 1400 also includes determining (box 1408) whether an acknowledgment has been received from the other nodes to which the message was transmitted (box 1406). This may include, for example, determining whether each message received from the other nodes includes an encoded value indicating that the message was received (e.g., the contents of that node's ACKOUT register), as described above regarding... Figure 12A and Figure 12B The subject of discussion.

[0282] If it is determined that an acknowledgment has been received from another node that transmitted the message to it, processing flow 1400 continues to box 1412. In this case, processing flow 1400 includes deleting the message stored in the buffer (box 1412). Furthermore, while deleting the message in this way (box 1412), processing flow 1400 includes transmitting the next message according to the transmission schedule (box 1406).

[0283] However, if it is determined that no acknowledgment has been received from other nodes to which the message was transmitted, processing flow 1400 continues to box 1410. In this case, the message is held (box 1410) in a buffer. Processing flow 1400 then also includes transmitting the next message according to the transmission schedule (box 1406). This may include message priority-based retransmission (box 1406) of messages that have already been held in the buffer as the next transmission or as a subsequent transmission, as discussed herein.

[0284] Example

[0285] The technology disclosed herein may also be described in the following examples.

[0286] Example 1. A node in a system of interconnected nodes configured to communicate over a network, the node comprising: a plurality of buffers, each of the plurality of buffers being associated with a different message priority category; processing circuitry configured to generate a message and store the message in one of the plurality of buffers based on the message priority category of the message; and communication circuitry configured to transmit the message to the network using a transmission schedule according to an Ethernet Physical Layer Collision Avoidance (PLCA) scheme, wherein, after the message is transmitted to the network, the processing circuitry is configured to selectively delete 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, the indication being based on an encoded value of an acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes.

[0287] Example 2. The node according to Example 1, wherein the encoded value of the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes indicates acknowledgment.

[0288] Example 3. A node according to any combination of Examples 1 to 2, wherein the processing circuitry is configured to delete the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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.

[0289] Example 4. A node according to any combination of Examples 1 to 3, wherein the processing circuitry is configured to retain the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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.

[0290] Example 5. A node according to any combination of Examples 1 to 4, wherein when the message is held in one of the plurality of buffers, the communication circuit is configured to retransmit the message to the network according to the transmission schedule.

[0291] Example 6. A node according to any combination of Examples 1 to 5, wherein the retransmitted message causes the node that has received the message among the plurality of other nodes to identify the retransmitted message as a duplicate message and discard the retransmitted message.

[0292] Example 7. A node according to any combination of Examples 1 to 6, wherein the retransmitted message includes one or more encoded values ​​indicating: (i) one of the plurality of buffers storing the retransmitted message; and (ii) the retransmitted message is a retransmission, and wherein the retransmitted message causes a node among the plurality of other nodes that has received the message to identify the retransmitted message as a duplicate message via the one or more encoded values.

[0293] Example 8. A node according to any combination of Examples 1 to 7, wherein the acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes includes a bit string, and wherein the processing circuitry is configured to determine whether each of the plurality of other nodes has received the message by determining, for each corresponding message transmitted to the network by each of the plurality of other nodes, whether a bit in the bit string having a predetermined bit position identifying the node indicates acknowledgment of the message transmitted to the network by the node.

[0294] Example 9. A node according to any combination of Examples 1 to 8, wherein: the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes includes a bit string comprising a plurality of bits, each of the plurality of bits having a pre-position identifier for each corresponding node, and the encoded value of the acknowledgment field corresponding to the pre-position identifier for the node.

[0295] Example 10. A node according to any combination of Examples 1 to 9, wherein the communication circuitry is configured to transmit the message to the network via an Ethernet communication protocol.

[0296] Example 11. A node according to any combination of Examples 1 to 10, wherein the Ethernet communication protocol includes the 10BASE-T1S Ethernet protocol or the 10BASE-T1L Ethernet protocol.

[0297] Example 12. A computer-implemented method for nodes in a system of interconnected nodes configured to communicate over a network, the method comprising: generating a message; storing the message in one of a plurality of buffers based on a message priority category of the message; transmitting the message to the network using a transmission schedule according to an Ethernet physical layer collision avoidance (PLCA) scheme; and after transmitting the message to the network, selectively deleting the message stored in one of the plurality of buffers based on an indication that 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 corresponding message transmitted to the network by each of the plurality of other nodes.

[0298] Example 13. The method according to Example 12, wherein the encoded value of the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes indicates acknowledgment.

[0299] Example 14. The method according to any combination of Examples 12 to 13, wherein selective deletion comprises: deleting the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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.

[0300] Example 15. The method according to any combination of Examples 12 to 14, wherein selective deletion comprises: retaining the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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.

[0301] Example 16. The method according to any combination of Examples 12 to 15, wherein: when the message is held in one of the plurality of buffers, the message is retransmitted to the network according to the transmission schedule.

[0302] Example 17. The method according to any combination of Examples 12 to 16, wherein the retransmitted message causes the node that has received the message among the plurality of other nodes to identify the retransmitted message as a duplicate message and discard the retransmitted message.

[0303] Example 18. The method according to any combination of Examples 12 to 17, wherein the retransmitted message includes one or more encoded values ​​indicating: (i) one of the plurality of buffers storing the retransmitted message; and (ii) the retransmitted message is a retransmission, and wherein the retransmitted message causes a node among the plurality of other nodes that has received the message to identify the retransmitted message as a duplicate message via the one or more encoded values.

[0304] Example 19. The method according to any combination of Examples 12 to 18, wherein the acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes includes a bit string, and further comprising: determining whether each of the plurality of other nodes has received the message by determining, for each corresponding message transmitted to the network by each of the plurality of other nodes, whether a bit in the bit string having a predetermined bit position identifying the node indicates acknowledgment of the message transmitted to the network by the node.

[0305] Example 20. The method according to any combination of Examples 12 to 19, wherein: the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes includes a bit string comprising a plurality of bits, each of the plurality of bits having a pre-position identifier for each corresponding node, and the encoded value of the acknowledgment field corresponding to the pre-position identifier for the node.

[0306] Example 21. The method according to any combination of Examples 12 to 20, wherein transmitting the message to the network comprises: transmitting the message to the network via an Ethernet communication protocol.

[0307] Example 22. The method according to any combination of Examples 12 to 21, wherein the Ethernet communication protocol includes the 10BASE-T1S Ethernet protocol or the 10BASE-T1L Ethernet protocol.

[0308] in conclusion

[0309] Although specific embodiments have been shown and described herein, it should be understood that any arrangement calculated to achieve the same purpose may replace the specific embodiments shown. This disclosure is intended to cover any and all adjustments or variations of the various embodiments. Combinations of the above embodiments and other embodiments not specifically described herein will be apparent to those skilled in the art upon review of the above description.

[0310] It should also be noted that certain terms used in the specification and claims can be interpreted in a very broad sense. For example, the terms "circuit" or "circuit system" as used herein will be interpreted to include not only hardware but also software, firmware, or any combination thereof. The term "data" can be interpreted to include any form of data representation. In addition to any form of digital information, the term "information" can also include other forms representing information. In embodiments, the terms "entity" or "unit" can include any device, apparatus circuit, hardware, software, firmware, chip or other semiconductor, as well as the physical implementation of logic units or protocol layers, etc. Furthermore, the terms "coupled" or "connected" can be interpreted broadly to cover not only direct coupling but also indirect coupling.

[0311] It should also be noted that the methods disclosed in the specification or claims can be implemented by an apparatus having means for performing each of the respective steps of these methods.

[0312] Although specific embodiments have been shown and described herein, those skilled in the art will understand that various alternatives and / or equivalent implementations may be used instead of the specific embodiments shown and described without departing from the scope of this disclosure. This disclosure is intended to cover any adjustments or variations of the specific embodiments discussed herein.

Claims

1. A node in a system of interconnected nodes configured to communicate over a network, the node comprising: Multiple buffers, each of which is associated with a different message priority category; A processing circuit configured to generate a message and store the message in one of the plurality of buffers based on the message priority category of the message; as well as The communication circuit is configured to transmit the message to the network using a transmission schedule based on an Ethernet physical layer collision avoidance (PLCA) scheme. Wherein, after the message is transmitted to the network, the processing circuitry is configured to selectively delete the message stored in one of the plurality of buffers based on an indication of whether each of the plurality of other nodes coupled to the network has received the message, the indication being based on the encoded value of an acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes.

2. The node according to claim 1, wherein, The encoded value of the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes indicates acknowledgment.

3. The node according to claim 1, wherein, The processing circuitry is configured to delete the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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. The node according to claim 1, wherein, The processing circuit is configured to retain the message stored in one of the plurality of buffers when the encoded value of the acknowledgment field contained in each corresponding 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. The node according to claim 4, wherein, When the message is held in one of the plurality of buffers, the communication circuit is configured to retransmit the message to the network according to the transmission schedule.

6. The node according to claim 5, wherein, The retransmitted message causes the nodes among the plurality of other nodes that have already received the message to identify the retransmitted message as a duplicate message and discard the retransmitted message.

7. The node according to claim 6, wherein, The retransmitted message includes one or more encoded values, which indicate: (i) one of the plurality of buffers storing the retransmitted message; And (ii) the retransmitted message is a retransmission, and The retransmitted message enables the nodes among the plurality of other nodes that have already received the message to identify the retransmitted message as a duplicate message through the one or more encoded values.

8. The node according to claim 1, wherein, The acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes comprises a bit string, and The processing circuitry is configured to determine whether each of the plurality of other nodes has received the message by determining, for each corresponding message transmitted to the network by each of the plurality of other nodes, whether a bit in the bit string having a predetermined bit position identifying the node indicates acknowledgment of the message transmitted to the network by the node.

9. The node according to claim 1, wherein: The acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes comprises a bit string containing multiple bits. The predefined bit position of each of the plurality of bits identifies each corresponding node, and The encoded value of the confirmation field corresponds to the pre-positioned location that identifies the node.

10. The node according to claim 1, wherein, The communication circuit is configured to transmit the message to the network via the Ethernet communication protocol.

11. The node according to claim 10, wherein, The Ethernet communication protocol includes the 10BASE-T1S Ethernet protocol or the 10BASE-T1L Ethernet protocol.

12. A computer-implemented method for nodes in a system configured to communicate over a network, the method comprising: Generate a message; The message is stored in one of multiple buffers based on its message priority category. The message is transmitted to the network using a transmission scheduling method based on the Ethernet Physical Layer Collision Avoidance (PLCA) scheme. as well as After the message is transmitted to the network, the message is selectively deleted from one of the plurality of buffers, based on an indication that each of the plurality of other nodes coupled to the network has received the message. The indication is based on the encoded value of the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes.

13. The method according to claim 12, wherein, The encoded value of the acknowledgment field contained in each corresponding message transmitted to the network by each of the plurality of other nodes indicates acknowledgment.

14. The method according to claim 12, wherein, The selective deletion includes: When the encoded value of the acknowledgment field contained in each corresponding 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, the message stored in one of the plurality of buffers is deleted.

15. The method according to claim 12, wherein, The selective deletion includes: When the encoded value of the acknowledgment field contained in each corresponding 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, the message stored in one of the plurality of buffers is retained.

16. The method of claim 15, further comprising: When the message is held in one of the plurality of buffers, the message is retransmitted to the network according to the transmission schedule.

17. The method according to claim 16, wherein, The retransmitted message causes the nodes among the plurality of other nodes that have already received the message to identify the retransmitted message as a duplicate message and discard the retransmitted message.

18. The method according to claim 17, wherein, The retransmitted message includes one or more encoded values, said one or more encoded values ​​indicating: (i) one of the plurality of buffers storing the retransmitted message, and (ii) the retransmitted message is a retransmission, and The retransmitted message enables the nodes among the plurality of other nodes that have already received the message to identify the retransmitted message as a duplicate message through the one or more encoded values.

19. The method according to claim 12, wherein, The acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes includes a bit string and further includes: By determining whether a bit in the bit string that identifies the node at a predetermined bit position indicates acknowledgment of the message transmitted by the node to the network for each corresponding message transmitted by each of the plurality of other nodes, it is thus determined whether each of the plurality of other nodes has received the message.

20. The method of claim 12, wherein: The acknowledgment field included in each corresponding message transmitted to the network by each of the plurality of other nodes comprises a bit string containing multiple bits. The predefined bit position of each of the plurality of bits identifies each corresponding node, and The encoded value of the confirmation field corresponds to the pre-positioned location that identifies the node.

21. The method according to claim 12, wherein, Transmitting the message to the network includes: The message is transmitted to the network via the Ethernet communication protocol.

22. The method according to claim 21, wherein, The Ethernet communication protocol includes the 10BASE-T1S Ethernet protocol or the 10BASE-T1L Ethernet protocol.

Images