EP4635133A1 - Dispositif d'authentification pour un véhicule - Google Patents

Dispositif d'authentification pour un véhicule

Info

Publication number
EP4635133A1
EP4635133A1 EP23828344.4A EP23828344A EP4635133A1 EP 4635133 A1 EP4635133 A1 EP 4635133A1 EP 23828344 A EP23828344 A EP 23828344A EP 4635133 A1 EP4635133 A1 EP 4635133A1
Authority
EP
European Patent Office
Prior art keywords
network
authentication
validation value
network node
authentication device
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
EP23828344.4A
Other languages
German (de)
English (en)
Inventor
Helge ZINNER
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.)
Aumovio Germany GmbH
Original Assignee
Continental Automotive Technologies GmbH
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 Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of EP4635133A1 publication Critical patent/EP4635133A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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
    • 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
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the invention relates to an authentication device for a vehicle, a network node, a method for authenticating a network of network nodes for a vehicle, a program element and a storage medium.
  • An object of the invention is to provide improved authentication of a network for a vehicle.
  • an authentication device configured to authenticate a network of network nodes for a vehicle.
  • the authentication device is configured to determine a total validation value of an addable size of authentication messages across the network nodes, compare the determined total validation value with a total validation value expected by the authentication device, and authenticate the network based on the comparison of the expected total validation value with the determined total validation value.
  • the authentication messages are, for example, special messages that are generated and sent only for authentication.
  • the authentication device can be one of the network nodes that has, for example, additional or dedicated services or program elements necessary for authentication. Such authentication can be carried out, for example, during setup or starting or booting up the network or during any manipulation of the network. Manipulation is, for example, the replacement of a network node or a software update.
  • a software update can concern a configuration or an update of a program or part of a program, such as a dynamic library file.
  • the validation value is a message length or a runtime.
  • a message length can be, for example, a number of transmission units such as bits or symbols.
  • a runtime can result from the number of transmission units and the transmission speed and can be determined, for example, by measuring or determining the received bits.
  • the validation value is only a message length or only a runtime.
  • the authentication device and the network nodes are connected to one another, for example, via a network bus, also referred to as a bus in this disclosure.
  • the authentication messages can, for example, have a header with an ID to identify the message type.
  • the message body i.e. the content of the message or the so-called "payload" is irrelevant and does not have to be decoded.
  • the only important thing is the length of the message, which is defined, for example, by the number of bits in the payload or the total number of bits in the message.
  • the runtime is then determined by the number of bits and the transmission speed.
  • the authentication device is configured to send a beacon, wherein the beacon is the request to a first network node to generate and send an authentication message, and wherein the authentication device is configured to Authentication message from a second network node that is different from the first network node, and is configured to determine a total validation value, wherein the total validation value corresponds to the added validation values of the authentication messages of the first network node and the second network node.
  • the authentication device waits until it receives an authentication message from the second network node and determines an added validation value from the authentication messages of the first network node and the second network node. This implicitly means that in order to obtain an added validation value, the second network node sends the message to the second network node to enable the addition, and the authentication device can determine an added value such as a total runtime or a total length.
  • the authentication device can be set up to carry out an addition itself or to measure a time until it has received the message from the second node. This is created by sending the authentication messages serially via the first and second network nodes.
  • the determined runtime or “total runtime” can contain offsets that arise at the network nodes or through the sending of the beacon, which can be partly physical in nature and partly caused by data processing or specifications, e.g. through a standard.
  • the authentication device can send a beacon again.
  • Such an authentication process forms a cycle that is described in this disclosure referred to as such.
  • the duration or period of this cycle corresponds to the total validation value and is also referred to herein as cycle length.
  • the authentication device is a network node, a bus master and/or a gateway.
  • it can also be, for example, a control device that has the corresponding requirements.
  • a network node of a network for a vehicle wherein the network node is configured to receive a beacon or an authentication message for authentication of the network, to generate an authentication message which is defined with respect to the authentication by a validation value of an addable size of the authentication messages, and to send the generated authentication message.
  • the validation value can be a message length or a runtime, and in particular can be only one of these values.
  • the network node is, for example, set up to send the authentication message over the bus when it is its turn. This is the case, for example, after a predecessor node with an address or ID known to it has sent its message.
  • the address or ID of the predecessor node is, for example, preconfigured or can be obtained by the authentication device.
  • a chain can be formed that begins with the reception of a beacon and passes through one or more other network nodes in sequence to end again at the authentication device that has the added runtime or the added length of the Authentication messages are determined.
  • the authentication message, or its payload, of the previous network node could be appended to the authentication message generated by the current network node, or the authentication device determines the length of the authentication messages each time a node involved in the authentication sends one and gradually adds up the lengths.
  • the network node is an electronic control unit (ECU), a sensor, a display device, an actuator or another network-capable device.
  • ECU electronice control unit
  • the network node must have hardware logic and/or software logic that can generate and send the authentication messages.
  • a network comprising an authentication device as described herein and at least one network node as described herein.
  • the network may further comprise a network bus and is not limited to an authentication device.
  • the beacon is a network-wide signal or a network-wide message that can be received by all network nodes. If there is another authentication device in the network that also knows a valid overall validation size, it can also perform authentication. In this case, the starting authentication device is different from the device that performs the authentication.
  • the additional authentication device can be part of the chain, i.e. an intermediate authentication station, so to speak, which itself sends an authentication message. There can therefore be several authentication devices in the chain.
  • the authentication device e.g. a bus master, can thus be configured to receive the last authentication message of the chain and to acquire the validation value of an addable size of the authentication messages for authentication.
  • the validation value of the authentication messages is individual for each network node.
  • the network node can be configured with a validation value statically or dynamically, whereby the validation values usually differ from network node to network node.
  • the network has further network nodes, and the authentication device is configured to determine which network node is part of the chain based on a dynamically generated or stored security pattern.
  • the security pattern further contains one or more of the following values: individual validation value for each network node, ID of the previous network node.
  • the validation value for a network node and a receiving node can be preconfigured.
  • the validation value e.g. the individual length of an authentication message from a network node, can be configured before delivery, so that the individual value is only known to the respective network node.
  • each network node only knows the predecessor node, which is preconfigured or communicated to it dynamically.
  • the authentication device can thus be set up to send the validation value to the network nodes. This increases flexibility. Security is provided by the fact that as long as a malicious device does not know the total runtime or the total length, it is not possible for it to identify a single malicious network node. or to configure all network nodes with validation values that result in a valid overall validation value. It must only be ensured that the total runtime or the total length of the authentication messages remains secret and cannot be manipulated, and that the validation value of a network node cannot be read, e.g. if it is taken from the network and analyzed by an attacker. Since the network is secure after, for example, a network node has been replaced with a malicious network node, it can also be assumed that there is no malicious software in the network that can read the validation values during runtime.
  • the network could consist of the authentication device and one or more network nodes. However, several such networks or subnetworks could also exist side by side. This would allow a malicious device to be identified directly or at least isolated.
  • the network is based on a physical layer according to an Ethernet standard.
  • the Ethernet standards available for automotive applications include, for example, the 10 Mbit/s IEEEP802.3cg standard, or standards with 100 Mbit/s, 1000 Mbit/s, or 2.5, 5, 10 Gbit/s).
  • a variant of the IEEEP802.3ch standard is the MultiDrop mode based on CSMA/CD, which does not require switches (switch ICs), but is designed as a bus.
  • the IEEE P802.3cg standard uses, among other things, a mechanism (PLCA, Physical Layer Collision Avoidance) to avoid collisions during bus access and to ensure fair access. Only one PHY (transceiver) is granted access to the bus at a time. This means that collisions cannot occur. Access is designed according to a so-called round robin procedure.
  • Each control unit (ECU, electronic control unit) or each node on the bus is given the opportunity to send within a defined cycle (or sequence).
  • a so-called headnode determines the cycle and repeatedly sends "beacons" on the bus.
  • the nodes then start a timer depending on the ID of the previous node that they know, which determines the sequence in which they are allowed to send, and then send after the timer has expired and they recognize that it is their turn.
  • a method for authenticating a network of network nodes for a vehicle comprises the following steps:
  • the method thus provides a mechanism in which all control devices together form a kind of blockchain and are authenticated via it. If just one node makes a minimal change to the communication, this can classify an authentication device and the bus as insecure, for example.
  • a program element which, when executed on a processor of the authentication device, instructs the authentication device to perform the steps of the method described above.
  • the computer program element may be part of a computer program, but it may also be a whole program in itself.
  • the computer program element may be used to update an existing computer program to invention.
  • a storage medium is provided on which the program element is stored.
  • the computer-readable medium may be considered to be a storage medium, such as a USB flash drive, a CD, a DVD, a data storage device, a hard disk, or any other medium on which a program element as described above can be stored.
  • a storage medium such as a USB flash drive, a CD, a DVD, a data storage device, a hard disk, or any other medium on which a program element as described above can be stored.
  • the invention can be used to detect, for example, a change in the network, such as an attack via OBD access, an exchange or manipulation of a control unit, or access to safety-critical control units via OBD or infotainment. Furthermore, attacks such as hacker attacks on vehicle networks and theft can be detected and prevented. Furthermore, sensors and sensor data can be authenticated.
  • a computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a semiconductor medium supplied together with or as part of other hardware, but may also be stored/distributed in other forms, for example via the Internet or other wired or wireless telecommunications systems.
  • a suitable medium such as an optical storage medium or a semiconductor medium supplied together with or as part of other hardware, but may also be stored/distributed in other forms, for example via the Internet or other wired or wireless telecommunications systems.
  • Fig. 1A is a diagram of a first example scenario
  • Fig. 1 B is a diagram of a second example scenario
  • Fig. 2 is a block diagram of a network according to an embodiment
  • Fig. 3 is a flow chart of a method for authenticating a network
  • Fig. 4A is a diagram of a valid bus cycle
  • Fig. 4B is a diagram of a faulty bus cycle
  • Fig. 5 a flow chart of the method with further steps
  • Fig. 6 a flow chart of the procedure with focus on security patterns
  • Fig. 7A a first security example
  • Fig. 7B a second security example
  • Fig. 8 shows a vehicle with a network according to an embodiment.
  • Fig. 1 A shows a diagram of an example scenario in which an existing communication connection 108 on a network bus is interfered with.
  • an additional data packet 106 of malware is inserted between the regular data packets 104.
  • the sender of the data stream including the additional data packet 106 is the same.
  • Such a data packet in an authentication message would change its length and thus be detected.
  • Fig. 1 B shows a diagram of a second scenario with a manipulation of control units, in which a control unit 114 is replaced.
  • the ECU A 102 communicates with the ECU B 114 via the transceivers 110 and 112.
  • the ECU B 114 could be replaced by an ECU B' 116 with transceiver 118, for example to bypass an immobilizer or to manipulate the engine control. From the application's point of view, it cannot be recognized that this is a replaced control unit ECU B' 116.
  • the control unit ECU B' 116 can, for example, take on the original name, such as an ID, an IP address or a bus system address, of the original control unit ECU B 114 and is therefore invisible to the software. This represents a potential danger and can also affect sensors and actuators.
  • a jump from, for example, an infotainment domain of an ECU server or domain controller to a driver assistance system (ADAS, Advanced Driver Assistance Systems) domain should be prevented.
  • ADAS Driver Assistance Systems
  • Fig. 2 shows a block diagram of a network comprising an authentication device 202 and several network nodes 204 and a network bus 206.
  • Fig. 3 shows a block diagram of a method 300 for authenticating a network of network nodes for a vehicle, comprising the steps:
  • Figures 4A and 4B show the effects of attacks and unauthenticated devices on the bus in a case where the network nodes NO, N1, N2, N3 know the total runtime 410.
  • the total runtime 410, 420 changes and postpones the sending of the next beacon 408, 418 by a difference 424 so that a deviation from the expected total runtime 410 can be detected. Any interested node can detect this shift.
  • Fig. 4A The secure scenario is shown in Fig. 4A.
  • Each network node e.g. a control unit, a sensor or an actuator, follows the pattern and sends exactly the message in the right size (e.g. 200 bytes).
  • the sum of all data packets or message lengths in the cycle (sent and not sent) then defines the cycle length 410, i.e. the total validation value, and thus also the time of transmission of the next beacon 408, 410, which is received by all participants NO, N1, N2, N3.
  • No synchronization is necessary here, since each network node transmits immediately when the bus is free (observing the specified order). The method therefore works without the need for precise coordination of the transmission cycle.
  • Fig. 4B shows a case in which an attack or an error has occurred.
  • One or more participants e.g. network nodes 414, 416
  • network nodes 414, 416 are affected and behave differently than defined by the security pattern. This does not initially affect the bus communication. However, the actual cycle length is affected and deviates significantly from the previously defined one. This can then be identified as a problem. In this case, no network node needs to know the overall pattern or have knowledge of the data of the other network nodes, which is a particular advantage of the method. The network nodes only have knowledge of, for example, the start of the next cycle. The method is therefore particularly suitable for a highly distributed system. At the time the new beacon 408 is sent out by the authentication device or master, each network node then knows whether the bus can be considered secure or not.
  • the method 300 presented in Fig. 3 can be part of a network procedure with further steps, which has the following steps, as shown in Fig. 5:
  • step 502 the network bus is initialized.
  • step 504 the number of bus participants capable of transmitting, i.e. the network nodes described here, is determined.
  • a security pattern is defined.
  • the security pattern contains, for example, the individual validation values such as the runtime or length of the authentication message. These can be determined using a random generator, for example.
  • the security pattern can also define the order in which the network nodes send their authentication message.
  • the network nodes thus form a chain with, for example, the authentication device as the start and end link, whereby the authentication device itself does not generate and send an authentication message.
  • there are other authentication devices in the chain that do not necessarily generate and distribute a security pattern, but receive it from the master of the bus.
  • the overall validation value is calculated based on the pattern.
  • an overall validation value can first be specified or already configured and the security pattern in step 506 is defined under the condition of this specified overall validation value.
  • the overall validation value can optionally be transmitted to all network nodes. In an alternative, the overall validation value can be transmitted to some of the network nodes, which can then also carry out authentication.
  • step 510 the security pattern is sent, for example, in individual form to the network nodes.
  • the network nodes are sent, for example, the length of the authentication message to be generated and the ID of the predecessor node.
  • steps 504 to 510 or part of these steps can be replaced by a preconfiguration.
  • the order of steps 510 and 508 can also be swapped.
  • step 512 a beacon is sent, which starts the sending of the authentication messages.
  • the authentication messages are generated and sent by the network nodes in the defined order according to the respective validation value.
  • each node on the bus sends a predefined data packet, for example after startup or initialization or after the vehicle starts. Only the size of the packet is relevant here and not the content. This implicitly maps the bus cycle. Only after a node has sent can the next node send, and so on. When all nodes have had their turn, the master can send a new beacon to start a new cycle, whereby the time of sending this new beacon depends exclusively on the sum of the nodes' delays. Each participant therefore has a direct influence on this time. The next beacon time can therefore be predicted precisely.
  • step 516 the validation of the total validation value takes place, i.e. the authentication and checking of the total validation value is carried out according to the method 300.
  • Steps 504 to 512 and 516 can, for example, be performed by the authentication device.
  • Fig. 5 therefore also shows the process of bus identification and pattern definition and transmission.
  • Terminal 30 i.e. when the power supply is connected, or a service, a plug'n'play of a new control unit, or at any other point in time, which is either permanently configured or communicated dynamically to the participants on the bus.
  • terminal 30 i.e. when the power supply is connected, or a service, a plug'n'play of a new control unit, or at any other point in time, which is either permanently configured or communicated dynamically to the participants on the bus.
  • knowledge of the number of participants is necessary - i.e. which control units are included in the security procedure, or which control units are to be tested. For example, all of them could always be included, or just a subset of the connected participants.
  • the subset can be control units that are either particularly safety-critical, devices with a monitoring function, or just devices that can technically participate in the procedure. This is shown in Fig. 6. It should also be taken into account which control units are used for monitoring,
  • Fig. 6 shows a flow chart of the method with a focus on the creation and transmission of the security pattern.
  • the reference symbols are related to Fig. 5.
  • Step 504 is divided into two sub-steps 602 and 604. Accordingly, in 602 it is determined which control units or participants should be checked by the method. These are, for example, newly connected control units, control units that have been in sleep mode, control units with an online connection, multiple interfaces, etc.
  • the control units are determined that should be informed of the security result, such as only the bus master, all control units or diagnostic devices, etc.
  • the method either dynamically determines a security pattern or uses a pattern that has already been saved and preconfigured.
  • the pattern defines which participant or network node (ECU, sensor, actuator, etc.) sends an authentication message. Furthermore, the pattern defines the message lengths that are to be sent. No time synchronization is necessary for this, because the control units send in sequence or when the previous one has sent its authentication message.
  • the cycle length or the total validation value is calculated.
  • a decision is made as to whether further control units are to be informed. If only the bus master as an authentication device, for example the gateway, monitors the bus is to be used, only the pattern is transmitted in step 616. The cycle length does not need to be transmitted in this case. Otherwise, i.e.
  • step 614 the cycle length can first be transmitted in step 614 and then step 616 can be used to transmit the pattern.
  • step 616 can be used to transmit the pattern.
  • Figures 7A and 7B show two examples of a security pattern 702.
  • nodes 0, 1, 5, 7 and 8 send (Tx) an authentication message with the specified length L in bytes, while all other nodes do not send an authentication message.
  • the nodes that do not send an authentication message are also part of the pattern 702, since not sending also influences the cycle length.
  • the advantage of this is that the pattern 702 does not have to be completely distributed or known, only the respective node has to know its own values.
  • nodes 1, 3, 5 and 8 send an authentication message.
  • the lengths L differ partially from those of the pattern 702 in Fig. 7A.
  • the security level works in combination with all participants, similar to a blockchain-based system.
  • the applied pattern then clearly determines the cycle length.
  • Various patterns are possible here.
  • the pattern is a static pattern that is encrypted and programmed.
  • the pattern is a dynamically created pattern.
  • the pattern is based on predefined parameters such as the current time.
  • the pattern is based on the MAC addresses of the participants.
  • the pattern does not directly specify the length of the authentication message, but it may contain one or more parameters from which the network node can derive the length.
  • the authentication device which is the master, sends a parameter value to the network node, e.g. a control unit, which the control unit adds to the last two digits of its MAC address and then uses as the length for the next data packet, which here is equivalent to the authentication message.
  • the pattern can also be permanently encoded in a secure memory area and then queried on request or the frame length can be determined with it.
  • Fig. 8 schematically shows a vehicle 800 with a network 200 described herein, comprising an authentication device 202, several network nodes 204, and a network bus 206.
  • the process makes it possible to block attacks in the hardware and thus prevent them from reaching the ECU software or even a possible forwarding. This relieves the burden on resources and possible firewalls. The attacker can no longer gain access to the system using the process. Furthermore, attacks can not only be fended off, but the attempt itself can also be diagnosed.
  • the process also offers another method to only allow authorized access to the vehicle's on-board network.
  • the common hardware does not have to be changed; the existing hardware can continue to be used.
  • the computing capacity required is low, so that a security procedure can be implemented and subsequently written to the flash memory without affecting the system resources (memory, computing power, real-time capability).
  • the process also has the particular advantage that there is no need to actively intervene in the communication.
  • the security procedure can be carried out and checked silently. In addition, not all control units have to participate in the process.
  • the process can also be evaluated in real time and does not require any further calculation or analysis in a cloud.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un dispositif d'authentification (202) conçu pour authentifier un réseau de nœuds de réseau pour un véhicule (800). À cet effet, le dispositif d'authentification (202) est conçu pour déterminer une valeur de validation globale d'une taille pouvant être ajoutée de messages d'authentification concernant les nœuds de réseau (204), pour comparer la valeur de validation globale déterminée avec une valeur de validation globale attendue par le dispositif d'authentification (202), et pour authentifier le réseau (200) sur la base de la comparaison de la valeur de validation globale attendue avec la valeur de validation globale déterminée.
EP23828344.4A 2022-12-13 2023-12-01 Dispositif d'authentification pour un véhicule Pending EP4635133A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022213582.2A DE102022213582A1 (de) 2022-12-13 2022-12-13 Authentifizierungsgerät für ein Fahrzeug
PCT/DE2023/200241 WO2024125732A1 (fr) 2022-12-13 2023-12-01 Dispositif d'authentification pour un véhicule

Publications (1)

Publication Number Publication Date
EP4635133A1 true EP4635133A1 (fr) 2025-10-22

Family

ID=89322083

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23828344.4A Pending EP4635133A1 (fr) 2022-12-13 2023-12-01 Dispositif d'authentification pour un véhicule

Country Status (4)

Country Link
EP (1) EP4635133A1 (fr)
CN (1) CN120303904A (fr)
DE (1) DE102022213582A1 (fr)
WO (1) WO2024125732A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102024209355A1 (de) * 2024-09-26 2026-03-26 Infineon Technologies Ag Vorrichtung zur sicheren kommunikation in einem ethernetbasierten bussystem und verfahren zum authentifizieren von ethernet-frames

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012216689B4 (de) * 2012-09-18 2017-05-04 Continental Automotive Gmbh Verfahren zur Überwachung eines Ethernet-basierten Kommunikationsnetzwerks in einem Kraftfahrzeug
KR101371902B1 (ko) * 2012-12-12 2014-03-10 현대자동차주식회사 차량 네트워크 공격 탐지 장치 및 그 방법
KR101472896B1 (ko) * 2013-12-13 2014-12-16 현대자동차주식회사 차량 내 통신 네트워크에서의 보안 강화 방법 및 그 장치
DE102018213198A1 (de) * 2018-08-07 2020-02-13 Continental Teves Ag & Co. Ohg Verfahren zum Überwachen der Kommunikation eines Bussystems eines Fahrzeugs
DE102018213898B4 (de) * 2018-08-17 2020-03-19 Continental Automotive Gmbh Überwachung einer Netzwerkverbindung auf Abhören
DE102019220096B4 (de) * 2019-12-18 2021-09-16 Continental Automotive Gmbh Verfahren zur Absicherung der Zeitsynchronisation eines Ethernet-Bordnetzes
DE102021202075A1 (de) * 2020-07-23 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Validierung von Nachrichten

Also Published As

Publication number Publication date
DE102022213582A1 (de) 2024-06-13
CN120303904A (zh) 2025-07-11
WO2024125732A1 (fr) 2024-06-20

Similar Documents

Publication Publication Date Title
DE102013202064B4 (de) Verfahren und Vorrichtung zum Verbinden eines Diagnosegeräts mit einem Steuergerät in einem Kraftfahrzeug
EP3278529B1 (fr) Procédé de détection d'attaque, dispositif de détection d'attaque et système de bus pour un véhicule automobile
DE102019130502A1 (de) Fahrzeug und Verfahren für eine fahrzeuginterne Mitteilungsübertragung
EP3501154A1 (fr) Établissement d'une communication sécurisée à l'intérieur d'un réseau de communication en temps réel
DE112016003907T5 (de) Weiterleitungsvorrichtung
EP2842291B1 (fr) Authentification d'un premier appareil au moyen d'un centre de commutation
DE102019220096B4 (de) Verfahren zur Absicherung der Zeitsynchronisation eines Ethernet-Bordnetzes
DE102016222740A1 (de) Verfahren für ein Kommunikationsnetzwerk und elektronische Kontrolleinheit
WO2018077528A1 (fr) Détection de manipulations dans un réseau can par vérification d'identifiants can
DE102020125262A1 (de) Warnsystem für Controller Area Networks
DE102016222741A1 (de) Verfahren für ein Kommunikationsnetzwerk und elektronische Kontrolleinheit
DE102017203185B4 (de) Kraftfahrzeug mit einem in mehrere getrennte Domänen eingeteilten Datennetzwerk sowie Verfahren zum Betreiben des Datennetzwerks
EP3641231A1 (fr) Procédé et dispositif de surveillance d'une communication de données
EP4635133A1 (fr) Dispositif d'authentification pour un véhicule
DE102012210327A1 (de) Verfahren zum Übertragen von Nachrichten in einem Kommunikationssystem, insbesondere eines Fahrzeugs
DE102016210625B4 (de) Verfahren und Vorrichtungen zum Testen der Erreichbarkeit von Ethernet-Netzwerkknoten in heterogenen Netzwerken
DE10331307A1 (de) Vorrichtung und Verfahren sowie Sicherheitsmodul zur Sicherung eines Datenzugriffs eines Kommunikationsteilnehmers auf mindestens eine Automatisierungskomponente eines Automatisierungssystems
EP3688951A1 (fr) Procédé de détection d'une attaque menée contre un calculateur d'un véhicule
EP3560153B1 (fr) Procédé pour faire fonctionner un dispositif de traitement de données et dispositif de traitement de données
DE102016212755B3 (de) Ethernet-Fahrzeugbordnetz mit geschützter Konfigurierbarkeit
DE102010028225A1 (de) Verfahren zur Bereitstellung einer Kommunikation für mindestens ein Gerät
DE102019125493A1 (de) Slaveeinrichtung, Bussystem und Verfahren
WO2018184786A1 (fr) Procédé de configuration d'au moins un appareil dans un réseau, programme informatique et support d'enregistrement lisible par ordinateur
DE102022214195A1 (de) Verfahren und Recheneinheit zur Erkennung eines unerlaubten physischen Zugriffs auf ein Bussystem
DE102023123232A1 (de) Fahrzeugnetzwerksicherheit

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: 20250714

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR

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

Owner name: AUMOVIO GERMANY GMBH

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)