Method for protecting time synchronization in a network from unauthorized changes

Abstract

The present invention relates to a method for protecting network time synchronization from unauthorized modifications to a grandmaster clock in a reference time domain. The method comprises monitoring a network device's physical communication interfaces for the arrival of time synchronization-related messages disseminating information about the best clock in the network. If the time synchronization-related messages apply to an initially established and synchronized reference time domain, a check is performed to determine whether the time synchronization-related messages announce a new grandmaster clock with clock parameters that are better than those of the previous grandmaster clock. If so, the network device initiates a virtual reference time domain, sending only necessary requests and responses related to the virtual reference time domain and validating the clock parameters received in the time synchronization-related messages. If the verification indicates that the proposed new grandmaster clock is authentic or valid, the network device disconnects the virtual time domain, updates its stored information about the grandmaster clock, and, from that point on, sends time synchronization-related messages based on the new clock parameters to the network. Otherwise, the network device rejects the proposed new grandmaster clock as the new grandmaster clock for the reference time domain.

Description

Technical Field

[0001] The invention relates to a communication network having network devices that are time-synchronized with one another, in particular in the electrical system of a vehicle. Background Art

[0002] Ethernet technology is increasingly being adopted in vehicles to replace older or proprietary data connections and data buses. Ethernet connections support multiple network protocols at Layer 3 of the OSI layer model to transmit data packets between transmitters and receivers. Higher protocol layers segment data streams into packets, facilitate process communication between communicating systems, convert data into a system-independent form, and ultimately provide functionality to applications.

[0003] Systems in a vehicle that communicate with each other via Ethernet connections can place particularly high demands on transmission reliability and the timing coordination of data packets. This is especially true for safety-critical applications in the vehicle, such as the transmission of sensor information and control information for autonomous driving or driver assistance systems.

[0004] The scope of use of time-synchronized network devices will continue to increase in the future. One reason for this is that more and more control units transmit sensor data from different sensors, which are combined and evaluated to provide safety and convenience functions. This combination of data from different sensors is also known as sensor fusion. A particularly important aspect of sensor data fusion is the temporal correlation of the sensor data. Depending on the application, it may be necessary to fused correlated sensor data with millisecond or microsecond accuracy, while for other applications, larger time intervals between detection times may sometimes be permitted. It is also conceivable that detection times must be correlated with an accuracy in the nanosecond range. However, in addition to the data required for sensor fusion, data captured during monitoring vehicle operation and used only for maintenance purposes or to document approved and correct operation may also be subject to strict requirements for being captured and stored at the correct time.

[0005] Almost all Ethernet communication networks used in vehicles use a time synchronization protocol to provide a global time base within the network. Time synchronization in Ethernet networks is defined in the IEEE 802.1AS standard and is based on the Precision Time Protocol (PTP). PTP defines a master / slave clock hierarchy with a best clock (also known as a grandmaster clock) within the network. The time base for other network devices in the network is derived from this best clock (i.e., the grandmaster clock). The best master clock algorithm (BMCA) is used to find this best clock and publish this information to the network. To maintain proper synchronization, systems that support IEEE 802.1AS periodically send announcement messages containing information about the best clock in the network to their neighboring nodes. The recipient of this message compares this information with its own clock signature and messages received on another physical interface containing clock information about other network devices. Based on these messages, a time synchronization tree is constructed. In this process, each physical interface (hereinafter referred to as a port) is assigned one of four states. The "master port" state is assigned to a port whose path to the grandmaster clock is shorter than that of its connection partner. If other ports on the network device do not already have the "Slave Port" status, assign it the "Slave Port" status. For ports that cannot fully support the PTP protocol, select the "Disabled" status. If none of the other three statuses apply, select the "Passive" status.

[0006] In a variation of PTP, the generalized Precision Time Protocol (gPTP), two network devices always communicate directly with each other to achieve time synchronization. Neither network device simply forwards received time synchronization-related messages to another network device. Instead, the network device corrects the received time information for delays on the receiving line and within the network device itself before forwarding it. These network devices are also known as "time-aware systems."

[0007] Figure 1An exemplary block diagram of a vehicle network 100 is shown, which includes multiple network devices 102, 104, 106, 108, 110, and 112 synchronized with a first grandmaster clock. In this case, network devices 102 and 108, 102 and 104, 104 and 110, 104 and 106, and 106 and 112 are interconnected via bidirectional communication connections. Furthermore, network devices 104, 106, and 108 are connected to other network devices (not shown) via bidirectional communication connections. Each of network devices 102-112 has a timer that can be synchronized according to the IEEE 802.1AS standard. After executing the BMCA specified in the standard, network device 112 is determined to be the grandmaster clock for the entire system, meaning that time synchronization-related messages are transmitted from network device 112 to the network. In this case, network device 112 transmits time synchronization-related messages to network device 106, which is directly connected to it, as well as to another network device (not shown). The direction of transmission of time synchronization-related messages is indicated by the dashed arrows depicted next to the communication connections. Network device 106 corrects the time information received from network device 112 for the previously determined delay on the communication connection to network device 112 and the time required for correction and forwarding in network device 106, and transmits the correspondingly modified time synchronization-related messages to network device 104 and another network device (not shown). The time synchronization-related messages contain not only the corrected time information but also information about the system's grandmaster clock (in this case, network device 112). Network device 104 proceeds accordingly and again transmits time synchronization-related messages corrected for the relevant delays to network devices 110 and 102, as well as another network device (not shown). Similarly, network device 102 transmits the corrected time information to network device 108. Due to the corresponding correction of the time information before forwarding, all timers in the network devices are synchronized with the time of the grandmaster clock, except for any remaining inaccuracies caused by individual differences in the correction of the time information before forwarding. The grandmaster clock periodically transmits time synchronization-related messages to the network, which are then further distributed as described above.

[0008] The IEEE 802.1AS standard allows the timing system (i.e., the grandmaster clock) to change at any time. To do this, the Best Master Clock Algorithm (BMCA) is executed again. For example, if a control unit is operating with changed clock parameters, or if a new control unit is added to the network, BMCA is executed, and the clock with the currently best clock parameters is always selected by the system's network devices. BMCA can also be triggered by software or hardware errors in network devices, or by an attacker who manipulates the software or hardware appropriately. Figure 2 This situation is shown in .

[0009] exist Figure 2 In FIG. 1 , network device 108 sends a notification message to network device 102 containing clock parameters of a clock that is better than the clock of network device 112. Network device 102 sends the message to the other network devices, which gradually synchronize their local clocks to the new grandmaster clock. Network device 112 is no longer the grandmaster clock, but instead receives time synchronization-related messages based on time information from the clock of network device 108. The change in time synchronization is indicated by the shading of the rectangle representing the network device and by the change in direction of the partially dashed arrow indicating the propagation of the time synchronization-related message.

[0010] If an attacker successfully takes over time synchronization in a vehicle network and missynchronizes individual or all network devices, this could have dangerous consequences for the safety of vehicle operation. For example, if data from multiple different sensors is combined to control vehicle systems, it is necessary to capture sensor data within a predetermined time window in order to form a valid sensor database for control or feedback control intervention at specific times. Data with significantly different time periods, not captured within the narrow time window required for sensor fusion, but with timestamps within the time window due to an attacker's manipulation of time synchronization, could cause operational disruptions, up to system failure, and in the worst case, an accident.

[0011] Methods for identifying changes in the configuration or structure of a communication network by using the time synchronization of the network are known in the prior art. Unauthorized changes to the configuration of a network could include, for example, the insertion of a network device that intercepts messages and sends altered messages. This could be used to prevent or at least undermine secure and correct operation. DE 102012216689B4 proposes identifying this type of attack by monitoring the delay of time synchronization-related messages within a communication network. Additional network devices that are later connected between two network devices, intercept and forward messages, or manipulate the software of a network device in a manner related to data forwarding will inevitably change the delay of the messages, even if the forwarded messages have not changed, which means that an attack can be identified.

[0012] A correct and secure time base in a network is also crucial in other contexts. For example, DE 10 2014 200 558 A1 describes a secure network access protection method that uses authenticated time protected by an authentication protocol. In this case, message delays are determined, and the integrity of time synchronization-related messages is verified using an additional protocol.

[0013] While the use of time synchronization mechanisms and protocols in networks is widely used for secondary purposes, protecting the time synchronization itself from attacks has not been considered or has been considered only rarely so far.

[0014] It is therefore an object of the present invention to specify a method and a network device that at least prevent unauthorized changes to the time synchronization in a network. Summary of the Invention

[0015] The object of the invention is therefore achieved by a method as claimed in claim 1 and a network device as claimed in claim 8. Improvements and further developments of the method or system are described in the corresponding dependent claims.

[0016] The protection of time synchronization provided by the present invention is primarily directed towards preventing or at least hindering an attacker from making unwanted or unauthorized changes to the grandmaster clock of the network's reference time domain, or from hardware or software failures after initial synchronization. Here, the reference time domain refers to the basic time domain applicable to all network devices in the network.

[0017] In this specification, a communication connection refers to a physical or logical connection between a transmitter and a receiver. A communication connection can be uniquely identified by a port number. A port number can be used to distinguish multiple communication connections originating from or terminating at a particular endpoint.

[0018] In this specification, the terms network device and network node are used synonymously unless the respective context indicates a difference.

[0019] In the following description, it is assumed that the reference time domain has been correctly and unmanipulatedly initialized, for example, according to the Best Master Clock Algorithm (BMCA) of the IEEE 802.1AS standard, and that all network devices in the network have information about which network device provides the grandmaster clock of the reference time domain for the network and what clock ID and clock parameters the grandmaster clock has. Each network device may also have information about which of its physical interfaces are used to transmit valid time synchronization related messages. This initial situation corresponds to the previous reference to Figure 1 Describe the situation.

[0020] According to the present invention, a method for protecting time synchronization in a network from unauthorized modification includes monitoring all physical communication interfaces of a first network device for incoming Announce messages, Sync messages, or Follow-Up messages from a second network device. These messages are used to disseminate information related to the best clock in the network. Typically, in a network system based on the IEEE 802.1AS standard, such messages are sent cyclically and may be forwarded cyclically.

[0021] The time information is extracted from the received notification message, synchronization message or follow-up message, including Grandmaster Clock Class, Grandmaster Clock Accuracy, Grandmaster Priority 1, Grandmaster Priority 2 and Current UTC Offset. In addition, the first network device checks whether these messages apply to the reference time domain. If this is not the case and the notification message, synchronization message or follow-up message applies to a separate time domain to which the first network device does not belong, the message can be forwarded, for example, according to the standard. Otherwise, for example, if the message applies to a virtual reference time domain that the first network device has previously started for time synchronization-related messages from the second network device, the message can be forwarded to the processing steps described later to verify the clock parameters transmitted in the message, otherwise the message can be rejected.

[0022] If the notification message applies to the reference time domain, a check is performed to determine whether the notification message announces a new grandmaster clock with better clock parameters than the clock parameters of the previous grandmaster clock. If this is not the case, the notification message can be ignored, or a time synchronization-related message containing information about the grandmaster clock of the network can be sent from the first network device to the second network device.

[0023] If the clock parameters received in a notification message describe a clock with better parameters, the present invention involves isolating the second network device from the rest of the network with respect to time synchronization-related messages sent by the network device. This isolation ensures that the potentially new grandmaster clock provided by the second network device is not immediately adopted or activated within the system, or even that time synchronization-related messages from the network device are not forwarded, as it has not yet been determined whether the second network device is secure and trustworthy as a new timekeeper. In undesirable circumstances, the entire system would be switched to a potentially unreliable or incorrect clock within milliseconds. To this end, the first network device initiates a virtual reference time domain for time synchronization-related messages received from the second network device. Based on the time synchronization-related messages received from the second network device, the first network device does not send its own time synchronization-related messages to other directly connected network devices, but instead only sends the necessary requests and responses to the second network device in accordance with the IEEE 802.1AS standard. Previously applicable time synchronization continues to be maintained for the first network device and all other network devices except the second network device. The virtual reference time domain applies only to the second network device and to an area isolated from the rest of the first network device.

[0024] The first network device also verifies the clock parameters sent by the second network device. This may include, for example, comparing the clock parameters reported by the second network device during time synchronization initialization and stored in the first network device, checking for permitted or impermissible combinations of clock class and clock accuracy. It may also include comparing the time information contained in time synchronization-related messages sent by the second network device with the time information sent by the original grandmaster clock over a longer period of time, or checking whether different clock parameters are repeatedly transmitted in time synchronization-related messages received via the relevant interface. During the verification process, the new grandmaster clock may also be authorized at a higher protocol level, for example by a control unit temporarily connected to the system with sufficient authority. Authorization may also be requested by the first network device via an appropriate message to a network device equipped with higher authority. If the verification indicates that the grandmaster clock proposed by the second network device is authentic or valid, the first network device interrupts the virtual reference time domain, updates its stored information for the grandmaster clock, and sends time synchronization-related messages based on the new clock parameters to the network. Otherwise, the first network device rejects the proposed clock as the new grandmaster clock.

[0025] For example, the rejection may involve the first network device itself sending a time synchronization-related message to the second network device claiming that it has a better clock than the clock proposed by the second network device. The second network device will then immediately stop sending its own synchronization messages, notification messages, or follow-up messages. If this is the case, the virtual time domain is interrupted and the method continues to monitor for arriving time synchronization-related messages. If the second network device does not stop sending its own synchronization messages, notification messages, or follow-up messages despite the "response" from the first network device having a "better" clock, the virtual time domain is maintained to isolate the time synchronization-related messages from the second network device from the rest of the network until the second network device stops sending synchronization messages, notification messages, or follow-up messages or the validity of the clock reported by the second network device is confirmed at a higher protocol level.

[0026] Before a first network device initiates a virtual reference time domain, it may send a message to a second network device proposing to establish a separate time domain in which the second network device acts as the grandmaster clock. If the second network device accepts the proposal, the first network device operates the separate time domain. In this case, the first network device does not necessarily need to forward messages related to time synchronization for the separate time domain to the network; it may simply terminate or ignore these messages without informing the second network device. However, in some cases, it may forward these messages, for example, to a network device that is designed to check for time synchronization messages applicable to the separate time domain. In this case, these messages may carry a separate domain number, for example. If the second network device does not accept the proposal, it initiates the virtual reference time domain and performs the further method steps as described above.

[0027] Even if the first network device has enabled the virtual reference time domain, it can still forward time-independent communications from the second network device to the appropriate recipients over the network in the usual manner. The first network device can reject time-critical messages, such as those with timestamps clearly intended for safety-related applications, or it can send a message to the network indicating to other network devices that messages from the second network device are untrustworthy, at least with respect to the relevant time information. The first network device can also provide its own timestamp in the message and identify the message in an appropriate manner. This can be accomplished by providing a flag or other field in the message or header.

[0028] The computer program product according to the invention comprises instructions which, when executed by a computer, cause said computer to carry out one or more refinements and further developments of the method described above.

[0029] The computer program product can be stored on a computer-readable data carrier. The data carrier can be physically embodied as, for example, a hard disk, a CD, a DVD, a flash memory, etc. However, the data carrier can also include a modulated electrical, electromagnetic or optical signal that can be received by a computer via an appropriate receiver and stored in the computer's memory.

[0030] A network device implementing the method according to the present invention includes not only a microprocessor and non-volatile and volatile memories, but also at least two physical communication interfaces. The components of the network device are communicatively connected to each other via one or more data lines or data buses. The network device is configured to receive time synchronization-related messages on the interfaces and to inspect and, if necessary, isolate notification messages, synchronization messages, or follow-up messages using the method described above.

[0031] A system according to the present invention having a plurality of network devices connected via a communication network comprises at least one network device configured to execute the above-described method according to the present invention.

[0032] The method according to the invention can advantageously be used to increase the reliability of time synchronization, in particular of communication connections in safety-related networks, such as those required for the transmission of sensor data by autonomous driving systems or driver assistance systems.

[0033] The method according to the present invention can be implemented using existing network equipment. In this case, only software adjustments are required to establish and operate separate time domains. Therefore, implementation incurs minimal additional costs, if any. Existing systems can be configured to implement the method with appropriate software changes. Another advantage of the method according to the present invention is that the underlying hardware platform is irrelevant, as long as it supports establishing or operating multiple separate time domains and PTP. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The present invention will now be explained by way of example with reference to the accompanying drawings, in which:

[0035] Figure 1 An exemplary block diagram illustrating a vehicle network having a plurality of network devices synchronized with a first grandmaster clock time;

[0036] Figure 2 Shown from Figure 1 An exemplary block diagram of a vehicle network having a plurality of time-synchronized network devices, wherein a first grandmaster clock has been replaced by a second grandmaster clock;

[0037] Figure 3 An exemplary block diagram showing a vehicle network having a plurality of time-synchronized network devices when executing the method steps according to the present invention;

[0038] Figure 4 A schematic flow chart showing an embodiment of the method according to the present invention, and

[0039] Figure 5 An exemplary block diagram of a network device configured to execute the method according to the present invention is shown. DETAILED DESCRIPTION

[0040] The same or similar elements may be denoted by the same reference numerals in the drawings.

[0041] Figure 1 and Figure 2 This has been explained above and will not be described here.

[0042] Figure 3 An exemplary block diagram of a vehicle network 100 having multiple time synchronization network devices when performing the method steps according to the present invention is shown. Figure 2 As described above, network device 108 has sent a notification message to network device 102 announcing a clock with better clock parameters. Based on the methods specified in the IEEE 802.1AS standard, this clock will become the grandmaster clock for the entire network. To prevent or mitigate simple manipulation, network device 102 has initiated a virtual time domain, in which the clock proposed by network device 108 acts as the grandmaster clock. To other network devices, the clock provided by network device 112 appears to be the grandmaster clock, as previously described. The division of the time domain by network device 102 into the original time domain and the virtual time domain is indicated by the partial shading of network device 102. Dashed arrows indicate the direction in which time synchronization-related messages are sent from the network's grandmaster clock or the virtual time domain.

[0043] Figure 4A schematic flow chart of an embodiment of a method 200 according to the present invention in a first network device is shown. In step 202, the interface is first monitored for notification messages, synchronization messages, or follow-up messages from a second network device connected thereto. When such a time synchronization-related message arrives, it is first checked to see if it applies to the reference time domain initially established and synchronized. If not, i.e., the "No" branch of step 204, a check is performed in step 204a to determine if the time synchronization-related message applies to the previously initiated virtual reference time domain. If not, i.e., the "No" branch of step 204a, the time synchronization-related message is forwarded in step 206. If the check in step 204 indicates that the time synchronization-related message applies to the reference time domain, i.e., the "Yes" branch of step 204, a further check is performed in step 208 to determine if the time synchronization-related message announces a new grandmaster clock with better clock parameters than the previous grandmaster clock. If not, i.e., the "No" branch of step 208, the message is rejected or ignored in step 210 and monitoring continues. If the check in step 208 indicates that a new grandmaster clock has been announced with clock parameters that are better than those of the previous grandmaster clock (i.e., the "yes" branch of step 208), the first network device initiates a virtual reference time domain in step 218. Prior to initiating the virtual reference time domain in step 218, the first network device may optionally propose to the second network device to establish a separate time domain in step 212. If the second network device accepts this proposal (i.e., the "yes" branch of step 214), the first network device may operate the separate time domain and appropriately forward time synchronization-related messages applicable to the separate time domain to the rest of the network. If the second network device does not accept the proposal to establish a separate time domain (i.e., the "no" branch of step 214), the first network device initiates the virtual reference time domain. Within the virtual reference time domain, the clock parameters sent by the second network device are subsequently verified in step 220. If the check in step 204a indicates that the time synchronization-related messages received from the second network device are applicable to the previously established virtual reference time domain (i.e., the "yes" branch of step 204a), the method bypasses the checks in step 208 and (possibly) step 214 and immediately continues with the clock parameter verification in step 220. If the verification in step 220 indicates that the grandmaster clock proposed by the second network device is authentic or valid (i.e., the "yes" branch of step 220), the first network device interrupts the virtual time domain in step 222, updates its stored information about the grandmaster clock in step 224, and from then on sends time synchronization-related messages based on the new clock parameters to the network. If the verification in step 220 indicates that the grandmaster clock proposed by the second network device is unauthentic or invalid (i.e., the "no" branch of step 220), the first network device rejects the clock proposed by the second network device as the grandmaster clock of the reference time domain in step 226.This rejection can include the first network device sending its own notification message to the second network device, wherein the clock parameters in the notification message represent a better clock than the clock parameters transmitted in the time synchronization-related message from the second network device. As long as the notification message, synchronization message, or follow-up message arrives from the second network device and no higher protocol level authorization occurs, the virtual reference time domain is maintained. Applicable checks are performed in steps 228 and 230.

[0044] Figure 5 An exemplary block diagram of a network device 400 configured to perform the method according to the present invention is shown. The network device 400 includes not only a microprocessor 402, but also volatile and non-volatile memories 404, 406, and two communication interfaces 408. The elements of the network device are communicatively connected to one another via one or more data connections or data buses 410. The non-volatile memory 406 contains program instructions that, when executed by the microprocessor 402, implement at least one improvement of the method according to the present invention.

[0045] List of reference numerals:

[0046] 100 Network

[0047] 102-112 Network Equipment

[0048] 200 Methods

[0049] 202 Monitoring time synchronization related messages

[0050] 204 Baseline Time Domain Check

[0051] 204a Virtual Baseline Time Domain Check

[0052] 206 Forwarding in Virtual Base Time Domain

[0053] 208 Clock parameter check

[0054] 210 Reject / Ignore

[0055] 212 Propose a separate time domain

[0056] 214 Check whether to accept a separate time domain

[0057] 216 forwards

[0058] 218 Start virtual reference time domain

[0059] 220 Clock Parameter Verification

[0060] 222 Interrupt Virtual Time Domain

[0061] 224 Update the stored clock parameters

[0062] 226 Reject New Clock

[0063] 228 Maintaining Virtual Time Domain

[0064] 230 Check authorization for new clock

[0065] 400 Network Equipment

[0066] 402 Microprocessor

[0067] 404 RAM

[0068] 406 ROM

[0069] 408 Communication Interface

[0070] 410 bus

Claims

1. A method (200) for protecting time synchronization in a network (100) from unauthorized modification of a grandmaster clock of a reference time domain, the method comprising: - monitoring (202) a physical communication interface of a first network device for the arrival of time synchronization related messages from a second network device, these messages being used to propagate information about the best clock in the network, - performing a first check (204) to determine whether these time synchronization related messages apply to the reference time domain for initial establishment and synchronization, and if this is the case then: - performing a second check (208) to determine whether these time synchronization related messages announce a new grandmaster clock having better clock parameters than the previous grandmaster clock, and if this is the case then: - initiating (218) a virtual reference time domain by the first network device, wherein the first network device does not forward time synchronization related messages based on the time synchronization related messages of the second network device to the rest of the network, and wherein, based on the virtual reference time domain, only necessary requests and responses according to the IEEE 802.1AS standard are sent from the first network device to the second network device, - verifying (220) the clock parameters sent by the second network device, Wherein, if the verification shows that the grandest clock proposed by the second network device is authentic or valid, the first network device interrupts (222) the virtual reference time domain, updates (224) the information stored therein related to the grandest clock, and from this point on sends time synchronization related messages based on the new clock parameters to the network; otherwise, the first network device rejects (226) the use of the clock as the new grandest clock of the reference time domain.

2. The method according to claim 1, further comprising: Before starting (218) the virtual reference time domain: - sending (212) a response to the second network device proposing to establish a separate time domain, and - performing a third check (214) to determine whether the second network device accepts additional time domains, and if this is the case: - the first network device ignores, terminates or forwards (216) time synchronization related messages arriving from the second network device for the additional time domain, Or, if that is not the case, then: - The first network device starts (218) the virtual reference time domain and performs subsequent method steps.

3. The method according to claim 1, wherein The verification (220) includes: - comparing the received clock parameters with the clock parameters reported by the second network device during time synchronization initialization and stored in the first network device, - check for allowed or disallowed combinations of clock class and clock accuracy, or - Receive authorization for a higher protocol level.

4. The method according to claim 1, wherein The rejection (226) includes: - sending a notification message to the second network device, wherein the clock parameter in the notification message indicates a better clock than the clock transmitted in the notification message of the second network device, - Maintaining the virtual reference time domain as long as further notification messages arrive from the second network device (228) and no authorization of a higher protocol level for the new grandmaster timepiece announced by the second network device occurs (230).

5. The method according to claim 1, further comprising: If the first check (204) indicates that the time synchronization related message received from the second network device is not applicable to the reference time domain, then: - Checking (204a) whether these time synchronization related messages apply to the previously started virtual reference time domain, and if so: - verifying (220) the clock parameters sent by the second network device and executing subsequent method steps, Or, if not, then: - Forward or ignore (206) these time synchronization related messages.

6. The method according to claim 1, further comprising: If this second check (208) shows that the received notification message does not announce a new grandmaster having better clock parameters than the clock parameters of the previous grandmaster, then: - Ignore (210) the notification message.

7. The method according to claim 1, wherein Messages that are not used for clock synchronization but carry time information and arrive at the first network device from the second network device are forwarded by the first network device only after the first network device has added information about the ambiguous authenticity of the time information to the message, or after the first network device has informed all other network devices in the network of the ambiguous authenticity of the time information in the message from the second network device.

8. A network device comprising a microprocessor (402), a volatile memory (404) and a non-volatile memory (406), two or more communication interfaces (408) communicatively connected to each other via one or more data lines or a data bus (410), wherein: The network device is configured to perform the method according to one of claims 1 to 7.

9. A system having a plurality of network devices (104-112) according to claim 8, wherein: At least one of the network devices (102) is configured to perform the method according to one of claims 1 to 7.

10. A vehicle having a system according to claim 9.

11. A computer program product comprising instructions which, when a computer executes the program, cause the computer to carry out the method according to one of claims 1 to 7.

12. A computer-readable data carrier having stored thereon a computer program product according to claim 11.

Images