Patent Publication Number: US-9843597-B2

Title: Controller area network bus monitor

Description:
RELATED APPLICATION DATA 
     The present application claims the benefit of U.S. Provisional Application No. 62/099,603, titled “Easy to Deploy Origin-Validation and Alert System for CAN-Bus Messages”, and filed on Jan. 5, 2015, the entire contents of which are incorporated by reference as if included herein. 
    
    
     BACKGROUND 
     The present invention relates to monitoring data, and more specifically, but not exclusively, to monitoring data in a controller area network bus. 
     SUMMARY 
     According to an embodiment described herein, a system to monitor a controller area network bus can include a processor to detect a message from a source electronic control unit in a vehicle. The processor can also calculate a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between a first monitor and the source electronic control unit. Additionally, the processor can detect that the message corresponds to a function controlled by a second electronic control unit, and generate a warning that the message from the source electronic control unit is malicious. 
     According to another embodiment described herein, a method for monitoring a controller area network bus can include detecting, via a processor, a message transmitted by the controller area network from a source electronic control unit in a vehicle. The method can also include calculating, via the processor, a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between a first monitor and the source electronic control unit based in part on a wave propagation speed. Additionally, the method can include detecting, via the processor, that the message corresponds to a function controlled by a second electronic control unit, and generating, via the processor, a warning that the message from the source electronic control unit is malicious. 
     According to yet another embodiment described herein, a computer program product can monitor a controller area network bus, wherein the computer program product comprises a computer readable storage medium having program instructions embodied therewith and the computer readable storage medium is not a transitory signal per se. The program instructions can be executable by a processor to cause the processor to detect, via the processor, a message from a source electronic control unit in a vehicle and calculate, via the processor, a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between a first monitor and the source electronic control unit based in part on a wave propagation speed. Furthermore, the program instructions can cause the processor to detect, via the processor, that the message corresponds to a function controlled by a second electronic control unit and generate, via the processor, a warning that the message from the source electronic control unit is malicious. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         FIG. 1  depicts a block diagram of an electronic control module that can monitor a controller area network bus according to an embodiment described herein; 
         FIG. 2A  depicts two monitor units for monitoring a controller area network bus according to an embodiment described herein; 
         FIG. 2B  depicts a single monitor unit for monitoring a controller area network bus according to an embodiment described herein; 
         FIG. 3  depicts a technique for calculating a distance between a monitor unit and a source electronic control unit in a controller area network according to an embodiment described herein; 
         FIG. 4  is a process flow diagram of an example method that can monitor a controller area network bus according to an embodiment described herein; and 
         FIG. 5  is a tangible, non-transitory computer-readable medium that can monitor a controller area network bus according to an embodiment described herein. 
     
    
    
     DETAILED DESCRIPTION 
     Modern vehicles are monitored and controlled by dozens of electronic control units (ECUs) which communicate and coordinate using an intra-vehicle network. The de-facto standard of the automotive industry for establishing network-connectivity between ECUs is the Controller Area Network bus (also referred to herein as CAN-bus). The CAN-bus establishes broadcast communication between ECUs, allowing near real time communication that is required to support in-vehicle systems including critical safety systems such as anti-lock braking, air-bags, and crash-prediction. 
     The CAN-bus architecture was designed to provide a reliable channel for short control messages that is robust to errors and malfunctions. Accordingly, the CAN protocol supports message prioritization and integrates cyclic redundancy checks to ensure that messages arrive without errors. However, the CAN protocol was not designed for security. For example, the source of a CAN message is not authenticated and not even specified in messages. Therefore, a compromised ECU can send spoofed malicious messages, which can compromise the safety of the vehicle and pose a danger to passengers in case of a cyber-attack. A hacker may compromise an ECU by exploiting vulnerabilities in the ECU&#39;s firmware or by transmitting malware to the vehicle&#39;s electronic control systems (e.g., by connecting to the physical on-board diagnostic interface). The risk for attacks increases as vehicles communicate with each other (using vehicle to vehicle communication) or with the infrastructure (vehicle to infrastructure communication) and establish vehicular ad-hoc networks. This provides a greater attack surface and allows compromised vehicles to infect the vehicles around them. Therefore, the security of the vehicle&#39;s embedded systems and communication links between them has become a concern for manufacturers. 
     The system described herein monitors the CAN-bus and detects a location of an ECU that generates a message by leveraging the communication properties of the CAN-bus. The system described herein does not require interactive protocols such as changes to existing ECUs, which can create a deployment problem. Furthermore, the techniques described herein avoid implementing a cryptographic challenge-response protocol, which has unreasonable overhead for communication over the CAN-bus. Rather, the origin-detection technique described herein is passive and does not incur any overhead on CAN-bus communications and does not require updating existing ECUs or firmware. 
       FIG. 1  is a block diagram of an example electronic control module monitor that can monitor a controller area network bus. The electronic control module monitor  100  may be, for example, a mobile phone, laptop computer, desktop computer, or tablet computer, among others. The electronic control module monitor  100  may include a processor  102  that is adapted to execute stored instructions, as well as a memory device  104  that stores instructions that are executable by the processor  102 . The processor  102  can be a single core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory device  104  can include random access memory (e.g., SRAM, DRAM, zero capacitor RAM, SONOS, eDRAM, EDO RAM, DDR RAM, RRAM, PRAM, etc.), read only memory (e.g., Mask ROM, PROM, EPROM, EEPROM, etc.), flash memory, or any other suitable memory systems. The instructions that are executed by the processor  102  may be used to monitor a controller area network bus. 
     The processor  102  may be connected through a system bus  106  (e.g., PCI, ISA, PCI-Express, NuBus, etc.) to an input/output (I/O) device interface  108  adapted to connect the electronic control module monitor  100  to one or more I/O devices  110 . The I/O devices  110  may include, for example, a keyboard, a gesture recognition input device, a voice recognition device, and a pointing device, wherein the pointing device may include a touchpad or a touchscreen, among others. The I/O devices  110  may be built-in components of the electronic control module monitor  100 , or may be devices that are externally connected to the electronic control module monitor  100 . 
     The processor  102  may also be linked through the system bus  106  to a display device interface  112  adapted to connect the electronic control module monitor  100  to a display device  114 . The display device  114  may include a display screen that is a built-in component of the electronic control module monitor  100 . The display device  114  may also include a computer monitor, television, or projector, among others, that is externally connected to the electronic control module monitor  100 . A network interface card (NIC)  116  may also be adapted to connect the electronic control module monitor  100  through the system bus  106  to a network (not depicted). 
     The storage  118  can include a hard drive, an optical drive, a USB flash drive, an array of drives, or any combinations thereof. The storage  118  may include a message detector  120  that can detect a message from any suitable source electronic control unit in a vehicle. For example, the message detector  120  can detect a message from an engine control module (ECM), an electronic brake control module (EBSM), a transmission control module (TSM), and a body control module (BCM), among others. The message detector  120  can also calculate a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between the electronic control module monitor  100  and the source electronic control unit. For example, a source electronic control unit can transmit messages in two directions on a CAN-bus. Accordingly, the electronic control module monitor  100  can detect an arrival time associated with messages that are transmitted in either direction on the CAN-bus. In some embodiments, storage  118  can also include a security module  122  that can detect that the message corresponds to a function controlled by a second electronic control unit. In some examples, the security module  122  can detect that the source electronic control unit generates a message pertaining to a function that is performed by another electronic control unit. For example, the security module  122  can detect that an engine control module (ECM) generates a message pertaining to a braking function controlled by an electronic brake control module (EBSM). 
     In some examples, the security module  122  can also generate a warning that the message from the source electronic control unit is malicious. For example, the security module  122  can generate a warning that the message generated by the source electronic control unit is malicious because the message pertains to a function controlled by another electronic control unit. The security module  122  can also generate a warning that the message is malicious based on a determination that the distance between source electronic control unit and the authorized electronic control unit exceeds a threshold. For example, the warning can indicate that the function of the message is associated with an electronic control unit that is located a distance from the source electronic control unit that exceeds a predetermined threshold. 
     It is to be understood that the block diagram of  FIG. 1  is not intended to indicate that the electronic control module monitor  100  is to include all of the components shown in  FIG. 1 . Rather, the electronic control module monitor  100  can include fewer or additional components not illustrated in  FIG. 1  (e.g., additional applications, additional modules, additional memory devices, additional network interfaces, etc.). Furthermore, any of the functionalities of the message detector  120  and security module  122 , may be partially, or entirely, implemented in hardware and/or in the processor  102 . For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor  102 , or in any other device. 
       FIG. 2A  depicts two electronic control unit monitors (also referred to herein as monitor units) for monitoring a controller area network bus in a vehicle according to an embodiment described herein. The two monitor units  202  and  204  can monitor messages and data transmitted on the controller area network bus  206 . In some embodiments, the controller area network bus  206  can transmit messages and data for any suitable number of electronic control units such as an engine control module (ECM)  208 , an electronic brake control module (EBSM)  210 , a transmission control module (TSM)  212 , and a body control module (BCM)  214 , among others. 
     In some embodiments, the monitor units  202  and  204  are located at the edge of the controller area network bus  206 . In some examples, the monitor units  202  and  204  can transmit data to a control unit  216 , which can standardize time readings associated with messages. For example, the control unit  216  can standardize times associated with messages received by the monitor unit  202  and times associated with messages received by the monitor unit  204 . The control unit  216  can also validate the source electronic control unit of each bit in a message&#39;s payload. For example, the control unit  216  can detect the distance between the source electronic control unit and a monitor unit  202  or  204  and then the control unit  216  can determine if the source electronic control unit is valid. In some embodiments, the validity of the source electronic control unit (also referred to herein as source ECU) depends on the contents of the message. For example, the contents of the message should correspond to the functions managed by the source ECU. 
     In some embodiments, the monitor units  202  and  204  can record the arrival time stamp of the first bit in a message payload and monitor collisions on the CAN-bus in the middle of message transmission. In this example, each monitor unit  202  and  204  sends to the control unit  216  the message, the first-bit of the arrival time stamp, and a binary indication for whether there was a collision during transmission of the message&#39;s payload. The control unit  216  validates that the source of the first bit is authorized to send the message and that there was no collision on the CAN-bus. 
       FIG. 2B  depicts a single monitor unit for monitoring a controller area network bus in a vehicle according to an embodiment described herein. The monitor unit  218  can monitor messages and data transmitted on the controller area network bus  206 . As discussed above, in some embodiments, the controller area network bus  206  can transmit messages and data for any suitable number of modules such as an engine control module (ECM)  208 , an electronic brake control module (EBSM)  210 , a transmission control module (TSM)  212 , and a body control module (BCM)  214 , among others. 
     In some embodiments, the monitor unit  218  can be attached to each end of the controller area network bus  206 . In some examples, the two arrival time stamp measurements associated with a message&#39;s payload are produced by a single clock, thereby, avoiding clock synchronization challenges and reducing deployment costs. Furthermore, detecting messages transmitted on a controller area network bus  206  with a single monitor  218  eliminates the requirement for a control unit. The monitor unit  218  can be configured with distances and message identifiers of various modules  208 ,  210 ,  212 , and  214  that transmit data on the controller area network bus  206 . The monitor unit  218  can then monitor the controller area network bus  218  to detect a source ECU associated with a message and, if necessary, provide warning messages indicating malicious messages have been detected. 
       FIG. 3  depicts a technique for calculating a distance between a monitor unit and a source electronic control unit in a controller area network according to an embodiment described herein. The source electronic control unit  302  can include any suitable module that transmits data or messages via the controller area network bus. For example, the source control unit can include the engine control module (ECM)  208 , electronic brake control module (EBSM)  210 , transmission control module (TSM)  212 , or body control module (BCM)  214  of  FIG. 2A , among others. 
     In some embodiments, monitor units M1  304  and M2  306  can be placed on the controller area network bus on either side of a source electronic control unit  302 . In some examples, the monitor units M1  304  and M2  306  are placed at either end of the controller area network bus. The monitor units M1  304  and M2  306  can be used to identify a location of the source electronic control unit  302  that transmits a message. For example, the monitor units M1  304  and M2  306  can detect at least two Arrival Time Stamps (also referred to herein as ATS). Each monitor unit M1  304  and M2  306  can include a clock recorder that enables detecting the location of the source electronic control unit  302  on the controller area network bus. For example, the monitor units M1  304  and M2  306  can determine low level characteristics of the CAN-bus in order to detect the location of the source ECU on the CAN-bus. In some embodiments, the low level characteristics can include a propagation delay that is equal to d/C, where d is the distance between a source or sender module and a recipient module, and C is the wave propagation speed. Accordingly, the arrival time stamp (ATS) measurements can be modeled by Equation 1 below, where tS and tR denote the sending time of the message and receiving time of the message respectively. Additionally, ε denotes the measurement error (e.g., due to clock inaccuracy), which is bounded, i.e., |ε|≦Δ.
 
 tR=tS+d/C +ε(1)  Eq(1)
 
     The location of the source ECU  302  on the Can-bus can be determined by the distance between the source ECU  302  and monitor unit M1  304  and M2  306 . In  FIG. 3 , L denotes the distance between the two monitor units M1  304  and M2  306 . Additionally, L1 denotes the distance between the source ECU  302  that transmits a message and the monitor M1  304 . The following Equation 2 can estimate the distance from the source ECU  302  to monitor M1  304 :
 
 L′ 1= C/ 2( t 1 R−t 2 R+I/C )  Eq(2)
 
     In Equation 2, L′1 denotes the estimated distance between the source ECU  302  and the monitor M1  304 . Additionally, t1R and t2R denote the message receiving time at M1  304  and M2  306  respectively. The estimation error of the location of the source ECU  302  is bounded by ΔC, where |L′1−L1|&lt;ΔC. In some examples,
 
 t 1 R=t 0 +I 1/ C+ε 1  Eq(3)
 
 t 2 R=t 0+( I−I 1)/ C+ε 2  Eq(4)
 
     In Equation 3 and Equation 4, t0 denotes the transmission time between the source ECU  302  and a monitor unit M1  304  or M2  306 . Additionally, ε1 and ε2 denote the error in arrival time stamps determined by monitor unit M1  304  and monitor unit M2  306  respectively. In some examples, |ε1|, |ε2|≦Δ. Equations 3 and 4 can be used to determine L1 in some embodiments. For example, L1 can be determined by Equation 5:
 
 L 1 =C/ 2( t 1 R−t 2 R+I/C+ε 1−ε2)  Eq(5)
 
     In some embodiments, the error bound can be determined using Equation 6 below:
 
 L′ 1− L 1|=| C/ 2( t 1 R−t 2 R+L/C )− C/ 2( t 1 R−t 2 R+L/C+ε 1−ε2)|= C/ 2|ε1−ε2|≦ C/ 2 2Δ=Δ C   Eq(6)
 
In some examples, the error bound may not depend on the location of the source ECU  302  on the CAN-bus or the transmission time.
 
     If an authorized source ECU  302  sent the message, then no alert will be initiated. Alternatively, if the location of the source ECU  302  is distant by more than a predetermined amount from any of the authorized source ECUs, then the control unit can generate an alert. Similarly, if a source ECU  302  transmits a message while another ECU sends the payload of a legitimate message, then the control unit can generate an alert. Furthermore, since the alerts identify the location of the source ECU  302 , this provides valuable information to identify and mitigate the attack by patching or replacing the ECU that generated a malicious message. 
       FIG. 4  is a process flow diagram of an example method that can monitor a controller area network bus according to an embodiment described herein. The method  400  can be implemented with any suitable computing device, such as the electronic control module monitor  100  of  FIG. 1 . 
     At block  402 , the message detector  120  can detect a message from a source electronic control unit in a vehicle. In some examples, the message detector  120  can observe any number of messages transmitted via the CAN-bus and record the arrival time stamps for the payload of each message. The payload, as referred to herein, can include header information and data bits. In some examples, the payload may not exceed a predetermined number of bits. The header information can include a start of frame and end of frame indicator, a unique identifier that represents a priority level of a message, control information, such as a remote transmission request, an identifier extension bit (IDE), and data length code, a cyclic redundancy check and delimiter, and an acknowledgement slot and delimiter, among others. 
     At block  404 , the message detector  120  can calculate a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between a first monitor and the source electronic control unit. In some examples, the first message detector  120  can calculate the location of the source electronic control unit based on the distance from the first message detector  120  to the source electronic control unit and a distance from a second monitor unit to the source electronic control unit. In other embodiments, the first message detector  120  can calculate the location of the source ECU using two arrival times determined solely by the first message detector  120 . As discussed above in relation to  FIG. 3 , in some embodiments, the first message detector  120  can calculate the distance between a source ECU and the first message detector  120  based on arrival times that indicate a wave propagation speed and a propagation delay. 
     At block  406 , the security module  122  can detect that the message corresponds to a function controlled by a second electronic control unit. For example, the security module  122  can be configured with the distance of each electronic control unit on a CAN-bus from any suitable number of monitor units. The security module  122  can also include a list of message identifiers corresponding to each electronic control unit. For example, an engine control module may send notifications related to revolutions per minute, but not about the vehicle&#39;s speed. In some embodiments, the security module  122  can detect the function associated with a message by analyzing identifiers located in the header information of the message, such as a message identifier, and comparing the identifiers to the physical location of the ECU. 
     At block  408 , the security module  122  can generate a warning that the message from the source electronic control unit is malicious. For example, the security module  122  can generate a warning if the source ECU&#39;s location is more than a predetermined distance from any of the authorized sources that can generate the message. For example, an authorized source indicates that an electronic control unit manages the functions included in a message generated by the electronic control unit. The security module  122  generates a warning if the authorized source did not generate the message. Furthermore, if a source ECU transmits a message while another ECU sends the payload of a message from an authorized source, then the security module  122  can generate a warning. 
     In some embodiments, when the security module  122  detects that a message is spoofed or generated by an unauthorized ECU, the security module  122  can react in real-time to invalidate that message and cause all ECUs on the CAN-bus to discard the message. For example, the security module  122  may have permission to operate in a read-write mode on the CAN-bus. In order to invalidate a spoofed message, the security module  122  can leverage the recessive property of ‘1’-bits in the CAN-bus architecture. Specifically, when two ECUs transmit ‘0’ and ‘1’ bits simultaneously, all ECUs can read a ‘0’-bit from the CAN-bus. Furthermore, the CAN-bus protocol mandates that a valid message&#39;s CRC field ends with a ‘1’-bit. This allows the security module  122  to verify that the source of the message is authorized. If the source ECU was not authorized to transmit a message (i.e., the message is spoofed), the security module  122  can modify a cyclic redundancy check corresponding to the message, wherein the modified cyclic redundancy check invalidates the message. For example, the security module  122  can transmit a ‘0’-bit simultaneously with the spoofed-message&#39;s CRC-delimiter located at the end of the message. This ensures that the spoofed message&#39;s CRC ends with a ‘0’-bit rather than a ‘1’-bit, thus invalidating the message and causing all ECUs on the bus to discard or block the message. 
     The process flow diagram of  FIG. 4  is not intended to indicate that the operations of the method  400  are to be executed in any particular order, or that all of the operations of the method  400  are to be included in every case. Additionally, the method  400  can include any suitable number of additional operations. For example, the security module  122  may communicate with the CAN-bus using a read only protocol. Accordingly, the security module  122  can transmit the warning to an external computing device residing on any suitable secondary bus. 
     The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention. 
     The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire. 
     Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device. 
     Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the users computer, partly on the users computer, as a stand-alone software package, partly on the users computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention. 
     Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions. 
     These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks. 
     The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. 
     Referring now to  FIG. 5 , a block diagram is depicted of an example of a tangible, non-transitory computer-readable medium that can monitor a controller area network bus. The tangible, non-transitory, computer-readable medium  500  may be accessed by a processor  502  over a computer interconnect  504 . Furthermore, the tangible, non-transitory, computer-readable medium  500  may include code to direct the processor  502  to perform the operations of the current method. 
     The various software components discussed herein may be stored on the tangible, non-transitory, computer-readable medium  500 , as indicated in  FIG. 5 . For example, a message detector  506  can detect a message from any suitable source electronic control unit in a vehicle. For example, the message detector  506  can detect a message from an engine control module (ECM), an electronic brake control module (EBSM), a transmission control module (TSM), and a body control module (BCM), among others. The message detector  506  can also calculate a location of the source electronic control unit based on at least two arrival times, the arrival times indicating a distance between the electronic control module monitor and the source electronic control unit. 
     In some embodiments, a security module  508  can detect that the message corresponds to a function controlled by a second electronic control unit. In some examples, the security module  508  can detect that the source electronic control unit generates a message pertaining to a function that is performed by another electronic control unit. For example, the security module  508  can detect that an engine control module (ECM) generates a message pertaining to a braking function controlled by an electronic brake control module (EBSM), and the like. In some examples, the security module  508  can also generate a warning that the message from the source electronic control unit is malicious. 
     It is to be understood that any number of additional software components not shown in  FIG. 5  may be included within the tangible, non-transitory, computer-readable medium  500 , depending on the specific application.