Multi-state messaging anomaly detection for securing broadcast networks

JP7631299B2Active Publication Date: 2025-02-18BATTELLE MEMORIAL INST
View PDF 10 Cites 0 Cited by

Patent Information

Application Number
JP2022504152
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2019-07-25
Filing Date
2020-07-22
Publication Date
2025-02-18
Estimated Expiration
2040-07-22

Smart Images

  • Figure 0007631299000002
    Figure 0007631299000002
  • Figure 0007631299000003
    Figure 0007631299000003
  • Figure 0007631299000004
    Figure 0007631299000004
Patent Text Reader

Abstract

An electronic device connectable to a CAN bus or other broadcast network is disclosed. The electronic device is programmed to calculate expected periodicity and periodic variability metrics for a historical accumulation of messages for different message headers, identify periodic message headers based on the periodic variability metrics, detect a time anomaly as a deviation of a period of a most recent set of two or more messages with the periodic message header from an expected periodicity for the periodic message header, and generate an alert indicating the detected time anomaly. The electronic device may further be programmed to maintain a state machine for a vehicle (or other platform) including the CAN bus and perform state-aware anomaly detection.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 878,432, filed July 25, 2019, and entitled “MULTI-STATE MESSENGING ANOMALY DETECTION FOR SECURING A BROADCAST NETWORK,” which is incorporated by reference in its entirety.

[0002] The following relate to broadcast network security technologies, controller area network (CAN) bus security alternative technologies, electronic control unit (ECU) security technologies, ground vehicle electronic security technologies, water vehicle electronic security technologies, space vehicle electronic security technologies, ECU trust / assurance technologies, industrial control system networks, and the like. [Background technology]

[0003] (background) Modern vehicles employ modularized electronic components such as anti-brake system (ABS) modules, engine control modules, and modules for controlling steering, throttle, cruise control, climate control systems, and various other vehicle functions. These modules communicate with each other using a CAN bus. Auxiliary systems such as vehicle entertainment systems, navigation systems, and the like also sometimes include ECUs that are connected to the CAN bus. The above examples are ground vehicles, however, water vehicles, space vehicles, e.g., satellites, and industrial control systems all employ such modularization and frequently utilize CAN bus architectures. A CAN bus is a type of broadcast network, i.e., a network in which all messages transmitted on the CAN bus are received by all ECUs on the CAN bus. More generally, a broadcast network is a network in which traffic on the network is received by all electronic devices on the network. In some embodiments, a broadcast network does not include authentication, whereby a receiving device may verify the source of a message, or confidentiality, whereby a sender may control which recipients may interpret the message. CAN bus traffic does not inherently include message authentication or confidentiality, and adding such capabilities is often impractical in terms of network data consumption, reliability, and efficiency.

[0004] Communication over the CAN bus at the application layer consists of an arbitration identifier (ARB ID) and up to eight data bytes. The ARB ID indicates the meaning of the data contained in the message. For example, the wheel speed may be contained on ARB ID 0x354 with two bytes of data representing the rotational speed of each of the four wheels. All ECUs on the vehicle that have the need to know the wheel speed are programmed to associate ARB ID 0x354 with the wheel speed. Furthermore, the ARB ID provides a convenient way to resolve collisions, i.e., situations where two ECUs attempt to transmit a message on the CAN bus at the same time. In such a situation, the ARB ID of the message defines the priority of the message, and the higher priority message is transmitted and the ECU attempting to transmit a lower priority message automatically retransmits after a predefined time delay. The broadcast nature of the CAN bus network advantageously allows for the ad-hoc addition of new electronic components. This is ideal for automobile manufacturers who sell vehicles in a variety of models with different features, as well as for aftermarket manufacturers supplying aftermarket sound systems (for example).

[0005] However, the broadcast nature of the CAN bus also introduces security challenges. Any ECU (or more generally, any electronic device on the CAN bus) may be connected to the CAN bus (or an ECU already connected to the CAN bus may be compromised) and may then transmit messages on the CAN bus that are received by all ECUs or other electronic devices on the CAN bus network. The messages do not include authentication to identify the sender in a secure manner. Thus, there is no barrier to a device being added to the network (or an existing device being compromised to be programmed) that is programmed to mimic legitimate transmissions by adopting the same ARB ID header and payload format used in legitimate transmissions, thereby conducting unauthorized, potentially malicious activity over the CAN bus. Such malicious activity may range from unauthorized collection of data to potentially life-threatening actions such as inducing dangerous throttle or braking actions.

[0006] No. 9,792,435 to Harris et al., issued on October 17, 2017 and entitled "Anomaly Detection for Vehicular Networks for Intrusion and Malfunction Detection," is incorporated herein by reference in its entirety. No. 10,083,071 to Sonalker et al., issued on September 25, 2018 and entitled "Temporal Anomaly Detection on Automotive Networks," is incorporated herein by reference in its entirety. These patents describe several approaches for detecting anomalous messaging on a CAN bus, thereby providing an alert of potentially malicious activity on the CAN bus.

[0007] Thus, certain improvements to the security and responsiveness of the CAN architecture are provided herein. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] U.S. Patent No. 9,792,435 [Patent Document 2] U.S. Patent No. 10,083,071 Summary of the Invention [Means for solving the problem]

[0009] (Brief summary) According to some illustrative embodiments disclosed herein, an electronic device is disclosed that is connectable to a network. Traffic on the network is received by all electronic devices on the network, and the network does not provide message authentication. A transmitted message comprises a payload and a message header that identifies the payload. The electronic device is programmed to calculate an expected periodicity and a periodic variability metric for a historical accumulation of messages for different message headers, identify a periodic message header based on the periodic variability metric, detect a time anomaly as a deviation of a periodicity of a most recent set of two or more messages with a periodic message header from an expected periodicity for the periodic message header, and generate an alert indicating the detected time anomaly.

[0010] According to some illustrative embodiments disclosed herein, an electronic device is disclosed that is connectable to a network, where traffic on the network is received by all electronic devices on the network, and the network does not provide message authentication. A transmitted message comprises a payload and a message header that identifies the payload. The electronic device includes an electronic processor and a non-transitory storage medium that stores time anomaly detection instructions that are readable and executable by the electronic processor to perform a time anomaly detection method. The time anomaly detection instructions include instructions readable and executable by the electronic processor to calculate expected periodicity and periodic variability metrics for a historical accumulation of messages for different message headers and identify a periodic message header based on the periodic variability metric, instructions readable and executable by the electronic processor to detect a time anomaly as a deviation of a periodicity of a most recent set of two or more messages with periodic message headers from an expected periodicity for the periodic message header, and instructions readable and executable by the electronic processor to generate an alert indicative of the detected time anomaly.

[0011] According to some example embodiments disclosed herein, an electronic device is disclosed that is connectable to a network, where traffic on the network is received by all electronic devices on the network, and where the network does not provide message authentication. The electronic device is programmed to maintain a state machine for the vehicle based on messages on the network and / or sensor data received from one or more sensors monitoring the platform, perform anomaly detection on messages on the network using at least one parameter value for a current state of the state machine, including generating an alert in response to detecting an anomaly, and update at least one parameter value for the new state in response to a transition from a current state of the state machine to a new state. [Brief description of the drawings]

[0012] Any quantitative dimensions shown in the drawings are to be understood as non-limiting illustrative examples. Unless otherwise indicated, the drawings are not to scale, and if any aspect of the drawings is shown as being to scale, the depicted scale is to be understood as a non-limiting illustrative example.

[0013] [Figure 1] FIG. 1 presents a schematic representation of a vehicle having a CAN bus and a functional diagram of one ECU on the CAN bus implementing an embodiment of time anomaly detection as disclosed herein.

[0014] [Diagram 2] 2 and 3 present diagrammatic representations of two illustrative embodiments of the temporal anomaly detection of FIG. [Diagram 3] 2 and 3 present diagrammatic representations of two illustrative embodiments of the temporal anomaly detection of FIG.

[0015] [Figure 4] FIG. 4 presents a diagrammatic representation of one illustrative embodiment of a portion of the state machine of FIG.

[0016] [Diagram 5] FIG. 5 presents a graphical representation of a preferred method for automatically learning the state machine of FIG. 1 from training CAN bus data.

[0017] [Figure 6] FIG. 6 presents a diagrammatic representation of an illustrative approach for utilizing a state machine to provide state recognition for the temporal anomaly detection of FIG. 2 or FIG.

[0018] [Figure 7] 7 and 8 present diagrammatic representations of two illustrative embodiments of the state transition detection block of FIG. [Figure 8] 7 and 8 present diagrammatic representations of two illustrative embodiments of the state transition detection block of FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] (Detailed Description) As mentioned above, the ARB ID of a message on the CAN bus indicates the meaning of the data contained within the message, for example, wheel speed may be contained on ARB ID 0x354 with two bytes of data representing the rotational speed of each of the four wheels. All control modules on the vehicle that have a need to know wheel speed will be programmed to associate ARB ID 0x354 with wheel speed. Typically, one module, such as the anti-brake system (ABS) module, will only be responsible for transmitting these messages.

[0020] CAN bus is commonly used on real-time systems and messages can be divided into two types: periodic and aperiodic. Periodic messages are messages of a given ARB ID that are transmitted through the real-time task scheduler to share information that other modules utilize in their real-time control tasks. One example is a torque request originating from the stability control module, which requests a torque change by the engine control module. Periodic messages are transmitted at approximately fixed time intervals. The time intervals are not fully deterministic since the CAN itself cannot be guaranteed to be deterministic, for example in a crash situation where lower priority messages are delayed. When the engine is running without any request for torque modification, the payload of successive messages is identical, and the payload changes when a torque modification is required, such as to maintain vehicle stability. The second type of message is aperiodic. These messages are typically transmitted in response to a user action, such as a button press or door unlock.

[0021] Disclosed herein are embodiments of time anomaly detection that detects anomalies in the timing of messages in a periodic message stream. The disclosed time anomaly detection advantageously does not require training on a set of training data and is adaptive to changes in the average message transmission frequency. Additionally, because the time anomaly detection function does not require access to the message data, the function works when CAN bus messages are encrypted at the application layer.

[0022] Disclosed herein are embodiments of state-aware anomaly detection in which a state machine for a host platform (e.g., ground vehicles, water vehicles, space vehicles, industrial automation and process control systems, etc.) is maintained. These embodiments leverage the recognition herein that the pattern of messages for a given ARB ID may depend on the state of the platform. For example, an ABS module may transmit messages broadcasting wheel speed periodically during normal vehicle operation. However, when cruise control is in use on the platform (thereby changing platform state), the frequency of wheel speed messages transmitted by the ABS module may be increased to provide this information to the cruise control module operating at a higher time resolution. As another example, an ABS system may transmit messages providing an ABS modulated brake pulse rate when the ABS system is operating during an emergency braking event, but may not transmit these messages otherwise. By using a state machine to recognize the state of the platform, messaging anomaly detection can be tailored with respect to the current state of the platform. This state awareness can provide improved accuracy in identifying anomalies. The state machine itself can also be used for anomaly detection; for example, if the state machine detects a state transition that is not one of the state machine's allowed state transitions, this violation can be flagged.

[0023] It should be appreciated that the disclosed time anomaly detection and the disclosed state-aware anomaly detection may be usefully combined. For example, in the absence of state awareness, a moderate change in the frequency of messages for a particular ARB ID when the platform state changes (e.g., when cruise control is in use) may be erroneously flagged as an anomaly. In the combined embodiment disclosed herein, state awareness ensures that such errors do not occur. Additionally, with adaptive time anomaly detection as disclosed herein, a history accumulation of messages for a given ARB ID used in adaptively adjusting the time anomaly detection for that ARB ID may be stored in memory when the platform changes from a current (first) state to a new state, and then when the platform returns to the first state, the stored history accumulation of messages for the first state is retrieved and used. (In the absence of such storage / retrieval, when the platform returns to the first state, there will be some dead time during which sufficient history accumulation of messages for the ARB ID occurs, and any anomalies involving that ARB ID during this dead time will not be detected.)

[0024] While the disclosed temporal anomaly detection and the disclosed state-aware anomaly detection can be usefully combined as described above, it should be further appreciated that the disclosed temporal anomaly detection can additionally or alternatively be used in conjunction with other types of anomaly detection, such as the per-message SVM classifier-based anomaly detector described in U.S. Patent No. 9,792,435 to Harris et al. In this example, different values ​​of the SVM hyperplane curvature parameter γ are trained for different states of the vehicle, and the value of parameter γ trained for the current state of the platform as indicated by the state machine is used. This allows the SVM classifier to be more finely tuned for the particular patterns of CAN bus message traffic present in the current state of the platform, as compared to training that is not state-aware.

[0025] Referring to FIG. 1, a platform 10 includes a controller area network (CAN) bus 12 to which several electronic control units (ECUs) 14 are connected. An exemplary platform 10 is an automobile. More generally, the vehicle 10 may be a ground vehicle (e.g., an automobile 10 as shown, or a truck, an off-road vehicle, a motorcycle, a bus, or the like), a water vehicle (e.g., an ocean-going vessel, a submarine, or the like), or a space vehicle (e.g., an orbital satellite, an interplanetary probe, or the like), or an industrial control system, e.g., an industrial automation and / or industrial process control system employing a CAN bus or other broadcast network. More generally, an ECU may be any electronic device that is connected to a CAN bus or other network 12 of a platform (e.g., a vehicle, an industrial control system, or the like), such as (in the case of a typical vehicle) an engine control module, an ABS module, a power steering module, and / or other vehicle operation related electronic devices, a car stereo or other in-vehicle entertainment system, a radio transceiver used for outside-vehicle communication (e.g., a communications satellite transceiver), a vehicle climate control module, or the like. In the case of an industrial control system, the ECUs may include, for example, furnace control modules, gas flow controller ECUs, robot controllers, etc. More generally, the CAN bus 12 may be any broadcast network, i.e., any network where traffic on the network is received by all electronic devices on the network and where the traffic on the network does not include message authentication. Message authentication in this context is information contained within a message or within the architecture of the network by which a receiving device may verify the source of the message. The CAN bus does not natively provide message authentication. Note that while the network does provide message authentication, a given set of two or more ECUs 14 on the network may incorporate authentication into messages sent between those ECUs.For example, two ECUs may employ public key cryptography by exchanging public keys over a CAN bus or some other communication path, and then encrypted messages between these ECUs would be authenticated using public key cryptography. However, the network does not provide that message authentication.

[0026] A message on a broadcast network may comprise a payload and a message header that identifies the payload. In the case of a CAN bus, the message header that identifies the payload is an ARB ID header. In this regard, in a given platform, a single ECU may simply transmit a message with a specific ARB ID header, but this does not mean that this specific ARB ID header serves as a message authentication by which a receiving device may verify the source of the message. This is because any ECU on the network may be compromised to transmit a message with its ARB ID (or alternatively, a malicious new device may connect to the CAN bus and transmit a message with its ARB ID), and the receiving device would not have any way of knowing that the message originated from the compromised or malicious new device, and not from the ECU that was supposed to transmit the message with its ARB ID. More generally, the disclosed approach may be used on any network where traffic on the network is received by all electronic devices on the network (i.e., a broadcast network), where traffic on the network does not include message authentication, and where transmitted messages comprise a payload and a message header that identifies the payload. An illustrative embodiment employs a CAN bus as the network, where the header is the full ARB ID, and a subset of the ARB ID, such as a Parameter Group Number (PGN) as in the SAE J-1939 standard, or some other identifier, consistently represents the same data content.

[0027] Continuing with reference to FIG. 1, at least one protection ECU 14 prot (or more generally, electronic devices 14 on a network 12 prot ) includes anomaly detection capabilities as shown diagrammatically in FIG. prot The ECU 14 includes an electronic processor 20 and a non-transitory storage medium 22 that stores instructions 24 that are readable and executable by the electronic processor 20. The hardware components 20, 22 may be implemented in a variety of ways. For example, in some embodiments, the electronic processor 20 and the non-transitory storage medium 22 may be separate integrated circuit (IC) chips disposed on a printed circuit board (PCB, not shown), with conductive traces of the PCB operatively connecting the processor 20 and the storage medium 22. As some examples, the electronic processor 20 may comprise a microprocessor or microcontroller IC chip, and the non-transitory storage medium 22 may comprise a memory IC chip, such as a flash memory chip, a read-only memory (ROM) IC chip, an electronically programmable read-only memory (EPROM) IC chip, or the like. In other embodiments, the electronic processor 20 and the non-transitory storage medium 22 may be monolithically integrated as a single IC chip. As some examples, the ECU 14 may include a microprocessor or microcontroller IC chip, and the non-transitory storage medium 22 may comprise a memory IC chip, such as a flash memory chip, a read-only memory (ROM) IC chip, an electronically programmable read-only memory (EPROM) IC chip, or the like. In other embodiments, the electronic processor 20 and the non-transitory storage medium 22 may be monolithically integrated as a single IC chip. prot The ECU 14 is implemented as an application specific integrated circuit (ASIC) chip or a field programmable gate array (FPGA) chip, with both the storage device and the digital processor being monolithically fabricated on a single ASIC or FPGA. prot receives CAN traffic 26 from the CAN bus 12.

[0028] 1 , instructions 24 include time anomaly detection instructions 30 that are readable and executable by electronic processor 20 to perform a time anomaly detection method that implements time anomaly detection, and state machine instructions 32 that are readable and executable by electronic processor 20 to maintain a state machine for platform 10 based on messages on CAN bus or other network 12 and / or sensor data received from one or more sensors monitoring platform 12, such as inertial sensors. prot is connected to receive sensor data from the accelerometer 33, the acceleration data from the accelerometer 33 may be used to measure platform conditions (rate of acceleration of the illustrative vehicle platform 10, detection of whether the engine is on or off based on engine induced vehicle vibrations, etc.). Other types of inertial sensors may also be used in addition to or in place of the illustrative accelerometer 33 (e.g., gyroscopes, magnetometers). As another illustrative example, in the case of an industrial control system, suitable sensors may include temperature sensors, pressure sensors, gas sensors, and / or other types of industrial process sensors. Sensors monitoring the platform 12 may include the ECU 14, prot 1) via wiring, cabling, a wireless communication interface, or the like. prot Note that the ECU 14 may be connected to the ECU 14. If the connection is by way of a CAN bus 12, which is another possible approach, the sensor data would be in the form of messages on the CAN bus network. prot is a dedicated electronic device that performs only anomaly detection. prot is an ECU that performs some other function (e.g., ECU14 prot (The instructions 24 may be an ABS module controlling anti-lock braking, a cruise control module, etc.). In these latter embodiments, the instructions 24 further include instructions for the electronic device 14 protThe ECU 14 that executes the instructions 24 includes control instructions 34 that are readable and executable by the electronic processor 20 to control the ECU 14 (e.g., to implement ABS, to implement cruise control, etc.). In embodiments that include control instructions 34, the instructions 24 may further include message rejection instructions 36 that are readable and executable by the electronic processor 20 to prevent the control instructions 34 from processing messages that are detected as anomalous by the time anomaly detection method. prot thereby implementing time anomaly detection 40 (via execution of time anomaly detection instructions 30), maintaining a state machine 42 for the vehicle 10 based on sensor data received from one or more sensors 33 monitoring messages and / or the platform on the CAN bus or other network 12 (via execution of state machine instructions 32), and in some embodiments performing ECU task processing 44 via execution of control instructions 34, optionally including a message rejection filter 46 via execution of message rejection instructions 36.

[0029] The ECU task processing 44 is optional and prot is included when platform 10 performs functions on platform 10 other than providing the disclosed network protection anomaly detection services. For example, platform 10 may be a ground vehicle and ECU 14 may be a prot If the ECU 14 is an anti-lock braking system (ABS) module, the ECU task processing 44 preferably performs functions related to anti-lock braking, such as monitoring wheel speed, monitoring signals from the brake pedal, and modulating (e.g., pulsing) the brakes applied to the wheel if it is detected that it is unable to engage the road during a braking event. As another example, the platform 10 is an industrial control system and the ECU 14 prot If ECU 14 is a furnace control module, ECU task processing 44 may include monitoring the temperature of one or more furnace zones and regulating the current to the furnace heater coils (for an electric furnace) or regulating the fuel flow to the furnace burners (for a combustible fuel furnace). protis a dedicated device for providing (only) the disclosed network protection anomaly detection service, in which case it is assumed that the ECU task processing 44 is omitted.

[0030] As will be further described herein, the time anomaly detection 40 includes maintaining a history accumulation 50 of messages for each ARB ID that is being monitored for anomalies, and optionally includes state-specific adjustments 52 in which the anomaly detection is adjusted for a current state 54 of the state machine 42. As shown diagrammatically in FIG. 1, the time anomaly detection 40 receives and processes the CAN bus traffic 26, and similarly, the state machine 42 for the vehicle 10 is maintained based on messages on the CAN bus traffic 26. The ECU task processing 44 (if implemented) also receives the CAN bus traffic 26, except to the extent that anomaly messages detected by the time anomaly detection 40 may be filtered out by an optional message filtering filter 46. Depending on the task being performed, the ECU task processing 44 may also transmit messages, i.e., the ECU task processing 44 may also inject messages into the CAN bus traffic 26. These outgoing messages are typically not processed by time anomaly detection 40 (although, alternatively, processing the outgoing messages by time anomaly detection 40 is also contemplated), but may be included in the CAN traffic on which state machine 42 is maintained. prot is the cruise control module of vehicle 10, ECU task processing 44 may include sending a message indicating that the cruise control is in use, which may cause a state transition in state machine 42.

[0031] In the illustrative embodiment, a single ECU 14 on the CAN bus 12 prot14. However, it is envisioned that more than one, or even all, of the ECUs 14 are provided with state-aware anomaly detection 40, 42. For example, any device for which a message rejection filter 46 is desired would advantageously include state-aware anomaly detection 40, 42.

[0032] Additionally, it is contemplated to implement the temporal anomaly detection 40 without the state machine 42, in which case there would be no state-specific tuning 52 and the history accumulation 50 would not be state-specific. Conversely, it is contemplated to implement the state machine 42 in conjunction with anomaly detection other than (or in addition to) the illustrative temporal anomaly detection 40. For example, as discussed above, the per-message SVM classifier-based anomaly detector described in U.S. Patent No. 9,792,435 to Harris et al. may benefit from state awareness.

[0033] 2, an illustrative embodiment of time anomaly detection 40 is described. A history accumulation 50 is maintained for each message header 60 in the CAN bus traffic 26. The message header 60 may illustratively be the complete ARB ID or a subset of the complete ARB ID, such as a parameter group number (PGN) as in the SAE J-1939 standard. Although not explicitly shown in the drawings, each message may be transmitted to electronic device 14, as illustrated in FIG. protIt should be appreciated that messages recorded in the history store 50 are assigned a timestamp indicating when they were received at the time of message reception. Thus, messages recorded in the history store 50 are time stamped. The clock generating the timestamp may be local to the electronic device and need not be synchronized across the network. History store statistics 62 including expected period and period variability metrics are calculated for the message history store 50. In one approach, each message with a subject message header is associated (i.e., time stamped) with the time it was received. This time is compared to the most recent previous time the message was received resulting in a measure of message period that is added to the history store 50. Once the history store 50 contains some specified minimum number of samples (which may be a tunable parameter of state specific tuning 52, or a tunable global parameter if no state awareness is present), statistics 62 including the average or representative message period are determined along with standard deviation, variance, or other selected variability metric. The variability metric is a measure of the determinism of the message in the message header. For example, a small standard deviation or variance indicates a highly periodic occurrence of the messages of the message header, while a large value for the standard deviation or variance indicates a wide range of different message periods and low periodicity. In decision 64, it is determined whether the messages of the subject message header are sufficiently periodic to be considered deterministic. For example, decision 64 may employ a threshold value for the standard deviation (or alternatively, the variance), such that if the standard deviation (or variance) is below the threshold, the message header is considered periodic, otherwise the message header is considered aperiodic. If the message header is aperiodic, then at 66 the message header is ignored. This is shown diagrammatically in FIG. 2 by feedback arrow 68, which indicates that the message header should not be subsequently accumulated or further processed. Note that there is a separate history accumulation 50 and separate statistics 62 for each message header occurring on the CAN bus.

[0034] In addition to not calculating (or alternatively ignoring) the statistics 62 until a specified minimum number of samples have been accumulated, in some embodiments the statistics 62 are reset after a period of inactivity for a given message header. This reset feature may also be a tunable parameter of state-specific tuning 52, or a tunable global parameter if no state awareness is present. In a non-limiting illustrative example, the reset of the statistics 62 is applied after 30 seconds without any messages with a subject message header. This mechanism allows the statistics 62 to reflect the operation of the platform by ignoring missing messages. Missing messages may be an indication of a malfunction or simply that the user is not running part of the system (e.g., not using cruise control), and are unlikely to be indicative of a malicious attack. It should also be noted that other approaches to calculating the statistics 62 are contemplated, including expected value and variance metrics, such as applying a Fast Fourier Transform (FFT) to calculate the mean and variance or standard deviation.

[0035] 2, detection of aperiodic messages transmitted with a periodic message header (i.e., a message with a message header that is periodic as shown in decision 64) is performed as follows: The periodicity 70 of the two most recent messages with a periodic message header (i.e., in the case of a CAN bus, the subject message header) is calculated as the time separation of the two most recent messages. In decision 72, an anomaly is detected if the deviation of the time separation 70 of the two most recent messages from the expected periodicity for the periodic message header (from historical statistics 62) exceeds a certain threshold X, which again may be a tunable parameter of state-specific tuning 52, or a tunable global parameter if there is no state awareness. In some embodiments, the threshold X is a defined percentage deviation from the expected periodicity for the message header. If an anomaly is detected, in operation 74, the most recent message with the subject message header is flagged as anomalous. 1 is employed, the anomaly flagging operation 74 may also trigger the filter 46 to prevent the immediate message from being processed by the ECU task processing 44. Additionally or alternatively, it is contemplated that the anomaly flagging operation 74 may send an alert to an on-board computer display of the vehicle 10, and / or the alert may be transmitted wirelessly to a centralized location (e.g., an automobile manufacturer's monitoring center that uses the information to monitor firmware upgrades), etc.

[0036] One potential difficulty with the time anomaly detection approach described with reference to Figure 2 is that the non-deterministic nature of the CAN bus (e.g., the possibility of message transmission delays due to collisions) means that the threshold X may need to be set to a fairly high value to limit false positives, which may reduce sensitivity. This is because a time anomaly is detected as a deviation from the expected periodicity (from a statistic of 50) for the periodic message header of the most recent set of only two messages with a periodic message header.

[0037] With reference to FIG. 3, another illustrative embodiment of the time anomaly detection 40 is described, which uses a sliding window 80 statistic together with the historical representative value 50. By using the sliding window 80, a time anomaly is detected as a deviation from an expected period of the period of a recent set of more than two messages with a periodic message header. The window size W of the sliding window may be a tunable parameter of the state-specific tuning 52, or a tunable global parameter if no state awareness is present. As shown in FIG. 3, the processes 62, 64, 66, 68 are preferably performed as already described with reference to FIG. 2 to determine that the subject message header is sufficiently periodic to perform the time anomaly analysis. For each periodic message header as thus determined, a sliding window accumulation 80 is performed until it is detected in decision 82 that the window is filled with W samples. Once the window is filled, in operation 84, the period of the recent set of W messages with periodic message headers is calculated. This can be calculated, for example, as follows:

number

[0038] The window size W of the sliding window 80 presents a trade-off between the likelihood of a false positive attack flag and the time it takes to flag an attack. If real-time control communications on the vehicle operate at frequencies above 20 Hz, an attack may be detected and alerted within one second or less by using a window size W of 20 samples.

[0039] Advantageously, both the temporal anomaly detection approach described with reference to FIG. 2 and the temporal anomaly detection approach described with reference to FIG. 3 do not require the training of any machine learning (ML) components. Also, the approaches can be adaptive if the history accumulation 50 is reset as described above. Improved real-time adaptability can be achieved by using a time-domain anomaly detection method in which the history accumulation 50 is reset as the sample size B H This can be achieved when the buffer is implemented as a first-in, first-out (FIFO) buffer. For example, H is set to 5,000 samples and the periodicity of the subject message header is 500 Hz, a slow change in the expected period over time of about 10 seconds can be accommodated as the buffer discards the oldest samples.

[0040] As another variation, it is expected that attacks will be more likely to be associated with a decrease in periodicity because malicious actors typically inject additional messages. Thus, in some embodiments, deviations from the expected periodicity for the subject message headers of a recent set of two (FIG. 2) or more (FIG. 3) messages are flagged as anomalous, as this suggests that a message has been injected, and it is only those deviations where the periodicity of the recent set of messages is less than the expected periodicity. In contrast, deviations where the periodicity of the recent set of messages is greater than the expected periodicity are less likely to indicate a malicious attack and are not flagged as anomalous.

[0041] One potential problem with the time anomaly detection approach of Figures 2 and 3 is that if the vehicle 10 changes its state, this may result in a change in the periodicity of some periodic message headers. In the example described above, the ABS module transmits messages broadcasting wheel speeds with ARB ID 0x354. These messages are transmitted less frequently when cruise control is not in use and more frequently when cruise control is in use. In such a case, when cruise control is in use, the frequency of messages with ARB ID 0x354 increases dramatically, which may be erroneously detected as a time anomaly.

[0042] 1, it is further disclosed herein to maintain a state machine 42 for the vehicle 10 based on messages on the CAN bus or other network 12 and / or sensor data received from one or more sensors 33 monitoring the platform 12, including maintaining an identification of a current state 54. In the wheel speed example, a state transition detected by the state machine 42 may trigger a reset of the anomaly detector (and more specifically, of the history accumulation 50 and associated statistics 62). Thus, a sudden increase in the frequency of messages in ARB ID 0x354 would not be detected as a (false) anomaly.

[0043] Briefly referring to FIG. 4, an illustrative portion of a possible state machine for a vehicle 10 is shown, including the states "engine off", "engine on", "vehicle turning", "brake system engaged", and "cruise control engaged". The directed arrows in FIG. 4 represent permitted state transitions. The vehicle 10 is in only one state at any given time, e.g., state "cruise control engaged" in FIG. 4. According to a conventional state machine schematic representation, in FIG. 4, the possible states of the state machine are represented by nodes (shown as ovals in FIG. 4), and each allowed state transition from an initial state to a next state is shown as a directed arc extending from connecting the initial state to the next state. It should be understood that the state machine will be specific to a particular platform. FIG. 4 shows a portion of a possible state machine for an illustrative vehicle 10. As another example (not shown), an industrial process may have states such as "Conveyor Belt Transport", "Furnace Start", "Furnace Hung", "Furnace Shutdown", "Quench", etc., with appropriate corresponding state transition arcs (e.g., "Conveyor Belt Transport" → "Furnace Start", "Furnace Start" → "Furnace Hung", "Furnace Shutdown" → "Conveyor Belt Transport", "Conveyor Belt Transport" → "Quench", etc.).

[0044] Determination of the state of the vehicle 10 can be accomplished using machine learning (ML) to eliminate any necessary a priori information that a human observer may need to use the determination. ML algorithms are used to learn different states for the vehicle, and state-specific tuning parameters 52 can be used to adjust the tracking of periodic messages, or even adjust the messages being tracked in time. For example, messages broadcasting wheel speeds can be sent periodically during normal operation. Once cruise control is in use on the vehicle, this periodicity can increase. ML correlates the "cruise control in use" state with a faster periodicity for the wheel speed broadcast messages without a human having to manually set parameters. Another example can verify the physical state of the vehicle during state transitions. The power draw of a vehicle during engine start is a well-known pattern that a trained automotive engineer can easily detect. ML algorithms can extract physical characteristics from the data contained within the CAN messages, eliminating the need for a trained engineer to map out all known vehicle characteristics and identifying patterns that a human cannot identify on their own.

[0045] The machine learning approach to determining state involves the creation of a unique model to be used for anomaly detection for each state tracked. The state machine 42 then monitors incoming messages and / or sensor data received from one or more sensors monitoring the platform for state change triggers. Once a trigger is observed, the state determination algorithm can switch the model currently being used to detect anomalies. During training, a sliding window can be used to collect CAN messages for investigation. This sliding window tracks the last X messages, where X is an adjustable parameter. The machine learning algorithm can then determine the platform state by examining unique messages, occurrences / periodicity of messages, or other yet to be determined characteristics contained within this sliding window.

[0046] The number of states tracked can also be adjusted to meet operational needs. For example, a broad range of state determination may track only two unique states, such as the vehicle in motion and the vehicle idling. A more precise state determination may track N unique states, where N is an adjustable parameter. These states may include vehicle parked, vehicle cruise control, vehicle turning, vehicle accelerating / braking, etc.

[0047] Each state may have a unique model associated with it. When a state transition is detected, whether through a specific message being detected or through analyzing a buffer of recent messages, the model for the new state is switched in, refining the anomaly detection capabilities.

[0048] State-aware anomaly detection algorithms can also be used to enhance time anomaly detection. Periodic CAN messages are transmitted nearly deterministically (not completely deterministic since CAN itself cannot be guaranteed to be deterministic) on the platform network during normal operation. Periodic messages can be divided into two categories: true periodic messages and event periodic messages. True periodic messages have a nearly deterministic rate when the engine is running. Event periodic messages have a nearly deterministic periodicity or a significantly different periodicity when an event occurs that places the platform in a unique state, such as enabling cruise control on modern vehicles. Once the platform enters this new state, there may be a unique event periodic message that is sent nearly deterministically for the duration of time the platform remains in this state. Using a unique model for each state that the new algorithm tracks would allow the time algorithm to be adjusted, allowing the device to monitor more effectively for time anomalies.

[0049] Once state awareness is obtained, the state can be used for other security or condition assessments, allowing condition-based maintenance or detection of diagnostics at inappropriate times. Thus, it should be understood that certain messages may be appropriate on the cyber-physical network, i.e., the CAN network 12, only when the vehicle 10 is in an appropriate state. For example, a diagnostic reprogramming message to the engine controller (e.g., ECU 14) should only occur when the engine is off and the vehicle 10 is not moving, and therefore is in an "ignition on, engine off" state. Similarly, there are messages that should only occur when the vehicle 10 is not in a specific state, but are acceptable in any other state, e.g., a door unlock message would be appropriate in all states except "engine on, vehicle moving". Finally, a message may be appropriate in more than one state and inappropriate in the remaining ones, e.g., a diagnostic message to reprogram the radio is acceptable in both "ignition on, engine off" and "engine on, not moving" states, but not acceptable in "moving state" or "ignition off" states. Whenever a message is observed, either due to its presence or due to its specific content being in a state that is not enabled, the message is anomalous and should be reported.

[0050] Detection of the state incompatibility anomaly message may be performed by the ECU 14 according to the following exemplary embodiment. First, a message is captured from the network 12 and either processed at the message level or segmented into signals. In the context of this exemplary embodiment, the terms "message" and "signal" are used synonymously. The ECU 14 or other suitable component then associates the signal with its corresponding data in a table / database, for example, stored on the non-transitory storage medium 22. In various embodiments, the data may be stored in a DBC file, however, it should be understood that the data may be any representation in which a signal is looked up in a table and further parameters for that signal are available. The parameters for that signal may in a simple form be an enumeration of available states and a binary value representing that signal is enabled (1) or not enabled (0) during that state.

[0051] An exemplary lookup table may contain parameter values ​​(0,0;1,1;2,1;3,1) for signals that are not enabled in state (0) and enabled in states 1, 2, and 3, provided that the corresponding system has states listed from 0 to 3. In an enhanced embodiment, the table may be extended to give the reason why the signal was abnormal and / or to represent the corrective action to be taken. For example, (0,0,9;1,1,0;2,1,0;3,1,0), where 9 would represent an enumeration in the table indicating either or both of the corrective action to be taken or the reason why the signal was abnormal. The table may also store information regarding the reason as text in the table.

[0052] According to a more complex form, the table may be implemented to represent signals, i.e. elements in a message and their individual states. According to one implementation, via a bit field for matching of signal content to enabled / disabled states. It should be understood that this approach may be most applicable when signals are constrained to a small number of bits. For example, a set of fields (State; Set or Clear; Bit Field), where State represents the state in which the field is active, Set or Clear represents whether the bit field represents a bit that must be set (1) or cleared (0) for triggering to occur, and Bit Field represents the bit in the signal to be verified. If some bits must be positive and some negative, two of these segments may be combined through an "and" combination. A non-limiting example is that if an anomaly should be reported in a state enumerated as (3) and the third bit is Set (assuming an 8-bit number represented in binary notation), the table entry would be (3, 1, '0000 0001'). A second implementation of representing the same information includes the use of typical database notation and simple query language (SQL) methods suitable for extracting and comparing features of data elements, as would be understood by one skilled in the art. Those skilled in the art will appreciate that such an implementation would necessarily increase the overhead of the present system, e.g., resource usage and the like. Thus, the vehicle 10 state may be used to determine whether a signal / message is abnormal via a blacklist of messages based on the vehicle state, e.g., if the vehicle 10 is moving, any messages of a diagnostic nature may be prohibited. Thus, the parameter values ​​associated with the current state may change in response to a transition from the current state to a new state. As indicated above, in the case where a signal (message) is determined to be abnormal based on the state, further processing may be applied, as disclosed above and below.

[0053] 5, one illustrative approach for training the state machine 42 is described. Training utilizes training CAN traffic data 100 (and optionally training sensor data, such as that obtained by the accelerometer 33 in parallel with obtaining the training CAN traffic data 100). For supervised or semi-supervised learning, the training CAN traffic data 100 is suitably labeled with state annotations, e.g., annotated by an engineer performing the collection of the CAN data 100. In one embodiment, the engineer operates the vehicle in different states (engine off, engine on / idle, driving, turning, cruise control engaged, cruise control disengaged, etc.) and identifies the times at which each state change occurs (this may include combing through the CAN data and identifying messages that indicate precisely when the engineer initiated various state change platform operations). Blocks of data during state change events are then labeled with their correct state, e.g., when the engine is in a stopped state at time t m The vehicle is driven from idle to running at time t n and at a later time t p If it is released in the time interval [t m ,t n ] are labeled as platform state “operating” and are split into time intervals [t n ,t p ] is tagged as platform state "cruise control engaged."

[0054] In operation 102, the CAN data 100 is segmented into time intervals or windows. These may optionally partially overlap in time. In operation 104, the windows are clustered into N clusters using a clustering technique such as k-means clustering. Each cluster corresponds to a state of the state machine. Depending on the choice of clustering algorithm, the number of classes (N) may be fixed or may be a suitable parameter of the clustering operation 104. If the number of clusters is fixed, the clustering may be re-run several times with different values ​​for N, optimizing the number of clusters by selecting the value of N that results in the most discriminatory clusters (the discriminability metric optionally incorporates a penalty for higher values ​​of N to bias toward state machines with a reasonable number of states). In operation 106, the clusters are labeled with a state indicator based on the state annotations of the CAN data 100. For example, each cluster may be labeled with a state indicator where most of the CAN data that fall into that cluster are labeled. In an alternative embodiment, the state labeling operation 106 is omitted, in which case the states are not explicitly associated with readily human-identifiable conditions.

[0055] In operation 108, allowed state transitions are identified. This can be done by labeling each window defined in segmentation operation 102 with the state (and state indicator, if operation 106 is performed) to which it best fits. This generates a sequence of states, and therefore a set of state transitions, that occur in the training CAN data set 100. These are the allowed state transitions. In contrast, any state transition that does not occur in the training data 100 is not an allowed state. The identification of allowed state transitions, i.e., operation 108, is also optional. If no allowed state transitions (corresponding to arcs in the example of FIG. 4) are determined, then no state transition is considered permissible.

[0056] Further, state-specific tuning 52 is determined for each state in operation 110. For each state, the portion of the CAN bus training data 100 that belongs to the window (from segmentation 102) assigned to that state forms a (sub)set of training CAN bus data for use in optimizing tuning parameters of the temporal anomaly detection 40 for that particular state.

[0057] The approach of FIG. 5 is merely one illustrative example of constructing the state machine 42. In other embodiments, the state machine 42 may be created manually. For example, states can be defined based on known operating modalities of the vehicle 10, including, for example, but not limited to, the states labeled in FIG. 4. State transitions can be identified by specific CAN bus messages. For example, a design engineer may know that a certain message or set of messages is conveyed on the CAN bus when cruise control is first engaged, and similarly, when cruise control is released, when a turn is performed, etc. In this approach, the state-annotated CAN bus data 100 is used only to perform state-specific adjustments, for example, window segmentation 102 is suitably performed, with each window assigned a state based on the state indicator annotations of the data 100, and the subsets of data assigned to the various states are then used in operation 110.

[0058] Now referring to FIG. 6, a preferred approach for the implementation of state recognition in the time anomaly detection 40 is described. It is assumed that the state machine 42 has been constructed automatically or semi-automatically and that state-specific tuning parameters 52 have been derived for each state. During vehicle operation, the CAN bus traffic 26 is input to the time anomaly detection 40 and processed as described with reference to FIG. 2 or with reference to FIG. 3. In parallel, the CAN bus traffic 26 (and optionally sensor data from available sensors 33) is input to a state transition detection block 120 that detects state transitions, for example by detecting a message (or a set of messages) and / or sensor data indicative of a state transition (see FIG. 7) or by fitting a window of CAN data to the clusters generated in operation 104 of FIG. 5 (see FIG. 8, which assumes that the state machine 42 was created by a clustering algorithm). When the state transition detection block 120 detects a state transition, the current state 54 of the state machine 42 is updated accordingly in operation 122. Additionally, for each periodic message header, the state specific adjustments 52 of the time anomaly detection 40 are updated in operation 124 to the values ​​for the new state.

[0059] In some embodiments, the state transition also triggers a reset of history accumulation 50 since the existing data is for the previous state and may not represent the new state, however this will result in some dead time as history accumulation for the new state occurs.

[0060] Thus, in another approach shown in FIG. 6, state recognition is utilized to avoid this dead time, if possible. To this end, in operation 126, the history accumulation for the previous state is stored and the history accumulation for the new state is retrieved, if it exists. To further illustrate, consider the following example. The driver initially drives without cruise control, during which time history accumulation 50 accrues for the "cruise control off" state. The driver then engages cruise control (state transition). In response, operation 126 stores the history accumulation for the "cruise control off" state and resets the history accumulation 50 for the new "cruise control engaged" state, assuming that no history accumulation is yet available for the "cruise control engaged" state. Now, there will be some dead time when sufficient history accumulation for the new state accrues before time anomaly detection can be initiated. The driver then drives and drives for some time, during which time history accumulation 50 for the "cruise control engaged" state continues to accrue. The driver then enters a busier traffic situation and releases cruise control (another state transition). In response, operation 126 stores history accumulation for the "cruise control engaged" state and retrieves the previously stored history accumulation for the "cruise control released" state. Thus, there is no dead time before time anomaly detection can operate for the "cruise control released" state. If the driver then enters a less congested traffic situation and re-engages cruise control, operation 126 stores history accumulation for the "cruise control released" state and retrieves the previously stored history accumulation for the "cruise control engaged" state, again allowing time anomaly detection to proceed without dead time. And so on.

[0061] 6, the detected state transitions are used to update state-specific adjustments 52 of the illustrative temporal anomaly detection 40. However, it should be understood that other types of anomaly detection may similarly be updated with state-specific adjustments. For example, a per-message SVM classifier-based anomaly detection such as that described in U.S. Patent No. 9,792,435 to Harris et al. may have a hyper-parameter γ that is updated with state-specific values.

[0062] If state machine 42 includes information regarding allowed state transitions (e.g., as determined in operation 108 of the training process of FIG. 5 or manually created by a design engineer based on known operation of vehicle 10), this information can also provide an independent mechanism for anomaly detection. For example, at decision 130 it is determined whether a state transition is an allowed transition, and if not, at 132 an anomalous state transition is flagged. Similarly, at decision 134 it may be determined whether the frequency or other pattern of state transitions is irregular (e.g., based on the pattern of state transitions observed in operation 108 of FIG. 5), and an anomalous pattern of state transitions may be flagged as well.

[0063] 7 and 8, two illustrative embodiments of the state transition detection block 120 of FIG. 6 are described. FIG. 7 shows an embodiment preferably employed for the case where the state machine 42 is generated by CAN bus data window clustering as described with reference to FIG. 5. A sliding window 140 produces messages from the CAN bus traffic 26 until it is determined in decision block 142 that the window is filled. To facilitate comparison with the clusters generated by the state machine learning operations 102, 104 of FIG. 5, decision block 142 preferably indicates that the window is filled when it has the same number of messages as the window generated by the segmentation operation 102. When the window is filled, it is compared with the clusters / states generated by the state machine learning operations 102, 104 of FIG. 5 to identify the cluster / state closest to the message window. In decision 146, it is determined whether this closest cluster / state is the same as the current state 54. If the closest cluster / state is the same as the current state 54, no state transition has occurred. On the other hand, if the closest cluster / state is different from the current state 54, then a state transition has been detected 148, i.e., from the current state 54 to a new state that is the closest cluster / state to the message window. Optionally, the decision 146 may employ some statistics to improve robustness, for example, the detection 148 may be made only if the same closest cluster / state continues to be detected as the sliding window 140 yields a certain number M of messages.

[0064] 8, an embodiment of the state transition detection block 120 is described that is preferably used in an embodiment in which the state machine 42 includes identification of a specific message or set of messages that indicate a state transition. For example, if the state machine 42 is created manually, the designer may label each state transition with the message or set of messages that occur as part of that state transition. In this embodiment, a buffer 150 stores the most recent N messages received from the CAN bus traffic 26. The buffer size N should be large enough to encompass the maximum expected time interval over which any set of messages indicating a state transition is expected to occur. Block 152 iterates through each possible state transition from the current state, and decision block 152 monitors the CAN bus traffic 26 to detect whether a message or set of messages indicating each such state transition has occurred, and if so, then the state transition is detected (156). Processes 152, 154 are repeated for all possible state transitions each time a new message enters the buffer 150. (In an alternative approach, the buffering 152, 154 may be repeated less frequently, as long as the buffer size N is large enough to prevent the possibility of missing a set of messages indicating a state transition).

[0065] Preferred embodiments have been illustrated and described. Obviously, modifications and alterations will occur to others upon reading and understanding the foregoing detailed description. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

[0066] It will be understood that variations of the above-disclosed and other features and functions, or alternatives thereof, may be combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may continue to be made by those skilled in the art, which are also intended to be encompassed by the following claims.

[0067] In order to assist the Patent Office and any readers of this application and any resulting patent in interpreting the claims appended hereto, Applicants do not intend that any of the appended claims or claim elements invoke 35 U.S.C. § 112(f), unless the words "means for" or "step for" are expressly used in a particular claim.

[0068] (Item 1) 1. An electronic device connectable to a network, wherein traffic on the network is received by all electronic devices on the network, the network does not provide message authentication, the transmitted message comprises a payload and a message header that identifies the payload, the electronic device: calculating expected periodicity and periodic variability metrics for historical accumulation of messages for different message headers and identifying periodic message headers based on the periodic variability metrics; detecting a time anomaly as a deviation in a periodicity of a most recent set of two or more messages with a periodic message header from the expected periodicity for the periodic message header; generating an alert indicative of the detected time anomaly; An electronic device that is programmed to (Item 2) 2. The electronic device of claim 1, wherein the most recent set of two or more messages with the periodic message header consists of two most recent messages with the periodic message header, and the time anomaly is detected as a deviation in a time separation of the two most recent messages from the expected periodicity for the periodic message header. (Item 3) 3. The electronic device of claim 2, wherein the alert includes a representation of the most recent message along with the periodic message header. (Item 4) 2. The electronic device of claim 1, wherein the most recent set of two or more messages with the periodic message header consists of a set of three or more most recent messages with the periodic message header, and the time anomaly is detected as a deviation of a measured periodicity for the set of three or more most recent messages from the expected periodicity for the periodic message header. (Item 5) The electronic device further comprises: Controlling tasks performed by the electronic device based on messages received over the network; responsive to detecting the time anomaly, excluding one or more messages of the most recent set of two or more messages from use in controlling the task. 5. The electronic device according to any one of items 1 to 4, programmed to perform the following: (Item 6) The network is a platform network, and the electronic device further comprises: maintaining a state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; in response to a transition of said state machine to a new state; (i) adding a parameter value for the new state to a parameter of a periodic message header identification based on the cyclic variability metric; and / or (ii) parameters defining the deviation detected as a time anomaly to parameter values ​​relating to the new state; and adjusting at least one parameter of 6. The electronic device according to any one of items 1 to 5, programmed to perform the following: (Item 7) The network is a platform network, and the electronic device further comprises: maintaining a state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; in response to a transition from a current state of the state machine to a new state; storing the history accumulation of messages relating to the different message headers with respect to the current state; loading from memory a history store of messages relating to said different message headers for said new state; and 7. The electronic device according to any one of items 1 to 6, programmed to perform the following: (Item 8) 8. The electronic device of any one of claims 1-7, wherein the network comprises a Controller Area Network (CAN) bus and the message header comprises an ARB ID header. (Item 9) 1. An electronic device connectable to a network, wherein traffic on the network is received by all electronic devices on the network, the network does not provide message authentication, the transmitted message comprises a payload and a message header that identifies the payload, the electronic device: an electronic processor; a non-transitory storage medium storing time anomaly detection instructions readable and executable by said electronic processor to implement a time anomaly detection method; Including, The time anomaly detection command instructions readable and executable by the electronic processor to calculate expected periodicity and periodic variability metrics for historical accumulation of messages for different message headers and to identify periodic message headers based on the periodic variability metrics; instructions readable and executable by the electronic processor to detect a time anomaly as a deviation in a periodicity of a most recent set of two or more messages with a periodic message header from the expected periodicity for the periodic message header; instructions readable and executable by the electronic processor to generate an alert indicative of the detected time anomaly; 2. An electronic device comprising: (Item 10) 10. The electronic device of claim 9, wherein the most recent set of two or more messages with the periodic message header consists of two most recent messages with the periodic message header, and the time anomaly is detected as a deviation in a time separation of the two most recent messages from the expected periodicity for the periodic message header. (Item 11) Item 11. The electronic device of item 10, wherein the alert includes a representation of the most recent message along with the periodic message header. (Item 12) 10. The electronic device of claim 9, wherein the most recent set of two or more messages with the periodic message header consists of a set of three or more most recent messages with the periodic message header, and the time anomaly is detected as a deviation of a measured periodicity for the set of three or more most recent messages from the expected periodicity for the periodic message header. (Item 13) The non-transitory storage medium further comprises: control instructions readable and executable by the electronic processor to control the electronic device based on messages received over the network; message rejection instructions readable and executable by the electronic processor to prevent the control instructions from processing one or more messages of the immediate set of two or more messages; 13. The electronic device according to any one of items 9-12, wherein the electronic device stores: (Item 14) the network is a network of platforms, and the non-transitory storage medium further stores state machine instructions readable and executable by the electronic processor to maintain a state machine for the platforms based on messages on the network and / or sensor data received from one or more sensors monitoring the platforms; The electronic device of any one of items 9-12, wherein the time anomaly detection instructions further include instructions readable and executable by the electronic processor for updating at least one parameter of the time anomaly detection method to a parameter value of the new state in response to a transition of the state machine to a new state. (Item 15) the network is a network of platforms, and the non-transitory storage medium further stores state machine instructions readable and executable by the electronic processor to maintain a state machine for the platforms based on messages on the network and / or sensor data received from one or more sensors monitoring the platforms; The time anomaly detection instruction further comprises: storing the history accumulation of messages relating to the different message headers with respect to the current state; loading from memory a history store of messages relating to said different message headers for said new state; and 15. The electronic device of any one of items 9-14, comprising instructions readable and executable by the electronic processor to perform the steps. (Item 16) 16. The electronic device of any one of claims 9-15, wherein the network comprises a Controller Area Network (CAN) bus and the message header comprises an ARB ID header. (Item 17) 1. An electronic device connectable to a network that hosts a platform, wherein traffic on the network is received by all electronic devices on the network, the network does not provide message authentication, and the electronic device: maintaining a state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; performing anomaly detection on messages on the network using at least one parameter value related to a current state of the state machine, including generating an alert in response to detecting an anomaly; in response to a transition from the current state of the state machine to a new state, updating the at least one parameter value for the new state; An electronic device that is programmed to (Item 18) The electronic device further comprises: Detecting a transition from a current state of the state machine to a new state; generating an alert in response to the detected transition being not an allowed transition of the state machine; Item 18. The electronic device of item 17, programmed to perform the steps of: (Item 19) The electronic device further comprises: Detecting a state transition of the state machine; and generating an alert in response to the detected pattern of state transitions satisfying an irregular transition pattern criterion; 19. The electronic device according to any one of items 17-18, programmed to perform the following: (Item 20) the message transmitted over the network comprises a payload and a message header identifying the payload; The electronic device of any one of items 17-19, wherein performing the anomaly detection includes detecting a periodic message header in which messages on the network have an expected periodicity that meets a periodicity criterion, and detecting an anomaly as a deviation of the periodicity of a recent message with the periodic message header from the expected periodicity, the network comprising a Controller Area Network (CAN) bus.

Claims

1. 1. An electronic device connectable to a network of a platform, wherein traffic on the network is received by all electronic devices on the network, the network does not provide message authentication, and a transmitted message comprises a payload and a message header that identifies the payload, the electronic device: training a state machine for the platform utilizing training traffic data from the network; maintaining the trained state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; in response to a transition of said state machine to a new state; (i) adding a parameter value for the new state to a parameter for identifying a periodic message header based on a cyclic variability metric; and / or (ii) parameters that define deviations in parameter values ​​for the new state that are detected as time anomalies; and adjusting at least one parameter of calculating expected periodicity and periodic variability metrics for historical accumulation of messages for different message headers and identifying periodic message headers based on the periodic variability metrics; detecting a time anomaly as a deviation of a periodicity of a most recent set of two or more messages with a periodic message header from the expected periodicity for the periodic message header; generating an alert indicative of the detected time anomaly; and in response to a transition from a current state of the state machine to a new state; storing the historical accumulation of messages relating to the different message headers relating to the current state; and loading from memory a history store of messages relating to said different message headers for said new state; To carry out An electronic device that is programmed to

2. 2. The electronic device of claim 1, wherein the most recent set of two or more messages with the periodic message header consists of two most recent messages with the periodic message header, and the time anomaly is detected as a deviation in a time separation of the two most recent messages from the expected periodicity for the periodic message header.

3. The electronic device of claim 2 , wherein the alert includes a representation of the most recent message along with the periodic message header.

4. 2. The electronic device of claim 1, wherein the immediate set of two or more messages with the periodic message header consists of a set of three or more immediate messages with the periodic message header, and the time anomaly is detected as a deviation of a measured periodicity for the set of three or more immediate messages from the expected periodicity for the periodic message header.

5. The electronic device further comprises: Controlling tasks performed by the electronic device based on messages received over the network; responsive to detecting the time anomaly, excluding one or more messages of the most recent set of two or more messages from use in controlling the task.

5. An electronic device according to claim 1, programmed to:

6. The training comprises: Segmenting the training traffic data into a plurality of windows, the training traffic data including state-annotated traffic; clustering the plurality of windows into N clusters, each cluster corresponding to a state of the state machine; labeling each of the N clusters with a state indicator representative of the segment of training traffic data contained within a corresponding window; identifying permitted state transitions according to each state indicator; The electronic device of any one of claims 1 to 5, comprising:

7. The electronic device further comprises: Detecting a transition from a current state of the state machine to a new state; generating an alert in response to the detected transition being not an allowed transition of the state machine; 6. An electronic device according to claim 1, programmed to:

8. The electronic device of any one of claims 1 to 7, wherein the network comprises a Controller Area Network (CAN) bus and the message header comprises an ARB ID header.

9. 1. An electronic device connectable to a network of a platform, wherein traffic on the network is received by all electronic devices on the network, the network does not provide message authentication, and a transmitted message comprises a payload and a message header that identifies the payload, the electronic device: an electronic processor; a non-transitory storage medium storing time anomaly detection instructions readable and executable by said electronic processor to implement a time anomaly detection method; Including, The time anomaly detection command state machine instructions readable and executable by the electronic processor to train a state machine for the platform utilizing training traffic data from the network; state machine instructions readable and executable by the electronic processor for maintaining the state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; instructions readable and executable by the electronic processor to calculate expected periodicity and periodic variability metrics for historical accumulation of messages for different message headers and to identify periodic message headers based on the periodic variability metrics; instructions readable and executable by the electronic processor to detect a time anomaly as a deviation in a periodicity of a most recent set of two or more messages with a periodic message header from the expected periodicity for the periodic message header, and to generate an alert indicative of the detected time anomaly; state machine instructions readable and executable by the electronic processor for maintaining a state machine for the platform based on messages on the network and / or sensor data received from one or more sensors monitoring the platform; Including, The time anomaly detection instruction further comprises: storing the history accumulation of messages relating to the different message headers with respect to the current state; loading from memory a history store of messages relating to said different message headers for said new state; and instructions readable and executable by said electronic processor to perform The time anomaly detection instructions further comprise: (i) adding a parameter value for the new state to a parameter for identifying a periodic message header based on a cyclic variability metric; and / or (ii) parameters that define deviations in parameter values ​​for the new state that are detected as time anomalies; the electronic device comprising instructions readable and executable by the electronic processor to update parameter values ​​of the new state, the parameter values ​​including at least one of:

10. 10. The electronic device of claim 9, wherein the most recent set of two or more messages with the periodic message header consists of two most recent messages with the periodic message header, and the time anomaly is detected as a deviation in a time separation of the two most recent messages from the expected periodicity for the periodic message header.

11. The electronic device of claim 10 , wherein the alert includes a representation of the most recent message along with the periodic message header.

12. 10. The electronic device of claim 9, wherein the immediate set of two or more messages with the periodic message header consists of a set of three or more immediate messages with the periodic message header, and the time anomaly is detected as a deviation of a measured periodicity for the set of three or more immediate messages from the expected periodicity for the periodic message header.

13. The non-transitory storage medium further comprises: control instructions readable and executable by the electronic processor to control the electronic device based on messages received over the network; message rejection instructions readable and executable by the electronic processor to prevent the control instructions from processing one or more messages of the immediate set of two or more messages; The electronic device according to any one of claims 9 to 12, further comprising:

14. The electronic device of any one of claims 9-12, wherein the time anomaly detection instructions further comprise instructions readable and executable by the electronic processor for, in response to a transition of the state machine to a new state, updating at least one parameter of the time anomaly detection method to a parameter value of the new state.

15. 15. The electronic device of claim 9, wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor for detecting a transition from a current state of the state machine to a new state and, in response to the detected transition being not an allowed transition of the state machine, generating an alert.

16. The electronic device of any one of claims 9 to 15, wherein the network comprises a Controller Area Network (CAN) bus and the message header comprises an ARB ID header.

17. The electronic device, further comprising: a program for detecting the time anomaly as a period of the most recent set of two or more messages that is shorter than the periodic message header from the expected period for the periodic message header; 9. The electronic device of claim 1, wherein the electronic device is not programmed to detect the time anomaly as a longer period of the most recent set of two or more messages than the periodic message header from the expected period for the periodic message header.

18. The instructions readable and executable by the electronic processor for detecting the time anomaly include: instructions readable and executable by the electronic processor to detect the time anomaly as a shorter period of the most recent set of two or more messages than the periodic message header from the expected period for the periodic message header; 17. The electronic device of claim 9, wherein the electronic device does not include instructions readable and executable by the electronic processor to detect the time anomaly as a longer period of the most recent set of two or more messages than the periodic message header from the expected period for the periodic message header.

Citation Information

Patent Citations

  • Intrusion detection method and device, electronic equipment and storage medium

    CN109547254A

  • On-vehicle network device

    JP2017047835A

  • Detection device, gateway device, detection method, and detection program

    JP2018046432A

  • US10,083,071

  • Host behavior and network analytics based automotive secure gateway

    US20190104108A1