EP3692698A1 - Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués - Google Patents

Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués

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.)
Withdrawn
Application number
EP18793485.6A
Other languages
German (de)
English (en)
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/fr
Withdrawn legal-status Critical Current

Links

Classifications

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un système et un procédé permettant de sécuriser une communication de données dans un réseau embarqué, lesdits système et procédé pouvant comprendre une unité de sécurité conçue pour authentifier une communication de données entre des premier et second composants connectés au réseau. Une unité de sécurité peut authentifier une communication se rapportant à une mise à jour de micrologiciel. Si une communication de données ne peut pas être authentifiée, l'unité de sécurité peut bloquer la communication.
EP18793485.6A 2017-10-03 2018-10-03 Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués Withdrawn EP3692698A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762567251P 2017-10-03 2017-10-03
PCT/IL2018/051078 WO2019069308A1 (fr) 2017-10-03 2018-10-03 Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués

Publications (1)

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

Family

ID=64017402

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18793485.6A Withdrawn EP3692698A1 (fr) 2017-10-03 2018-10-03 Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués

Country Status (2)

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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3097988B1 (fr) * 2019-06-25 2021-06-04 Renault Sas Procédé de dialogue avec un calculateur sur bus embarqué de véhicule.
CN114124533B (zh) * 2021-11-24 2024-07-02 山西大鲲智联科技有限公司 数据拦截方法、装置、电子设备和计算机可读介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3358800B1 (fr) * 2014-01-06 2021-10-20 Argus Cyber Security Ltd Gardien de bus
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 (fr) 2019-04-11

Similar Documents

Publication Publication Date Title
US11755713B2 (en) System and method for controlling access to an in-vehicle communication network
Jo et al. A survey of attacks on controller area networks and corresponding countermeasures
US11637696B2 (en) End-to-end communication security
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
EP3198908B1 (fr) Échange sécurisé d'informations de capteur de véhicule
JP2019537179A (ja) 機器の安全なプロビジョニングと管理
US20170302452A1 (en) Message authentication library
CN114710351A (zh) 用于在通信过程中改进数据安全性的方法和系统
Steger et al. Secup: Secure and efficient wireless software updates for vehicles
KR102389727B1 (ko) 차량 내 전자식 제어기 보안성 평가 방법 및 그 장치
US12113898B2 (en) Binding with cryptographic key attestation
WO2021084221A1 (fr) Attestation pour dispositifs contraints
CN115088232A (zh) 数据加密的方法、数据传输的方法、相关装置以及设备
EP3692698A1 (fr) Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués
US11909874B2 (en) Secure confidential use of communication session keys
KR20190097216A (ko) 센서의 측정값들에 서명하기 위한 방법, 장치 및 명령어들을 포함하는 컴퓨터 판독 가능 저장 매체
CN114978544A (zh) 一种访问认证方法、装置、系统、电子设备及介质
Zachos Securing J1939 communications using strong encryption with FIPS 140-2
EP3637717B1 (fr) Système et procédé permettant d'établir la confiance d'un dispositif de réseau
Andréasson et al. Device Attestation for In-Vehicle Network
Lodge et al. Addressing Vulnerabilities in CAN-FD: An Exploration and Security Enhancement Approach
CN118316641A (zh) 物联网设备的数据处理方法、装置、电子设备及存储介质

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

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20240501