Network timing synchronization

Abstract

The present disclosure relates to network timing synchronization. Technologies related to time synchronization in a network are disclosed. In some embodiments, a device includes a first circuit having a first clock configured to maintain a local time value of a node coupled to a network. The first circuit is configured to send a first message to a second circuit. The first message includes a first present time. The second circuit has a second clock that maintains a reference time value of the network. The first circuit receives a second message from the second circuit, the second message including a second present time and associated with a timestamp identifying the reference time value. The first circuit compares the first present time with the second present time to determine whether the timestamp is valid, and in response to determining that the timestamp is valid, uses the timestamp to synchronize the first clock with the second clock.

Description

[0001] This application is a divisional application of PCT application No. 201780052633.9, which entered the Chinese national phase and whose international filing date is September 8, 2017 and whose invention name is “NETWORK TIMING SYNCHRONIZATION”. Technical Field

[0002] The present disclosure relates generally to computing devices, and more particularly, to synchronizing time between multiple devices communicating over a network. Background Art

[0003] Various protocols have been developed to synchronize computer clocks over computer networks. In many cases, protocols can facilitate the distribution of timing information provided from a source that maintains a master clock such as the atomic clock of the U.S. Naval Observatory. For example, one of the most notable protocols is the Network Time Protocol (NTP) for synchronizing time between computers connected to the Internet. The timing information received by this protocol can be used not only to display the time on the user's computer, but also to coordinate the performance of various operations, such as distributing software updates to the computer, displaying notifications, calling backup utilities, and timestamping emails. As timing requirements change, other network protocols have been developed to achieve more accurate time synchronization. For example, IEEE 802.1AS can be used in various audio and video applications to synchronize time between devices that consume or produce audio and video content. Summary of the invention

[0004] The present disclosure describes an embodiment in which time is synchronized between nodes in a network. In various embodiments, a device includes a first circuit having a first clock, which is configured to maintain a local time value of a node coupled to a network. The first circuit is configured to send a first message including a first nonce to a second circuit that maintains a reference time value of the network. The first circuit receives a second message from the second circuit, which includes a second nonce and is associated with a timestamp that identifies the reference time value. The first circuit compares the first nonce with the second nonce to determine whether the timestamp is valid, and in response to determining that the timestamp is valid, uses the timestamp to synchronize the first clock with the second clock. In some embodiments, the first circuit sends a first message during an exchange with the second circuit to determine a propagation delay between the first circuit and the second circuit, and by determining the offset between the first clock and the second clock based on the propagation delay and the timestamp, uses the timestamp to synchronize the first clock with the second clock. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram illustrating an example of a network implementing time synchronization.

[0006] Figure 2is a block diagram illustrating an example of a hardware security module configured to facilitate time synchronization.

[0007] Figure 3A and Figure 3B is a diagram showing an example of messages in synchronous communication.

[0008] Figures 4A-4C is a diagram illustrating an example of messages in a propagation delay exchange.

[0009] Figure 5 is a diagram illustrating an example of an integrity check value field included in one or more of the messages.

[0010] Figure 6 is a diagram illustrating an example of a present field included in one or more of the messages.

[0011] Fig. 7A and Figure 7B is a communication diagram illustrating an example of time synchronization including propagation delay exchange and synchronous communication.

[0012] Figure 8 is a flow chart illustrating an example of boundary checking for synchronous communications.

[0013] Fig. 9A and Fig. 9B is a flow chart illustrating examples of other methods that may be performed by a network component.

[0014] Fig.10 is a block diagram illustrating an exemplary computer system. DETAILED DESCRIPTION

[0015] This disclosure includes references to "one embodiment" or "an embodiment." The appearance of the phrase "in one embodiment" or "in an embodiment" does not necessarily refer to the same embodiment. The particular features, structures or characteristics may be combined in any suitable manner consistent with this disclosure.

[0016] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as "configured to" perform one or more tasks or operations. This expression—[an entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, this expression is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform a task even if the structure is not currently being operated. "A node configured to transmit traffic over a network" is intended to cover, for example, a device having circuits that perform that function during operation, even if the device in question is not currently in use (e.g., a power source is not connected to it). Thus, an entity described or stated as "configured to" perform a task refers to a physical thing used to implement the task, such as a device, a circuit, a memory storing executable program instructions, etc. The phrase is not used herein to refer to an intangible thing. Thus, a "configured to" structure is not used herein to refer to a software entity, such as an application programming interface (API).

[0017] The term “configured to” is not intended to mean “configurable to.” For example, an unprogrammed FPGA would not be considered “configured to” perform a particular function, although it may be “capable of being configured to” perform that function and may be “configured to” perform that function after being programmed.

[0018] The statement in the appended claims that a structure is "configured to" perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) for that claim element. Thus, no claim in the present application as filed is intended to be interpreted as having a means-plus-function element. If the applicant wishes to invoke section 112(f) during the prosecution of the application, it will use the "means for" [performing the function]" structure to phrase the claim element.

[0019] As used herein, the terms "first," "second," and the like act as labels for the nouns that follow them, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly noted. For example, an exchange between a first circuit and a second circuit may include the communication of multiple messages. The terms "first" and "second" may be used to refer to any two of the messages in the exchange. In other words, for example, a "first" message and a "second" message are not limited to the initial two messages in the exchange.

[0020] As used herein, the term "based on" is used to describe one or more factors that influence a determination. The term does not exclude that there may be additional factors that may influence the determination. That is, the determination may be based only on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "determining A based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor such as C. This phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is therefore synonymous with the phrase "based at least in part on."

[0021] As used herein, the term "synchronize" means to calculate an adjustment to be made to a first clock to determine a value of a second clock. Although the term includes adjusting a value in a first clock to have the same time as a second clock, for purposes of this disclosure, the term also includes not adjusting a value in the first clock. For example, "synchronizing" a first clock with a second clock may include calculating an adjustment to the first clock and applying the adjustment to a time value output by the first clock in order to determine a time value of the second clock.

[0022] One problem with traditional time synchronization schemes is that they generally do not consider security issues. This design failure can allow a malicious person to potentially interfere with a computing device's perception of the current time. For example, the person can attempt to deceive a trusted time source by providing a message announcing an incorrect time. The person can also attempt to replay the message after a delay and have the recipient think the replayed message is fresh (e.g., replay the message with a delay corresponding to the recipient's offset clock). In doing so, the person may be able to interfere with the intended operations performed by the device and may cause other problems.

[0023] The present disclosure describes various technologies for improving the security of time synchronization systems. In various embodiments described below, a computer network implements a protocol for managing clock synchronization between network nodes with corresponding local clocks. The protocol can be used to periodically announce the current time of the network clock by transmitting a first group of one or more messages from the master clock to the slave clock, and to determine the offset between the clocks by transmitting a second group of messages, so as to take into account the propagation delay introduced by the network when distributing the announced current time. In order to improve the security of these messages, in some embodiments, an integrity check value (ICV) is added to each message. As used herein, the term "integrity check value" will be interpreted according to its meaning understood in the art, and includes an integer that can be used to verify the integrity of the data and is calculated by applying a keying function (i.e., a function using a cryptographic key) to the data. Including this value allows the message to be verified and resists tampering by malicious entities. In some embodiments, one or more present times are included in the exchange, which are used to determine the propagation delay and then repeated in the subsequent announcement of the current time. As used herein, the term "present time" will be interpreted according to its meaning understood in the art, and includes an arbitrary and unpredictable number that is used only once in an operation or a group of operations. For example, a random or pseudo-random number generator algorithm may be used to determine the present time. Including the present time in this manner prevents malicious entities from attempting to interfere with the node's local time to replay older announcements. In some embodiments, a network node may collect information for determining a propagation delay, which may also be used to determine an expected offset between a local clock and a network clock. The node may then compare this expected offset with an offset calculated based on a timestamp identifying the current time in a subsequent announcement. If the expected offset is significantly different from the calculated offset, the node may discard the announcement because it may be illegal.

[0024] In some embodiments, messages associated with time synchronization may also be processed by a secure circuit coupled to a network node using timing information (as opposed to the node itself handling the processing). As used herein, the term "secure circuit" refers to a circuit that protects isolated internal resources from being directly accessed by external entities. As will be described below, in various embodiments, the secure circuit may maintain the local clock of the network node and a key for generating or verifying the ICV included in the message. In some cases, using a secure circuit to process messages (as opposed to the node) may provide additional security for the network.

[0025] The present disclosure begins with the combination Figure 1 and Figure 2 Description of the components in a secure network that implements time synchronization. Figures 3A-7B Describes network communications between nodes. Methods performed by network components refer to Figure 8-9B Finally, about Fig.10Exemplary computer systems that may be used to implement one or more network components are discussed.

[0026] Now turn to Figure 1 , depicts a block diagram of a network 100 configured to implement time synchronization. In the illustrated embodiment, the network 100 includes a switch 110 coupled to a plurality of nodes 120A-C via a link 112. The nodes 120A-B are in turn coupled to corresponding hardware security modules (HSMs) 130A-B via a link 122, which include local clocks 132A-B. As shown, the node 120C is coupled to a master host (GM) 140, which includes a network clock 142. The switch 110 is also coupled to an HSM 130D including a local clock 132D. In various embodiments, the network 100 may be implemented differently than shown. Therefore, in some embodiments, there may be more (or fewer) switches 110 and / or nodes 120. In some embodiments, the GM 140 may be coupled to the switch 110 (opposite to the node 120). In some embodiments, the functions described herein with respect to the HSM 130 may be implemented by circuits in the node 120.

[0027] In some embodiments, network 100 is a local area network (LAN) configured to transmit network traffic between nodes 120. In various embodiments, network traffic is routed between nodes 120 via switch 110. Thus, switch 110 may be configured to queue received messages (i.e., data frames) from nodes 120 and analyze the source and destination addresses specified by the frames in order to properly send the messages to their designated destinations. In some embodiments, switch 110 is configured to route data frames according to IEEE 802.3 (i.e., Ethernet frames); however, in other embodiments, other network protocols may be supported.

[0028] Node 120 may correspond to any suitable device configured to communicate via a network. In some embodiments, node 120 may be a device such as a desktop computer and a laptop computer, a mobile device, a smart TV, an intelligent appliance, etc., within a home or office network. In some embodiments, node 120 is a machine within a manufacturing plant, which is configured to perform various operations. In some embodiments, node 120 is an electronic control unit (ECU) in a vehicle such as an airplane, a ship, a car, an amusement vehicle, etc. As used herein, the term "electronic control unit (ECU)" should be interpreted according to its meaning understood in the art, and includes an embedded system (e.g., a microcontroller) that controls one or more operations of the vehicle. In some embodiments, node 120 may include, for example, a motor ECU that transmits a torque control message and a wheel speed message to control the operation of the motor, a brake system ECU that transmits a brake control message to apply a brake, a LIDAR ECU that processes data received from one or more LIDAR sensors, a flight yoke ECU that transmits the angle of a yoke controller, etc., and the like.

[0029] In various embodiments, the nodes 120 (and the switches 110) are configured to use synchronized time for various purposes, including coordinating traffic communications through the network 100. For example, an ECU receiving streams from multiple LIDAR sensors can generate an overall view of the surrounding environment of a vehicle, which depends on the synchronized time between the ECU and the sensors transmitting the streams. That is, the first LIDAR sensor and the second LIDAR sensor can time stamp their respective streams so that the ECU can determine what each sensor is looking at at a given time. If these timestamps are generated by unsynchronized clocks, then when one LIDAR sensor indicates the presence of an object, the ECU may have problems determining whether the object is present in front of the vehicle, while the other sensor gives the appearance that there is nothing in front of the vehicle because it contains an erroneous timestamp. As another example, in some embodiments, traffic transmitted through the network 100 is coordinated according to a schedule that indicates when a particular node 120 should transmit a particular traffic. For example, if the time is not synchronized across the nodes 120, node 120A may begin transmitting network traffic during the time slot assigned to node 120B. This conflict can cause the nodes to obtain incorrect information or significantly delayed information, which can be associated with time-critical tasks.

[0030] In one embodiment, a hardware security module (HSM) 130 is a secure circuit configured to provide time information 134 to nodes 120 for various purposes. In some embodiments, each HSM 130 includes a local clock 132 configured to maintain a value of a local time at that node 120, which is synchronized with a network clock 142 via the HSM 130. As will be described in more detail below, in various embodiments, time synchronization of the network 100 may be performed such that a given HSM 130 synchronizes its local clock 132 with an HSM 130 of a neighboring node 120 or switch 110 that resides on a path between the given HSM 130 and the master host 140 and is a hop closer to the master host 140. Thus, HSM 130A and HSM 130B may synchronize their local clocks 132A and 132B with local clock 132D in HSM 130D, which is coupled to node 120 that is one hop closer to node 120C and master host 140. Figure 1 In the absence of other closer nodes 120, HSM 130D may in turn synchronize with network clock 142 in master host 140. In other words, time synchronization of network 100 may be viewed as a tree structure, where a given child node is synchronized with its parent node, and master host 140 serves as the root node in the tree structure.

[0031] When performing synchronization between the clocks of two HSMs 130, the HSM 130 that provides the timing information (e.g., HSM 130D) may be referred to as the master, and the HSMs 130 that receive the timing information (e.g., HSMs 130A and 130B) may be referred to as slaves. As part of performing synchronization, in various embodiments, the slave may determine the propagation delay between it and its master (e.g., the delay between HSM 130A and HSM 130D). The slave may also determine the offset between its local clock 132 and the master's clock (e.g., the offset between clocks 132A and 132D). Once these values ​​are determined, the HSM 130 may provide information 134 to its node 120, wherein the timing information includes a time value associated with the current value of the network clock 142 and is calculated based on the value of the local clock 132, the propagation delay, and the determined offset. In various embodiments, HSM 130 relies on maintaining local time and synchronized time (as opposed to node 120), because HSM 130 may employ various security techniques that make them more secure than node 120, as described below with reference to Figure 2 described.

[0032] In one embodiment, master host (GM) 140 is a circuit configured to maintain the network time of network 100 (i.e., the reference time to which local clocks 132 are synchronized). That is, although HSM 130D may act as a host for HSM 130A and HSM 130B, GM 140 is the ultimate authority (i.e., the "master host") in the illustrated embodiment. As described above, in the illustrated embodiment, GM 140 includes a network clock 142 configured to track the current value of the network time. In some embodiments, GM 140 may be one of several master clocks and is selected as the master host through an election process. As described above, in some embodiments, GM 140 may be coupled to switch 110 (with Figure 1 120E shown in FIG) and / or may implement the functionality of HSM 130 discussed below. In various embodiments, GM 140 is also configured to facilitate time synchronization with HSM 130D via synchronization (sync) communications 152 and propagation delay (Pdelay) exchanges 154. (Although Figure 1 Only communications 152 and exchanges 154 are shown between GM 140 and HSM 130D in order to simplify the diagram, but communications 152 and exchanges 154 are also provided from HSM 130D to HSMs 130A and 130B.

[0033] In the illustrated embodiment, a synchronization communication 152 is a message transmitted by a master (e.g., GM 140 or HSM 130D) to announce the current value of the network time identified by its synchronization clock 132 or network clock 142. In various embodiments, a given synchronization communication 152 includes a timestamp that identifies the current value of the network time when the synchronization communication 152 was sent from the master and can be used by a given slave to determine the offset (i.e., the difference) between the slave's local clock 132 and the master's clock 132 or clock 142. In various embodiments, the offset determined is 1) the time difference between the master's clock and the slave's clock and 2) the frequency difference between the master's clock and the slave's clock, because in some cases their frequencies may be slightly different. Because the respective frequencies of clocks 132 and 142 may fluctuate with temperature changes, synchronization communications 152 may be sent periodically (e.g., eight times per second). In some embodiments, a given synchronization communication 152 includes two messages: a synchronization message sent at a particular time (described below with reference to FIG. 1 ); and a synchronization message sent at a particular time. Figure 3A Discussion), and a follow-up message (see below) that includes a timestamp that specifies a network time value that specifies a particular time (i.e., the time when the synchronization message was sent). Figure 3B Discussion). In some embodiments, these messages include the contents of IEEE 802.1AS frames.

[0034] In the illustrated embodiment, the Pdelay exchange 154 is an exchange between the master and the slave to determine the propagation delay between the master and the slave. That is, because the message takes time to traverse the network 100, the timestamp specified in the synchronous communication 152 is delayed when it arrives at the HSM 130. To address this issue, the HSM 130 determines the propagation delay and the dwell time to appropriately adjust the timestamp in the synchronous communication 152 so that it accurately reflects the current network time. In some embodiments, the exchange 154 includes the slave sending a message to the master (described below and Figure 4A Request) and receives a corresponding response from the host (below and in Figure 4B Response in (referred to as Pdelay in response). The propagation delay may then be determined by: 1) calculating the difference between the arrival time of the first message and its departure time, 2) calculating the difference between the arrival time of the second message and its departure time, and 3) determining the average of the differences. It is noteworthy that the use of the arrival and departure times of the two messages is to account for the fact that the arrival timestamps and departure timestamps are provided by the master's clock and the slave's clock, which may be unsynchronized as described above. For example, HSM 130D may record the departure time of the first message and the arrival time of the second message based on local clock 132D, but rely on GM 140 to provide timestamps for the arrival time of the first message and the departure time of the second message, which are based on network clock 142. In some embodiments, the second message may include both timestamps. In other embodiments, the second message includes a timestamp of the arrival time of the first message, and a third message is sent (below and in Figure 4C 14. In some embodiments, the Pdelay exchange 154 is performed periodically (e.g., once per second) because the propagation delay may change as the temperature of the links 112 and 122 changes. In some embodiments, the message transmitted in the exchange 154 includes the content of the IEEE 802.1AS frame.

[0035] To improve the security of the sync communication 152 and the Pdelay exchange 154, in various embodiments, the HSM 130 and the GM 140 are configured to perform various techniques to make them more resistant to tampering by malicious entities. In some cases, these techniques can protect the HSM 130 if a node 120 becomes compromised and begins spoofing the host or GM 140 of the HSM 130 by broadcasting its own sync communication 152. These techniques can also prevent man-in-the-middle attacks such as a switch 110 becoming compromised and attempting to replay messages from an old sync communication 152 or Pdelay exchange 154.

[0036] First, in some embodiments, during the synchronous communication 152 and the Pdelay exchange 154, an integrity check value (ICV) is added to one or more messages sent between the GM 140 and the HSM 130. The ICV can be calculated using any of a variety of algorithms. For example, in one embodiment, the GM 140 and the HSM 130 are configured to calculate the ICV using a message authentication code (MAC) algorithm such as a Hash-based MAC (HMAC) algorithm. In another embodiment, the ICV is a digital signature calculated using a digital signature algorithm (DSA). In yet another embodiment, the ICV includes a MAC encrypted using the Advanced Encryption Standard (AES) in a cipher block chaining (CBC) mode. In some embodiments, the key used to determine the ICV is unique to a given HSM 130 that is involved in the communication and is known to the HSM 130 and its host. For example, if HSM 130D is sending a first message to HSM 130A and a second message to HSM 130B, the ICV in the first message is calculated using the first key, and the ICV in the second message is calculated using a second key that is different from the second key. Therefore, HSMs 130A and 130B are not only able to verify the integrity of the received message, but are also able to authenticate the message because HSM 130D is the only other entity that has a key that is unique to that HSM 130. Therefore, if HSM 130 receives a message that includes an ICV and is not sure that the ICV is valid, the message is suspicious and may be ignored by HSM 130. In doing so, HSM 130 and GM 140 may prevent entities from attempting to spoof messages from GM 140 or a particular HSM 130. Examples of messages that include an ICV are provided below with reference to FIG. Figure 3A-5 discuss.

[0037] Second, in some embodiments, the HSM 130 is configured to provide a present during a Pdelay exchange 154, which is repeated by its host during one or more subsequent synchronous communications 152. (In some embodiments, the host may also include Figure 7B In doing so, HSM 130 and GM 140 may prevent malicious entities from replaying synchronization communications 152 sent before the nonce was provided because they would lack the nonce. Thus, if HSM 130 receives a synchronization communication 152 that includes a nonce that is different from the nonce previously provided, HSM 130 may disregard the communication 152 as suspicious. Figure 3A , Figure 3B , Figure 4A and Figure 6 The discussion includes examples of current messages.

[0038] Third, in some embodiments, the HSM 130 is configured to determine an expected offset during the Pdelay exchange 154, and to perform a bounds check on the offset calculated from a given synchronous communication 152 using the expected offset, so as to determine whether the synchronous communication 152 is valid. Although the Pdelay exchange 154 is primarily performed to determine the propagation delay as described above, the offset between the clock of the master and the clock of the slave may be determined based on information obtained when determining the delay. Specifically, the offset may be determined by: 1) calculating the average of the departure time of the first message and the arrival time of the second message, 2) calculating the average of the arrival time of the first message and the departure time of the second message, 3) determining the difference between the two averages, so that the difference is the offset. In such embodiments, the HSM 130 is configured to determine the offset and compare it with the offset calculated based on the timestamp included in the subsequent synchronous communication 152. If the calculated offset differs from the expected offset by more than a certain threshold, the timestamp included in the synchronous communication 152 is suspicious. Therefore, the HSM 130 may ignore the synchronous communication 152 and not attempt to provide time information 134 based on the suspicious timestamp. In doing so, HSM 130 can prevent spoofing and / or man-in-the-middle attacks. Figure 8 An example of a method for performing bounds checking is described in more detail.

[0039] Now turn to Figure 2 , depicting a block diagram of an HSM 130. As described above, in some embodiments, the HSM 130 is used to replace the timing maintenance and synchronization of the node 120 because the HSM 130 can be more secure for reasons discussed below. As also noted, in some embodiments, the GM 140 can implement the functions described with respect to the HSM 130 in order to improve the security of the GM 140. In the illustrated embodiment, the HSM 130 includes a network interface 210, one or more processors 220, a read-only memory (ROM) 230, a local clock 132, a cryptographic accelerator 240, and a key storage device 250 coupled together via an interconnect 260. The ROM 230 also includes firmware 232. The key storage device 250 also includes one or more ICV keys 252. In some embodiments, the HSM 130 may include more (or fewer) components than shown.

[0040] In one embodiment, the network interface 210 is configured to facilitate communication with the node 120. Therefore, the interface 210 can perform encoding and decoding data across the link 122, and in some embodiments, the link 122 is a serial peripheral interface (SPI) bus. In various embodiments, the interface 210 is also configured to isolate the internal components 220-250 from external entities such as the node 120 by filtering the read and write operations that enter. In some embodiments, the HSM 130 presents a limited attack surface by supporting only a small number of commands. For example, in one embodiment, the HSM 130 supports commands that allow the node 120 to request the current time and commands that provide data for synchronous communication 152 or Pdelay exchange 154. If the interface 210 receives data that is not a supported command from the node 120, the interface 210 can prevent the data from entering the HSM 130. In doing so, the HSM 130 prevents, for example, the node 120 from being able to directly access the local clock 132.

[0041] In one embodiment, the processor 220 is configured to execute program instructions to implement the various operations described herein with respect to the HSM 130. In some embodiments, the processor 220 is hardwired to fetch from a specific address range at boot time in order to boot the firmware 232 from the ROM 230. Specifically, because the memory 230 is a ROM (as opposed to some other types of memory that can be easily written to), the firmware 232 resists modification, and therefore tampering. Thus, by simply restarting the processor 220, the HSM 130 can be restored to a default trusted state, which in the illustrated embodiment can be initiated by asserting the reset signal 202. Thus, the processor 220 can further be used to isolate components in the HSM 130.

[0042] In one embodiment, the cryptographic accelerator 240 is a circuit configured to perform cryptographic operations on the HSM 130. The cryptographic accelerator 240 may implement any suitable cryptographic algorithm such as the Data Encryption Standard (DES), the Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), HMAC, etc. In the illustrated embodiment, the accelerator 240 is configured to use keys stored in the key storage device 250, which may isolate access from other components of the HSM 130. That is, in some embodiments, the accelerator 240 may allow the ICV key 252 to be updated by the processor 220, but does not allow the processor 220 to read the key 252 from the storage device 250.

[0043] In various embodiments, the cryptographic accelerator 240 is configured to use the ICV key 252 to verify the ICV including the synchronization communication 152 and the Pdelay exchange 154. Thus, the accelerator 240 may be configured to receive a message, calculate the ICV using the ICV key 252, and compare the calculated ICV with the ICV contained in the received message. If the two ICVs do not match, the HSM 130 may discard the message instead of using it to calculate the time information 134. The ICV key 252 may correspond to any suitable algorithm such as those mentioned above. As described above, in some embodiments, the ICV key 252 is unique to the HSM 130 - that is, there is no other HSM 130 that includes the key 252.

[0044] Now turn to Figure 3A , depicts a diagram of a synchronization message 300. As described above, the synchronization message 300 is an example of a message that may be included in the synchronization communication 152. In the illustrated embodiment, the message 300 includes a header, a reserved portion (shown as "Reserved"), a present field (shown as "slaveNonce Type-Length-Value (TLV)"), and an ICV field (shown as "ICVTLV"). Although these fields may be of any suitable size, in this example, the header, reserved portion, present field, and ICV field have sizes of 34, 10, approximately 10, and approximately 30 octets, respectively. Notably, in the illustrated embodiment, the ICV field includes an ICV for the message 300, as will be described with reference to FIG. Figure 5 The present field includes the present time repeated by the host (e.g., Figure 1 GM 140 or HSM 130D), as referenced Figure 6 In some embodiments, the synchronization message 300 may include more (or fewer) elements than shown. In some embodiments, the synchronization message 300 is an IEEE 802.1AS synchronization frame, in which the present field and the ICV field are appended to the end of the frame.

[0045] Now turn to Figure 3B, depicting a diagram of a synchronization follow-up 350. As described above, the synchronization follow-up 350 is an example of another message that may be included in the synchronization communication 152. In the illustrated embodiment, the message 350 includes a header, a timestamp (shown as "precisionOriginTimestamp"), additional metadata about the communication 152 (shown as "Follow_UPInformation TLV"), a present field (shown as "slaveNonce Type-Length-Value (TLV)"), and an ICV field (again shown as "ICV TLV"). Although these fields can be any suitable size, in this example, the sizes of these fields are 34, 10, 34, approximately 10, and approximately 30 octets, respectively. Notably, in the illustrated embodiment, the timestamp indicates the departure time of the earlier synchronization message 300 - that is, the network time value when the message 300 left the host (e.g., as determined by the identified network clock 142 or based on the determined offset of the local clock 132D and the HSM 130D). In some embodiments, the message 350 may include more (or fewer) elements than shown. In some embodiments, the message 350 is an IEEE 802.1AS Sync Follow-up frame, in which the ICV field is appended to the end of the frame.

[0046] Now turn to Figure 4A , depicting a diagram of a Pdelay request 400A and a Pdelay request 400B. As described above, a Pdelay request 400 is an example of an initial message that may be included in a Pdelay exchange 154 and requests a corresponding response from a host. As shown, message 400A includes a header, two reserved portions (shown again as "reserved"), a present field (shown again as "slaveNonce TLV"), and an ICV field. Although these fields can be any suitable size, in this example, the sizes of these fields are 34, 10, 10, approximately 10, and approximately 30 octets, respectively. It is noteworthy that in the illustrated embodiment, the present field includes the present sent by the HSM 130 so as to be included later in the synchronization message 300 and / or the synchronization follow-up message 350. In some embodiments, message 400A may include more (or fewer) elements than shown. Therefore, as shown in request 400B, the ICV field may be omitted. In some embodiments, message 400 is an IEEE 802.1AS Pdelay request frame having a present field and / or an ICV field appended to the end of the frame.

[0047] Now turn to Figure 4B, depicting a diagram of a Pdelay response 430A and a Pdelay response 430B. As described above, the Pdelay response 430 is an example of another message that may be included in the Pdelay exchange 154 and is a response to the Pdelay request 400. As shown, the message 430A includes a header, a timestamp (shown as "requestReceiptTimestamp"), a port number field identifying the port of the requesting HSM 130 (shown as "requestedPortIdentity"), and an ICV field (again shown as "ICV TLV"). Although these fields can be any suitable size, in this example, the sizes of these fields are 34, 10, 10, and approximately 30 octets, respectively. It is noteworthy that in the illustrated embodiment, the timestamp indicates the arrival time of the earlier Pdelay request 400 - that is, the value of the network time when the message 400 is received at the GM 140. In some embodiments, the message 430A may include more (or fewer) elements than shown. Therefore, as shown in response 430B, the master may include another nonce (shown as a "masterNonce TLV") in response 430B. Figure 4C and Figure 7B As described, when response 430 is subsequently included in a follow-up message in request 400 along with the original nonce provided by the slave, this additional nonce can be used to verify response 430. In some embodiments, message 430 is an IEEE 802.1AS Pdelay response frame in which the ICV field and / or the nonce provided by the master is appended to the end of the frame.

[0048] Now turn to Figure 4C, depicting a diagram of a Pdelay follow-up 460A and a Pdelay follow-up 460B. As described above, the Pdelay follow-up 460 is an example of another message that may be included in the Pdelay exchange 154 and includes additional information about the earlier Pdelay response 430. As shown, the message 460A includes a header, a timestamp (shown as "responseOriginTimestamp"), a port number field identifying the port of the requesting HSM 130 (shown as "requestedPortIdentity"), and an ICV field (again shown as "ICV TLV"). Although these fields can be any suitable size, in this example, the sizes of these fields are 34, 10, 10, and approximately 30 octets, respectively. Notably, in the illustrated embodiment, the timestamp indicates the departure time of the Pdelay response 430 - that is, the value of the network time when the message 430 left the host. In some embodiments, the message 460 may include more (or fewer) elements than shown. Thus, as shown in follow-up 460B, a first nonce (shown as "slaveNonce TLV") and a second nonce (shown as "masterNonce TLV") may be included. In such an embodiment, the first nonce corresponds to the nonce included by the slave 400 in the request 400; the second nonce corresponds to the nonce included by the master in the response 430B. Figure 7B As described, the second master-provided nonce may be included to establish an association with the first slave-provided nonce. Upon confirming the association, the slave HSM 130 may determine the earlier received response 430B by confirming that the master-provided nonce in the message 430B matches the second nonce in the follow-up 460B. In some embodiments, the message 460 is an IEEE 802.1AS Pdelay follow-up frame having an ICV field, a slave-provided nonce, and / or a master-provided nonce appended to the end of the frame.

[0049] Now turn to Figure 5, depicting a diagram of an ICV field 500. As described above, the ICV field 500 includes an ICV for messages 300-460. In the illustrated embodiment, the field 500 additionally includes an identifier of the type of the field 500 (shown as "tlvType"), the length of the field 500 (shown as "lengthField"), a lifetime field indicating the length of time that the field 500 is valid (shown as "lifetimeId"), a replay counter indicating a number of links 112 that may be traversed (shown as "replayCounter"), an identifier of the ICV key 252 (shown as "keyId"), an identifier of the algorithm used to generate the ICV (shown as "algorithmId"), a reserved field, a padding field, and the ICV. In some embodiments, the ICV field 500 may include more (or fewer) elements than shown.

[0050] Now turn to Figure 6 , depicts a diagram of a nonce field 600. As described above, the nonce field 600 includes the nonce in messages 300 and 400. In the illustrated embodiment, field 600 additionally includes an identifier of the type of field 600 (shown as "tlvType"), the length of field 600 (shown as "lengthField"), a number indicating use since some initial state (shown as "nonceCount"), and the nonce (shown as "slaveNonce"). In some embodiments, the ICV field 600 may include more (or fewer) elements than shown.

[0051] Now turn to Fig. 7A , depicting the host (e.g., Figure 1 GM 140 or HSM130D in the Figure 1 1 and 1 . A communication diagram of time synchronization 700A between HSMs 130A, B, or D in FIG. 1 and 1 . In the illustrated embodiment, synchronization 700A includes a Pdelay exchange 154 for determining propagation delays followed by synchronization communication 152 to determine the offset between the clock of the master and the clock of the slave adjusted to the network time. In some embodiments, synchronization 700A may include the additional performance of communication 152 before repeating synchronization 700A.

[0052] As shown, the Pdelay exchange 154 may start the departure of the Pdelay request 400A at time T1, which includes the present and the ICV from the slave to the host. The slave may also store the timestamp of T1 (as shown in clock 132). At time T2, the request 400A arrives at the host, and the host verifies the ICV of the request 400A and stores the present for subsequent inclusion in the synchronous communication 152. At time T3, the host sends a Pdelay response 430A (as shown in clock 142) including the timestamp of T2, as well as the ICV to the slave. At time T4, the response 430A arrives at the slave, which confirms the ICV and stores the timestamp of T4. Subsequently, the Pdelay follow-up 460A including the timestamp of T3 arrives at the slave, which verifies the ICV. Then, the slave can determine the propagation delay by calculating the average of the difference between T4 and T3 and the difference between T2 and T1.

[0053] As shown, the synchronous communication 152 may begin at time T5, where the master sends a synchronization message 300 including a present and an ICV to the slave. At time T6, the synchronization message 300 arrives at the slave, which determines whether the message 300 is valid by verifying the ICV and confirming that the present included in the message 300 matches the earlier present included in the Pdelay request 400A. In some embodiments, the slave determines whether there is a match by comparing the present. In another embodiment, the slave determines whether there is a match by comparing the checksum generated based on the present - in some embodiments, these checksums may be included in one or more messages 400A, 300 and 350 instead of (or in addition to) including the present. Subsequently, the master sends a synchronization follow-up 350, which includes a timestamp of T5 and a copy of the earlier present of the slave, which verifies the present and ICV. If both the sync message 300 and the follow up 350 are valid, the slave calculates the offset between the master clock adjusted to the network time and its clock by adjusting the timestamp of T5 based on the previously determined propagation delay and determining the difference between the timestamp of T6 and the adjusted timestamp of T5.

[0054] In various embodiments, before using the determined offset to calculate the network time from the local clock 132, the slave also further performs a bounds check by comparing the calculated offset to another offset (e.g., an "expected" offset) calculated from the timestamps identifying T1-T4. In various embodiments, the slave calculates the expected offset by: 1) determining the midpoint 702A (the average of T1 and T4) and the midpoint 702B (the average of T2 and T3), and 2) determining the difference between the midpoints 702A and 702B to produce the expected offset. If the expected offset differs from the offset calculated from the synchronous communication 152 by more than a threshold value (the distance between T1 and the midpoint 702A in some embodiments), the offset calculated from the synchronous communication 152 is suspicious and can be discarded. However, if the difference between the offsets is less than (or equal to) the threshold value, the slave can continue to determine the network time based on the value of the local clock 132 and the offset calculated from the synchronous communication 152, and the determined network time can be provided to the node 120 as the time information 134.

[0055] Now turn to Figure 7B , depicts a communication diagram of another example of time synchronization 700B between a master (e.g., GM 140 or HSM 130D) and a slave (e.g., HSM 130A, B, or D). In the illustrated embodiment, synchronization 700B includes a Pdelay exchange 154 followed by a synchronization communication 152. Notably, synchronization 700B is similar to synchronization 700A, but its use of the present is different.

[0056] As shown, synchronization can start at time T1, wherein the slave sends a Pdelay request 400B including a first present (shown as present A), which arrives at the host at T2. At T3, the host sends a response 430B, which includes a timestamp of T2 and a second present (shown as Nonce B) received at T4. Then, the host sends a follow-up 460B to the response 430B, which includes the first present and the second present and the timestamp of T3. By including the first present and the second present in the follow-up 460B, the host establishes the association of the second present with the first present. Based on this association, the slave can then determine whether the response 430B received earlier is valid by comparing the second present in the response 430B with the second present in the follow-up 460 (which may include comparing the present and the checksum generated based on the present as described above). In other words, associating the first present and the second present in this way allows to verify the earlier message later, even if the host cannot include the first present due to timing constraints. In turn, being able to verify this earlier message prevents a malicious entity from replaying an older response 430B using some other nonce.

[0057] As shown, after authentication of messages 430B and 460B has been verified, synchronization 700B may proceed as discussed in synchronization 700A with the transmission of synchronization message 300 and subsequent message 350 both including a first nonce for authentication messages 300 and 350 .

[0058] Now turn to Figure 8 , depicts a flow diagram of a boundary check 800. Boundary check 800 is one example of a method for checking the boundaries of an offset determined from a timestamp in a synchronization message such as the synchronization follow-up 350 discussed above. In various embodiments, boundary check 800 is performed by a device having a first clock circuit (e.g., local clock 132) configured to maintain a first time value for coordinating traffic on a network and synchronization circuits such as HSM 130. In such embodiments, the device performing check 800 may act as a slave attempting to synchronize with a corresponding master.

[0059] In step 810, the synchronization circuit determines a propagation delay through the network for receiving synchronization information associated with a second clock circuit that maintains a second time value (e.g., network clock 142). In such embodiments, step 810 includes the synchronization circuit sending a first message (e.g., Pdelay request 400) through the network and receiving a second message (e.g., Pdelay response 430) through the network.

[0060] In step 820, the synchronization circuit determines an expected offset between the first time value and the second time value based on the departure time and arrival time of the first message (e.g., time T1 and T2) and the departure time and arrival time of the second message (e.g., time T3 and T4). In some embodiments, step 820 includes calculating a first average value (e.g., midpoint 702B) between the arrival time of the first message and the departure time of the second message, calculating a second average value (e.g., midpoint 702A) between the departure time of the first message and the arrival time of the second message, and determining a difference between the first average value and the second average value, the expected offset being the difference. In some embodiments, the synchronization circuit stores the departure time of the first message and the arrival time of the second message, and receives the arrival time of the first message in a second message (e.g., Pdelay response 430), and receives a third message including the departure time of the second message (e.g., Pdelay follow-up 460).

[0061] In step 830, the synchronization circuit receives synchronization information (e.g., synchronization communication 152) specifying a timestamp of a second time value. In some embodiments, the received synchronization information includes a third message (e.g., synchronization follow-up 350) specifying a timestamp and an integrity check value for a third message. In such embodiments, step 830 includes verifying the third message using the integrity check value. In some embodiments, the received synchronization information includes a fourth message (e.g., synchronization message 300) including a present time, and step 830 includes the synchronization circuit verifying the received synchronization information by comparing the present time with the present time sent in the first message. In some embodiments, the present time in the second frame is included in a field (e.g., present time field 600) attached to the end of the second frame, which has an integrity check value field (e.g., ICV field 500).

[0062] In step 840, the synchronization circuit determines whether the timestamp is valid by comparing the expected offset to the offset calculated based on the timestamp. An electronic control unit (ECU) transmits network traffic over a network based on the first time value and the calculated offset.

[0063] Now turn to Fig. 9A , depicts a flow diagram of an ICV check 900. The ICV check 900 is one example of a method for checking an ICV found in a synchronization message, such as the synchronization follow-up 350 discussed above. Although described below with respect to synchronization messages, other embodiments of the ICV check 900 may be performed with respect to other messages that include an ICV. In various embodiments, the ICV check 900 is performed by a receiver of a message that includes an ICV, such as the HSM 130; however, corresponding methods are also contemplated for a sender that generates a frame that includes an ICV.

[0064] In step 910, a security circuit utilizing a received synchronization message (e.g., synchronization follow-up 350) is checked, the synchronization message specifying a time value associated with a master clock (e.g., network clock 142) and an integrity check value of the message. In some embodiments, the ECU is configured to transmit traffic through the network according to the master clock of the network. In various embodiments, the network node includes a master clock and is configured to calculate the integrity check value using a key unique to the security circuit. In step 920, the security circuit determines whether the synchronization message is valid based on the integrity check value. In step 930, in response to determining that the synchronization message is valid, the security circuit provides time information (e.g., time information 134) associated with the time value to the ECU.

[0065] In some embodiments, checking 900 also includes determining a propagation delay between the safety circuit and the sender of the synchronization message by sending a first message requesting a response (e.g., Pdelay request 400) and receiving a second message including a response (e.g., Pdelay response 430). In such embodiments, the first message and the second message include an integrity check value. In various embodiments, in step 930, the time information is determined based on the propagation delay and the time value of the master clock. In some embodiments, the integrity check value is appended to the end of the first message and the second message (e.g., as Figure 4A and Figure 4B In some embodiments, the safety circuit calculates an offset based on a departure time of the first message and an arrival time of the second message, and determines whether the synchronization message is valid based on a comparison between the offset and an offset calculated based on the time value.

[0066] Now turn to Fig. 9B , depicts a flow diagram of a nonce check 950. Nonce check 950 is one example of a method for checking the nonce found in multiple frames such as the Pdelay request 400 and sync follow-up 350 discussed above. In various embodiments, nonce check 950 is performed by a slave attempting to synchronize its clock with the master's clock; however, corresponding methods are also contemplated for a master that receives the nonce and inserts it into another frame.

[0067] In step 960, the first circuit sends a first message (e.g., Pdelay request 400) including a first nonce to the second circuit. In such embodiments, the first circuit has a first clock (e.g., local clock 132) configured to maintain a local time value of a communication node coupled to a network, and the second circuit has a second clock (e.g., network clock 142) that maintains a network time value of the network. In some embodiments, the first message is sent during an exchange with the second circuit to determine a propagation delay between the first circuit and the second circuit.

[0068] In step 970, the first circuit receives a second message (e.g., sync message 300) from the second circuit, which includes a second nonce (e.g., slaveNonce TLV in sync message 300) and a timestamp identifying a network time value (e.g., Figure 3B In some embodiments, step 970 includes receiving a follow-up message of the second message from the second circuit, such that the timestamp is included in the follow-up message and indicates a network time value when the second message was sent from the second circuit.

[0069] In step 980, the first circuit compares the first nonce to the second nonce to determine whether the timestamp is valid. In some embodiments, the second message includes a cryptographic checksum for the second message, and step 980 includes a cryptographic circuit (e.g., cryptographic accelerator 240) of the first circuit verifying the cryptographic checksum using a key stored in the cryptographic circuit to determine whether the timestamp is valid.

[0070] In step 990, in response to determining that the timestamp is valid, the first circuit uses the timestamp to synchronize the first clock with the second clock. In some embodiments, the first circuit uses the timestamp to synchronize the first clock with the second clock by determining an offset between the first clock and the second clock based on the propagation delay and the timestamp. In some embodiments, step 980 includes 1) calculating an expected offset between the first clock and the second clock, such that the expected offset is calculated based on the timing information determined from the exchange discussed in step 960, and 2) verifying the determined offset by comparing the determined offset to the expected offset.

[0071] Exemplary Computer System

[0072] Now turn to Fig.10 , depicts a block diagram of an exemplary computer system 1000. Computer system 1000 is one embodiment of a computer system that may be used to implement one or more components of security network 100, such as node 120 or master host 140. In the illustrated embodiment, computer system 1000 includes a processor subsystem 1020, which is coupled to system memory 1040 and I / O interface 1060 via an interconnect 1080 (e.g., a system bus). I / O interface 1060 is coupled to one or more I / O devices 1070. Computer system 1000 may be any of a variety of types of devices, including, but not limited to, a server system, a personal computer system, a network computer, an embedded system, etc. Although for convenience, the computer system 1000 is described in detail below. Fig.10 A single computer system 1000 is shown in FIG. 1 , but system 1000 may also be implemented as two or more computer systems operating together.

[0073] Processor subsystem 1020 may include one or more processors or processing units. In various embodiments of computer system 1000, multiple instances of processor subsystem 1020 may be coupled to interconnect 1080. In various embodiments, processor subsystem 1020 (or each processor unit within 1020) may include a cache or other form of onboard memory.

[0074] The system memory 1040 is available to store program instructions that can be executed by the processor subsystem 1020 to enable the system 1000 to perform the various operations described herein. The system memory 1040 can be implemented using different physical, non-transitory storage media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. The memory in the computer system 1000 is not limited to a main storage device such as memory 1040. Instead, the computer system 1000 may also include other forms of storage devices, such as cache memory in the processor subsystem 1020 and auxiliary storage devices (e.g., hard disk drives, storage arrays, etc.) on the I / O devices 1070. In some embodiments, these other forms of storage devices may also store program instructions that can be executed by the processor subsystem 1020 to perform the operations described herein.

[0075] According to various embodiments, I / O interface 1060 can be any of various types of interfaces configured to be coupled to and communicate with other devices. In one embodiment, I / O interface 1060 is a bridge chip (e.g., a south bridge) from the front side to one or more back side buses. I / O interface 1060 can be coupled to one or more I / O devices 1070 via one or more corresponding buses or other interfaces. Examples of I / O devices 1070 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs or their associated controllers), network interface devices (e.g., to local or wide area networks), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system 1000 is coupled to a network via network interface device 1070 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0076] ***

[0077] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even when only a single embodiment is described with respect to specific features. The feature examples provided in this disclosure are intended to be illustrative, not limiting, unless otherwise stated. The above description is intended to cover such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art who are aware of the effective effects of the present disclosure.

[0078] The scope of the present disclosure includes any feature or combination of features disclosed herein (explicitly or implicitly) or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be made during the prosecution of this patent application (or a patent application claiming priority thereto) for any such combination of features. In particular, with reference to the appended claims, features of the dependent claims may be combined with features of the independent claims, and features from the corresponding independent claims may be combined in any appropriate manner and not just by the specific combinations listed in the appended claims.

Claims

1. A device comprising: a first clock circuit configured to maintain a first time value associated with a network; A synchronization circuit, wherein the synchronization circuit is configured to: determining a propagation delay through a network for receiving synchronization information associated with a second clock circuit maintaining a second time value, wherein determining the propagation delay includes the synchronization circuit sending a first message through the network and receiving a second message through the network; determining an expected offset between the first time value and the second time value based on a departure time and an arrival time of the first message and a departure time and an arrival time of the second message; receiving synchronization information specifying a timestamp of the second time value; as well as Determining whether the timestamp is valid by comparing the expected offset with an offset calculated based on the timestamp, wherein determining whether the timestamp is valid comprises: If the difference between the expected offset and the offset calculated based on the timestamp exceeds a certain threshold, the timestamp is determined to be invalid.

2. The apparatus of claim 1 , wherein determining the expected offset comprises: calculating a first average between the arrival time of the first message and the departure time of the second message; calculating a second average between the departure time of the first message and the arrival time of the second message; as well as A difference between the first average and the second average is determined, wherein the expected deviation is the difference.

3. The apparatus according to claim 2, wherein the synchronization circuit is configured to: storing the departure time of the first message and the arrival time of the second message; receiving the arrival time of the first message within the second message; and A third message is received, the third message including the departure time of the second message.

4. The apparatus of claim 1 , wherein the received synchronization information includes a third message specifying a timestamp and an integrity check value of the third message; and The synchronization circuit is configured to verify the third message using the integrity check value.

5. The apparatus of claim 4, wherein the received synchronization information comprises a fourth message including a current time; and Wherein the synchronization circuit is configured to verify the received synchronization information by comparing the nonce with the nonce sent in the first message.

6. The apparatus of claim 5, wherein the nonce in the second message is included in a field appended to the end of the second message, the field having an integrity check value field.

7. The apparatus according to claim 1, further comprising: An electronic control unit (ECU) is configured to transmit network traffic over the network based on the first time value and the calculated offset.

Images