Scheduling-based low latency detection for desynchronization attacks

Abstract

The present disclosure describes scheduling-based low latency detection for desynchronization attacks. Techniques include methods, apparatus, systems, and computer readable media for detecting, quantifying, and locating attacks to enhance security of time-synchronized networking. Embodiments include a diagnostic flow producer for generating diagnostic information that provides evidence of timing attacks to nodes of a time-synchronized network. Embodiments include a diagnostic stream consumer for consuming diagnostic information, analyzing the diagnostic information, and determining whether a node is subject to a timing attack. Other embodiments are also described and claimed.

Description

Background Art

[0001] Many computing systems require real-time safety-critical features. For example, many autonomous systems, industrial systems, and the like require such systems to have real-time safety-critical features. This typically requires that the timing performance within the system have a higher level of safety relative to other aspects of the system. For example, factories typically employ synchronized robots in the presence of humans to complete coordinated tasks. In another example, robots utilize coordination to perform surgery on humans. As yet another example, self-driving vehicles require synchronization of networked sensing elements to establish accurate perception of the vehicle's surroundings, including other vehicles, objects, hazards, and personnel. The tools that are relied upon to achieve the necessary time performance, synchronization, and bounded latency communications so that such time-sensitive systems perform as required are typically referred to as time-synchronized networking.

[0002] Generally speaking, time synchronized networking or time sensitive networking defines a set of standards (and amendments) whose purpose is to achieve time synchronization and deterministic data delivery in converged networks where time-critical (TC) traffic coexists with other types of traffic. Therefore, there is a need to provide security for time synchronized network equipment to mitigate the risks associated with disruption of time synchronized network operations due to attacks on the timing of the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] To easily identify the discussion of any particular element or activity, the most significant digit or digits in a reference number refer to the figure number that first introduces that element.

[0004] Figure 1A The diagram illustrates an aspect of a time-synchronized network (TSN) 102 according to one embodiment.

[0005] Figure 1B The diagram illustrates an aspect of a TSN 102 for a sensor according to one embodiment.

[0006] Figure 1C The diagram illustrates an aspect of a TSN 102 for an actuator according to one embodiment.

[0007] Figure 2A The figure illustrates an aspect of a TSN 200a according to one embodiment.

[0008] Figure 2B An aspect of a timing diagram 200b is shown according to one embodiment.

[0009] Figure 3AThe diagram illustrates an aspect of a TSN 300a according to one embodiment.

[0010] Figure 3B An aspect of a timing diagram 300b is shown according to one embodiment.

[0011] Figure 4 The figure illustrates an aspect of an apparatus 400 according to one embodiment.

[0012] Figure 5 The figure illustrates an aspect of an apparatus 500 according to one embodiment.

[0013] Figure 6 An aspect of an operating environment 600 is illustrated according to one embodiment.

[0014] Figure 7 An aspect of an operating environment 700 is illustrated according to one embodiment.

[0015] Figure 8 An aspect of a system 800 is shown according to one embodiment.

[0016] Fig. 9 An aspect of a system 900 is shown according to one embodiment.

[0017] Fig. 10A An aspect of a benign operating environment 1000a is illustrated according to one embodiment.

[0018] Fig. 10B The diagram illustrates an aspect of an attack operating environment 1000b according to one embodiment.

[0019] Fig.11 An aspect of a logic flow 1100 is illustrated according to one embodiment.

[0020] Fig.12 An aspect of a heartbeat message structure 1200 is illustrated according to one embodiment.

[0021] Fig.13A The figure illustrates an aspect of a TSN node 1300a according to one embodiment.

[0022] Fig. 13B The figure illustrates an aspect of a TSN node 1300b according to one embodiment.

[0023] Fig.14 FIG. 14 shows an aspect of a computer readable medium 1400 according to one embodiment. DETAILED DESCRIPTION

[0024] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. However, the various embodiments may be implemented without these specific details. In other instances, well-known methods, processes, components, and circuits are not described in detail to avoid obscuring the specific embodiments. In addition, various aspects of the embodiments may be performed using various means, such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or some combination of hardware and software. For the purposes of this disclosure, references to "logic" shall mean hardware (such as, logic circuit systems or (more generally) circuit systems or circuits), software, firmware, or some combination thereof.

[0025] The present disclosure generally relates to low latency techniques for detecting, quantifying, and locating security attacks on time synchronization and traffic scheduling for systems operating under strict time requirements, such as systems based on time sensitive networks or time synchronized networks (TSNs). An embodiment defines and implements a novel heartbeat message that carries diagnostic information to help an intrusion detection system (IDS) detect, quantify, and locate desynchronization attacks on network nodes of the TSN. The diagnostic information may include time information, such as timestamps associated with critical events in the network nodes of the TSN. A trusted entity transmits a heartbeat message at a defined interval according to a security policy of the TSN or a TSN application. The security policy defines a heartbeat interval based on the time sensitivity of the TSN or a TSN application. The heartbeat interval may be different from a time synchronization protocol implemented for the TSN. In one embodiment, for example, the frequency of the heartbeat interval may be greater than the synchronization interval set by the time synchronization protocol.

[0026] As described, TSN defines a set of standards (and amendments) whose purpose is to achieve time synchronization and deterministic data delivery in a converged network where time-sensitive traffic coexists with other types of traffic. Various standards have been developed to address time synchronization or time-sensitive communication issues. As an example and not a limitation, some standards for implementing time-synchronized communications include standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) and / or the International Electrotechnical Commission (IEC). For example, IEEE 1588, IEEE 802.1AS, IEEE802.1Qbv, and IEC / IEEE60802 provide systems and methods for synchronizing device clocks. In one example, IEEE1588 defines a precision time protocol (PTP) for cross-network time synchronization. In another example, IEEE 802.1AS defines a time-sensitive networking protocol for time synchronization across networks, called generic PTP (gPTP), in which time-sensitive devices (e.g., clock followers) are synchronized to a leader clock (e.g., clock leader). In yet another example, IEEE 802.1Qbv defines time-sensitive networking for deterministic latency through traffic scheduling. In another example, IEC / IEEE 60802 defines a time-sensitive networking profile for industrial automation. Other examples include network time protocol (NTP), network time security (NTS), and other time synchronization network protocols, NTP is a networking protocol for clock synchronization between computer systems over a packet-switched, variable latency data network, and NTS is a secure version of NTP. Embodiments are not limited to these examples.

[0027] TSN typically implements some basic steps (e.g., defined by one or more standards) for all nodes operating within the TSN, such as time synchronization, traffic scheduling, packet formats, reporting procedures, etc. For time synchronization, the clock leader has a clock that maintains the network time of the TSN. The clock leader periodically sends time information to the clock follower. The clock follower uses the time information to adjust the local clock and synchronize the local clock to match the clock of the clock leader. This process is also followed by any intermediate node in the TSN, such as a switch or relay. For traffic scheduling, the central network controller (CNC) node distributes the traffic schedule to some or all of the TSN nodes in the TSN. Time-aware traffic shaping grants transmission windows to time-synchronized nodes. Each node has a specific transmission window with a predetermined period and duration. The node uses the transmission window to transmit data streams (e.g., in the form of messages, packets, or frames). The data stream flows from the "speaker node" to the "listener node".

[0028] Attackers may use various attack vectors to implement TSN timing attacks to desynchronize TSN. For example, attackers can inject malware into TSN nodes or inject false data into data streams transmitted between TSN nodes. Attacks can attempt to tamper with the TSN time synchronization process, causing network nodes such as clock followers and switches to be desynchronized relative to clock leaders. Due to clock drift, desynchronization causes network nodes to shift their timing windows, which affects traffic scheduling. This deteriorates the timing guarantee between the speaker node and the listener node. Therefore, in TSN, it is critical to detect damaged messages and / or software components of TSN nodes early.

[0029] A conventional solution to this problem is to implement one or more intrusion detection systems (IDS) to monitor the devices in the TSN to identify any abnormal behavior, such as desynchronization attacks that cause desynchronization events. A desynchronization attack is a network attack that aims to disrupt the timing synchronization of the TSN. The IDS implements software, firmware, or hardware that supports one or more dedicated security functions, such as detecting malicious behavior caused by an attacker. The IDS can be implemented on the TSN node, or it can be separated from the TSN node. The IDS receives as input a message containing time information, which is used to synchronize the clock of the TSN node with the network time of the TSN. The IDS analyzes the message to detect anomalies, such as slightly modifying the time information to cause the TSN node to update the internal clock with the wrong network time. Incorrect time synchronization can cause disruptions in time-sensitive applications executed on the TSN node, such as causing collisions between cooperative robot arms or delaying the braking of an autonomous vehicle. When the IDS detects an anomaly in a message carrying time information, the IDS generates an alarm and takes actions to isolate any affected TSN applications and / or TSN nodes from the damaged TSN node.

[0030] Traditional IDS is designed to detect desynchronization events at certain defined time intervals, such as the synchronization interval defined by the TSN standard. For example, TSN can implement various TSN standards in combination, such as IEEE 802.1AS for maintaining a common network time across all nodes in the TSN, and IEEE 802.1Qbv for scheduling transmission gates to provide bounded waiting times for messages. An attacker may attempt to modify the timing synchronization messages of the 802.1AS protocol, which in turn can break the bounded waiting times set by the 802.1Qbv protocol by causing desynchronization events. Since 802.1Qbv is strictly dependent on IEEE 802.1AS or IEEE 1588, any desynchronization will be manifested in the 802.1Qbv protocol.

[0031] Therefore, traditional IDSs typically attempt to detect such attacks during the synchronization interval defined by 802.1AS. The synchronization interval in 802.1AS refers to the frequency at which synchronization messages are sent across the network. These messages are used to notify and adjust the clocks of all devices in the network, thereby helping to synchronize them with a common time reference. For example, in some cases, the synchronization interval of 802.1AS is typically set to 125 milliseconds (ms). The exact synchronization interval can vary depending on the specific requirements of the system, the capabilities of the network hardware, and the level of accuracy required. The interval can even be adjusted dynamically depending on network conditions and system requirements.

[0032] However, in some cases, desynchronization events for TSN may occur faster than a given synchronization interval set for TSN. In such cases, TSN may require faster detection of desynchronization attacks to avoid catastrophic system failures. For example, autonomous vehicles may include sensors for light detection and ranging (LIDAR), radio detection and ranging (RADAR), cameras, ultrasonic sensors, inertial measurement units (IMU), global positioning system (GPS) sensors, etc. The LIDAR sensor implemented for autonomous vehicles and transmitted by TSN operates at a frequency of 100 Hertz (Hz), which means that it takes 100 samples per second, or one sample every 10 milliseconds. The sampling rate of high-end LIDAR sensors operates at a higher frequency of 1 Megahertz (MHz), which means that it collects a sample every 1 millisecond. An IDS designed to detect a desynchronization event every 125 milliseconds cannot detect desynchronization events quickly enough for the LIDAR sensor in the autonomous vehicle. This can cause the autonomous vehicle to incorrectly detect nearby objects, leading to a collision situation.Current detection solutions lack efficient methods to detect, quantify, and localize attacks in time synchronization and traffic measurement in modern TSNs.

[0033] In order to address these and other challenges in systems that implement time-synchronized networked operations, embodiments implement low latency techniques for detecting, quantifying, and locating security attacks on time synchronization and traffic scheduling of systems (such as TSN) operating under strict time requirements. Embodiments rely on accurate high-priority heartbeat message scheduling to infer the stability of the network. A trusted entity (such as a CNC) distributes scheduled time intervals (referred to as heartbeat intervals) for TSN nodes to transmit heartbeat messages. The CNC can define the heartbeat interval according to a security policy. For example, the defined heartbeat interval may be shorter than a given synchronization interval of the TSN. The CNC can also define a higher priority level for the heartbeat message relative to lower priority traffic messages to ensure bounded waiting times for the heartbeat message. The heartbeat message itself contains diagnostic information, such as immutable or cryptographically secure timestamps (such as transmission and / or reception timestamps) of critical events of high-priority messages. Similarly, a cryptographic engine encrypts or provides a message authentication code to the heartbeat message and / or diagnostic information to prevent unauthorized modification. The speaker node or CNC may generate a heartbeat message according to a defined schedule (e.g., an 802.1Qbv schedule) and transmit the heartbeat message to the listener node. . Each intermediate network node (such as a switch node or a relay node) along the network path between the speaker node and the listener node may add diagnostic information to the heartbeat message, such as an immutable timestamp of a critical event. The intermediate network node forwards the heartbeat message along the network path until it reaches the listener node. One or more IDSs deployed to monitor network nodes may analyze the immutable timestamp to determine whether the heartbeat message is transmitted across the TSN within an expected time interval, such as determined by a machine learning model or other inference model trained during benign conditions. Other inference models may include statistical-based models, rule-based models, signature-based models, or other models derived from first principles. When the IDS determines that the TSN transmits a heartbeat message faster or slower than the expected time interval, the IDS may generate a security alert and take various security actions defined by the security policy for the TSN.

[0034] In one embodiment, for example, a computing device may include a processing circuit system. The computing device may include a memory storing instructions that, when executed by the processing circuit system, cause the processing circuit system to receive a heartbeat message through an intrusion detection system (IDS) in a time-sensitive network (TSN), the heartbeat message including a heartbeat vector and a message authentication code (MAC), the heartbeat vector including a set of immutable values, each of which represents a timestamp associated with a network node in the TSN. The processing circuit system may: authenticate the heartbeat vector based on the message authentication code; retrieve a timestamp pair from the heartbeat vector; determine an actual time difference based on the timestamp pair; retrieve an expected time difference associated with the timestamp pair; and detect a desynchronization event for the TSN based on the actual time difference and the expected time difference.

[0035] When TSN implements heartbeat messages, IDS can detect desynchronization attacks faster before the TSN or a TSN application used for TSN experiences a desynchronization event that could damage or disable the operation of the TSN or TSN application. This results in rapid detection, quantification, and localization of network attacks, thereby improving the reliability, availability, and resilience of TSN.

[0036] Figure 1A An exemplary time synchronization network (TSN) 102 implemented according to a TSN standard (e.g., IEEE 1588, IEEE 802.1AS, IEEE 802.1Qbv, etc.) is depicted. As depicted, the TSN 102 includes various TSN nodes 104, such as TSN nodes 104a-d. The TSN nodes 104 may be implemented as different types of nodes of the TSN, such as a start node, a relay node, a switch node, an end node, a speaker node, a listener node, a diagnostic stream producer, a diagnostic stream consumer, etc. The TSN nodes 104a-d are communicatively coupled via a TSN fabric 114. The TSN fabric 114 may connect the TSN nodes 104a-d using various types of network topologies (such as a mesh, a star, etc.) and various types of communication channels (e.g., wired, wireless, optical fiber, a bus, etc.). It is noted that the number of nodes in the TSN 102 is selected for clarity and not for limiting purposes. In practice, TSN 102 may include any number and combination of nodes (eg, initiator nodes, switches, relay nodes, end devices, etc.).

[0037] The TSN nodes 104 may communicate with each other via the TSN fabric 114. For example, the TSN nodes 104 may send messages 112 to each other via one or more communication channels provided by the TSN fabric 114. The messages 112 may include control information and payload information. One type of control information may include time information. The time information may include a synchronization message, a time update message, or a time follow-up message (and other time protocol messages) of a time protocol used by the TSN 102.

[0038] Each TSN node 104 in the TSN 102 includes various hardware and / or software components. Figure 1A As depicted, TSN 104 includes a clock manager 106, a clock 108, and an intrusion detection system (IDS) 110 (referred to herein as an "IDS" or "detector"). For example, TSN node 104a includes clock manager 106a, clock 108a, and IDS 110a. TSN node 104b includes clock manager 106b, clock 108b, and IDS 110b. TSN nodes 104c, 104d are similar in configuration. It will be appreciated that these are only a few components of TSN 104, and TSN 104 may include other standard components of electronic devices, such as network interfaces, radio transceivers, input / output (I / O) components, memory units, processing circuits, controllers, sensors, actuators, mechanical components, application software, operating system software, TSN-enabled platforms, etc.

[0039] In various embodiments, clock manager 106 is implemented as a software component, and clock 108 is implemented as a hardware component (e.g., a "hardware clock" or "clock circuitry"). IDS 110 may be implemented as a software component, a hardware component, or a combination of both software and hardware components. The embodiments are not limited in this context.

[0040] The clock manager 106 typically manages the time (e.g., clock signals) generated by the clock 108. A key component in the clock synchronization mechanism is the clock manager software. In a time synchronized network such as TSN 102, this component interacts closely with the network hardware (e.g., Ethernet / Wi-Fi) to obtain Precision Time Protocol (PTP) message timestamps, and the component interacts closely with the PTP clock hardware to achieve appropriate phase / frequency corrections to synchronize with the clock leader. The clock manager 106 typically implements a "clock servo." A clock servo is a control algorithm that periodically takes as input some measurement (or estimate) of the clock offset from a reference clock and computes as output a time (e.g., phase) or frequency adjustment to compensate for a given offset.

[0041] The clock 108 is typically a hardware clock that implements a clock circuit system for generating signals for digital electronic devices implemented by the TSN node 104. In electronic devices, and particularly in synchronous digital circuits, a clock signal oscillates between a high state and a low state and is used to coordinate the actions of digital circuits. The clock signal is generated by a clock generator. Although more complex arrangements are used, the most common clock signal is a clock signal in the form of a square wave with a 50% duty cycle, typically with a fixed constant frequency. The circuit using the clock signal for synchronization can become active either on the rising edge or on the falling edge, or in the case of double data rate, the circuit becomes active on both the rising edge and the falling edge of the clock cycle. The clock 108 generates the clock signal under the control of the clock manager 106. The clock 108 can be implemented using any suitable hardware with the timing accuracy required for a given device or network. In the TSN 102, the clock 108 can be implemented as a PHC, but other hardware clocks can also be implemented. The embodiments are not limited to this context.

[0042] In normal operation, a network interface (not shown) of the TSN node 104 may receive a message 112 including time information representing the network time of the TSN 102. The clock manager 106 may receive the time information from the network interface, analyze the time information, and determine whether a time adjustment is required for the clock 108. When a time adjustment is required, the clock manager 106 generates control information and sends the control information to the clock 108. The clock 108 receives the clock manager control information and adjusts a parameter of the clock 108, such as a phase or frequency of a clock signal generated by the clock 108.

[0043] IDS110 typically monitors the clock manager 106 to detect abnormal or malicious behavior of TSN 102. In general, IDS110 is a device or software application that monitors a device, network or system for malicious activities or policy violations. IDS110 can be specifically adjusted to detect timing attacks, such as desynchronization attacks or other TSN specific attack vectors. Any intrusion activity or violation is usually reported to other devices in the same network, management parties, and / or collected centrally using security information and event management (SIEM) systems. The SIEM system combines outputs from multiple sources and uses alarm filtering techniques to distinguish malicious activities from false alarms. In addition to TSN nodes 104, IDS110 can also be implemented for other devices in TSN (such as relay nodes 104a-104c) to provide a more comprehensive security solution for attacks.

[0044] IDS110 can operate in online mode or offline mode. When operating in online mode, IDS110 checks network traffic in real time. It analyzes the traffic transmitted on the entire subnet and matches the traffic transmitted on the subnet with a library of known attacks. For example, it analyzes message 310 (e.g., TSN timing message) and applies some rules to determine whether it is an attack. Offline mode usually processes stored data and passes it through some processes to determine whether it is an attack. For offline situations, messages can be copied for offline analysis. Messages can be copied in hardware without initiating memory copying. However, software solutions can copy messages from queues for later analysis. In either of these two modes, once an attack is identified or abnormal behavior is sensed, an alert can be sent to a SIEM, a network manager, or a software application to automatically implement security protocols, such as discarding message 112, isolating infected devices protected by IDS110, and / or reconfiguring one or more network paths for affected devices in the TSN network.

[0045] IDS110 can use any number of different methods to detect attacks. For example, IDS110 can implement a signature-based method, a statistical anomaly-based method, a stateful protocol analysis method, a machine learning-based method, or some combination of all four methods. A signature-based IDS monitors packets in a network and compares them to preconfigured and predetermined attack patterns called signatures. A statistical anomaly-based or machine learning-based IDS monitors network traffic and compares it to an established baseline. The baseline will identify what is "normal" for the network, such as what bandwidth is typically used and what protocols are used. A stateful protocol analysis IDS identifies deviations in protocol states by comparing observed events to a defined profile of a generally accepted definition of benign activity. It will be understood that these detection methods are provided as examples and not limitations. Other embodiments may also use different detection methods. The embodiments are not limited in this respect.

[0046] Figure 1B The figure shows an example of a TSN node 104a of a TSN 102 designed to control one or more sensors 144. Figure 1BAs depicted, TSN node 104 manages various types of sensors 144, such as signal sensor 116, biometric sensor 118, power sensor 120, acoustic sensor 122, sound sensor 124, visual sensor 126, speed sensor 128, temperature sensor 130, etc. TSN node 104a may be adapted to implement a physics-based model for IDS 110. Physics-based approaches utilize state predictions based on physical models of system dynamics. Unlike traditional information-based security measures, physics-based models can utilize physical properties of the system as well as controller state estimates to achieve computationally inexpensive analytical redundancy. For example, mathematical model-based copies of the system are executed simultaneously to detect attacks.

[0047] Figure 1C The figure shows an example of a TSN node 104b of a TSN 102 designed to control one or more actuators and / or a host controller 146. Figure 1C As depicted, TSN node 104b manages various types of actuators / controllers 146, such as robot controller 136, server controller 138, mechanical actuator 148, circuit controller 140, device controller 142, video controller 132, computer controller 134, etc. Figure 1B Same, Figure 1C The TSN node 104 b shown in FIG. 1 may be suitable for implementing a physics-based model for the IDS 110 , as described in detail herein.

[0048] In time synchronization networks such as Figure 1A-Figure 1C In the TSN 102 depicted in FIG. 1 , it becomes important for all TSN nodes 104 to synchronize to a common network time or shared network time of the TSN 102. For example, the TSN nodes 104 may operate in accordance with IEEE 802.1AS, which implements a hierarchical network to synchronize one or more clock follower (CF) nodes to a clock leader (CL) node (e.g., grand CL) through a relay node or a switch node. The synchronization is performed through the transmission of time messages, such as the message 112. For example, for PTP, the time messages may include a time synchronization message, a time update message, and / or a time follow-up message.

[0049] In some cases, an attacker may simply attempt to disrupt the timing of a single TSN node 104 that handles critical functions, such as disrupting one or both of the TSN node 104a that manages the sensor 144 and / or the TSN node 104b that manages the actuator / controller 146. Rather than attempting to disrupt the timing of the entire TSN 102, the attacker attempts to attack the timing of a single TSN node 104 to disrupt critical operations of the TSN node 104, such as an electronic control unit (ECU) for speed sensing of a vehicle or a controller of a robotic arm in a factory.

[0050] In other cases, the attacker may attempt to disrupt the timing of the entire TSN 102. In order to attack or disrupt the TSN 102, the attacker may attempt to conduct a timing attack or a desynchronization attack to damage the timing of one or more of the TSN nodes 104 in the TSN 102. Assume that the TSN node 104c operates as a clock leader (CL) in the TSN 102, and the TSN node 104d operates as a clock follower (CF) in the TSN 102. If an attacker located on a network device (e.g., a switch or a relay) modifies a critical attribute on a specific port, then all downstream nodes of the network device may suffer a desynchronization event. In this example, if the attacker successfully damages the TSN node 104c, the TSN node 104d is vulnerable to a timing attack in the form of receiving a message 112 with incorrect time information from the TSN node 104c. Therefore, it becomes important to detect and locate the attack as quickly as possible. Furthermore, upon detection, it becomes important for the TSN 102 to quickly isolate the compromised network device and thereby prevent the desynchronization attack from spreading to other downstream nodes.

[0051] In all cases, time synchronized networks such as TSN 102 are susceptible to timing attacks or desynchronization attacks. If a single network node is compromised, this can lead to cascading failures across the entire TSN 102. Figure 2A , Figure 2B , Figure 3A and Figure 3B Examples of such attacks are further described.

[0052] Figure 2AA TSN 200a is depicted that is implemented in accordance with a TSN standard (e.g., IEEE 1588, IEEE 802.1AS, IEEE802.1Qbv, etc.). As depicted, the TSN 200a includes a clock leader node 202, relay nodes 204a, 204b, and 204c, and a clock follower node 206, all of which are communicatively coupled via a communication channel 208. As defined by IEEE 1588 and IEEE802.1AS, the clock leader node 202 and the clock follower node 206 have a "master / slave" relationship, where the clock leader node 202 is considered a "master" device and the clock follower node 206 is considered a "slave" device. The clock leader node 202 includes a clock that maintains the network time of the TSN 102. The clock follower node 206 includes a clock that synchronizes the clock to the network time via one or more of the messages 112. Alternatively, the nodes of the network may be implemented as a "speaker node" and a "listener node," respectively. This configuration refers to data transmission in which a speaker node transmits data and a listener node listens or receives data. For example, this configuration is used in scheduled traffic.

[0053] Relay nodes 204a, 204b, and 204c are time-aware switching nodes and can be any number of devices in a network that are arranged to transmit information. Clock leader node 202 sends or originates information, and clock follower node 206 receives or consumes information. Examples of clock leader node 202 or clock follower node 206 include devices such as electronic control units in autonomous vehicles, industrial systems, medical systems, etc. In addition, communication channel 208 can be any of a variety of communication channels, including wired or wireless communication channels. In some implementations, all devices in TSN 200a will receive a gate control list (GCL) table. However, in some implementations, only clock leader node 202 and switching nodes (e.g., relay node 204a, etc.) receive the GCL table, while destination devices (e.g., clock follower node 206) do not receive the GCL table.

[0054] Figure 2BA timing diagram 200b is depicted describing the communication window (e.g., Qbv window, etc.) of the switch of TSN 200a based on the GCL table. Typically, the GCL table is generated in a network controller (not shown) and is designed to give priority to time-critical (TC) traffic and prevent low-priority traffic from accessing the communication channel 208, thereby ensuring timely delivery of TC packets within a preconfigured time window. In particular, timing diagram 200b depicts Qbv windows 210a, 210b, and 210c, in which packets 212, 214, and 216 are transmitted. Note that for clarity, the communication windows mentioned herein are referred to as Qbv windows or protected windows. However, in addition to the Qbv window, other standards or technologies can also be used to form a protected communication window to facilitate time synchronization. Examples are not limited to this context.

[0055] To facilitate the transmission of packets (e.g., packet 212, etc.) during protected windows (e.g., Qbv windows 210a, etc.), nodes in TSN 200a are time synchronized and scheduled to transmit TC packets (e.g., packet 212, etc.) using non-overlapping protected windows (e.g., Qbv windows 210a, etc.). It should be understood that providing latency-bounded communication (e.g., as depicted in timing diagram 200b) requires tight synchronization of time between nodes in TSN 200a. Due to such reliance on time synchronization, reliable TSN operation can be disrupted by attacks on the timing of the network (sometimes referred to as desynchronization attacks or events).

[0056] Figure 3A Depicted is TSN 300a, which is similar to TSN 200a, except that relay node 302 is depicted as being compromised. Specifically, a clock (not shown) of relay node 302 may be attacked and corrupted, causing the Qbv window 210b associated with relay node 302 to be misaligned with, or even overlap with, protected windows of other switch nodes in the data flow path (e.g., along communication channel 208).

[0057] Figure 3B The depiction shows a timing diagram 300b in which Qbv window 210b is misaligned with Qbv window 210a and Qbv window 210c and overlaps with Qbv window 210a. As a result, packets (e.g., packet 214 in the figure) arrive too late relative to the attacked switch protected window (e.g., Qbv window 210b), causing these packets to be buffered and sent in the next protected window, or alternatively, these packets to be completely dropped. Due to the delay in transmitting packet 214, relay node 302 breaks the latency boundary of the flow it serves and may cause errors or damage the security of the system in which the node operates.

[0058] Figure 4 The figure shows a more detailed view of a TSN node 104 that implements one or more TSN protocols or standards. The TSN node 104 can be implemented as any network device suitable for operation within a TSN (such as TSN 102, 200a, 300a, etc.). The TSN node 104 can be implemented as part of a vehicle, a robot, an industrial machine, or any other device suitable for TSN. The TSN node 104 can be implemented as a start node 202, a relay node 204a-204c, a relay node 302, and / or an end node 206. The TSN node 104 can be implemented as a clock leader (CL) or a clock follower (CF) in a TSN. The TSN node 104 may include an interface for transmitting information (such as a message 112) with other TSN nodes 104 in the TSN 102.

[0059] The TSN node 104 may operate in accordance with a timing protocol, such as the Precision Time Protocol (PTP) of IEEE 1588, IEEE 802.1AS, etc. For example, the TSN node 104 may operate in accordance with IEEE 802.1AS, which implements a hierarchical network to synchronize a clock follower (CF) to a clock leader (CL) through a relay node or a switch node. Synchronization is performed by the transmission of a time message, such as message 112. For example, the time message may include a time synchronization message, a time update message, or a time follow-up message (among others) of the PTP. The time message may include a correction field that accumulates network residency, and an origin timestamp of the CL, as well as other fields and attributes. For example, the time message may also include a packet delay message type with additional fields and attributes.

[0060] like Figure 4 As depicted, the TSN device 104 may include a software platform 402 and a hardware platform 408. The software platform 402 may include one or more applications 404, the clock manager 106 and a kernel 406, among other software components. The hardware platform 408 may include a network interface (such as a transceiver 410), a clock circuit system 412, a processing circuit system 414, and a memory 416, among other hardware components.

[0061] Processing circuit system 414 may include circuit system or processor logic, such as, for example, any of a variety of commercial processors. In some examples, processing circuit system 414 may include multiple processors, multi-threaded processors, multi-core processors (whether multiple cores coexist on the same tube core or exist on separate tube cores) and / or some other kind of multi-processor architecture, in which multiple physically separate processors are linked in some way. In addition, in some examples, processing circuit system 414 may include a graphics processing portion and may include dedicated memory, multi-threaded processing and / or some other parallel processing capability. In some examples, processing circuit system 414 may be an application specific integrated circuit (ASIC) or a field programmable integrated circuit (FPGA). In some examples, processing circuit system 414 may be a circuit system arranged to perform calculations related to TSN, such as calculations related to switching, clock leaders, clock followers, routing, security, etc.

[0062] The memory 416 may include logic, portions of which include an array of integrated circuits, thereby forming a non-volatile memory, or a combination of non-volatile memory and volatile memory, for persistent storage of data. It will be appreciated that the memory 416 may be based on any of a variety of technologies. Specifically, the array of integrated circuits included in the memory 406 may be arranged to form one or more types of memory, such as, for example, dynamic random access memory (DRAM), NAND memory, NOR memory, etc.

[0063] The transceiver 410 may include logic and / or functions that support a communication interface. For example, the transceiver 410 may include one or more communication interfaces that operate according to various communication protocols or standards to communicate through a direct or network communication link. Direct communication may occur via the use of a communication protocol or standard described in one or more industry standards (including descendants and variants). For example, the transceiver 410 may facilitate communication through a bus, such as, for example, a peripheral component interconnect express (PCIe), a non-volatile memory express (NVMe), a universal serial bus (USB), a system management bus (SMBus), a SAS (e.g., a serially attached small computer system interface (SCSI)) interface, a serial AT attachment (SATA) interface, etc. In some examples, the transceiver 410 may be arranged to support wireless communication protocols or standards, such as, for example, Wi-Fi, Bluetooth, ZigBee, LTE, 5G, etc.

[0064] The TSN node 104 may also include where the network is a controller area network (CAN) or a vehicle area network (VAN). The TSN node 104 may be implemented as a device that manages sensors, actuators, or controllers. The sensors may include speed sensors, direction sensors, global positioning system (GPS) sensors, accelerator pedal sensors, brake pedal sensors, positioning sensors, object detection sensors, lane detection sensors, radar sensors, light detection and ranging (LIDAR) sensors, ultrasonic sensors, inertial measurement unit (IMU) sensors, temperature sensors, pressure sensors, height sensors, acoustic sensors, etc.

[0065] In one aspect, the TSN node 104 may be implemented as a CL or a CF of the TSN 102. As previously described, the clock manager 106 may ensure that the clock circuitry 412 maintains the network time of the TSN 102. When operating in the CL role, the clock manager 106 may send a message 112 with time information 418 representing the current network time to one or more nodes of the TSN 102 operating in the CF role. When operating in the CF role, the clock manager 106 may receive the message 112 from the CL node. The clock manager 106 may use the time information 418 from the message 112 to synchronize the local device time with the current network time maintained by the clock circuitry 412. The clock manager 106 analyzes the time information 418 and determines whether to adjust a parameter (e.g., phase or frequency) of the clock circuitry 412 to synchronize the clock circuitry 412 with the current network time.

[0066] Figure 5 The apparatus 500 is shown. Similar to the apparatus 400, the apparatus 500 includes the software platform 402 and the hardware platform 408. In addition, the apparatus 500 includes the IDS 110 for monitoring the clock manager 106 of the software platform 402. As previously described, the IDS 110 generally monitors the clock manager 106 to detect abnormal or malicious behavior of the clock manager 106. More specifically, the IDS 110 monitors the input and / or output of the clock manager 106, such as consuming as input the time information 418 sent from the transceiver 410 to the clock manager 106, and as output the clock manager control information 420 sent from the clock manager 106 to the clock circuit system 412.

[0067] like Figure 5 As depicted, the apparatus 500 includes a clock circuit system 412 for implementing a hardware clock (e.g., PHC) for a device (such as a TSN node 104). The apparatus 500 includes a processing circuit system 414 coupled to the clock circuit system 412, the processing circuit system 414 for executing instructions to perform the operation of the clock manager 106. The clock manager 106 is operable to receive a message 112 having time information 418 of a network (such as TSN 102). The clock manager 106 generates clock manager control information 420 for adjusting the clock circuit system 412 to the network time of the TSN 102. The clock manager control information 420 may include one or more parameters for adjusting the clock circuit system 412 of the apparatus 500. For example, the one or more parameters may represent an adjustment to the phase or frequency of the clock circuit system 412. For example, the clock manager control information 420 may include a phase or frequency adjustment based on a time offset between a reference time and a time maintained by the clock circuit system 412. The reference time is based on the time information 418 in the at least one message 112.

[0068] Device 500 further includes IDS 110 coupled to processing circuitry 414 and clock circuitry 412. In one embodiment, IDS 110 may be implemented as part of a software layer of device 500, such as software platform 402. In another embodiment, IDS 110 may be implemented as part of a hardware layer of device 500, such as hardware platform 408. In yet another embodiment, certain elements of IDS 110 may be implemented in software platform 402, while other elements of IDS 110 may be implemented in hardware platform 408. The embodiments are not limited in this context.

[0069] Although Figure 5 The IDS 110 is depicted as being implemented as part of the apparatus 500, but it is understood that the IDS 110 may be implemented by another apparatus, device, or system that is communicatively coupled to the apparatus 500. For example, the IDS 110 may be implemented as part of an IDS of the apparatus 500 that is separate from the apparatus 500, or as part of a device other than the device that implements the apparatus 500. For example, if the apparatus 500 is implemented by the TSN node 104a, the IDS 110 of the apparatus 500 may optionally be implemented in the TSN node 104b. The IDS 110 may also be implemented by an IDS that is communicatively coupled to the TSN node 104 directly via a wired or wireless connection or indirectly via the TSN fabric 114. The embodiments are not limited in this context.

[0070] IDS110 is operated to consume multiple types of information to detect security attacks. For example, IDS110 can receive and analyze message 112 for TSN nodes that implement software platform 402 and / or hardware platform 408. Message 112 can carry time information of TSN nodes, such as origin time, residence time, link delay, and other types of clock information. For example, message 112 may include synchronization message or "Follow Up" message. TSN node retrieves time information from message 112 or decodes time information from message 112, and uses time information to synchronize internal local clock with network time issued by clock leader or grandfather clock leader. IDS110 can also receive and analyze other types of information, such as clock manager control information 420 transmitted from clock manager 106 of software platform 402 and hardware platform 408. For example, IDS110 can consume software control messages, or it can have one or more taps on hardware bus or signal line for transmitting electrical signals to hardware platform 408. IDS 110 analyzes message 112 and / or other types of information and determines whether to generate an alert or take corrective action with respect to device 500 based on the results of the analysis.

[0071] Messages 112 are transmitted between TSN nodes at a frequency or rate, which can be measured in terms of the number of messages sent or received per unit time (such as the number of messages sent per second). This is referred to herein as the "message frequency". The message frequency for the transmission of messages 112, which carries the origin time (sync / follow-up) and link delay calculation (LDC), is typically dependent on the latency requirements of time-sensitive applications. The message frequency is typically calculated during the design phase of the TSN taking into account various factors and is instantiated during the initialization of the TSN or individual TSN nodes.

[0072] As previously mentioned, the message frequency used to transmit messages (particularly synchronization messages) can have a significant impact on the IDS operation of TSN102. Many security devices (such as IDS110) are deployed throughout TSN 102. Each deployed IDS110 monitors TSN nodes 104 or groups of TSN nodes 104, receives messages 112 and analyzes messages 112 for anomalies or abnormalities indicating security attacks. However, in some cases, TSN 102 may experience a desynchronization event before IDS110 analyzes synchronization messages to detect potential desynchronization attacks. Therefore, when IDS110 only checks messages 112 at the message frequency set for TSN 102, TSN102 is at risk of suffering a catastrophic failure.

[0073] To address these and other challenges in systems implementing time synchronized networking operations, embodiments implement low latency techniques to detect, quantify, and locate security attacks on time synchronization and traffic scheduling for systems operating under strict time requirements, such as TSN 102. Embodiments rely on accurate high priority heartbeat message scheduling to infer the stability of the network. A more detailed description of an exemplary implementation of a heartbeat message scheme is discussed below.

[0074] Figure 6 The diagram illustrates an operating environment 600 of a TSN 618 that implements one or more TSN protocols, such as IEEE 802.1Qbv, for example. IEEE 802.1Qbv defines a traffic schedule for nodes 1 to 5 of the TSN 618. A central network controller 604 distributes a traffic schedule 608 to nodes 1 to 5. The traffic schedule 608 includes a time window assigned to each node 1 to 5. For example, time windows (W) 1 to 5 may be assigned to nodes (N) 1 to 5, respectively. Since the traffic schedule 608 is distributed to all nodes 1 to 5, each of the nodes 1 to 5 is aware of the assigned time windows W1 to W5 for all nodes 1 to 5 in the TSN 102. This means that each of the nodes 1 to 5 can monitor the assigned time windows W1 to W5 for any of the nodes 1 to 5, even though the node uses its own local clock.

[0075] Figure 7 The diagram illustrates an operating environment 700 of a TSN 618 that implements one or more TSN protocols, such as IEEE 1002.1Qbv. In addition to the central network controller 604 distributing a traffic schedule 608 for messages 112 transmitted over the TSN 618, the central network controller 604 may also distribute a heartbeat schedule 702 to schedule heartbeat messages 706 for transmission over the TSN 618.

[0076] The "speaker node" transmits the heartbeat message 706 to the "listener node". Generally speaking, a heartbeat message is a periodic signal used in computer networks and software to indicate the normal operation or function of a connection or system. The heartbeat message is implemented in the TSN 618 where multiple network nodes or processes need to coordinate with each other. The heartbeat signal helps the IDS monitor the health of each network node.

[0077] like Figure 7 As depicted, each of the heartbeat messages 706 includes a custom, special, or otherwise well-defined message having various information elements (IEs), such as a heartbeat header 708, a heartbeat vector 710, and a MAC 712. The field length of each of the IEs may vary based on the particular implementation.

[0078] The heartbeat header 708 may include envelope information used to assist in routing the heartbeat message 706 along a network path of network nodes in the TSN 618. Examples of envelope information may include, but are not limited to, a source address, a destination address, a message number, a message identifier, a payload identifier, an encryption scheme identifier, a type identifier, and the like.

[0079] The heartbeat vector 710 may include a collection of timestamps for key events during the transmission of the heartbeat message 706. A timestamp is a sequence of characters or coded information that identifies when a certain event occurred, typically giving a date and time of day, sometimes accurate to a fraction of a second. Examples of key events may include, but are not limited to, timestamps associated with transmitter hardware, transmitter wakeup, transmitter program, transmitter kernel network scheduler, transmitter kernel hardware, receiver hardware, receiver program, or any other timestamp associated with an event when a speaker / listener exchanges heartbeats. For example, in one embodiment, a key event is when the transmitting hardware for a first network node in the TSN 618 transmits a heartbeat message 706 to a second network node in the TSN 618, and when the receiving hardware for the second network node receives the heartbeat message 706 from the first network node, and vice versa.

[0080] In one embodiment, the heartbeat vector 710 may include one or more immutable values ​​of immutable data types, similar to a tuple. In computing, an immutable value is a value that cannot be changed once created. If an immutable value needs to be changed, the immutable value itself will not be changed. Alternatively, a new value can be created based on the immutable value. Similarly, once a value such as a timestamp is added to the heartbeat vector 710, it cannot be changed. This ensures the data integrity, consistency, and security of the heartbeat vector 710. This is particularly important for distributed systems such as TSN 618. This is because many copies of the same message are passed between different network nodes. If parts of the message are mutable, different network nodes may end up with different versions of the same message, resulting in confusion and inconsistency. By making the timestamp in the heartbeat vector 710 of each heartbeat message 706 immutable, TSN 618 can ensure that all network nodes agree on the content of a given heartbeat message.

[0081] As the heartbeat message 706 traverses the various network nodes in the TSN 618, new immutable values ​​may be added to the heartbeat vector 710. For example, the transmitting hardware of the first network node generates a first timestamp representing the transmission time of each of the heartbeat messages 706, which is added to the heartbeat vector 710. The receiving hardware of the second network node generates a second timestamp representing the reception time of each of the heartbeat messages 706, which is also added to the heartbeat vector 710. Although the second network node can add the second timestamp to the heartbeat vector 710, due to the use of the authentication code, the second network node cannot create, replace, update, delete (CRUD) or otherwise modify the first timestamp of the heartbeat vector 710. If any of the fields are modified, the authentication code will not match and will therefore be discarded. For example, the modification may be due to a transmission corruption modified by an attacker. Additionally or alternatively, the second network node may generate a new heartbeat vector 710 using the old heartbeat vector 710 as input, as long as the original value of the old heartbeat vector 710 is retained and recoverable by the IDS. Embodiments may use a number of different cryptographic techniques (such as symmetric or asymmetric cryptographic schemes) to achieve the immutable property of the heartbeat vector 710, as described in reference to Fig.12 The embodiments are not limited in this context.

[0082] The heartbeat message 706 may further include a MAC 712. MAC 712 is a message authentication code (MAC), which is a short message used to confirm that the message comes from the sender (e.g., authentication) and has not been changed during transmission (e.g., integrity). MAC 712 is the result of a cryptographic function that takes a message of any length and a key as input and produces a fixed-size output, namely a MAC value, also commonly referred to as a tag. The purpose of a MAC is to authenticate a message: only a party with the same key can generate the same MAC for the same message. This ensures that if both parties share a key, they can use a MAC to authenticate the messages they send to each other. There are various types of MACs, including Hash-based Message Authentication Code (HMAC) and Cipher-based Message Authentication Code (CMAC). HMAC is generated by using a cryptographic hash function in combination with a key, while CMAC uses a block cipher in combination with a key. Although specific techniques are used to generate MAC 712, the main goal remains the same, namely to verify the integrity of the information being sent and to confirm the identity of the sender. In this way, the IDS or network node can use the MAC 712 to authenticate and confirm the identity of the sending network node in the TSN 618.

[0083] The heartbeat schedule 702 defines a schedule for the transmission of heartbeat messages 706 during a heartbeat interval 704 according to a security policy of the TSN 618 or a TSN application that relies on the TSN 618. The heartbeat interval 704 may include a set of parameters 1-M, where M represents any positive integer, that control the transmission of the heartbeat messages 706 through various network nodes in the TSN 618.

[0084] In one embodiment, for example, the heartbeat interval 704 may include 4 parameters (M=4), including: (1) heartbeat period; (2) heartbeat duration; (3) heartbeat vector type, and (4) heartbeat priority. The number and value of the parameters are variable, and the central network controller 604 can statically configure these parameters during the network design and initialization of the TSN 618, or dynamically configure these parameters during the network operation of the TSN 618.

[0085] The heartbeat interval 704 may include a heartbeat period parameter. The heartbeat period parameter may be set to a value that controls the message frequency of the heartbeat message 706. In one embodiment, for example, the defined heartbeat interval 704 may be set to a time interval that is shorter than a given synchronization interval of the TSN 618. For example, assume that the message frequency of the synchronization message of the TSN 618 is 125ms. In this case, the central network controller 604 may schedule the message frequency of the heartbeat message 706 to a shorter time interval. For example, the security policy of an autonomous driving application may include that a LIDAR sensor takes samples at a sampling rate of 1 millisecond and therefore may require security measures required to detect a desynchronization attack within 10 milliseconds. In this case, the central network controller 604 may schedule the heartbeat period to 10 milliseconds.

[0086] The heartbeat interval 704 may include a heartbeat duration parameter. The heartbeat duration parameter may be set to a value that controls the duration of the heartbeat message 706. Since the heartbeat message 706 provides additional security benefits at the expense of additional traffic load, the duration of the heartbeat message 706 may optimize the risk-reward balance of the operation of the TSN 618. Longer durations sacrifice network bandwidth and throughput to increase detectability and resilience. Autonomous vehicles may prioritize detection speed over network speed, while industrial robots may not. The heartbeat duration parameter allows the TSN 618 to be tuned for a given device, system, or application.

[0087] The heartbeat interval 704 may include a heartbeat vector type parameter. The heartbeat vector type parameter may be set to a value that controls the type of heartbeat vector 710 carried by the heartbeat message 706 as a payload. As previously described, the heartbeat vector 710 is a collection of timestamps for key events during the transmission of the heartbeat message 706. In one embodiment, there may be three different heartbeat vector types, designated as vector type 1, vector type 2, and vector type 3, which correspond to: (1) end-to-end heartbeat vectors; (2) speaker-listener heartbeat vectors; or (3) point-to-point heartbeat vectors. Vector type 1 is a vector that includes a collection of timestamps for each key event along the end-to-end network path from the speaker node through the intermediate nodes to the listener node. Vector type 2 is a vector that includes a collection of timestamps for each key event for the speaker node and the listener node and effectively omits any timestamps for the intermediate nodes. Vector type 3 is a vector that includes a collection of timestamps for each key event that occurs along the transmission link of the end-to-end network path from the speaker node through the intermediate nodes to the listener node. Vector type 3 may group timestamp pairs including a transmit hardware timestamp and a receive hardware timestamp to represent each link, where each link is the number of network nodes (N) minus 1 (N-1).

[0088] The heartbeat interval 704 may include a heartbeat priority parameter. The heartbeat priority parameter may be set to a value that controls the priority level of the heartbeat message 706 according to a priority scheme implemented for the TSN 618. The central network controller 604 may define a higher priority for the heartbeat message 706 relative to lower priority traffic messages to ensure bounded latency for the heartbeat message 706. In one embodiment, for example, the TSN 618 may implement a priority scheme for network traffic with three priorities, such as: (1) high; (2) normal; or (3) low. In this case, the heartbeat priority parameter would be set to high to ensure that it is prioritized relative to other network traffic carried by the TSN 618.

[0089] As an example, Figure 7 As depicted, assume that central network controller 604 distributes heartbeat schedule 702 to nodes 1-5 of TSN 618. Further assume that heartbeat schedule 702 includes example values ​​for TSN 618 as follows: (1) heartbeat period is 10 ms; (2) heartbeat duration is 50 us; (3) heartbeat vector type is set to 1, and (4) heartbeat priority is set to high. It will be appreciated that more or fewer heartbeat parameters may be implemented for a given TSN 618, with greater or less granularity of parameter values. The embodiments are not limited in this context.

[0090] In operation, node 1 operates as a speaker node to send a heartbeat message to node 4 operating as a listener node. Node 1 generates a heartbeat message 706 at a heartbeat interval 704 according to a heartbeat schedule 702 and transmits the heartbeat message 706 to node 4. The heartbeat message 706 contains diagnostic information for each of nodes 1-4, such as an immutable or cryptographically secure timestamp of critical events of high priority messages, such as transmission and / or reception timestamps. The diagnostic information appears in the form of a heartbeat vector 710 of vector type 1, which is an end-to-end heartbeat vector. Similarly, a cryptographic engine (not shown) encrypts the heartbeat message 706 and / or the heartbeat vector 710 to generate a MAC 712 using a MAC scheme to prevent unauthorized modification. Each intermediate network node 2, 3 (such as switch nodes 606, 610) along the network path between the speaker node (node ​​1) and the listener node (node ​​4) can add diagnostic information, such as immutable timestamps of key events, to the heartbeat vector 710 of the heartbeat message 706. The intermediate network nodes 2, 3 forward the heartbeat message 706 along the network path until it reaches the listener node (node ​​4).

[0091] One or more of the IDS 620, IDS 622, IDS 624, IDS 626, and / or IDS 628 deployed to monitor network nodes 1-5 may analyze the immutable timestamp carried by the heartbeat vector 710 to determine whether the network node transmits the heartbeat message 706 on the TSN 618 within the expected time interval. A machine learning model may be trained and deployed for each of the IDSs, which receives the timestamp from the heartbeat vector 710 as input and classifies the heartbeat vector 710 as benign or malicious, where the benign category indicates a normal operating environment and the malicious indicates an attack environment. When the IDS determines that the TSN 618 transmits the heartbeat message 706 faster or slower than the expected time interval, the IDS may generate a security alert and take various security actions defined by the security policy of the TSN 618.

[0092] Figure 8 The diagram shows a system 800 suitable for any TSN discussed herein, such as TSN 618 (or TSN 102). Figure 8 As depicted, system 800 may include a speaker node 802 and a listener node 806. In one embodiment, for example, speaker node 802 and listener node 806 are both TSN nodes 104 in TSN 618. In one embodiment, for example, speaker node 802 may represent any network node in TSN 618, such as Figure 7 1, and the listener node 806 may represent any network node in TSN 618 other than the speaker node 802, such as Figure 7 Node 4. Although system 800 depicts a single speaker node 802 and a single listener node 806 for clarity, it is understood that system 800 can implement multiple speaker nodes 802 and listener nodes 806. In addition, although Figure 8 806, there may be several intermediate nodes (not shown), such as nodes 2, 3, along the network path between the speaker node 802 and the listener node 806. The embodiments are not limited in this context.

[0093] In general operation, the speaker node 802 may generate various types of information, which may be transmitted to the listener node 806 via various communication channels implemented by the TSN 618. More specifically, as Figure 8As depicted, the speaker node 802 can generate various types of information that can be transmitted to the listener node 806 via a data stream 830 (e.g., data traffic). The data stream 830 can transmit data information for the network node via one or more data messages 832. For example, the data information may include normal TSN and conventional data traffic, such as control information, application information, management information, timing information, protocol information, etc. The data stream 830 can also transmit diagnostic information for the network node via one or more heartbeat messages 706. The data stream 830 can transmit a combination of data messages 832 and heartbeat messages 706 in a single unified information stream by interleaving the data messages 832 and the heartbeat messages 706 according to a defined protocol format. Alternatively, the heartbeat message 706 can be transmitted in a separate diagnostic stream (not shown).

[0094] While some embodiments may be described as a speaker node 802 sending diagnostic information to a listener node 806 in a data stream 830 via a heartbeat message 706, it is understood that a listener node 806 may also send a heartbeat message 706 to a speaker node 802. Furthermore, any network node in a TSN 618 may operate as a speaker node 802 or a listener node 806. The embodiments are not limited in this context.

[0095] In one embodiment, for example, a speaker node 802, such as TSN node 104, may be implemented at least in part by a computing device including a processor circuit system 818, a memory 820, and an interface 822. The memory 820 may be communicatively coupled to the processor circuit system 818 and the interface 822. The memory 820 may store instructions that, when executed by the processor circuit system 818, cause the processor circuit system 818 to perform one or more operations of the speaker node 802. Additionally or alternatively, the operations may be performed by dedicated hardware (e.g., a DSP, an ASIC, an FPGA, a circuit system, etc.) or a combination of hardware and software. The embodiments are not limited in this context.

[0096] The processor circuitry 818 may execute instructions for the data generator 804. The data generator 804 may prepare the data stream 830 for transmission from the speaker node 802 to the listener node 806 within the time window allocated to the speaker node 802 in the TSN 618. The data generator 804 may determine the transmission time required to send the data stream 830 from the speaker node 802 to the listener node 806 during the time window 670 allocated to the speaker node 802.

[0097] In one embodiment, for example, the central network controller 604 may allocate a time window to the speaker node 802 before sending the data message 832 and the heartbeat message 706 in the data stream 830. The central network controller 604 may distribute a schedule of time window allocations for the TSN nodes 104 to some or all of the TSN nodes 104 within the TSN 102 or TSN 618, such as the traffic schedule 608. The schedule of time window allocations includes time window allocations for some or all of the TSN nodes 104 within the TSN 618. In this way, one TSN node 104 will be aware of the time window allocations for other TSN nodes 104 in the TSN 102 and may monitor the time windows of the other TSN nodes 104 when receiving packets and frames of the other TSN nodes 104. The time windows may be defined according to any TSN or network protocol, such as the time windows defined by IEEE 802.1Qbv. Embodiments are not limited to IEEE 802.1Qbv, and other time windows defined by other TSN protocols may also be used for a given implementation.

[0098] The processor circuitry 818 may execute instructions for the heartbeat message manager 808. In general, the heartbeat message manager 808 may generate a set of heartbeat messages 706 for a given TSN node 104 operating as a speaker node 802. A security monitor 812 implemented by a listener node 806 or an IDS 834 that monitors and protects the listener node 806 may receive the heartbeat message 706 for the TSN node 104, analyze the heartbeat vector 710 carried by the heartbeat message 706, and determine whether the TSN node 104 (e.g., speaker node 802) associated with one or more timestamps carried by the heartbeat vector 710 has been compromised or subjected to a security attack.

[0099] An attacker may implement a timing attack on a TSN node 104, such as a speaker node 802, using various attack vectors to desynchronize the synchronization timing of the TSN 102. For example, an attacker may inject malware into the speaker node 802, or inject false data into the timing information received by the speaker node 802, so that the local clock 108 of the speaker node 802 maintains a local time that is different from the network time of the TSN 618. Due to clock drift, desynchronization causes the speaker node 802 to shift its assigned timing window 670, which affects traffic scheduling. For example, this deteriorates the timing guarantee between the speaker node 802 and other TSN nodes 104 in the TSN 102, such as the listener node 806. Another example of an attack is when other TSN nodes 104 (e.g., intermediate nodes) along the network path to the monitor 812 are affected and therefore window misalignment will occur at these TSN nodes 104.

[0100] However, it is possible for an attacker to intercept the heartbeat message 1010 to modify the set of heartbeat messages 1010 or to forge a set of false heartbeat messages 1010. In order to enhance the security of the heartbeat message 1010, each of the heartbeat messages 1010 is designed to be unique, bound to the TSN node 104, and unforgeable. The heartbeat message is made unique and unforgeable using a pairwise cryptographic key shared between the TSN node 104 and the monitor 812. The keyed hash binds the node number and the packet sequence number. In addition, each of the heartbeat messages 1010 has a unique identifier having a defined minimum size or bit width. Forgery can occur during message relaying during the dwell time. After the message is relayed, the freshness of the identifier forces a completely new forgery attempt. For example, the Ethernet packet minimum payload can accommodate an identifier with a length of up to 368 bits.

[0101] The heartbeat message manager 808 can generate a set of heartbeat messages 706 for the speaker node 802 based on the definitions and parameters in the heartbeat schedule 702. The heartbeat message manager 808 can generate and initiate the transmission of heartbeat messages 1010 according to the heartbeat interval 704. Each of the heartbeat messages 1010 has a format including a heartbeat header 708, a heartbeat vector 710, and a MAC 712. Since the system 800 only includes the speaker node 802 and the listener node 806, the heartbeat vector 710 can be implemented as any one of heartbeat vector types 1, 2, or 3.

[0102] The heartbeat vector 710 may include a collection of timestamps associated with key events for the speaker node 802 and the listener node 806. For example, the processor circuitry 818 of the speaker node 802 may execute instructions for the timestamp generator 836, and the processor circuitry 824 of the listener node 806 may execute instructions for the timestamp generator 838. In one embodiment, the timestamp generator 836 generates timestamps indicating the time at which the transmitting hardware of the interface 822 transmits each of the heartbeat messages 706 from the speaker node 802 to the listener node 806. In one embodiment, the timestamp generator 838 generates timestamps indicating when the receiving hardware of the interface 828 of the listener node 806 receives each of the heartbeat messages 706 from the speaker node 802. The timestamp generator 836 adds a transmission timestamp to the heartbeat vector 710 prior to encryption of the heartbeat message 706 and transmission of the heartbeat message 706 from the speaker node 802. The timestamp generator 838 adds a reception timestamp to the heartbeat vector 710 after decryption / MAC verification of the heartbeat message 706 and receipt of the heartbeat message 706 by the listener node 806 .

[0103] The heartbeat message 706 and / or the heartbeat vector 710 carried by the heartbeat message 706 may include an authentication code, such as a MAC 712. In one embodiment, for example, the authentication code may be generated by a cryptographic key used by the speaker node 802 and the listener node 806 of the TSN 102. The authentication code may represent any cryptographically secure authentication code generated according to a given cryptographic scheme, such as a symmetric key scheme, an asymmetric key scheme, a public key encryption scheme, a Rivest-Shamir-Adleman (RSA) public key encryption scheme, etc. Embodiments are not limited to a particular cryptographic scheme.

[0104] For example, the processor circuit system 818 can execute instructions for the cryptographic engine 810. The cryptographic engine 810 can generate an authentication code, such as MAC 712, for the speaker node 802. The cryptographic engine 810 can receive a set of cryptographic information (such as a symmetric or asymmetric security key) as input and output an authentication code based on the security key. The heartbeat message manager 808 can generate heartbeat messages 706 and output them to the cryptographic engine 810. The cryptographic engine 810 can receive the heartbeat messages 706 as input from the heartbeat message manager 808 and generate an authentication code, such as MAC 712, for each of the heartbeat messages 706. The interface 822 can send the heartbeat messages 706 from the speaker node 802 to the listener node 806 in the data stream 830.

[0105] In one embodiment, for example, a listener node 806 such as TSN 104 may be implemented at least in part by a computing device including a processor circuit system 826, a memory 828, and an interface 824. The memory 826 may be communicatively coupled to the processor circuit system 824 and the interface 828. The memory 826 may store instructions that, when executed by the processor circuit system 824, cause the processor circuit system 824 to perform one or more operations of the listener node 806. Additionally, or alternatively, the operations may be performed by dedicated hardware (e.g., a DSP, an ASIC, an FPGA, a circuit system, etc.) or a combination of hardware and software. The embodiments are not limited in this context.

[0106] The processor circuitry 824 may execute instructions for the monitor 812. The monitor 812 may receive one or more heartbeat messages 706 from the data stream 830 via the interface 828. The processor circuitry 824 may execute instructions for the cryptographic engine 816 to verify the heartbeat message 706 based on the MAC 712. The cryptographic engine 816 may receive as input the MAC 712, and a set of cryptographic information (such as a symmetric or asymmetric security key), and output a verification that the MAC 712 is based on the security key. The monitor 812 may receive as input a verification or authentication from the cryptographic engine 816.

[0107] Once authentication and verification are complete, the monitor 812 may analyze the set of timestamps in the heartbeat vector 710 to determine if there is a deviation from an expected value, thereby providing some indication of a desynchronization attack. The monitor 812 may compare the desynchronization time to a defined threshold to determine if the comparison indicates sufficient evidence of a security attack on the speaker node 802. For example, the monitor 812 may determine the desynchronization time interval between the actual time difference between a pair of timestamps and the expected time difference between the pair of timestamps. Under benign or normal operating conditions, the expected time difference for the network node 104 of the TSN 618 may be measured or calculated.

[0108] As an example, a machine learning model (such as a machine learning classifier) ​​may receive a desynchronization time interval as an input and classify the desynchronization time interval as benign or malicious. A benign classification may indicate that the desynchronization time interval is within a defined statistical variance around a median or mean time value, and a malicious classification indicates that the desynchronization time interval is outside the defined statistical variance and thus indicates a potential desynchronization event. In response to a malicious classification, the monitor 812 may output a control signal to indicate that there is sufficient evidence of a security attack to generate an alarm or warning and take corrective security measures in response to the security attack.

[0109] The processor circuit system 824 may execute instructions for the alarm generator 814. The alarm generator 814 may receive a control signal from the monitor 812 indicating that a desynchronization attack has occurred on the speaker node 802 or an intermediate node (not shown), and generate an alarm for the TSN 102 indicating that the first TSN node 104 is under a security attack. The listener node 806 may send an alarm message to the CNC or SIEM via the interface 828. The CNC or SIEM may initiate security procedures in response to the security attack, such as isolating the speaker node 802, updating routing tables of other TSN nodes 104 (e.g., switch nodes, relay nodes, etc.) in the TSN 618, notifying neighboring TSN nodes of the attack on the speaker node 802, and other corrective actions.

[0110] Fig. 9 The diagram shows a system 900 suitable for any TSN discussed herein, such as TSN 618 (or TSN 102). Figure 8, the system 900 may include a speaker node 802 and a listener node 806. In addition, the system 900 includes an intermediate node 902, which is a network node along a network path between the speaker node 802 and the listener node 806. In one embodiment, for example, the speaker node 802, the intermediate node 902, and the listener node 806 are all TSN nodes 104 within the TSN 618. In one embodiment, for example, the speaker node 802 may represent node 1, the intermediate node 902 may represent node 2 or node 3, and the listener node 806 may represent node 4, as described in reference Figure 7 Although system 900 depicts a single intermediate node 902 for clarity, it is understood that system 900 may implement multiple intermediate nodes 902. The embodiments are not limited in this context.

[0111] The intermediate node 902 includes a processor circuit system 910, a memory 912, and an interface 914, which entities are similar to the reference Figure 8 The same entities discussed are similar. In some cases, the intermediate node 902 can also operate as the speaker node 802 using the data generator 904, the heartbeat message manager 906, the cryptographic engine 908, and the timestamp generator 920.

[0112] When the intermediate node 902 operates as a relay or switch node in the TSN 618 (such as the switch 606 and / or switch 610 of nodes 2 and 3 (respectively), the intermediate node 902 relays or switches the heartbeat message 706 from the speaker node 802 to the listener node 806. The intermediate node 902 receives the heartbeat message 706 from the speaker node 802 or another intermediate node 902 (not shown). The cryptographic engine 908 authenticates the heartbeat message 706 using the associated MAC 712. Once authenticated, the heartbeat message manager 906 retrieves the heartbeat vector 710 from the heartbeat message 706. For key events occurring at the intermediate node 902, the heartbeat message manager 906 receives a timestamp from the timestamp generator 920 and adds the timestamp to the heartbeat vector 710, such as the timestamp indicating the time at which the receiving hardware of the interface 914 receives the heartbeat message 706, and the timestamp indicating the time at which the transmitting hardware of the interface 914 transmits the heartbeat message 706 to the next hop in the network path, to the listener node 806. Since the timestamp carried by the heartbeat vector 710 is immutable, the intermediate node 902 can only add the timestamp to the heartbeat vector 710.

[0113] In some embodiments, the intermediate node 902 may implement a security monitor 922 similar to the security monitor 812, or may be protected by an IDS 924 having a security monitor 922. In such cases, the cryptographic engine 908 of the intermediate node 902 may decrypt the timestamp carried by the heartbeat vector 710 and analyze it for desynchronization attacks indicating a desynchronization event. An alarm generator similar to the alarm generator 814 may be used to generate alarms, report events, and take corrective security actions.

[0114] In other embodiments, the intermediate node 902 does not implement the security monitor 922, or does not have access to the security monitor 922. In such cases, the intermediate node 902 may not be able to decrypt or read the timestamp carried by the heartbeat vector 710.

[0115] Fig. 10A The diagram shows a benign operating environment 1000a for TSN 618. Fig. 10A As depicted, speaker node 1002 transmits data stream 1032 to relay node 1004. Data stream 1032 includes low priority traffic 1008 and low priority traffic 1012 interleaved with high priority heartbeat messages 1010. Relay node 1004 transmits data stream 1034 to listener node 1006. Data stream 1032 includes low priority traffic 1014 and low priority traffic 1016 interleaved with high priority heartbeat messages 1010.

[0116] The heartbeat message 1010 includes a heartbeat vector 1030. The speaker node 1002, the relay node 1004, and the listener node 1006 add timestamps of key events to the heartbeat vector 1030 when traversing the TSN 618. For example, the speaker node 1002 adds a transmit hardware timestamp 1024 of 64.52 μs, the relay node 1004 adds a receive hardware timestamp 1018 of 76.92 μs and a transmit hardware timestamp 1020 of 100.39 μs, and the listener node 1006 adds a receive hardware timestamp 1022 of 101.23 μs. If the heartbeat vector 1030 is vector type 1, the heartbeat vector 1030 includes a timestamp set <64.52, 76.92, 100.39, 101.23>. If the heartbeat vector 1030 is of vector type 2, the heartbeat vector 1030 includes a timestamp set <64.52, 101.23>. If the heartbeat vector 1030 is of vector type 3, the heartbeat vector 1030 includes a timestamp set <64.52, 76.92>, <100.39, 101.23>.

[0117] The IDS 1038 may retrieve and analyze the heartbeat vectors 1030 to detect any time anomalies that may indicate a desynchronization attack that may result in a desynchronization event against the TSN 618. The security monitor 1036 of the IDS 1038 compares the timestamps from the heartbeat vectors 1030 and compares the actual time difference against the expected time difference. The security monitor 1036 implements a machine learning classifier that is trained on training data collected when the TSN 618 is operating in a benign operating environment 1000a to obtain the expected time difference.

[0118] Since the benign operating environment 1000a is not under a desynchronization attack, the machine learning classifier implemented for the security monitor 1036 of the IDS 1038 analyzes the heartbeat vector 1030 of vector type 1, vector type 2, or vector type 3, and performs an inference operation to classify the actual time interval between a pair of sequential timestamps as benign or within the expected time interval. Assuming benign operating conditions of the TSN 618, a set of expected time differences for the transmission hardware time is obtained for the speaker node 1002, as shown in Table 1.

[0119] Table 1

[0120] Assuming a benign operating condition of TSN 618, a set of expected time differences for the receiving hardware time is obtained for the listener node 1006, as shown in Table 2.

[0121] Table 2

[0122] Given the averages in Tables 1 and 2, the monitor 1036 calculates the expected time difference between the transmission of the heartbeat message 1010 from the speaker node 1002 and the reception of the heartbeat message 1010 by the listener node 1006 as 101.189255μs-64.521284μs=36.67μs. If the heartbeat vector 1030 is vector type 2, the heartbeat vector 1030 includes a timestamp set <64.52, 101.23>. The security monitor 1036 calculates the actual time difference as 101.23μs-64.52μs=36.71μs. The security monitor 1036 compares the actual time difference 36.71μs with the expected time difference 36.67μs to find a difference of 36.71μs-36.67μs=0.04μs. Assume that the security monitor 1036 sets the defined threshold to 0.05 μs as evidence of a desynchronization attack. The security monitor 1036 compares the difference of 0.04 μs to the defined threshold of 0.05 μs and determines that the difference is less than the defined threshold (0.04 μs < 0.05 μs). In this example, the security monitor 1036 classifies the time difference as benign or within normal operating parameters.

[0123] Fig. 10B The diagram illustrates an attack operating environment 1000b of TSN 618. The attack operating environment 1000b illustrates a situation in which an attacker 1026 launches a desynchronization attack on a relay node 1004. The desynchronization attack adds 0.5 μs to the transmit hardware timestamp 1020 and the receive hardware timestamp 1022. Therefore, if the heartbeat vector 1030 is a vector type 1, the heartbeat vector 1030 includes a timestamp set <64.52, 76.92, 100.89, 101.73>. If the heartbeat vector 1030 is a vector type 2, the heartbeat vector 1030 includes a timestamp set <64.52, 101.73>. If the heartbeat vector 1030 is a vector type 3, the heartbeat vector 1030 includes a timestamp set <64.52, 76.92>, <100.39, 100.73>.

[0124] Since the attack operating environment 1000b is under a desynchronization attack, the machine learning classifier implemented for the security monitor of the IDS analyzes the heartbeat vector 1030 of vector type 1, vector type 2, or vector type 3, and classifies the actual time interval between a pair of sequential timestamps as malicious or exceeding the expected time interval by a threshold amount. Starting from the first position in the timestamp set carried by the heartbeat vector 1030, the timestamp pair may include two timestamps in sequence within the timestamp set without reusing any timestamp.

[0125] Given the averages in Tables 1 and 2, the monitor 1036 calculates the expected time difference between the transmission of the heartbeat message 1010 from the speaker node 1002 and the reception of the heartbeat message 1010 by the listener node 1006 as 101.189255μs-64.521284μs=36.67μs. If the heartbeat vector 1030 is vector type 2, the heartbeat vector 1030 now includes the timestamp set <64.52, 101.73> because the desynchronization attack has added 0.05μs of latency to the heartbeat message 1010, which is captured by the receiving hardware timestamp 1022. The security monitor 1036 calculates the actual time difference as 101.73μs-64.52μs=37.21μs. The security monitor 1036 compares the actual time difference 37.21μs with the expected time difference 36.67μs to find the difference 37.21μs-36.67μs=0.54μs. Assume that the security monitor 1036 sets the defined threshold to 0.05μs as evidence of a desynchronization attack. The security monitor 1036 compares the difference 0.54μs with the defined threshold 0.05μs and determines that the difference is greater than the defined threshold (0.54μs>0.05μs). In this example, the security monitor 1036 classifies the time difference as malicious or beyond normal operating parameters. The security monitor 1036 generates a security alert and takes corrective security actions according to the security policy of TSN 618.

[0126] The security monitor 1036 detects desynchronization attacks and can also quantify the amount of delay introduced by the desynchronization attack, as shown in the previous example above. In addition, the security monitor 1036 can also use positioning 1028 to locate the desynchronization attack. For example, if the heartbeat vector 1030 is a vector type 1, then under benign operating conditions, the heartbeat vector 1030 includes a timestamp set <64.52, 76.92, 100.39, 101.23>. A desynchronization attack on the relay node 1004 produces a different timestamp set <64.52, 76.92, 100.89, 101.73>. The security monitor 1036 compares the two different sets of timestamps and notes that the timestamp <64.52, 76.92> for the link between the speaker node 1002 and the relay node 1004 is within the normal operating parameters, while the timestamp <100.89, 101.73> for the link between the relay node 1004 and the listener node 1006 falls outside the normal operating parameters. The security monitor 1036 locates the desynchronization attack to the relay node 1004 based on this information. In some embodiments, the security monitor 1036 may have sufficient sensitivity to detect desynchronization attacks of 802.1AS drifts on the order of tens of microseconds. The operation of the disclosed embodiments may be further described with reference to the following figures. Some figures may include logic flows. Although such figures given herein may include specific logic flows, it is understood that the logic flows merely provide examples of how the general functions described herein are implemented. In addition, unless otherwise stated, a given logic flow does not necessarily have to be executed in the order presented. In addition, in some embodiments, not all behaviors illustrated in the logic flow may be necessary. Furthermore, a given logic flow may be implemented by hardware elements, software executed by a processor, or any combination thereof.The embodiments are not limited in this context.

[0127] Fig.11 The diagram illustrates an embodiment of a logic flow 1100. The logic flow 1100 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 1100 may include some or all of the operations performed by devices or entities within the TSN 102, 200, 300, 618, TSN nodes 104, IDS 110, device 400, device 500, and / or systems 800 and 900. More specifically, the logic flow 1100 illustrates an example in which a listener node 806 receives a data stream 830 that transmits diagnostic information in the form of time information for one or more TSN nodes 104, and the listener node 806 analyzes the diagnostic information to determine whether the one or more TSN nodes 104 are under a security attack based on the analysis.

[0128] Logic flow 1100 includes a block 1102 including the following operations: receiving a heartbeat message by an intrusion detection system (IDS) in a time sensitive network (TSN), the heartbeat message including a heartbeat vector and a message authentication code (MAC), the heartbeat vector including a set of immutable values, wherein each immutable value represents a timestamp associated with a network node in the TSN. Logic flow 1100 includes a block 1104 including the following operations: authenticating the heartbeat vector based on the message authentication code. Logic flow 1100 includes a block 1106 including the following operations: retrieving a timestamp pair from the heartbeat vector. Logic flow 1100 includes a block 1108 including the following operations: determining an actual time difference based on the timestamp pair. Logic flow 1100 includes a block 1110 including the following operations: retrieving an expected time difference associated with the timestamp pair, and detecting a desynchronization event for the TSN based on the actual time difference and the expected time difference.

[0129] For example, a monitor 1036 of an IDS 1038 receives a heartbeat message 1010 in a TSN 618. The heartbeat message 1010 includes a heartbeat vector 1030 and a MAC 712. The heartbeat vector 1030 includes a set of immutable values, each of which represents a timestamp associated with a network node in the TSN 618, such as a transmit hardware timestamp 1024, a receive hardware timestamp 1018, a transmit hardware timestamp 1020, and a receive hardware timestamp 1022. The IDS 1038 includes a cryptographic engine 816 for authenticating the heartbeat vector 1030 based on the MAC 712. The monitor 1036 retrieves a timestamp pair from the heartbeat vector 1030, such as <64.52, 101.73>. The monitor 1036 determines an actual time difference based on the timestamp pair, such as 101.73 μs-64.52 μs=37.21 μs. Monitor 1036 retrieves the expected time difference associated with the timestamp pair, such as 101.189255μs-64.521284μs=36.67μs. Monitor 1036 detects a desynchronization event for TSN based on the actual time difference and the expected time difference. Security monitor 1036 compares the actual time difference 37.21μs with the expected time difference 36.67μs to find the difference 37.21μs-36.67μs=0.54μs. Assume that security monitor 1036 sets the defined threshold to 0.05μs as evidence of a desynchronization attack. Security monitor 1036 compares the difference 0.54μs with the defined threshold 0.05μs and determines that the difference is greater than the defined threshold (0.54μs>0.05μs). In this example, security monitor 1036 classifies the time difference as malicious or outside normal operating parameters. The safety monitor 1036 generates safety alerts and takes corrective safety actions according to the safety policy of the TSN 618.

[0130] The logic flow 1100 may also include further operations. As an example and not limitation, the logic flow 1100 of any of the previous examples may further include: receiving a heartbeat message by the IDS at a defined time interval and at a frequency greater than the synchronization interval of the network nodes in the TSN. The logic flow 1100 of any of the previous examples may further include: receiving a heartbeat message with an identifier for identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission through the TSN. The logic flow 1100 of any of the previous examples may further include: using a machine learning model to detect a desynchronization event for the network node. The logic flow 1100 of any of the previous examples may further include: determining a desynchronization time interval between an actual time difference and an expected time difference, receiving the desynchronization time interval as an input to a machine learning classifier, and classifying the desynchronization time interval by the machine learning classifier as indicating a desynchronization event. The logic flow 1100 of any of the previous examples may further include: detecting a desynchronization event for the TSN when the desynchronization time interval between the actual time difference and the expected time difference is greater than 12.5 microseconds. The logic flow 1100 of any of the previous examples may further include: wherein each timestamp represents a timestamp associated with a transmitter hardware, a transmitter wakeup, a transmitter program, a transmitter kernel network scheduler, a transmitter kernel hardware, a receiver hardware, or a receiver program, or any other timestamp associated with an event when a speaker / listener exchanges heartbeats. It is understood that there are other timestamps associated with handling send / receive timestamps, and embodiments are not limited to these examples. For example, there are also timestamps associated with moving a receiver timestamp from a network card to a receiver kernel. Embodiments are not limited to this context.

[0131] The logic flow 1100 of any of the preceding examples may further include: wherein the timestamp pair includes a first timestamp and a second timestamp, the first timestamp indicating a transmission time for the first network node, and the second timestamp indicating a reception time for the second network node. The logic flow 1100 of any of the preceding examples may further include: locating a desynchronization event to a network node in the TSN based on a position of each timestamp in the timestamp pair in the set of immutable values. The logic flow 1100 of any of the preceding examples may further include: generating a security alert or a security action in response to detection of the desynchronization event.

[0132] Fig.12 An exemplary heartbeat message structure 1200 suitable for a heartbeat message as described herein, such as heartbeat message 1010, is shown. Fig.12As depicted, the heartbeat message structure 1200 has three information fields. The first information field is used for the node identifier 1202, and its length is 8 bits. The second information field is used for the sequence number 1204, and its length is 232 bits. The third information field is used for the authentication code 1206 (e.g., MAC 712), and its length is 128 bits. The combined total length of these three information fields is 368 bits. It will be appreciated that the number of fields and length of each field are given as examples rather than limitations, and different numbers of fields and field lengths may be used for a given implementation. The embodiments are not limited to this context.

[0133] Each heartbeat message 1010 is generated to be unique, bound to the TSN node 104, and unforgeable using a cryptographic algorithm. In one embodiment, for example, a pair of cryptographic keys 1214 are shared between the TSN node 104 and a security monitor (such as the monitor 812). The cryptographic key 1214 is used as a first input to a keyed hash algorithm. The count value from the counter 1208 is used as a second input to the keyed hash algorithm. The keyed hash algorithm receives two inputs and outputs a keyed hash 1210. The keyed hash 1210 binds the node identifier 1202 and the sequence number 1204 of the TSN node 104. The monitor 812 can use the keyed hash 1210 to authenticate and verify each heartbeat message 1010.

[0134] Some embodiments may avoid exhausting the count of heartbeat message numbers by changing cryptographic keys periodically, aperiodically, or on demand. This may prevent a situation where a TSN node 104 or TSN 102 runs out of sequence numbers. Cryptographic keys are modified periodically following well-known specifications, such as those from the National Institute of Standards and Technology (NIST). A rekeying operation may also be triggered when the system potentially runs out of sequence numbers.

[0135] Embodiments are specifically designed to protect the TSN 102 from an attacker 1026 attempting to compromise one or more TSN nodes 104 from multiple attack vectors. For example, assume that the attacker 1026 attempts to inject new packets into the TSN 618. In this case, the attacker 1026 cannot forge the heartbeat message 1010 because any forged heartbeat message will be detected via the cryptographic scheme used by the TSN node 104 and the monitor 812.

[0136] Fig.13ADevice 1316 is depicted. Device 1316 may be any of TSN nodes 104 in a TSN network. Device 1316 includes processing circuitry 1302, clock 1304, memory 1306, radio circuitry 1308, antenna 1310, network interface circuitry 1318, and wired connection 1320. Memory 1306 stores instructions 1312 and heartbeat instructions 1314. During operation, processing circuitry 1302 may execute instructions 1312 and / or heartbeat instructions 1314 to cause device 1316 to issue, consume, analyze, and monitor data stream 830 carrying heartbeat messages 1010 from other devices in the TSN network. In some examples, processing circuitry 1302 may execute instructions 1312 and / or heartbeat instructions 1314 to cause device 1316 to operate as a clock leader (CL) of the TSN network, such as sending time synchronization messages, time update messages, and other timing messages defined by the various IEEE standards discussed herein. In addition, the processing circuit 1302 may execute instructions 1312 to cause the device 1316 to send a timing message as a CL for a CF in the TSN network via the radio circuit system 1308 and the antenna 1310 or the network interface circuit system 1318. In addition, the processing circuit 1302 may execute instructions 1312 to cause the device 1316 to send a heartbeat message and / or a security message, such as an alarm message, a notification message, a network reconfiguration message, a device isolation message, a model update message, and other messages in the TSN network via the radio circuit system 1308 and the antenna 1310 or the network interface circuit system 1318 in response to a security attack.

[0137] Fig. 13BDevice 1336 is depicted. Device 1336 may be any of the TSN nodes 104 in the TSN network. Device 1336 includes processing circuitry 1322, clock 1324, memory 1326, radio circuitry 1328, antenna 1330, network interface circuitry 1338, and wired connection 1340. Memory 1326 stores instructions 1332 and heartbeat instructions 1334. During operation, processing circuitry 1322 may execute instructions 1332 and / or heartbeat instructions 1334 to cause device 1336 to issue, consume, analyze, and monitor data stream 830 carrying heartbeat messages 1010 to other devices in the TSN network. In some examples, processing circuit 1322 may execute instructions 1332 and / or heartbeat instructions 1334 to operate as a clock follower (CF) for a TSN network, such as receiving timing messages (e.g., based on time measurements from a global clock of the TSN network) from other devices in the TSN network (e.g., device 1316) as a clock follower. In some examples, processing circuit 1322 may execute instructions 1332 and / or heartbeat instructions 1334 to cause device 1336 to receive time synchronization messages, time update messages, and other timing messages defined by the various IEEE standards discussed herein. In addition, processing circuit 1322 may execute instructions 1332 and / or heartbeat instructions 1334 to cause device 1336 to receive timing messages via radio circuit system 1328 and antenna 1330 or network interface circuit system 1338 as a CF for a CL in a TSN network. In addition, the processing circuit 1322 can execute instructions 1332 and / or heartbeat instructions 1334 to cause the device 1336 to send heartbeat messages and security messages such as alarm messages, notification messages, network reconfiguration messages, device isolation messages, model update messages, and other messages in the TSN network via the radio circuit system 1328 and the antenna 1330 or the network interface circuit system 1338 in response to a security attack.

[0138] Fig.14The figure shows a computer-readable storage computer-readable medium 1400. The computer-readable storage computer-readable medium 1400 may include any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical storage medium, a magnetic storage medium, or a semiconductor storage medium. In various embodiments, the computer-readable storage computer-readable medium 1400 may include an article of manufacture. In some embodiments, the computer-readable storage computer-readable medium 1400 may store computer-executable instructions 1402, which the circuit system (e.g., processing circuit system 414, processor circuit system 818, processor circuit system 824, processing circuit 1302, processing circuit 1322, radio circuit system 1308, radio circuit system 1328, network interface circuit system 1318, network interface circuit system 1338, clock manager 106, clock circuit system 412, interface 822, interface 828, etc.) may utilize to execute. For example, the computer-executable instructions 1402 may include instructions for implementing the operations described with reference to the logic flow 1100. Examples of computer-readable storage computer-readable media 1400 or machine-readable storage media may include any tangible media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of computer-executable instructions 1402 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc.

[0139] As previously described with reference to the accompanying drawings, various elements of the device include various hardware elements, software elements, or a combination of the two. Examples of hardware elements include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements include software components, programs, applications, computer programs, applications, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether to use hardware elements and / or software elements to implement an embodiment varies depending on any number of factors, such as, for example, the required computing rate, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints desired for a given implementation.

[0140] One or more aspects of at least one embodiment are implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, which, when read by a machine, causes the machine to manufacture logic for performing the technology described herein. Such representations, referred to as "intellectual property (IP) cores", are stored on tangible machine-readable media and can be supplied to various customers or production facilities to be loaded into manufacturing machines that manufacture the logic or processor. Some embodiments are implemented, for example, using machine-readable media or articles that can store instructions or instruction sets, which, when executed by a machine, cause the machine to perform methods and / or operations according to an embodiment. Such machines include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, processing device, computer, processor, etc., and are implemented using any suitable combination of hardware and / or software. The machine-readable medium or article includes, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable medium, erasable or non-erasable medium, writable or rewritable medium, digital or analog medium, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory card or disk, various types of digital versatile disks (DVD), magnetic tape, cassette, etc. The instructions include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0141] As used herein, the terms "component", "system", "interface", etc. are intended to refer to computer-related entities, hardware, software (e.g., when executed), and / or firmware. For example, a component is a processor (e.g., a microprocessor, a controller, or other processing device), a process running on a processor, a controller, an object, an executable, a program, a storage device, a computer, a tablet PC, and / or a user equipment with a processing device (e.g., a mobile phone, etc.). As an illustration, an application running on a server and the server are also components. One or more components reside within a process, and a component is located on one computer and / or distributed between two or more computers. A collection of elements or other components is described herein, where the term "collection" can be interpreted as "one or more".

[0142] Further, these components execute from various computer-readable storage media having various data structures stored thereon (e.g., using modules). These components communicate via local and / or remote processes, such as according to signals having one or more data packets (e.g., data from one component interacts with another component in a local system, a distributed system, and / or across a network (such as the Internet, a local area network, a wide area network, or a similar network connected to other systems via signals)).

[0143] As another example, a component is a device having a specific functionality provided by mechanical parts operated by electrical or electronic circuitry, where the electrical or electronic circuitry is operated by a software application or firmware application executed by one or more processors. The one or more processors are internal or external to the device and execute at least a portion of the software or firmware application. As yet another example, a component is a device that provides a specific functionality by electronic components without mechanical parts; the electronic component includes one or more processors therein to execute the software and / or firmware that at least partially imparts the functionality of the electronic component.

[0144] The use of the word "exemplary" is intended to present concepts in a concrete manner. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X employs A or B" is intended to mean any of the natural inclusive arrangements. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied in any of the above cases. In addition, the articles "a / an" as used in this application and the appended claims should generally be interpreted to mean "one or more" unless otherwise specified or clear from the context to refer to the singular form. In addition, in the sense that the terms "including", "includes", "having", "has", "with" or variations thereof are used in the specific embodiments or claims, these terms are intended to be inclusive in a manner similar to the term "comprising". In addition, when discussing one or more numbered items (e.g., "first X," "second X," etc.), generally speaking, the one or more numbered items may be different or they may be the same, but in some cases, the context may dictate that they are different or the same.

[0145] As used herein, the term "circuitry" may refer to, be part of, or include a circuit, an integrated circuit (IC), a monolithic IC, a discrete circuit, a hybrid integrated circuit (HIC), an application-specific integrated circuit (ASIC), an electronic circuit, a logic circuit, a microcircuit, a hybrid circuit, a microchip, a chip, a chiplet, a chipset, a multi-chip module (MCM), a semiconductor die, a system on a chip (SoC), a processor (shared, dedicated, or group), a processor circuit, a processing circuit, or an associated memory (shared, dedicated, or group) operably coupled to a circuitry that executes one or more software or firmware programs, a combinational logic circuit, or other suitable hardware components that provide the described functions. In some embodiments, the circuitry is implemented using one or more software or firmware modules, or the functions associated with the circuitry are implemented by one or more software or firmware modules. In some embodiments, the circuitry includes logic that is at least partially operable in hardware. Note that hardware, firmware, and / or software elements may be collectively or individually referred to as "logic," "circuitry" herein.

[0146] Some embodiments are described using the expressions "one embodiment" or "an embodiment" and their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" at different locations in this specification does not necessarily all refer to the same embodiment. In addition, unless otherwise stated, the above-mentioned features are considered to be usable together in any combination. Therefore, any features discussed separately can be used in combination with each other, unless it is mentioned that these features are incompatible with each other.

[0147] Some embodiments are presented in terms of program processes executed on a computer or computer network. A process is generally understood here as a self-consistent sequence of operations that results in a desired result. These operations are those that require physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transmitted, combined, compared, and otherwise manipulated. Mainly for common purposes, it has proven to be convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc. However, it should be noted that all of these and similar terms are associated with appropriate physical quantities and are merely convenient notations applied to these quantities.

[0148] In addition, the manipulations performed are often referred to with terms such as addition or comparison, which are often associated with mental operations performed by a human operator. In most cases, such capabilities of a human operator are not necessary or desirable in any of the operations described herein that form part of one or more embodiments. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include general-purpose digital computers or similar devices.

[0149] Some embodiments are described using the expressions "coupled" and "connected," and their derivatives. These terms are not necessarily intended to be synonymous with each other. For example, some embodiments are described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" also means that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0150] Embodiments also relate to devices or systems for performing these operations. The device is specifically configured for the desired purpose, or it includes a general-purpose computer that is selectively activated or reconfigured by a computer program stored in the computer. The processes presented herein are not inherently related to a particular computer or other device. It may be convenient to use various general-purpose machines with programs written according to the teachings herein, or to prove to construct more specialized devices to perform the required method steps. The required structure of various such machines is apparent from the given description.

[0151] It should be emphasized that the description abstract is provided to allow the reader to quickly understand the nature of the present technology disclosure. The abstract is submitted with the understanding that the abstract will not be used to interpret or limit the scope or meaning of the claims. Therefore, the appended claims are thus incorporated into the specific implementation method, wherein each claim independently becomes a separate embodiment. In the appended claims, the terms "including" and "wherein" are used as the concise English equivalents of the corresponding terms "including" and "wherein", respectively. In addition, the terms "first", "second", "third", etc. are used only as marks and are not intended to impose numerical requirements on their objects.

[0152] The following examples relate to further embodiments, from which numerous arrangements and configurations will be apparent.

[0153] In one example, a method may include: receiving a heartbeat message by an intrusion detection system (IDS) in a time sensitive network (TSN), the heartbeat message including a heartbeat vector and a message authentication code (MAC), the heartbeat vector including a set of immutable values, each of which represents a timestamp associated with a network node in the TSN; authenticating the heartbeat vector based on the message authentication code; retrieving a timestamp pair from the heartbeat vector; determining an actual time difference based on the timestamp pair; retrieving an expected time difference associated with the timestamp pair; and detecting a desynchronization event for the TSN based on the actual time difference and the expected time difference.

[0154] The method of any of the preceding examples may include receiving, by the IDS, a heartbeat message at a defined time interval, the defined time interval being less than a synchronization interval of network nodes in the TSN.

[0155] The method of any of the preceding examples may include receiving a heartbeat message having an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

[0156] The method of any of the preceding examples may include using a machine learning model to detect a desynchronization event for a network node.

[0157] The method of any of the preceding examples may include determining a desynchronization time interval between an actual time difference and an expected time difference, receiving the desynchronization time interval as an input to a machine learning classifier, and classifying the desynchronization time interval as indicating a desynchronization event via the machine learning classifier.

[0158] The method of any of the preceding examples may include detecting a desynchronization event for the TSN when a desynchronization time interval between an actual time difference and an expected time difference is greater than 12.5 microseconds.

[0159] The method of any of the preceding examples may also include: wherein each timestamp represents a timestamp associated with a transmitter hardware, a transmitter wakeup, a transmitter program, a transmitter kernel network scheduler, a transmitter kernel hardware, a receiver hardware, or a receiver program.

[0160] The method of any preceding example may further include: wherein the timestamp pair comprises a first timestamp and a second timestamp, the first timestamp being used to indicate a transmission time to the first network node and the second timestamp indicating a reception time to the second network node.

[0161] The method of any of the preceding examples may include locating a desynchronization event to a network node in the TSN based on a position of each timestamp in a timestamp pair in the set of immutable values.

[0162] The method of any of the preceding examples may include generating a security alert or a security action in response to detecting a desynchronization event.

[0163] In one example, a computing device may include a processing circuit system. The computing device may include a memory storing instructions that, when executed by the processing circuit system, cause the processing circuit system to: receive a heartbeat message through an intrusion detection system (IDS) in a time-sensitive network (TSN), the heartbeat message including a heartbeat vector and a message authentication code (MAC), the heartbeat vector including a set of immutable values, each of which represents a timestamp associated with a network node in the TSN; authenticate the heartbeat vector based on the message authentication code; retrieve a timestamp pair from the heartbeat vector; determine an actual time difference based on the timestamp pair; retrieve an expected time difference associated with the timestamp pair; and detect a desynchronization event for the TSN based on the actual time difference and the expected time difference.

[0164] The computing device of any of the preceding examples, the processing circuit system being configured to receive, via the IDS, heartbeat messages at defined time intervals that are less than a synchronization interval of network nodes in the TSN.

[0165] The computing device of any of the preceding examples, the processing circuitry receiving a heartbeat message having an identifier for identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

[0166] The computing device of any of the preceding examples, wherein the processing circuit system is used to use a machine learning model to detect desynchronization events for a network node.

[0167] The computing device of any of the preceding examples, wherein the processing circuit system is used to: determine a desynchronization time interval between an actual time difference and an expected time difference, receive the desynchronization time interval as an input to a machine learning classifier, and classify the desynchronization time interval as indicating a desynchronization event via the machine learning classifier.

[0168] The computing device of any of the preceding examples, the processing circuit system being configured to detect a desynchronization event for the TSN when a desynchronization time interval between the actual time difference and the expected time difference is greater than 12.5 microseconds.

[0169] The computing device of any of the preceding examples may also include: wherein each timestamp represents a timestamp associated with a transmitter hardware, a transmitter wakeup, a transmitter program, a transmitter kernel network scheduler, a transmitter kernel hardware, a receiver hardware, or a receiver program.

[0170] The computing device of any preceding example may further include: wherein the timestamp pair includes a first timestamp and a second timestamp, the first timestamp indicating a transmission time for the first network node and the second timestamp indicating a reception time for the second network node.

[0171] The computing device of any of the preceding examples, the processing circuit system being configured to: locate a desynchronization event to a network node in the TSN based on a position of each timestamp in a timestamp pair in the set of immutable values.

[0172] Any computing device of the above examples, the processing circuit system is used to generate a security alert or security action in response to the detection of a desynchronization event. Other technical features may be readily apparent to those skilled in the art from the following drawings, description and claims.

[0173] In one example, a non-transitory computer-readable storage medium includes instructions that, when executed by a computer, cause the computer to: receive a heartbeat message through an intrusion detection system (IDS) in a time-sensitive network (TSN), the heartbeat message including a heartbeat vector and a message authentication code (MAC), the heartbeat vector including a set of immutable values, each of which represents a timestamp associated with a network node in the TSN; authenticate the heartbeat vector based on the message authentication code; retrieve a timestamp pair from the heartbeat vector; determine an actual time difference based on the timestamp pair; retrieve an expected time difference associated with the timestamp pair; and detect a desynchronization event for the TSN based on the actual time difference and the expected time difference.

[0174] The computer-readable storage medium of any preceding example may include instructions for receiving, by the IDS, heartbeat messages at defined time intervals that are less than a synchronization interval of network nodes in the TSN.

[0175] The computer-readable storage medium of any preceding example may include instructions for receiving a heartbeat message having an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

[0176] The computer-readable storage medium of any preceding example may include instructions for using a machine learning model to detect a desynchronization event for a network node.

[0177] The computer-readable storage medium of any of the preceding examples may include instructions for determining a desynchronization time interval between an actual time difference and an expected time difference, receiving the desynchronization time interval as input to a machine learning classifier, and classifying the desynchronization time interval as indicating a desynchronization event via the machine learning classifier.

[0178] The computer readable storage medium of any preceding example may include instructions for detecting a desynchronization event for the TSN when a desynchronization time interval between an actual time difference and an expected time difference is greater than 12.5 microseconds.

[0179] The computer-readable storage medium of any preceding example may further include: wherein each timestamp represents a timestamp associated with a transmitter hardware, a transmitter wakeup, a transmitter program, a transmitter kernel network scheduler, a transmitter kernel hardware, a receiver hardware, or a receiver program.

[0180] The computer-readable storage medium of any preceding example may further include: wherein the timestamp pair includes a first timestamp and a second timestamp, the first timestamp indicating a transmission time for the first network node and the second timestamp indicating a reception time for the second network node.

[0181] The computer-readable storage medium of any preceding example may include instructions for locating a desynchronization event to a network node in the TSN based on a position of each timestamp in a timestamp pair in a set of immutable values.

[0182] The computer-readable storage medium of any of the preceding examples may include instructions for generating a security alert or a security action in response to detection of a desynchronization event.

[0183] It is understood that any of the above examples can be implemented as system and / or device plus function embodiments. The embodiments are not limited to these examples.

Claims

1. A method, comprising: Receiving a heartbeat message through an intrusion detection system IDS in a time-sensitive network TSN, wherein the heartbeat message includes a heartbeat vector and a message authentication code MAC, wherein the heartbeat vector includes a set of immutable values, wherein each immutable value represents a timestamp associated with a network node in the TSN; Authenticating the heartbeat vector based on the message authentication code; Retrieve a timestamp pair from the heartbeat vector; determining an actual time difference based on the timestamp pair; retrieving an expected time difference associated with the timestamp pair; as well as A desynchronization event for the TSN is detected based on the actual time difference and the expected time difference.

2. The method of claim 1, comprising: The heartbeat message is received by the IDS at a defined time interval, where the defined time interval is greater than a synchronization interval of network nodes in the TSN.

3. The method of claim 1, comprising receiving the heartbeat message with an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

4. The method of claim 1, comprising: A machine learning model is used to detect the desynchronization event for the network node.

5. The method of claim 1, comprising: determining a desynchronization time interval between the actual time difference and the expected time difference; receiving the desynchronization time interval as an input to a machine learning classifier; as well as The desynchronization time interval is classified by the machine learning classifier as indicating the desynchronization event.

6. The method of claim 1, comprising: The desynchronization event for the TSN is detected when the desynchronization time interval between the actual time difference and the expected time difference is greater than a defined threshold.

7. The method of claim 1, wherein: Each timestamp represents a timestamp associated with a transmitter hardware, a transmitter wakeup, a transmitter program, a transmitter kernel network scheduler, a transmitter kernel hardware, a receiver hardware, or a receiver program.

8. The method of any one of claims 1 to 7, comprising generating a security alert or a security action in response to detection of the desynchronization event.

9. A computing device comprising: Processing circuit system; as well as a memory storing instructions that, when executed by the processing circuitry, cause the processing circuitry to: Receiving a heartbeat message through an intrusion detection system IDS in a time-sensitive network TSN, wherein the heartbeat message includes a heartbeat vector and a message authentication code MAC, wherein the heartbeat vector includes a set of immutable values, wherein each immutable value represents a timestamp associated with a network node in the TSN; Authenticating the heartbeat vector based on the message authentication code; Retrieve a timestamp pair from the heartbeat vector; determining an actual time difference based on the timestamp pair; retrieving an expected time difference associated with the timestamp pair; as well as A desynchronization event for the TSN is detected based on the actual time difference and the expected time difference.

10. The computing device of claim 9, the processing circuitry to receive the heartbeat message via the IDS at a defined time interval, the defined time interval being greater than a synchronization interval of network nodes in the TSN.

11. The computing device of claim 9, the processing circuitry to receive the heartbeat message with an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

12. The computing device of claim 9, the processing circuit system to use a machine learning model to detect the desynchronization event for the network node.

13. The computing device of claim 9, wherein the processing circuit system is configured to: determining a desynchronization time interval between the actual time difference and the expected time difference; receiving the desynchronization time interval as an input to a machine learning classifier; and The desynchronization time interval is classified by the machine learning classifier as indicating the desynchronization event.

14. The computing device of any one of claims 9-13, the processing circuit system to: detect the desynchronization event for the TSN when a desynchronization time interval between the actual time difference and the expected time difference is greater than a defined threshold.

15. A non-transitory computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to: Receiving a heartbeat message through an intrusion detection system IDS in a time-sensitive network TSN, wherein the heartbeat message includes a heartbeat vector and a message authentication code MAC, wherein the heartbeat vector includes a set of immutable values, wherein each immutable value represents a timestamp associated with a network node in the TSN; Authenticating the heartbeat vector based on the message authentication code; Retrieve a timestamp pair from the heartbeat vector; determining an actual time difference based on the timestamp pair; retrieving an expected time difference associated with the timestamp pair; as well as A desynchronization event for the TSN is detected based on the actual time difference and the expected time difference.

16. The computer-readable storage medium of claim 15, comprising instructions for receiving the heartbeat message by the IDS at a defined time interval, the defined time interval being greater than a synchronization interval of network nodes in the TSN.

17. The computer-readable storage medium of claim 15, comprising instructions for receiving the heartbeat message with an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

18. The computer-readable storage medium of claim 15, comprising instructions for using a machine learning model to detect the desynchronization event for the network node.

19. The computer-readable storage medium of claim 15, comprising instructions for: determining a desynchronization time interval between the actual time difference and the expected time difference; receiving the desynchronization time interval as an input to a machine learning classifier; and The desynchronization time interval is classified by the machine learning classifier as indicating the desynchronization event.

20. The computer-readable storage medium of any one of claims 15 to 19, comprising instructions for detecting the desynchronization event for the TSN when a desynchronization time interval between the actual time difference and the expected time difference is greater than a defined threshold.

21. A device, comprising: A device for receiving a heartbeat message through an intrusion detection system IDS in a time sensitive network TSN, wherein the heartbeat message includes a heartbeat vector and a message authentication code MAC, wherein the heartbeat vector includes a set of immutable values, wherein each immutable value represents a timestamp associated with a network node in the TSN; means for authenticating the heartbeat vector based on the message authentication code; means for retrieving a timestamp pair from said heartbeat vector; means for determining an actual time difference based on the time stamp pair; means for retrieving an expected time difference associated with the timestamp pair; as well as Means for detecting a desynchronization event for the TSN based on the actual time difference and the expected time difference.

22. The apparatus of claim 21, comprising means for receiving the heartbeat message by the IDS at a defined time interval, the defined time interval being greater than a synchronization interval of network nodes in the TSN.

23. The apparatus of claim 21, comprising means for receiving the heartbeat message with an identifier identifying a priority level of the heartbeat message, the priority level indicating a highest priority level for transmission over the TSN.

24. The apparatus of claim 21, comprising means for detecting the desynchronization event for the network node using a machine learning model.

25. Apparatus as claimed in any one of claims 21 to 24, comprising: means for determining a desynchronization time interval between said actual time difference and said expected time difference; means for receiving said desynchronization time interval as input to a machine learning classifier; as well as Means for classifying, by the machine learning classifier, the desynchronization time interval as indicative of the desynchronization event.

Images