WO2019118425A1

WO2019118425A1 - Secure transmission module

Info

Publication number: WO2019118425A1
Application number: PCT/US2018/064900
Authority: WO
Inventors: Aaron Sanjaya BENEDEK; Samir Kumar MISHRA; Yao LU
Original assignee: Trillium Incorporated
Priority date: 2017-12-11
Filing date: 2018-12-11
Publication date: 2019-06-20

Abstract

An analysis module performs real time analysis of incoming data to determine whether to allow the data to pass through to a functional module of system, such as a controller in a vehicle. The analysis module may perform a number of checks in serial or parallel using appropriate logic to evaluate a threat posed by the incoming data. When no threat is found, the data is passed to the functional module, such as an engine or transmission controller. When a threat is identified, an incidence response module may take an appropriate action such as discarding the data, reporting the finding, or even disqualifying a source of the data.

Description

SECURE TRANSMISSION MODULE

Background

[0001] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0002] Vehicles increasing rely on electronics for discrete functions and as well increasingly rely on in-vehicle and extra-vehicle data communications among various functions for command and control of the vehicle. In-vehicle networks have been in use since the 1980s but have primarily been designed for reliability and noise immunity given the extremely harsh operating environment. Now, particularly in view of self- driving vehicles with integrated mapping, laser ranging, and image recognition systems, more than simply reliable and accurate transmission of data is of interest. Protection from intrusion into the vehicle network by unknown actors was recently announced as the single largest concern among automotive executives. Examples of vehicle network intrusion are well publicized. The threat posed by malicious hacking of a vehicle network is hard to overestimate.

Summary

[0003] A module may be added at various access points in a vehicle or other connected devices to provide high speed intrusion detection and protection. The devices may use serial or parallel evaluation of an incoming message to determine the source of a message, whether the source is known, and whether the message itself contains unexpected content, of either a malicious origin or simply due to a malfunction elsewhere in the vehicle. The module may take steps to protect the system by isolating the source, raising an error, taking countermeasures against a bad actor, or combinations of these and other responses.

Brief Description of the Drawings

[0004] The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0005] Fig. 1 is a block diagram of an exemplary system real time data checks in accordance with the current disclosure;

[0006] Fig. 2 is block diagram of an exemplary secure transmission module suitable for use in the system of Fig. 1 ;

[0007] Fig. 3 is an exemplary data flow for the secure transmission module of Fig. 2;

[0008] Fig. 4 is an alternative data flow for the secure transmission module of Fig. 2;

[0009] Fig. 5 is a top level functional view of the secure transmission module of Fig.

2;

[0010] Fig. 6 is a second level functional view of one aspect of the top level view of Fig. 5;

[0011] Fig. 7 is a continuation of the second level functional view of Fig. 6; and

[0012] Fig. 8 is a continuation of the second level functional view of Fig. 7.

Detailed Description

[0013] Flacking a computer system raises the risk of loss of personal data or exposure of company secrets and may result in financial losses. Flacking a control system, whether it is in a vehicle or an Internet of Things (loT) device may cause the system to malfunction and damage itself or its surroundings. For example, a hacked vehicle may have its braking system tampered with. A hacked thermostat may allow a structure to freeze resulting in cracked pipes and water damage. A disabled alarm system may allow a fire to spread unnoticed.

[0014] A secure transmission module may allow messages from outside a vehicle or loT device as well as messages generated inside the vehicle or loT device to be analyzed in real time prior to gaining access to a vehicle subsystem or loT device. The secure transmission module may discard an individual message that does not pass a review. In addition, a source of the suspect message may be disabled or excluded from the associated network when certain conditions are met, such as a number of bad messages in a row from a particular source or when even a single message is identified as having a malicious payload.

[0015] The block diagram of Fig. 1 illustrates an exemplary vehicle 102 with various internal subsystems connected by a network 103. The vehicle 102 of Fig. 1 is shown with an engine controller 104, a transmission controller 106 and a body electronics module 108. The vehicle 102 may also include a single or multiple break modules 110 and an entertainment controller 112. The vehicle may also include a gateway 114 that is coupled to a cloud server 116. The cloud server 116 may support telematics data as well as entertainment content. Also illustrated are a number of secure transmission modules 118. Each secure transmission module 118 may evaluate messages received on the internal network 103 or data being transmitted via the gateway 114.

[0016] As shown in Fig. 1 , a secure transmission module 118 may be completely implemented within its respective controller such as the engine controller 104. In such an embodiment, data passed from the secure transmission module 118 to the controller may be injected directly into an input processor, an internal memory, or a register. In an embodiment where the secure transmission module 118 is external to a controller, such as shown with the transmission controller 106, the secure transmission module 118 may be required to emulate whatever protocol is used on the network 103 for data transfers with the respective controller. In the illustration of Fig. 1 , a secure transmission module 118 may be associated with cloud server 116 in order to validate data either coming from or being sent to the vehicle 102. [0017] While it may be desirable to have a secure transmission module 118 at each data processing point, it is not necessary, as shown with the entertainment controller 112. In some embodiments, a secure transmission module 118 may only evaluate inbound data to offer protection to its respective controller. In another embodiment the secure transmission module 118 may monitor data in both directions, that is both data arriving at and being sent from a particular controller.

[0018] An incident response module 124 may implemented in the cloud server 116 and may be in communication with each of the various secure transmission modules 118 in order to evaluate and act on error messages. The incident response module 124 may receive and analyze data received from a vehicle or other loT device. In addition to analyzing the data received, the incident response module 124 may take actions according to rules or heuristics associated with that data source, either as a class or based on an individual setting. For example, a warning about a service item may be sent to a driver or when sensing a critical situation a vehicle may even be remotely stopped. In another embodiment, however, some level of incident response may be managed within each secure transmission module 118, with relevant data shared between modules 118. For example, after detecting a denial of service attack that may limit an ability to communicate with the incident response module 124, a secure transmission module 118 may begin discarding packets until a traffic rate returns to a more normal level.

[0019] Fig. 2 may illustrate an exemplary block diagram of a secure transmission module 118. The secure transmission module 118 may include a processor 120 and a memory 122 coupled via a data bus 121. A data bus may also connect the processor to a network input output module 125 that may manage communication with, for example, vehicle network 103. An output module 126 may format data for presentation to the respective system or subsystem to which the secure transmission module 118 is coupled, e.g., the engine controller 104.

[0020] In some embodiments, a virtualized environment may be deployed so that a single processor 120 is not physically embodied but rather is part of a virtual machine instance of a virtual environment. In such cases, a single or multi-core computing environment may host different systems in isolated containers so that safety critical and non-safety critical systems may operate in separate virtual environments. In such a virtualized environment, the secure transmission module 118 may also operate as a virtualized instance.

[0021] The memory 122 may include code that is executable by the processor 120 to implement a number of systems, services, and functions. An operating system 128 may manage routine functions such as memory management, work interactions, file management, diagnostics etc. In this illustration, data inspection may be performed via a number of individual checks represented by a generic check module 130, a deep packet inspection module 132, and an error checking/handling module 136. As discussed above, an incident response function 138 may be built into the secure transmission module 118 or may be present external to the module 118.

[0022] The generic check module 130 may identify aspects of the message itself such as where the message comes from, a volume or velocity of messages from that source, and a format check. The source of the message may be of interest from an operational standpoint, such as, a transmission controller 106 may not expect to receive a message from the entertainment controller 112. Even messages from an expected source may arrive at a higher than expected volume indicating perhaps a denial of service attack. Malformed messages may indicate an attempt to cause a stack overflow error in a target controller.

[0023] A deep packet inspection module 132 may evaluate contents of a message to determine whether the message itself represents data that is within expected

parameters, particularly in view of an operating characteristic of the vehicle.

Unexpected data may arise for any of several reasons. In one case, a simple malfunction in one module may create malformed packets, spurious data, or flood a network with messages, to name a few possible scenarios. In another case, malicious attempts to access critical systems or disrupt operations may result in non-compliant data packets or message contents. For example, a sequence of full throttle and no throttle messages arriving faster than a human can operate the vehicle controls may indicate an attempt to cause damage to the engine. In this respect, a machine learning engine 134 may help to evaluate message contents in view of previous messages, driving patterns, known vehicle performance characteristics and may help identify messages that are inconsistent with normal operation of one or more vehicle systems.

[0024] In an embodiment, illustrated more fully in Fig. 5, the intrusion detection 200 and intrusion prevention 202 aspects of the secure transmission module represented by the deep package inspection 132 and machine learning 134 modules may not be present in every instance of secure execution module. For example, a secure execution module 118 embedded in an engine controller 104 may not implement deep packet inspection. In another embodiment, intrusion detection 200 and intrusion prevention 202 functions may be implemented separately from the secure execution module 118.

In such an embodiment, a secure execution module 118 may be embedded in a controller, e.g., ECM 104 and an intrusion detection function 202 may be implemented external to the controller.

[0025] An error checking/handling module 136 may monitor the error package, and detect the intrusion based on the anomalous behavior of the error packages. This module is specifically designed for an attack that disables the target ECU by increasing the error counter significantly. The types of error may not just include the simple errors such as format errors, CRC errors, but may also cover secure package errors such as MAC errors, freshness value errors, or both. The error module 136 may, in an embodiment, detect the malicious errors and send a report to the incident center.

[0026] The incident response module 138 may take steps to protect the system by discarding messages that do not meet expected parameters as well as log those messages and report the identification, disposition, and source of such messages.

[0027] While the embodiment illustrated in Fig. 2 shows three evaluation modules, these functions and processes may be divided in different manners and either further combined or further separated.

[0028] Fig. 3 may illustrate one evaluation technique used by a secure transmission module 118 to evaluate a message. In this illustration, checks may be performed serially. Data may be received at block 150 where the generic check may be performed by, for example, module 130. If passed at block 150, the message may be passed to block 152 where the deep package inspection may be performed by module 132. If passed at block 152, the message may be accepted and passed forwarded to its respective controller. When any of the checks fail, an error handling function 154 may record and report error data to an incident response function 158 such as processing by the incident response module 124. Local errors such as CAN bus errors or data CRC errors may be reported to the incident response module 124 but may be handled locally within the system detecting the error. As discussed above, some errors like a denial of service attack may prompt a local response.

[0029] Alternatively, at Fig. 4, a message may be processed in parallel so that each evaluation is performed simultaneously at blocks 170 and 172. Only when each block passes the message, is the message accepted at block 176. Similar to the above process, any failure at any of the blocks 170, 172, 174 will cause execution to continue at an incident response function 178 such as processing by the incident response module 124. Whether processed in serial or parallel, the ability to quickly evaluate and pass or fail a data message may be a valuable aspect of some systems where real time messaging may be valuable for correct system function. For example, a delay in messages between the engine controller 104 and the transmission controller 106 may affect passenger comfort, fuel economy, or other operational aspects.

[0030] Figs. 5-8 illustrate the functions of the secure execution module 118 from a more functional perspective. Fig. 5, illustrates a top level view showing two main aspects of message evaluation. The first is an intrusion detection system 200 that is discussed more with respect to Fig. 6. The second is an intrusion protection system which is discussed in more detail with respect to Figs. 7 and 8. Turning to Fig. 6, intrusion detection may be illustrated as a number of higher level functions, some of which may have sub-functions. In this illustration, an analysis function 204 may involve several aspects of checking including anomaly-based detection 206. This may include a check of data values, data format, protocol, or other data elements that would be expected to meet certain criteria but are out of range from that expectation. A network behavior analysis function 208 may include, as discussed above, volume and velocity of data as well as data source. When such a signature check fails, the message may be diverted to the incident response module 138. A stateful protocol analysis detection function 212 may evaluate the message type and requests as compared to a REST message format. That is, a PUT message may be inconsistent with a module that routinely only responds to GET messages.

[0031] A machine learning function 214 may operate in conjunction with the analysis function 204 and may include an intrusion detection database 216, framework and tensor flow integration functions 218, 220, respectively. These latter functions may be implementation-specific and allow various weighting factors to be modified as the database grows and becomes more refined.

[0032] A database updater for the intrusion protection system 222 may provide for changes to the database from both external and internal sources. The intrusion protection function 200 may rely on a rules-based system to allow faster evaluations. A rule system database 224 may store those rules.

[0033] The intrusion protection function 202 may include a number of high level functions including a backup database 230 and a corresponding backup function 232. An intrusion protection database updater 34 may receive updates that are both network component specific 236, that is, native system aspects as well as over the air component specific updates 238. OTA component updates may be received from the cloud 116 representing any number of executive systems such as OEMs and tier 1 or tier 2 suppliers. The intrusion protection function 202 may also support pre-emptive measures when a suspected attack is identified. For example, the intrusion protection function 202 may isolate a source of suspicious data from the network 103. In another example, the intrusion protection system 202 may launch a counter measure against the offending data source, such as, but not limited to, sending data to that may mislead the attacker to a false conclusion or that causes the offending data source to re-initialize and perhaps remove any recently-introduced code.

[0034] A fault handler 240 may include those functions discussed above such as for reporting 242 as well as protection system and detection system fault handlers 246, that, for example, manage message disposition. The fault handlers 246 may also provide data to the rule database update function 248. The rule database 250 itself may have aspects specific to a particular engine control unit 252 that are both function specific 254 and hardware specific 256. That is, engine control unit specific functions may vary both based on the actual hardware of the system as well as functions performed by that specific hardware. The rule database 250 may also be driven by nonspecific elements 260 such as known attack vectors 262 that may apply across multiple hardware or function boundaries.

[0035] Similarly, network specific attacks and their corresponding rules 264 may include rules associated with any number of networks. Turning briefly to Fig. 8, these networks may include, but are not limited to, a controller area network (CAN) flexible data rate (FD) network 270, a regular CAN network 272, different implementations of ethernet standards 274 such as automotive 276 and the standard ethernet 278. Other networks may include the Flexray network 280, ISO-TP 282, ISO-UDS 284, local interconnect network (LIN) 286, and media oriented Systems Transport (MOST) network 288. Returning to Fig. 7, rules may be generated according to various OEM specific implementations 266 such as various communication protocols 268.

[0036] The technical effect of the disclosed systems and methods is an ability to perform a real time threat analysis of extra-vehicular and intra-vehicular

communications in order to detect and protect against erroneous or malicious communications within a control-based system. Although the discussion above focuses primarily on real time communications, the impact on loT devices is similar in that messages that may subvert the function of the device may be intercepted, ignored when warranted, reported, and added to a database of attack vectors to improve future message screening.

[0037] The techniques disclosed herein benefit all parties with an interest in the correct operation of controller-based systems be they industrial, commercial, or consumer-oriented. The ability to protect systems from unwanted messages be they simple errors, a nuisance, or a genuine threat to the safety of people and property benefits all aspects of an ecosystem associated with the systems and devices being protected.

[0038] The figures depict preferred embodiments for purposes of illustration only.

One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0039] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be

understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.

Claims

1. A security apparatus for real time threat analysis comprising:

a processor;

an input coupled between the processor and a data network;

an output that selectively passes data from the input to a downstream entity; and a memory storing executable code implementing a plurality of modules that

analyze data received at the input, the plurality of modules including:

a generic check module that analyzes a source of the data and a format of the data and sends a non-compliant condition indicator ;

a deep package inspection module that analyzes data relationships and data sequence;

an error handler that evaluates error classes and recurrence; and an incident response module that one of modifies or blocks the data

received at the input responsive to a non-compliant condition indicator received from one or more of the the generic check module, the deep package inspection module, and the error handler.

2. The security apparatus of claim 1 , wherein the generic check module signals the incident response module to act on the received data responsive to the received data failing to meet a required format.

3. The security apparatus of claim 1 , wherein the generic check module signals the incident response module to act on the received data responsive to the received data exceeding a message velocity limit corresponding to a source of the received data.

4. The security apparatus of claim 1 , wherein the generic check module signals the incident response module to act on the received data responsive to the received data arriving from an unauthorized source.

5. The security apparatus of claim 1 , wherein the deep package inspection module incorporates a machine learning engine that trains on received data and prior results from the deep package inspection module.

6. The security apparatus of claim 5, wherein the deep package inspection module evaluates a content of the data and responsive to determining that the content is not consistent with expected parameters sends a non- compliance indicator to the incident module.

7. The security apparatus of claim 5, wherein the deep package inspection module evaluates a content of the data in view of performance characteristics of the vehicle to determine data that is inconsistent with normal operation of a corresponding vehicle system.

8. The security apparatus of claim 1 , wherein the incident response module

discards messages from a source that is identified as sending non- compliant messages.

9. A method of evaluating data received in a system, the method comprising:

receiving a data packet intended for a downstream subsystem;

performing a generic check of the data for format and source discrepancies; performing a deep package inspection of a content of the data packet involving artificial intelligence analysis of the data packet;

performing an error check of the data packet;

responsive to finding an irregularity at any of the performing steps, removing the data packet from a flow of data to the subsystem.

10. The method of claim 9, further comprising:

responsive to finding an irregularity, generating a response action related to the irregularity.

11. The method of claim 10, wherein generating the response action comprises isolating a source of the irregularity from a network supporting the packet communication.

12. The method of claim 10, wherein generating the response action comprises purposefully sending generated data to a source of the irregularity to reduce an effectiveness of an attack.

13. The method of claim 9, wherein performing the generic check, performing the deep package inspection, and performing the error check of the data packet are performed independently and in parallel.

14. The method of claim 9, wherein performing the deep package inspection

comprises determining that the content of the data packet is inconsistent with historical contents of data packets from the same source.

15. The method of claim 9, wherein performing an error check of the data packet comprises performing a check of a message authentication code (MAC).