Secure communications using pre-shared keys and active members.

Description

1 / 94 “NODES IN INTERCONNECTED NODE SYSTEMS, METHOD FOR TRANSMITTING A PROTECTED MESSAGE, METHOD FOR RECEIVING A PROTECTED MESSAGE AND METHOD FOR COMMUNICATION THROUGH NODES IN INTERCONNECTED NODE SYSTEMS” FIELD OF THE INVENTION

[001] The present invention relates generally to the use of protected data communications and, more particularly, to the use of protected communications that take advantage of locally stored key counter values, according to a real-time bus key distribution system, to eliminate the need for dedicated key agreement messages, as well as to the use of active member groups to provide an additional layer of security by adding data to scheduled protected messages that are transmitted between nodes within member groups without the use of dedicated protected messages for that purpose. FUNDAMENTALS OF THE INVENTION

[002] Control Area Network (CAN), Control Area Network - Flexible Data Rate (CAN FD), Control Area Network - Extra Long (CAN XL), and Ethernet communication protocols are currently the dominant networks / protocols implemented for use in automotive vehicular communications, which utilize a concurrent electrical / electronic (E / E) architecture. However, these conventional approaches present several disadvantages, particularly regarding the communication overhead required to distribute shared keys that are used to authenticate, encrypt, and decrypt protected messages within the network.

[003] The document by XUHANG YING ET AL: “Covert Channel-Based Transmitter Authentication in Controller Area Networks”, ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY Petition 870260071805, dated 07 / 20 / 2026, page 105 / 320 2 / 94 ITHACA, NY 14853, December 8, 2019 (08 / 12 / 2019), XP081548914, refers to hidden channel-based transmitter authentication in CAN. Document EP 4 080 813 A1 refers to a communication method and an electronic device. The document by LIN HSIAO-YING ET AL.: “AnchorCAN: Anchor-Based Secure CAN Communications System”, 2018 IEEE CONFERENCE ON DEPENDABLE AND SECURE COMPUTING (DSC), IEEE, December 10, 2018 (12 / 10 / 2018), pages 1-7, XP033506596, DOI: 10.1109 / DESEC.2018.8625173 [accessed 01 / 23 / 2019] refers to an anchor-based secure CAN communication system. Document CN 113 132 098 B refers to a secure communication method on a scalable CAN bus and a device for a large-scale vehicular network. BRIEF DESCRIPTION OF THE DRAWINGS

[004] The drawings accompanying this document, incorporated herein and forming part of the descriptive report, illustrate aspects of the present invention and, together with the description, serve to explain the principles of the aspects and enable a person skilled in the relevant art to create and use the aspects.

[005] Figure 1A illustrates the use of a conventional key agreement messaging protocol for low priority frames.

[006] Figure 1B illustrates the use of a conventional key agreement messaging protocol for high priority frames.

[007] Figure 2A illustrates an exemplary node architecture, according to one or more embodiments of the present invention.

[008] Figure 2B illustrates an exemplary key session generator, according to one or more embodiments of the present invention.

[009] Figure 2C illustrates an exemplary novelty value (FV) record received, according to one or more embodiments of the present invention.

[010] Figure 3 illustrates an exemplary system of interconnected nodes, including defined safe zones, according to one or more modalities of Petition 870260071805, dated 07 / 20 / 2026, p. 106 / 320 3 / 94 present invention.

[011] Figure 4A illustrates an exemplary format of a received protected message, according to one or more embodiments of the present invention.

[012] Figure 4B illustrates an exemplary format of a protected message transmitted, according to one or more embodiments of the present invention.

[013] Figure 5 illustrates an exemplary use of a hardware-based solution for using novelty values, according to one or more embodiments of the present invention.

[014] Figure 6 illustrates an exemplary hardware-based implementation for adapting the protected messaging system to an existing conventional system, according to one or more embodiments of the present invention.

[015] Figures 7A and 7B illustrate exemplary process flows according to one embodiment of the present invention.

[016] Figure 8 illustrates exemplary formats of protected messages used to request and respond to online status verification requests, according to one or more embodiments of the present invention.

[017] Figures 9A and 9B illustrate exemplary process flows according to one embodiment of the present invention.

[018] Exemplary aspects of the present invention will be described with reference to the accompanying drawings. The drawing in which an element first appears is normally indicated by the leftmost digit(s) in the corresponding reference number. SUMMARY OF THE INVENTION

[019] Once again, conventional communication protocols and electrical / electronic (E / E) architectures present several disadvantages, Petition 870260071805, dated 07 / 20 / 2026, page 107 / 320 4 / 94 primarily in relation to the processing capacity, overhead, and time required to generate the shared keys necessary to ensure authentic and secure communications across the network. For example, a typical I / E architecture used to communicate secure messages, as discussed below, might comprise a system of interconnected “nodes,” which can represent any type of suitable 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 systems can be on the order of tens or hundreds, and each node can transmit secure messages to other nodes and receive secure messages from other nodes within the interconnected system.

[020] The underlying network supporting the interconnected node system can be implemented as part of any suitable type of system that utilizes protected communications, such as, for example, a vehicular network, industrial networks like those used in production lines, etc. For example, an interconnected node system might comprise groups of nodes that communicate securely via a connected transmission bus to facilitate a real-time control system. Such a real-time control system might utilize sensor data communication, control data, or other data, and might include components that, in case of failure, could pose a significant safety risk. Thus, specific operational parameters need to be considered to ensure secure and robust communications within such systems.

[021] For example, any of the nodes in such a real-time control system can be restarted at any time (for example, if an internal supervisory timer is triggered), and all data in the node's volatile memory (RAM) is lost as a result. Furthermore, after a node starts (or restarts), it Petition 870260071805, dated 07 / 20 / 2026, page 108 / 320 5 / 94 must be able to resume communications very quickly, i.e., in a few milliseconds, to receive and send messages (e.g., sensor data, actuator commands, etc.) to / from other nodes on the bus. Furthermore, messages must be protected against tampering by an attacker and potentially encrypted to prevent an attacker from viewing the message content. A node must also be protected against replay attacks (i.e., when an attacker copies a message sent on the bus and retransmits it later to try to make receiving nodes act accordingly). Additionally, cryptographic systems for protected messages must change keys when they become "exhausted" (i.e., used too frequently), and each group of nodes involved in protected communications needs to agree on the same values ​​for a replacement key.

[022] To this end, it is observed that protected messages are generated by a node before transmission through the use of one or more shared keys, which may also be called shared secrets or secret keys, and generally do not change during the lifetime of the nodes. Shared keys are typically stored in the local memory of each node and provided as an input to a cryptographic block, which implements a cryptographic function, such as a key derivation function (KDF). The cryptographic block also receives an input in the form of a counter value, which may change over time, as well as any other suitable inputs that are used to ensure the uniqueness of the keys generated in this way.The cryptographic block can therefore generate, for each set of entries that includes at least the shared key and a counter value, one or more session keys, which can be used for authentication and / or encryption of the protected messages. Thus, when symmetric cryptography is implemented, the node(s) that... Petition 870260071805, dated 07 / 20 / 2026, p. 109 / 320 6 / 94 receive(s) the protected message and use(s) the same session key(s) as the node that transmitted the protected message.

[023] However, shared keys and session keys should not be transmitted unencrypted (i.e., in plaintext), as this poses a significant security risk, exposing pre-shared keys to potential attackers. Thus, to avoid transmitting keys in plaintext, conventional communication protocols and I / E architectures utilize a system called key agreement. This process ensures that nodes involved in secure communications agree to use the same session key (through a key agreement protocol) and, when the key runs out or needs to be updated, the nodes agree on a new session key. Thus, for a node that has been restarted and has forgotten all the details of previous keys, the node cannot replay messages using an old session key.

[024] Therefore, a monotonically increasing sequence number is normally used to avoid replaying messages where the key has not changed, which can also be called the novelty value (VV). This is accomplished through the MKA (MACsec Key Agreement) protocol of the current Ethernet standard. However, this introduces problems when implemented as part of real-time protected control systems. Specifically, the protocol takes a long time to complete, and a node that has been restarted needs to wait a long time for a consensus to be established on a new session key before the node can receive and send protected messages again (i.e., a large number of messages must be exchanged between a group of nodes and a central key server).

[025] For example, and moving on to Figures 1A and 1B, blocks A, B, C and D represent high-priority frames according to a protocol of Petition 870260071805, dated 07 / 20 / 2026, p. 110 / 320 7 / 94 key agreement communication, such as MACsec, for example. After an interruption in communications, for example, when a node is restarted, key messages need to be transmitted from each node to other nodes in the system to ensure synchronization between all nodes in a group. Thus, the blocks at the bottom of Figure 1A represent key distribution messages when protected messages have a lower priority. In this case, it is shown that protected communications cannot occur between nodes B, C, and D until a new key message is distributed to each of nodes B, C, and D. This adds latency to protected communications and is therefore undesirable for low-priority protected message communication. This also introduces a problem for higher-priority communications, as shown in Figure 1B.Specifically, Figure 1B illustrates the introduction of latency as a result of the need to distribute key messages to each of the communicating nodes A, B, C, and D. Thus, conventional key agreement protocols are not suitable for nodes connected on a transmission bus for use in real-time control systems, as such latency can introduce significant security risks.

[026] The methods described below aim to solve this problem, achieving key agreement without the need to exchange separate key agreement messages and, consequently, meeting the stringent startup time requirements for real-time control systems. This is achieved, as discussed in more detail below, by using a global group key counter, with each node storing in its non-volatile memory the most recent value of this counter that was observed through the last protected message received. This counter value increases monotonically, and the nodes maintain synchronization by transmitting this counter value (or a representation of the counter value) in each protected message. Petition 870260071805, dated 07 / 20 / 2026, page 111 / 320 8 / 94

[027] The counter may also be called here alternatively the key counter, as it is used (along with a pre-shared key, also stored in non-volatile memory) by the cryptographic block to derive one or more session keys, as noted above. Since different nodes in a communication group may use the same cryptographic function, the same key counter and the same shared key generate the same session key. As a result, when nodes synchronize with the same global key counter of the group, they are, in effect, agreeing to use the same session key.

[028] Again, each protected message includes the key counter or, more precisely, a representation (e.g., a bit portion) of the key counter to allow receiving nodes to establish the group's global key counter value using their local copies, which, in turn, are stored in non-volatile memory. This facilitates key agreement because the key counter changes infrequently. Thus, including a portion of the key counter, such as a smaller predetermined number of truncated bits, is sufficient for each receiving node to verify that the counter value used by the transmitting node (and sent in the protected message) matches the key counter stored locally on the receiving node. And since the key counter representation is carried in all protected messages, there is no need for any separate key agreement message.In other words, the key agreement is implicit in all protected messages, and therefore no delay results from waiting for a consensus agreement between nodes, as is the case with conventional systems.

[029] In addition, the methods described here can extend the use of key counters and pre-shared keys to protect against weak replay attacks by implementing a tracking solution. Petition 870260071805, dated 07 / 20 / 2026, page 112 / 320 9 / 94 active members. This active member tracking solution defines one or more member groups that can include the entirety of the number of interconnected nodes in a system or a subset of those nodes. Once the member groups are defined, each node within a member group can request, or “challenge,” other nodes within the same group at any time to verify its online status. In other words, a node challenging other nodes in the group can request that they respond to a challenge request. These challenge requests can be made through a representation of a query value encoded in the protected message, and can be contained in any field of the protected message. One advantage is that the query value representation can be a small field (e.g., a single bit), so challenge requests can be easily added to protected messages that will be transmitted in the course of typical communications between nodes.For example, the query value representation can be added as a field or any suitable part of a protected message generated and transmitted in the course of typical protected message communications between interconnected nodes in the same membership group. This advantageously eliminates the need to transmit challenge requests as part of separate, dedicated messages.

[030] The query value representation can be used by each node in the member group to identify that an online state check has been requested from each node that issued such a challenge. Each node in the member group can therefore maintain, through local storage, a record of query values ​​(e.g., a bit sequence) corresponding to each node's challenge requests. In this way, each node in the member group tracks an indication of each other node's challenge requests, which is correlated with each requesting node through a dedicated and predetermined bit position in the bit sequence per node in the member group. In response to such challenge requests, each node can Petition 870260071805, dated 07 / 20 / 2026, page 113 / 320 10 / 94 transmits a protected message that includes responses (e.g., in a field or other part of the protected message) that encode its locally stored bit sequence, which identifies the current locally stored record of challenge query values ​​from all other nodes in the member group. Thus, and similarly to what was observed above for the query value representation, the encoded responses can also be relatively small (e.g., a bit sequence) and be added to the next protected message to be transmitted between nodes in a member group. Therefore, responses to challenge requests also do not require the use of separate, dedicated messages. As noted in more detail below, the use of challenge requests and responses as part of typical protected message communications advantageously allows for greater security without negatively impacting message bandwidth.

[031] Each node that has requested a challenge can therefore check if a node is online by identifying whether an encoded value has been set in the protected message that corresponds to the requesting node's predetermined bit position. The encoded value in this bit position is then compared with a predetermined value (e.g., '1') and associated with the node that previously requested the challenge via the reserved bit position. The encoded value contained in this bit position therefore represents an affirmative response to the challenge. Otherwise, the protected message may not be accepted, as the online status check request was not acknowledged by the responding node.The use of member groups and the ability to perform such challenge requests can be particularly useful in combination with the use of counter values ​​and pre-shared keys discussed above, as this provides an additional layer of security for protection against weak replay attacks. This is the result of leveraging the counter validation schemes discussed here, which... Petition 870260071805, dated 07 / 20 / 2026, page 114 / 320 11 / 94 ensures that the bit sequence cannot be manipulated. DETAILED DESCRIPTION

[032] In the following description, several specific details are presented to provide a complete understanding of aspects of the present invention. However, it will be evident to those skilled in the art that aspects, including structures, systems, and methods, can be practiced without these specific details. The description and representation presented here are the common means used by those experienced or skilled in the art to convey, in the most effective way, the essence of their work to others skilled in the art. In other cases, well-known methods, procedures, components, and circuit assemblies have not been described in detail to avoid unnecessarily obscuring aspects of the present invention.

[033] The modalities presented here are divided into two separate sections for ease of explanation. Section I addresses the use of protected communications that leverage locally stored key counter values, according to a real-time bus key distribution system that eliminates the need for dedicated key agreement messages. Section II addresses the use of active member groups to provide an additional layer of security. Although these modalities are discussed separately, it is noted that either of the modalities described in Section I or Section II can be combined with the other, and any architectures, communication protocols, and / or techniques described in Section I are also applicable to the modalities described in Section II, and vice versa.For example, any of the modalities described here in relation to Section I may optionally include the use of active member modalities, as described in Section II, as an additional layer of security for protection against weak replay attacks. I. Secured communications using key counter values Petition 870260071805, dated 07 / 20 / 2026, page 115 / 320 12 / 94 stored locally

[034] As discussed in more detail below, the modes described in this document can be implemented according to any suitable communication architecture that uses a transmission bus to facilitate secure communications between a system of interconnected nodes. The transmission bus can be implemented, for example, according to what is known as a “multipoint” scheme. In other words, although the modes described in this document can function according to a point-to-point communication architecture, the modes can be particularly useful for use in a point-to-multipoint communication architecture.Furthermore, although not limited to use in real-time control systems, the modalities described in this document can be advantageously implemented as part of such systems, which require more stringent considerations regarding safety, timing, and robustness compared to conventional node-based communication networks.

[035] For example, and using a vehicle real-time control system as an example, the nodes in such real-time control systems can control critical safety components, such as steering, braking, acceleration, etc., of the vehicle. As a result, it is crucial that the protected messages between these nodes are sent and received with low latency, that the nodes come back online quickly after being restarted, and that the system nodes are not negatively affected while waiting for the restarted nodes to come back online. Furthermore, due to increasing security considerations and to resist reverse engineering attempts, a real-time control system needs to be resistant to malicious attacks that may attempt to gain unauthorized access to system keys or other information.

[036] For example, one of these attacks includes so-called “attacks of Petition 870260071805, dated 07 / 20 / 2026, page 116 / 32013 / 94 repetition”, which may include “strong” and “weak” replay attacks. The methods in this Section are primarily aimed at preventing strong replay attacks, which force the out-of-order retransmission of protected messages to other nodes. To protect against such attacks, conventional systems use a “novelty value” (NV) to prevent the repetition of the same (legitimate) message, forcing receivers to act on it at an invalid time. These conventional systems, which include the Control Area Bus (CAN) and multipoint Ethernet communication protocols such as 10BASE-T1S and 10Base-T1L, result in out-of-order frame transmission due to priority queuing. Thus, these conventional systems have adopted an “acceptance window”, although this still allows replay attacks, but confines such attacks to a window to try to limit this possibility.However, the main disadvantage of such a system is that the window can be relatively large (for example, 1 second) and, as a result, this reduces, but does not eliminate, the possibility of exposure to repeat attacks.

[037] Other attacks include denial-of-service attacks using key agreement messages. As noted above, the use of conventional key agreement protocols requires a substantial number of these messages to be transmitted within the network, which increases quadratically with the number of nodes. Thus, it is possible to exploit the use of such a large number of messages to maliciously trigger a key re-agreement process, causing the disruption of bus traffic. Furthermore, these attacks can be used to trigger multiple key re-agreements, completely disrupting protected traffic.

[038] Additional attacks include the reuse of Secure Channel Indicator (SCI) values, the details of which are discussed later, to break assumptions about nonce reuse. For example, a malware-infected node could use SCI values ​​assigned to another node and force the device to send Petition 870260071805, dated 07 / 20 / 2026, page 117 / 320 14 / 94 messages that could reuse a nonce value, implicitly leaking the session key. Additionally, attacks can include denial-of-service attacks on a key agreement server, which can bring down the server with a bus shutdown attack, thus preventing the server from issuing new keys.

[039] The modalities described here address these issues to increase the robustness of real-time control systems against such attacks. To this end, the modalities described here do not use key agreement messages and instead can operate independently of a key agreement server. Thus, instead of using a centralized key agreement system, the modalities described here can maintain a locally stored copy of the counter values ​​that would conventionally be derived from a central server. Again, a representation of the counter value can be transmitted as part of each protected message, which can be used by a receiving node to validate the counter and verify the protected message. A. Node Architecture

[040] Figure 2A illustrates a node architecture, according to one or more embodiments of the present invention. Node 200 can be identified with any suitable type of component, and can represent a node in a system of interconnected nodes, this system being illustrated in Figure 3 and discussed further below. For example, node 200 can be identified with part of an electronic control unit (ECU), a sensor, an actuator, a main module, etc. The various nodes in such an interconnected system may differ in type and / or function, although each node may have a common functionality, as discussed here in relation to node 200. Thus, each node in the system of interconnected nodes can be configured to transmit and / or receive protected messages in the same manner described here in relation to node 200. Petition 870260071805, dated 07 / 20 / 2026, page 118 / 320 15 / 94

[041] Node 200, as shown in Figure 2A, may represent a node in the system of interconnected nodes configured to communicate via a bus according to a multipoint scheme, as discussed herein. Such a multipoint scheme may, for example, be part of a vehicular I / E architecture, as discussed above, which may include a CAN bus architecture or other suitable vehicular I / E architecture. The system of interconnected nodes may support the communication of protected messages according to any suitable type of system, such as a real-time control system that may be implemented in a vehicle. Thus, node 200 may be one of any suitable number of nodes communicating with each other by transmitting and receiving protected messages via the data interface 210, which may be coupled to and / or form part of a bus used as part of any suitable type of point-to-point or multipoint scheme.Data interface 210 may comprise any suitable number and / or type of data interface(s) to facilitate the exchange of secure messages between node 200 and any suitable number of other nodes within the interconnected node system.

[042] Node 200 can transmit and / or receive protected messages, as discussed in this document, to communicate with other nodes within the interconnected node system using any suitable number and / or type of communication protocols and corresponding operating modes. For example, node 200 can be configured to receive and transmit protected messages according to communication protocols that utilize the AES-GCMSIV (Galois / Counter Authenticated Encryption) operating mode, the Counter with CBC-MAC (CCM) operating mode, communication protocols that utilize operating modes that implement the ShangMi 4 (SM4) cipher, any suitable type of Ethernet communication protocol (e.g., multipoint Ethernet communication protocols such as 10BASE-T1S, 10BASE-T1L, the Ethernet MACsec standard, etc.), any Petition 870260071805, dated 07 / 20 / 2026, pp. 119 / 320 16 / 94 suitable vehicular network protocol, such as a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, any suitable communication protocol that implements the Authenticated Encryption with Associated Data (AEAD) operating modes, etc.

[043] Again, node 200 (as well as all other nodes in the interconnected system) is configured to transmit protected messages to other nodes and to receive protected messages transmitted by other nodes through data interface 210. Thus, although each node in the interconnected node system (which includes node 200) is configured to perform transmitting and receiving functions, the term “transmitting node” is used here to refer to any node that is currently performing the transmission of a protected message and / or performing any functions related to these protected message transmissions, while the term “receiving node” is used here to refer to any node that is currently receiving a protected message and / or performing any functions related to these protected message receptions.

[044] To perform protected message communications, node 200 comprises a session key generator 202, a non-volatile memory 204, a volatile memory 206, and a protected message handler 208. These components are illustrated in Figure 2A as separate entities, with their respective functions described separately for ease of explanation. However, any components of node 200 may be integrated or otherwise combined with each other. Node 200 may also comprise additional or alternative components, such as those shown and discussed here in relation to Figure 2A. Furthermore, although node 200 is shown and described here in relation to the use of non-volatile memory 204 and volatile memory 206, this is only an example and not a limitation. Petition 870260071805, dated 07 / 20 / 2026, pages 120 / 320 17 / 94 Any data stored in non-volatile memory 204 and volatile memory 206 can be additionally or alternatively stored in other memories, which may be part of node 200 or external components to node 200. For example, any data illustrated in the Figures as being stored in volatile memory can alternatively be stored in non-volatile memory and vice versa. However, it is recognized that specific types of static data, such as secret keys, may be advantageously stored in non-volatile memory to ensure their security. Furthermore, it may be desirable to ensure the persistence of static data, such as secret keys, in case a node goes offline and returns to the bus, as can occur with a node restart.

[045] Furthermore, node 200 is shown and discussed here in relation to the execution of the functions of transmitting and receiving protected messages, although it is understood that node 200 may comprise separate components to perform each respective function or, alternatively, comprise a combination of such components to selectively implement both functions independently of each other. Thus, the protected message handler 208 may represent an encoder, a decoder, or a combination of both to facilitate the operation of node 200 according to any of these previously mentioned modes of operation.

[046] The protected message handler 208 may comprise any suitable number and / or type of components, with an example of such components being shown in Figure 2A by way of example and not limitation. For example, the protected message handler 208 may comprise the communication circuitry set 208.1, which may be coupled to the data interface 210 and thus to the corresponding bus of the interconnected node system, as discussed herein. Thus, the data interface 210 may Petition 870260071805, dated 07 / 20 / 2026, pp. 121 / 320 18 / 94 includes any suitable implementation of components for this purpose, such as, for example, wires, buses and / or their respective terminals, ports, pins, etc. The communication circuit set 208.1 can be implemented as any suitable hardware components that allow communication between node 200 and other nodes within the interconnected node system, as discussed below, through the data interface 210. Thus, the communication circuit set 208.1 can transmit protected messages to the data interface 210 and receive protected messages from the data interface 210 according to any number and / or type of suitable communication protocols, such as those discussed below. For this purpose, the communication circuit set 208.1 can comprise hardware components, software components, or combinations of both, which are normally associated with components configured to perform data communications.For example, the 208.1 communication circuit set may comprise any suitable number of ports, drivers, temporary transmit and / or receive storage devices, switches, etc.

[047] The processing circuitry 208.2 may comprise any suitable number and / or type of dedicated hardware components, such as a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), dedicated logic, and / or other circuitry assemblies, etc. The processing circuitry 208.2 may be implemented as one or more processors and / or cores, which may execute computer-readable instructions stored in program memory 208.3 to perform any of several functions, as discussed in detail later on. Thus, although the processing circuitry 208.2 is illustrated in Figure 2A as a separate entity from the session key generator 202, it is understood that the circuitry 208.2 Petition 870260071805, dated 07 / 20 / 2026, pp. 122 / 320 19 / 94 processing 208.2 can facilitate the operations of the session key generator 202, as discussed further below, and therefore, the session key generator 202 and the processing circuit assembly 208.2 may, in some embodiments, comprise the same component(s).

[048] Program memory 208.3 may comprise any suitable type of non-transient computer-readable medium, such as volatile memory, non-volatile memory, or combinations thereof. Insofar as node 200 implements software-based solutions to perform the various functions discussed herein, this may be achieved, for example, by means of the processing circuitry 208.2 executing instructions stored in program memory 208.3. B. Safe zones

[049] Again, node 200 can represent one of several nodes that form a system of interconnected nodes. Figure 3 illustrates an example of such a system of interconnected nodes, comprising a total of X nodes. Node 200 can be identified with any of the Ni-Nx nodes, and each of the Ni-Nx nodes can transmit and receive protected messages in a manner similar to node 200, as discussed here.

[050] The 300 interconnected node system (also referred to herein simply as the 300 system) may include any suitable number of secure zones (SZ), three of which are shown in Figure 3 for brevity, represented as secure zones SZ-A, SZ-B, and SZ-C. These secure zones may be defined in accordance with any of the communication protocols discussed herein, and the nodes of the 300 system may identify the intended receiving nodes of the protected messages transmitted and received within these secure zones by means of the use of a secure channel indicator (SCI) field, as discussed in more detail below.

[051] Continuing with reference to Figure 3, each of the safe zones, Petition 870260071805, dated 07 / 20 / 2026, pp. 123 / 320 20 / 94, in turn, comprises a respective group of nodes. For example, the secure zone SZ-A of the 300 system, as shown in Figure 3, comprises nodes Ni, N2, and N3. The secure zone SZ-B comprises nodes N3 and N4, and the secure zone SZ-C comprises nodes N3 and Nx. The modalities discussed here can implement the transmission and reception of protected messages according to a specific secure zone, within which the transmitting node and the intended receivers of the protected message are part. However, the modalities are not limited to their use with a system comprising such protected nodes, and can be implemented as part of any suitable communication system, i.e., with or without the use of secure zones. C. Key Generation and Management

[052] To enable the use of protected messages, node 200, as well as all other nodes in system 300, stores a set of shared keys, based on the secure zone, when secure zones are used. In other words, each node in system 300 stores a shared key, which may alternatively be called a secret key or shared secret, in non-volatile memory (NVM). With reference now to Figure 2A, this is illustrated by node 200 comprising a non-volatile memory 204 configured to store a shared key for each secure zone of which node 200 is a member within system 300. Thus, node 200 can be identified with node N3, as shown in Figure 3, for ease of explanation, since node N3 is a member of each of the secure zones SZ-A, SZ-B, and SZ-C. Therefore, node 200, in this case, stores three shared keys, A, B, and C, in non-volatile memory 204.Obviously, node 200 can store a greater or lesser number of shared keys, depending on the number of secure zones of which node 200 is a member. Consequently, in one embodiment, each node is configured to store, in its non-volatile memory, any suitable number M of keys. Petition 870260071805, dated 07 / 20 / 2026, pp. 124 / 320 21 / 94 shared keys, where M is greater than or equal to the number of secure zones of which the node is a member. For example, node 200 can store one shared key per secure zone, as shown in Figure 2A, although this is just an example and not a limitation, since node 200 can store any suitable number of shared keys per secure zone.

[053] Thus, NVM 204 can be implemented as any suitable type of non-volatile memory with any suitable size to store any suitable number of shared keys. Each of the shared keys can represent a predetermined bit sequence or other suitable encoded numeric value with any suitable length. Each node within the same secure zone therefore stores the same shared key in its respective NVM, which is used for the transmission and reception of protected messages for that secure zone, but not for other secure zones. For example, nodes Ni and N2 can store only the shared key A for secure zone A, while node N2 can store only the shared key B for secure zone B. The secret key is usually static and does not change during the operational lifetime of a node and can therefore be written, stored, etc., as part of an initial manufacturing process.Alternatively, shared keys can be written to NVM 204 via node 200 or another suitable device. To ensure security, shared keys are not included in the protected messages communicated between nodes and can only be accessed or known by each node through its respective NVM, and are therefore unknown to other nodes in system 300.

[054] In any case, the shared “permanent” keys are used to facilitate the generation of temporary session keys, which can be called here simply session keys, and are used to transmit and receive protected messages within the same secure zones. For this, Petition 870260071805, dated 07 / 20 / 2026, pp. 125 / 320 22 / 94 refer to Figure 2B, which provides additional details regarding the session key generator 202, as shown in Figure 2A. Session keys are generated using a key derivation function (KDF), which represents a specific cryptographic function according to the specific communication protocol implemented by node 200. The use of KDFs is generally known and therefore, further details about the operation of the KDF are not described here for the sake of brevity.

[055] Like shared keys, session keys can represent a bit sequence or other suitable encoded numeric value of any suitable length. In either case, once generated, the 208.2 processing circuitry can use a respective session key per secure zone to generate each protected message transmitted to other nodes within the same secure zone, and also use that same session key to authenticate and / or decrypt protected messages received from nodes within the same secure zone. Thus, the 208.2 processing circuitry can perform any suitable type of cryptographic function that uses, as a cryptographic key, the session keys generated to generate the protected messages.

[056] Furthermore, it may be particularly advantageous to implement one session key for authentication purposes and a second for encryption purposes on a node, since some cryptographic functions require distinct keys for authentication and encryption. It is also noted that, in some alternative embodiments, an individual session key may be assigned to individual nodes participating in a secure zone. In this scenario, for each protected message, the key derivation function (KDF) may be executed (i.e., transmit and / or receive). In particular, for a hardware implementation of KDF, this may be accomplished without penalty.

[057] Note that session key generator 202 can implement Petition 870260071805, dated 07 / 20 / 2026, pp. 126 / 320 23 / 94 any suitable type of KDF to generate any suitable number of session keys from each respective shared key. That is, the 202 session key generator is configured to generate, for each of the secure zones, a respective temporary session key using a respective shared key and a respective key counter value, according to a respective cryptographic function. Furthermore, for the transmission of a protected message to each group of nodes within a secure zone, each respective protected message comprises a plurality of fields, as discussed later, with one of the fields comprising a representation of the respective counter value used to generate the session key used to generate the protected message. Further details on the content and format of the protected messages are discussed later.

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

[059] In any case, it is observed that the same KDF algorithm will generate Petition 870260071805, dated 07 / 20 / 2026, page 127 / 320 24 / 94 repeatedly the same session key from the same entries. Thus, and as will be described in more detail below, other nodes can be configured with the same KDFs and shared keys to authenticate and / or decrypt protected messages using their own session keys and entries, which must then match the session keys used when the protected message was generated by the transmitting node (i.e., before being received by the receiving node).

[060] Although session keys are described here as being used to transmit protected messages to all other receiving nodes within a secure zone, this is merely an example for ease of explanation. Specifically, session keys, as described here, can be implemented to generate protected messages that may represent only authentication messages or, alternatively, authentication and encryption messages. For example, for the various AES-GCM-based protocols (used in MACsec), an integrity check value (ICV) is computed according to their respective algorithms. For messages protected only by authentication, the ICV is calculated without encrypted data, and for authenticated and encrypted protected messages, the ICV is computed in parallel with the encrypted data.Messages for authentication only can be particularly useful, for example, in scenarios where a message needs to be read first to quickly execute a specific control or command without first decrypting the protected message payload. The modalities discussed here can implement any suitable algorithms for computing ICVs, including known techniques. According to these cryptographic functions used to generate the ICV, the inputs typically comprise a key (e.g., the session key), a counter value (e.g., the key counter value), the message plaintext (when present), and a current novelty value (FV). Petition 870260071805, dated 07 / 20 / 2026, pp. 128 / 320 25 / 94 transmitted in the protected message.

[061] In any case, based on the specific cryptographic algorithm used to compute the ICV, the ICV can be generated using the same key used for data encryption (i.e., the encrypted payload) or a different key. In both cases, the keys used for ICV generation and data encryption can comprise the locally stored session keys of the transmitting node, which, in turn, can comprise the same session keys or different session keys, in various modes, that are identified with the key counter(s) for a specific secure zone. Thus, for authentication purposes, a transmitting node can use its locally stored session key to compute the ICV, while, for authenticated and encrypted protected messages, the transmitting node can use its locally stored session key(s) to compute both the ICV and the encrypted payload.For both types of protected messages, the ICV is verified through the receiving node to establish the authentication of the protected message, as discussed further below.

[062] Thus, the modalities include any suitable number of session keys being generated from the same shared key and KDF, with a different key counter value (or other different inputs) being used to generate each different session key in this way. Alternatively, the 202 session key generator can generate any suitable number of different session keys per secure zone, using the same inputs and KDF, but a different shared key, to thus generate each different session key in this way.

[063] To provide an illustrative example, the 202 session key generator can be configured to generate, from each stored shared key, two respective temporary session keys, in accordance with the Petition 870260071805, dated 07 / 20 / 2026, pp. 129 / 320 26 / 94 same cryptographic function. Thus, the same key counter value can be used to generate different session keys from the same shared key, varying other entries to the KDF. Continuing with this example, a first of the temporary session keys generated in this way can allow a receiving node to decrypt the protected message, while a second of the temporary session keys generated in this way can allow a receiving node to authenticate the protected message. In other words, the nodes within each secure zone can operate according to a predetermined scheme, so that specific session keys are used for authentication, encryption, or both, of protected messages.

[064] Again, a variable related to the generation of different session keys from the same shared key is the key counter value, which can also be called the counter value here. Thus, each receiving node needs to ensure that its session key has been generated with the same key counter value as the transmitting node; otherwise, the receiving node will not be able to authenticate and / or decrypt the protected message. In this way, the modalities described here advantageously allow nodes to synchronize their key counter values ​​and therefore their session keys without the use of key messages.

[065] Therefore, it is prudent now to provide further details on the conventional use of key counter values. It is noted that conventional systems use a centralized server, control plane, main module, etc., to maintain a global counter value, which needs to be communicated to the nodes, as discussed above, as part of the key agreement messages. However, embodiments of the present invention recognize that session keys can alternatively be maintained and derived locally, eliminating the need for communication with a centralized entity for the agreement. Petition 870260071805, dated 07 / 20 / 2026, pp. 130 / 320 27 / 94 keys.

[066] To this end, each node in the 300 system can comprise any suitable number of counters, with one for each shared key, as shown in Figure 2B. The counters can be implemented as any hardware components, software components, or combinations of both, allowing the generation of unique counter values ​​that can be represented by any suitable number of bits. Each counter can be implemented, for example, to generate a monotonically increasing counter value that is incremented in response to one or more predefined conditions being met, which may be the result of a “key renewal” event. Such a key renewal event can occur, for example, in response to any suitable number of conditions, which can be voluntary or triggered by a security alert.For example, a node might perform a key renewal when a number of protected messages are transmitted with a corresponding session key exceeding a predetermined number of messages (i.e., session key “exhaustion”), the expiration of a predetermined time period, each system initialization, etc. To provide another example, key renewal conditions might include a security alert that can be detected by a centralized server, another node, a host processor, etc. The security alert could be sent to node 200 via data interface 210 or another suitable data interface, and explicitly instruct node 200 to perform a key renewal process.

[067] Thus, the 208.2 processing circuitry of node 200 can periodically perform a key renewal process according to the various conditions discussed above. In one embodiment, the 208.2 processing circuitry can implement a rate limiter configured to limit the number of key renewal operations within a given period. Petition 870260071805, dated 07 / 20 / 2026, pp. 131 / 320 28 / 94 time. This could include, for example, a prioritization-based system that can be implemented through node 200. Such a system could take into account supervisory timer reset cycles, for example, and comprise the storage of one or more priority flags in NVM 204, the presence of which cancels the triggering of the key renewal process. For example, non-volatile memory could store such a flag, which is indicative of some event that, when present, cancels the key renewal process. Thus, while the flag is stored in NVM 204, the 208.2 processing circuitry will not execute a key renewal operation, despite any of the aforementioned conditions being met. The priority flag can be cleared after a predetermined time period has elapsed, as soon as the event ends, etc.so that the key counter is not incremented while the priority flag is set.

[068] In some embodiments, the processing circuitry set 208.2 may implement (for example, by executing instructions stored in program memory 208.3) a stable storage algorithm, which may also be called an atomic storage algorithm, to perform the key renewal process. Stable storage is a classification of computer data storage technology that guarantees atomicity for any write operation and allows software to be written robustly against some hardware and power failures. To be considered atomic, when reading back a portion of the disk that has just been written, a storage subsystem must return the written data or the data that was in that portion of the disk before the write operations. Stable storage algorithms generally aim to eliminate corrupted data in storage.For this reason, the data is stored more than once or with an error correction code, so that it is always possible to read the value correctly. Petition 870260071805, dated 07 / 20 / 2026, page 132 / 320 29 / 94 most recently corrupted. The use of such a stable storage algorithm can be particularly useful to protect against a power failure or instability during the increment process that does not result in a corrupted key counter value.

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

[070] For example, and as shown in Figure 2A, NVM 204 can store any suitable number of key counter values, which are correlated to each of the stored shared keys. In this way, NVM 204 stores, for each of the secure zones, a respective shared key and a respective key counter value. That is, the key counter values ​​can be different from each other in the different secure zones, although the value of each key counter can be synchronized between the nodes within each secure zone, as discussed later.

[071] A representation of this key counter value can be included in each protected message in an unencrypted form, that is, “in text”. Petition 870260071805, dated 07 / 20 / 2026, page 133 / 320 "30 / 94 clean". Therefore, and as discussed in more detail below, each receiving node can verify the validity of the key counter value based on a comparison of the key counter value representation in the received protected message with the key counter value stored locally on the receiving node. Since each node in the 300 system can store key counter values ​​in this way, a receiving node can determine whether a counter value computed from the counter value representation contained in the protected message matches the locally stored counter value.

[072] Otherwise, the receiving node can increment and overwrite its locally stored key counter value to match the counter value used to generate the session key and the protected message, pending verification of the protected message, as discussed in more detail below. That is, before updating the locally stored key counter value in this way, the receiving node can validate the key counter value represented in the protected message by generating a session key (through its session key generator) from the computed counter value (i.e., the representation of the counter value sent in the protected message). This temporary session key is then used on the receiving node to verify a matching integrity check value (ICV) contained in the protected message.In other words, the representation of the counter value in the protected message allows a receiving node to derive a temporary session key, which is used to validate the counter value used by the transmitting node to generate the session key that was used to generate the protected message. This process is described in more detail below.

[073] Again, session keys generated by the session key generator at any given time are considered temporary, and can be changed when key counter values ​​are incremented, as Petition 870260071805, dated 07 / 20 / 2026, page 134 / 320 31 / 94 observed above. Thus, volatile memory 206 is configured to store each of the session keys generated by session key generator 202. Temporary session keys can be overwritten or deleted as updated session keys are generated (for example, when the counter value is incremented), as discussed above.

[074] Protected messages can also be transmitted with a sequence number representation. The sequence number may, in some embodiments, comprise a novelty value (VV), such as the novelty value defined in accordance with any of the communication protocols described in this document. However, although referred to in this document as a novelty value, sequence numbers are not limited to novelty values ​​defined in any specific communication protocol or standard, and may comprise a sequence of bits or other suitable encoded numeric value of any suitable length, which may be used to enhance security measures by preventing a replay attack.

[075] Thus, the novelty value is also a temporary and variable value, and therefore volatile memory 206 can also store the most recent novelty value for each transmitting node that is correlated to each session key (and, in turn, to the key counter value), as shown in Figure 2A. As a security measure, the processing circuitry 208.2 can increment the novelty value after each protected message is transmitted and after each protected message is received. That is, the novelty value can have a predetermined initial value (e.g., 1) that is incremented by a transmitting node when each protected message is transmitted and is also incremented by a receiving node as each protected message is received.

[076] It is observed that protected messages can reach a receiving node out of order, that is, the temporary storage scheme used by Petition 870260071805, dated 07 / 20 / 2026, page 135 / 320 32 / 94 A transmitting node will typically send a higher-priority message before a lower-priority one. Thus, conventional systems typically accept out-of-order messages, but use a "window" so that the messages played need to be relatively recent, in the hope that this will provide adequate protection against such attacks. Furthermore, conventional systems use multiple sequence numbers at each transmitting node (one for each secure channel), and then the transmitting node ensures that, within each of its secure channels, the sequence numbers are transmitted in order.

[077] Due to the use of key counter values ​​as described herein, the modalities discussed herein extend this conventional use of novelty values ​​in several different ways. First, each receiving node stores a record of previously received novelty values ​​that were contained in previously received and accepted protected messages, which are correlated to each transmitting node, secure zone, and current key counter value. The number of recorded novelty values ​​stored in this manner can be any suitable number, depending on the specific application.

[078] Additional details about the recording of received novelty values ​​are shown in Figure 2C, which illustrates that each key counter value is correlated with its number of previously received novelty values ​​for each transmitting node and per secure zone. Thus, the received FV record 208.1, as shown in Figure 2C, includes a set of novelty values ​​recorded per node, because each of the nodes is part of only one secure zone in this example. However, this is only an example and not a limitation, and the received FV record 208.1 can store any appropriate number of novelty values ​​for each transmitting node, based on the number of secure zones of which each node is a part. For example, if node N4 were also part of secure zone A, the received FV record 208.1 would also store a record of the values ​​of Petition 870260071805, dated 07 / 20 / 2026, pp. 136 / 320 33 / 94 news received from node N4 through secure zone A (not shown).

[079] Thus, the receiving node uses the novelty value in each received protected message to determine if a current protected message from a specific transmitting node has already been received. To do this, the receiving node consults the stored set of novelty values ​​recorded for that specific transmitting node, which can be identified through the transmitted SCI value, as discussed later. If a newly received protected message does not have a novelty value greater than the last recorded novelty value, the protected message is discarded as a duplicate. Note that the first received protected message is always accepted by the receiving node, that is, before the history of previously received novelty values ​​is available.

[080] Secondly, when the local key counter value is changed (i.e., during a key renewal process in which the key counter value is incremented), the transmitting node resets the novelty value (for the specific secure zone for which the key counter was reset) to a predetermined initial value (e.g., 1). The receiving node is configured to recognize the initial novelty value in a protected message that is received after such an event occurs. Thus, after a key renewal event occurs, the receiving node can continue storing any suitable predetermined number of the last received novelty value for previously used key counter values, so that older protected messages that are still being processed in the priority queues (and therefore with old counter values) are still validated even after the receiving node starts using a new key counter value.Alternatively, novelty values ​​stored in this way can be deleted after a predetermined period of time has elapsed by using a new key counter value. In this way, a receiving node can still receive and accept protected messages during this time. Petition 870260071805, dated 07 / 20 / 2026, page 137 / 320 34 / 94 is a key renewal event, and will accept the first message transmitted after a key renewal process has occurred.

[081] Novelty values ​​can serve different purposes for transmitting and receiving nodes. For example, a transmitting node can compare the incremented novelty value after the transmission of a protected message with a predetermined novelty value threshold to determine if a threshold number of protected messages has been transmitted, thus triggering the key renewal process as mentioned above. For example, since the transmitting node generates and stores a different session key for each secure channel, it can use the novelty value to count the messages that use the session key, i.e., the number of protected messages transmitted per session key. When the novelty value for a given secure zone reaches a predetermined threshold value, the transmitting node can increment the key counter as part of a key renewal process, as mentioned above.

[082] Thus, the predetermined threshold value may comprise a value per node or a value that represents the sum of any suitable number of nodes, such as those within the same secure zone, for example. In other words, when the same session key is used on all other transmitting nodes in the same secure zone, a quota may be set for that threshold, such that the quota for all nodes in the secure zone sums to less than a depletion count (i.e., the predetermined threshold value) for the session key.

[083] In one embodiment, the exhaustion counter can be implemented using the transmitting node ID (or SCI) in the KDF used to generate the session keys, so that there are unique session keys for each transmitting node. In this case, the exhaustion count of a transmitting node can be identified using its own session key, which reduces the number of key renewal processes, as the quota is not shared between multiple nodes. Petition 870260071805, dated 07 / 20 / 2026, page 138 / 320 35 / 94

[084] Thus, the KDF implemented by the 202 session key generator can optionally receive, as part of the additional inputs shown in Figure 2B, a secure channel identifier (SCI), which is unique throughout the system. The concept of a secure channel and the transport of a secure channel identifier are part of the Ethernet MACsec standard, as well as other communication standards, and will be discussed further below. D. Secure message format and communication protocol

[085] Figure 4A illustrates a protected message format and the corresponding processing schedule, according to one or more embodiments of the present description. The protected message, as shown in Figure 4A, can be transmitted according to any suitable communication protocol and can constitute a 400 communication protocol frame comprising any suitable number of fields. Again, the communication protocol, and therefore the accompanying 400 communication protocol frame, as shown in Figure 4A, can be identified with any suitable type of communication protocol that can be implemented to facilitate the communication of protected messages through a multipoint bus architecture.For example, the communication protocol frame 400 can be identified with a CAN communication protocol frame, a CAN FD communication protocol frame, a CAN XL communication protocol frame, an Ethernet communication protocol frame (e.g., multipoint Ethernet such as 10BASE-T1S, 10BASE-T1L), etc.

[086] In any case, the 400 communication protocol frame can be identified with a protected message that is generated by a transmitting node using a temporary session key for a specific secure zone, as discussed here in relation to node 200. The 400 communication protocol frame may include additional, fewer or alternative fields, as shown in Petition 870260071805, dated 07 / 20 / 2026, page 139 / 320 36 / 94 Figure 4A. For example, the communication protocol frame 400 comprises a header 402, an SCI 404, a counter value (CNT) representation 406 used to generate the protected message, a novelty value 408, a payload 410, an ICV 412, and an end-of-frame identifier (EOF) 414. The communication protocol frame 400 can subsequently be received by a receiving node as a protected message, which is accepted or rejected, as discussed further below.

[087] A secure channel within a secure zone comprises a single writer and multiple readers and therefore identifies a secure zone comprising nodes within the system of interconnected nodes that are intended receivers of a protected message. An SCI value can be identified by means of various communication protocols, such as the CAN XL communication protocol and the Ethernet MACsec standard. For example, according to the MACsec standard, the secure zone is defined by the shared key, and this SCI is used to identify a transmitting node. For example, the SCI can be used as one of the KDF inputs to generate unique session keys for each transmitter.

[088] Each secure channel is therefore identified with a respective SCI and is unique in the physical and logical network. Thus, the secure zones SZ-A, SZ-B, and SZ-C, as shown in Figure 3, are defined by a separate and unique SCI. The processing circuitry set 208.2 of node 200 is configured to generate the protected message comprising an SCI value that indicates which of the secure zones the protected message is destined for, i.e., the SCI identifies the secure channel and, in turn, the receivers within the secure zone to which the message is transmitted. It is assumed that the communication protocol frame 400 is received by a receiving node that is in the same secure zone as the transmitting node, which, again, is indicated by the SCI value. Another use for the SCI is to avoid the window problem for out-of-order novelty values. That is, different SCIs can be Petition 870260071805, dated 07 / 20 / 2026, pp. 140 / 320 37 / 94 are used for different priorities, so that they are in order within the same SCI (and therefore the FV is associated with an SCI rather than a transmitting node). The SCI can also be used at the application level to identify a subgroup of receiving nodes within a safe zone.

[089] The representation of counter value 406 (also referred to here as CNT 406) may comprise the integer key counter value that was used by the transmitting node to generate the session key or, alternatively, a truncated portion of the key counter value. For example, CNT 406 may comprise a predetermined number of least significant bits (e.g., 4, 6, 8, etc.) of the integer key counter value that CNT 406 represents.

[090] Thus, a receiving node (e.g., the 208.2 processing circuitry) can determine whether its local key counter value stored in NVM 204 matches CNT 406 by comparing the entire key counter value stored for the secure zone, as indicated by the SCI, or alternatively by comparing the truncated portion of CNT 406. Comparing only the least significant truncated bits of the counter value in this way is sufficient because the key counter value does not change frequently, for example, only in response to key renewal conditions, as noted in this document.

[091] Continuing with this example, if the key counter value stored locally on the receiving node matches the key counter value derived from CNT 406, the receiving node can keep its locally stored key counter value as is, determine that the key counter value represented by CNT 406 is valid, and accept the protected message. Alternatively, the receiving node can determine that the key counter value represented by CNT 406 is “provisionally” valid when the key counter value stored locally on the receiving node matches the one derived from CNT 406. Petition 870260071805, dated 07 / 20 / 2026, p. 141 / 320 38 / 94, that is, subject to additional verification processes.

[092] For example, the receiving node's 208.2 processing circuitry can be configured to validate the key counter value represented by CNT 406 by verifying the protected message in several ways. Thus, after message verification, the key counter value derived from CNT 406 is considered valid, and therefore the protected message is accepted. The verification may include, for example, the receiving node calculating a session key from the key counter value derived from CNT 406. Thus, the session key generated in this way must match the session key used by the transmitting node to generate the protected message and must also match the session key stored locally on the receiving node when the key counter value derived from CNT 406 matches the key counter value stored locally on the receiving node.Therefore, message verification can be performed by the receiving node using the session key generated from the key counter value derived from CNT 406, which is used to decrypt the protected message content to derive and verify an ICV, as discussed in more detail below.

[093] However, if the key counter value stored locally on the receiving node is less than the key counter value derived from CNT 406, this means that the locally stored key counter value is outdated, and the receiving node executes a key renewal process to update the locally stored key counter value, overwriting the current key counter value with a new value that matches the key counter value represented by CNT 406. Furthermore, for session keys associated with the current secure zone (as indicated by the SCI), after verifying the validity of the counter value through the ICV verification process described above, the receiving node generates an updated session key from the value of Petition 870260071805, dated 07 / 20 / 2026, page 142 / 320 39 / 94 updated key counter and overwrites its previously stored session key with the updated one, which should now match the session key used by the transmitting node to generate the protected message.

[094] In other words, the receiving node's 208.2 processing circuitry is configured to update the locally stored key counter value to match the key counter value computed from CNT 406 when the locally stored key counter value is less than the computed key counter value, but not to update the locally stored key counter value when the two key counter values ​​already match. Thus, and as discussed further below, the validation of the key counter value represented by CNT 406 may involve verifying the protected message based on the processing of one or more fields of the protected message.This might involve, for example, using a currently stored session key or generating an updated session key from the corresponding shared key stored in the non-volatile memory of the receiving node, as appropriate, and then using the session key (or the updated session key, as appropriate) for the verification of the protected message, as discussed in more detail below.

[095] Furthermore, if the key counter value stored locally on the receiving node is determined to be greater than that derived from CNT 406, the receiving node can retain its locally stored key counter value as is, conditionally determine that the key counter value represented by CNT 406 is invalid, and conditionally reject the protected message. Thus, the receiving node's processing circuitry 208.2 is configured to determine that the key counter value represented by CNT 406 is invalid, and to conditionally reject the protected message when the key counter value computed from CNT 406 is less than the key counter value of Petition 870260071805, dated 07 / 20 / 2026, page 143 / 320 40 / 94 keys stored locally, as this indicates a replay attack, an outdated message, or a corrupted message.

[096] Conditional rejection of the key counter value is discussed further below and may include, for example, a further determination as to whether the key counter value derived from CNT 406 in the protected message is nevertheless within a predetermined time period, which may be referred to here as the “tolerance period”. This tolerance period may represent, in some embodiments, a predetermined time period (e.g., 500 ms, 1 second, etc.) such that old key counter values ​​are accepted within the tolerance period. Thus, the tolerance period may represent the age of the derived key counter value since the last (different) key counter received. Additionally or alternatively, the tolerance period may be determined based on a series of novelty values ​​associated with the derived key counter value.In this way, communication is not interrupted for a specified period of time after a key renewal event occurs. However, once the grace period expires, messages with derived old key counter values ​​may be rejected, thus reducing the risk of replay attacks.

[097] Thus, in each case, the receiving node accepts or rejects the protected message based on the determined validity of the key counter value that is computed from CNT 406. Again, the protected message verification process implemented by the receiving node may use additional techniques to perform key counter value validation to determine whether the message should be accepted. For example, the protected message may contain a sequence number field, shown in Figures 4A and 4B as the novelty value (FV) 408. The novelty value may also be included in an unencrypted form as part of the protected message, as discussed later. The representation of the value of Petition 870260071805, dated 07 / 20 / 2026, page 144 / 320 41 / 94 novelty, which may alternatively be referred to here as FV 408, may comprise the complete novelty value used (and stored) by the transmitting node when generating the protected message or, alternatively, a truncated portion of the novelty value, such as a predetermined set of least significant bits. Thus, a receiving node can, as an additional layer of security, verify that the novelty value in a received protected message matches the novelty value stored in the receiving node's volatile memory (i.e., after the FV is incremented upon receiving the protected message). Otherwise, the message may be discarded, as the protected message may be part of a replay attack and / or have been sent out of order. Further details on the use of novelty values ​​are discussed below in relation to Figures 7A and 7B.

[098] The 410 payload can be encrypted via the 2080.2 processing circuitry of the transmitting node using the session key. This encryption process can be performed according to any suitable cryptographic function, including known cryptographic functions. Again, in various scenarios, the protected messages, as discussed here, may comprise only authentication messages or authenticated and encrypted messages. The 410 payload may therefore comprise plaintext that is part of an authentication-only message (or be omitted) or, alternatively, data that has been encrypted via the transmitting node, i.e., ciphertext.

[099] In addition, the communication protocol frame 400 comprises a field containing an ICV 412, which is generated by the processing circuitry 208.2 of the transmitting node. The ICV may be computed according to any suitable techniques, including known techniques defined according to any communication standards, as discussed herein. For example, the ICV may comprise a bit sequence of predetermined length, computed by the processing circuitry 208.2 based on any Petition 870260071805, dated 07 / 20 / 2026, page 145 / 320 42 / 94 suitable cryptographic function, such as, for example, a Cyclic Redundancy Check (CRC) or a Hash-based Message Authentication Code (HMAC). The ICV can therefore be computed by executing an appropriate cryptographic function, as mentioned above, using as inputs the current key counter value and / or the plaintext of the payload 410. The ICV may comprise data representing a specific field or data representing a combination of data from other fields of the protected message 400, for example, as shown in Figure 4A. For example, the ICV may comprise any suitable combination of the header 402 (including a security label), the integer key counter value represented by the CNT 406, the plaintext payload 410 or the ciphertext payload 410 etc.

[0100] ICV 412 can be transmitted as part of the protected message in plaintext, although payload 410 must first be decrypted by the receiving node to compute and verify the ICV with the same cryptographic function with which ICV 412 was generated by the transmitting node. To do this, the receiving node can compute the session key (for that specific secure zone) using the locally stored key counter value corresponding to the computed key counter value derived from CNT 406. Again, these key counter values ​​(initially or after key renewal) must match each other when the key counter value derived from CNT 406 is valid.In other words, and as noted above, the key counter value stored in the receiving node may already match the one used by the transmitting node, or it may be updated to match the one used by the transmitting node through a key renewal process performed by the receiving node to update its key counter value, as the case may be.

[0101] In any case, as soon as the receiving node generates a temporary session key from the key counter value computed by CNT 406, this Petition 870260071805, dated 07 / 20 / 2026, page 146 / 320 43 / 94 should correspond to the session key used by the transmitting node to generate the protected message before it is received at the receiving node. This generated session key should also correspond to the session key stored locally on the receiving node, assuming that the key counter value used by the transmitting node to generate the protected message is the same as the one stored locally on the receiving node. That is, since the same KDF, key counter value, and shared key are used by the transmitting and receiving nodes, this will result in identical session keys being issued in each case. The receiving node can then use the generated temporary session key to decrypt the 410 payload, and utilize the same cryptographic function used by the transmitting node to compute the ICV.The receiving node can therefore compare the ICV computed in this way with ICV 412 to determine if the computed key counter value derived from CNT 406 is valid and thus verify the protected message when the ICVs match and therefore accept the protected message. The receiving node can reject the message when the ICVs do not match, as the protected message is not verified and therefore the key counter value is not validated.

[0102] Figure 4B illustrates another protected message format and the corresponding processing timeline, according to one or more embodiments of the present invention. The protected message format, as shown in Figure 4B, is identical to that shown in Figure 4A with respect to the message format and fields. Thus, each of the fields 452, 454, 456, 458, 460, 462, and 464 can be identified with the same analogous fields 402, 404, 406, 408, 410, 412, and 414 of the protected message, as shown in Figure 4A. However, the protected message format, as shown in Figure 4B, can be identified with a subsequent protected message that is transmitted by the receiving node, as discussed above, after receiving the protected message shown in Figure 4A. Therefore, upon receiving and accepting the protected message shown in Figure 4A, the node Petition 870260071805, dated 07 / 20 / 2026, page 147 / 320 The 44 / 94 receiver can store the novelty value (or a portion of it) in its volatile memory, as discussed above and in relation to Figure 2C. The receiver node can then increment this novelty value when transmitting a subsequent message and store this incremented value in its volatile memory as well, as shown in Figure 2A. This is illustrated in Figure 4B by means of the FV+1 458 field.

[0103] Thus, the receiving node can become a transmitting node and transmit the protected message, as shown in Figure 4B. To do this, the (now) transmitting node can access from its volatile memory a session key according to the current key counter value and the secure zone corresponding to the receiving node(s) of the transmitted protected message. As part of this process, the transmitting node can compute the ICV and encrypt the payload to generate the 460 payload. The transmitting node also computes the current SCI based on the secure zone of the receiving node(s) of the protected message, as well as the representation of the CNT 456 counter value, which is based on the current key counter value used to compute the session key for that specific secure zone, as discussed above.Once the information for each of these fields is computed, the transmitting node assembles and transmits the protected message, as discussed above, with the process being repeated as needed for each of the receiving nodes in the 300 system. E. Examples of Hardware Implementation

[0104] Figure 5 illustrates the use of a hardware-based solution to utilize novelty values ​​according to one or more embodiments of the present description. Figure 5 shows the 400 communication protocol frame from Figure 4A, which includes a plurality of fields. The 400 communication protocol frame is identified with a protected message generated by a transmitting node. Note that if the novelty values ​​are generated according to Petition 870260071805, dated 07 / 20 / 2026, page 148 / 320 45 / 94 mentioned above, through a software-based approach, the transmitting node can reorder the protected messages, which will then be received out of order by each of the receiving nodes. Although the acceptance window regarding replay attacks may allow receiving nodes to accept such messages, the use of a software-based approach consumes considerable processing overhead.

[0105] Thus, the solution described in relation to Figure 5 allows a transmitting node to alternatively generate protected messages “in real time”, instead of being stored in a temporary storage and reordered, which is the conventional way in which protected messages are transmitted. For this, the transmitting node can implement any suitable type of timer mechanism. For example, each transmitting node can use a timer that references a cycle time representing a predetermined value, such as 10 microseconds, 5 microseconds, etc. Thus, the novelty value can still represent a sequence of bits, but these bits can comprise a binary representation of a number of “cycles”, with each cycle corresponding to a predetermined cycle time.This eliminates the need for the transmitting node to store novelty values ​​for each protected message transmitted, as shown in Figure 2A, assuming the timer runs faster than the message transmission time. In this respect, it is noted that a novelty value, in any case, should not be reused for two messages. Therefore, the novelty value, as discussed here, can generally be implemented as any suitable type of monotonically increasing counter, and as discussed in relation to Figure 5, it can include, for example, a cycle timer, a unique sequence number counter, etc.

[0106] The use of timestamps for FV can be advantageous for a system in which protected messages are not reordered by the scheme of Petition 870260071805, dated 07 / 20 / 2026, pp. 149 / 320 46 / 94 temporary storage at the transmitting node, and therefore the transmitting node only needs one secure channel. This can occur, for example, when protected messages are generated at the time of transmission (i.e., done in hardware connected to a communication protocol mechanism). This reduces the storage and processing overhead associated with multiple secure channels. In this way, the hardware-based solution allows for a simplification of the SCI to a single fixed channel on the transmitting node side, since the use of the timestamp ensures that the FV is always increasing per protected message.

[0107] Thus, for the hardware-based solution, as shown in Figure 5, the transmitting node can use a fixed SCI value that corresponds to a device address unique to that specific transmitting node. Thus, this SCI value is unique throughout the system 300. As a result of this modification, the receiving node can additionally or alternatively store in its non-volatile memory 204 and / or volatile memory 206, as shown in Figure 2C, data such as those shown in Table 500. For example, Table 500 represents a mapping of SCI values ​​(i.e., unique addresses of transmitting nodes) to previously transmitted novelty values ​​(i.e., timestamps). Table 500 can be stored in the form of a lookup table to facilitate such a hardware-based solution.Table 500 can include a unique SCI value corresponding to each transmitting node from which the receiving node is configured to receive protected messages, with 7 being shown in Figure 5 for brevity, since Table 500 can store any suitable number of SCI and FV values ​​for received encoded messages, based on the specific application.

[0108] The receiving node can therefore implement a hardware-based solution (e.g., through the 208.2 processing circuitry) configured to examine the data entries in table 500 until it finds a corresponding SCI value for SCI 404. For that entry in the table (i.e., SCI 5 in this Petition 870260071805, dated 07 / 20 / 2026, pp. 150 / 320 47 / 94 example), the table must contain a previous novelty value less than the current FV 408. If FV 408 is less than the corresponding previous FV in table 500 for SCI 5, the receiving node may reject the message, as it is likely a replay attack. Note that if the table is not large enough to store the required number of entries, additional matching may be transferred to software management (e.g., using a hash table).

[0109] Figure 6 illustrates another hardware-based implementation for adapting the protected message system to an existing conventional system, according to one or more embodiments of the present invention. Architecture 600, as shown in Figure 6, demonstrates that the embodiments described herein are protocol-agnostic. That is, the use of counter-value representations in protected messages and session keys, as discussed herein, can be implemented independently of an existing communication architecture and protocol. For example, architecture 600 comprises an existing mechanism 602, which may comprise any suitable type of conventional communication mechanism for use with a real-time control system. Some examples of the existing mechanism 602 may comprise a CANbus mechanism, an Ethernet protocol mechanism, etc., as well as any of the communication protocols discussed herein.Although a single mechanism is shown in Figure 6, the 600 architecture can comprise any suitable number of different mechanisms simultaneously, for example, a CANbus mechanism and an Ethernet mechanism.

[0110] The 600 architecture is implemented in an Advanced Extensible Interface (AXI) bus architecture, for example, and also includes TX and RX clean text queue memories for temporary storage of transmitted messages that are communicated within the specific system in which the existing 602 mechanism is implemented. Conventionally, the Petition 870260071805, dated 07 / 20 / 2026, page 151 / 320 Existing mechanism 602 controls the AXI coupled to the TX queue memory and the 604 transmission temporary store. Thus, existing mechanism 602 is configured to receive messages from the 604 transmission temporary store and to transmit these messages with an unencrypted payload according to any suitable communication protocol, such as those discussed here, for example. Furthermore, existing mechanism 602 is normally directly coupled to the AXI and the RX queue memory, and therefore existing mechanism 602 can provide received messages with unencrypted payloads to the RX queue memory for delivery to other system nodes.

[0111] However, the 600 architecture additionally comprises an accelerated real-time security mechanism (ARTIS) 610, as well as a multiplexer 612. The ARTIS 610 can be implemented as any suitable dedicated hardware components, such as a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a system-on-a-chip (SoC), dedicated logic and / or other circuit assemblies, etc. The ARTIS 610 mechanism is configured to perform any of the functions discussed here in relation to the transmit and receive nodes, such as, for example, reading the key counter value representation contained in the protected messages, deriving the necessary session keys, performing encryption, authentication and decryption, etc.ARTIS 610 can be advantageously implemented in hardware rather than software to eliminate the need to reorder protected messages and thus minimize latency. This advantageously reduces the window for replay attacks to such a small period of time that the risk of replay attacks is essentially eliminated.

[0112] The 600 architecture also comprises a 612 multiplexer, which is controlled by the ARTIS 610 mechanism via the 601 control signal. Thus, the Petition 870260071805, dated 07 / 20 / 2026, page 152 / 320 The ARTIS 610 control mechanism (49 / 94) is configured to dynamically change the operation of the system in which it is implemented (e.g., system 300) between unprotected and protected message operation. For example, the lower path of multiplexer 612 can be selected to route plaintext data from the temporary transmission store 604 to the existing mechanism 602, and the ARTIS 610 mechanism can also route received plaintext data to the RX queue memory in this operating mode.

[0113] However, the upper path of the 612 multiplexer can be selected when operating in a cryptographic mode. In this mode, plaintext messages are routed from the transmission temporary store to the ARTIS 610 engine and are used by the ARTIS 610 engine to generate encrypted payloads that are included as part of the protected messages, as discussed here. In this mode of operation, the protected messages are also routed to the RX queue memory and distributed to other receiving nodes in the system, but as protected messages (instead of unprotected messages generated by the existing 602 engine). In this way, the 600 architecture allows the simultaneous operation of an existing, unprotected messaging system with the protected messaging system modes discussed in this document. F. Illustrative Process Flows

[0114] Figures 7A and 7B illustrate the process flows used by the transmitting and receiving nodes to transmit and receive protected encoded messages, according to one or more embodiments of the present invention. With reference to Figures 7A and 7B, the process flows may comprise a method executed by and / or associated with any suitable number and / or type of components, such as one or more processors (processing circuit assemblies), hardware components, executed instructions (e.g., software components), or combinations thereof. The components may be Petition 870260071805, dated 07 / 20 / 2026, page 153 / 320 50 / 94 associated with one or more components of node 200, as discussed in this document. Flows 700 and 750 may include alternative or additional blocks not shown in Figures 7A and 7B for brevity, and may be executed in a different order than shown. Furthermore, some blocks may be optional.

[0115] Specifically, Figure 7A provides further details about the process implemented by a transmitting node when generating and transmitting a protected message. Figure 7B provides further details about the process implemented by a receiving node to validate the values ​​of key counters in a received protected message in order to accept or reject it.

[0116] Referring first to Figure 7A, process flow 700 can be implemented through any of the nodes discussed here, as well as any of the nodes included in system 300, for example, when performing a protected message transmission. This could include, for example, node 200, as discussed here in relation to Figure 2A.

[0117] Process flow 700 begins with the transmission (block 702) of a protected message. The protected message may be formatted according to any suitable communication protocol and include any suitable number of fields, such as the communication frames discussed here in relation to Figures 4A-4B.

[0118] Upon transmission of the protected message, process flow 700 includes the increment (block 704) of the novelty value via the transmitting node. This may include, for example, the processing circuitry 208.2 incrementing the locally stored novelty value (e.g., FV.A, FV.B, FV.C, etc.) based on the specific secure zone corresponding to the intended receiving node(s), as shown in Figure 2A. Thus, the novelty value that is incremented in this way can be correlated to one or more Petition 870260071805, dated 07 / 20 / 2026, page 154 / 320 51 / 94 session keys for that specific secure zone, as discussed here.

[0119] Process flow 700 further comprises the transmitting node determining (block 706) whether a key renewal condition has been met. These conditions may include any suitable predetermined conditions that, when met, result in the key counter being incremented, as discussed further below, assuming that a priority flag, if implemented, is not set. Such conditions may include, for example, a number of protected messages transmitted with a corresponding session key exceeding a predetermined number of messages, the expiration of a predetermined time period, each system initialization, the receipt of a security alert request, etc.

[0120] As an illustrative example regarding session key exhaustion, the determination of whether the number of protected messages transmitted with a given session key has exceeded a predetermined number of messages may include determining (block 706) whether the current novelty value (now incremented) exceeds a predetermined threshold value. This predetermined threshold value may be selected as any suitable value that triggers a key renewal process due to session key exhaustion, as discussed herein. For example, the threshold novelty value may be several million or several billion.

[0121] Thus, if a key renewal condition is met (for example, the incremented novelty value exceeds the predetermined limit), the transmitting node executes (block 708) a local key renewal process of the key counter values. Thus, using as an example the secure zone A above, which is assumed to be used for the transmission of the current protected message, this might include session key generator 202 incrementing (block 708) the key counter A.1 and overwriting NVM 204 with this new key counter value. Petition 870260071805, dated 07 / 20 / 2026, page 155 / 320 52 / 94 keys updated (e.g., a key counter A.1+1, not shown). Additionally, when a key renewal event occurs, the transmitting node can reset its locally stored novelty value, which is transmitted in the next protected message, to its predetermined or default value (e.g., 1), which is then incremented for subsequently transmitted messages, as noted here.

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

[0123] Process flow 700 further comprises generating (block 712) an updated session key from the incremented key counter value. This may involve, using secure zone A as an example, session key generator 202 computing session key A.2 from shared key A and the key counter value incremented according to the KDF, as shown in Figure 2B. The previous session key A.1, as shown in Figure 2A, can then be overwritten with the updated session key A.2 or otherwise invalidated for future protected transmissions. For example, the updated session key A.2 can be stored in volatile memory 206 in a new location or by overwriting the contents of session key A.1.

[0124] Process flow 700 may comprise generating (block 714) a protected message. This may include, for example, the processing circuitry 208.2 generating a protected message, as discussed in this document, with any suitable number of fields. The protected message may be generated in this manner using the original session key (e.g., session key A.1) if the novelty value is determined (block 706) to be less than the threshold value or, alternatively, the updated session key (e.g., the Petition 870260071805, dated 07 / 20 / 2026, page 156 / 320 53 / 94 session key A.2) can be used when the novelty value is determined (block 706) to be greater than the threshold value, and therefore the key counter and session key are updated. In either case, the protected message can be generated using the current session key to encrypt the protected message payload, to transmit the protected message as an authentication-only message, or to transmit the protected message as an encrypted and authenticating message. Again, the session key can be one of several (e.g., one being used for authentication and another being used for encryption). In this case, process flow 700 can be extended to selectively update any suitable number of session keys corresponding to the same novelty value.

[0125] Process flow 700 may involve queuing (block 716) the generated protected message. This may include, for example, the communication circuit set 208.1 adding the protected message to a queuing temporary store for transmission (block 702) in the appropriate order based on a message priority. Alternatively, if a hardware-based solution is implemented as discussed above in relation to Figure 5, the use of a queuing temporary store may not be necessary, and the protected message may be transmitted (block 702) as soon as it is generated (block 714). Process flow 700 may therefore be repeated for each protected message transmission via a transmitting node, with process flow 700 being applied to each subsequent protected message transmission.

[0126] With reference now to Figure 7B, process flow 750 can be implemented through any of the nodes discussed in this document, as well as any of the nodes included in system 300, for example, when receiving a protected message transmission. This may include, for example, node 200, as discussed in this document in relation to Figure 2A, when operating Petition 870260071805, dated 07 / 20 / 2026, page 157 / 320 54 / 94 as a receiving node.

[0127] Process flow 750 begins with receiving (block 752) a protected message. Again, the protected message can be formatted according to any suitable communication protocol and include any suitable number of fields, such as the communication frames discussed in this document in relation to Figures 4A-4B.

[0128] Process flow 750 further comprises determining (block 754) whether the message counter, for example, the key counter value represented by CNT 406, as discussed in this document, is less than the locally stored key counter value corresponding to the secure zone to which the protected message was sent and received. This determination may comprise, for example, comparing the representation of the key counter value encoded by CNT 406 with the locally stored key counter value for the same secure zone. For example, CNT 406 may represent a predetermined number of least significant bits of the key counter value used to generate the message encoded by the transmitting node before it is received. In this case, the determination (block 754) may comprise a comparison, using the processing circuitry 208.2, between the same predetermined corresponding number of least significant bits of the locally stored key counter value for the current secure zone. Alternatively, if the integer key counter value is represented by CNT 406, the determination (block 754) may comprise a comparison, by means of the processing circuitry 208.2, between the total value of the locally stored key counter and the integer key counter value represented by CNT 406 for the current secure zone.

[0129] In any case, if it is determined that the key counter value derived from CNT 406 is less than the stored key counter value Petition 870260071805, dated 07 / 20 / 2026, page 158 / 320 55 / 94 locally for this secure zone, process flow 750 comprises conditionally approving or rejecting the derived key counter value. For example, process flow 750 comprises a further determination as to whether (block 755) the key counter value derived from CNT 406 is within the predetermined tolerance period, as noted above. Again, this tolerance period may represent a period of time elapsed since the last receipt of a different key counter value and may additionally or alternatively be computed based on the novelty values ​​associated with the key counter value derived from CNT 406.

[0130] If the key counter value derived from CNT 406 is outside this tolerance period, the process flow consists of rejecting (block 756) the protected 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 protected message, as this indicates a replay attack, an obsolete message, or a corrupted message.

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

[0132] However, if the value derived from CNT 406 is greater than the key counter value stored locally for that secure zone, then the value Petition 870260071805, dated 07 / 20 / 2026, page 159 / 320 The locally stored key counter value 56 / 94 is outdated, as noted above. As a result, the leftmost branch of process flow 750 corresponds to a conditional local key renewal process (i.e., at the receiving node). That is, the receiving node can update its locally stored key counter value in this case only when the key counter value represented in CNT 406 is deemed valid through an additional message verification process.

[0133] For example, after the receiving node determines (block 758, Y) that the locally stored key counter value is outdated, process flow 750 comprises generating (block 760) a temporary session key. To do this, the receiving node uses the full-length key counter value that was used by the transmitting node to generate the protected message that was received. Thus, if CNT 406 represents a truncated portion of the full-length key counter value used by the transmitting node to generate the protected message, the receiving node can derive the full length of the key counter value through a computational process. For example, the receiving node (e.g., processing circuitry 208).2) can concatenate the untruncated portion (e.g., the upper significant bits) of the locally stored key counter value with the remaining truncated portion of the total length of the key counter value (e.g., the lower significant bits) represented by CNT 406.

[0134] Since the total length of the key counter value is derived from CNT 406, the process of generating (block 760) the temporary session key is identical to that used to generate the locally stored session key, by both the receiving and transmitting nodes. Thus, the receiving node uses the same KDF and other entries that were (or should have been) used by the transmitting node to generate the temporary session key. Specifically, the entire key counter value is used as one of the entries for the KDF, along with the key. Petition 870260071805, dated 07 / 20 / 2026, page 160 / 320 57 / 94 shared local data stored on the receiving node that corresponds to the current secure zone.

[0135] Thus, the total length of the key counter value computed in this way can be validated using the temporary session key to decrypt the protected message payload, compute the ICV value, and then compare the computed ICV value with the ICV 412 contained in the protected message. Thus, the ICVs will only match (block 762, Y) when the key counter value used to generate the protected message is valid. Otherwise (block 762, N), process flow 750 consists of the rejection (block 756) of the protected message by the receiving node.

[0136] Therefore, when the ICVs match, the receiving node stores (block 764) an updated key counter value in NVM 204, overwriting the current key counter value, so that the locally stored key counter value now matches the full valid length of the key counter value derived from CNT 406. Again, this key counter value was used by the transmitting node to generate the session key and, in turn, used to generate the current protected message. For example, if the receiving node previously stored key counter A.1, as shown in Figure 2A, after this process, both the receiving node and the transmitting node will store key counter A.1+1.

[0137] In addition, process flow 750 comprises storing (block 766) the temporary session key that was generated (block 760) from the full-length key counter value derived from CNT 406, as described above, as the updated local session key of the receiving node. For example, if the receiving node previously stored session key A.1, as shown in Figure 2A, then after this process, the receiving node and the transmitting node would store session key A.2, which is generated using the key counter A.1+1, as shown in Figure 2A. Petition 870260071805, dated 07 / 20 / 2026, page 161 / 320 58 / 94 shown in Figure 2B.

[0138] Process flow 750 further comprises updating (block 768) the local novelty value to match that received in the protected message. For example, if the receiving node previously stored the novelty value FV.A, as shown in Figure 2A, then after this process, the receiving node and the transmitting node would store the novelty value FV.A+1. In addition, the receiving node can update the received FV register 206.1, as shown in Figure 2C, to store the FV of the protected message A.2 correlated with the key counter value and the secure zone, as noted above.

[0139] Process flow 750 also includes accepting the protected message as the final step of the process, once the key counter value has been validated and the novelty value has been updated as a result of the local key renewal process.

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

[0141] Otherwise, the process flow continues to determine (block 772) whether the novelty value contained in the protected message is greater than the novelty value stored locally for the transmitting node and the secure zone, for example, as shown in the FV log in Figure 2C. If this is the case, the Petition 870260071805, dated 07 / 20 / 2026, page 162 / 320 59 / 94 The receiving node rejects the protected message. If not, the process flow includes updating (block 768) the locally stored FV with the FV contained in the protected message, as discussed above, and accepting (block 776) the protected message. Process flow 750 can therefore be repeated for each protected message received through a receiving node, with process flow 750 being applied to each subsequent protected message received. II. Secure Communications Leveraging Active Member Groups

[0142] Again, replay attacks can include strong and weak types. As discussed in Section I above, strong replay attacks can include a node that legitimately receives a message once (i.e., accepting a validated protected message) and then accepts another maliciously generated protected message at a later time from an attacker. These strong replay attacks can, for example, allow an attacker to store a previously sent “disable immobilizer” protected message and then send that same message later. The use of the real-time bus key distribution system described in Section I aims to eliminate, or at least significantly reduce, the possibility of such strong replay attacks.

[0143] However, this Section provides additional methods that can be used in addition to and / or in combination with those described above in Section I as an additional security measure against weak replay attacks. Weak replay attacks are associated with techniques that aim to disconnect or force a node offline for a period of time to exploit the lack of this knowledge by other nodes. For example, a weak replay attack can be carried out by partitioning the bus in a system used for protected communications. As a result, a target node fails to receive the protected message originally transmitted from other nodes and instead receives the Petition 870260071805, dated 07 / 20 / 2026, page 163 / 320 60 / 94 message subsequently protected, when it comes back online at a time useful to an attacker. For example, in a real-time control system used in an automotive environment, a node might not receive a protected message transmitted to “unlock door” and instead receive that same message when an attacker forwards it to unlock the door while driving.

[0144] Weak replay attacks present specific security problems regarding a disconnected node that has been restarted. For example, and as described above in relation to Figure 7B, upon coming back online after a restart, a receiving node will accept protected messages from other nodes with a key counter value higher than the key counter value stored locally on the receiving node. This allows an attacker to initiate a weak replay attack by partitioning the network, restarting a node, and then replaying the old protected traffic from other nodes. The modalities described in this Section address this problem through the use of active member groups. Specifically, the modalities described in this Section augment the real-time bus key distribution system described in Section I to discover which nodes are currently online, i.e., “active”.A reboot node can therefore refuse to accept protected messages from non-members or from members of the same group who have not verified their online status, even if a protected message had been accepted, for example, with process flow 750 described in Section I above with respect to Figure 7B.

[0145] The member groups, as discussed herein, may comprise any suitable number of nodes within the interconnected node system, as described above in Section I. This may include, for example, the entirety of the 300 interconnected node system, as shown and discussed above with respect to Figure 3. Alternatively, the member groups may comprise a smaller subset of the 300 interconnected node system. Thus, the node system Petition 870260071805, dated 07 / 20 / 2026, page 164 / 320 The 61 / 94 interconnected 300 system can comprise any suitable number of member groups, each having any suitable number of nodes as part of its respective member group. Member groups can comprise nodes that overlap with other member groups, such as the safe zones discussed above. Thus, member groups can be defined according to any suitable grouping of nodes, which may be the same as or different from the safe zones discussed in this document. When member groups are different from safe zones, member groups and safe zones can simultaneously be part of the 300 interconnected node system. In any case, the member groups discussed in this document can be predetermined in relation to the 300 interconnected node system, and therefore each 200 node described in this document can be configured to operate using this information, which will be discussed further below. A. Protected message format for active members

[0146] Figure 8 illustrates examples of protected message formats used to request and respond to online status check requests, according to one or more embodiments of the present description. The protected message formats shown in Figure 8 may correspond to protected messages that are transmitted and received according to any suitable communication protocol, and may constitute communication protocol frames comprising any suitable number of fields. The 800, 850 communication protocol frames may comprise several fields that are also included in the 400, 450 communication protocol frames, as shown and discussed above in relation to Figures 4A and 4B.Thus, and as noted above in Section I, the 800 and 850 communication protocol frames can also be identified with any suitable type of communication protocol that can be implemented to facilitate the communication of messages protected by means of... Petition 870260071805, dated 07 / 20 / 2026, page 165 / 320 62 / 94 is a multipoint or point-to-point bus architecture.

[0147] The 800 communication protocol frame may, for example, correspond to a communication frame identified with a protected message that is initially transmitted by node 200 when acting as a transmitting node. Thus, to support the use of active members, as discussed in accordance with the modalities provided in this Section, the processing circuit set 208.2 is configured to generate the 800 communication protocol frame, which is transmitted by the communication circuit set 208.1, as noted in Section I above. In the context of member groups, as discussed in this section, a node that requests online verification from other nodes may alternatively be referred to as a “challenger” node, and an online verification request may alternatively be referred to as a “challenge request” or simply as a “challenge”.Furthermore, any node that receives a protected message containing a request for online verification from other nodes and then responds to that request can alternatively be referred to as a "responder" node. It should also be noted that, although the concepts of challenger and respondent nodes are separated here for brevity and ease of explanation, a node can simultaneously function as both a challenger and a respondent node. The interaction between challenger and respondent nodes, as well as their roles, are discussed further below.

[0148] Note that the modalities described in this Section exploit the use of typical traffic that occurs with the system of interconnected nodes. That is, the modalities described in this Section may implement the use of additional information that is encoded and added to the protected messages, as discussed in Section I above, both to request online verification from other nodes and to respond to such requests. Thus, online verification requests (i.e., challenges), as well as responses to such requests, may occur through Petition 870260071805, dated 07 / 20 / 2026, page 166 / 320 63 / 94 of the common transmission of protected messages between nodes. This advantageously allows the online state of the nodes to be verified without the use of specialized messages, so that challenges and their respective responses do not overload the communication bandwidth.

[0149] For this purpose, the 800 communication protocol frame includes an 802 RSVP field, as shown, which comprises a representation of a query value. The query value can therefore be represented as any suitable encoded value indicating whether a node is requesting an online status check from other nodes within a member group. Note that the query value can be encoded by any node in the member group indiscriminately, i.e., a challenge request using the query value can leverage a protected message that is transmitted to multiple interconnected nodes, for example, via the multipoint scheme as discussed herein.

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

[0151] To provide an illustrative example, the query value may comprise any suitable encoded value that uniquely identifies the node. Petition 870260071805, dated 07 / 20 / 2026, page 167 / 320 64 / 94 transmitter that is requesting an online verification request from other nodes. This unique identification value can comprise any suitable value that is known by the other nodes in the member group through an initial configuration and installation process. For example, if node 200 is identified as node 5, the query value can represent a hardcoded representation of '5' when node 200 is requesting an online verification request from other nodes, and otherwise it can be set to '0'.

[0152] To provide another illustrative example, the RSVP 802 field may contain a one-bit binary value that is set to one value (e.g., 1) when a challenging node is requesting online verification from other nodes, and otherwise set to a different value (e.g., 0). Thus, the query value need not identify the challenging node, but may simply identify that the challenging node is making an online verification request from other nodes. In this case, each responding node can determine the identity of node 200 from which the protected message was received 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 that are populated by node 200 when transmitting each protected message according to the specific communication protocol that is used.

[0153] Thus, it is also observed that, although the 800, 850 communication protocol frames are shown in Figure 8 using a dedicated RSVP field 802 to provide the query value representation, this is by way of example and not a limitation. In other embodiments, the query value representation may be contained in an alternative field of the 800, 850 communication protocol frames, so that the dedicated RSVP field 802 is not necessary. For example, the query value representation may be contained in Petition 870260071805, dated 07 / 20 / 2026, page 168 / 320 65 / 94 part of header 452 or part of payload 410.

[0154] The 800, 850 communication protocol frames also include an 804 response (RESP) field, which is populated by a responding node in a subsequently transmitted protected message. The 804 RESP field may include encoded data representing any suitable indication of whether a node in the member group has responded affirmatively to an online status check request transmitted by other challenging nodes. As noted above for the 802 RSVP field, the encoded data contained in the 804 RESP field, as shown in Figure 8, may be contained in an alternative field of the 800, 850 communication protocol frames, so that the dedicated 804 RESP field is not required. For example, the encoded data contained in the 804 RESP field may be contained in part of the 452 header or be part of the 410 payload.

[0155] The RESP 804 field may include, for example, any suitable type of mapping that uniquely identifies each node in the member group. For example, and with reference to Figure 8, a member group may comprise 16 nodes within the 300 interconnected node system. Each of these 16 nodes may be uniquely identified in any suitable manner known to the other nodes, as noted above. The RESP 804 field may therefore comprise a bit sequence (e.g., a bit array), with the position of each bit in the bit sequence corresponding to each respective node in the member group. In other words, each bit in the bit sequence is identified with a different node in the member group by means of a respective predetermined bit position within the bit sequence.For the example 850 communication protocol frame, as shown in Figure 8, the rightmost bit position corresponds to node 0, and the leftmost bit corresponds to node 15.

[0156] Thus, each bit position in the RESP 804 field corresponds to a Petition 870260071805, dated 07 / 20 / 2026, pp. 169 / 320 The 66 / 94 value indicates whether each respective node responded affirmatively to an online status check request from one or more other nodes in the member group. The predetermined bit position of the RESP field therefore corresponds to each of the nodes that requested the online status check. Thus, each node in the member group that receives an online status request from other nodes can set the bit value for the bit position associated with each respective requesting 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 a value set by each node in response to a challenge request from any other node in the member group. Therefore, and with continued reference to Figure 8, the communication protocol frame 850 indicates that nodes 5, 10, and 14 requested online status checks from each node in the member group.

[0157] To populate the RESP 804 field, each node in the member group can maintain a record of online verification requests received from other nodes. For example, node 200 might include an online verification request record 207 as part of volatile memory 206, as shown in Figure 2A, or alternatively as part of non-volatile memory 204 (not shown). Thus, each responding node can store in the online verification request record 207 a bit sequence or other suitable set of encoded values ​​that corresponds to the RESP 804 field. For example, the online verification request record 207 might store a bit sequence identical to the RESP 804 field, with each bit position in the locally stored bit sequence corresponding to an indication of whether each node in the member group requested an online verification.Again, this is determined by the representation of the query value contained in the protected message transmitted by each node (for example, through the RSVP 802 field).

[0158] Again, and using the convention shown in the example in Figure 8, Petition 870260071805, dated 07 / 20 / 2026, page 170 / 320 67 / 94 assumes that a node has received an online verification request via protected messages received from each of the identified nodes 5, 10, and 14. These protected messages may be received over a period of time, and therefore the processing circuit set 208.1 may update the contents of the locally stored online verification request log 207 as each protected message is received. The number of protected messages that may be received in this way until the next scheduled protected message is generated with the RESP 804 field filled may be any limit number of protected messages based on the configuration, available bandwidth, number of nodes in the member group, etc.In any case, for each protected message received that has a query value representation indicating that a challenge request has been made (for example, via the RSVP field 802), the processing circuit set 208.1 accumulates the contents of the locally stored online verification request log 207 to represent each of these pending requests.

[0159] Therefore, before a node populates the RESP 804 field in response to these online verification requests, the local bit sequence stored in the online verification request register 207 may contain the same content as the RESP 804 field, as shown in Figure 8. As a result, when a node in the member group transmits the protected message to respond to pending challenges, the node copies (e.g., via the processing circuitry 208.2) the content of the online verification request register 207 to the RESP 804 field, as shown in Figure 8. Furthermore, once the protected message is transmitted with this RESP 804 field populated, the responding node is configured (e.g., via the processing circuitry 208.2) to reset the content of its locally stored online verification request register 207 to a predetermined initial state. Petition 870260071805, dated 07 / 20 / 2026, page 171 / 320 68 / 94 This predetermined state can include one that indicates there are no pending online verification requests from other nodes. For example, the locally stored online verification request log 207 can be reset to store a bit sequence consisting only of zeros. Therefore, and continuing with the present example, when there are no pending challenge requests for online state verification, each node in the member group can transmit its respective RESP field containing all zeros, i.e., the current content of the locally stored online verification request log 207.

[0160] Again, each node in the member group can operate in the same manner as node 200, as described above in relation to Figure 2A. To provide an illustrative example in relation to the 850 communication protocol frame, node 200 can receive several protected messages over time. From these protected messages, challenge requests are received for online verification from nodes 5, 10, and 14 via their respective protected messages. Thus, node 200 can receive the protected messages in any suitable manner (e.g., via a bus such as the multipoint bus described above) through the 208.1 communication circuit set, with the protected messages then being processed, as discussed in detail later, through the 208.1 processing circuit set to accept or reject the protected messages.

[0161] Thus, although a single responding node may be used as an example throughout this Section for ease of explanation, it is noted that each node that receives a challenge message may respond individually to such requests. Although termed a “responder,” it is understood in this context that each responding node does not need to transmit a dedicated protected message in response to such requests. Instead, each responding node may fill in its Petition 870260071805, dated 07 / 20 / 2026, page 172 / 320 69 / 94 own field RESP 804 as part of the next scheduled protected message to be transmitted. Again, to provide the content of field RESP 804, each node can modify the content of its locally stored online verification request log 207 (e.g., via the processing circuitry 208.2) as additional protected messages are received. Thus, the content of online verification request log 207 at any given time indicates which nodes have requested an online verification request that is currently pending (i.e., awaiting a response by populating field RESP 804 in a transmitted protected message).

[0162] Thus, and continuing with the present example, each responding node can populate the RESP 804 field when generating the next scheduled protected message, which is transmitted and received by each of the nodes in the member group, including nodes 5, 10, and 14. In this way, the protected message itself is not generated in response to receiving online verification requests via multiple protected messages. Instead, the RESP 804 field is populated as part of the generation of the next scheduled protected message to be transmitted in response to receiving online verification requests from one or more challenging nodes. In this way, a responding node can simultaneously respond to a challenge request from any number of nodes (e.g., all nodes) in the member group from which an online verification request was received via a single transmitted protected message.By using the existing protected message scheduling architecture and not requiring dedicated messages to be sent in this way, the speed at which nodes can respond to online verification requests is significantly faster (e.g., a few hundred microseconds, such as 100, 200, 300 microseconds, etc.), particularly for hardware configurations such as those discussed above in Section I. Further leveraging this advantage, for the... Petition 870260071805, dated 07 / 20 / 2026, page 173 / 320 70 / 94 active member modes described in this Section, all responding nodes can respond to a challenge within a maximum of their shortest period frame time plus their latency (typically < 20 ms). 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.

[0163] Since each responding node only responds to an online verification request via the RESP 804 field if it is online, the RESP 804 field in each protected message received by a challenging node allows the latter to infer (i.e., determine) the online state of each responding node within the member group. To illustrate, if protected messages containing the RESP 804 field are lost, the requesting node (i.e., the node that issued the challenge request) will need to request online status verification again to confirm an offline state. In the CAN XL protocol, messages are not lost by default (i.e., the protocol itself will retransmit messages corrupted by noise). For an Ethernet-based system, a requester can infer that a node is offline if a threshold number of challenge requests (e.g., two, three, etc.) are not answered.

[0164] However, in addition to inferring that a node is online, as noted above, a node that requests online verification from other nodes can implement an additional check based on the content of the RESP 804 field. For example, once a protected message is transmitted, including the content of the RESP 804 field, each node in the member group receives the protected message, which includes nodes that requested an online verification request as well as nodes that did not request it. Thus, each node that requested the online verification request (e.g., nodes 5, 10, and 14, using the example above) can then determine whether each node in the member group responded affirmatively to Petition 870260071805, dated 07 / 20 / 2026, page 174 / 320 71 / 94 these requests through the content of the RESP 804 field filled in by each responding node.

[0165] To illustrate, the 208.1 communication circuit set of node 200 is configured to receive protected messages from each node in the member group that has the RESP 804 field populated based on previous online status check requests. The receiving node (formerly a challenger node) can then determine whether each node in the member group that responded to a previous check request is online, based on the contents of the RESP 804 field. For example, and continuing the example above, node 5 can compare the contents of the bit at node 5's position with a predetermined value (e.g., the value of bit 1) to determine whether a responding node in the member group correctly identified its online status in response to the request.Continuing with this example, if, after transmitting a protected message requesting online verification, a member group node responds with a protected message including a '1' in this bit position in the RESP 804 field, then node 5 will determine that this node is online and active. Otherwise, node 5 would determine that the responding node is not online and is malfunctioning, or that the message is being sent by a non-authentic source, such as an attacker attempting a weak replay attack. Alternatively, node 5 may determine that the protected message with the challenge request was lost / corrupted, or that the protected message with the responding node's reply was lost / corrupted (however, with CAN XL, as noted above, this generally does not occur).

[0166] The comparison of the contents of the RESP 804 field can be carried out in any suitable manner, which may include a software-based implementation by means of the processing circuitry 208.2 (or other suitable processor(s)) executing instructions in program memory 208.3 (or other suitable memory). However, given the example of the encoding format Petition 870260071805, dated 07 / 20 / 2026, page 175 / 320 Given the single-bit 72 / 94 field of RESP 804, it can be particularly advantageous to compare the contents of the RESP 804 field using a hardware-based solution, such as logic gates, for example, and / or any other hardware suitable for determining an online status indication of the responding nodes. Such hardware can, for example, be implemented as part of the 208.1 communication circuit suite, the 208.2 processing circuit suite, etc.

[0167] It is further observed that each node in the member group can function in this manner, i.e., sending online verification requests to other nodes by means of the query value representation, responding to these requests using the RESP 804 field, and verifying whether each node is online based on the content of the RESP 804 field. For example, each challenging node in the member group can determine whether other nodes within the member group are online. This is facilitated by the challenging node (e.g., by means of the 208.2 processing circuitry) which determines, for each protected message received, whether a bit in the bit sequence corresponds to the predetermined bit position for the challenging node. The challenging node thus verifies whether a responding node is online, based on whether the value of this predetermined bit position correctly indicates that the challenging node previously requested the online status check.Thus, the encoded value of the predetermined bit position for the challenging node can represent a value (for example, '1') that indicates an affirmative response from each responding node to the prior online state verification request.

[0168] In any case, each node in the member group can accept or reject a protected message based on the response to a previously transmitted online status check request. Again, such a response may comprise the populated content of the RESP 804 field. Thus, the decision to accept a protected message may be based on the inferred online status of a node that transmitted a protected message with the populated content in response. Petition 870260071805, dated 07 / 20 / 2026, page 176 / 320 73 / 94 to an online status check request, as noted above. Alternatively, the decision to accept a protected message may be based on the online status of a node, which is determined by the content of a specific bit or other suitable mapping in the RESP 804 field indicating that the challenging node has previously sent an online status check request. In this way, each node in the member group can determine whether or not to accept protected messages based on whether each respective responding node is online. This conditional acceptance of protected messages in this manner is discussed in more detail below in relation to Figure 9B.

[0169] Regardless of how the online state of other nodes is determined, the modalities include node 200 maintaining a record of the online state of other nodes in the member group in any suitable manner. For example, each node in the member group may maintain an online state record with respect to other nodes in the member group. To this end, node 200 may comprise an online state record 209 as part of volatile memory 206, as shown in Figure 2A, or alternatively as part of non-volatile memory 204 (not shown). Thus, each node in the member group may store in the online state record 209 a sequence of bits or other suitable set of values ​​that are mapped to the current online state of each node in the member group at a given time.For example, the online status record 209 might store a bit sequence similar to the online verification request record 207, with each bit position in the locally stored bit sequence corresponding to an indication of whether each node in the member group is currently online (e.g., a '1') or offline (e.g., a '0').

[0170] In one embodiment, each node in the member group is configured (for example, by means of the 208.2 processing circuitry) to determine the current online state of each node in the member group based on any number Petition 870260071805, dated 07 / 20 / 2026, page 177 / 320 74 / 94 appropriate protected messages received. For example, as each protected message is received from each of the responding nodes, an online state determination can be made based on each protected message received. This determination may include, for example, an accumulation of bit values ​​received from each responding node that corresponds to the content of the RESP field. To illustrate, node 5 can transmit a protected message requesting online verification from each node in the member group via the content of the RSVP field 802. Each of the other 15 nodes in the member group can then transmit protected messages containing the content of the RESP field 804, which includes bit 5 in the RESP field, as shown in Figure 8 (and possibly additional bits), set to the value '1', which represents an affirmative response to node 5's online challenge request.As each of these protected messages is received from the other nodes, node 5 can therefore accumulate bit values ​​from the same predetermined bit position in the RESP 804 field corresponding to node 5 in each protected message. As bit values ​​are accumulated in this way, they are mapped to a predetermined bit position corresponding to each node in online status record 209. Thus, as each of the other 15 nodes is determined to be online, online status record 209 contains a bit value equal to '1' at a predetermined bit location corresponding to each of the other 15 nodes. In this way, the node's content in online status record 209 corresponds to an accumulation of bit values ​​from the RESP 804 field in a series of received protected messages.

[0171] In addition, the modalities include the value of each bit in the online status register 209 being reset to a predetermined value in response to the fulfillment of any suitable conditions. For example, the bit values ​​of the online status register 209 may be reset periodically or when a number of rejected protected messages exceeds a threshold. To provide Petition 870260071805, dated 07 / 20 / 2026, page 178 / 320 75 / 94 Another example, the bit values ​​of the online status register 209 can be reset after a timeout period has elapsed since the bit value of one or more nodes was updated. In this way, the online state of each node in the member group can be maintained through the contents of the online status register 209. Once the bit value of the online status register 209 is reset in this way, a node in the member group can then make another online verification request from nodes in the member group via another transmitted protected message, filling in the RSVP 802 field, as noted above. To provide an illustrative example, a node can issue another online verification challenge request during the reset period, so that there is a continuous “online” state that is being updated periodically.In this way, the online state can be used to accept / reject messages to avoid a gap in the state resulting in the loss of protected messages.

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

[0173] This can be particularly useful, for example, as a diagnostic tool. For example, if no node responds to a challenge, a node performing the challenge can determine that no other node in the member group is currently online and / or that the protected message transmitted with the challenge is Petition 870260071805, dated 07 / 20 / 2026, page 179 / 320 76 / 94 was lost. Furthermore, if a specific node in the member group does not respond due to the absence of an affirmative response in the RESP 804 field, it can be determined that the node is offline or that its response was lost. Additionally, if traffic from nodes identified as offline is still observed, it is likely that these nodes are being spoofed using repeated traffic.

[0174] Again, the use of active member modes, as discussed in this Section, can implement any of the communication protocols mentioned above in Section I. However, active member modes, as discussed in this Section, can provide specific advantages when used in accordance with Ethernet or Ethernet-based protocols. This is because CAN XL provides atomicity, and therefore, if a frame is marked as sent, all online nodes have successfully received it. Atomicity, therefore, greatly facilitates the detection of offline nodes, as challenges are not lost. However, it is observed that Ethernet protocols do not provide atomicity in this respect, and therefore, frames are routinely dropped. As a result, management algorithms need to deal with lost frames, which are typically retransmitted.The active member modes described in this Section advantageously enable Ethernet implementations that eliminate or reduce the complexity of such management algorithms by checking the online status of other nodes in a member group and maintaining a status log of this information. B. Active member process flows

[0175] Figures 9A-9B illustrate the process flows used by the nodes to transmit and receive protected messages, according to one or more embodiments of the present invention. With reference to Figures 9A-9B, the process flows may comprise methods performed by and / or associated with any suitable number and / or type of components, such as one or more processors (set of Petition 870260071805, dated 07 / 20 / 2026, pages 180 / 320 77 / 94 processing circuits), hardware components, executed instructions (e.g., software components), or combinations thereof. Components may be associated with one or more Node 200 components, as discussed in this document, and may represent software-based implementations, hardware-based implementations, or combinations thereof.

[0176] Specifically, Figure 9A provides further details on the process implemented by a node to generate and transmit a protected message. Figure 9B provides further details on the process implemented by a node to accept or reject a received protected message and, where applicable, to respond to challenge requests. It is observed that process flow 900 can be identified with the transmission of a protected message through a challenging node or a responding node, or alternatively, a node can function simultaneously as a challenging node and a responding node.

[0177] Furthermore, process flow 950 can be identified with the receipt and, optionally, the transmission of a protected message by a challenger node or a respondent node. Again, in both cases, a node can simultaneously function as a challenger node and a respondent node. For example, a challenger node may subsequently receive a protected message from a respondent node, so that process flow 950 refers to the receipt of a protected message from a node responding to the previous challenge request. Thus, flows 900, 950 may include alternative or additional blocks that are not shown in Figures 9A and 9B for brevity, and may be executed in a different order than shown. In addition, some blocks may be optional, depending on the specific function of a node at a given time.

[0178] Referring first to Figure 9A, process flow 900 can be implemented through any of the nodes discussed here, such as any Petition 870260071805, dated 07 / 20 / 2026, pp. 181 / 320 78 / 94 one of the nodes included in system 300, for example, when performing a protected message transmission. This may include, for example, node 200, as discussed here in relation to Figure 2A. Process flow 900 may include several blocks that are executed in the same way as process flow 700, as discussed above in Section I in relation to Figure 7A. For brevity, these common blocks are represented by subflow block 700.1, as shown in Figures 7A and 9A. Thus, process flow 900 illustrates that a node may transmit (block 902) a protected message using a process that is part of subflow 700.1. Furthermore, blocks 902, 914, and 916 are considered analogous blocks in relation to blocks 702, 714, and 716, respectively. Therefore, the functionality of blocks 902, 914, and 916 may be the same or substantially similar to that described previously in relation to blocks 702, 714, and 716, respectively.For the sake of brevity, only the differences between these functional blocks will be discussed in detail.

[0179] As shown in Figure 9A, both arrows emanating from subflow 700.1, as shown in Figure 7A, are merged into a single arrow for ease of explanation. Thus, the protected message is still generated (block 914) for process flow 900 based on the same conditions as subflow 700.1, as shown in Figure 7A. However, process flow 900 includes additional blocks 914.1 and 914.2, which are identified with the generation (block 914) of the protected message.

[0180] For example, the generation (block 914) of the protected message, as shown in Figure 9A, comprises the generation (block 914.1) of a representation of a query value. As discussed above, this can comprise any suitable query value that indicates whether the node is requesting an online verification request from other nodes in the member group. For example, the representation of a query value can comprise a binary value or a Petition 870260071805, dated 07 / 20 / 2026, page 182 / 320 79 / 94 encoded value that identifies the node, which may be part of the RSVP 802 field, as discussed above.

[0181] The generation (block 914) of the protected message, as shown in Figure 9A, also comprises the generation (block 914.2) of one or more encoded values ​​that indicate (when defined) responses to current requests (i.e., challenges) for online verification from any other nodes in the membership group. Thus, although not shown in Figure 9A for ease of explanation, the node may, before transmitting (block 902) the protected message with its own challenge requests, have received protected messages from other nodes challenging the node with their own challenge requests. Again, and as discussed above, the encoded values ​​provided in the protected message may comprise any suitable values ​​defined by the (currently transmitting) node that represent an affirmative response to each pending challenge request received from other nodes in the membership group. For example, the generation (block 914.2) One or more encoded values ​​may comprise the filling of the RESP 804 field in response to these online verification requests, as discussed above. The RESP 804 field may be filled, for example, by the node copying the contents of the local online verification request record 207 to the RESP 804 field, as noted in this document.

[0182] Once the protected message is generated (block 914), it can be queued (block 916) and transmitted (block 902) to the bus, for example, as noted in this document. After the protected message is transmitted (block 902), the node can then reset (block 904) the contents of the local online verification request log 207 to a predetermined state (e.g., all zeros), which will remain in that state until further challenges are received before the transmission (block 902) of the next protected message. However, it is noted that resetting (block 904) the contents of the log Petition 870260071805, dated 07 / 20 / 2026, page 183 / 320 80 / 94 requests for local online verification 207 is optional, as this will not occur if the node is not responding to any pending challenge requests by filling in the RESP 804 field.

[0183] With reference now to Figure 9B, process flow 950 can be implemented through any of the nodes discussed here, such as any of the nodes included in system 300, for example, when receiving a protected message. This could include, for example, node 200, as discussed here in relation to Figure 2A. Process flow 950 can include several blocks that are executed in the same way as process flow 750, as discussed above in Section I in relation to Figure 7B. For brevity, these common blocks are represented by subflow block 750.1, as shown in Figures 7B and 9B. Thus, process flow 950 illustrates that a node can receive (block 952) a protected message using a process that incorporates subflow 750.1. Furthermore, blocks 952, 976, and 956 are considered analogous blocks in relation to blocks 752, 776, and 765, respectively.Therefore, the functionality of blocks 902, 914, and 916 may be the same or substantially similar to that described previously in relation to blocks 752, 776, and 765, respectively. For the sake of brevity, only the differences between these functional blocks are discussed in more detail.

[0184] Subflow 750.1 provides several criteria that define the acceptance of a protected message, as discussed above in relation to Section I. For process flow 950, two paths are shown, with the upper path being identified with a challenging node receiving a response, and the lower path being identified with a responding node receiving a challenge request. Note that both paths can be executed by the same node at the same time, for example, when a node receives other challenge requests and checks the responses to its own challenge requests. Petition 870260071805, dated 07 / 20 / 2026, page 184 / 320 81 / 94

[0185] In any case, process flow 950 modifies the criteria by which a node can accept (block 976) protected messages based on the determination (block 954) of whether a responding node indicates that it is currently online, which may be in response to a request previously issued by a challenging node for online verification. Thus, the determination (block 954) can be performed by hardware or software, as noted above, and can determine, for example, whether a node has responded affirmatively to a previous request by setting a predetermined bit in the response field 804. Thus, if the online status request is not verified (block 954, no), the protected message will be rejected. Otherwise, the protected message will be accepted (block 976). In both cases, process flow 950 may include updating (block 958) the online status register.Again, this may include, for example, the challenging node updating the online status record 209, as discussed in this Section.

[0186] It is also important to note that the determination (block 954) of whether a node is online may include determining a node's online status within an acceptance window, which may correspond to any suitable timeout period. For example, the acceptance (block 976) of protected messages may be conditional upon timely confirmation of the online status (block 954, Yes), even when a given protected message does not contain a response. This determination may be included as part of the online determination, as shown in block 954. As an illustrative example, a challenging node may not transmit protected messages very frequently; therefore, additional protected messages that occur before the sending of a previous challenge request may not include a response to an immediately pending challenge.

[0187] Process flow 950 may additionally or alternatively include, upon acceptance (block 976) of the protected message, a further determination (block 960) as to whether the protected message includes a request for Petition 870260071805, dated 07 / 20 / 2026, pp. 185 / 320 82 / 94 online verification (i.e., a challenge request). This determination (block 960) may include, for example, identifying a representation of a query value contained in the protected message, such as the RSVP field 802, for example, as noted here. Otherwise, process flow 950 follows the same path noted above to update (block 958) the online status record (if necessary), and repeat this process for subsequently received protected messages.

[0188] However, if the protected message includes an online verification request, process flow 950 includes updating (block 962) the online verification request record, as mentioned earlier in relation to online verification request record 207. Process flow 950 can then proceed to block 914, as shown and discussed earlier in relation to process flow 900. In this case, a protected message can be generated, for example, by populating the RESP field 804 with the content of online verification request record 207. Obviously, the protected message generated in this way can also contain a challenge request from other nodes through query value representation, as mentioned here. EXAMPLES

[0189] The techniques of the present invention can also be described in the following examples.

[0190] Example 1. A first node in a system of interconnected nodes configured to communicate via a bus, the first node comprising: a set of processing circuits configured to: derive a temporary session key from a shared secret and a counter value according to a cryptographic function; and generate a protected message using the temporary session key, wherein the protected message includes a first field comprising a representation of the counter value, and a Petition 870260071805, dated 07 / 20 / 2026, page 186 / 320 83 / 94 second field comprising a representation of a query value indicating whether the first node is requesting an online status check from one or more other nodes within the interconnected node system; and a set of communication circuits configured to transmit the protected message to the bus.

[0191] Example 2. The first node of Example 1, where the set of processing circuits is configured to determine whether a second node in the interconnected node system is online based on a protected message received via the bus, the protected message received comprising a response to an online status check sent by the first node via the bus.

[0192] Example 3. The first node of any combination of Examples 1 to 2, where the processing circuitry is configured to accept the received protected message based on the response to the online status check sent via the bus.

[0193] Example 4. The first node of any combination of Examples 1 to 3, where the response to the online status check is represented by a third field contained in the received protected message that indicates the online status of the second node.

[0194] Example 5. The first node of any combination of Examples 1 to 4, where the processing circuitry is configured to store an indication of a given online state of the plurality of nodes based on the received protected message.

[0195] Example 6. The first node of any combination of Examples 1 to 5, wherein the third field comprises a sequence of bits, and wherein the processing circuitry is configured to determine whether the second node is online by determining, for the received protected message, whether a bit in the sequence Petition 870260071805, dated 07 / 20 / 2026, page 187 / 320 An 84 / 94 bit array that has a predetermined bit position identified with the first node indicates that the first node requested the online status check.

[0196] Example 7. The first node of any combination of Examples 1 to 6, wherein the query value representation comprises a one-bit binary value or an encoded value that uniquely identifies the first node.

[0197] Example 8. The first node of any combination of Examples 1 to 7, where the representation of the counter value in the protected message allows one or more other nodes in the interconnected node system to derive the temporary session key.

[0198] Example 9. The first node of any combination of Examples 1 to 8, where the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

[0199] Example 10. The first node of any combination of Examples 1 to 9, wherein the set of communication circuits is configured to transmit the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0200] Example 11. The first node of any combination of Examples 1 to 10, wherein the protected message forms at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol frame, a Control Area Network Extra Long (CAN XL) communication protocol frame, or an Ethernet communication protocol frame.

[0201] Example 12. A first node in a system of interconnected nodes Petition 870260071805, dated 07 / 20 / 2026, pp. 188 / 320 85 / 94 configured to communicate via a bus, the first node comprising: a set of communication circuits configured to receive a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function prior to receiving the protected message, and (ii) a second field containing an encoded value indicating whether a second node responded affirmatively to an online state check request from the first node; and a set of processing circuits configured to: determine the validity of the counter value that is computed from the counter value representation contained in the first field;and accept or reject the protected message based on (i) the determined validity of the counter value, and (ii) a determination, based on the value encoded in the second field, as to whether the second node responded affirmatively to the online state check request.

[0202] Example 13. The first node of Example 12, where: the second field comprises a sequence of bits including a plurality of bits, a predetermined bit position of each of the plurality of bits is identified with a respective node among the system of interconnected nodes, and the value encoded in the second field corresponds to a predetermined bit position identified with the first node.

[0203] Example 14. The first node of any combination of Examples 12 to 13, wherein the previously transmitted protected message includes a third field comprising a representation of a query value indicating whether the first node is requesting an online status check from the second node.

[0204] Example 15. The first node of any combination of Examples 12 to 14, where the query value representation comprises a binary value of Petition 870260071805, dated 07 / 20 / 2026, pp. 189 / 320 86 / 94 is a bit or encoded value that uniquely identifies the first node.

[0205] Example 16. The first node of any combination of Examples 12 to 15, where the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

[0206] Example 17. The first node of any combination of Examples 12 to 16, wherein the set of communication circuits is configured to transmit the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0207] Example 18. The first node of any combination of Examples 12 to 17, wherein the protected message forms at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol frame, a Control Area Network Extra Long (CAN XL) communication protocol frame, or an Ethernet communication protocol frame.

[0208] Example 19. A first node in a system of interconnected nodes configured to communicate via a bus, the first node comprising: a set of communication circuits configured to receive a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function before receiving the protected message, and (ii) a second field comprising a representation Petition 870260071805, dated 07 / 20 / 2026, pages 190 / 320 87 / 94 of a query value indicating a request for online status verification; and a set of processing circuits configured to: determine the validity of the counter value which is computed from the counter value representation contained in the first field; and accept or reject the protected message based on the determined validity of the counter value; and wherein the set of communication circuits is further configured, when the protected message is accepted, to generate a next protected message scheduled for transmission to the bus which includes a third field containing an encoded value indicating an affirmative response to the request for online status verification.

[0209] Example 20. The first node of Example 19, wherein: the third field comprises a bit sequence including a plurality of bits, and wherein each bit in the bit sequence is identified with each respective node of the interconnected node system by means of a respective predetermined bit position within the bit sequence.

[0210] Example 21. The first node of any combination of Examples 19 to 20, wherein the processing circuitry is configured to store a local bit sequence comprising an indication, for each respective bit in the bit sequence, as to whether each node in the system of interconnected nodes has requested an online status check from the first node.

[0211] Example 22. The first node of any combination of Examples 19 to 21, wherein the set of communication circuits is configured to transmit the next scheduled protected message to the bus comprising, as the bit sequence included in the third field, the local bit sequence.

[0212] Example 23. The first node of any combination of Examples 19 to 22, where the processing circuitry is configured to reset the value of each bit in the local bit sequence to a predetermined initial value after the transmission of the next scheduled protected message. Petition 870260071805, dated 07 / 20 / 2026, pp. 191 / 320 88 / 94

[0213] Example 24. The first node of any combination of Examples 19 to 23, wherein the query value representation comprises a one-bit binary value or an encoded value that uniquely identifies the second node.

[0214] Example 25. The first node of any combination of Examples 19 to 24, where the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

[0215] Example 26. The first node of any combination of Examples 19 to 25, wherein the set of communication circuits is configured to transmit the next scheduled protected message according to a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0216] Example 27. The first node of any combination of Examples 19 to 26, wherein the protected message and the next scheduled protected message form at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol frame, an Extra Long Control Area Network (CAN XL) communication protocol frame, or a multipoint Ethernet communication protocol frame.

[0217] Example 28. A node in a system of interconnected nodes that are part of a protected control system and are configured to communicate via a bus, comprising: a set of processing circuits configured to: generate a protected message using a temporary session key, wherein the protected message includes (i) a first field comprising a representation of a query value indicating whether the node is Petition 870260071805, dated 07 / 20 / 2026, pp. 192 / 320 89 / 94 requesting an online status check from other nodes within the interconnected node system, and (ii) a second field indicating whether the node responded affirmatively to an online status check request from any node in the interconnected node system, and storing an indication of the current online status of each node in the interconnected node system; and a set of communication circuits configured to transmit the protected message to the bus.

[0218] Example 29. The node of Example 28, wherein the stored indication of the current online state of each node in the interconnected node system comprises a bit sequence, and wherein the value of each bit in the bit sequence indicates whether each node in the interconnected node system is currently online.

[0219] Example 30. The node of any combination of Examples 28 to 29, wherein the set of processing circuits is configured to determine the current online state of each node in the system of interconnected nodes based on an accumulation of bit values ​​from a plurality of received protected messages.

[0220] Example 31. The node of any combination of Examples 28 to 30, wherein the bit value of each bit in the bit sequence is reset to a predetermined value after a timeout period expires.

[0221] Example 32. The node of any combination of Examples 28 to 31, wherein the set of communication circuits is configured to transmit the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0222] Example 33. A method for transmitting a protected message via a node in a system of interconnected nodes configured to communicate via a bus, the method comprising: deriving a session key Petition 870260071805, dated 07 / 20 / 2026, pp. 193 / 320 Temporary 90 / 94 session key derived from a shared secret and a counter value according to a cryptographic function; generate a protected message using the temporary session key, wherein the protected message includes a first field comprising a representation of the counter value and a second field comprising a representation of a query value indicating whether the node is requesting an online state check from one or more other nodes within the interconnected node system; and transmit the protected message to the bus.

[0223] Example 34. The method of Example 33, in which transmitting the protected message comprises: transmitting the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, a Control Area Network Extra Long (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0224] Example 35. A method for receiving a protected message through a first node in a system of interconnected nodes configured to communicate via a bus, the method comprising: receiving a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function prior to receiving the protected message, and (ii) a second field containing an encoded value indicating whether a second node responded affirmatively to an online state check request from the first node; determining the validity of the counter value that is computed from the counter value representation contained in the first field; and accepting or rejecting the protected message based on (i) validity Petition 870260071805, dated 07 / 20 / 2026, pp. 194 / 320 91 / 94 determined from the counter value, and (ii) in a determination, based on the value encoded in the second field, as to whether the second node responded affirmatively to the online status check request.

[0225] Example 36. The method of Example 35, wherein receiving the protected message comprises: receiving the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, a Control Area Network Extra Long (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0226] Example 37. A method for communication through a first node in a system of interconnected nodes configured to communicate through a bus, the method comprising: receiving a protected message through the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function before receiving the protected message, and (ii) a second field comprising a representation of a query value indicating a request for online state verification, determining the validity of the counter value that is computed from the counter value representation contained in the first field; accepting or rejecting the protected message based on the determined validity of the counter value;And when the first protected message is accepted, generate a subsequent protected message scheduled for transmission to the bus that includes a third field containing an encoded value indicating an affirmative response to the online status check request.

[0227] Example 38. The method of Example 37, in which receiving the first protected message comprises: receiving the protected message according to a Petition 870260071805, dated 07 / 20 / 2026, pp. 195 / 320 92 / 94 communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol; and wherein transmitting the second protected message comprises: transmitting the next scheduled protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

[0228] Example 39. A method for communication via a node in a system of interconnected nodes that are part of a protected control system and are configured to communicate via a bus, the method comprising: generating a protected message using a temporary session key, wherein the protected message includes (i) a first field comprising a representation of a query value indicating whether the node is requesting an online status check from other nodes within the system of interconnected nodes, and (ii) a second field indicating whether the node has responded affirmatively to a request for an online status check from any node within the system of interconnected nodes, storing an indication of the current online status of each node in the system of interconnected nodes; and transmitting the protected message to the bus.

[0229] Example 40. The method of Example 39, wherein transmitting the protected message comprises: transmitting the protected message in accordance with a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network - Flexible Data Rate (CAN FD) communication protocol, a Control Area Network communication protocol Petition 870260071805, dated 07 / 20 / 2026, pp. 196 / 320 93 / 94 Extra Long Control Area (CAN XL) or a multipoint Ethernet communication protocol. CONCLUSION

[0230] Although specific embodiments have been illustrated and described herein, it should be noted that any arrangement calculated to achieve the same objective may be substituted for the specific embodiments shown. The present invention is intended to encompass any and all adaptations or variations of 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.

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

[0232] It should also be noted that the methods described in the descriptive report or in the claims can be implemented by a device having means to perform each of the respective steps of those methods.

[0233] Although specific modalities have been illustrated and described Petition 870260071805, dated 07 / 20 / 2026, pp. 197 / 320 94 / 94 in this document, it will be understood by those skilled in the art that a variety of alternative and / or equivalent embodiments may be substituted for the specific embodiments shown and described, without departing from the scope of the present invention. This description is intended to cover any adaptations or variations of the specific embodiments discussed in this document. Petition 870260071805, dated 07 / 20 / 2026, pp. 198 / 320

Claims

1 / 12 CLAIMS 1. First node in a system of interconnected nodes configured to communicate via a bus, the first node CHARACTERIZED in that it comprises: a set of processing circuits (208.2) configured to: derive a temporary session key from a shared secret and a counter value according to a cryptographic function; generate a protected message using the temporary session key, wherein the protected message includes a first field comprising a representation of the counter value, and a second field comprising a representation of a query value indicating whether the first node is requesting an online state check from one or more other nodes within the interconnected node system; and determine whether a second node in the interconnected node system is online based on a received protected message that is received via the bus, the received protected message comprising a response to an online state check sent via the bus by the first node; and set of communication circuits (208.1) Configured to transmit the protected message to the bus, where the response to the online status check is represented by a third field contained in the received protected message that indicates an online status of the second node.

2. First node, according to claim 1, CHARACTERIZED in that the processing circuitry (208.2) is configured to accept the received protected message based on the response to the online status check sent via the bus.

3. First node, according to claim 1, CHARACTERIZED by the fact Petition 870260071805, dated 07 / 20 / 2026, page 199 / 320 2 / 12 that the processing circuitry (208.2) is configured to store an indication of a given online state of the second node based on the protected message received.

4. First node, according to claim 1, CHARACTERIZED in that the third field comprises a bit sequence, and in that the processing circuitry (208.2) is configured to determine whether the second node is online by determining, for the received protected message, whether a bit in the bit sequence that has a predetermined bit position identified with the first node indicates that the first node has requested online status verification.

5. First node, according to claim 1, CHARACTERIZED in that the query value representation comprises a one-bit binary value or an encoded value that uniquely identifies the first node.

6. First node, according to claim 1, CHARACTERIZED in that the representation of the counter value in the protected message allows one or more other nodes in the interconnected node system to derive the temporary session key.

7. First node, according to claim 1, CHARACTERIZED in that the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

8. First node, according to claim 1, CHARACTERIZED in that the set of communication circuits (208.1) is configured to transmit the protected message according to a communication protocol comprising one of a Control Area Network, CAN, Control Area Network with Flexible Data Rate, CAN FD, Control Area Network with Extra Long, CAN XL, or a multipoint Ethernet communication protocol. Petition 870260071805, dated 07 / 20 / 2026, p. 200 / 320 3 / 12 9. First node, according to claim 1, CHARACTERIZED in that the protected message forms at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol frame, an Extra Long Control Area Network (CAN XL) communication protocol frame, or an Ethernet communication protocol frame.

10. First node in a system of interconnected nodes configured to communicate via a bus, the first node CHARACTERIZED in that it comprises: a set of communication circuits (208.1) configured to receive a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function prior to receiving the protected message, and (ii) a second field containing an encoded value indicating whether a second node responded affirmatively to an online state check request from the first node; and a set of processing circuits (208.2) configured to: determine a validity of the counter value that is computed from the counter value representation contained in the first field; and accept or reject the protected message based on (i) the determined validity of the counter value and (ii) a determination, based on the value encoded in the second field, as to whether the second node responded affirmatively to the online state check request, Petition 870260071805, dated 07 / 20 / 2026, p. 201 / 320 4 / 12 wherein: the second field comprises a bit sequence including a plurality of bits, a predetermined bit position of each of the plurality of bits is identified with a respective node among the system of interconnected nodes, and the value encoded in the second field corresponds to a predetermined bit position identified with the first node.

11. First node, according to claim 10, CHARACTERIZED in that a protected message previously transmitted by the first node includes a third field comprising a representation of a query value indicating whether the first node is requesting an online status check from the second node.

12. First node, according to claim 11, CHARACTERIZED in that the query value representation comprises a one-bit binary value or an encoded value that uniquely identifies the first node.

13. First node, according to claim 10, CHARACTERIZED in that the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

14. First node, according to claim 10, CHARACTERIZED in that the set of communication circuits (208.1) is configured to transmit the protected message according to a communication protocol comprising one of a Control Area Network communication protocol, CAN, a Control Area Network communication protocol with Flexible Data Rate, CAN FD, an Extra Long Control Area Network communication protocol, CAN XL, or a multipoint Ethernet communication protocol.

15. First node, according to claim 10, CHARACTERIZED in that the protected message forms at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol frame, an Extra Long Control Area Network (CAN XL) communication protocol frame, or an Ethernet communication protocol frame.

16. First node in a system of interconnected nodes configured to communicate via a bus, the first node CHARACTERIZED in that it comprises: a set of communication circuits (208.1) configured to receive a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function before receiving the protected message, and (ii) a second field comprising a representation of a query value indicating a request for online state verification; and a set of processing circuits (208.2) configured to: determine a validity of the counter value which is computed from the counter value representation contained in the first field; and accept or reject the protected message based on the determined validity of the counter value, wherein the communication circuitry (208.1) is additionally configured, when the protected message is accepted, to generate a next scheduled protected message for transmission to the bus, which includes a third field containing an encoded value indicating an affirmative response to the online status check request, Petition 870260071805, 20 / 07 / 2026, p. 203 / 320 6 / 12 the third field comprises a bit sequence including a plurality of bits, and each bit in the bit sequence is identified with each respective node of the interconnected node system by means of a respective predetermined bit position within the bit sequence.

17. First node, according to claim 16, CHARACTERIZED in that the processing circuitry (208.2) is configured to store a local bit sequence comprising an indication, for each respective bit in the bit sequence, as to whether each node in the system of interconnected nodes has requested an online status check from the first node.

18. First node, according to claim 17, CHARACTERIZED in that the communication circuitry (208.1) is configured to transmit the next scheduled protected message to the bus comprising, as the bit sequence included in the third field, the local bit sequence.

19. First node, according to claim 18, CHARACTERIZED in that the processing circuitry (208.2) is configured to reset a value of each bit in the local bit sequence to a predetermined initial value after transmitting the next scheduled protected message.

20. First node, according to claim 16, CHARACTERIZED in that the query value representation comprises a one-bit binary value or an encoded value that uniquely identifies a second node in the system of interconnected nodes.

21. First node, according to claim 16, CHARACTERIZED in that the system of interconnected nodes is configured to communicate via the bus according to a multipoint scheme.

22. First node, according to claim 16, CHARACTERIZED by Petition 870260071805, dated 20 / 07 / 2026, p. 204 / 320 7 / 12 fact that the set of communication circuits (208.1) is configured to transmit the next scheduled protected message in accordance with a communication protocol comprising one of a Control Area Network, CAN, Control Area Network with Flexible Data Rate, CAN FD, Control Area Network Extra Long, CAN XL, or a multipoint Ethernet communication protocol.

23. First node, according to claim 16, CHARACTERIZED in that the protected message and the next scheduled protected message form at least part of a communication protocol frame, and wherein the communication protocol frame comprises one of a Control Area Network (CAN) communication protocol frame, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol frame, an Extra Long Control Area Network (CAN XL) communication protocol frame, or an Ethernet communication protocol frame.

24. A node in a system of interconnected nodes that are part of a protected control system and are configured to communicate via a bus, CHARACTERIZED in that it comprises: a set of processing circuits (208.2) configured to: generate a protected message using a temporary session key, wherein the protected message includes (i) a first field comprising a representation of a query value indicating whether the node is requesting an online status check from other nodes within the system of interconnected nodes, and (ii) a second field indicating whether the node has responded affirmatively to a request for an online status check from any node within the system of interconnected nodes, and Petition 870260071805, dated 20 / 07 / 2026, p. 205 / 320 8 / 12 store an indication of the current online status of each node in the system of interconnected nodes; and a set of communication circuits (208.1) configured to transmit the protected message to the bus, where the stored indication of the current online state of each node in the interconnected node system comprises a bit sequence, and where a value of each bit in the bit sequence indicates whether each node in the interconnected node system is currently online.

25. Node, according to claim 24, CHARACTERIZED in that the processing circuitry (208.2) is configured to determine the current online state of each node in the interconnected node system based on an accumulation of bit values ​​from a plurality of received protected messages.

26. A node, according to claim 24, CHARACTERIZED in that the bit value of each bit in the bit sequence is reset to a predetermined value after a timeout period has elapsed.

27. Node, according to claim 24, CHARACTERIZED in that the set of communication circuits (208.1) is configured to transmit the protected message according to a communication protocol comprising one of a Control Area Network communication protocol, CAN, a Control Area Network communication protocol with Flexible Data Rate, CAN FD, an Extra Long Control Area Network communication protocol, CAN XL, or a multipoint Ethernet communication protocol.

28. Method for transmitting a protected message via a first node in a system of interconnected nodes configured to communicate via a bus, the method CHARACTERIZED by the fact that it comprises: deriving a temporary session key from a shared secret and a counter value according to a cryptographic function; Petition 870260071805, dated 07 / 20 / 2026, p.206 / 320 9 / 12 generate a protected message using the temporary session key, wherein the protected message includes a first field comprising a representation of the counter value, and a second field comprising a representation of a query value indicating whether the first node is requesting an online status check from one or more other nodes within the interconnected node system; determine whether a second node in the interconnected node system is online based on a received protected message that is received via the bus, the received protected message comprising a response to an online status check sent via the bus by the first node; and transmit the protected message to the bus, wherein the response to the online status check is represented by a third field contained in the received protected message indicating an online status of the second node.

29. Method according to claim 28, CHARACTERIZED in that transmitting the protected message comprises: transmitting the protected message according to a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

30. Method for receiving a protected message through a first node in a system of interconnected nodes configured to communicate via a bus, the method CHARACTERIZED in that it comprises: receiving a protected message via the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function prior to receiving the protected message, and (ii) a second field containing an encoded value indicating whether a second node responded affirmatively to an online state check request from the first node; determining a validity of the counter value that is computed from the representation of the counter value contained in the first field;and accept or reject the protected message based on (i) the determined validity of the counter value, and (ii) a determination, based on the value encoded in the second field, as to whether the second node responded affirmatively to the online state check request, wherein: the second field comprises a bit sequence including a plurality of bits, a predetermined bit position of each of the plurality of bits is identified with a respective node among the system of interconnected nodes, and the value encoded in the second field corresponds to a predetermined bit position identified with the first node.

31. Method according to claim 30, CHARACTERIZED in that receiving the protected message comprises: receiving the protected message according to a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol.

32. Method for communication through a first node in a system of interconnected nodes configured to communicate through a bus, the method CHARACTERIZED by the fact that it comprises: receiving a protected message through the bus, wherein the protected message includes (i) a first field comprising a representation of a counter value that was used to derive a temporary session key to generate the protected message according to a cryptographic function before receiving the protected message, and (ii) a second field comprising a representation of a query value that indicates a request for online state verification; determining a validity of the counter value that is computed from the representation of the counter value contained in the first field; accepting the protected message based on the determined validity of the counter value;and generate a next scheduled protected message for transmission to the bus that includes a third field containing an encoded value indicating an affirmative response to the online status check request, wherein the third field comprises a bit sequence including a plurality of bits, and wherein each bit in the bit sequence is identified with each respective node of the interconnected node system by means of a respective predetermined bit position within the bit sequence.

33. Method according to claim 32, CHARACTERIZED in that receiving the protected message comprises: receiving the protected message according to a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol. Petition 870260071805, dated 07 / 20 / 2026, p. 209 / 320 12 / 12 34. A method for communication through a node in a system of interconnected nodes that are part of a protected control system and are configured to communicate through a bus, the method CHARACTERIZED by the fact that it comprises: generating a protected message using a temporary session key, wherein the protected message includes (i) a first field comprising a representation of a query value indicating whether the node is requesting an online status check from other nodes within the system of interconnected nodes, and (ii) a second field indicating whether the node has responded affirmatively to a request for an online status check from any node within the system of interconnected nodes; storing an indication of the current online status of each node in the system of interconnected nodes;and transmit the protected message to the bus, wherein the stored indication of the current online state of each node in the interconnected node system comprises a bit sequence, and wherein a value of each bit in the bit sequence indicates whether each node in the interconnected node system is currently online.

35. Method according to claim 34, CHARACTERIZED in that transmitting the protected message comprises: transmitting the protected message according to a communication protocol comprising one of a Control Area Network (CAN) communication protocol, a Control Area Network with Flexible Data Rate (CAN FD) communication protocol, an Extra Long Control Area Network (CAN XL) communication protocol, or a multipoint Ethernet communication protocol. Petition 870260071805, dated July 20, 2026, pp. 210-320

Images