Systems and methods for protecting vehicles

Abstract

We provide systems, methods, and programs for protecting vehicles from theft. [Solution] The method includes monitoring transmissions via an in-vehicle network; determining that a rogue device is connected to the in-vehicle network based on at least two of the content of at least one message, the electrical characteristics of the message transmission, and the vehicle context; determining that the rogue device is used to perform at least one of stealing a vehicle and bypassing a vehicle's security or access system; recording and reporting information related to the rogue component; and performing at least one of preventing or mitigating attacks on the vehicle and preventing theft or misuse of the vehicle.

Description

【Technical Field】 【0001】 The present invention generally relates to protecting a vehicle. More specifically, the present invention relates to protecting a vehicle from unauthorized connection of a device to an in-vehicle network of the vehicle. 【0002】 Background of the Invention Modern vehicles include a complex system consisting of multiple components connected by an in-vehicle communication network, channels, and interfaces. Attacks on vehicles may involve connecting a unit or device to an in-vehicle network, an in-vehicle communication bus, or other in-vehicle communication channels. Therefore, to protect a vehicle from malicious entities, it is necessary to protect the in-vehicle communication network, bus, or channel. 【0003】 Summary of the Invention One embodiment of the present invention includes monitoring transmissions via an in-vehicle network and determining that an unauthorized device is used to connect to the in-vehicle network, steal the vehicle, and / or bypass the vehicle's security system or access system based on at least two of the content of at least one message, the electrical characteristics of the message transmission, and the context of the vehicle, recording and reporting information related to the unauthorized component, performing at least one of preventing or reducing an attack on the vehicle, and preventing theft or unauthorized use of the vehicle. A method for protecting a vehicle from theft is included. A system including a data processing circuit can be configured to execute the method. A computer program including instructions for causing a computer to execute the method when the program is executed by the computer. 【0004】 The method may include calculating a set of signatures for each set of components connected to the in-vehicle network based on the electrical characteristics of the transmission over the in-vehicle network, and determining that a rogue component is connected to the in-vehicle network is based on associating the electrical characteristics of the transmission with the set of signatures. 【0005】 The method may include determining that the electrical characteristics of a transmission match, at least partially, the electrical characteristics represented by a signature, and updating the signature according to the electrical characteristics of the transmission. The method may also include creating a signature based on previously unseen electrical characteristics of one or more transmissions. Determining that a rogue component is malicious may be based on the vehicle's condition. 【0006】 Determining that a malicious component is malicious may be based on examining messages sent by the malicious component and identifying operations that the malicious component attempts to perform. Methods may include preventing the malicious component from communicating over the network. Methods may also include controlling or activating components within the vehicle to thus protect the vehicle from the malicious component. 【0007】 The method may include determining, based on matching the message content with the component's signature, whether a message that appears to originate from a component was actually sent from the component, and whether the rogue component is connected to the in-vehicle network. The signature may be received from a server. One embodiment determines that the rogue component is used to perform at least one of the following: coding a key, unlocking a vehicle door, and starting a vehicle engine. One embodiment determines that the rogue component is physically connected to the in-vehicle network. 【0008】 Based on at least one of commands, configuration elements, events, and vehicle states or contexts, one embodiment performs at least one of the following: authenticating a rogue component, ignoring a rogue component, deleting a signature, creating a signature representing a new component, and calculating or recalculating a component signature. Other aspects and / or advantages of the present invention are described herein. 【0009】 Non-limiting examples of embodiments of the present disclosure are described below with reference to the figures accompanying this specification, which are listed after this paragraph. Identical features shown in multiple figures are generally labeled with the same label in all figures in which those features appear. Labels that label icons representing a given feature of an embodiment of the present disclosure in the figures may be used to refer to the given feature. Dimensions of features shown in the figures have been selected for convenience and clarity of presentation and are not necessarily proportional to actual size. For example, some dimensions of elements may be emphasized relative to others for clarity, and several physical components may be contained within a single functional block or element. Furthermore, where appropriate, reference numbers may be repeated between figures to indicate corresponding or similar elements. 【0010】 The subject matter considered to be the present invention is specifically pointed out and expressly claimed in the concluding section of this specification. However, the present invention, with respect to both its object, features and advantages, as well as its configuration and method of operation, may be best understood by referring to the following embodiments for carrying out the invention when read in conjunction with the accompanying drawings. Embodiments of the present invention are shown as examples, not as limitations, in the figures of the accompanying drawings, where similar reference numerals indicate similar or identical elements. [Brief explanation of the drawing] 【0011】 [Figure 1] A block diagram of a computing device according to an exemplary embodiment of the present invention is shown. [Figure 2]This shows a system according to an exemplary embodiment of the present invention. [Figure 3] This shows a system according to an exemplary embodiment of the present invention. [Figure 4A] This shows an object in memory according to an exemplary embodiment of the present invention. [Figure 4B] This illustrates a timeline of messages and metadata according to an exemplary embodiment of the present invention. [Figure 5] A flowchart of a method according to an exemplary embodiment of the present invention is shown. [Modes for carrying out the invention] 【0012】 Embodiments of the present invention provide and enable novel methods for identifying, tracking, discovering, or determining that a rogue device is connected to an in-vehicle network. More specifically, embodiments of the present invention identify or determine that a rogue device is connected to an in-vehicle network and is used to bypass the vehicle's security system for the purpose of stealing the vehicle or otherwise misusing the vehicle. 【0013】 Refer to Figure 1, which shows a non-limiting block diagram of a computing device or computing system 100 that may be used by or included in a system according to some embodiments of the present invention. For example, the anti-theft unit described further herein may be a component of the computing device 100 or may include a component of the computing device 100. 【0014】 In some embodiments, the computing device (or system) 100 includes a controller 105 which is a hardware controller. For example, the computer's hardware processor or hardware controller 105 may be, or include, a central processing unit processor (CPU), a field-programmable gate array (FPGA), or other chip, or any suitable computing device or computing device. In some embodiments, the computing system 100 includes memory 120, an operating system (OS) 115, executable code 125, a storage system 130, and I / O components 135 which may be detachably connected to the computing device 100. In some embodiments, the controller 105 (or possibly one or more controllers or processors across multiple units or devices) is configured to perform the methods described herein (e.g., by executing software or code) and / or to perform or function as various modules, units, etc., for example, by executing software or by using dedicated circuitry. Multiple computing devices 100 may be included, and one or more computing devices 100 may exist, function, or act as components of a system according to some embodiments of the present invention. 【0015】 In some embodiments, OS115 includes any code segments (similar to the executable code 125 described herein) designed and / or configured to perform tasks involving the coordination, scheduling, arbitration, monitoring, control, or otherwise management of the operation of the computing device 100, such as scheduling the execution of a software program or enabling a software program or other module or unit to communicate. For example, OS115 may be a commercial operating system such as QNX or Linux. 【0016】 In some embodiments, memory 120 is hardware memory. For example, memory 120 may be, or may include, a machine-readable medium for storing software, such as random-access memory (RAM), read-only memory (ROM), a memory chip, flash memory (referred to herein as flash), volatile memory and / or non-volatile memory, or other suitable memory units or storage units. Memory 120 may be, or may include, multiple, possibly different memory units. In some embodiments, memory 120 is a non-temporary-readable medium of a computer or processor, or a non-temporary storage medium of a computer, such as RAM. Some embodiments may include a non-temporary storage medium that, when executed, stores instructions causing a processor to perform the methods disclosed herein. 【0017】 The executable code 125 may be software, an application, a program, a process, a task, or a script. The programs, processes, tasks, applications, or software referenced herein may be firmware, middleware, microcode, hardware description languages, etc., which, when executed by any type of instruction—for example, by one or more hardware processors or controllers 105—cause a processing system or processing device (e.g., system 100) to perform the various functions described herein. In some embodiments, the executable code 125 is executed by the controller 105, possibly under the control of an operating system 115. For example, the executable code 125 may be an application within an anti-theft unit. 【0018】 The storage system 130 may be or include any storage unit, architecture, or hardware. For example, the storage system 130 may be or include a hard drive or disk, a Universal Serial Bus (USB), etc. In some cases, the computing device 100 is a server and the storage system 130 is a solid-state drive (SSD) or hard disk drive. 【0019】 The I / O component 135 may be used for connection (for example, via included ports), and may include a mouse, keyboard, touchscreen or pad, or any suitable input device. The I / O component may include one or more screens, touchscreens, displays or monitors, speakers, and / or any other suitable output devices. Any applicable I / O component may be included in or connected to the computing device 100 as shown by the I / O component 135, for example, a wired or wireless network interface card (NIC) or chip, a Universal Serial Bus (USB) device, or an external hard drive may be included in the I / O component 135. Although vehicles such as cars are primarily described and / or referenced herein, other vehicles such as ships, trains, and aircraft are also applicable. 【0020】 Refer to Figure 2, which shows a system 200 according to an exemplary embodiment of the present invention. As shown in Figure 2, the system 200 may be a vehicle comprising a plurality of components, elements, or units 260, each of which may be an electronic control unit (ECU) or a sensor comprising a CPU, memory, and communication elements, etc. For brevity and clarity, elements 260 are referred to herein as ECUs. For brevity, the system 200 is also referred herein as vehicle 200 or car 200. 【0021】 For example, the first ECU260 may control the brake system of the vehicle 200, the second ECU60 may control the engine, the third ECU260 may control the infotainment system of the vehicle 200, and the fourth 260 element may be a hydraulic sensor. For clarity and brevity, the ECU260 may be collectively referred to as ECU260 (including the plural) or individually below. The system 200 may be referred to as vehicle 200 for brevity in this specification, but it should be understood that any relevant system is applicable. 【0022】 As further shown in Figure 2, system 200 may include in-vehicle networks 271 and 272, which are used not only to enable the ECU 260 to communicate, but also to enable the ECU 260 to control and communicate with components or elements within system 200. System 200 may include switches, hubs, or bridges 273 that connect networks 271 and 272. Switches, hubs, or bridges 273 may be configurable devices that can be configured to connect or disconnect networks 271 and 272, or they may be configured to selectively allow messages to propagate from one network to another. It will be understood that any number of networks, such as networks 271 and 272, can be included in the system and interconnected by, for example, several switches, hubs, or bridges 273. 【0023】 For clarity, in this specification, in-vehicle network 271 and in-vehicle network 272 are referred to as network 271 and network 272, respectively. For example, network 271 may be a high-speed Controller Area Network (CAN) bus that enables ECU 260 to control the brake system of vehicle 200, and network 272 may be a medium-speed CAN bus that enables ECU 260 to control the infotainment system. 【0024】 Networks 271 and 272 may be any suitable bus or network infrastructure, may include it, or may comprise it, and can support any suitable protocol. For example, in-vehicle networks 271 and 272 may be an Ethernet network, a CAN network or bus, or a combination thereof. Components connected to ECU 260 may use any communication protocol or standard to communicate via networks 271 and 272. For example, protocols or standards such as Internet Protocol (IP), Transmission Control Protocol (TCP), Scalable Service-Oriented MiddlewarE over IP (SOME / IP), Universal Measurement and Calibration (XCP), Diagnostics over Internet Protocol (DoIP), and Unified Diagnostic Services (UDS) may be used. Without departing from the scope of the present invention, any other applicable protocol can also be used. For clarity and brevity, although many elements of networks 271 and 272 are implied, such as switches, routers, gateways connecting these two networks, etc., they are not shown. It is recognized that embodiments of the present invention are not limited by the nature of networks 271 and 272. 【0025】 As further illustrated, system 200 includes a vehicle theft prevention (VTP) unit 250, which is connected to the in-vehicle communication infrastructure as shown. For example, as shown, VTP 250 is connected to both in-vehicle networks 271 and 272. VTP 250 may be a component or a part of computing device 100, or may include them. For example, VTP 250 typically includes a memory 120, a controller 105, executable code 125, and an I / O component 135. The I / O component 135 enables VTP 250 to physically detect networks 271 and 272, receive network transmissions, messages, frames, or data packets from networks 271 and 272, process the received messages or packets, store data and information in storage 130, and transmit messages or packets via networks 271 and 272. 【0026】 VTP 250 can be installed or included in the system at various stages or times. For example, VTP 250 may be included in the vehicle by the vehicle manufacturer, or VTP 250 may be installed by the vehicle owner, for example, as an application or service of one of the ECUs 260. The information used by VTP 250 described herein, such as content signature 401, hardware signature 402, rules 403, context 404, configuration 405, and device 406, can be stored or included in VTP 250 at various stages or times. For example, objects in memory 121 can be stored in memory 121 by the vehicle manufacturer, by the vehicle owner, or by a remote server. 【0027】 For the sake of clarity and brevity, network transmissions, messages, frames, and data packets may be collectively referred to as transmissions (including plural), messages (including plural), frames (including plural), and data packets (including plural) below, or they may be referred to individually as transmissions, messages, frames, and packets. 【0028】 Device 280 may be any device, element, or system used by a person (hereinafter referred to as the perpetrator) attempting to steal, break into, damage, or misuse the car 200. Typically, device 280 is adapted to connect to the in-vehicle network, for example, to at least one of networks 271 and 272. For example, the perpetrator may forcibly open a door, window, or trunk, or they may remove the headlight assembly of the car 200, thus exposing the wires of network 272 and connecting device 280 to network 272. Once connected to network 272, the perpetrator typically uses device 280 to send messages or packets via network 272, for example, messages that cause the ECU 260 to unlock the doors of the car 200 or start the engine of the car 200. For example, using a device connected to the in-vehicle network, an intruder could send a message to the ECU260, which is responsible for radio frequency (RF) key recognition and authentication, instructing it to authenticate the intruder's key, unlock the doors of the vehicle 200, start the engine, or reprogram or duplicate the key. As described, such an attempt can be identified and blocked by embodiments of the present invention. 【0029】 In other cases, the perpetrator may attempt to damage the vehicle 200, for example, by installing a virus, deleting code or data, or corrupting data necessary for the proper functioning of the vehicle 200. 【0030】 Refer to Figure 3, a block diagram of system 200 according to an exemplary embodiment of the present invention. As shown, the VTP 250 can connect to several in-vehicle networks, buses, or other communication infrastructures, for example, the VTP 250 connects to in-vehicle networks 271 and 272 as described herein. Further as shown, several components, elements, or units 260 and agent 282 are connected to networks 271 and 272. As shown, using connection 281, the intruder connects device 280 to network 271, for example, connection 281 may be a jack or socket that the intruder could access, an on-board diagnostic (OBD), or simply bare wires on network 271. 【0031】 As shown in the figure, the VTP250 includes an electrical characteristics processing unit 251 (referred to herein as unit 251), a content processing unit 252 (referred to herein as unit 252), a context processing unit 253 (referred to herein as unit 253), a VTP manager 254, memory 120, and an input / output (I / O) unit 255. For brevity and clarity, the VTP manager 254 is referred to herein as manager 254. 【0032】 In the embodiment, units 251 and 252 are connected to the in-vehicle networks so that they can detect and receive frames from each in-vehicle network independently or separately from other in-vehicle networks. For example, as shown, unit 251 is physically but separately connected to networks 271 and 272, and can simultaneously detect, measure, identify, and determine the values ​​and attributes of electrical signals, such as voltage and / or current, of, within, or via network 271, or of network 272. 【0033】 Generally, information exchanged between nodes via networks 271 and 272 is encoded into bits represented by voltage levels in the wires or conductors of these networks. Different units or nodes 260 will generate different transitions, fluctuations, waveforms, trends, patterns, characteristics, or attributes of voltage changes when communicating via networks 271 and 272. For example, even if two similar or identical nodes connected to network 271 are made to send the exact same message, network packet, or frame, the resulting voltage changes, signal defects and deviations, and patterns of transitions or fluctuations of these two transmissions will be different. Therefore, the hardware signatures (e.g., hardware signature 402) calculated for messages sent by two similar or identical nodes will be different. Hardware signatures can be created so that they are unique and can therefore be used to verify the hardware source of a transmission, e.g., a network packet or frame. 【0034】 In the embodiment, unit 251 measures electrical characteristics such as attributes or patterns of voltage changes, transitions, or fluctuations generated by transmission nodes when transmitting messages, packets, or frames over networks 271 and 271. For example, electrical characteristics such as maximum and minimum voltage levels, voltage change frequencies, and voltage transition rise and fall times are measured by circuits within unit 251, such as low-pass filters (LPFs) and analog-to-digital (A / D) converters. 【0035】 In the embodiment, unit 251 analyzes the transitions, fluctuations, waveforms, trends, patterns, characteristics, or attributes of voltage changes and generates an identifying hardware signature for each of the multiple units. A unique hardware signature can be created for each hardware component due to the characteristics or attributes of voltage changes caused by hardware components identical in manufacture. Electrical or physical attributes or characteristics, including frequency, voltage level, resistance, capacitance, or other measurable physical attributes or characteristics, are characterized, described, identified, classified, or represented in their respective hardware signatures, for example, hardware signature 402 as described with reference to Figure 4A. 【0036】 For example, unit 251 also calculates and / or generates hardware signatures for some or all units 260 connected to networks 271 and 272. For example, a graph or waveform of voltage levels over time may be generated or represented by unit 251, and the features, attributes, or characteristics of the graph may be calculated and used to generate a hardware signature that clearly or uniquely identifies a particular hardware node 260 on the network. For example, the features, attributes, or characteristics that unit 251 identifies and / or calculates may include Fourier coefficients and amplitudes that are specific or unique to a particular ECU 260. Such coefficients and amplitudes may be used by unit 251 to calculate or generate a unique hardware signature for each particular ECU 260. Note that the signatures generated as described will match any transmission of the relevant unit 260, regardless of the content or length of the transmission. Once created, the hardware signatures are used, for example, by manager 254 to match and / or validate transmissions, as further described herein. 【0037】 Unit 251 can detect, measure, identify, and determine the physical characteristics, attributes, and values ​​of or associated with networks 271 and 272. For example, Unit 251 can be equipped or adapted to measure and determine the capacitance, resistance, conductivity, or continuity of network 272. For example, the connection of device 280 may cause a sudden surge or change in capacitance or voltage in the system that can be detected by Unit 251. In embodiments, Unit 251 works in conjunction with agent 282 to measure and determine the physical characteristics and attributes of the in-vehicle network. For example, a voltage drop across network 271 can be continuously or periodically measured by agent 282 connected to an endpoint of network 271, and periodic messages (e.g., TCP ping messages) exchanged between Unit 251 and agent 282 can be used to allow Unit 251 to identify if an intruder physically disconnects a portion of network 272 (even temporarily) to connect device 280. 【0038】 In the embodiment, unit 252 analyzes, processes, and records information related to the content of messages, packets, or frames exchanged over networks 271 and 272. Unit 252 primarily operates at the logical level of transmission, such as network protocols and message headers and payloads. For example, unit 252 inspects, analyzes, and processes the header of a frame, thus identifying the source and destination of the frame, the length of the frame, and other information or metadata. Unit 252 is further adapted to inspect, analyze, and process the content or payload of messages, packets, or frames. 【0039】 In embodiments, unit 252 tags, classifies, organizes, sorts, or categorizes messages according to their content. For example, during a learning mode session, unit 252 creates and records content signatures that can be used to match or identify frames, messages, or packets containing the same or similar content or payload. For example, a set of values ​​within each set of header portions (e.g., network protocol, source / destination address or port, or a value within an offset in the payload) can be used to create a content signature. For example, based on some content similarity between a set of messages from an ECU 260 controlling the headlights of a car 200, unit 252 creates a content signature that will match future messages from the headlight ECU. A content signature as referred to herein may include multiple fields that relate to (or identify) multiple portions of a frame or packet. Thus, using content signatures, complex rules can be used to match or process incoming frames. Unit 252 may acquire information that identifies hardware elements, such as Media Access Control (MAC) addresses, or other information that identifies Rx / Tx hardware components, and record it, for example, in a content signature. For example, such hardware-related information may be received from Unit 251 and included in the content signature. Once created, the content signature is used, for example, by Manager 254 to match and / or validate transmissions, as further described herein. 【0040】 In the embodiment, unit 253 determines the context or state of the vehicle 200. The context may be determined by unit 253 based on the operating state of the vehicle and / or the circumstances under which the vehicle is operating. 【0041】 For example, unit 253 can receive messages, frames, or packets from network 271 (e.g., via unit 251) and, based on the received messages, can determine whether vehicle 200 is stationary or in transit, or whether vehicle 200 is moving, whether the engine is running, etc. Unit 253 can receive information from any source, such as, for example, the owner or driver of vehicle 200, or from the Internet. Once determined, the context is used, for example, by manager 254 to match and / or validate the transmission, as further described herein. The term “context” as used herein means any data or information that describes the context, or is related to it, and therefore logic and rules in the system may be based on the vehicle's context. 【0042】 The memory 121 of the VTP250 may be a component of the memory 120 within the computing device 100, or it may include the memory 121 within the computing device 100. For example, the memory 121 may be flash memory, RAM, etc. In some embodiments, the memory 121 may be external to the VTP250, for example, connected to a network 272, and the read / write operations described can be performed via the network 272. The manager 254 and all other units of the VTP250 can write data to and read data from the memory 121. 【0043】 For example, hardware signatures and logical signatures are stored in memory 120 by units 251 and 252, respectively, and then inspected and processed by manager 254. Similarly, context information is written to memory 121 and is therefore available to manager 254. Commands and rules can be written to and read from memory 121, so that manager 254 can control the operation of units 251, 252, and 253. For example, configuration data such as rules and thresholds are written to memory 121 by manager 254, and then the configuration data is read and applied by units 251, 252, and 253. 【0044】 Manager 254 uses the information received from units 251, 252, and 253 to determine that the rogue device is connected to and / or physically connected to the in-vehicle network 271. As will be further described, Manager 254 can further identify, discover, determine, record, and report valuable information. For example, Manager 254 can determine, record, and report what the user (perpetrator) of the rogue device is trying to do, and which elements or subsystems the perpetrator is targeting or attacking. 【0045】 I / O unit 255 can send messages or packets over networks 271 and 272. For example, manager 254 can send messages over networks 271 and 272 using or via I / O unit 255. Similarly, units 251, 252, and 253 can send messages using I / O unit 255. As shown in the figure, I / O unit 255 can be adapted to send and receive messages from external sources, such as the internet, etc. 【0046】 Refer to Figure 4A, a block diagram of elements contained in memory 121 according to an exemplary embodiment of the present invention. As shown, memory 121 in VTP250 may include content signatures 401, hardware signatures 402, rules 403, contexts 404, configurations 405, and devices 406. In the embodiment, content signatures 401 may include, for example, a plurality of content signatures learned by processing unit 252 during a learning or training phase. Content signatures 401 may include, for example, predefined content signatures that are downloaded from a server or otherwise installed. Hardware signatures 402 may include, for example, a plurality of hardware signatures learned by processing unit 251. For the sake of clarity and brevity, content signatures 401, hardware signatures 402, and rules 403 may be collectively referred to as content signatures (including plural) 401, hardware signatures (including plural) 402, and rules (including plural) 403, or they may be referred to individually as content signatures 401, hardware signatures 402, and rules 403. 【0047】 Values ​​and strings within header fields, as well as attributes or characteristics of content including any values, strings, or portions of a message, are characterized, described, identified, categorized, or represented in their respective content signatures, for example, content signature 401 as described with reference to Figure 4A. 【0048】 In this embodiment, a content signature is associated with a hardware signature. For example, the hardware signature of a specific ECU260, such as the ECU260 that reports engine heat, is associated with the content signature of a message received from that specific ECU. Thus, the rules and logic used to process packets or frames can be based on the hardware source of the message and any information contained in the message. 【0049】 Rule 403 typically contains configuration and other data used to process a frame or packet. For example, the logic applied by manager 254 is based on pointers, values, thresholds, and operations within rule 403. Context 404 contains the described context information. When processing an incoming frame, rule 403 may relate to or depend on one of the following pieces of information: content signature 401, hardware signature 402, and context 404. The information objects shown in Figure 4A can be stored in multiple memory components 121. For example, rule 403 can be stored in RAM, and the hardware signature can be stored in a flash memory stick or element. 【0050】 Device 406 may be a list, a table, a set of objects, or any other structure in memory 121. Device 406 may include a set of data entries that identify, classify, and describe each set of devices connected to the in-vehicle network. For example, device 406 may include a set of hardware signatures 402, content signatures 401, and metadata for a set of ECUs 260 in system 200. For example, the metadata in device 406 may include information obtained from or from the manufacturer of the ECU 260, such as type, version, serial number, etc., and one or more content signatures 401 that can be used to identify a device based on messages transmitted by the device. In other cases, the metadata in device 406 may include information collected, received, or generated by DU250, for example, during a learning or training phase. For example, since the message ECU 260 that controls the air conditioning (A / C) system in the vehicle 200 is known (e.g., to the manufacturer of the A / C ECU 260), a reference content signature 401 for such an ECU 260 can be created in advance and included in a device 406 in the vehicle 200. The reference content signature 401 can be used to identify or classify a device based on the messages it sends. Thus, for example, by matching a content signature 401 generated by a unit 252 in the VTP 250 with a reference content signature 401 in device 406, the VTP 250 can identify the ECU 260 in the system 200 and associate the ECU 260 with, for example, a type, class, manufacturer, name, model, or serial number. The metadata in device 406 can indicate the status of the ECU 260, for example, whether the ECU is operational, resetting, or defective. 【0051】 Refer to Figure 4B, which graphically shows a set of messages received over time according to an exemplary embodiment of the present invention. During operation, when a network frame or packet is received by the VTP250, hardware signatures and content signatures are calculated or generated for the incoming (received) message, for example, by units 251 and 252, as described. 【0052】 For example, following the timeline shown in Figure 4B, message M1 410 is received first, and hardware signature HS1 and content signature CS1 are calculated for message M1 and associated with it. Similarly, hardware signature HS2 and content signature CS2 are calculated for message M2, etc., and associated with them, and so on. The hardware and content signatures are then used in conjunction with more rules 403 for processing incoming messages. For example, signatures calculated for messages such as HS1 and CS1 are associated with or matched with signatures in device 406 or configuration 405, as described. 【0053】 In the embodiment, a method for protecting a vehicle from theft includes monitoring transmissions over an in-vehicle network. For example, VTP250 monitors transmissions over networks 271 and 272, for example using indiscriminate modes known in the art, so that any frames, messages, or data packets transmitted over networks 271 and 272 are received by units 251, 252 and / or manager 254. In the embodiment, VTP250 determines the electrical characteristics of the message transmission based on the content of the message and determines, based on the context of the vehicle, that a rogue device is connected to the in-vehicle network. 【0054】 For example, the hardware signature HS3 calculated for message M3 is unknown to unit 251 or manager 254, and for example, since message M3 was sent by device 280, the hardware signature HS3 cannot be found in device 406. Furthermore, context 404 does not indicate a state or context in which an unknown device is permitted to connect to the vehicle's network. In such a case, manager 254 determines that message M3 was sent by an unauthorized device. 【0055】 In the embodiment, the VTP250 determines what a rogue device connected to the in-vehicle network is being used for. For example, the VTP250 may identify or determine that device 280 is being used to steal vehicle 200 or to bypass the vehicle 200's security or access system. For example, based on repeated attempts by device 280 to provide authentication information, such as device 280 randomizing a PIN code or password in an attempt to access a resource, the VTP250 may determine that device 280 is being used to bypass the vehicle 200's security or access system. For example, based on the hardware signature of one or more messages transmitted by device 280, and further based on the content of these messages, and further based on the context of vehicle 200, the VTP250 may determine that the user of device 280 is attempting to steal vehicle 200. 【0056】 If VTP250 identifies or determines that a rogue device has connected to the network of a protected system, VTP250 then takes one or more actions. For example, VTP250 records and reports events. For example, VTP250 records and reports the date / time when device 280 connected to network 271, hardware information of device 280 such as MAC address, geographical location of vehicle 200, context and status of vehicle 200, and messages sent by device 280. In embodiments, VTP250 takes proactive action when a rogue device connects to either network 271 or 272. For example, VTP prevents or mitigates an attack on vehicle 200 and / or prevents theft or any unauthorized use of vehicle 200. For example, the VTP250 can prevent device 280 from communicating via network 271, or it can activate or deactivate a part of ECU 260, thereby preventing device 280 from operating as intended. 【0057】 In the embodiment, the VTP250 calculates a set of hardware signatures 402 for each set of components connected to the in-vehicle network based on the electrical characteristics of the transmission over the in-vehicle network. For example, hardware signatures 402 are calculated by the VTP250. The VTP250 can determine that a malicious component is physically connected to the in-vehicle network. For example, the VTP250 determines that device 280 is physically connected to network 271 based on associating the electrical characteristics of the transmission from device 280 with a set of signatures. For example, if a hardware signature 402, such as HS5 calculated for message M5, does not match any of the hardware signatures 402 in device 406, or any of the hardware signatures 402, then the VTP250 determines that message M5 is likely to have been sent by a device physically connected to network 271, and is also likely to be a malicious and / or rogue device or component connected to network 271. 【0058】 In the embodiment, the VTP250 determines that the electrical characteristics of the transmission match at least partially with the electrical characteristics represented by the signature, and updates the signature according to the electrical characteristics of the transmission. For example, messages 410 M1, 420 M2, and 430 M3 all arrive from the same source ECU260, but the hardware signatures (of M1 and M2) match a specific hardware signature 402, while the hardware signature HS3 of message M3 only partially matches a specific hardware signature 402. The hardware signature HS4 of message M4 also only partially matches a specific hardware signature 402, and possibly matches HS3 as well, so the VTP250 may then modify the specific hardware signature 402 in device 406 because the physical layer connecting the VTP250 and the source ECU260 may have changed slightly, for example, due to wire degradation. 【0059】 For example, the electrical characteristics of messages from the same particular ECU260 (characterized by a specific hardware signature 402) may be similar but not identical. For instance, electrical characteristics such as frequency or voltage level may gradually change due to temperature changes or wire degradation. Generally, the VTP250 continuously or periodically modifies or updates the hardware signature 402 to adapt to small changes. Thus, the VTP250 can continuously generate and update signatures. The VTP250 can update or modify the hardware and software signatures of device 406 based on time intervals, commands, or events. 【0060】 In the embodiment, the VTP250 creates a hardware signature 402 based on previously unseen electrical characteristics of one or more transmissions. For example, commands received by the VTP250 via the I / O unit 255 and from a server or a tool connected to the OBD port cause the VTP250 to start or assume a learning mode, or one of the following modes of operation: diagnostic mode, auto-discovery mode, or service mode. For example, in learning mode, the VTP250 creates a hardware signature based on transmissions by repeatedly modifying a specific hardware signature 402 until, for example, that specific hardware signature 402 matches a message sent from a specific ECU260. Thus, the VTP250 can learn, calculate, store, provide, and use the signature hardware signature 402 when, for example, a new ECU260 is connected to the network 272 by the owner of the vehicle 200 or at a service station. In another embodiment, the VTP250 can continuously or periodically update existing hardware signatures 402 within the device 406 to adapt to physical or environmental changes in or around the vehicle 200. 【0061】 In this embodiment, the VTP250 determines that a malicious component connected to the in-vehicle network is malicious based on the vehicle's state or context. For example, if car 200 is parked (not moving) or if car 200's engine is off, a malicious component connected to the in-vehicle network is more likely to be malicious than a malicious component connected to the in-vehicle network while car 200 is moving at 60 miles per hour. 【0062】 The context of vehicle 200 may reflect or indicate whether the owner of vehicle 200 is inside vehicle 200 or near vehicle 200. For example, if the context or state of vehicle 200 indicates that the owner of vehicle 200 is neither inside nor near vehicle 200, such as the owner's device not being connected to vehicle 200's telematics system via Bluetooth, then VTP 250 determines that the rogue component 280 connected to network 271 is malicious. In another example, if context 404 indicates that vehicle 200 is locked, then the rogue component connected to the in-vehicle network is more likely to be malicious than if vehicle 200 were unlocked. Needless to say, VTP 250 does not take context 404 into account alone, but rather, for example, the determination of whether the rogue component connected to the in-vehicle network is malicious is based on one or more rules 403, information within configuration 405 and device 406, and other described aspects. The data within context 404 is typically used by VTP250 in combination with other elements or aspects, such as signature matching, message sequences, etc. 【0063】 In the embodiment, the VTP250 determines that a malicious component is malicious based on examining the messages sent by the malicious component and identifying the operations that the malicious component is attempting to perform. For example, by comparing the header and content of messages sent from device 280 with predefined messages in configuration 405, the VTP250 can identify or determine which particular messages device 280 is sending, which ECU 260 these messages are addressed to, and what these messages are designed to cause. For example, the VTP250 determines that device 280 is malicious based on identifying a particular sequence of messages, such as message M2 from device 280 being an attempt to unlock the doors of car 200, and / or message M3 being a command to start the engine. 【0064】 In the embodiment, the VTP250 determines that a malicious component is malicious based on a sequence of messages. For example, the content signature 401 may include a description or characteristics of a sequence of messages, such as a sequence containing commands to start the engine of car 200, which typically includes unlocking the doors of car 200, entering a security code, and only then starting the engine. In another example, the VTP250 notes and records a sequence of diagnostic messages sent while the car's engine is stopped. In yet another case, a command to open the doors that appears before the key is identified is flagged, recorded, or processed as described. 【0065】 In some embodiments, configuration 405 includes a specific message sequence used by an attack, for example, a particular attack at startup, and a message sequence that identifies a known attack analyzed to identify the operation. By matching the messages from device 280 with the sequences in configuration 405 that identify the attack, VTP 250 can identify the attack and even predict the actions that device 280 will attempt to perform. 【0066】 In the embodiment, the VTP250 prevents malicious components from communicating over the network. For example, to prevent device 280 from communicating over networks 271 and 272, the VTP250 blocks, corrupts, or interrupts messages sent from device 280. For example, the VTP250 modifies the cyclic redundancy check (CRC) value of messages sent by device 280, or uses other techniques to corrupt, interrupt, or block messages originating from device 280. For example, to prevent device 280 from communicating over networks 271 and 272, the VTP250 floods device 280 with redundant messages, or the VTP250 instructs some ECUs 260 to ignore or discard incoming messages from device 280. In another example, VTP250 configures bridge 273 to block messages from device 280 from propagating through network 272, or VTP250 causes or instructs ECU260 to assume a safe mode or another mode that can protect ECU260 from device 280. 【0067】 In the embodiment, the VTP250 protects the vehicle from unauthorized components by controlling or activating in-vehicle components. For example, if it determines that an unauthorized and malicious device is connected to the network 271, the VTP250 sends a message to the ECU260, which controls the ignition of the vehicle's engine 200, causing the ECU260 to prevent the engine from starting. If it determines that an unauthorized and malicious device is connected to the in-vehicle network, the VTP250 can activate or sound an alarm, even if the alarm has been deactivated, by, for example, sending a command to the relevant ECU260. For example, even if device 280 was used to deactivate the alarm system of vehicle 200, the VTP250 activates or reactivates the alarm system by communicating with the relevant ECU260. 【0068】 In this embodiment, the VTP250 configures or controls network infrastructure elements within the vehicle to protect the vehicle from malicious components. For example, if it identifies that a malicious device 280 is connected to network 271, the VTP250 configures or reconfigures bridge 273 to selectively prevent network packets or messages from passing from network 271 to 272. 【0069】 In some cases, the VTP250 sends messages to ECUs responsible for the vehicle's security or protection, such as the door control module, body control module, smart key access system unit, or other ECUs. For example, a message or command sent by the VTP250 may disable an application in a first ECU260, cause a second ECU260 to assume lockdown or sleep mode, cause a third ECU260 to ignore a particular message, or cause an ECU to activate an alarm, activate an immobilizer or location service, or call the owner of the vehicle. 【0070】 As described, device 406 can also include a complete description of some or all of the ECU260. Different types of ECU260 can be tagged, categorized, or otherwise identified internally. As described, by associating content signature 401 with hardware signature 402, VTP250 can actually know who or what is each of the ECU260. Thus, rule 403 can be based on the attributes, type, or class of the ECU, for example, a first rule 403 can be associated with telematics ECU260, and a second rule can include commands sent to door ECU260 and other commands sent to alarm ECU260, etc. For example, a rule indicating that an ECU controlling ignition (which may be identified internally as "ECU17A") needs to be disabled can be executed by VTP250 because ECUs having the type ECU17A will appear in device 406. For example, an ECU of type ECU17A will appear in device 406 because it is pre-installed within the device, or because VTP250 identifies that one of the content signatures 401 of ECU260 matches a reference content signature 401 in device 406, and based on the match, VTP250 adds an entry for ECU17A in device 406. 【0071】 In this embodiment, the VTP250 verifies, based on the component's signature, that a message that appears to originate from a component is indeed originating from that component. In other words, the VTP250 verifies the hardware source of the message. For example, to verify the hardware source of message M4, the VTP250 verifies and confirms that the hardware signature HS4 and content signature CS4 match the respective hardware signatures 402 and content signatures 401 in the entry within device 406. If CS4 matches the content signature 401 in the entry within device 406, but HS4 does not match the hardware signature 402 in the entry, the VTP250 determines that a rogue device connected to the in-vehicle network is attempting to impersonate or forge one of the ECUs 260. For example, message M5 is sent by device 280 in an attempt to retrieve information needed to duplicate, activate, or encode the key for car 200. CS5 may match the content signature 401 of a specific ECU 260 within device 406, while HS5 will not match the corresponding hardware signature 402 of that ECU 260, since HS5 is a hardware device of device 280. 【0072】 In this embodiment, the reference hardware signature 402, reference content signature 401, manufacturer details and information, description, or any other information may be received, for example, via the I / O unit 255 from a remote server and from an internet-connected server. For example, after a software update of one of the ECUs 260, the new reference content signature 401 of the updated ECU 260 may be downloaded or received from the remote server and included in the device 406. 【0073】 In this embodiment, the VTP250 determines that an unauthorized component connected to the in-vehicle network is used to perform at least one of the following actions: unlocking the vehicle doors and starting the vehicle engine. For example, the VTP250 identifies and records that messages M2 420 and M4 440 were sent by device 280, that message M2 instructs ECU 260 to unlock the doors of vehicle 200, and that message M4 instructs ECU to start the engine of vehicle 200. 【0074】 In the embodiment, the VTP250 identifies that a malicious component is connected to the in-vehicle network based on matching the content of a message with the signature of a component. For example, if the hardware signature HS2 of message M2 matches the hardware signature 402 in an entry within device 406, and the content signature CS2 matches the content signature 401 in the same entry, the VTP250 determines that message M2 is validated, valid, and secure. In the embodiment, the VTP250 calculates the hardware signature of all messages obtained from the in-vehicle network, and uses the calculated hardware signatures to validate all messages within the in-vehicle network, thus providing continuous and sequential validation of communications over the in-vehicle network. 【0075】 It should be noted that attacks that do not necessarily involve a physical connection to the in-vehicle network can be detected by matching the hardware characteristics of the message source with the content transmitted by the source. For example, a hacker gains control of the ECU260 that controls the headlights and causes the ECU260 to send a command message M3 that the headlight ECU260 does not normally send. For example, message M3 is a command to unlock the doors, a command that the headlight ECU260 would never send. Hardware signature HS3 matches hardware signature 402 in the headlight and ECU260 entries in device 406, but since the headlight ECU260 never sends a command to the doors, content signature CS3 does not match content signature 401 in the headlight EU260 entry. Such a hardware content mismatch allows the VTP250 to determine that the headlight ECU has been attacked or has been accessed without authorization. Thus, the VTP250 can verify the validity of a message based on the association of hardware and content characteristics. 【0076】 In embodiments, based on at least one of a command, a configuration element, an event, and a vehicle state or context, the VTP250 may perform at least one of the following actions: authenticate a rogue component, ignore a rogue component, delete a hardware signature or content signature, create a hardware signature and / or content signature representing a new component, and calculate or recalculate the hardware signature and content signature of a component. 【0077】 For example, in learning mode or training mode, VTP250 adds an entry in device 406 containing the hardware signature 402 and content signature 401 of a new but unapproved connected ECU260, thus authenticating ECU260. In another case, VTP250 ignores messages from unapproved ECUs, for example, in service station ignore mode. Based on a command, VTP250 can remove the hardware signature 402 or content signature 401 from device 406, for example, when ECU260 is removed from vehicle 200. VTP250 can not only create a hardware signature and / or content signature representing a new component in a new entry in device 406, for example, but can also recalculate or update the hardware signature and content signature within device 406. 【0078】 The VTP250 can operate according to a context mode or state based on information in a context 404 stored within, for example, unit 253. For example, context 404 may indicate that vehicle 200 is in an authentication context or a non-operational context, for example, to allow a technician to connect an external diagnostic device. The context, state, or mode can be relearned, for example, when a technician replaces an ECU and needs to relearn its signature. A specific context can be stored in context 404 when vehicle 200 is in a garage or service station, and another specific context can be set for diagnostic purposes, for example. The context can be set, for example, within context 404 by unit 253, by manager 254, by a diagnostic device (e.g., connected to an OBD port), or by a remote entity such as a server via a telematics unit in vehicle 200. 【0079】 The operating mode can be automatically entered or assumed by the VTP250 based on, for example, the state or context of the vehicle 200, based on a command, or based on a message received from the ECU260. For example, the context or state of the vehicle 200 is determined or calculated by the unit 253 based on vehicle speed, tire pressure, vehicle load, road gradient, traction, ambient temperature, humidity, or season, and recorded in the context 404. 【0080】 The context can be identified, determined, or set by, for example, unit 253, based on the procedure. For example, the procedure required to duplicate a key typically involves the exchange of information such as a password, identification number, or PIN code, and such a procedure can be identified as a context by, for example, unit 253, and VTP250 can operate according to the identified context. The rules in rule 403 can be associated with the context. For example, VTP250 does not affect messages related to key duplication when context 404 indicates that a legitimate key duplication procedure is in progress. 【0081】 A hardware signature 401 typically remains unchanged once identified or set as described by the context, while a content signature 401 may change according to data within the context 404. For example, a particular ECU 260 is expected to transmit specific content matching a particular content signature 401 when the system 200 operates according to a particular first context, but the same ECU 260 is expected to transmit different messages with different content when the system 200 operates according to a different second context. In an embodiment, the content signature 401 includes content signatures 401 used for each of several contexts for a particular ECU 260. 【0082】 Therefore, the VTP250 can validate the message based on the context of the vehicle 200. Such capability allows the VTP250 to identify that the EU260 has been compromised when an intruder gains access to and control of the compromised ECU260, and to cause the ECU260 to send a message that the ECU260 would not normally send under certain contexts. 【0083】 Hardware and content signatures within device 406 may be context-dependent. For example, a first content signature 401 within device 406 can be used for a specific ECU 260 when car 200 is parked (first context or state), a second different content signature 401 for the same ECU 260 is used when the engine is off, and a third content signature 401 is used for car 200 traveling at 60 mph on a highway. In another case, rule 403 may indicate that when car 200 is in a certain context, a specific ECU 260 is not expected to send any messages or otherwise be operational. Messages received from a specific ECU 260 when car 200 is in a certain context can allow VTP 250 to determine whether an attack is underway or car 200 is at risk. Thus, VTP 250 can identify a threat based on the hardware source of the message, regardless of the message's content. In some cases, the VTP250 identifies an attack regardless of context. For example, the ECU260 that controls the infotainment system in car 200 does not normally send a message that causes or starts the engine of car 200. Therefore, a message sent by the infotainment ECU260 that commands another ECU260 to start the engine will be recognized by the VTP250 and require action because, for example, the content signature 401 calculated for the message does not match the content signature 401 stored for the infotainment ECU260 in device 406. 【0084】 In yet another case, Rule 403 may instruct that when vehicle 200 is in a certain context, a particular ECU 260 is expected to send one or more messages or otherwise be operational. By failing to receive messages from a particular ECU 260 when vehicle 200 is in a certain context, VTP 250 may determine that an attack is underway or that vehicle 200 is at risk. Thus, VTP 250 may identify a threat based on the context and the specific hardware source of the message, possibly regardless of the message's content. At any point and wherever VTP 250 identifies a security threat or risk, VTP 250 may take action. For example, VTP 250 may record information related to the risk or threat, alert the user, and control components within system 200. For example, VTP 250 may restart ECU 260, block messages from devices connected to the in-vehicle network, and communicate with a remote computer. 【0085】 Refer to Figure 5, which shows a flowchart of a method according to an exemplary embodiment of the present invention. As shown in block 510, a method according to an embodiment of the present invention includes monitoring transmissions over an in-vehicle network. For example, any frame, message, or data packet transmitted over networks 271 and 272 is received by VTP250, for example, using the promiscuous mode described. 【0086】 As shown in block 515, the method includes determining that a rogue device is connected to an in-vehicle network based on at least two of the content of at least one message, the electrical characteristics of the message transmission, and the vehicle context. For example, VTP250 identifies and determines that device 280 is connected to network 271, as described. 【0087】 As shown in block 520, the method includes determining that a rogue device is used to perform at least one of the following: stealing a vehicle and bypassing a vehicle's security or access system. For example, an attempt to steal vehicle 200 or bypass a security or access system is identified by VTP250 based on repeated attempts to access a resource, or on specific commands or messages sent to multiple specific ECUs 260, as described. 【0088】 As shown in block 525, the method includes recording and reporting information related to the rogue component, preventing or mitigating attacks on the vehicle, and preventing theft or misuse of the vehicle. For example, VTP250 may interrupt messages transmitted by device 280 and prevent device 280 from accessing network 272. 【0089】 In the embodiments for carrying out the invention, numerous specific details are given in order to provide a complete understanding of the invention. However, it will be understood by those skilled in the art that the invention can be carried out without these specific details. In other embodiments, well-known methods, procedures, and components, modules, units, and / or circuits are not described in detail so as not to obscure the invention. Some features or elements described in relation to one embodiment may be combined with features or elements described in relation to other embodiments. For clarity, descriptions of the same or similar features or elements may not be repeated. 【0090】 Embodiments of the present invention are not limited in this respect, but descriptions using terms such as “process,” “calculate,” “compute,” “determine,” “establish,” “analyze,” and “check” may refer to the operation(s) and / or processes(s) of a computer, computing platform, computing system, or other computing device that manipulates data represented as physical (e.g., electrical) quantities in the registers and / or memory of a computer, and / or converts it into other data similarly represented as physical quantities in the registers and / or memory of a computer or other non-temporary information storage medium capable of storing instructions to perform operations and / or processes. Embodiments of the present invention are not limited in this respect, but as used herein, the terms “plurality” and “a plurality” may include, for example, “plurality” or “two or more.” Throughout this specification, the terms “plurality” or “a plurality” may be used to describe two or more components, devices, elements, units, parameters, etc. As used herein, a term, set, may include one or more articles. 【0091】 Unless expressly stated otherwise, embodiments of the methods described herein are not restricted to any particular chronological order. Furthermore, some of the method elements described may occur or be performed simultaneously, at the same time, or in parallel. Some of the described method elements may be omitted or repeated during the sequence of operations of the method. 【0092】 In the specification and claims of this application, the verbs “comprise,” “include,” and “have,” and each of their conjugations, are used to indicate that one or more objects of the verb are not necessarily a complete list of components, elements, or parts of one or more subjects of the verb. Unless otherwise stated, adjectives such as “substantially” and “about” modifying the condition or relational characteristic of one or more features of one embodiment of the present disclosure are understood to mean that the condition or characteristic is defined within an acceptable range for the operation of the embodiment as described. Furthermore, the word “or” is considered to be inclusive rather than exclusive, indicating at least one or any combination of the items to which it joins. 【0093】 The descriptions of embodiments of the present invention in this application are provided for illustrative purposes only and are not intended to limit the scope of the invention. The embodiments described include different features, not all of which are required in all embodiments. Some embodiments utilize only some of the features, or some of the possible combinations of features. Modifications of the embodiments of the present invention described, and embodiments including different combinations of features noted in the embodiments described, will be conceivable to those skilled in the art. The scope of the invention is limited only by the claims. 【0094】 While certain features of the present invention have been illustrated and described herein, many variations, substitutions, alterations, and equivalents will be conceivable to those skilled in the art. It is therefore understood that it is intended to cover all such variations and alterations that fall within the true spirit of the present invention. 【0095】 Various embodiments are presented. Each of these embodiments may, of course, include features from other embodiments presented, and embodiments not specifically described may include various features described herein.

Claims

[Claim 1] A method of protecting a vehicle from theft, Monitoring transmissions via the in-vehicle network, Based on at least two of the following: the content of at least one message, the electrical characteristics of the transmission of the message, and the context of the vehicle, the unauthorized device is connected to the in-vehicle network. Stealing the aforementioned vehicle, and Bypassing the security system or access system of the aforementioned vehicle, It is determined that it will be used to perform at least one of the following, Record and report information related to the aforementioned unauthorized component. To prevent or mitigate attacks on the aforementioned vehicle, and To prevent the theft or misuse of the aforementioned vehicle, Perform at least one of the following, The method, including the method described above. [Claim 2] Based on the electrical characteristics of the transmission via the in-vehicle network, calculate a set of signatures for each set of components connected to the in-vehicle network. Includes, Determining that an unauthorized component is connected to the in-vehicle network is based on associating the electrical characteristics of the transmission with the set of signatures. The method according to claim 1. [Claim 3] The electrical characteristics of the transmission are determined to be at least partially consistent with the electrical characteristics represented by the signature. Updating the signature according to the electrical characteristics of the transmission, The method according to claim 1 or 2, including the method according to claim 1 or 2. [Claim 4] The method according to claim 1, comprising creating a signature based on previously unseen electrical characteristics of one or more transmissions. [Claim 5] Determining that the fraudulent component is malicious is the method according to any one of the prior claims, based on the condition of the vehicle. [Claim 6] The method according to any one of the prior claims, wherein determining that the malicious component is malicious is based on examining messages sent by the malicious component and identifying operations that the malicious component attempts to perform. [Claim 7] The method according to any one of the prior claims, comprising preventing the unauthorized component from communicating through the network. [Claim 8] The method according to any one of the prior claims, comprising controlling or activating a component within the vehicle to thus protect the vehicle from the unauthorized component. [Claim 9] Based on matching the content of the aforementioned message with the component's signature, The message that appeared to originate from the said component was actually sent from the said component, and The unauthorized component is connected to the in-vehicle network. A method according to any one of the prior claims, comprising determining one of the following. [Claim 10] The method according to any one of the prior claims, wherein the signature is received from a server. [Claim 11] The method according to any one of the prior claims, comprising determining that the unauthorized component is used to perform at least one of coding a key, unlocking the doors of the vehicle, and starting the engine of the vehicle. [Claim 12] The method according to any one of the prior claims, comprising determining that the unauthorized component is physically connected to the in-vehicle network. [Claim 13] Based on at least one of the following: commands, configuration elements, events, and the state or context of the vehicle, Authenticating the aforementioned unauthorized component, Ignoring the aforementioned malicious component, Deleting the signature, Creating a signature to represent a new component, Calculating or recalculating the signature of a component. The method according to any one of the prior claims, comprising performing at least one of the following: [Claim 14] A system comprising a data processing circuit configured to perform the method described in any one of claims 1 to 13. [Claim 15] A computer program that, when executed by a computer, includes instructions causing the computer to perform the method described in any one of claims 1 to 13.

Images