EP3692698A1 - System and method for validation of authenticity of communication at in-vehicle networks - Google Patents

System and method for validation of authenticity of communication at in-vehicle networks

Info

Publication number
EP3692698A1
EP3692698A1 EP18793485.6A EP18793485A EP3692698A1 EP 3692698 A1 EP3692698 A1 EP 3692698A1 EP 18793485 A EP18793485 A EP 18793485A EP 3692698 A1 EP3692698 A1 EP 3692698A1
Authority
EP
European Patent Office
Prior art keywords
communication
security unit
data
unit
ecu
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP18793485.6A
Other languages
German (de)
French (fr)
Inventor
Yaron Galula
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Argus Cyber Security Ltd
Original Assignee
Argus Cyber Security Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Argus Cyber Security Ltd filed Critical Argus Cyber Security Ltd
Publication of EP3692698A1 publication Critical patent/EP3692698A1/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication

Definitions

  • the present invention relates to prevention of cyber- attacks. More particularly, the present invention relates to systems and methods for validation of authenticity of communication at in- vehicle networks.
  • In-vehicle networks allow internal communication between various components of a vehicle (e.g., air conditioning system, diagnostics, engine, etc.) by communicating with different electronic control units (ECUs).
  • An electronic control unit gets input from sensors (e.g., speed, temperature, pressure, etc.) to be used in its analysis and exchange data among themselves during the normal operation of the vehicle.
  • sensors e.g., speed, temperature, pressure, etc.
  • the in-vehicle network allows exchanging data quickly and reliably, with internal communication between the ECUs.
  • the ECUs which are directly connected to the outside world through external interfaces (such as telematics, multimedia, and driver assistance systems) may pose the highest risk.
  • OTA over-the-air
  • a central location sends an update to a subset of the users or nodes (e.g., ECUs).
  • a challenge in the firmware over the air (FOTA) process is the need of the ECU to receive the update and to validate its authenticity before applying an update. This is done in order to make sure the update is valid and for example was not compromised in transit (e.g., by an attack or otherwise) or is a malicious package delivered by a spoofed server.
  • the process of validating the authenticity in the target ECU typically requires high resource processing from the target ECU.
  • a system includes at least one security unit operatively connected to an in-vehicle data communication network; and at least first and second components connected to the in-vehicle network; wherein the security unit is adapted to authenticate communication of data between the first and second components.
  • the security unit may be integrated into one of the first and second components.
  • the security unit may be adapted to authenticate wireless communication between the first and second components.
  • the security unit may be adapted to, if a communication of data cannot be authenticated, perform at least one of: generate an alarm, block the communication, record information related to the communication, alert the component that sent data and, alert the node that is the destination of the sent data.
  • the security unit and the first component may be adapted to share a secret that is unknown to the second component; and use the secret to authenticate communication between the security unit and the first component.
  • the security unit may be adapted to record communications between the first and second nodes, analyze recorded communications and determine a communication was compromised.
  • the security unit may be adapted to check integrity of communicated data.
  • the security may examine communication of data from the first component to the second component, and authenticate the data communication.
  • a communication unit connected to the security unit may be adapted to enable components connected to the in-vehicle network to communicate with external components that are not physically connected to the in-vehicle network.
  • FIG. 1 shows a block diagram of a computing device, according to some embodiments of the invention
  • Fig. 2 A shows a block diagram of an authenticity validation system, according to some embodiments of the invention
  • FIG. 2B shows a block diagram of an authenticity validation system, according to some embodiments of the invention.
  • FIG. 3 shows a flowchart of a method of authenticity verification, according to some embodiments of the invention.
  • the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”.
  • the terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like.
  • the term set when used herein may include one or more items.
  • the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.
  • a computing device 100 may include a controller 105 that may be, for example, a central processing unit processor (CPU), a chip or any suitable computing or computational device, an operating system 115, a memory 120, executable code 125, a storage system 130 that may include input devices 135 and output devices 140.
  • Controller 105 (or one or more controllers or processors, possibly across multiple units or devices) may be configured to carry out methods described herein, and/or to execute or act as the various modules, units, etc. More than one computing device 100 may be included in, and one or more computing devices 100 may act as the components of, a system according to embodiments of the invention.
  • Operating system 115 may be or may include any code segment (e.g., one similar to executable code 125 described herein) designed and/or configured to perform tasks involving coordination, scheduling, arbitration, supervising, controlling or otherwise managing operation of computing device 100, for example, scheduling execution of software programs or tasks or enabling software programs or other modules or units to communicate.
  • Operating system 115 may be a commercial operating system. It will be noted that an operating system 115 may be an optional component, e.g., in some embodiments, a system may include a computing device that does not require or include an operating system 115.
  • a computer system may be, or may include, a microcontroller, an application specific circuit (ASIC), a field programmable array (FPGA) and/or system on a chip (SOC) that may be used without an operating system.
  • ASIC application specific circuit
  • FPGA field programmable array
  • SOC system on a chip
  • Memory 120 may be or may include, for example, a Random Access Memory (RAM), a read only memory (ROM), a Dynamic RAM (DRAM), a Synchronous DRAM (SD-RAM), a double data rate (DDR) memory chip, a Flash memory, a volatile memory, a non-volatile memory, a cache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units.
  • Memory 120 may be or may include a plurality of, possibly different memory units.
  • Memory 120 may be a computer or processor non- transitory readable medium, or a computer non-transitory storage medium, e.g., a RAM.
  • Executable code 125 may be any executable code, e.g., an application, a program, a process, task or script. Executable code 125 may be executed by controller 105 possibly under control of operating system 115. For example, executable code 125 may be an application that enforces security in a vehicle as further described herein, for example, cyber-attacks on in- vehicle networks. Although, for the sake of clarity, a single item of executable code 125 is shown in Fig. 1 , a system according to some embodiments of the invention may include a plurality of executable code segments similar to executable code 125 that may be loaded into memory 120 and cause controller 105 to carry out methods described herein.
  • Storage system 130 may be or may include, for example, a flash memory as known in the art, a memory that is internal to, or embedded in, a micro controller or chip as known in the art, a hard disk drive, a CD-Recordable (CD-R) drive, a Blu-ray disk (BD), a universal serial bus (USB) device or other suitable removable and/or fixed storage unit.
  • Content may be stored in storage system 130 and may be loaded from storage system 130 into memory 120 where it may be processed by controller 105.
  • some of the components shown in Fig. 1 may be omitted.
  • memory 120 may be a non- volatile memory having the storage capacity of storage system 130. Accordingly, although shown as a separate component, storage system 130 may be embedded or included in memory 120.
  • Input devices 135 may be or may include any suitable input devices, components or systems, e.g., a detachable keyboard or keypad, a mouse and the like.
  • Output devices 140 may include one or more (possibly detachable) displays or monitors, speakers and/or any other suitable output devices.
  • Any applicable input/output (I/O) devices may be connected to computing device 100 as shown by blocks 135 and 140.
  • NIC network interface card
  • USB universal serial bus
  • any suitable number of input devices 135 and output device 140 may be operatively connected to computing device 100 as shown by blocks 135 and 140.
  • input devices 135 and output devices 140 may be used by a technician or engineer in order to connect to a computing device 100, update software and the like.
  • Input and/or output devices or components 135 and 140 may be adapted to interface or communicate, with control or other units in a vehicle, e.g., input and/or output devices or components 135 and 140 may include ports that enable device 100 to communicate with an engine control unit, a suspension control unit, a traction control and the like.
  • Embodiments of the invention may include an article such as a computer or processor non-transitory readable medium, or a computer or processor non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory, encoding, including or storing instructions, e.g., computer-executable instructions, which, when executed by a processor or controller, carry out methods disclosed herein.
  • a storage medium such as memory 120
  • computer-executable instructions such as executable code 125
  • controller such as controller 105.
  • the storage medium may include, but is not limited to, any type of disk including magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs), such as a dynamic RAM (DRAM), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, including programmable storage devices.
  • ROMs read-only memories
  • RAMs random access memories
  • DRAM dynamic RAM
  • EPROMs erasable programmable read-only memories
  • flash memories electrically erasable programmable read-only memories (EEPROMs)
  • magnetic or optical cards or any type of media suitable for storing electronic instructions, including programmable storage devices.
  • Embodiments of the invention may include components such as, but not limited to, a plurality of central processing units (CPU) or any other suitable multi-purpose or specific processors or controllers (e.g., controllers similar to controller 105), a plurality of input units, a plurality of output units, a plurality of memory units, and a plurality of storage units.
  • a system may additionally include other suitable hardware components and/or software components.
  • a system may include or may be, for example, a personal computer, a desktop computer, a mobile computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a Personal Digital Assistant (PDA) device, a tablet computer, a network device, or any other suitable computing device.
  • PDA Personal Digital Assistant
  • a system may include or may be, for example, a plurality of components that include a respective plurality of central processing units, e.g., a plurality of CPUs as described, a plurality of CPUs embedded in an on board, or in-vehicle, system or network, a plurality of chips, FPGAs or SOCs, a plurality of computer or network devices, or any other suitable computing device.
  • a system as described herein may include one or more devices such as computing device 100.
  • FIG. 2A and additionally to Fig. 2B show block diagrams of an authenticity validation system, according to some embodiments of the invention.
  • a system may be embedded into an in-vehicle network 200 (or vehicle bus), for instance integrated into a vehicle electronic control unit (ECU) in order to detect and/or prevent attacks on the in-vehicle network 200.
  • In-vehicle network 200 may include a processor 201 (e.g., such as controller 105 shown in Fig. 1) in communication with other components of in-vehicle network 200 (where communication is indicated with arrows in Figs. 2A-2B).
  • processor 201 may be coupled to at least one ECU 202 and may analyze operations of ECUs coupled thereto. It should be noted that each of processor 201 and ECUs 202, 204 coupled thereto may be considered as a node of the in-vehicle network 200. In some embodiments, communication between nodes of in-vehicle network 200 may be carried out at least partially with wireless communication (e.g., via Bluetooth).
  • wireless communication e.g., via Bluetooth
  • in-vehicle network 200 may further include a communication module 203 configured to allow wireless communication within in-vehicle network 200 and/or communication with external devices, for example to allow a navigation system to communicate with satellites and/or to allow receiving messages (e.g., a time stamp) from external sources.
  • in-vehicle network 200 may further include a battery 205 (e.g., the battery of the vehicle) to power components of the in-vehicle network 200.
  • communication between nodes of in-vehicle network 200 may be continuous or periodic (e.g., sending single files and/or images).
  • At least one node of in-vehicle network 200 may analyze and/or process communication within in-vehicle network 200.
  • at least one computing device such as device 100, as shown in Fig. 1 may be embedded into in- vehicle network 200 and process data from the network to analyze communication within the in- vehicle network 200.
  • at least one computing device such as device 100, as shown in Fig. 1 may be embedded into at least one node of in-vehicle network 200 and process data from that node and/or from the network to analyze communication within the in- vehicle network 200.
  • the authenticity validation system may include at least one security unit 206 coupled to communication module 203 and configured to analyze and determine authenticity validation of communication within in-vehicle network 200.
  • a trusted security unit 206 may analyze communication from a first ECU 202 to a second ECU 204 (e.g., communicating via communication module 203) to determine if the communication from first ECU 202 is authenticated.
  • Security unit 206 may be, or may include components of computing device 100.
  • security unit 206 may be a security unit that includes a controller 105, a memory 120 and executable code 125.
  • Security unit 206 may be connected to a communication bus or to an in-vehicle network such that it can examine all communication between a first entity (e.g., ECU 202) and a second entity (e.g., ECU 204).
  • security entity 206 may be, or may be connected as a gateway between a first network segment to which ECU 202 is connected and a second network segment to which ECU 204 is connected, accordingly, all data communicated between ECU 202 and ECU 204 may pass through security unit 206 thus enabling security unit 206 to examine any or all data exchanged between ECU 202 and ECU 204.
  • Security unit 206 may examine at least one message sent from a first unit (e.g., from ECU 202) to a second unit (e.g., to ECU 204) over an in- vehicle network and determine whether or not the first unit is allowed to send the at least one message to the second unit. If security unit 206 determines that the first unit is not allowed to send the at least one message to the second unit then security unit 206 may prevent the second unit from receiving, or processing, the at least one message. For example, security unit 206 may include (e.g., in storage system 130) a list of ECUs, or an identifier of a specific ECU that are/is allowed to update firmware in or of ECU 202.
  • Security unit 206 may further monitor and/or examine all data communications destined to ECU 202 and, if a data communication or message related to a firmware update and destined to ECU 202 is identified (e.g., based on a protocol used for updating firmware) then security unit 206 may check whether or not the source of the message or communication is included in the list of nodes, ECUs or components which are allowed to update firmware in ECU 202. If the source of the message is not in the list, security unit 206 may block the message, e.g., as described herein. To block a message, security unit 206 may cause the receiving unit (e.g. ECU 202) to ignore the message or to avoid processing the message, e.g., by sending a command to the receiving ECU.
  • the receiving unit e.g. ECU 202
  • security unit 206 may guarantee that only specific, designated, predefined nodes or ECUs can update ECU 202. For example, assuming that a list of nodes permitted to update ECU 202 only includes ECU 204 then if a hacker gains control of an ECU other than ECU 204, the hacker will not be able to update firmware of ECU 202.
  • security unit 206 may intercept messages sent to ECU 202, determine the messages are related to an update of software in, or a configuration change of, ECU 202, determine whether or not the update or configuration are to be allowed or permitted, and, if security unit 206 determines that an update or configuration is not allowed or permitted then security unit 206 may block or prevent the update or configuration. Blocking a message or a communication of data may be done or accomplished, by security unit 206, using any method.
  • security unit 206 may send an abort or stop command to ECU 202 and/or ECU 204 causing ECU 202 and/or ECU 204 to terminate a communication session or to otherwise stop communicating over a network.
  • security unit 206 may block, prevent or drop packets or messages thus effectively blocking a communication.
  • security unit 206 may apply an electrical signal to a communication bus thus causing a communication error which in turn disrupts communication, e.g., by rendering data on the bus useless. It will be understood that any method may be used, by security unit 206, for blocking messages or data communication and accordingly, the scope of the invention is not limited by the blocking method used.
  • the at least one security unit 206 may include a communication validation algorithm to validate executed communication in the system.
  • Fig. 2A illustrates an embodiment with a system 210 where the communication module 203 is external and the security unit 206 is internal to in- vehicle network 200.
  • Fig. 2B illustrates an embodiment with a system 220 where the communication module 203 and the security unit 206 are internal to the in-vehicle network 200.
  • the communication module 203 may be directly coupled to processor 201 and/or directly coupled to at least one ECU 202, 204.
  • communication module 203 enables components directly connected to an in-vehicle network to communicate with a system or device that is external to, or outside of the vehicle.
  • An external system or device as referred to herein may be any system or device that is not directly or physically connected to an in-vehicle network in a vehicle.
  • communication module 203 is directly or physically connected to an in- vehicle network via a first port and includes at least one more, or second, interface, port or unit, that enables communication module 203 to communicate with external devices that may be otherwise unable to communicate with components connected to an in-vehicle network.
  • communication module 203 enables ECU 1 202 to communicate with a diagnostics system in a service location, a server on the internet and/or with a system at an Original Equipment Manufacturer (OEM) premises.
  • OEM Original Equipment Manufacturer
  • communication between nodes of the in-vehicle network 200 may not include checking signatures while updates are sent to the respective node in the network (e.g., ECU 202).
  • security unit 206 may check signatures for communication from at least one node of the in-vehicle network 200 and/or may detect updating attempts to the respective node in the network (e.g., ECU 202).
  • security unit 206 may block the communication from proceeding (e.g., by sending an abort command to the sending and/or receiving node).
  • communication authenticity validation algorithm may be executed with processor 201 and/or security unit 206 to determine communication received from a node of in-vehicle network 200 as authentic (e.g., validates that a cryptographic signature corresponds to the data content in the transmission over the in-vehicle network 200).
  • security unit 206 may determine that communication received from a node of in-vehicle network 200 is not valid (invalid) and, for instance, issue an alert to the intended recipient of the communication that the communication failed authentication or was otherwise compromised.
  • security unit 206 may monitor all communication within in-vehicle network 200 to detect spoofing of messages to a first node (e.g., ECU 202) as originating from a second node (e.g., ECU 204). In some embodiments, security unit 206 may issue an alert to the node from which the communication was received that the communication failed authentication or otherwise compromised.
  • a first node e.g., ECU 202
  • a second node e.g., ECU 204
  • security unit 206 may issue an alert to the node from which the communication was received that the communication failed authentication or otherwise compromised.
  • communication between at least one pair of nodes within in-vehicle network 200 may have dedicated attributes (e.g., media access control (MAC)).
  • MAC media access control
  • a communication protocol between at least two nodes of in-vehicle network 200 may include authentication data to be verified by security unit 206 during authenticity validation.
  • a communication protocol between at least one node of in-vehicle network 200 (e.g., ECU 202) and security unit 206 may include dedicated authentication data (secret) to be verified during authenticity validation, wherein such secret or protocol may not be shared with the at least one intended recipient of the communication.
  • security unit 206 may authenticate ECU 202 and provide ECU 202 with a key for signing messages sent from ECU 202 to ECU 204, future messages sent from ECU 202 to ECU 204 may be examined by security unit 206 to verify that they are signed using the key provided. Accordingly, security unit 206 can verify and/or authenticate messages destined to ECU 204 thus relieving ECU 204 from having to verify or authenticate messages it receives. Accordingly, embodiments of the invention provide secured communication between nodes in a network without burdening the nodes.
  • security unit 206 shares a secret with a first node (e.g., with ECU 202) where the secret is unknown to other nodes or components, e.g., a secret encryption key is shared with ECU 202 but is not disclosed or reviled to ECU 204.
  • security node 206 may establish separate, different, secured communication channels with nodes in a network.
  • a secured channel with a node can be used for communicating sensitive data with the node.
  • security unit 206 may use a secured channel to provide ECU 202 with a key for signing messages, using a secured channel ensures that no other node in a network can obtain the key.
  • security unit 206 can authenticate or verify a source of a message, e.g., based on a signature that corresponds to a key provided to a node as described.
  • security unit 206 can verify that a message sent to ECU 204 was sent by ECU 202 and not by any other ECU or node in a network.
  • embodiments of the invention enable enforcing security measures related to content, source and destination.
  • security unit 206 can ensure that a firmware update of ECU 204 is only performed by ECU 202 by verifying that messages containing, or related to, a firmware update are signed by a securely key provided to ECU 202 as described.
  • Dedicated authentication data may be any piece of digital data that is used to authenticate, validate or verify the true origin, or sender identity, of messages or other digital data sent over an in- vehicle network or communication bus.
  • dedicated authentication data can be a digital signature used for signing data, by attaching or including a signature, such that, using the signature, a receiver of the messages or data can validate, authenticate or verify the identity of the sender or origin of the messages or data.
  • the communication protocol may be based on cryptography. In some embodiments, the communication protocol may be based on communication of physical characteristics and/or fingerprinting. Detection of spoofing may be done according to a specific or selected protocol which can be based on crypto or physical characteristics of a communication as further described herein.
  • Physical characteristics may be any elements related to the physical aspect of a component or signal.
  • physical characteristics can be characteristics of the electrical signal, identifying the physical element which transmitted the signal, for instance, the time it takes for an electrical voltage to rise, amount of memory used, power consumption and the like.
  • Physical characteristics may be, or may include data that identifies or characterizes a physical component, e.g., a memory size, a serial number and the like.
  • Physical characteristics may be, or may include data that identifies or characterizes operational aspects of a component, e.g., a CPU clock speed, power consumption, voltage at a specific point or circuit, amount of data sent/received over a network and the like.
  • all communication may be stored (e.g., on a memory unit, in storage system 130 or on a server) and security unit 206 or a server may analyze the communication history and determine that communication previously received by at least one node of in-vehicle network 200 may be compromised.
  • security unit 206 and/or at least one node (e.g., ECU) as recipient of communication may perform additional communication integrity checks to detect transmission errors.
  • security unit 206 may be embedded into firmware of in-vehicle network 200 and or embedded into an intrusion detection system (IDS).
  • IDS intrusion detection system
  • security unit 206 may be embedded into processor 201.
  • Fig. 3 show a flowchart of a method of authenticity verification, according to some embodiments of the invention.
  • the method of detecting attacks on in vehicle networks may be performed by computing device 100 (as shown in Fig. 1) or by any other computation device embedded at in-vehicle network 200 (as shown in Figs. 2A-2B).
  • processor 201 may monitor 301 communications at the in-vehicle network 200 until at least one communication attempt is detected 302.
  • processor 201 and/or security unit 206 may check 303 signatures of the detected communication attempt and/or check 304 external update attempts. In case that the signatures are authenticated and no other source of data is detected, processor 201 and/or security unit 206 may validate 305 the communication authenticity. In case that the signatures are not authenticated and/or another source of data is detected (e.g., a malicious source (node) is injecting messages into the data stream), processor 201 and/or security unit 206 may block 306 the communication.
  • a malicious source node
  • a system and method as described herein may provide or enforce security to an in-vehicle network, components or system by controlling update or configuration of components on the in- vehicle network.
  • security unit 206 monitors network traffic destined to ECU 204, determines whether or not the traffic is related to an update or configuration of ECU 204 and, if the traffic is indeed related to an update or configuration of ECU 204, security unit 206 authenticates or verifies the traffic.
  • security unit 206 may allow ECU 202 to configure or update of ECU 204 and may further prevent any other component from configuring or updating firmware in ECU 204.
  • security unit 206 may examine all network traffic directed to ECU 204, e.g., capture and analyze messages or packets sent to ECU 202 over an in-vehicle network, determine whether or not the traffic is related to an update or configuration of ECU 204, and, if messages related to an update or configuration of ECU 204 are not originated or sent from ECU 202 are detected then security unit 206 may block the messages. Accordingly, embodiments of the invention may guarantee that a component (e.g., ECU 204) can only be updated or configured by a specific or designated component or unit, for example, security unit 206 guarantees ECU 204 is updated or configured by ECU 202 and further guarantees that no other component in system 220 can update or configure ECU 204.
  • a component e.g., ECU 204
  • An update or configuration as referred to herein may include a firmware update or a modification of a configuration.
  • a configuration may include modifying operational parameters, for example, ECU 202 may configure ECU 204 by changing configuration parameters or values in, or used by, ECU 204, e.g., parameters or values that determine ports used by ECU 204, messages or responses sent by ECU 204 and the like.
  • security unit 206 may provide ECU 202 with a key or other data useable for signing messages sent to ECU 204.
  • Security unit 206 may further provide ECU 204 with a key or other data usable for verifying a signature.
  • ECU 202 may use a key for signing messages sent to ECU 204, e.g., a key provided by security unit 206 may be used, by ECU 202 and ECU 204 to generate a signature and/or validate a signature as known in the art.
  • messages that include a firmware or other update of ECU 204, sent by ECU 202 may be signed, by ECU 202, using a key provided by security unit 206, and the messages may be verified, by ECU 204, using a key provided by security unit 206.
  • messages sent by ECU 202 to ECU 204 may be routed via security unit 206 and security unit 206 may verify the messages, e.g., using a key as described.
  • Security unit 206 may periodically generate and update encryption/decryption keys, e.g., security unit 206 may periodically generate new keys and, using a list of ECUs in a system (e.g., stored in storage system 130), security unit 206 may automatically distribute the keys, accordingly, signing messages as described herein may be done by ECUs using keys which are automatically and periodically generated and distributed.
  • encryption/decryption keys e.g., security unit 206 may periodically generate new keys and, using a list of ECUs in a system (e.g., stored in storage system 130), security unit 206 may automatically distribute the keys, accordingly, signing messages as described herein may be done by ECUs using keys which are automatically and periodically generated and distributed.
  • Authenticating messages as described herein may include verifying a signature. For example, since security unit 206 generates and distributes keys used for signing messages as described, security unit 206 may readily authenticate messages by verifying or ascertaining that the messages are correctly signed by the correct keys.
  • embodiments of the invention enable a system wherein a first component (e.g., ECU 204) can only be updated or configured by a specific, designated, second component in a system (e.g., ECU 202) and further authenticate data communications based on a source and destination of the communication and based on a signature.
  • a first component e.g., ECU 204
  • a specific, designated, second component in a system e.g., ECU 202
  • Embodiments of the invention may further relieve a component from the burden of verifying or validating the authenticity of an entity that updates it.
  • security unit 206 may verify and/or validate that a firmware update of ECU 204 is indeed made by ECU 202 and security unit 206 may further prevent any other ECU or component in a system from updating ECU 204, thus ECU 204 needs not verify or authenticate the source and/or content of an update. It is noted that security unit 206 can perform authentication and protections as described for a large number of ECUs in a system, accordingly, a single unit (e.g., security unit 206) can provide security as described to a large number of units in a system.
  • embodiments of the invention may be readily appreciated by a person skilled in the art.
  • known systems and methods either do not verify or authenticate data transmissions of, or related to, sensitive data or operations such as firmware updates and configuration of components, or they leave it for the receiving component to verify, validate or authenticate a sensitive transmission or operation, accordingly, embodiments of the invention improve the field of security, and specifically, security in in-vehicle systems, by protecting components from being maliciously updated, configured, or reconfigured and by further providing the protection in a way that does not burden the components being updated or configured.
  • Embodiments of the invention further improve the field of security, and specifically, security in in-vehicle systems, by associating data and/or operations with a signature thus providing an additional security measure and preventing maliciously updating or configuring components in a system.
  • embodiments of the invention enable and provide scalable system that is easily and simply managed, e.g., when a new component is added, all that needs to be done in order to protect the new component is update security unit 206 such that it protects the new component as described herein.
  • keys can be stored in, or downloaded to, a single, central unit (e.g., security unit 206) and the central unit can automatically distribute and/or update keys throughout a system.
  • a single, central unit e.g., security unit 206

Abstract

A system and method for securing data communication in an in-vehicle network may include a security unit adapted to authenticate communication of data between first and second components connected to the network. A security unit may authenticate a communication related to an update of firmware. If a communication of data cannot be authenticated, the security unit may block the communication.

Description

SYSTEM AND METHOD FOR VALIDATION OF AUTHENTICITY OF
COMMUNICATION AT IN- VEHICLE NETWORKS
FIELD OF THE INVENTION
[001] The present invention relates to prevention of cyber- attacks. More particularly, the present invention relates to systems and methods for validation of authenticity of communication at in- vehicle networks.
BACKGROUND OF THE INVENTION
[002] As vehicles become more connected to wireless networks, the risk for cyber-attacks increases. Cyber security is especially important when considering autonomous vehicles. As such, an autonomous vehicle fleet should be monitored for cyber security related events in order to both detect and respond to threats.
[003] In-vehicle networks allow internal communication between various components of a vehicle (e.g., air conditioning system, diagnostics, engine, etc.) by communicating with different electronic control units (ECUs). An electronic control unit gets input from sensors (e.g., speed, temperature, pressure, etc.) to be used in its analysis and exchange data among themselves during the normal operation of the vehicle. For example, the engine needs to tell the transmission what the engine speed is, and the transmission needs to tell other modules when a gear shift occurs. The in-vehicle network allows exchanging data quickly and reliably, with internal communication between the ECUs. The ECUs which are directly connected to the outside world through external interfaces (such as telematics, multimedia, and driver assistance systems) may pose the highest risk.
[004] Software and/or firmware may be downloaded using over-the-air (OTA) programming, where new software, configuration settings, and updating encryption keys may be distributed to the ECUs. Usually, a central location sends an update to a subset of the users or nodes (e.g., ECUs). A challenge in the firmware over the air (FOTA) process is the need of the ECU to receive the update and to validate its authenticity before applying an update. This is done in order to make sure the update is valid and for example was not compromised in transit (e.g., by an attack or otherwise) or is a malicious package delivered by a spoofed server. The process of validating the authenticity in the target ECU typically requires high resource processing from the target ECU. SUMMARY OF THE INVENTION
[005] In some embodiments, a system includes at least one security unit operatively connected to an in-vehicle data communication network; and at least first and second components connected to the in-vehicle network; wherein the security unit is adapted to authenticate communication of data between the first and second components.
[006] The security unit may be integrated into one of the first and second components. The security unit may be adapted to authenticate wireless communication between the first and second components.
[007] The security unit may be adapted to, if a communication of data cannot be authenticated, perform at least one of: generate an alarm, block the communication, record information related to the communication, alert the component that sent data and, alert the node that is the destination of the sent data.
[008] The security unit and the first component may be adapted to share a secret that is unknown to the second component; and use the secret to authenticate communication between the security unit and the first component.
[009] The security unit may be adapted to record communications between the first and second nodes, analyze recorded communications and determine a communication was compromised. The security unit may be adapted to check integrity of communicated data.
[010] The security may examine communication of data from the first component to the second component, and authenticate the data communication. A communication unit connected to the security unit may be adapted to enable components connected to the in-vehicle network to communicate with external components that are not physically connected to the in-vehicle network. Other aspects and/or advantages of the present invention are described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[011] The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:
[012] Fig. 1 shows a block diagram of a computing device, according to some embodiments of the invention; [013] Fig. 2 A shows a block diagram of an authenticity validation system, according to some embodiments of the invention;
[014] Fig. 2B shows a block diagram of an authenticity validation system, according to some embodiments of the invention; and
[015] Fig. 3 shows a flowchart of a method of authenticity verification, according to some embodiments of the invention.
[016] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.
DETAILED DESCRIPTION
[017] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.
[018] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, "processing," "computing," "calculating," "determining," "establishing", "analyzing", "checking", or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes. Although embodiments of the invention are not limited in this regard, the terms "plurality" and "a plurality" as used herein may include, for example, "multiple" or "two or more". The terms "plurality" or "a plurality" may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term set when used herein may include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.
[019] Reference is made to Fig. 1 , which shows a block diagram of a computing device 100, according to some embodiments of the invention. A computing device 100 may include a controller 105 that may be, for example, a central processing unit processor (CPU), a chip or any suitable computing or computational device, an operating system 115, a memory 120, executable code 125, a storage system 130 that may include input devices 135 and output devices 140. Controller 105 (or one or more controllers or processors, possibly across multiple units or devices) may be configured to carry out methods described herein, and/or to execute or act as the various modules, units, etc. More than one computing device 100 may be included in, and one or more computing devices 100 may act as the components of, a system according to embodiments of the invention.
[020] Operating system 115 may be or may include any code segment (e.g., one similar to executable code 125 described herein) designed and/or configured to perform tasks involving coordination, scheduling, arbitration, supervising, controlling or otherwise managing operation of computing device 100, for example, scheduling execution of software programs or tasks or enabling software programs or other modules or units to communicate. Operating system 115 may be a commercial operating system. It will be noted that an operating system 115 may be an optional component, e.g., in some embodiments, a system may include a computing device that does not require or include an operating system 115. For example, a computer system may be, or may include, a microcontroller, an application specific circuit (ASIC), a field programmable array (FPGA) and/or system on a chip (SOC) that may be used without an operating system.
[021] Memory 120 may be or may include, for example, a Random Access Memory (RAM), a read only memory (ROM), a Dynamic RAM (DRAM), a Synchronous DRAM (SD-RAM), a double data rate (DDR) memory chip, a Flash memory, a volatile memory, a non-volatile memory, a cache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units. Memory 120 may be or may include a plurality of, possibly different memory units. Memory 120 may be a computer or processor non- transitory readable medium, or a computer non-transitory storage medium, e.g., a RAM.
[022] Executable code 125 may be any executable code, e.g., an application, a program, a process, task or script. Executable code 125 may be executed by controller 105 possibly under control of operating system 115. For example, executable code 125 may be an application that enforces security in a vehicle as further described herein, for example, cyber-attacks on in- vehicle networks. Although, for the sake of clarity, a single item of executable code 125 is shown in Fig. 1 , a system according to some embodiments of the invention may include a plurality of executable code segments similar to executable code 125 that may be loaded into memory 120 and cause controller 105 to carry out methods described herein.
[023] Storage system 130 may be or may include, for example, a flash memory as known in the art, a memory that is internal to, or embedded in, a micro controller or chip as known in the art, a hard disk drive, a CD-Recordable (CD-R) drive, a Blu-ray disk (BD), a universal serial bus (USB) device or other suitable removable and/or fixed storage unit. Content may be stored in storage system 130 and may be loaded from storage system 130 into memory 120 where it may be processed by controller 105. In some embodiments, some of the components shown in Fig. 1 may be omitted. For example, memory 120 may be a non- volatile memory having the storage capacity of storage system 130. Accordingly, although shown as a separate component, storage system 130 may be embedded or included in memory 120.
[024] Input devices 135 may be or may include any suitable input devices, components or systems, e.g., a detachable keyboard or keypad, a mouse and the like. Output devices 140 may include one or more (possibly detachable) displays or monitors, speakers and/or any other suitable output devices. Any applicable input/output (I/O) devices may be connected to computing device 100 as shown by blocks 135 and 140. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device or external hard drive may be included in input devices 135 and/or output devices 140. It will be recognized that any suitable number of input devices 135 and output device 140 may be operatively connected to computing device 100 as shown by blocks 135 and 140. For example, input devices 135 and output devices 140 may be used by a technician or engineer in order to connect to a computing device 100, update software and the like. Input and/or output devices or components 135 and 140 may be adapted to interface or communicate, with control or other units in a vehicle, e.g., input and/or output devices or components 135 and 140 may include ports that enable device 100 to communicate with an engine control unit, a suspension control unit, a traction control and the like.
[025] Embodiments of the invention may include an article such as a computer or processor non-transitory readable medium, or a computer or processor non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory, encoding, including or storing instructions, e.g., computer-executable instructions, which, when executed by a processor or controller, carry out methods disclosed herein. For example, a storage medium such as memory 120, computer-executable instructions such as executable code 125 and a controller such as controller 105.
[026] The storage medium may include, but is not limited to, any type of disk including magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs), such as a dynamic RAM (DRAM), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, including programmable storage devices.
[027] Embodiments of the invention may include components such as, but not limited to, a plurality of central processing units (CPU) or any other suitable multi-purpose or specific processors or controllers (e.g., controllers similar to controller 105), a plurality of input units, a plurality of output units, a plurality of memory units, and a plurality of storage units. A system may additionally include other suitable hardware components and/or software components. In some embodiments, a system may include or may be, for example, a personal computer, a desktop computer, a mobile computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a Personal Digital Assistant (PDA) device, a tablet computer, a network device, or any other suitable computing device.
[028] In some embodiments, a system may include or may be, for example, a plurality of components that include a respective plurality of central processing units, e.g., a plurality of CPUs as described, a plurality of CPUs embedded in an on board, or in-vehicle, system or network, a plurality of chips, FPGAs or SOCs, a plurality of computer or network devices, or any other suitable computing device. For example, a system as described herein may include one or more devices such as computing device 100.
[029] Reference is made to Fig. 2A and additionally to Fig. 2B which show block diagrams of an authenticity validation system, according to some embodiments of the invention. In some embodiments, such a system may be embedded into an in-vehicle network 200 (or vehicle bus), for instance integrated into a vehicle electronic control unit (ECU) in order to detect and/or prevent attacks on the in-vehicle network 200. In-vehicle network 200 may include a processor 201 (e.g., such as controller 105 shown in Fig. 1) in communication with other components of in-vehicle network 200 (where communication is indicated with arrows in Figs. 2A-2B). [030] In some embodiments, processor 201 may be coupled to at least one ECU 202 and may analyze operations of ECUs coupled thereto. It should be noted that each of processor 201 and ECUs 202, 204 coupled thereto may be considered as a node of the in-vehicle network 200. In some embodiments, communication between nodes of in-vehicle network 200 may be carried out at least partially with wireless communication (e.g., via Bluetooth).
[031] In some embodiments, in-vehicle network 200 may further include a communication module 203 configured to allow wireless communication within in-vehicle network 200 and/or communication with external devices, for example to allow a navigation system to communicate with satellites and/or to allow receiving messages (e.g., a time stamp) from external sources. In some embodiments, in-vehicle network 200 may further include a battery 205 (e.g., the battery of the vehicle) to power components of the in-vehicle network 200. In some embodiments, communication between nodes of in-vehicle network 200 may be continuous or periodic (e.g., sending single files and/or images).
[032] According to some embodiments, at least one node of in-vehicle network 200 may analyze and/or process communication within in-vehicle network 200. In some embodiments, at least one computing device (such as device 100, as shown in Fig. 1) may be embedded into in- vehicle network 200 and process data from the network to analyze communication within the in- vehicle network 200. In some embodiments, at least one computing device (such as device 100, as shown in Fig. 1) may be embedded into at least one node of in-vehicle network 200 and process data from that node and/or from the network to analyze communication within the in- vehicle network 200.
[033] According to some embodiments, the authenticity validation system may include at least one security unit 206 coupled to communication module 203 and configured to analyze and determine authenticity validation of communication within in-vehicle network 200. For example, a trusted security unit 206 may analyze communication from a first ECU 202 to a second ECU 204 (e.g., communicating via communication module 203) to determine if the communication from first ECU 202 is authenticated.
[034] Security unit 206 may be, or may include components of computing device 100. For example, security unit 206 may be a security unit that includes a controller 105, a memory 120 and executable code 125. Security unit 206 may be connected to a communication bus or to an in-vehicle network such that it can examine all communication between a first entity (e.g., ECU 202) and a second entity (e.g., ECU 204). For example, security entity 206 may be, or may be connected as a gateway between a first network segment to which ECU 202 is connected and a second network segment to which ECU 204 is connected, accordingly, all data communicated between ECU 202 and ECU 204 may pass through security unit 206 thus enabling security unit 206 to examine any or all data exchanged between ECU 202 and ECU 204.
[035] Security unit 206 may examine at least one message sent from a first unit (e.g., from ECU 202) to a second unit (e.g., to ECU 204) over an in- vehicle network and determine whether or not the first unit is allowed to send the at least one message to the second unit. If security unit 206 determines that the first unit is not allowed to send the at least one message to the second unit then security unit 206 may prevent the second unit from receiving, or processing, the at least one message. For example, security unit 206 may include (e.g., in storage system 130) a list of ECUs, or an identifier of a specific ECU that are/is allowed to update firmware in or of ECU 202. Security unit 206 may further monitor and/or examine all data communications destined to ECU 202 and, if a data communication or message related to a firmware update and destined to ECU 202 is identified (e.g., based on a protocol used for updating firmware) then security unit 206 may check whether or not the source of the message or communication is included in the list of nodes, ECUs or components which are allowed to update firmware in ECU 202. If the source of the message is not in the list, security unit 206 may block the message, e.g., as described herein. To block a message, security unit 206 may cause the receiving unit (e.g. ECU 202) to ignore the message or to avoid processing the message, e.g., by sending a command to the receiving ECU. Accordingly, security unit 206 may guarantee that only specific, designated, predefined nodes or ECUs can update ECU 202. For example, assuming that a list of nodes permitted to update ECU 202 only includes ECU 204 then if a hacker gains control of an ECU other than ECU 204, the hacker will not be able to update firmware of ECU 202.
[036] For example, security unit 206 may intercept messages sent to ECU 202, determine the messages are related to an update of software in, or a configuration change of, ECU 202, determine whether or not the update or configuration are to be allowed or permitted, and, if security unit 206 determines that an update or configuration is not allowed or permitted then security unit 206 may block or prevent the update or configuration. Blocking a message or a communication of data may be done or accomplished, by security unit 206, using any method. For example, to block a message, or communication of data, from ECU 202 to ECU 204, security unit 206 may send an abort or stop command to ECU 202 and/or ECU 204 causing ECU 202 and/or ECU 204 to terminate a communication session or to otherwise stop communicating over a network. In the case where a data flow between ECU 202 and ECU 204 is via security unit 206 (e.g., in a configuration where security unit 206 acts as a gateway), security unit 206 may block, prevent or drop packets or messages thus effectively blocking a communication. In yet other cases security unit 206 may apply an electrical signal to a communication bus thus causing a communication error which in turn disrupts communication, e.g., by rendering data on the bus useless. It will be understood that any method may be used, by security unit 206, for blocking messages or data communication and accordingly, the scope of the invention is not limited by the blocking method used.
[037] According to some embodiments, the at least one security unit 206 may include a communication validation algorithm to validate executed communication in the system.
[038] Fig. 2A illustrates an embodiment with a system 210 where the communication module 203 is external and the security unit 206 is internal to in- vehicle network 200. Fig. 2B illustrates an embodiment with a system 220 where the communication module 203 and the security unit 206 are internal to the in-vehicle network 200. In some embodiments, the communication module 203 may be directly coupled to processor 201 and/or directly coupled to at least one ECU 202, 204.
[039] In some embodiments, communication module 203 enables components directly connected to an in-vehicle network to communicate with a system or device that is external to, or outside of the vehicle. An external system or device as referred to herein may be any system or device that is not directly or physically connected to an in-vehicle network in a vehicle. In some embodiments, communication module 203 is directly or physically connected to an in- vehicle network via a first port and includes at least one more, or second, interface, port or unit, that enables communication module 203 to communicate with external devices that may be otherwise unable to communicate with components connected to an in-vehicle network. For example, communication module 203 enables ECU 1 202 to communicate with a diagnostics system in a service location, a server on the internet and/or with a system at an Original Equipment Manufacturer (OEM) premises.
[040] It should be noted that without the security unit 206, communication between nodes of the in-vehicle network 200 may not include checking signatures while updates are sent to the respective node in the network (e.g., ECU 202). In some embodiments, security unit 206 may check signatures for communication from at least one node of the in-vehicle network 200 and/or may detect updating attempts to the respective node in the network (e.g., ECU 202). In some embodiments, security unit 206 may block the communication from proceeding (e.g., by sending an abort command to the sending and/or receiving node).
[041] In some embodiments, communication authenticity validation algorithm may be executed with processor 201 and/or security unit 206 to determine communication received from a node of in-vehicle network 200 as authentic (e.g., validates that a cryptographic signature corresponds to the data content in the transmission over the in-vehicle network 200). In some embodiments, security unit 206 may determine that communication received from a node of in-vehicle network 200 is not valid (invalid) and, for instance, issue an alert to the intended recipient of the communication that the communication failed authentication or was otherwise compromised.
[042] It should be noted that by checking all communication at security unit 206, harmful data packets may be blocked from reaching the recipient and stopped at the security unit 206, thereby preventing attacks in the in-vehicle network 200. In some embodiments, security unit 206 may monitor all communication within in-vehicle network 200 to detect spoofing of messages to a first node (e.g., ECU 202) as originating from a second node (e.g., ECU 204). In some embodiments, security unit 206 may issue an alert to the node from which the communication was received that the communication failed authentication or otherwise compromised.
[043] It should be noted that since the validation is carried out at security unit 206, there is no longer a need for the recipient node (e.g., ECU 204) to validate the incoming communication and thereby reducing required processing power and/or resources for each node in in-vehicle network 200. In some embodiments, communication between at least one pair of nodes within in-vehicle network 200 may have dedicated attributes (e.g., media access control (MAC)).
[044] According to some embodiments, a communication protocol between at least two nodes of in-vehicle network 200 (e.g., ECUs) may include authentication data to be verified by security unit 206 during authenticity validation. In some embodiments, a communication protocol between at least one node of in-vehicle network 200 (e.g., ECU 202) and security unit 206 may include dedicated authentication data (secret) to be verified during authenticity validation, wherein such secret or protocol may not be shared with the at least one intended recipient of the communication. For example, security unit 206 may authenticate ECU 202 and provide ECU 202 with a key for signing messages sent from ECU 202 to ECU 204, future messages sent from ECU 202 to ECU 204 may be examined by security unit 206 to verify that they are signed using the key provided. Accordingly, security unit 206 can verify and/or authenticate messages destined to ECU 204 thus relieving ECU 204 from having to verify or authenticate messages it receives. Accordingly, embodiments of the invention provide secured communication between nodes in a network without burdening the nodes.
[045] In some embodiments, security unit 206 shares a secret with a first node (e.g., with ECU 202) where the secret is unknown to other nodes or components, e.g., a secret encryption key is shared with ECU 202 but is not disclosed or reviled to ECU 204. Using keys or other methods or means, security node 206 may establish separate, different, secured communication channels with nodes in a network.
[046] A secured channel with a node can be used for communicating sensitive data with the node. For example, security unit 206 may use a secured channel to provide ECU 202 with a key for signing messages, using a secured channel ensures that no other node in a network can obtain the key. Accordingly, security unit 206 can authenticate or verify a source of a message, e.g., based on a signature that corresponds to a key provided to a node as described. For example, security unit 206 can verify that a message sent to ECU 204 was sent by ECU 202 and not by any other ECU or node in a network. Accordingly, embodiments of the invention enable enforcing security measures related to content, source and destination. For example, security unit 206 can ensure that a firmware update of ECU 204 is only performed by ECU 202 by verifying that messages containing, or related to, a firmware update are signed by a securely key provided to ECU 202 as described.
[047] Dedicated authentication data may be any piece of digital data that is used to authenticate, validate or verify the true origin, or sender identity, of messages or other digital data sent over an in- vehicle network or communication bus. For example, dedicated authentication data can be a digital signature used for signing data, by attaching or including a signature, such that, using the signature, a receiver of the messages or data can validate, authenticate or verify the identity of the sender or origin of the messages or data.
[048] In some embodiments, the communication protocol may be based on cryptography. In some embodiments, the communication protocol may be based on communication of physical characteristics and/or fingerprinting. Detection of spoofing may be done according to a specific or selected protocol which can be based on crypto or physical characteristics of a communication as further described herein.
[049] Physical characteristics may be any elements related to the physical aspect of a component or signal. For example, in the case of fingerprinting, physical characteristics can be characteristics of the electrical signal, identifying the physical element which transmitted the signal, for instance, the time it takes for an electrical voltage to rise, amount of memory used, power consumption and the like. Physical characteristics may be, or may include data that identifies or characterizes a physical component, e.g., a memory size, a serial number and the like. Physical characteristics may be, or may include data that identifies or characterizes operational aspects of a component, e.g., a CPU clock speed, power consumption, voltage at a specific point or circuit, amount of data sent/received over a network and the like.
[050] According to some embodiments, all communication may be stored (e.g., on a memory unit, in storage system 130 or on a server) and security unit 206 or a server may analyze the communication history and determine that communication previously received by at least one node of in-vehicle network 200 may be compromised. According to some embodiments, security unit 206 and/or at least one node (e.g., ECU) as recipient of communication may perform additional communication integrity checks to detect transmission errors. According to some embodiments, security unit 206 may be embedded into firmware of in-vehicle network 200 and or embedded into an intrusion detection system (IDS). According to some embodiments, security unit 206 may be embedded into processor 201.
[051] Reference is made to Fig. 3, which show a flowchart of a method of authenticity verification, according to some embodiments of the invention. In some embodiments, the method of detecting attacks on in vehicle networks may be performed by computing device 100 (as shown in Fig. 1) or by any other computation device embedded at in-vehicle network 200 (as shown in Figs. 2A-2B).
[052] In some embodiments, processor 201 (e.g., included in security unit 206) may monitor 301 communications at the in-vehicle network 200 until at least one communication attempt is detected 302. In some embodiments, processor 201 and/or security unit 206 may check 303 signatures of the detected communication attempt and/or check 304 external update attempts. In case that the signatures are authenticated and no other source of data is detected, processor 201 and/or security unit 206 may validate 305 the communication authenticity. In case that the signatures are not authenticated and/or another source of data is detected (e.g., a malicious source (node) is injecting messages into the data stream), processor 201 and/or security unit 206 may block 306 the communication.
[053] A system and method as described herein may provide or enforce security to an in-vehicle network, components or system by controlling update or configuration of components on the in- vehicle network. For example, in some embodiments, security unit 206 monitors network traffic destined to ECU 204, determines whether or not the traffic is related to an update or configuration of ECU 204 and, if the traffic is indeed related to an update or configuration of ECU 204, security unit 206 authenticates or verifies the traffic. For example, security unit 206 may allow ECU 202 to configure or update of ECU 204 and may further prevent any other component from configuring or updating firmware in ECU 204. For example, security unit 206 may examine all network traffic directed to ECU 204, e.g., capture and analyze messages or packets sent to ECU 202 over an in-vehicle network, determine whether or not the traffic is related to an update or configuration of ECU 204, and, if messages related to an update or configuration of ECU 204 are not originated or sent from ECU 202 are detected then security unit 206 may block the messages. Accordingly, embodiments of the invention may guarantee that a component (e.g., ECU 204) can only be updated or configured by a specific or designated component or unit, for example, security unit 206 guarantees ECU 204 is updated or configured by ECU 202 and further guarantees that no other component in system 220 can update or configure ECU 204.
[054] An update or configuration as referred to herein may include a firmware update or a modification of a configuration. A configuration may include modifying operational parameters, for example, ECU 202 may configure ECU 204 by changing configuration parameters or values in, or used by, ECU 204, e.g., parameters or values that determine ports used by ECU 204, messages or responses sent by ECU 204 and the like.
[055] In some embodiments security unit 206 may provide ECU 202 with a key or other data useable for signing messages sent to ECU 204. Security unit 206 may further provide ECU 204 with a key or other data usable for verifying a signature. ECU 202 may use a key for signing messages sent to ECU 204, e.g., a key provided by security unit 206 may be used, by ECU 202 and ECU 204 to generate a signature and/or validate a signature as known in the art. For example, messages that include a firmware or other update of ECU 204, sent by ECU 202 may be signed, by ECU 202, using a key provided by security unit 206, and the messages may be verified, by ECU 204, using a key provided by security unit 206. In some embodiments, messages sent by ECU 202 to ECU 204 may be routed via security unit 206 and security unit 206 may verify the messages, e.g., using a key as described. Security unit 206 may periodically generate and update encryption/decryption keys, e.g., security unit 206 may periodically generate new keys and, using a list of ECUs in a system (e.g., stored in storage system 130), security unit 206 may automatically distribute the keys, accordingly, signing messages as described herein may be done by ECUs using keys which are automatically and periodically generated and distributed.
[056] Authenticating messages as described herein may include verifying a signature. For example, since security unit 206 generates and distributes keys used for signing messages as described, security unit 206 may readily authenticate messages by verifying or ascertaining that the messages are correctly signed by the correct keys.
[057] Accordingly, embodiments of the invention enable a system wherein a first component (e.g., ECU 204) can only be updated or configured by a specific, designated, second component in a system (e.g., ECU 202) and further authenticate data communications based on a source and destination of the communication and based on a signature. Embodiments of the invention may further relieve a component from the burden of verifying or validating the authenticity of an entity that updates it. For example and as described, security unit 206 may verify and/or validate that a firmware update of ECU 204 is indeed made by ECU 202 and security unit 206 may further prevent any other ECU or component in a system from updating ECU 204, thus ECU 204 needs not verify or authenticate the source and/or content of an update. It is noted that security unit 206 can perform authentication and protections as described for a large number of ECUs in a system, accordingly, a single unit (e.g., security unit 206) can provide security as described to a large number of units in a system.
[058] Advantages of embodiments of the invention may be readily appreciated by a person skilled in the art. For example, known systems and methods either do not verify or authenticate data transmissions of, or related to, sensitive data or operations such as firmware updates and configuration of components, or they leave it for the receiving component to verify, validate or authenticate a sensitive transmission or operation, accordingly, embodiments of the invention improve the field of security, and specifically, security in in-vehicle systems, by protecting components from being maliciously updated, configured, or reconfigured and by further providing the protection in a way that does not burden the components being updated or configured. Embodiments of the invention further improve the field of security, and specifically, security in in-vehicle systems, by associating data and/or operations with a signature thus providing an additional security measure and preventing maliciously updating or configuring components in a system. Moreover, by centralizing the supervising of sensitive data transmissions and/or centralizing the supervising of sensitive operations (such as configuration of ECUs), embodiments of the invention enable and provide scalable system that is easily and simply managed, e.g., when a new component is added, all that needs to be done in order to protect the new component is update security unit 206 such that it protects the new component as described herein. In another aspect, rather than having to distribute (or provide each ECU to be protected with) keys used for signing messages as described, keys can be stored in, or downloaded to, a single, central unit (e.g., security unit 206) and the central unit can automatically distribute and/or update keys throughout a system.
[059] Unless explicitly stated, the method embodiments described herein are not constrained to a particular order in time or chronological sequence. Additionally, some of the described method elements may be skipped, or they may be repeated, during a sequence of operations of a method.
[060] Various embodiments have been presented. Each of these embodiments may of course include features from other embodiments presented, and embodiments not specifically described may include various features described herein.

Claims

1. A system including:
at least one security unit operatively connected to an in-vehicle data communication network; and
at least first and second components connected to the in-vehicle network;
wherein the security unit is adapted to authenticate communication of data between the first and second components.
2. The system of claim 1, wherein the security unit is integrated into one of the first and second components.
3. The system of claim 1, wherein the security unit is adapted to authenticate wireless communication between the first and second components.
4. The system of claim 1 , comprising a communication unit connected to the security unit and adapted to enable components connected to the in-vehicle network to communicate with external components that are not physically connected to the in-vehicle network.
5. The system of claim 1, wherein the security unit is adapted to, if a communication of data cannot be authenticated, perform at least one of: generate an alarm, block the communication, record information related to the communication, alert the component that sent data and, alert the node that is the destination of the sent data.
6. The system of claim 1 , wherein the security unit and the first component are adapted to: share a secret that is unknown to the second component; and
use the secret to authenticate communication between the security unit and the first component.
7. The system of claim 1 , wherein the security unit is adapted to:
record communications between the first and second nodes;
analyze recorded communications and determine a communication was compromised.
8. The system of claim 1 , wherein the security unit is adapted to check integrity of communicated data.
9. The system of claim 1, wherein the first and second components do not authenticate data communications.
10. A method of securing data communication in an in- vehicle network, the method comprising:
examining, by a security unit connected to the in- vehicle network, communication of data from a first component to a second component, the first and second components connected to the in- vehicle network; and
authenticating the data communication, by the security unit.
11. The method of claim 10, wherein the security unit is integrated into one of the first and second components.
12. The method of claim 10, comprising authenticating wireless communication between the first and second components.
13. The method of claim 10, comprising enabling, by a communication unit connected to the security unit, components connected to the in-vehicle network to communicate with external components that are not physically connected to the in-vehicle network.
14. The method of claim 10, comprising, if the communication of data cannot be authenticated, performing at least one of: generating an alarm, blocking the communication, recording information related to the communication, alerting the component that sent data and, alert the node that is the destination of data sent.
15. The method of claim 10, comprising:
sharing a secret that is unknown to the second component; and
use the secret to authenticate communication between the security unit and the first component.
16. The method of claim 10, comprising:
recording communications between the first and second nodes; and
analyzing recorded communications and determining a communication was compromised.
17. The method of claim 11 , comprising checking integrity of communicated data.
18. A method comprising:
examining at least one message sent from a first unit to a second unit over an in- vehicle network; and
if determining the first unit is not allowed to send the at least one message to the second unit then preventing the second unit from receiving or processing the at least one message.
19. The method of claim 18, comprising determining the first unit is not allowed to send the at least one message based on a signature included in the message.
20. The method of claim 18, comprising determining the first unit is not allowed to send the at least one message based on a list of allowed nodes.
EP18793485.6A 2017-10-03 2018-10-03 System and method for validation of authenticity of communication at in-vehicle networks Pending EP3692698A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762567251P 2017-10-03 2017-10-03
PCT/IL2018/051078 WO2019069308A1 (en) 2017-10-03 2018-10-03 System and method for validation of authenticity of communication at in-vehicle networks

Publications (1)

Publication Number Publication Date
EP3692698A1 true EP3692698A1 (en) 2020-08-12

Family

ID=64017402

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18793485.6A Pending EP3692698A1 (en) 2017-10-03 2018-10-03 System and method for validation of authenticity of communication at in-vehicle networks

Country Status (2)

Country Link
EP (1) EP3692698A1 (en)
WO (1) WO2019069308A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3097988B1 (en) * 2019-06-25 2021-06-04 Renault Sas Method of dialogue with a computer on a vehicle's on-board bus.
CN114124533A (en) * 2021-11-24 2022-03-01 山西大鲲智联科技有限公司 Data interception method and device, electronic equipment and computer readable medium

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2892201B1 (en) * 2014-01-06 2017-08-30 Argus Cyber Security Ltd. Detective watchman
US11165851B2 (en) * 2015-06-29 2021-11-02 Argus Cyber Security Ltd. System and method for providing security to a communication network
US10798114B2 (en) * 2015-06-29 2020-10-06 Argus Cyber Security Ltd. System and method for consistency based anomaly detection in an in-vehicle communication network

Also Published As

Publication number Publication date
WO2019069308A1 (en) 2019-04-11

Similar Documents

Publication Publication Date Title
US11755713B2 (en) System and method for controlling access to an in-vehicle communication network
US11637696B2 (en) End-to-end communication security
Jo et al. A survey of attacks on controller area networks and corresponding countermeasures
US11386017B2 (en) Technologies for secure authentication and programming of accelerator devices
Mundhenk et al. Security in automotive networks: Lightweight authentication and authorization
US10341321B2 (en) System and method for policy based adaptive application capability management and device attestation
Woo et al. A practical security architecture for in-vehicle CAN-FD
US10614216B2 (en) Paravirtualized security threat protection of a computer-driven system with networked devices
EP3198908B1 (en) Securely exchanging vehicular sensor information
JP2019537179A (en) Secure provisioning and management of equipment
US20170302452A1 (en) Message authentication library
CN114710351A (en) Method and system for improving data security during communication
Steger et al. Secup: Secure and efficient wireless software updates for vehicles
WO2021084221A1 (en) Attestation for constrained devices
US20230379152A1 (en) Binding with cryptographic key attestation
CN115088232A (en) Data encryption method, data transmission method, related device and equipment
WO2019069308A1 (en) System and method for validation of authenticity of communication at in-vehicle networks
KR102389727B1 (en) Method and apparatus for evaluating security of electronic controller in vehicle
KR20190097216A (en) Computer-readable storage medium containing a method, apparatus and instructions for signing measurements of a sensor
CN114978544A (en) Access authentication method, device, system, electronic equipment and medium
Zachos Securing J1939 communications using strong encryption with FIPS 140-2
US11909874B2 (en) Secure confidential use of communication session keys
EP3637717B1 (en) System and method for establishing trust of a network device
Andréasson et al. Device Attestation for In-Vehicle Network
WO2018029692A1 (en) System and method for prevention of attacks in connected vehicles

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200504

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ARGUS CYBER SECURITY LTD

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210326