DEVICE FOR SECURE COMMUNICATION IN AN ETHERNET-BASED BUS SYSTEM AND METHOD FOR AUTHENTICATING ETHERNET FRAMES

Abstract

The concept presented herein comprises a device (105, 110) for secure communication in an Ethernet-based half-duplex multidrop bus system (100), wherein the device (105, 110) has a physical interface (111) for receiving and sending Ethernet frames (310) at the physical layer (OSI layer 1) and a processing unit (112) for processing the Ethernet frames (310) at the data link layer (OSI layer 2). The device (105, 110) is configured to transmit an Ethernet frame (310) via the physical interface (111) only at a transmission time (TO) specified and exclusively reserved by a bus master.The device (105, 110) includes a monitoring unit (113) configured to verify the authenticity of a received Ethernet frame (310) originating from another network participant (140) by comparing the received Ethernet frame (310) and its transmission time (TO), and wherein the monitoring unit (113) is configured to corrupt the received Ethernet frame (310) on the physical bus (100) if a lack of authenticity is detected, so that none of the other network participants (120, 130) recognize this Ethernet frame (310) as valid at the physical layer (OSI layer 1).

Description

[0001] The innovative concept described herein concerns the technical field of network technology. A device for secure communication in an Ethernet-based half-duplex multidrop bus system is proposed, enabling the authentication of Ethernet frames transmitted via the multidrop bus. Furthermore, a corresponding method for authenticating Ethernet frames in an Ethernet-based half-duplex multidrop bus system is proposed.

[0002] Ethernet-based half-duplex multi-drop bus systems are network topologies in which multiple network entities can send and receive information in half-duplex mode on a shared bus. A multi-drop bus (MDB) is a computer bus where all components are galvanically isolated from each other and connected to the electrical circuit. A multi-drop bus allows multiple nodes to use a single bus segment. An arbitration process determines which device on the bus transmits information while the other devices listen. Multi-drop buses offer the advantage of a simple and therefore cost-effective design. They are also easily scalable.

[0003] However, in such bus systems, participants can be relatively easily compromised or replaced by fake participants. A fake participant can impersonate a genuine participant, for example, by forging their messages, which then appear falsely authentic to the other participants.

[0004] Current solutions for this involve implementing secure communication at OSI Layer 3 or above (e.g., MACsec, IPsec, TLS). However, this leads to additional delays in information transmission and increased power consumption for processing the required secure communication protocol. Implementing a crypto module or even a complete security protocol requires a significant increase in the necessary additional silicon area on the chip, resulting in considerably higher costs. Furthermore, with known security solutions implemented at OSI Layer 3 or above, a forged Ethernet frame from a fake bus participant can enter the Ethernet core network before it can even be detected.

[0005] It would therefore be desirable to improve existing security solutions for authenticating Ethernet frames in multidrop bus systems so that corrupt and / or forged data frames are detected and filtered out at the hardware level.

[0006] This can be achieved by a device for secure communication in an Ethernet-based half-duplex multidrop bus system and by a corresponding method for authenticating Ethernet frames in such a multidrop bus system with the features according to the independent claims. Furthermore, a computer program with program code for carrying out the method is proposed.

[0007] Further embodiments and advantageous aspects of the innovative device and the corresponding method are mentioned in the respective dependent patent claims.

[0008] The innovative device features a physical interface (PHY) for receiving and sending Ethernet frames at the physical layer (i.e., OSI layer 1). The device also features a processing unit for handling Ethernet frames at the data link layer (i.e., OSI layer 2). The device is configured to transmit an Ethernet frame via the physical interface (PHY) only at a specific and exclusively reserved transmission time (TO) specified by a bus master.According to the innovative concept presented herein, the device includes a monitoring unit (GUARD) designed to verify the authenticity of a received Ethernet frame originating from another network participant by comparing the received Ethernet frame with its transmission time (TO), wherein the monitoring unit (GUARD) is designed to corrupt the received Ethernet frame on the physical bus if a lack of authenticity is detected, so that no other network participant recognizes this Ethernet frame as valid at the physical layer (OSI layer 1).

[0009] The associated process includes a step of receiving and sending Ethernet frames at the physical layer (OSI Layer 1) via a physical interface (PHY), and a step of processing the Ethernet frames at the data link layer (OSI Layer 2) via a processing unit (microcontroller). An Ethernet frame is only sent via the physical interface (PHY) at a transmission time (TO) specified and exclusively reserved by a bus master.According to the innovative concept presented herein, the method involves verifying the authenticity of a received Ethernet frame originating from another network participant by comparing the received Ethernet frame with its transmission time (TO). In the event of a detected lack of authenticity, the method includes a further step whereby the received Ethernet frame is corrupted on the physical multidrop bus so that no other network participant recognizes this Ethernet frame as valid at the physical layer (OSI layer 1).

[0010] Some exemplary embodiments are shown in the drawing and are explained below. They show: Fig. 1. A schematic block diagram of an Ethernet network with multiple network participants, Fig. 2 a schematic view of an innovative device according to an exemplary embodiment, Fig. 3. the structure of an Ethernet frame, Fig. 4 the sequence of a PLCA cycle, Fig. 5A, Fig. 5B Schematic block diagrams to illustrate the OSI layers in a stack and the placement of the innovative monitoring unit within the stack, Fig. 6A-6D schematic block diagrams to illustrate the hardware-side implementation of the innovative monitoring unit within individual component parts, Fig. 7 a schematic block diagram of an Ethernet network with multiple network participants, wherein the bus master is equipped with an innovative monitoring unit, Fig. 8 a schematic block diagram of an Ethernet network with multiple network participants, wherein the bus master and the bus slaves are each equipped with an innovative monitoring unit, and Fig. 9 A schematic block diagram to illustrate an innovative procedure.

[0011] In the following, exemplary embodiments are described in more detail with reference to the figures, whereby elements with the same or similar function are provided with the same reference numerals.

[0012] Process steps depicted or described in this disclosure may also be carried out in a different order than depicted or described. Furthermore, process steps relating to a specific feature of a device are interchangeable with that very feature of the device, and vice versa.

[0013] The following embodiments are described using the 10BASE-T1S standard as an example. However, it is also conceivable that the innovative concept described herein could be used in other Ethernet-based half-duplex network systems, such as 10BASE-T1M. Likewise, it would be conceivable that the innovative concept presented here could be applied in all other available Ethernet standards, particularly in PLCA-based Ethernet standards (PLCA: Physical Layer Collision Avoidance).

[0014] For the sake of clarity, a few of the terms used herein will first be defined in more detail.

[0015] Where reference is made here to different OSI layers, this refers to the individual layers of the ISO / OSI reference model standardized by the IEEE. The OSI layers can also be referred to as layers or OSI layers.

[0016] According to IEEE, OSI layer 1 is also referred to as the physical layer. It is the lowest layer in the ISO / OSI reference model. This layer provides mechanical, electrical, physical, and other functional means to activate and deactivate physical connections, maintain them, and transmit bits over them.

[0017] OSI layer 1 can be divided into up to three sub-layers, including the topmost PCS (Physical Coding Sub Layer), the PMA (Physical Medium Attachment) Sub Layer below it, and the bottommost PMD (Physical Medium Dependent) Sub Layer.

[0018] The PCS sublayer determines when a functional connection is established, compensates for different data rates, and performs the encoding. The PCS sublayer provides an interface between the underlying PMA sublayer and the media-independent interface (MII) above it.

[0019] The PMA Sub Layer is responsible for PMA framing, octet synchronization / recognition, and scrambling / descrambling.

[0020] The PMD sublayer consists of a transceiver for the physical medium. A PMD sublayer also helps define the physical layer of network protocols. Specifically, it defines the details of transmitting and receiving individual bits on a physical medium. These responsibilities include bit timing, signal encoding, interaction with the physical medium, and the characteristics of the line itself.

[0021] Directly above OSI layer 1 is OSI layer 2, also known as the data link layer. The data link layer's task is to ensure reliable, meaning largely error-free, transmission and to regulate access to the transmission medium. This is achieved by dividing the bit data stream into blocks—also called frames—and adding checksums as part of channel coding. This allows the receiver to detect erroneous blocks and either discard them or even correct them. However, this layer does not provide for re-requesting discarded blocks.

[0022] OSI Layer 2 can be divided into two sublayers, including the MAC Sublayer (Media Access Control, Layer 2a) and the LLC Sublayer (Logical Link Control, Layer 2b). The Ethernet protocol describes both OSI Layer 1 and OSI Layer 2, and CSMA / CD can be used for access control at both layers.

[0023] The OSI layers can be integrated into different, independent physical components of a network entity (also called a network participant). A network participant for use in the innovative multidrop bus, for example, can have at least one processing unit that decides which data to send and processes the received data. This processing unit could be, for example, a microcontroller. Furthermore, an entity can have a so-called PHY, which converts the digital information into physical information on the bus.

[0024] PHY, an abbreviation for Physical Layer, is a term from computer and communications engineering. A PHY refers to a special integrated circuit or functional group within a circuit responsible for encoding and decoding data between a purely digital system and the transmission medium (physical medium). PHY also stands for physical interface.

[0025] A PHY is required within a network interface controller for the implementation of the functions of the physical layer, i.e., OSI layer 1.

[0026] A PHY connects a device at the data link layer (OSI layer 2), often also called a MAC, to a physical medium such as a copper cable. A PHY typically incorporates functions of both the PCS sublayer and the PMD sublayer.

[0027] An Ethernet PHY is a component that operates at the physical layer, specifically at OSI layer 1 of the OSI model. An Ethernet PHY implements the functionalities of Ethernet assigned to the physical layer. Its purpose is to provide physical access to a connection using analog signals. It is typically connected via a media-independent interface (MII) to a MAC chip in a microcontroller or other system responsible for higher-layer functions.

[0028] More precisely, the Ethernet PHY is a chip that implements the hardware transmit and receive function of Ethernet frames; it forms the interface between the analog domain of Ethernet line modulation and the digital domain of packet signaling at the data link layer (OSI layer 2).

[0029] Common Ethernet interfaces include, for example, fiber optic cables or two to four copper pairs for data communication. A single-pair Ethernet protocol, such as Single Pair Ethernet (SPE), can be used for communication, which requires only a single copper cable pair and can still communicate at the intended speeds.

[0030] However, data security and data integrity also play a role in Ethernet-based bus systems. For example, multidrop bus systems are used in industrial environments and the automotive sector. Particularly in the latter case, manipulations on the multidrop bus, such as message forgery, can lead to serious security flaws that, in the worst-case scenario, can endanger the lives of the vehicle's occupants. Therefore, a concept that allows for secure communication in a multidrop bus system in a simple and cost-effective manner is desirable.

[0031] Fig. Figure 1 shows a schematic block diagram of a conventional vehicle bus system 10. The vehicle bus system 10 can have several control units 101, 102, 103, 104; 110, 120, 130, 140, which can also be referred to as ECUs (Electronic Control Units). Each ECU can perform a different task in the vehicle.

[0032] ECUs 101, 102, 103, 104; 110, 120, 130, 140 can be integrated into different subnetworks. Switches 105, 106, 107 can be used to connect ECUs 101, 102, 103, 104; 110, 120, 130, 140 located in the different subnetworks.

[0033] For example, it would be conceivable that ECU 101 is integrated into a first subnetwork, ECU 102 into a (similar or different) second subnetwork, and ECUs 103 and 104 into a (similar or different) third subnetwork. ECUs 110, 120, 130, and 140 could also be integrated into a (similar or different) fourth subnetwork. The subnetworks could differ, for example, in their data rate or the medium used. The subnetworks, as well as the entire vehicle bus system 10, could preferably be Ethernet networks.

[0034] Subnetwork 100, which contains ECUs 110, 120, 130, 140 and switch 105, can be configured, for example, as an Ethernet-based half-duplex multidrop bus system. In automotive environments, networks based on the 10BASE-T1S standard are commonly used, as described here for ECUs 110, 120, 130, and 140. This is an Ethernet network with a data rate of up to 10 Mbit / s, baseband signaling, and twisted-pair cabling. 10BASE-T1S (IEEE 802.cg) is a variant of Automotive Ethernet that supports half-duplex and full-duplex communication and allows either a direct point-to-point connection between two nodes or network participants, or the use of a multidrop topology with multiple nodes or network participants on a single bus segment.

[0035] Multidrop cabling of a bus line offers expansion and scalability with fewer physical wires and lower weight than point-to-point topologies. With minimal space requirements at the ECU, the bus line can be easily extended by adding sensor units.

[0036] One of the main goals of the 10BASE-T1S physical layer is to coordinate transmissions over different media and ensure cooperative behavior among nodes on a multidrop bus. This is achieved, among other things, through the use of Physical Layer Collision Avoidance (PLCA) technology to minimize dead time and prevent collisions. PLCA is described in more detail below.

[0037] Fig. Figure 2, however, initially shows a purely exemplary schematic block diagram of an innovative device using the example of a bus-slave device, such as the ECU 110 from Fig. 1. The ECU 110 is designed here as an innovative device for secure communication in an Ethernet-based half-duplex multidrop bus system 100. However, the innovative device 110 can also be any other device previously described with reference to Fig. As described in Figure 1, network participants 105, 120, 130, and 140 are involved. The innovative device can be configured, for example, as a bus slave device, such as the ECUs 110, 120, 130, and 140, or as a bus master device, such as the switch 105. Corresponding embodiments are described in more detail with reference to the following figures.

[0038] The in Fig. The innovative device 110, illustrated as an example, has a physical interface 111, also referred to as a PHY, for receiving and sending Ethernet frames at the physical layer (OSI layer 1). The device 110 also has a processing unit 112 for processing the Ethernet frames at the data link layer (OSI layer 2).

[0039] The device 110 is designed to send an Ethernet frame via the physical interface 111 only at a transmission time specified and exclusively reserved by a bus master.

[0040] Furthermore, the device 110 includes an innovative monitoring unit 113, which is also referred to as GUARD in the present disclosure. The monitoring unit (GUARD) 113 is designed to detect a signal from another network participant, e.g., from a neighboring ECU 120 ( Fig. 1) to verify the authenticity of the originating, received Ethernet frame by comparing the received Ethernet frame with its transmission time.

[0041] Should the monitoring unit (GUARD) 113 detect a lack of authenticity in the received Ethernet frame, it can corrupt this Ethernet frame on the physical bus 100 so that no other network participant, such as the other ECUs 130, 140 ( Fig. 1) or the switch 105 recognizes this Ethernet frame as valid at the physical layer (OSI layer 1).

[0042] The monitoring unit (GUARD) 113 can preferably be integrated in the physical layer, i.e., in OSI layer 1. For example, the monitoring unit (GUARD) 113 can be integrated between the physical layer (OSI layer 1) and the data link layer (OSI layer 2).

[0043] Fig. Figure 3 schematically shows an Ethernet packet 300 with an Ethernet frame 310, as it can be used according to the innovative concept presented here. The Ethernet frame 310 could, for example, be a so-called Tagged MAC Frame according to IEEE 802.3.

[0044] Ethernet frame 310 contains a six-byte encoded destination MAC address 311, also known as the Destination Address (DA), and a six-byte encoded source MAC address 312, also known as the Source Address (SA). The Destination MAC address 311 identifies the network station that is to receive the data contained in Ethernet frame 310. This Destination MAC address 311 can also be a multicast or broadcast address. The Source MAC address 312 identifies the sender of Ethernet frame 310.

[0045] In a Tagged MAC Frame 310 according to IEEE 802.1, four additional bytes follow as VLAN tag 313. The first two bytes contain the constant 0x8100 (=802.1q TagType), which identifies a Tagged MAC Frame 310 as such. In a Basic MAC Frame, the Ethertype field would otherwise be located here. The value 0x8100 can therefore also be considered the Ethertype for VLAN data; however, the actual Ethertype (su) follows tag 313.

[0046] The next two bytes (TCI Tag Control Information) contain three bits for the priority (Class of Service, 0 lowest, 7 highest priority), one bit Canonical Format Indicator (CFI) that ensures compatibility between Ethernet and Token Ring, and 12 bits for the VLAN ID. This VLAN tag 313 is followed by the type field (EtherType) 314 of the actual frame 310, which originally occupied the position of VLAN tag 313 and has a value other than 0x8100 (for example, 0x0800 for an IPv4 packet in the image).

[0047] The Type field (EtherType) 314 specifies the protocol used at the next higher layer within the user data. Values ​​are greater than 0x0600. The special value 0x8100, used to identify a VLAN tag 313, is reserved within the Type set. If a VLAN tag 313 is present, the subsequent Type field must not be 0x8100.

[0048] All fields described so far that lie between (and including) the destination MAC address 311 and (including) the type field 314 are also referred to collectively as "network participant-specific information" within the scope of this disclosure. The terms "network participant-specific frame information" or "network participant-specific frame data" may also be used synonymously.

[0049] Following the type field 314, the payload data 315 is encoded in data blocks. A maximum of 1500 bytes of payload data can be transmitted per data block. The payload data 315 is interpreted by the protocol specified under Type. The data bytes are sent in ascending byte order.

[0050] The PAD field 316 is used to reduce the Ethernet frame 310 to the required minimum size of 64 bytes. The FCS field 317 (Frame Check Sum) represents a 32-bit CRC checksum. The FCS is calculated over the actual frame 310, starting with the destination MAC address 311 and ending with the PAD field 316.

[0051] As mentioned earlier, 10BASE-T1S offers collision avoidance at the physical layer (i.e., OSI layer 1), namely the so-called PLCA: Physical Layer Collision Avoidance. This is a component of the Ethernet Reconciliation Sublayer, which is located between OSI layers 1 and 2. The Reconciliation Sublayer is typically situated between the physical layer (i.e., OSI layer 1) and the MAC sublayer (Media Access Control, layer 2a).

[0052] The purpose of PLCA is to avoid collisions in the shared medium and the associated overhead of retransmission. Essentially, PLCA establishes a transmission cycle to choreograph transmit opportunities (TOs) on bus 100. Just as with a group of individuals, nothing would be heard properly if all participants spoke chaotically at once. A PLCA transmit cycle establishes the speaking opportunities and the order in which participants speak, but allows enough flexibility so that no time is wasted waiting for those who have nothing to say.

[0053] In PLCA, each node (also called PHY or PHY device), including the innovative device 110, is assigned a unique ID, the so-called PHY ID. Only the PHY device that currently has a transmission opportunity (TO) is permitted to send data. Transmission opportunities (TOs) are assigned using a round-robin algorithm, starting with PHY ID = 0, which is assigned to the bus master or PLCA coordinator. Nodes can generally only initiate a transmission during a transmission opportunity (TO) that corresponds to their own ID. The start of a new PLCA cycle is always signaled by the bus master with a synchronization pattern, also known as a beacon.

[0054] Fig. Figure 4 shows a schematic view of a PLCA cycle. The PLCA cycle itself includes the aforementioned beacon signal 410, which signals the start of the PLCA cycle, followed by N+1 time slots 4110, 4111, ..., 411 N, which allow N+1 variable-sized data packets to be sent. Within the context of this disclosure, the time slots are also referred to as transmit opportunities (TO) or transmission times.

[0055] During its transmit time (TO), a PHY 110 can immediately send a data packet 413 or must send a COMMIT pattern 412 of SYNC symbols to compensate for any MAC latency and gain additional time before sending a packet 413. If the node does not wish to send data, it can also send a SILENCE pattern 414 during its time slot 4110, 4111, ..., 411. N transmitted.

[0056] A node can assign its time slot 4110, 4111, ..., 411 NThe number of nodes increases to accommodate larger transmissions, and high-priority messages can be sent earlier. The other nodes wait until a sending node has completed its transmission before another node begins a transmission with the next available transmission opportunity (TO). A new time slot is 4110, 4111, ..., 411 N It begins at the end of a packet transmission, or if nothing is transmitted within a certain time, also known as TO_TIMER 415.

[0057] At the beginning of each transmission cycle, the transmission opportunity (TO) is first assigned to the node with PHY-ID = 1 on bus 100. If there is no data to transmit for this node and it cannot perform a COMMIT 412, it passes its transmission opportunity (TO) to the next node on bus 100.

[0058] To better understand the PLCA cycle, it can be helpful to imagine the use of a variable delay line 420 to allocate 100 transmission times (TOs) to each node on the bus. The PLCA timing scheme involves synchronizing the aforementioned TO_TIMERs 415 so that the maximum latency remains constant at less than one PLCA cycle. A TO_TIMER 415 is very short (typically 20 bits), so there is negligible throughput loss when waiting for PHYs that have nothing to transmit.

[0059] For example, in the upper left corner Fig. Figure 4 depicts a PLCA cycle with minimal latency ('MIN PLCA cycle') in which no one has anything to send, so the total latency is simply the number of nodes multiplied by TO_TIMER. In the subsequent second PLCA cycle, only the nodes with PHY-ID = 1 and PHY-ID = 3 have anything to send, so all other nodes relinquish their sending opportunity (TO).

[0060] The lower section in Fig. Figure 4, however, shows a PLCA cycle with maximum latency. Each node uses the maximum size for a data packet and sends a COMMIT 412 while waiting for the MAC.

[0061] The advantage of PLCA is that each node independently tracks the TO_TIMER 415 after the BEACON 410. Since nodes that have no data to transmit abandon their transmission opportunity (TO), the short time window provided by the TO_TIMER 415 ensures minimal throughput loss or latency increase. This variable delay is similar to the concept of TDMA (Time Division Multiple Access), but PLCA is not a fixed or absolute reference point for time-bound packets; instead, it adapts to the transmission needs of each node on the bus.

[0062] In summary, the operating principle of PLCA is to dynamically create transmit opportunities (TOs) so that at any given time only one network participant is allowed to send a packet over the medium. Each network participant is assigned a unique ID for this purpose. The network participant with ID = 0 is the PLCA coordinator or bus master. It begins a cycle by sending a BEACON signal (a kind of heartbeat signal) 410 onto the line, thereby first acknowledging its own transmit opportunity (TO).

[0063] If the PLCA coordinator with ID = 0 has no data to transmit, the transmission opportunity (TO) is released after 20 bit times (TO_TIMER), and the next network participant with ID = 1 receives its transmission opportunity (TO). Otherwise, the PLCA coordinator retains the transmission opportunity (TO) until a packet has been transmitted.

[0064] A new cycle is always started by the bus master or PLCA coordinator when the last network participant on the multidrop bus 100 has received its transmit opportunity (TO), regardless of whether it ultimately discarded its transmit opportunity (TO) or used it for data transmission.

[0065] As mentioned earlier, PLCA is a component of the Ethernet Reconciliation Sublayer, which is typically located between the Physical Layer (OSI Layer 1) and the MAC Layer (OSI Layer 2). The Reconciliation Sublayer automatically detects when a node has data to transmit. If the MAC contains data to be transmitted, the Reconciliation Sublayer postpones the transmission until a transmission opportunity (TO) arises.

[0066] In summary, the PLCA has the following characteristics: • The nodes (PHYs) are assigned statically unique IDs [0... N]. • The node with ID = 0 is the bus master or PLCA coordinator. ◯ It sends a BEACON signal to signal the start of a PLCA cycle and to allow other nodes to synchronize their TO_TIMER. • A PLCA cycle consists of a BEACON and N+1 subsequent transmit opportunities (TO), which allows N+1 variable-sized data packets to be sent. ◯ Nodes can only begin their transmission within their assigned transmission opportunity (TO), the number of which corresponds to their own node ID. ◯ A new transmission opportunity (TO) begins if nothing is transmitted during the TO_TIMER, or at the end of a packet transmission. ◯ Nodes can send a COMMIT pattern within their transmit opportunity (TO) to balance MAC latencies before sending a packet.

[0067] The device 110 according to the invention can now use all these properties to check the authenticity of a received Ethernet frame 310 originating from another network participant 105, 120, 130, 140 by comparing the received Ethernet frame 310 and its transmission time (TO) against each other.

[0068] As mentioned earlier, every Ethernet frame 310 sent by a network participant contains participant-specific information that is unique and exclusively attributable to that one network participant. This includes, among other things, the source MAC address SA, the destination MAC address DA, the VLAN tag including one or more of its components, such as the VLAN ID, or the Ethertype. The source MAC address is unique. The remaining information, especially in combination with the source MAC address, can also become unique and thus further classify the content of the Ethernet frame 310.

[0069] This network participant-specific information is therefore explicitly not the user data transmitted in Ethernet frame 310, but at least one of the following frame segments: • Source MAC address, • Destination MAC address, • VLAN tag including one or more of the pieces of information it contains, such as the VLAN ID, and • Ethertype.

[0070] If the PLCA described above is used, each network participant 105, 110, 120, 130, 140 can also receive an exclusively reserved network participant-specific transmit opportunity (TO).

[0071] An Ethernet frame 310 sent by a network participant 105, 110, 120, 130, or 140 contains information that should only be sent by that specific network participant and no other network participant. Each network participant has a specific ID (PHY ID) and a corresponding relative time slot or transmission opportunity (TO) during which each network participant 105, 110, 120, 130, or 140 is exclusively permitted to transmit.

[0072] The innovative device 110 can now, for example, combine the PLCA information, such as the transmit opportunity (TO) derivable via the PHY ID, with the network participant-specific information contained in the Ethernet frame 310 (such as SA / DA / VLAN tag / Ethertype, etc.) in order to match the Ethernet data frame 310 with the transmit opportunity (TO) to which the Ethernet data frame 310 was transmitted.

[0073] If a network participant, such as the innovative device 110, identifies information on the multidrop bus 100 that was sent in a time slot exclusively reserved for itself, or by another network participant in an incorrect time slot for that participant, the device 110 can corrupt the corresponding Ethernet frame 310 on the physical bus 100 in such a way that none of the other network participants connected to the multidrop bus 100 can evaluate the Ethernet frame 310 and the information it contains as valid at OSI layer 1.

[0074] According to exemplary embodiments, the innovative monitoring unit (GUARD) 113 integrated in the device 110 for this purpose can be designed to compare the network participant-specific information contained in the Ethernet frame 310 (such as SA / DA / VLAN tag / Ethertype, etc.) with the network participant-specific transmission opportunity (TO) for the purpose of verifying the authenticity of a received Ethernet frame 310.

[0075] The comparison can be performed either using an acceptance list or a blocking list. According to one conceivable embodiment, the monitoring unit (GUARD) 113 integrated in the device 110 can be configured to compare the network participant-specific information contained in the received Ethernet frame 310 (such as SA / DA / VLAN tag / Ethertype, etc.) and the network participant-specific send time (TO) with an acceptance list containing at least the send time (TO) and at least one of the following list entries: • the source MAC address, and / or • the destination MAC address, and / or • the VLAN tag including one or more of the pieces of information it contains, such as the VLAN ID, and / or • the ether type.

[0076] The monitoring unit (GUARD) 113 can be configured to authenticate the received Ethernet frame 310 precisely when both the network participant-specific transmission time (TO) of the received Ethernet frame 310 and the network participant-specific information contained in the received Ethernet frame 310 (such as SA / DA / VLAN tag / Ethertype, etc.) match the list entries in the acceptance list.

[0077] In a second conceivable embodiment, the monitoring unit (GUARD) 113 integrated in the device 110 can be configured to compare the network participant-specific information (such as SA / DA / VLAN tag / Ethertype, etc.) contained in the received Ethernet frame 310 and the network participant-specific send time (TO) with a block list containing at least the send time (TO) and at least one of the following list entries: • the source MAC address, and / or • the destination MAC address, and / or • the VLAN tag including one or more of the pieces of information it contains, such as the VLAN ID, and / or • the ether type.

[0078] The monitoring unit (GUARD) 113 can be configured to not identify the received Ethernet frame 310 as authentic if and only if the network participant-specific transmission time (TO) of the received Ethernet frame 310 and / or the network participant-specific information contained in the received Ethernet frame 310 (such as SA / DA / VLAN tag / Ethertype, etc.) match at least one of the list entries from the block list.

[0079] Network participant-specific information, such as SA / DA / VLAN tag / Ethertype, etc., is contained within Ethernet frame 310 itself and can therefore be directly determined from it. The network participant-specific transmit opportunity (TO), on the other hand, can be queried via the PLCA state machine integrated into the PLCA component.

[0080] As described at the beginning, the PLCA state information, such as the PHY ID or the network participant-specific transmit opportunity (TO) that can be derived from it, is available locally in the component in which the PLCA is implemented, which is usually the Reconciliation Sublayer located within the physical layer.

[0081] The Fig. 5A and Fig. Figure 5B shows the hierarchical arrangement of the Reconciliation Sublayer 114 with the PLCA integrated therein. Fig. Figure 5A initially shows a standard stack, where the Reconciliation Sublayer 114, including the integrated PLCA, is integrated into the physical layer, i.e., OSI layer 1. Above this is the MAC Sublayer 115 as sublayer 2b of the data link layer, or OSI layer 2.

[0082] Fig. Figure 5B shows a stack in which the innovative monitoring unit (GUARD) 113 is integrated. The monitoring unit (GUARD) 113 can preferably be implemented at the physical layer, i.e., at OSI layer 1. In a possible configuration, as shown here purely as an example, the monitoring unit (GUARD) 113 can optionally be implemented together with the reconciliation sublayer 114 and / or the PLCA integrated therein. Here too, the MAC sublayer 115 is located above the reconciliation sublayer 114 as sublayer 2b of the data link layer, or OSI layer 2.

[0083] The monitoring unit (GUARD) 113 can also be located between the Physical Coding Sublayer (PCS) 116 and the Physical Medium Attachment Sublayer (PMA) 117. It is also conceivable that the monitoring unit (GUARD) 113 is located between the Physical Medium Attachment Sublayer (PMA) 117 and the Physical Medium Dependent (PMD) Transceiver 118. PMD is simply a convention within the 10BASE-T1S standard. More generally, the transceiver 118 can be an analog interface that functions as a level converter.

[0084] Regardless of the exact placement of the GUARD 113 in the standard stack, real-world 10BASE-T1S implementations offer several possibilities for implementing the innovative GUARD 113 in a network participant, such as the innovative device 110. As mentioned earlier, the OSI layers can be integrated into different, independent physical components of a network participant, such as the innovative device 110.

[0085] In the following Fig. Figures 6A to 6D show, purely by way of example, two component parts 601, 601 that can be provided within the device 110. Fig. 6A and Fig. Figure 6B shows different possibilities in which of the two component parts 601, 602 the OSI layer 1, which contains the physical interface (PHY) 111, and the OSI layer 2, which contains the process unit (µC) 112, can be integrated.

[0086] The innovative device 110 can of course have further component parts (not explicitly shown here) in which, for example, higher OSI layers are integrated.

[0087] Fig. Figure 6A shows a first conceivable implementation example, where the monitoring unit (GUARD) 113 is implemented in a first component 601, which also contains the physical interface 111 on OSI layer 1. Optionally, a reconciliation sublayer with integrated PLCA 114 and / or a MAC sublayer 115 can also be implemented in the first component 601. The processing unit (µC) 112 on OSI layer 2 can be implemented in a second component 602. Communication between the first component 601 and the second component 602 can be achieved, for example, via SPI (Serial Peripheral Interface).

[0088] This form of implementation offers the advantage that no change to the process unit (µC) 112 is necessary, so that, for example, any process unit (µC) 112 that is able to communicate via the communication interface used (e.g. SPI) can also use the innovative GUARD concept.

[0089] Fig. Figure 6B shows a second possible implementation example, where the monitoring unit (GUARD) 113 is again implemented in the first component 601, which also contains the physical interface 111 at OSI layer 1. Optionally, a reconciliation sublayer with integrated PLCA 114 can also be implemented in the first component 601. Furthermore, an MAC sublayer 115 can optionally be implemented in the second component 602, which also contains the processing unit (µC) 112 at OSI layer 2. Communication between the first component 601 and the second component 602 can be achieved, for example, using any xMII (Media Independent Interface).

[0090] This form of implementation offers the advantage that no change to the process unit (µC) 112 is necessary, so that, for example, any process unit (µC) 112 that is able to communicate via the communication interface used (e.g. xMII) can also use the innovative GUARD concept.

[0091] Fig. Figure 6C shows a second possible implementation example, where the monitoring unit (GUARD) 113 is implemented in the second component 602, which also contains the processing unit (µC) 112 at OSI layer 2. Additionally, a reconciliation sublayer with integrated PLCA 114 and / or a MAC sublayer 115 and / or at least one of the following network protocol layers can optionally be implemented in the second component 602: • a media access control layer (MAC) 115, • a Physical Coding Sublayer (PCS) 116, • a Physical Medium Attachment Sublayer (PMA) 117.

[0092] The first component 601 can have any analog interface, such as a Physical Medium Dependent (PMD) transceiver 118, in addition to the physical interface (PHY) 111 on OSI layer 1. Communication between the first component 601 and the second component 602 can be effected, for example, via three pins (Tx |Rx| ED).

[0093] This form of implementation offers the advantage of complete integration into the process unit (µC) 112. Bus access can be achieved using a very simple and cost-effective transceiver 118, as no logic is required on the side of the physical interface (PHY) 111.

[0094] Fig. Figure 6D shows a second possible implementation example, where the monitoring unit (GUARD) 113 is implemented together with the Physical Medium Dependent (PMD) transceiver 118 in the first component 601. The second component 602, which also includes the processing unit (µC) 112 at OSI layer 2, can optionally also integrate a reconciliation sublayer with integrated PLCA 114 and / or a MAC sublayer 115 of OSI layer 2.

[0095] The second component 602 can also contain one or more sub-layers of OSI layer 1, such as the Physical Medium Attachment Sublayer (PMA) 117 and / or the Physical Coding Sublayer (PCS) 116. Communication between the first component 601 and the second component 602 can be achieved, for example, via three pins (Tx | Rx | ED).

[0096] This form of implementation offers the advantage of complete integration into the process unit (µC) 112. Bus access can be achieved using a very simple and cost-effective analog frontend, such as a transceiver 118.

[0097] Another option, not explicitly shown here, is the complete integration of all functions into a single component or device.

[0098] As mentioned at the beginning, the monitoring unit (GUARD) 113 is designed to corrupt the received Ethernet frame 310 on the physical bus 100 if a lack of authenticity is detected, so that no other network participant recognizes this Ethernet frame 310 as valid at the physical layer (OSI layer 1).

[0099] One embodiment provides that the monitoring unit (GUARD) 113 can be configured to corrupt the received Ethernet frame 310 on the physical bus 100 in case of inauthenticity by generating physical collisions on the bus medium. A physical collision should be generated immediately, i.e., at the latest at the next possible transmission opportunity (TO).

[0100] For example, physical collisions can be generated using the CSMA / CD algorithm (Carrier Sense Multiple Access with Collision Detection) provided by Ethernet. To ensure that a usable collision is generated, a collision pattern with a length of at least 32 bits should be used.

[0101] Furthermore, it is advantageous if a collision pattern generated for a collision is not equal to the frame checksum (FCS) of the already transmitted fragment of the Ethernet frame 310 to be corrupted. Optionally, the monitoring unit (GUARD) 113 can have a collision counter configured to increment its counter value by one digit for each generated collision.

[0102] The following are, with reference to the Fig. 7 and Fig. Eight different scenarios are described that can be detected by means of an innovative monitoring unit (GUARD) 113 in an Ethernet-based half-duplex multidrop bus system 100. In both figures, the previously mentioned scenario is shown with reference to Fig. 1. The described bus system 10 serves to clarify the hardware components, and secondly, the one described previously, with reference to Fig. Figure 4 illustrates the PLCA cycle used to describe the functional level. Elements with the same or similar function are marked with the same reference symbols as in the previous figures.

[0103] Fig. Figure 7 shows a possible embodiment in which the innovative device is configured as a bus master or PLCA coordinator, such as switch 105. One or more network participants 110, 120, 130, 140, in the form of bus slaves, such as ECUs, can be connected to switch 105.

[0104] Device 105 can include a previously described PLCA component (not explicitly shown here), whereby each network participant 105, 110, 120, 130, 140 is assigned a sequential, unique PHY ID. In the example shown here, switch 105, as the PLCA coordinator, would have the ID = 0.

[0105] The first ECU 110, for example, receives ID = 1, followed by the second ECU 120 with ID = 2, then the third ECU 130 with ID = 3, which is in turn followed by the fourth ECU 140 with ID = 4. All IDs are also listed on the left side of the image in box 701.

[0106] As previously described, in PLCA each ID is linked to a transmission time (TO) exclusively reserved for the corresponding network participant 105, 110, 120, 130, 140, so that each network participant 105, 110, 120, 130, 140 can only transmit on bus 100 at one defined transmission opportunity (TO) exclusively reserved for it.

[0107] As in Fig. As shown in Figure 7, the innovative device in the form of the switch 105, as the sole network participant, features a monitoring unit (GUARD) 113 according to the innovative concept presented herein. This means that the other network participants, in the form of the bus slaves or ECUs 110, 120, 130, and 140, all lack a monitoring unit (GUARD) 113.

[0108] Nevertheless, with such a configuration it is possible to identify forged Ethernet data frames 310 as well as forged or unauthorized network participants using the innovative monitoring unit (GUARD) 113. In the embodiment shown here, both the multidrop bus 100 and the core network located behind the switch 105 can be protected.

[0109] As previously described, the monitoring unit 113 can be configured to detect network participant-specific information contained in a received Ethernet data frame 310, such as... • the source MAC address (SA), and / or • the destination MAC address (DA), and / or • the VLAN tag including one or more of the pieces of information it contains, such as the VLAN ID, and / or • to compare the Ether type with the network participant-specific send time (TO). The send time (TO) of the received Ethernet frame 310 can be determined, for example, using the sequential unique ID of the sending network participant. That is, if the device 105 receives an Ethernet data frame 310 at a send time (TO) associated with ID = 1, the device 105 knows that this Ethernet data frame 310 must originate from the network participant 110. Otherwise, the device 110 corrupts this Ethernet data frame 310 on the physical bus 100.

[0110] In the Fig. The 7 illustrated and non-limiting examples show, for each ID (see Box 701), a purely exemplary source MAC address SA (Box 702) and a purely exemplary destination MAC address DA (Box 703) are given.

[0111] In the example scenario shown at the top right (Box 710), the device 105 receives, for example, an Ethernet data frame that was sent during one of the fourth transmit opportunity (TO) 4114 assigned to the ECU 140, which the device 105 can in turn deduce from the unique ID = 4.

[0112] As indicated in Box 710, the received Ethernet frame contains the source MAC address SA: 00:00:01:00:00:05, which correctly corresponds to the fourth ECU 140 with ID = 4 (see Boxes 701 and 702). However, the received Ethernet frame contains a destination MAC address DA: 00:00:04:00:00:03 (see Box 710), which does not match the destination address DA: 00:00:04:00:00:05 stored for the fourth ECU 140 (e.g., in an acceptance list or block list) (see Boxes 701 and 703). Therefore, the received Ethernet data frame can be identified as inauthentic and corrupted.

[0113] According to such an embodiment, an Ethernet frame received from another network participant 140 may initially have been correctly transmitted at a transmission time (TO) exclusively reserved for that other network participant 140. Nevertheless, the monitoring unit (GUARD) 113 can identify the forged Ethernet frame as inauthentic by comparing the network participant-specific information contained in the received Ethernet frame, such as SA / DA / VLAN tag / Ethertype, etc., with the transmission time (TO). If the network participant-specific information does not match the transmission time (TO), as in this case, the monitoring unit (GUARD) 113 can identify the Ethernet frame originating from the other network participant 140 as inauthentic and corrupt it on the physical bus 100, for example, by intentionally creating a collision using CSMA / CD.

[0114] In the second example scenario given in Box 711, for example, the device 105 again receives an Ethernet data frame that was sent in one of the fourth transmit opportunity (TO) 4114 assigned to ECU 140, which can again be deduced from the unique ID = 4.

[0115] The received Ethernet frame contains the source MAC address SA: 00:00:01:00:00:01 and the destination MAC address DA: 00:00:04:00:00:03 (see Box 711). As can be seen in Boxes 702 and 703, neither the source MAC address nor the destination MAC address in the Ethernet frame matches the source and destination MAC addresses associated with ID = 4. Instead, the source and destination MAC addresses in the Ethernet frame (see Box 711) are associated with ID = 0. This means that this Ethernet frame should have originated from the bus master, i.e., from the innovative device 105. However, since device 105 is equipped with the innovative monitoring unit (GUARD) 113, it can detect that this Ethernet frame did not originate from itself. Thus, the device 105 can identify the received Ethernet frame as inauthentic and corrupt it.

[0116] According to such an embodiment, it is conceivable that a received Ethernet frame 310 originating from another network participant 140 was sent at a transmission time (TO) exclusively reserved for the device 105 itself. In this case, the monitoring unit 113 can recognize the transmission time (TO) of the received Ethernet frame 310 as its own transmission time (TO) and, based on this, identify the Ethernet frame 310 originating from the other network participant 140 as inauthentic, even if the received Ethernet frame 310 otherwise contains the correct network participant-specific information associated with this transmission time (TO), such as SA / DA / VLAN tag / Ethertype, etc.

[0117] Box 712 shows a third example scenario of a fake Ethernet frame, which is linked to the one in Fig. However, the configuration outlined in section 7 cannot be reliably identified. In this example scenario, device 105 receives an Ethernet frame from the first ECU 110 with ID = 1. The Ethernet frame was correctly sent at the transmission time (TO) 4111, which corresponds to ID = 1.

[0118] The received Ethernet frame contains the source MAC address SA: 00:00:01:00:00:02 and the destination MAC address DA: 00:00:04:00:00:10 (see Box 712). As shown in Boxes 702 and 703, both the source MAC address and the destination MAC address contained in the Ethernet frame match the source and destination MAC addresses corresponding to ID = 1. This means that an Ethernet frame that was sent at the correct time of transmission (TO) corresponding to a specific ID and contains the correct network participant-specific information for that ID, such as SA / DA / VLAN tag / Ethertype, etc., can be received by the device shown in the diagram. Fig. The configuration shown in section 7 cannot be reliably detected.

[0119] Fig. Figure 8 shows another possible configuration that makes it possible to solve this problem (Box 712) as well. In addition to the bus master 105 (switch), all other bus slaves (ECUs) 110, 120, 130, 140 in the multidrop bus system 100 each have their own monitoring unit (GUARD) 113. For the following description of Fig. 8 It is assumed that the innovative device is designed here in the form of one of the bus slaves, e.g. in the form of the first ECU 110.

[0120] Otherwise, elements with the same or similar function are provided with the same reference symbols as in the previous figures. Furthermore, reference is made to the description above. Fig. 7 referred to. The example scenarios shown in boxes 710 and 711 also correspond to those previously mentioned, with reference to Fig. The 7 discussed example scenarios are consistent, therefore, to avoid repetition, reference is also made to the description above.

[0121] The third example scenario shown in Box 712 also matches the third example scenario above with respect to the source and destination MAC addresses transmitted in the Ethernet frame. That is, the fake Ethernet frame (Box 712) was initially correctly sent at the transmission time (TO) 4111, corresponding to ID = 1, and the source and destination MAC addresses contained in the Ethernet frame (see Box 712) also match the source and destination MAC addresses associated with ID = 1 (see Boxes 702 and 703).

[0122] The forged Ethernet frame was not sent by the first ECU 110, but by another network participant falsely claiming to be the first ECU 110. This forged Ethernet frame, originating from the "false" first ECU, can now be detected by the "real" first ECU 110 using its integrated, innovative monitoring unit (GUARD) 113, because the "real" first ECU 110 knows that this Ethernet data frame 310 did not originate from it.

[0123] According to such an embodiment, an Ethernet frame 310 originating from an incorrect network participant may have been correctly sent at a transmission time (TO) exclusively reserved for the innovative device (e.g., first ECU) 110. However, the monitoring unit (GUARD) 113 can recognize the transmission time (TO) of the received Ethernet frame 310 as its own transmission time (TO) and, based on this, identify the Ethernet frame 310 originating from the incorrect network participant as inauthentic, even if the received Ethernet frame 310 otherwise contains the correct network participant-specific information associated with that transmission time (TO), such as SA / DA / VLAN tag / Ethertype, etc.

[0124] With the in Fig. In the configuration shown in Figure 8, both the core network behind switch 105 and the multidrop bus system 100 itself can be protected against falsified messages on the multidrop bus system 100. Each network participant 105, 110, 120, 130, 140 can be individually protected by its own monitoring unit (GUARD) 113, thus also protecting the rest of the entire vehicle network.

[0125] With the in the Fig. 7 and Fig. The 8 configurations shown can therefore detect several scenarios: 1. An Ethernet frame identified by its network participant-specific data, such as SA / DA / VLAN tag / priority / Ethertype, etc., is sent during a false transmission opportunity (TO), i.e., one attributed to a different network participant: This scenario can be detected by the network participant who possesses the correct ID corresponding to the time of transmission (TO) of the Ethernet frame, using local knowledge. This scenario can also be recognized by all other network participants with additional network knowledge. 2. An Ethernet frame identified by its network participant-specific data, such as SA / DA / VLAN tag / priority / Ethertype, etc., is sent by the wrong network participant during the correct sending opportunity (TO): ◯ This scenario can be detected by the network participant who possesses the correct ID corresponding to the time of transmission (TO) of the Ethernet frame.

[0126] With reference to the Fig. 7 and Fig. Section 8 below describes a practical example to better illustrate the innovative concept and its practical benefits. It is assumed that the Ethernet-based Multidrop Bus System 100 is installed in a vehicle network and is compatible with the 10BASE-T1S Ethernet standard.

[0127] In this example, network participant 140 with ID = 4 is a headlight. Network participant 110 with ID = 1 is a control unit capable of gaining access to the vehicle.

[0128] The headlight, i.e., network participant 140, can easily be accessed externally by thieves. Thieves could attempt to access the bus system 100 by replacing network participant 140 or by connecting an additional fraudulent device to network participant 140 and thus coupling it into bus 100.

[0129] An Ethernet frame 310 sent by a fraudulent network participant can be detected by all GUARD devices 105, 110, 120, 130, 140, even if the Ethernet frame was sent at a send time (TO) reserved for the genuine network participant 140 with ID = 4.

[0130] This can be achieved by the monitoring unit (GUARD) 113 comparing the transmission time (TO) with, for example, the source MAC address associated with this ID = 4. If these data points do not match, the Ethernet frame is corrupted.

[0131] If the source MAC address is copied by the attacker, the source MAC address may match the source MAC address stored at ID = 4, but other network participant-specific data contained in the Ethernet frame, such as the destination MAC address, the VLAN tag including one or more of the information it contains, such as the VLAN ID, or the Ethertype (or other parts) of the Ethernet frame, may not match the send time (TO) associated with ID = 4.

[0132] Furthermore, fake Ethernet frames sent by another fake network participant during the off-peak (TO) times of the real network participant 110 can be detected by the real network participant 110.

[0133] The attacker would therefore have to gain physical access to the real network participant 110, or interrupt the connection to the real network participant 110.

[0134] Fig. Figure 9 shows a schematic block diagram of an innovative method for authenticating Ethernet frames 310 in an Ethernet-based half-duplex multidrop bus system 100. The individual process steps can also be executed in a different order than shown.

[0135] Block 901 includes receiving and sending Ethernet frames 310 at the physical layer level (OSI layer 1) via a physical interface 111, wherein an Ethernet frame 310 is only sent via the physical interface 111 at a time specified and exclusively reserved by a bus master.

[0136] Block 902 includes the processing of the Ethernet frames 310 at the data link layer level (OSI layer 2) by means of a process unit 112.

[0137] Block 903 involves verifying the authenticity of a received Ethernet frame 310 originating from another network participant 140 by comparing the received Ethernet frame 310 with its transmission time (TO).

[0138] In the event of a detected lack of authenticity, the procedure proceeds to block 904. This includes a further step according to which the received Ethernet frame 310 is corrupted on the physical multidrop bus 100 so that no other network participant 120, 130 recognizes this Ethernet frame 310 as valid at the physical layer (OSI layer 1).

[0139] In summary, it can be stated that the innovative GUARD concept presented here offers a way to verify the authenticity of Ethernet frames 310 at the physical layer, i.e., at OSI layer 1.

[0140] Network participants can have specific transmission opportunities (TOs), which correspond to a relative time at which a network participant is permitted to send data or Ethernet frames. Knowing which network participant is permitted to transmit at a particular transmission opportunity (TO) can be used to identify fraudulent network traffic.

[0141] The processes carried out can be divided into detection and the action to be performed. Recognition:

[0142] GUARD is a function that combines filtering based on network participant-specific information available in Ethernet frames 310 with physical layer status information (provided by PLCA).

[0143] GUARD network participants can identify other devices that are transmitting during the GUARD network participant's own transmit opportunity (TO).

[0144] GUARD identifies Ethernet frames based on the network participant-specific information they contain, such as SA / DA / VLAN tag / priority / EtherType, etc., which were sent during a false transmit opportunity (TO) by another network participant. Action:

[0145] GUARD uses the above knowledge to filter received Ethernet frames (locally).

[0146] GUARD uses the CSMA / CD characteristic of Ethernet to generate physical collisions when an error is detected, in order to protect other network participants.

[0147] The innovative GUARD concept therefore offers the following advantages: • GUARD offers protection based on existing information • GUARD requires no additional information on the line and no changes to the protocols on the line. • GUARD is compatible with standard Ethernet communication and supports all protocols • GUARD requires no calculations in software • GUARD requires only hardware support • GUARD operates on the lowest OSI layer (i.e., OSI layer 1) • GUARD offers a solution with lower costs and lower power consumption than existing security protocols at higher OSI layers (OSI layer 2 and above) in 10BASE-T1S, and also provides a simple way of protecting against spoofing. • GUARD is therefore a particularly attractive solution for small sensors and actuators. • GUARD eliminates fake “rogue frames” before they can enter the rest of the core network.

[0148] The embodiments described above merely illustrate the principles of the innovative concept described herein. It is understood that modifications and variations of the arrangements and details described herein will be obvious to other people skilled in the art. Therefore, it is intended that the concept described herein be limited only by the scope of protection set forth in the following patent claims and not by the specific details presented herein by way of description and explanation of the embodiments.

[0149] Although some aspects have been described in connection with a device, it is understood that these aspects also constitute a description of the corresponding process, so that a block or component of a device is also to be understood as a corresponding process step or as a feature of a process step. Similarly, aspects described in connection with or as a process step also constitute a description of a corresponding block, detail, or feature of a corresponding device.

[0150] Some or all of the process steps can be performed by (or using) a hardware apparatus, such as a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, some or more of the key process steps can be performed by such an apparatus.

[0151] Depending on specific implementation requirements, exemplary embodiments can be implemented in hardware or software, or at least partially in hardware or at least partially in software. The implementation can be carried out using a digital storage medium, such as a floppy disk, DVD, Blu-ray disc, CD, ROM, PROM, EPROM, EEPROM, FLASH memory, hard disk, or other magnetic or optical storage medium, on which electronically readable control signals are stored. These signals can interact with, or interact with, a programmable computer system in such a way as to execute the respective method. Therefore, the digital storage medium can be computer-readable.

[0152] Some embodiments therefore include a data carrier that has electronically readable control signals capable of interacting with a programmable computer system in such a way as to carry out one of the methods described herein.

[0153] In general, embodiments can be implemented as a computer program product with a program code, wherein the program code is effective in carrying out one of the methods when the computer program product runs on a computer.

[0154] The program code can also be stored on a machine-readable medium, for example.

[0155] Other embodiments include a computer program for performing one of the methods described herein, wherein the computer program is stored on a machine-readable medium. In other words, an embodiment of the method described herein is a computer program that includes program code for performing one of the methods described herein when the computer program is executed on a computer.

[0156] Another embodiment of the method described herein is a data carrier (or a digital storage medium or a computer-readable medium) on which the computer program for carrying out one of the methods described herein is recorded. The data carrier, digital storage medium, or computer-readable medium is typically tangible and / or non-volatile.

[0157] Another embodiment of the method described herein is a data stream or a sequence of signals that represents the computer program for carrying out one of the methods described herein. The data stream or sequence of signals can be configured, for example, to be transferred via a data communication connection, such as the Internet.

[0158] Another embodiment comprises a processing device, for example a computer or a programmable logic device, which is configured or adapted to perform one of the methods described herein.

[0159] Another embodiment comprises a computer on which the computer program for performing one of the procedures described herein is installed.

[0160] Another embodiment comprises a device or system designed to transmit a computer program for carrying out at least one of the methods described herein to a receiver. The transmission can be, for example, electronic or optical. The receiver can be, for example, a computer, a mobile device, a storage device, or a similar device. The device or system can, for example, include a file server for transmitting the computer program to the receiver.

[0161] In some embodiments, a programmable logic device (for example, a field-programmable gate array, an FPGA) can be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field-programmable gate array can interact with a microprocessor to perform one of the methods described herein. Generally, in some embodiments, the methods are performed by any hardware device. This can be general-purpose hardware such as a computer processor (CPU) or method-specific hardware such as an ASIC.

Claims

[1] Device (105, 110) for secure communication in an Ethernet-based half-duplex multidrop bus system (100), wherein the device (105, 110) has the following features: a physical interface (111) for receiving and sending Ethernet frames (310) at the physical layer (OSI layer 1), a process unit (112) for processing the Ethernet frames (310) at the data link layer level (OSI layer 2), wherein the device (105, 110) is configured to send an Ethernet frame (310) via the physical interface (111) only at a transmission time (TO) specified and exclusively reserved by a bus master, and a monitoring unit (113) designed to verify the authenticity of a received Ethernet frame (310) originating from another network participant (140) by comparing the received Ethernet frame (310) and its transmission time (TO), and wherein the monitoring unit (113) is designed to corrupt the received Ethernet frame (310) on the physical bus (100) in the event of a detected lack of authenticity, so that none of the other network participants (120, 130) recognize this Ethernet frame (310) as valid at the physical layer (OSI layer 1). [2] Device (105, 110) according to claim 1, wherein each Ethernet frame (310) sent by a network participant (105, 110, 120, 130, 140) contains network participant-specific information that is uniquely and exclusively assigned to that one network participant, and wherein each network participant (105, 110, 120, 130, 140) has an exclusively reserved network participant-specific transmit time (TO), and wherein the monitoring unit (113) is designed to compare the network participant-specific information contained in the Ethernet frame (310) with the network participant-specific transmission time (TO) for the purpose of verifying the authenticity of the received Ethernet frame (310). [3] Device (105, 110) according to claim 2, wherein the network participant-specific information is not the user data transmitted in the Ethernet frame (310), but at least one of the following frame segments: • Source MAC address, • Destination MAC address, • VLAN tag including one or more of the pieces of information it contains, and • Ethertype. [4] Device (105, 110) according to claim 2 or 3, wherein the monitoring unit (113) is designed to compare the network participant-specific information contained in the received Ethernet frame (310) and the network participant-specific transmit time (TO) with an acceptance list containing at least the following list entries: • Time of broadcast (TO), and • Source MAC address, and / or • Destination MAC address, and / or • VLAN tag including one or more of the pieces of information contained therein, and / or • Ethertype, and wherein the monitoring unit (113) is designed to authenticate the received Ethernet frame (310) if and only if both the network subscriber-specific transmit time (TO) of the received Ethernet frame (310) and the network subscriber-specific information contained in the received Ethernet frame (310) match the list entries in the acceptance list. [5] Device (105, 110) according to claim 3 or 4, wherein the monitoring unit (113) is designed to compare the network participant-specific information contained in the received Ethernet frame (310) and the network participant-specific transmit time (TO) with a block list containing at least the following list entries: • Time of broadcast (TO), and • Source MAC address, and / or • Destination MAC address, and / or • VLAN tag including one or more of the pieces of information contained therein, and / or • Ethertype, and wherein the monitoring unit (113) is designed to not identify the received Ethernet frame (310) as authentic if and only if the network subscriber-specific transmit time (TO) of the received Ethernet frame (310) and / or the network subscriber-specific information contained in the received Ethernet frame (310) matches at least one of the list entries from the block list. [6] Device (105, 110) according to one of the preceding claims, wherein the monitoring unit (113) is configured to corrupt the received Ethernet frame (310) on the physical bus (100) in case of lack of authenticity by generating physical collisions on the bus medium. [7] Device (105, 110) according to claim 6, wherein the physical collisions are generated using the CSMA / CD algorithm provided by Ethernet. [8] Device (105, 110) according to claim 7, wherein a collision pattern generated for a collision is not equal to the frame checksum of the already transmitted fragment of the Ethernet frame (310) to be corrupted. [9] Device (105, 110) according to claim 7 or 8, wherein a collision pattern has a length of at least 32 bits. [10] Device (105, 110) according to one of claims 7 to 9, wherein the monitoring unit (113) has a collision counter configured to increment its counter value by one digit for each generated collision. [11] Device (105, 110) according to one of the preceding claims, wherein the monitoring unit (113) is implemented in the physical interface (111). [12] Device (105, 110) according to claim 11, wherein a media access control layer (115) is implemented in the physical interface (111). [13] Device (105, 110) according to claim 11 or 12, wherein a PLCA component (114) is implemented in the physical interface (111). [14] Device (105, 110) according to claim 13, wherein the monitoring unit (113) is integrated with the PLCA component. [15] Device (105, 110) according to one of claims 1 to 10, wherein the monitoring unit (113) is implemented in the process unit (112). [16] Device (105, 110) according to claim 15, wherein a PLCA component (114) is implemented in the process unit (112). [17] Device (105, 110) according to claim 16, wherein the monitoring unit (113) is integrated with the PLCA component. [18] Device (105, 110) according to one of claims 15 to 17, wherein at least one of the following network protocol layers is implemented in the process unit (112): • a media access control layer (MAC), • a Physical Coding Sublayer (PCS), • a Physical Medium Attachment Sublayer (PMA). [19] Device (105, 110) according to one of the preceding claims, wherein the half-duplex multidrop bus system (100) is based on the 10Base-T1S Ethernet standard. [20] Device (105, 110) according to one of the preceding claims, wherein the device (105, 110) has a PLCA component (PLCA: Physical Level Collision Avoidance), wherein each network participant (105, 110, 120, 130, 140) has a sequential unique ID which is linked to the transmit time (TO) exclusively reserved for the corresponding network participant (105, 110, 120, 130, 140), and wherein the monitoring unit (113) is designed to determine the transmission time (TO) of the received Ethernet frame (310) originating from the other network participant (140) based on the sequential unique ID of the other network participant (140). [21] Device (105, 110) according to one of the preceding claims, wherein the device (105) is the bus master in the multidrop bus system (100) and has the monitoring unit (113) as the sole network participant. [22] Device (105, 110) according to claim 21, where the received Ethernet frame (310) originating from the other network participant (140) was correctly sent at a transmission time (TO) exclusively reserved for that other network participant (140), wherein the monitoring unit (113) is designed to compare the network participant-specific information contained in the received Ethernet frame (310) with the transmission time (TO) of the Ethernet frame (310), and to identify the received Ethernet frame (310) originating from the other network participant (140) as not authentic if the network participant-specific information contained therein does not match the transmission time (TO) of the Ethernet frame (310). [23] Device (105, 110) according to claim 20 or 21, wherein the received Ethernet frame (310) originating from the other network participant (140) was sent at a transmission time (TO) exclusively reserved for the device (105), and wherein the monitoring unit (113) is designed to recognize the transmission time (TO) of the received Ethernet frame (310) as its own transmission time (TO) and, based on this, to identify the received Ethernet frame (310) originating from the other network participant (140) as not authentic, even if the received Ethernet frame (310) otherwise contains the correct network participant-specific information associated with that transmission time (TO). [24] Device (110, 105) according to one of claims 1 to 20, wherein the device (110) is one of several bus slaves in the multidrop bus system (100), each having its own monitoring unit (113). [25] Device (110, 105) according to claim 24, wherein the bus master (105) in the multidrop bus system (100) also has its own monitoring unit (113). [26] Device (105, 110) according to claim 24 or 25, where the received Ethernet frame (310) originating from the other network participant (140) was correctly sent at a transmission time (TO) exclusively reserved for that other network participant (140), wherein the monitoring unit (113) integrated in the device (110) is designed to compare the network subscriber-specific information contained in the received Ethernet frame (310) with the transmission time (TO) of the Ethernet frame (310), and to identify the received Ethernet frame (310) originating from the other network participant (140) as not authentic if the network participant-specific information contained therein does not match the transmission time (TO) of the Ethernet frame (310). [27] Device (105, 110) according to one of claims 24 to 26, wherein the received Ethernet frame (310) originating from the other network participant was sent at a transmission time (TO) exclusively reserved for the device (110), and wherein the monitoring unit (113) is designed to recognize the transmission time (TO) of the received Ethernet frame (310) as its own transmission time (TO) and, based on this, to identify the received Ethernet frame (310) originating from the other network participant as not authentic, even if the received Ethernet frame (310) otherwise contains the correct network participant-specific information associated with that transmission time (TO). [28] Method for authenticating Ethernet frames (310) in an Ethernet-based half-duplex multidrop bus system (100), wherein the method comprises the following steps: Receiving and sending Ethernet frames (310) at the physical layer (OSI layer 1) via a physical interface (111), where an Ethernet frame (310) is only sent via the physical interface (111) at a transmission time (TO) specified and exclusively reserved by a bus master, and Processing the Ethernet frames (310) at the data link layer level (OSI layer 2) by means of a processing unit (112), Verifying the authenticity of a received Ethernet frame (310) originating from another network participant (140) by comparing the received Ethernet frame (310) with its transmission time (TO), and wherein, in the event of a detected lack of authenticity, the procedure includes a further step whereby the received Ethernet frame (310) is corrupted on the physical multidrop bus system (100) so that no other network participant (120, 130) recognizes this Ethernet frame (310) as valid at the physical layer (OSI layer 1). [29] Computer program comprising program code for carrying out the method according to claim 28, when the program runs on a computer.

Images