GB2580025A - Anomaly detection system for in-vehicle network - Google Patents
Anomaly detection system for in-vehicle network Download PDFInfo
- Publication number
- GB2580025A GB2580025A GB1820657.3A GB201820657A GB2580025A GB 2580025 A GB2580025 A GB 2580025A GB 201820657 A GB201820657 A GB 201820657A GB 2580025 A GB2580025 A GB 2580025A
- Authority
- GB
- United Kingdom
- Prior art keywords
- data
- data set
- piece
- generated
- probability
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
- G06F11/3075—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved in order to maintain consistency among the monitored data, e.g. ensuring that the monitored data belong to the same timeframe, to the same system or component
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/81—Threshold
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Traffic Control Systems (AREA)
Abstract
Detecting anomalous data in an in-vehicle network by receiving messages comprising data by a vehicle electronic control unit (ECU), generating a data set comprising probability of occurrence of a current piece of data received at a current instance of time with reference to a previous piece of data received at a previous instance of time. The generated data set is compared with a reference data set stored at the electronic control unit, if the comparison exceeds a threshold percentage the data is flagged as anomalous. The anomalous data may be stored in a log and/or be prevented from transmitted out of the ECU. A portion of the reference data set may be replaced with a portion of the generated data set. The comparing step may be executed after the probability of each piece of data is generated.
Description
Anomaly Detection System For In-Vehicle Network
FIELD OF INVENTION
This invention generally relates to arrangements for secure communication and specifically for preventing or indicating unauthorised communication activity in vehicles.
BACKGROUND OF INVENTION
As vehicle systems become increasingly connected with other vehicle systems within a vehicle, with other vehicles' systems, and even with servers and web browsers, it becomes necessary to detect whether messages transmitted therebetween are legitimate.
Anomaly detection systems for an in-vehicle network are designed to detect abnormal behaviours and attacks on the vehicle. A typical way of detecting unauthorised messages is to copy all messages into buffers and to scan the contents of these messages periodically, while in the meantime, the original message is transmitted to the intended recipient, e.g. adestination vehicle system. However, since the scanning is done only periodically, real-time detection of unauthorised messages, whether malicious or not, cannot be guaranteed. Furthermore, any action to prevent malicious messages from affecting the destination vehicle system maybe too late, particularly if the destination vehicle systems are critical systems like engine control and airbag control.
Another way of detecting unauthorised messages is to detect anomalies in the payload of the message, i.e. the actual content or data in the message. In existing solutions based on a content model, the incoming data could be analysed as to driving pattern, environment status, driving location and other references, so that the data can be classified and the appropriate data reference set can be selected for detection of anomalies. Timing of the messages may also be used to detect anomalies. In existing solutions based on a timing model, the incoming data could be examined id classified. and the time intervals between messages could be identified. and corpared against time references Lm detect anemone-However, because the data can be classified in different ways, many different reference data sets are required for each classification and relatively long decision times may be required, thereby resulting in a delay of any preventive measures.
There are other anomaly detection methods used for general computer networks. However, these anomaly detection methods are usually not suitable for vehicle networks because they do not provide suitable response times for vehicle applications. Response times for vehicle applications are critical because of the potential life-threatening scenarios that can happen it the response time is not quick enough. For example, a driver response time for identifying an obstacle and braking the vehicle includes: the time for the driver to see the obstacle, recognise the danger of the obstacle, and lift his foot off the accelerator and onto the brake to avoid crashing into the obstacle, which could be a pedestrian. Typically, human response times for vehicle applications are in the range of milliseconds to seconds.
To adequately support vehicle and road users, vehicle systems need to react faster than the typical human response time. Similarly, detection of anomalies in data from vehicle networks between in-vehicle systems, such as between an advanced driving assistancesystemandabrakingsystem, between vehicle and other vehicles' systems and/or between in-vehicle systems and remote servers, needs to be in a real-time range of milliseconds. On the other hand, an acceptable response time for detecting anomalies in large-scale data from computer networks, e.g. big data or mined data from a network of Internet of Things devices, is in the range of minutes or longer.
Therefore, there is a need for a new or improved system and method 5 to detect anomalies in vehicle networks that overcomeorat least ameliorate one or more of the disadvantages discussed above.
SUMMARY
It is therefore an object to provide a system and method that can detect anomalies in an in-vehicle network to address the problems discussed above. Particularly, it is an object to provide a system and method that can detect anomalies in a time frame suitable for vehicle applications.
To accomplish these and other objects, there is provided, in a first aspect, a method of detecting anomalous data in an in-vehicle network, the method comprising: receiving messages comprising data by avehicle electronic control unit; generating a data set comprising probability of occurrence of a current piece of data received at a current instanceoftime (ti) with reference to a previous piece of data received at a previous instance of time (ttd); comparing the generated data set witha reference data set stored in a non-transitory computer-readable storage medium of the electronic control unit; if the comparison exceeds a threshold percentage, flagging the current piece of data as anomalous.
Data or payload may be received by a vehicle electronic control unit sequentially or in a series, e.g. a series of speed readings received from a speedometer of the vehicle. As such, the received data may be evaluated against the previous data in the series as to its probability of occurrence. The higher the probability of occurrence of the received data evaluated against the previous data, the less likely will the received data be an anomaly. In statistics, conditional self-information may be used to represent or:quantify the probability of occurrence of a current piece of data received at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (t*--) . The conditional self-information E of a piece of data at instance i can be computed as the negative log of the probabilityP of occurrence of the piece of data at instance i with reference to the previous occurrence of the data at instance i-1 {i.e. E(dataildatai-i}, or: Ti = 1092 P (dataildatai_,) wherein i refers to discrete instances or samples oi data, e.g. 0, l, 2, 3, n. Thus, where conditional self-information is used, the higher the value of E, the more likely will the received data be an anomaly.
The term "probability-is used interchangeably with the term. "conditional self-information" herein, unless otherwise 20 specified.
The probability of occurrence of a current piece of data received at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (ti 1) may also be used to derive other statistical concepts, such as entropy. Entropy describes a measure for the uncertainty of a collection of pieces of data. For example, entropy can be calculated as the sum of the multiplication product between the probability of occurrence of a current piece of data i and the conditional self-information of i with reference to the previous piece of data i-1, in the data set, or: H(data set) = 1 P(i)log P(i) n=1 wherein i refers to discrete instances or samples of data in the data set, and n refers to the total number of instances in the data set. Thus, the entropy of the generated data set is compared 5 against the entropy of the reference data set to detect anomalies. Where entropy is used, the comparison may be done for the whole set, which may advantageously be more economical than comparing each probability or conditional self-information value. In an example, conditional self-information may be used to detect 10 anomalies in a one-time attack, while entropy may be used to detect anomalies during message flooding-type attacks.
In an example, for a certain vehicle model, where the speed or the vehicle is currently 20 km/h (at tis-), the probability of the vehicle speed being 25 km/h in the next sampling (ti), e.g. after every second, may be higher than the probability of the speed being 30 km/h at U. The set of actual data received (e.g. speed values) is used to generate a data set of probabilities or conditional self-information. If there are anomalies in the set of actual data, the probabilities would be different from probabilities derived from a set of data without anomalies. Therefore, detection of anomalies can be achieved bya comparison of the probabilities. Advantageously, the disclosed method is independent of the actual value or content of the data in the message since probabilities or data derived from probabilities, e.g. conditional self-information, are used instead. Further advantageously, reference data sets for every condition or every type of data are not required, thereby saving the time, memory and processing resources that would otherwise be required for classifying the data, choosing a reference data set and comparing the actual values against the appropriate reference data set. Storage space in a non-transitory computer-readable storage medium of the vehicle electronic control unit (ECU) may advantageously be saved. The electronic control unit may advantageously require less resources for processing the comparing step. Thus, the disclosed method may be implemented into any vehicle ECU without slowing down or otherwise compromising other functions of the ECU.
The disclosed method may advantageously be robust as small variations in the actual content may be detected by the disclosed method. For example, for a certain vehicle model and considering the gear or drive mode the vehicle is at, the probability of the vehicle speed being 25 km/h at tl following a speed of 20 km/h at ti i is calculated as 0.4 and this probability is entered into the generated data set. However, the reference probability for such speeds, i.e. 25 km/h at ti following a speed of 20 km/h at tai, is 0.3 as obtained from the reference data set. The percentage difference may be calculated as follows: calculated probability-reference probability X 100%, reference probability which, for the above example, is 33.3%. Although the difference in probabilities was only 0.1, the percentage of 33.3% obtained would be able to flag anomalies to a user, which is an advantage of the disclosed method. In other examples, the threshold percentage may refer to the ratio of the calculated probability to the reference probability, rather than the difference between the two. The threshold percentage may depend on the type of data, the requirements of the ECU, and/or other criteria.
Once a piece of data is identified as an anomaly, it is flagged as such. Further actions may depend on the requirements of the ECU implementing the disclosed method, termed herein as the "host ECU". For example, ahost ECU may record the current piece of data as anomalous in a log stored in the non-transitory computer-readable storage medium. In another example, a host ECU may log the anomaly and subsequently allow transmission of the anomalous data out of the ECU, e.g. to a destination ECU. In yet another example, flagging of the anomalymaybe done by indicating on the message itself. For example, a note may be added into the message to indicate that there is an anomaly therein. The host ECU may add a sub-header to the message indicating that there is an anomaly in the message. Each piece of data received in the host ECU is used to generate a probability. Thus, vetting of the data received by the host ECU is advantageously done on each data received. In other words, scanning the data is done as a matter of course, built into the disclosed method. The disclosed method may therefore be an embedded software or firmware in the host ECU. In contrast, in the prior art method of periodic scanning, much resources would be dedicated to scanning data if data was scanned as a matter of course. This is because there are many more steps involved in the prior art method as compared to the disclosed method.
The disclosed method may be a detection or a diagnostics method, whereby flagged data can be logged and retrieved at a later time to review and diagnose problems. Alternatively, or additionally, the disclosed method may be configured to prevent the spread of anomalies. In such embodiments, the anomalous piece of data may be prevented from being transmitted out of the host ECU.
Preventive measures to prevent the anomalous piece of data from propagating may include sending a signal or message to a communication bus driver and/or a communication bus hardware to stop transmission of the anomalous data. Another preventive measure may include quarantining the anomalous data within the host ECU. Yet another preventive measure may include deleting the anomalous data from the host ECU. The anomalous part of the message may be deleted and the rest of the message may be transmitted out of the host ECU. The host ECU may trigger an alarm, e.g. an audible alarm or visual alarm on a display in the vehicle, and either allow transmission of the anomalous data or quarantine the anomalous data, so that later diagnoses or checks may be done.
The reference data set may be based on an existing or historical 5 set of actual data. Actual data may be available from logs or diagnostics of an ECU. From the actual data, the probability of each piece of data evaluated against a previous piece of data may be calculated to generate the reference data set. Thus, the reference data set may comprise a historical data set comprising 10 probability of occurrence of a historical piece of data received at a historical instance of time (tj) with reference to a previous historical piece of data received at a previous historical instance of time (tj 1).
It maybe advantageous for a reference data set to be updated withup-to-date data patterns flowing through the ECU. Accordingly, at least a portion of the reference data set maybe replaced with a portion of the generated data set. The reference data set may be replaced with the generated data set at certain points. For example, the reference data set maybe replaced with the generated data set once a complete data set is generated or once the data set is 60%, 70%, 80%, 90% or more filled in. Alternatively, when new pieces of data are received, each new probability may be entered into the generated data set and, concurrently, into the reference data set to replace a reference data point in the reference data set. In yet another alternative, the replacement may be done at specific time points, e.g. after one day or one week. The reference probabilities or conditional self-information may be designed to be automatically updated with probabilities or conditional self-information of current data. Advantageously, the disclosed method may be capable of learning from the current data to improve effectiveness of the anomaly detection. Advantageously, the disclosed method does not require constant updating from a backend server.
After generating the probability of each piece of data, the probability may be entered into a data set or matrix or look-up table, termed herein as "generated data set". The data set may have a predetermined sample size. That is, the probabilities of a predetermined number of pieces of data are entered into the data set. Once the generated data set is filled up, the comparing step may be executed. When new pieces of data are received, the new probabilities may be entered into a new data set and once the new data set is filled up, the comparing step may again be executed. Alternatively, a pipelined architecture may be used, whereby after each new piece of data is received, the comparing step may be executed. The pipelined architecture may be implemented in various ways. For example, when a piece of data "i" is received, its probability is calculated and entered into a data set "i" having probabilities of a first piece of data, second piece of data, m, to this it' piece of data, the predetermined sample size being i. When an "i+1""' piece of data is received, its probability is calculated and entered into another data set "i+1" having probabilities of the second piece of data, third piece of data, to this "i+1"Ik, piece of data. The probabilities of the second piece of data, third piece of data, m, to the ith piece of data may be copied from the lb' data set to the "111-'3 data set, and the probability of the "i+1"Lu piece of data is added into the "i+1"" data set. In another example, the new probabilities may replace and update at least a portion of the probabilities in the generated data set. In such pipelined examples, the comparing step may be executed after the probability or conditional self-information of each piece of data is generated. Such pipelined process, or steps that can be done in parallel, is advantageous in that each probability generated may immediately be compared with a reference probability. A complete data set may not need to be generated before the comparing step is executed. Any delay associated with filling up a data set before comparing may advantageously be avoided. A higher rate of detection may advantageously be achieved.
The generated data set and the reference data set may have the 5 same sample size, i.e. the same number of sampled data, to advantageously facilitate scenarios where at least a portion of the generated data set or even the whole generated data set substitutes the reference data set. The sample size of a data set may depend on the type of data, therequirementsoftheECU, and/or 10 other criteria. For example, the generated data set may have a sample size suitable to meet time critical requirements of the ECU, e.g. a smaller size allows for a faster anomaly decision.
An electronic control unit suitable for use with the disclosed method may be any vehicle electronic control unit connected to the in-vehicle network. An example of a suitable ECU is an in-vehicle gateway or an in-vehicle router or switch. A gateway allows data or messages to be transmitted between the same or different networks or protocols. In some scenarios, the term.
"gateway" is interchangeable with the terms "router" and "switch". Implementing the disclosed method in an in-vehicle gateway may be advantageous since most, if not all, messages flowing through the in-vehicle network go through the gateway-to be routed. Where the vehicle has one central gateway, the method may be implemented therein. Where the vehicle has several gateways, the method maybe implemented in at least one, some or all of the gateways. As a main functionality of an in-vehicle gateway-is to route messages as quick as possible, any functionality of the gateway, such as scanning of incoming messages to detect the potential threats, will lead to additional routing time. Advantageously, the disclosed method utilizes less memory resources and therefore may not slow down or compromise the main functions of the gateway. Another example of a suitable ECU is a telematics unit or data communication module since messages received by the vehicle from an external network, e.g. a telecommunications network or vehicle-to-vehicle network, may be received by the telematics unit. Messages received from external networks may be transmitted to the in-vehicle gateway for communication to other vehicle systems if necessary. Hence, the "in-vehicle network" may also include messages coming from external of the vehicle or external networks.
Accordingly, in a second aspect, there is provided an in-vehicle gateway comprising: one or more communication interfaces configured to receive and transmit messages comprising data; non-transitory computer-readable storage medium comprising computer-readable instructions stored thereon; and a processor configured to execute the computer-readable instructions, wherein the computer-readable instructions comprise an anomaly detection module configured to: generate a data set comprising probability of occurrence of a current piece of data received from the communication interface at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (till); compare the generated data set with a reference data set stored in the non-transitory computer-readable storage medium; if the comparison exceeds a threshold percentage, flag the current piece of data as anomalous.
The anomaly detection module may be configured as a detection or a diagnostics module, whereby flagged data can be recorded in a log and retrieved at a later time to review and diagnose problems. Alternatively, or additionally, the anomaly detection module may be further configured to prevent the anomalous piece of data from being transmitted out of the gateway. Exemplary preventive measures may be as disclosed herein.
The reference data set may one disclosed herein. For example, the reference data set may comprise a historical data set comprising probability of occurrence of a historical piece of data received at a historical instance of time (tj) with reference to a previous historical piece of data received at a previous historical instance of time (tj-)).
The threshold percentage may depend on criteria disclosed herein.
The generated data set and the reference data set may have the same sample size, to facilitate scenarios whereat least a portion of the reference data set is replaced with a portion of the generated data set. Such scenarios are advantageous to keep the reference data set updated with current data patterns flowing through the ECU.
The anomaly detection module may be configured to execute the comparing step after the probability of each piece of data is generated. Advantageously, an anomaly decision may be obtained 20 quicker.
BRIEF DESCRIPTION OF DRAWINGS
Fig. la illustrates the electrical architecture of a vehicle 25 electronic control unit (ECU) 150 according to an embodiment of the invention.
Fig. lb illustrates the software architecture 100 of an in-vehicle gateway according to an embodiment of the present 30 disclosure.
Fig. 2 illustrates the creation of a reference data set 300 from a velocity data set 200.
Fig. 3 illustrates the creation of a data set 3000 generated from newly received velocity data 2200.
Fig. 4 illustrates the comparison of data set 3000 and reference 5 data set 300 to detect anomalies.
Fig. 5a illustrates a pipelined architecture according to an embodiment, where multiple generated data sets are provided to allow the comparison to be executed after the probability of each 10 piece of data is generated.
Fig. 5b illustrates a pipelined architecture according to another embodiment, where a single data set is updated with the probability of newly received data and the comparison is executed 15 after each update.
DETAILED DESCRIPTION
Hereinafter, exemplary embodiments of the disclosure will be described in detail with reference to the accompanying drawings. Exemplary embodiments of the disclosure have alsobeendescribed herein with reference to examples. The description of this disclosure is provided for the purpose of explaining the principles of the invention and its practical application, thereby enabling a person skilled in the art to understand the invention for various exemplary embodiments and with various modifications as are suited to the particular use contemplated. The description is not intended to be exhaustive or to limit the invention to the precise embodiments disclosed. Modifications and equivalents will be apparent to practitioners sXilled in this art and are encompassed within the spirit and scope of the appended claims.
A method of detecting anomalous data in an in-vehicle network is provided. The method comprises receiving messages comprising data by a vehicle electronic control unit; generating a data set comprising probability of occurrence of a current piece of data received at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (t1 1) ; comparing the generated data set with a reference data set; and if the comparison exceeds a threshold percentage, flagging the current piece of data as anomalous.
Fig. la shows an illustration of the electrical architecture of a vehicle electronic control unit (ECU) 150 according to an embodiment of the invention. ECU 150 receives messages via communication bus 152, e.g. CAN bus, Flexray, LIN, etc, from another node 160, such as another ECU. There may be multiple communication buses 152 communicating with other nodes 160. The method, or at least some steps of the method, may be a computer-implemented method. For example, the generating step, the comparing step and the flagging step may be implemented by software as described below. The vehicle electronic control unit 150 comprises a non-transitory computer-readable storage medium 154 which stores the software or the anomaly detection module, the reference data set as well as the records or logs of the data identified as anomalies or non-anomalies, i.e. normal. Suitable non-transitory computer-readable storage media of an ECU is not particularly limited, and may typically include flash memory, read-only memory, non-volatile memory, non-volatile random access memory, and solid state drives. The storage medium maybe a dedicated secure memory for security functions or may be a storage medium shared with other functions of the ECU. For example, ECU 150 may comprise a hardware security module (HSM) 156 which generates and manages cryptographic keys for encryption and decryption of sensitive data going through ECU 150. HSV 156 itself may comprise secure non-transitory computer-readable storage medium, in which the disclosed software may alternatively be stored. In another example, the records or logs of the data identified as anomalies or non-anomalies may be stored in a separate internal memory 158, e.g. an EEPROM or flash memory, of the ECU 150 or even in an external memory chip 158' connected to ECU 150 via communication bus 152', e.g. SPI.
The non-transitory computer-readable storage medium 154 also stores computer-readable instructions necessary for the electronic control unit (ECU) to perform its functions. Computer-readable instructions form the software architecture of the ECU and may include, but are not limited to, software, application programs, firmware, drivers of hardware, transport protocols, and/or an operating system_ As is -rmown to a person of skill in the art, code may be implemented in various layers of a computing system. The lowest layer of code (physical or hardware layer) transmits and receives raw bits from the hardware to serve the layer above it. The highest layer of code interacts directly with the end user. A program or module providing a particular function may encompass code traversing several layers.
ECU 150 may also comprise one or more processors or microprocessor core 157 configured to execute the computer-readable instructions. ECU 150 may further comprise any other peripheral components 159 according to the requirements of ECU 150. The components 154, 156, 157, 158 and 159 may be connected to each other and communicate with each other via an internal bus interface 155, e.g. crossbar bus, according to its communication protocols.
In an embodiment, the ECU is an in-vehicle gateway configured to perform the disclosed method. Therefore, the computer-readable instructions may include instructions to: generate a data set comprising probability of occurrence of a current piece of data received from the communication interface at a current instance of time (t,) with reference to a previous piece of data received at a previous instance of time (ti H; compare the generated data 5 set with a reference data set stored in the non-transitory computer-readable storage medium; If the comparison exceeds a threshold percentage, flag the current piece of data as anomalous. The instructions may be developed as a package Or module or set of instructions to perform the disclosed method of 10 detecting anomalous data in an in-vehicle network.
Accordingly, an in-vehicle gateway is provided, the in-vehicle gateway comprising non-transitory computer-readable storage medium having computer-readable instructions stored thereon. The computer-readable instructions comprise an anomaly detection module configured to: generate a data set comprising probability of occurrence of a current piece of data received from the communication interface at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (till); compare the generated data set with a reference data set stored in the non-transitory computer-readable storage medium; if the comparison exceeds a threshold percentage, flag the current piece of data as anomalous.
The pieces of data are received by the in-vehicle gateway within messages, such as CAN bus massages or data packets. Hence, within the electrical architecture of the gateway, one or more communication interfaces of the gateway are included and configured to receive and transmit the messages comprising data. A communication interface may include wired interfaces or wireless or network interfaces, e.g. a CAN bus interface or a Wi-Fi network interface. A gateway may be a computing device having, within its electrical architecture, one or more processors or microcontrollers configured to execute the computer-readable instructions. It is understood that the components within the electrical architecture of the gateway or other ECU suitable to implement the disclosed method may vary depending on the requirements of the computing system.
Fig. lb shows an illustration of the software architecture 100 of an in-vehicle gateway according to an embodiment of the invention. In this embodiment, the gateway receives and transmits messages through a CAN bus. In this embodiment, the software architecture of the gateway comprises six layers: hardware layer 102, CAN driver layer 104, communication interface layer 106, transport protocol/protocol data unit router 108, runtime environment 110 and application layer 112. The anomaly detection module 120 in this embodiment is implemented between the driver layer 104 and communication interface layer 106. However, the anomaly detection module may be implemented in any other layer, for example as part of the driver layer 104. Implementation in lower layers advantageously allow for faster processing time as the instructions are of a layer closer to the hardware executing the instructions, e.g. the processor (157 in Fig. la). The anomaly detection module 120 may therefore be considered an embedded software or firmware.
CAN message 2000 comprising data 2200 is transmitted through the CAN bus and received by the hardware layer 102 of the gateway. CAN message 2000 maybe stored in ahardware buffer or a transitory storage medium in the hardware layer 102 and the data 2200 in message 2000 is extracted in the driver layer 104. Data 2200 may also be stored in a transitory storage medium of the gateway. The extracted payload or data 2200 is passed through anomaly detection module 120 to detect for anomalies.
Anomaly detection module 120 is capable of machine learning as well as detecting and/or preventing anomalies for vehicle applications in a real-time range of milliseconds.
To illustrate the method implemented in anomaly detection module 120, velocity data is used as an example, though any type of data can be used with the method. Fig. 2 illustrates how a reference data set or matrix 300 is created. The header Vo to V, of matrix 300 represents the range of velocities capable of being attained by the vehicle, whereby Vc is the lowest velocity, V, is the highest velocity that can be attained, and V], V2 are fixed intervals of velocity between Vi, and Vfl. For illustration, an example could be that the header Ve is 0 km/h, the header V1 is 1 km/h, _. and the header V, is 200 km/h. Velocity data set 200 15 contains velocity data sequentially received during operation (or simulated operation) of the vehicle. Velocity data set 200 is used to train a reference data set or matrix 300 with conditional self-information E. The conditional self-information Eim,if of two consecutive velocity values at time tml and tmis then calculated. Say the first sampled velocity data V-p,t. at tj] in data set 200 is 5 km/h and the second sampled velocity data Vsecond at tj is 8 km/h, the conditional self-information E_,econd Of Vserond based on Vfirst is calculated and entered into matrix 300 in the box or E8,5. As more velocity data samples in data set 200 are processed, the boxes of matrix 300 get filled up with new conditional self-information values and/or the existing conditional self-information values get updated or recalculated. The calculations of Emmj may take into account the characteristics of the data set. For example, for a velocity data set, the following exemplary characteristics may be taken into account: the vehicle model, drive mode (e.g. coo mode, comfort mode, sport mode), driving pattern (e.g. aggressive driving profile), environment (e.g. rain, snow), driving location (e.g. highway driving, city driving). Alternatively, different matrices 300 can be populated for different characteristic conditions. For example, matrix 30C-can be populated for highway driving, matrix 3002 can be populated for city driving, etc. Further velocity data sets 200 can be used to train matrix 300 so that there are sufficient samples of velocity data for the matrix 300 to be trained with reasonable accuracy. Training of an initial reference data set or matrix 300 is done prior to the comparing step of the disclosed method, and in some embodiments, during manufacture on the vehicle ECU or during development of the software architecture of the vehicle ECU. The trained matrix 300 is then stored in the non-transitory computer-readable storage medium of the electronic control unit. As compared to prior art solutions based on content, analyses on the data content in the disclosed method, e.g. classification and characterizing of content, is advantageously conducted prior to the actual detection of anomalies in the in-vehicle network since the analyses are built into the conditional self-information or probabilities in the trained matrix 300. Thus, the disclosure is able to provide an efficient detection system that can react to detect anomalies in real-time. In addition, the trained matrix 300 maybe based on unadulterated data and therefore does not need to have anomalies built into it in order to detect anomalies.
Thus, any historical data set comprising probability of occurrence of a historical piece of data received at a historical instance of time (t) with reference to a previous historical piece of data received at a previous historical instance of time (tj-) may advantageously be used as a reference data set.
Reference data set or matrix 300 may be continuously trained with values from newly received velocity data 2200 or a generated data set of probabilities 3000 generated from the newly received velocity data 2200 (as illustrated in Fig. 3). Advantageously, the more samples of velocity data there are, the better or mare refined will be the training of matrix 300. In addition, updated characteristics of the newly received, real-time velocity data may be considered and built into matrix 300. As newly received 5 data can be reused to train the reference data set 300, a constant amount of memory resources is required, therefore a lightweight detection module is provided. In this embodiment, at least a portion of matrix 300 may be replaced with a portion of the generated data set 3000. For example, one, some, or all E' values 10 derived from the newly received pieces of data in the generated data set 3000 may directly replace the E values in matrix 300.
Other than being used to train reference data set 300, each piece of newly received, real-time velocity data 2200 is used to generate conditional self-information with reference to velocity data received at the previous instance of time (ti_i). A data set or matrix 3000 is created containing the generated E'-,t. Generated data set 3000 is filled up the same way as matrix 300.
As shown in Fig. 4, generated data set or matrix 3000 is then compared with reference data set or matrix 300 and if the comparison exceeds a threshold percentage, data 2200 is flagged as anomalous. Where generated data set 3000 is just beginning to fill up, the E' values may not be accurately reflected compared to reference data set 300 since the sample size of data set 3000 is small. The comparing step may therefore be programmed to commence after a certain duration, e.g. after a certain sample size is reached or after a certain duration of vehicle operation.
Alternatively, when the generated data set 3000 has not yet been sufficiently trained, the threshold percentage may be set higher (since the difference between the E' and E values could be larger) or a tolerance of the threshold percentage may be set at a larger value so that the untrained E' values in data set 3000 are not falsely detected as positive for anomalies. Furthermore, where one matrix 300 is used, which takes into account the different characteristics and conditions of the data, the threshold percentage may be set higher or a tolerance of the threshold percentage may be set at a larger value. This is because the E values in such a matrix 300 are reflective of a combination of characteristics, e.g. city driving as well as highway driving, while the real-time E' values in matrix 3000 are only reflective of that real-time condition. In yet another alternative, the threshold percentage may be dynamically defined to reflect the real-time conditions. For example, during city driving, one threshold value is used, while during highway driving, another threshold value is used. On the other hand, where multiple matrices 300 are used, each reflecting different characteristics and/or conditions, the threshold percentage of each may be tightened or set at a higher standard, i.e. set at a lower value, or a tolerance of the threshold_ percentage may be set at a lower value. Where multiple matrices 300 are used, in order to retrieve the appropriate matrix 300 for the comparing step, data from other vehicle systems can be pulled for use. For example, the host ECU can pull CPS data from the vehicle's navigation system to ascertain whether the vehicle is on small roads or on a highway, and upon ascertaining, the appropriate matrix 300 is retrieved from the non-transitory storage medium for the comparing step.
The real-time E' values may then be used to train this matrix 300 or update the E values in this matrix 300.
The threshold percentage is determined or defined by practical situations. For certain types of data, the threshold percentage may be determined empirically, considering the historical E or E' values. For other types of data, the threshold percentage may be a constant. For some types of data, the threshold percentage may be defined together with a tolerance value, e.g. threshold percentage ± tolerance. The tolerance value may be determined based on how a range of historical E or E' values deviate or differ from each other.
To decrease the number of false positives or false negatives, a 5 proper window size must be chosen. That is, the sample size of received data or the generated data set must be sufficient enough. However, in a linear, sequential method, the result of the comparison and anomaly detection can only be obtained after collecting the required number of samples. This may not be fast 10 enough for certain scenarios. Accordingly, in an embodiment, a pipelined architecture is provided, wherein the comparing step can be executed after the probability of each piece of data is generated.
Fig. 5a illustrates an embodiment of a pipelined process, wherein a first data set 30004having the required sample size of E' values is generated from real-time velocity data Vfirst to Vi. The E' values in data set 30004 (E'mo, E'hc, E'c,4, .4) represent conditional self-information values calculated based on the real-time velocity data, each maybe the same or different to each other depending on the conditional self-information calculations. A second generated data set 30002 is provided with the E' values of the second piece of data, third piece of data, to the 1'3 piece of data copied from the first generated data set 30004. When a subsequent piece of data V111 is received, its E'1,1 r value is calculated and entered into generated data set 30002, and the existing E' values in data set 30002 are updated if necessary due to the entry of the F' value. value. Again, the E' values in generated data set 30002 (E'0,0, E'i,o, may each be the same or different to each other depending on the conditional self-information calculations. Generated data sets 30003, 30004 and so on are provided, depending on the requirements of the anomaly detection system 120, since increasing the number of generated data sets will linearly increase the amount of memory resources required.
Fig. 5b illustrates another embodiment of a pipelined process, in which there is only one generated data set 3000. Once the data set 3000 has the required sample size of conditional self-information values generated from teal-time velocity data V-1,st to V1, the conditional self-information E'1,,g of a subsequent newly received data Vi+± is generated and entered into the same data set by replacing and updating the E' value of the relevant box. The E' values in data set 3000 in Fig. 5b (E10,c represent conditional self-information values calculated based on the real-time velocity data, each maybe the same or different to each other depending on the conditional self-information calculations. Thus, the generated data set still comprises the required sample size and can proceed with the comparing step.
In the pipelined architecture embodiments, as the data set comprises the required sample size, the conditional self-information values can be considered sufficiently accurate so that when comparing with the reference data set, false positives or false negatives may be avoided. Thus, a pipelined method is advantageously provided, whereby the comparing step can be executed after the probability of each piece of data is generated.
Therefore, when new data is received, its conditional self-information is calculated and entered into a generated data set or matrix 3000, either filling a blank space in a matrix 3000, or replacing and/or updating a value in the matrix 3000. The conditional self-information of the new data is also entered into the reference data set or matrix 300 by replacing and/or updating a value in the matrix 300. Advantageously, since both matrix 3000 and matrix 300 have fixed sizes, the memory required to store the matrices is constant and should not increase unless future requirements of the ECU necessitate modification of the size of the matrices.
Once an anomaly is detected, the anomaly may recorded in a log stored in the non-transitory storage medium and a signal is sent to the CAN driver layer 104 and the hardware layer 102 (see dotted arrows in Fig. 1) to prevent the anomalous piece of data from being transmitted out of the ECU. If data 2200 is not anomalous, i.e. is normal, driver layer 104 (or any one of the layers depending on how the routing is coded) may instruct message 2000 to be transmitted to a destination ECU based on header information in message 2000.
Advantageously, the anomaly detection module 120 can identify both bad injection (spoofing attacks) and replay attacks by comparing the conditional self-information of a sequence of data (velocity data in this example) against the conditional self-information of a previously trained set of unadulterated data. Advantageously, low memory resources are required and detection can be done in real-time. Advantageously, because of the compactness of the data sets in the anomaly detection module 120, the other functions of the ECU are not compromised and any upgrading of the ECU to add or improve its functions may even be possible. Advantageously, a small overhead of code or machine-readable instructions as disclosed herein is required to implement the disclosed method.
Claims (15)
- PATENT CLAIMS1. A method of detecting anomalous data in an in-vehicle network, the method comprising: receiving messages comprising data by a vehicle electronic control unit; generating a data set comprising probability of occurrence of a current piece of data received at a current instance of time (ti) with reference to a previous piece of data received at a previous instance of time (ti-±); comparing the generated data set with a reference data set stored in a non-transitory computer-readable storage medium of the electronic control unit; if the comparison exceeds a threshold percentage, flagging the current piece of data as anomalous.
- 2. The method of claim. 1, further comprising recording the current piece of data as anomalous in a log stored in the non-transitory computer-readable storage medium.
- 3. The method of claim. 1 or 2, further comprising preventing the anomalous piece of data from being transmitted out of the electronic control unit.
- 4. The method of any preceding claim, wherein the reference data set comprises a historical data set comprising probability of occurrence of a historical piece of data received at a historical instance of time (t.j) with reference to a previous historical piece of data received at a previous historical instance of time (tj -).
- 5. The method of any preceding claim, wherein the generated data set and the reference data set have the same sample size.
- 6. The method of any preceding claim, further comprising replacing at least a portion of the reference data set with a portion of the generated data set.
- 7. The method of any preceding claim, wherein the comparing step is executed after the probability of each piece of data is generated.
- 8. The method of any preceding claim, wherein the electronic control unit is an in-vehicle gateway.
- 9. An in-vehicle gateway comprising: one or more communication interfaces configured to receive and transmit messages comprising data; non-transitory computer-readable storage medium comprising computer-readable instructions stored thereon; and a processor-configured to execute the computer-readable instructions, wherein the computer-readable instructions comprise an anomaly detection module configured to: generate a data set comprising probability of occurrence of a current piece of data received from the communication interface at a current instance of time (tt) with reference to a previous piece of data received at a previous instance of time (t1-1); compare the generated data set with a reference data set stored in the non-transitory computer-readable storage medium; if the comparison exceeds a threshold percentage, flag the current piece of data as anomalous.
- 10. The gateway of claim 9, wherein the anomaly detection module is further configured to record the current piece of data as anomalous in a log stored in the non-transitory computer-readable storage medium.
- 11. The gateway of claim 9 or 10, wherein the anomaly detection module is further configured to prevent the anomalous piece of data from being transmitted out of the gateway.
- 12. The gateway of any one of claims 9-11, wherein the reference data set comprises a historical data set comprising probability of occurrence of a historical piece of data received at a historical instance of time (ti) with reference to a previous historical piece of data received at a previous historical instance of time (tpi).
- 13. The gateway of any one of claims 9-12, wherein the generated data set and the reference data set have the same sample size.
- 14. The gateway of any one of claims 9-13, further comprising replacing at Least a portion of the reference data set with a portion of the generated data set.
- 15. The gateway of any one of claims 9-14, wherein the anomaly detection module is configured to execute the comparing step after the probability of each piece of data is generated.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1820657.3A GB2580025A (en) | 2018-12-19 | 2018-12-19 | Anomaly detection system for in-vehicle network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1820657.3A GB2580025A (en) | 2018-12-19 | 2018-12-19 | Anomaly detection system for in-vehicle network |
Publications (2)
Publication Number | Publication Date |
---|---|
GB201820657D0 GB201820657D0 (en) | 2019-01-30 |
GB2580025A true GB2580025A (en) | 2020-07-15 |
Family
ID=65147326
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB1820657.3A Withdrawn GB2580025A (en) | 2018-12-19 | 2018-12-19 | Anomaly detection system for in-vehicle network |
Country Status (1)
Country | Link |
---|---|
GB (1) | GB2580025A (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110764944B (en) * | 2019-10-22 | 2023-05-16 | 东软睿驰汽车技术(沈阳)有限公司 | Abnormality detection method and device |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010111748A1 (en) * | 2009-04-01 | 2010-10-07 | Curtin University Of Technology | Systems and methods for detecting anomalies from data |
WO2012140601A1 (en) * | 2011-04-13 | 2012-10-18 | Bar-Ilan University | Anomaly detection methods, devices and systems |
US20170192871A1 (en) * | 2015-12-30 | 2017-07-06 | International Business Machines Corporation | Detecting anomalous sensors |
EP3343519A1 (en) * | 2017-01-03 | 2018-07-04 | The Boeing Company | Reducing nuisance fault indications from a vehicle using physics based and data driven models |
-
2018
- 2018-12-19 GB GB1820657.3A patent/GB2580025A/en not_active Withdrawn
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010111748A1 (en) * | 2009-04-01 | 2010-10-07 | Curtin University Of Technology | Systems and methods for detecting anomalies from data |
WO2012140601A1 (en) * | 2011-04-13 | 2012-10-18 | Bar-Ilan University | Anomaly detection methods, devices and systems |
US20170192871A1 (en) * | 2015-12-30 | 2017-07-06 | International Business Machines Corporation | Detecting anomalous sensors |
EP3343519A1 (en) * | 2017-01-03 | 2018-07-04 | The Boeing Company | Reducing nuisance fault indications from a vehicle using physics based and data driven models |
Also Published As
Publication number | Publication date |
---|---|
GB201820657D0 (en) | 2019-01-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11665178B2 (en) | Methods and arrangements for message time series intrusion detection for in-vehicle network security | |
US11411681B2 (en) | In-vehicle information processing for unauthorized data | |
Lokman et al. | Intrusion detection system for automotive Controller Area Network (CAN) bus system: a review | |
US11570184B2 (en) | In-vehicle network system, fraud-detection electronic control unit, and fraud-detection method | |
US20220350888A1 (en) | Methods and arrangements for multi-layer in-vehicle network intrusion detection and characterization | |
US20190012488A1 (en) | Method, apparatus and device for storing vehicle travelling data | |
JP2021036419A (en) | Context system for providing cyber security for connected vehicles | |
RU2018111478A (en) | System and method for creating rules | |
CN110120935B (en) | Method and device for identifying anomalies in data flows in a communication network | |
US20200014758A1 (en) | On-board communication device, computer program, and message determination method | |
Taylor et al. | Probing the limits of anomaly detectors for automobiles with a cyberattack framework | |
EP3857846A1 (en) | Electronic controller security system | |
US20230275877A1 (en) | Visual sensor validation system | |
CN111903095B (en) | Detection device and method thereof, and recording medium | |
GB2580025A (en) | Anomaly detection system for in-vehicle network | |
Rajapaksha et al. | Improving in-vehicle networks intrusion detection using on-device transfer learning | |
JP2022542251A (en) | Multistate messaging anomaly detection for securing broadcast networks | |
US12047398B2 (en) | Security reporting via message tagging | |
EP4274160A1 (en) | System and method for machine learning based malware detection | |
WO2019207764A1 (en) | Extraction device, extraction method, recording medium, and detection device | |
Lee | Evaluation of the architecture alternatives for real-time intrusion detection systems for connected vehicles | |
US10560317B2 (en) | Subscription to a subset of switching events | |
Grammatikakis et al. | DoS Detection on In-Vehicle Networks: Evaluation on an Experimental Embedded System Platform | |
KR20200124470A (en) | Apparatus for gateway of a vehicle, system having the same and method for detect invasion thereof | |
US20200226257A1 (en) | System and method for identifying activity in a computer system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |