Trusted environment self-learning method and system for vehicle network intrusion detection system

Abstract

In various embodiments, methods, systems, and vehicle devices are provided. A method of determining a trusted operating environment for a vehicle-mounted network intrusion detection system (NIDS) for learning a vehicle platform includes: executing the NIDS to monitor a set of electronic control units (ECUs) and vehicle state elements by receiving a set of vehicle-derived inputs regarding a vehicle operating state; identifying a trusted window during which learning regarding a network topology and whitelist messages included in the vehicle platform is permissible in response to a determination regarding the vehicle operating state; creating a vehicle-specific configuration including a list of network topologies and whitelist messages used by ECUs in the vehicle platform; and preventing misconfiguration of at least one network in the list of network topologies and whitelist messages in the vehicle-specific configuration within the vehicle platform outside the trusted window.

Description

Technical Field

[0001] The present disclosure relates generally to vehicles and safety, and more particularly to methods, systems, and apparatus for evaluating a trust level of a system topology of a vehicle for use in system configuration or calibration of control units (ECUs) in the vehicle. Background Art

[0002] In recent years, significant progress has been made in autonomous and semi-autonomous driving features for inland vehicles with complex networks and host systems. Within the complex networks and systems of mass production, the electrical content generated by a fully manufactured vehicle exhibits significant variability, which needs to be accounted for in safety assessments. In vehicles with more advanced autonomous, semi-autonomous, and related feature options, multiple system variations are coordinated by different ECUs (Electronic Control Units). While regulatory focus aligns with the automated driving system category, even platforms that do not support any type of autonomy require suitability and will be introduced in vehicles without autonomy. Autonomous and semi-autonomous vehicle ECUs are internally connected via multiple communication buses, enabling connected ECUs to read or send data to other ECUs. Therefore, if an adversary can compromise one ECU, they can access and exploit data from other ECUs. The function of an in-vehicle network intrusion detection system (NIDS) is to monitor the internal environment (in this case, the ECU network) for suspicious events that may indicate a compromise and prevent network compromise and intrusion.

[0003] To successfully operate a NIDS, network signal monitoring software must be able to accurately map the network topology. Network topology mapping includes details related to the type and number of networks (Controller Area Network, Ethernet, etc.) as well as details related to which ECUs are located on which networks.

[0004] The desire is to move away from the expensive and time-consuming calibration process that has been used to create a vehicle-specific configuration containing a list of network topologies and messages used by each ECU, each part of a unique platform build.

[0005] It is desirable to have a system design that is capable of securely self-learning the vehicle network topology by monitoring certain ECU network security and vehicle state elements to identify trusted windows during which learning can occur, thereby preventing unauthorized personnel from accessing the vehicle system and causing misconfiguration of the vehicle system.

[0006] It is expected to provide functionality that supports secure self-enabling of NIDS in selected vehicle sales regions to ensure compliance with regional data privacy regulations in sales regions that may differ from where the vehicle is assembled.

[0007] Furthermore, other desirable features and characteristics of the present disclosure will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background. Summary of the Invention

[0008] In at least one exemplary embodiment, a method for determining a trusted window for a vehicle-based network intrusion detection system (NIDS) for learning a vehicle platform is provided. The method includes: executing the NIDS by a processor to monitor an electronic control unit (ECU) network and vehicle state elements by receiving a set of vehicle inputs regarding a vehicle operating state; identifying, by the processor, a trusted window during which learning of a network topology and whitelist messages included in a vehicle platform build configuration is permissible; creating, by the processor, a vehicle-specific configuration including a list of network topologies and whitelist messages used by an ECU on a specific network in the vehicle platform; and preventing, by the processor, misconfiguration of at least one network in the list of network topologies and whitelist messages in the vehicle-specific configuration outside the trusted window based on an evaluation of at least one security impact of the network topologies and whitelist messages included in the list used by the ECU in the vehicle platform.

[0009] In at least one embodiment, the method includes applying, by a processor, to algorithmically generate a network topology and a whitelist message having behaviors associated with a vehicle platform.

[0010] In at least one embodiment, the method includes implementing, by a processor, previously available data of a network topology generated during manufacture of the vehicle.

[0011] In at least one embodiment, the method wherein the previously available data includes ECU data that is part of the vehicle network topology.

[0012] In at least one embodiment, the method wherein the data vehicle network topology includes ECU and controller area network (CAN) bus membership.

[0013] In at least one embodiment, the method includes automatically learning, by a processor, the vehicle sales region through an algorithm in the NIDS.

[0014] In at least one embodiment, the method includes enabling, by the processor, the NIDS to utilize pre-existing manufacturing data to extract the sales region of the vehicle to enable operability of the NIDS in accordance with privacy regulations of the region where the vehicle will be sold.

[0015] In at least one embodiment, the method includes extracting, by a processor, a compact system network profile in conjunction with learned topology to generate at least one whitelist message set for a vehicle build based on whitelist message usage, while also considering whitelist messages for OEM aftermarket ECUs to be added during the system lifecycle.

[0016] In another exemplary embodiment, a system is provided. The system includes: a processor configured to execute an in-vehicle network intrusion detection system (NIDS) to monitor a set of electronic control units (ECUs) and vehicle state elements by receiving a set of vehicle inputs regarding vehicle operating states; in response to a determination regarding the vehicle operating states, the processor configured to identify a trusted window that allows learning about network topologies and whitelist messages included in a vehicle platform; the processor configured to create a vehicle-specific configuration, the vehicle-specific configuration including a list of network topologies and whitelist messages used by the ECUs in the vehicle platform; and the processor configured to prevent misconfiguration of at least one network in the list of network topologies and whitelist messages in the vehicle-specific configuration in the vehicle platform outside the trusted window based on an evaluation result of at least one security impact of the network topologies and whitelist messages included in the list used by the ECUs in the vehicle platform.

[0017] In at least one exemplary embodiment, the processor is configured to implement an algorithm to generate a network topology and a whitelist message having behaviors relevant to a vehicle platform.

[0018] In at least one exemplary embodiment, the processor is configured to implement previously available data of the network topology generated during vehicle manufacture.

[0019] In at least one exemplary embodiment, the previously available data includes ECU data that is part of a vehicle network topology.

[0020] In at least one exemplary embodiment, the data vehicle network topology includes, but is not limited to, a controller area network (CAN) bus location.

[0021] In at least one exemplary embodiment, the processor is configured to implement automatic learning of vehicle sales regions using an algorithm in the NIDS.

[0022] In at least one exemplary embodiment, the processor is configured to extract at least one set of whitelist messages for a vehicle build based on the whitelist message usage via a compact system network profile in conjunction with a learned topology.

[0023] In another exemplary embodiment, a vehicle device is provided. The vehicle device includes: a vehicle controller including a processor, wherein the processor executes an algorithm to determine a trusted window for an onboard network intrusion detection system (NIDS) to learn about a vehicle platform, including executing the NIDS to monitor a set of electronic control units (ECUs) and vehicle state elements by receiving a set of vehicle inputs regarding a vehicle operating state; identifying a trusted window during which learning about a network topology and whitelist messages included in the vehicle platform is permissible in response to the determination regarding the vehicle operating state; creating a vehicle-specific configuration including a list of network topologies and whitelist messages used by ECUs in the vehicle platform; and preventing misconfiguration of at least one network in the list of network topologies and whitelist messages in the vehicle-specific configuration outside the trusted window based on an evaluation result of at least one security impact of the network topologies and whitelist messages included in the list used by the ECUs in the vehicle platform.

[0024] In at least one exemplary embodiment, a vehicle device includes a processor configured to generate, via an algorithm, a network topology and a whitelist message having behaviors associated with a vehicle platform.

[0025] In at least one exemplary embodiment, a vehicle device includes a processor configured to implement previously available data of a network topology generated during vehicle manufacturing.

[0026] In at least one exemplary embodiment, a vehicle device includes a processor configured to implement automatic learning of a vehicle sales region through an algorithm in a NIDS. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Exemplary embodiments will be described below with reference to the following drawings, wherein like reference numerals represent like elements, and wherein:

[0028] Figure 1 is a functional block diagram illustrating an autonomous or semi-autonomous vehicle having a NIDS configured with an intelligent recognition algorithm capable of controlling vehicle ECU calibration and other configurations based on evaluating a trusted environment in which vehicle calibration may occur using a set of parameters, according to an exemplary embodiment;

[0029] Figure 2A 、 2B and 2C is a flow chart illustrating steps of an autonomous or semi-autonomous vehicle having a NIDS configured with an intelligent recognition algorithm capable of controlling vehicle ECU calibration and other configurations based on using a set of parameters to assess a trusted environment in which vehicle calibration may occur, according to an exemplary embodiment; and

[0030] Figure 3is a block diagram illustrating a gateway that communicates with a set of ECUs of an autonomous or semi-autonomous vehicle and external ECUs having a NIDS configured with an intelligent identification algorithm that enables gateway access and control of vehicle ECU calibration and other configurations based on evaluating a trusted environment in which vehicle calibration may occur using a set of parameters, according to an exemplary embodiment. DETAILED DESCRIPTION

[0031] The following detailed description is merely exemplary in nature and is not intended to limit application and use. In addition, it is not intended to be bound by any express or implied theory presented in the previous technical field, background technology, invention content or the detailed description below. As used herein, the term "module" refers to any hardware, software, firmware, electronic control component, processing logic and / or processor device, alone or in any combination, including but not limited to: application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), electronic circuits, processors (shared, dedicated or grouped) and memories that execute one or more software or firmware programs, combinational logic circuits and / or other suitable components that provide the functionality.

[0032] Embodiments of the present disclosure may be described herein in terms of functional and / or logical block components and various processing steps. It should be understood that such block components may be implemented by any number of hardware, software, and / or firmware components configured to perform a specified function. For example, embodiments of the present disclosure may employ various integrated circuit components, such as storage elements, digital signal processing elements, logic elements, lookup tables, etc., which may perform various functions under the control of one or more microprocessors or other control devices. In addition, those skilled in the art will appreciate that embodiments of the present disclosure may be practiced in conjunction with any number of systems, and the systems described herein are merely exemplary embodiments of the present disclosure.

[0033] For the sake of brevity, conventional techniques related to signal processing, data transmission, signaling, control, machine learning, image analysis, and other functional aspects of the system (and the various operating components of the system) are not described in detail herein. In addition, the connecting lines shown in the various figures included herein are intended to represent example functional relationships and / or physical connections between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may exist in the embodiments of the present disclosure.

[0034] NIDS can host signal processing and recognition algorithms to distinguish between baseline operation and deviations of network protocols and system behavior, facilitating the identification of target system behavior violations. Intrusion detection can be implemented to prevent malicious network traffic activity, such as intrusion into vehicle systems and manipulation of configuration data.

[0035] This disclosure describes methods, systems, and apparatus for constraining calibration, extension, and development efforts on a per-platform basis for vehicle system information required to support network intrusion detection system functionality. This disclosure describes methods, systems, and apparatus for providing a self-learning algorithm that generates the configuration data required for proper operation of a NIDS while using OEM-specific MFG processes and ECU states to create a trusted environment for learning.

[0036] Figure 1 is a functional block diagram illustrating an autonomous or semi-autonomous vehicle having a NIDS configured with a (i.e., intelligent) recognition algorithm capable of controlling vehicle ECU calibration and other configurations based on using a set of parameters to assess a trusted environment in which vehicle calibration may occur, according to an exemplary embodiment.

[0037] Figure 1 An embodiment of an autonomous vehicle 100 is shown, wherein an identification algorithm evaluates a set of parameters or factors to determine a trusted environment for gateway access to ECU configurations for the vehicle's systems. While the disclosed subject matter is intended to be implemented within the systems of an autonomous vehicle 100, other ways of deploying the disclosed subject matter are also possible. For example, it is entirely possible that the subject matter could be deployed or integrated into systems or devices in other types of vehicles, which may or may not be autonomous or remote devices, such as drones.

[0038] refer to Figure 1 , according to an exemplary embodiment, a vehicle 100 is shown having a network 105 (i.e., a full vehicle network) self-configuring processor system (inputs, ECU flags, vehicle status, ECUs, sensors and sensor data, calibration data, etc.) 110. The vehicle 100 includes a plurality of sensors 120, a sensor ECU 131, a general ECU 130, and a trusted network self-configuring module 132 of the trusted network self-configuring processor system 110.

[0039] The trusted network self-configuring processor system 110 for in-vehicle NIDS avoids the need for expensive calibration propagation methods by implementing build processes and ECU states unique to the vehicle manufacturing process and new compact network design artifacts that contain the critical network information required by the system. Trust in the environment assessed for the network self-configuring processor system 110 is critical, replacing the propagation of vehicle-specific signature calibrations.

[0040] The trust level of the trusted network self-configuring processor system 110 is determined by a set of determinations, checks or evaluation results of a security assessment (or security impact), which includes evaluating the following parameters or attributes: (1) an ECU-level flag, security token or counter indicating that the production process is possible, (2) ECU privileged access status, such as security access level and (3) vehicle mileage ≤ a key threshold for distinguishing the vehicle as a new vehicle so that the system recognizes this value and can imply that the vehicle exists in a trusted OEM manufacturing environment; and in the trusted environment, the NIDS can (4) securely receive network topology information generated during the vehicle manufacturing process to identify which ECUs exist and on which (which) networks, and can determine the use of the learned topology information of (4) in combination with (6) a new compact system configuration ARXML file to generate (5) a baseline whitelist of vehicle network platform-specific content, which identifies all possible ECUs and messages and related performance behaviors.

[0041] In an exemplary embodiment, the trust assessment of the sales region of the learning system enables system functionality only (or almost only, or as much as possible) in markets where data collection complies with regional regulatory requirements. In addition, other additional customer-specific enablement criteria may also be used in conjunction with this enablement flag. In this regard, this is an initial "enablement" flag that needs to be "ANDed" with other information, such as customer permission to collect data as an option. The trust assessment leverages existing manufacturing processes and trust models by appending the (7) sales region code to the canonical server name, such as the canonical server name configured to support the telematics ECU136 and can be programmed based on the expected sales region. Although the canonical URL name may not provide a resolvable sales data region without requiring additional lookup tables and configuration, the use of the (7) sales region code in conjunction with the (8) telematics system provides user terms and conditions acceptance to allow the NIDS to maintain system flexibility for the current dynamic global environment in terms of data privacy and off-vehicle data.

[0042] This assessment of a trusted environment eliminates the reliance on human resources and time-consuming calibration methods to provide the information required for in-vehicle NIDS functionality, enabling the creation of a baseline definition for each unique vehicle build configuration.

[0043] In an exemplary embodiment, the network self-configuring processor system 110 does not need to calibrate the NIDS configuration table because the implemented auto-learning algorithm creates a trusted environment instead of relying on the security provided by the signed calibration files.

[0044] In an exemplary embodiment, the network self-configuring processor system 110 relies on existing or legacy security elements that are available but have been repurposed or designed to create an environment that defines the trusted window required to learn the system configuration.

[0045] In an exemplary embodiment, the network self-configuring processor system 110 implements a compact system network profile extraction 151 that can be used in conjunction with system topology learning information to generate a vehicle build-specific "whitelist" message set with associated message capabilities. The system profile can be 100MB in size and contain all possible messages that any make or assembly of vehicles may have for all protocols. The extraction size is on the order of 10 kilobytes and can be used within the program memory 144 of a modern embedded system (e.g., a microcontroller).

[0046] In an exemplary embodiment, if whitelist messages are transmitted on the vehicle network within the trusted environment window, they are the only messages and may be considered normal or baseline events.

[0047] In an exemplary embodiment, messages that are not part of the whitelist message but are part of the overall system configuration ARXML are considered anomalous and will be flagged by the NIDS as violations that are clear violations, regardless of any other performance considerations.

[0048] In an exemplary embodiment, the network self-configuring processor system 110 can enable a process to leverage traditional or existing ECU design and vehicle manufacturing processes to learn canonical telematics server URL names to securely and easily receive explicit sales regions at build time without requiring additional programming time or ECU calibration memory partitioning.

[0049] In an exemplary embodiment, the network self-configuring processor system 110 ties NIDS operations to as-built data and enables the NIDS to determine whether recording and offloading data is permitted according to regional data privacy laws.

[0050] In an exemplary embodiment, the network self-configuration processor system 110 defines a mechanism by which learned vehicle network configuration information can be used to verify the legitimacy of certain approved aftermarket ECUs that can be added to the vehicle network, while also adjusting the vehicle whitelist to add new messages, while also being able to detect tampering with previously learned configurations.

[0051] The sensors sense observable states of the vehicle 100 and may include, but are not limited to, image, LIDAR, and radar sensors 120. Typically, each of the plurality of sensors is specifically coupled to a trusted network self-configuration processor module (communication gateway controller) 132 of the vehicle 100 and is configured to sense the external environment of the vehicle 100. The trusted network self-configuration processor module 132 receives sensor signals generated by the sensors 120 and provided by the sensor ECU 131, and processes the sensor signals to obtain sensor data. Although the illustrated embodiment implements the platform as a vehicle 100, the concepts presented herein may be deployed in other platforms, such as aircraft, spacecraft, ships, motorcycles, robots, robotic devices, etc. In addition, if desired, the concepts presented herein may also be deployed in alternative mobile and non-mobile platform applications.

[0052] As described above, the vehicle 100 typically includes a plurality of sensors 120, a sensor ECU 131, a general ECU device 130, and software sufficient to ingest digital information and / or sensed information, convert the sensed information into digital information, and provide the digital information to the network self-configuring processor system 110. Typically, each of the plurality of sensors is configured to sense various aspects of the vehicle 100's surroundings.

[0053] Outside of a trusted manufacturing environment, if configured, the network self-configuring processor system 110 can allow data to be filtered within designated areas via 136 and also incorporate additional customer approval as an additional input to allow data collection. The transceiver 136 can be used to establish and maintain communication links to onboard components and external communication sources for providing additional data, such as acceptance of customer terms and conditions required to complete NIDS activation. The transceiver 136 can perform signal processing (e.g., digitization, data encoding, modulation, etc.) as is known in the art and, in this case, for receiving transmission and reception time data.

[0054] Continue to refer Figure 1, depicts the components of the network self-configuring processor system 110 and their functions. In the depicted embodiment, the computer system of the network self-configuring processor system 110 includes the network 105, the ECU 130, an additional vehicle communication interface 146, and a communication gateway controller 132 having a block data processor 142 communicatively coupled to a memory 144, a storage device 148, an interprocessor bus 150, and an optional storage disk 158. In various embodiments, the network self-configuring processor system 110 performs the actions and other functions further described below in conjunction with FIG. 2 . The block data processor 142 performs the computational and control functions attributed to the network self-configuring processor system 110 and may include any type of module or modules, a single integrated circuit such as a micromodule, or any suitable number of integrated circuit devices and / or circuit boards that work together to perform the described operations, tasks, and functions by manipulating electrical signals representing data bits at memory locations in the system memory, as well as other signal processing.

[0055] During operation, the block data processor 142 loads and executes one or more programs, algorithms, and rules embodied as instructions and application programs (i.e., learning algorithms) 152 contained within the memory 144, and thereby controls the general operation of the control system of the communication gateway controller 132. In performing the processes described herein, the block data processor 142 loads and executes at least one program 156.

[0056] Computer-readable storage media such as memory 144, storage device 148, or optional storage disk 158 can be used as memory and scratch pad storage. A memory location where data bits are maintained is a physical location with specific electrical, magnetic, optical, or organic properties corresponding to the data bits. Memory 144 can be any type of suitable computer-readable storage medium. For example, memory 144 can include various types of dynamic random access memory (DRAM), such as SDRAM, various types of static RAM (SRAM), and various types of non-volatile memory (PROM, EPROM, and flash memory). In some examples, memory 144 is located and / or co-located on the same computer chip as block data processor 142. In the depicted embodiment, memory 144 stores the aforementioned instructions and application 152, along with one or more configurable variables, in stored values ​​154.

[0057] Storage device 148 is a computer-readable storage medium in the form of any suitable type of storage device, including direct access storage devices such as hard drives, flash memory systems, floppy disk drives, and optical disk drives. In an exemplary embodiment, storage device 148 includes a program product from which memory 144 can receive a program 156 for performing one or more embodiments of one or more processes of the present disclosure. In another exemplary embodiment, the program product can be stored directly in and / or accessed by memory 144 and / or a disk (e.g., optional storage disk 158), as described below.

[0058] Data records may be stored in computer-readable storage media, such as memory 144, storage device 148, or optional storage disk 158. The internal bus 150 of 132 is used to transfer programs, data, status, and other information or signals between the various components of the network of self-configuring processors in the system 110. Bus 150 may be any suitable physical or logical means of connecting computer systems and components. This includes, but is not limited to, direct hardwired connections, fiber optics, infrared, and wireless bus technologies. During operation, programs 156 stored in memory 144 are loaded and executed by the block data processor 142.

[0059] Interface 146 may also include one or more network interfaces to allow 110 to communicate with technicians and / or manufacturing systems, thereby allowing communication and potential storage of manufacturing specific status information, which may ultimately be placed in a storage device, such as storage device 148 .

[0060] In various embodiments, the vehicle 100 is autonomous or semi-autonomous, and the control system and / or components of the communication gateway controller 132 are incorporated into the vehicle 100. The vehicle 100 is, for example, a vehicle that is automatically controlled to transport passengers between locations. The vehicle 100 is depicted as a passenger car in the illustrated embodiment, but it should be understood that any other vehicle may be used, including motorcycles, trucks, sport utility vehicles (SUVs), recreational vehicles (RVs), boats, aircraft, etc.

[0061] Now refer to Figure 2A 、 2B and 2C, Figures 2A-2C is a flow chart illustrating steps for an autonomous or semi-autonomous vehicle having a NIDS configured with an intelligent recognition algorithm capable of controlling vehicle ECU calibration and other configurations based on using a set of parameters to assess a trusted environment in which vehicle calibration may occur, according to various embodiments.

[0062] exist Figure 2AIn step 205, the network self-configuration processor system 110 executes the NIDS algorithm to start the automatic vehicle 100 specific network message learning algorithm. When the NIDS configuration is implemented, the NIDS is able to collect data from various ECU related systems of the vehicle 100. Figures 2A-2B During the self-configuration evaluation process (described in ), at task 210, the network self-configuration processor system 110 uses the manufacturing status indication through an algorithm via the central communication gateway module to perform a check or evaluation to determine whether the configuration value is greater than >0. If it is determined at task 215 that the value is >0 or true, then the security access is determined to be valid. The security access sub-function checks the vehicle mileage status to a certain determined low value, which is a critical threshold for the vehicle being considered for use. The functional check implementation is ((security access = valid sub-function, odometer value ≤ predetermined value or variable set low mileage)). This is related to steps 2-3 of the eight-step self-configuration evaluation.

[0063] Alternatively, if the configuration value at task 210 is not >0 (the check is false), the process proceeds to task 215, where a status check is performed to determine if the vehicle mileage is less than a preset amount (i.e., 100 km, 75 km, 50 km, etc.). Again, this corresponds to steps 2-3 of the eight-step process flow. In an exemplary embodiment, at task 215, if the vehicle mileage check is ≤100 km, the process proceeds to step 4, where network topology data in the trusted environment is learned at task 220, and then proceeds to steps 5-6 to initiate a vehicle NIDS network message whitelist learning sub-algorithm (step 5) based on the learned content (step 4) and the NIDS system configuration file extraction (step 6). A new, compact subset of the specific system configuration ARXML data is used to support automatic learning of the vehicle's specific network. Alternatively, if the result of task 215 is false, the process proceeds to task 222, where it is determined that the vehicle is not located in a manufacturing plant and is prevented from learning topology information, and the vehicle NIDS network message whitelist learning sub-algorithm is initiated (corresponding to steps 4-6 of the eight-step process flow).

[0064] At task 217 (steps 2-3), if the vehicle mileage status check is ≤ 100 km and the security access is equal to the manufacturing privilege level, and this is deemed true, then at task 219 (similar to task 217), network topology data is learned in the trusted environment, and steps 5-6 are performed to initiate the vehicle NIDS network message whitelist learning sub-algorithm (step 5) based on the learned content (step 4) and the NIDS system configuration file extraction (step 6). A new, compact subset of the specific system configuration ARXML data is used to support automatic learning of the vehicle-specific network. Alternatively, if the result of task 217 is false, the process proceeds to task 221, and it is determined that the vehicle is not located in a manufacturing plant and is prevented from learning topology information, and the vehicle NIDS network message whitelist learning sub-algorithm is initiated (corresponding to steps 4-6 of the eight-step process flow). The system is assumed to exist in a trusted OEM manufacturing environment, during which the NIDS can securely receive network topology information generated during the vehicle manufacturing process to identify which ECUs are present and which network(s) they are members of. Therefore, the system uses the learned topology information from step 4 (based on the learned environment) in step 5, combined with a new compact system configuration ARXML file (e.g., ARXML (AUTOSAR XML) file) in step 6 to generate a baseline whitelist of vehicle network platform-specific content for designing the system, its configuration, its transportation, and information storage. This facilitates the reusability of software components (SWCs) across systems, which identify all possible ECUs and messages and their associated performance behaviors.

[0065] refer to Figure 2B , the process proceeds to task 225 to receive a signed calibration containing the sales code data area. Corresponding to step 7 of the eight-step process, at task 230, a determination is made as to whether the area corresponding to the area code allows data collection. In other words, if the proposed data collection is permissible under the privacy management of that area. If it is deemed permissible, the process makes another check or determination at task 235 (corresponding to the last step of the eight-step process, i.e., step 8) to check whether the Terms and Conditions and Privacy Statement (TCPS) are accepted. If deemed true, data collection is permitted, allowing the NIDS to collect and unload data, depending on the operating conditions set in the NIDS state in a manner that enables data to be sent to the back office. If, at task 235, the TCPS is not accepted, data collection is not permitted. The NIDS is set to a state that prohibits data collection, and no data is collected until the conditions change.

[0066] refer to Figure 2COnce the NIDS configuration is complete, at task 240, the NIDS is enabled to collect data. At task 245, a CAN frame or message is received. At task 250, the CAN frame or message is checked or evaluated to see if it is included in the list of frames or messages extracted by the NIDS. If it is not found in the list, then at task 270, it is considered a violation. Alternatively, if it is on the list, the process checks the CAN frame or message against a set of normal behaviors at task 260. At task 265, a determination is made as to whether the frame violates normal behavior. If so, the process continues by marking the traffic consisting of the CAN frame or message as a violation. If not, the process proceeds to task 275, and the traffic is marked as normal. Thus, through this set of tasks, the NIDS implements mechanisms by which it learns vehicle network configuration information and verifies the legitimacy of certain approved aftermarket ECUs that may be added to the vehicle network, while also adjusting the vehicle whitelist to add new messages and being able to detect tampering with previously learned configurations.

[0067] Figure 3 3 is a block diagram illustrating a central communication gateway module 300 that communicates with a group of ECUs 305 of an autonomous or semi-autonomous vehicle and external manufacturing and diagnostic systems 310, according to an exemplary embodiment. The NIDS of the central communication gateway module 300 is configured with an intelligent recognition algorithm that enables the central gateway to access (via buses and bus locations 325) and control the calibration and other configuration of the vehicle ECUs of 300, based on a set of parameters used to assess a trusted environment in which vehicle safety self-learning can occur. The central communication gateway module 300 handles direct and inter-ECU or routed communications, enabling data exchange between all onboard ECUs, in addition to enabling external communications from the manufacturing and diagnostic network of 310 to pass through the central communication gateway module 300 via a group bus and bus location 325. The central communication gateway module 300 is a common gateway that converts data from one bus format to another (i.e., an architecture containing different types of data buses).

[0068] In an exemplary embodiment, the present disclosure describes an algorithm implemented by a processor to determine a trusted operating environment for an in-vehicle network intrusion detection system (NIDS) for learning a vehicle platform. The processor executes the NIDS using the algorithm to monitor a set of electronic control units (ECUs) and vehicle state elements by receiving a set of vehicle inputs regarding the vehicle's operating state. In response to the determination regarding the vehicle's operating state, the processor may identify a trusted window during which learning regarding network topologies and whitelist messages included in a vehicle platform build configuration is permissible. The processor may create a vehicle build-specific configuration containing a list of network topologies and whitelist messages used by the set of ECUs in each vehicle platform build configuration. Based on an assessment of at least one security impact of the network topologies and whitelist messages included in the list used by the set of ECUs in the vehicle platform, the processor may prevent undocumented misconfiguration of at least one network in the list of network topologies and whitelist messages for the vehicle build-specific configuration in the vehicle platform outside the trusted window. The processor implements the algorithm to correlate the set of network topologies and whitelist messages with behavior related to a specific vehicle platform build or manufacture. The processor may also utilize elements of previously available data on network topologies generated for the vehicle platform network design.

[0069] Previous or previously available data includes ECU data, including network instances, network segment configuration, ECU network membership, frame routing, network message address translation, and frame signal routing definitions. ECU data is part of the vehicle network topology. Previously available data also includes bus data. Processor-implemented automated learning is based on the vehicle's sales region, as determined by an algorithm within the NIDS.

[0070] The processor implements the NIDS to use an existing calibration file or make it readily available, otherwise it enables an unresolvable canonical region specific URL to extract the sales region of the vehicle to enable operability of the NIDS according to the privacy regulations of the region where the vehicle has been sold.

[0071] The processor extracts the learned topology from a compact system network profile to generate at least one whitelist message set for vehicle construction based on whitelist message usage.

[0072] In various exemplary embodiments, the implementation Figure 1 The algorithm 152 can be created in an offline training process derived from a supervised or unsupervised learning process and can be implemented using a neural network. For example, the neural network can include a trained convolutional neural network (CNN) and / or recurrent neural network (RNN), where similar methods can be applied and used for vehicle control operations.

[0073] In an exemplary embodiment, the algorithm may be implemented as a dynamic neural network that is trained during a training mode prior to use or provision in a vehicle (or other vehicles). Once the dynamic neural network is trained, it may be used in a vehicle (e.g., Figure 1 The system is implemented in an operating mode in a vehicle 100) in which the vehicle is operated in an autonomous, semi-autonomous or manual manner.

[0074] In various alternative exemplary embodiments, it will be appreciated that a neural network may also be implemented in a vehicle in a training mode and an operating mode and trained during initial operation in conjunction with operation of methods such as time delays for torque control prediction. Furthermore, in various embodiments, a vehicle may be operated only in an operating mode with a neural network that has been trained via a training mode with the same vehicle and / or other vehicles.

[0075] As briefly mentioned, the various modules and systems described above can be implemented as one or more machine learning algorithms or models that undergo supervised, unsupervised, semi-supervised, or reinforcement learning. Examples of such algorithms include, but are not limited to, artificial neural networks (ANNs) (such as recursive neural networks (RNNs) and convolutional neural networks (CNNs)), decision tree models (such as classification and regression trees (CARTs)), ensemble learning models (such as boosting, bootstrap aggregation, gradient boosting machines, and random forests), Bayesian network models (e.g., Naive Bayes), principal component analysis (PCA), support vector machines (SVMs), clustering models (such as K-nearest neighbors, K-means, expectation maximization, hierarchical clustering, etc.), and linear discriminant analysis models.

[0076] It should be understood that Figure 1-3 The process may include any number of additional or alternative tasks, Figure 1-3 The tasks shown do not need to be performed in the order shown, and Figure 1-3 The processes may be incorporated into more comprehensive programs or processes having additional functionality not described in detail herein. Figure 1-3 One or more of the tasks shown can be Figure 1-3 Examples of processes shown are omitted so long as the intended overall functionality remains intact.

[0077] The foregoing detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word "exemplary" means "serving as an example, instance, or illustration." Any embodiment described herein as exemplary is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, no intention is to be bound by any expressed or implied theory presented in the preceding technical field, background, or detailed description.

[0078] Although at least one exemplary embodiment has been presented in the foregoing detailed description, it should be understood that a large number of variations exist. It should also be understood that one or more exemplary embodiments are merely examples and are not intended to limit the scope, applicability, or configuration of the present disclosure in any way. Instead, the foregoing detailed description will provide those skilled in the art with a convenient roadmap for implementing one or more exemplary embodiments.

[0079] It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the disclosure as set forth in the appended claims and the legal equivalents thereof

Claims

1. A method for determining a trusted operating environment for a vehicle-mounted network intrusion detection system (NIDS) for a learning vehicle platform, comprising: executing, by the processor, an NIDS using an algorithm to monitor a set of electronic control units and vehicle status elements by receiving a set of vehicle inputs regarding vehicle operating status; identifying, by the processor, a trusted window during which learning about a network topology and whitelisted messages contained in a vehicle platform build configuration is permissible, responsive to a determination regarding a vehicle operating state, wherein the identification is based on a manufacturing-related security access level and vehicle mileage; creating, by a processor, a vehicle build specific configuration, the vehicle build specific configuration comprising a network topology and a list of whitelist messages used by the set of electronic control units in each vehicle platform build configuration; as well as Based on an evaluation result of at least one security impact of the network topology and whitelist messages included in the list for use by the set of electronic control units in the vehicle platform, the processor prevents a vehicle in the vehicle platform outside of the trusted window from constructing an undocumented misconfiguration of at least one network in the list of network topology and whitelist messages of a specific configuration.

2. The method according to claim 1, further comprising: The network topology and whitelist message are generated by the algorithm, and the whitelist message has a behavior related to a specific build of a vehicle platform.

3. The method according to claim 2, further comprising: Elements of previously available data that implement the network topology generated for vehicle platform network design.

4. The method according to claim 3, wherein: The previously available data includes ECU data consisting of network instances, network segment configurations, ECU network membership, frame routing, network message address translation, and frame signal routing definitions, which are part of the vehicle network topology.

5. The method according to claim 3, wherein: The previously available data includes bus data.

6. The method according to claim 4, further comprising: Automatic learning of vehicle sales areas is achieved through the algorithm in the NIDS.

7. The method according to claim 6, further comprising: The NIDS is enabled to use existing calibration files to make them readily available, or to enable non-resolvable canonical region specific URLs to extract the sales region of the vehicle to enable operability of the NIDS according to the privacy regulations of the region where the vehicle has been sold.

8. The method according to claim 7, further comprising: A processor extracts the learned topology via a compact system network profile to generate at least one whitelist message set for a vehicle build based on the whitelist message usage.

9. A system comprising: a processor configured to execute an in-vehicle network intrusion detection system (NIDS) with an algorithm to monitor a set of electronic control units and vehicle state elements by receiving a set of vehicle inputs regarding vehicle operating status; In response to a determination regarding an operating state of the vehicle, the processor is configured to identify a trusted environment that may allow learning about a network topology and whitelist messages included in a specific build of the vehicle platform, wherein the trusted environment is based on a trusted environment window, the trusted environment window being identified based on a security access level associated with manufacturing and mileage of the vehicle; the processor being configured to create a vehicle-specific configuration comprising a network topology and a list of whitelist messages for use by the set of electronic control units in a vehicle platform-specific build; as well as The processor is configured to prevent misconfiguration of at least one network in the list of network topologies and whitelist messages for a vehicle-specific configuration in a vehicle platform outside the trusted environment window based on an evaluation of at least one security impact of the network topologies and whitelist messages included in the list for use by the set of electronic control units in the vehicle platform-specific build.

10. The system of claim 9, further comprising: The processor implements the algorithm to generate the network topology and a whitelist message having a behavior associated with a vehicle platform; The processor is configured to implement previously available data of a network topology generated during manufacture of the vehicle; wherein the previously available data includes ECU data that is part of a vehicle network topology, wherein the data includes controller area network (CAN) ECU bus membership; The processor is configured to implement automatic learning of vehicle sales regions using an algorithm in the NIDS; and The processor is configured to extract at least one whitelist message set for a vehicle platform specific build based on the whitelist message usage via the compact system network profile in conjunction with the learned topology.

Images