Replay protection using synchronized shared network counters

Abstract

A method for replay protection in a network (100). The method includes (102) storing a maintenance counter value in a device, (104) obtaining a counter value from a message sent by another device, (110) storing the counter value as the maintenance counter value if the counter value is greater than the maintenance counter value (160), and (114) starting a timer function if the counter value is less than the maintenance counter value (120). The timer function includes (124) comparing the additional counter value with the maintenance counter value if a further message containing an additional counter value is received before the timer expires (106), storing the additional counter value as the maintenance counter value if the additional counter value is greater than the maintenance counter value, (126) stopping the timer, and (122) broadcasting a counter beacon message containing the maintenance counter value if the timer has expired (128).

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for replay protection in a device that is part of a network of communicatively connected devices. The present disclosure further relates to a device and a network implementing the method. The present disclosure further relates to a computer program and a computer-readable storage medium incorporating the method.

Background Art

[0002] One important aspect of securing communication between devices is replay protection. Replay protection is particularly important for Internet-of-Things (IoT) devices. A replay attack is a type of network attack in which a valid data transmission is maliciously repeated or delayed. Known communication protocols such as Zigbee (registered trademark), Bluetooth (registered trademark) Low Emission (BLE), KNX, Matter, WiFi (registered trademark), etc. include some form of replay protection.

[0003] A typical implementation of replay protection utilizes message counters. Each device sending a message records its own "outgoing" counter. The outgoing counter is incremented before sending the message. The outgoing counter is included in the message as clear text and is also typically used to generate a MIC (Message Integrity Code). The MIC allows the receiver to verify whether any part of the message has been altered. A typical message payload consists of a receiver ID, sender ID, message counter, encrypted message, and MIC. The receiver records a "last received counter" for each sender. Upon receiving a message, the receiver accepts it if its message counter is greater than the message sender's "last received counter," otherwise the receiver rejects the message as a replay.

[0004] Such replay protection mechanisms have several drawbacks, particularly in terms of working memory (e.g., RAM), storage memory (e.g., flash memory), and processing performance requirements. Each receiver must track the "last received counter" for all senders on the network, which is a particularly demanding requirement for IoT devices in large IoT networks. For example, with 1000 devices and using 32-bit counters and 16-bit device IDs, approximately 6KB of RAM would be needed to track the last received counter for each source of every device in the network. This can be difficult to implement for low-spec IoT devices. In the ideal case, devices should store the last received counter in NVRAM. This allows for protection against replay when the device is powered up. Similar to RAM, 6KB of NVRAM can be difficult to implement in a typical IoT device.

[0005] Two devices may synchronize their counters. For example, if a sender (device 1) sends a message to a receiver (device 2), and the receiver does not have device 1's last used counter, the receiver will typically defer message verification, trigger a synchronization protocol to obtain device 1's counter, and then process the received message. This is typically implemented as a two-message protocol. Using this protocol allows devices to not store message counters in NVRAM and to perform a synchronization protocol for messages from unknown senders. Synchronization protocols can work very well when the majority of messages on a network are unicast (one-to-one messages). If it is done only once and the receiver does not need to track the last used counter in RAM, a small performance penalty is acceptable. Such synchronization protocols become problematic in the case of broadcast communications (one-to-many messages) where one broadcast message can trigger synchronization protocols by thousands of receivers.

[0006] US2018183591A1 relates to a network node having normal mode and coordinator mode. The network node includes a counter and an increment unit, the increment unit incrementing the counter at regular time intervals. The network node switches to coordinator mode if it does not receive a counter synchronization message. [Overview of the project] [Problems that the invention aims to solve]

[0007] As outlined in the background section, known message replay protection mechanisms based on per-sender "outgoing" counters and tracking of these counters by receivers can be significantly disadvantageous for networks with a large number of devices, especially when communication protocols utilize broadcast messages. These disadvantages apply to standards such as Zigbee®, BLE Mesh, KNX, and Matter. [Means for solving the problem]

[0008] To overcome the shortcomings of prior art, this disclosure provides a replay protection mechanism based on a single, network-wide shared message counter, instead of the known mechanism in which each device records its own sending counter. The mechanism of this disclosure significantly reduces the resource requirements of network devices. Instead of tracking thousands of counters, devices can essentially maintain one synchronized, shared counter.

[0009] The following is an overview of the specific examples of embodiments disclosed herein. These embodiments are presented solely to provide the reader with a brief overview of these particular embodiments, and it should be understood that they are not intended to limit the scope of this disclosure. In fact, this disclosure may encompass various embodiments and / or combinations of embodiments not shown herein.

[0010] One aspect of this disclosure provides a computer-implemented method of replay protection. The method may be implemented on a device among several communicably connected devices operating in a broadcasting network. The method may include storing a maintained counter value in memory. The method may further include obtaining a received counter value from a message received over the broadcasting network. The method may further include comparing the received counter value with the maintained counter value to obtain a comparison result. Depending on the comparison result, the method may further include storing the received counter value as the maintained counter value if the received counter value is greater than the maintained counter value, and starting timer processing if the received counter value is less than the maintained counter value. The timer processing may further include starting a timer. The timer processing may further include comparing the received additional counter value with the maintained counter value if a further message containing an additional counter value is received over the broadcasting network before the timer expires. If a further received counter value is greater than the maintained counter value, the received further counter value may be stored as the maintained counter value, and the timer and / or timer processing may be stopped. The timer processing may further include, when the timer expires, sending a counter beacon message via the broadcasting network containing the maintained counter value (i.e., the value that has not been altered by the received counter value or the further received counter value), so that other devices can synchronize their maintained time value with the maintained timer value of this device.

[0011] Messages and / or further messages received via the broadcasting network may be data messages or counter beacon messages sent by another device within the broadcasting network.

[0012] Thus, a single, shared message counter may be used in the network, and this single shared message counter may be stored and updated as a maintenance counter value on each device. The device's maintenance counter value may be updated each time the device sends a data message or receives a message from another device in the network, and the counter value in the received message may be compared against the maintenance counter value for replay protection.

[0013] An incoming message can be a broadcast message containing the current counter value of one of several devices, i.e., the counter value stored as a maintenance counter value in the other devices, so that all devices can update (synchronize) their own maintenance counter values. Alternatively, an incoming message can be a message addressed to that device, which can contain the counter value and any format of content for that device. In the latter case in particular, the receiving device may broadcast a counter beacon message containing the updated message counter to all other devices to synchronize the maintenance counter values ​​in each device.

[0014] If the received counter value is smaller than the maintenance counter value, the message counter may need to be synchronized across all devices. In this case, the current device may broadcast its own maintenance counter value. To avoid network overflooding with counter beacon messages containing the current counter value, the timer processing of this disclosure allows other devices to communicate their maintenance counter values ​​before a device transmits its own. If another device shows a higher counter value within the timer period, the device can update its own maintenance counter value and no longer needs to transmit a counter beacon message.

[0015] In one embodiment, a message may include a counter value and content, and / or a further message may include a further counter value and content. The content may be data of any format and purpose, typically data intended for the receiving device. The method may further include, when a message is sent to the device by one of several devices, accepting the content if the received counter value or the further received counter value is greater than the maintenance counter value, and rejecting the content if the received counter value or the further received counter value is less than or equal to the maintenance counter value. In this embodiment, the message is unicast to the device, for example.

[0016] In an alternative embodiment, a message may include a counter value and further content, and / or a further message may include a further counter value and further content. The further content may be data of any form and purpose, typically data intended for the receiving device. The method may further include, when a message is sent to a device by one of several devices, accepting the content of a message if the received counter value is greater than the maintenance counter value minus a predetermined delta value, and rejecting the content if the received counter value is less than or equal to the maintenance counter value minus a predetermined delta value. The delta value allows one or more sending devices to have a typically temporary offset to the counter value without their message being identified as a replay attack.

[0017] In one embodiment, the method may further include incrementing a maintenance counter value to obtain an incremented counter value before sending a data message. The method may further include sending a data message over a broadcasting network, the data message containing the incremented counter value. The maintenance counter value is updated with the incremented counter value. The data message may also be a different type of message other than a counter beacon message, for example, for control and signaling.

[0018] In one embodiment, the duration of the timer is set according to the difference between the received counter value and the maintained counter value.

[0019] In one embodiment, the timer duration and the difference between the received counter value and the maintained counter value may be inversely proportional. This allows the timer to be set to a longer time interval when the difference is small, and vice versa.

[0020] In one embodiment, the duration of the timer may be randomized.

[0021] In one embodiment, the method may further include storing a maintenance counter value in the device's non-volatile memory. This allows the device to power cycle without losing its last known maintenance counter value.

[0022] In one embodiment, the method may further include initializing the device. Initialization may include loading a maintenance counter value from non-volatile memory. The method may further include starting an initialization timer. If the initialization timer expires without detecting or receiving a message, the method may further include sending a counter beacon message containing the maintenance counter value over the broadcasting network. This allows the maintenance counter value to be synchronized with all other devices, while the initialization timer prevents network overflooding by counter beacon messages from the device being initialized.

[0023] According to one aspect of this disclosure, a device is provided. The device may include means for performing a method of one or more embodiments of the embodiments described above.

[0024] In one embodiment, the device may be an IoT (Internet of Things) device. The IoT device may be, for example, a smart lighting device or any other IoT device.

[0025] According to one aspect of this disclosure, a broadcasting network is provided. The network may include two or more of the devices described above.

[0026] According to one aspect of the present disclosure, a computer program is provided. The computer program may include instructions that cause one or more processors to execute the method of one or more of the above-described embodiments when the program is executed by the one or more processors.

[0027] According to one aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium may include instructions that cause one or more processors to execute the method of one or more of the above-described embodiments when the medium is executed by the one or more processors.

Brief Description of the Drawings

[0028] Here, embodiments of the present disclosure will be described merely as examples with reference to the accompanying schematic diagrams in which corresponding reference numerals indicate corresponding parts. The drawings are for illustrative purposes only and do not limit the scope of protection defined by the claims. [Figure 1] A flowchart of an exemplary method of the present disclosure is shown. [Figure 2] A flowchart of another exemplary method of the present disclosure is shown. [Figure 3] An exemplary state machine of an active device of the present disclosure is shown. [Figure 4] An exemplary state machine of a device for initializing the present disclosure is shown. [Figure 5] An exemplary network topology including a device for implementing the method of the present disclosure is shown. [Figure 6] An exemplary computing system for implementing a particular aspect of the present disclosure is shown.

Modes for Carrying Out the Invention

[0029] It will be readily apparent that the components of the embodiments generally described herein and shown in the accompanying drawings can be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the various embodiments shown in the drawings is not intended to limit the scope of this disclosure, but is merely representative of the various embodiments. Although various aspects of the embodiments are presented in the drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0030] The embodiments described herein are in all respects merely illustrative and should not be constrained. Therefore, the scope of this disclosure is indicated not by this detailed description but by the appended claims. All modifications within the meaning and scope of the equivalents of the claims should be incorporated within the scope of the present invention.

[0031] Throughout this Specification, references to features, advantages, or similar terms do not imply that all features and advantages that may be realized in this Disclosure are or are present in any single example of this Disclosure. Rather, terms referring to features and advantages should be understood to mean that certain features, advantages, or characteristics described in relation to embodiments are included in at least one embodiment of this Disclosure. Thus, discussions of features and advantages, as well as similar terms, throughout this Specification may, but not necessarily, refer to the same examples.

[0032] Furthermore, the features, advantages, and characteristics described herein may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the invention may be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that are not presented in all embodiments of the herein. Throughout this specification, references to “one embodiment,” “an embodiment,” or similar wording mean that a particular feature, structure, or characteristic described in relation to a shown embodiment is included in at least one embodiment of the herein. Thus, throughout this specification, the phrases “in one embodiment,” “in an embodiment,” and similar wording may all, though not necessarily, refer to the same embodiment.

[0033] This invention focuses on designing a replay protection mechanism that uses a single, shared, message counter across the entire network, rather than the standard mechanism where each device has its own sending counter. This mechanism significantly reduces the resource requirements of network devices. Instead of tracking thousands of counters, devices essentially maintain one synchronized counter.

[0034] This disclosure enables shared counter replay protection, where devices in a network track a single shared message counter. Different networks may have their own message counters, which can be used by all devices in that network. The message counters may be synchronized between devices in the network by sending broadcast messages. When a unicast message is sent to one or more devices in the network, the shared message counter may be incremented for each message sent. A device may detect all network messages, including unicast and broadcast messages sent to other devices, so that each device can track the shared message counter. Each device may store the message counter as a maintenance counter value. Incoming messages with a counter value greater than the maintenance counter value may be accepted. Incoming messages with a counter value less than or equal to the maintenance counter value may be replay messages and therefore should not be accepted and may be ignored.

[0035] This disclosure provides a measure to prevent network flooding caused by update messages, also known as "counter beacon messages," for synchronizing maintenance counter values ​​across multiple devices.

[0036] A device may conditionally accept messages with small counter values ​​using a delta value, for example, to handle communication errors. This disclosure provides measures to protect against replay when such messages are conditionally accepted.

[0037] This disclosure enables a device to synchronize a shared message counter when powered up. To this end, the device may periodically store the maintenance counter value in non-volatile memory, such as NVRAM.

[0038] Figure 1 shows an exemplary embodiment of process 100 of the present disclosure. The process may be computer-implemented in a device, for example, an IoT device. The device may be part of a network that includes other devices implementing process 100. The process enables replay protection by utilizing a message counter shared among devices in the network.

[0039] In step 102, the current message counter is stored in the device's memory as a maintenance counter value, and the device is waiting for a message. The maintenance counter value may be stored in any suitable data format.

[0040] Each time a device sends a message to another device, for example as a unicast message, the message counter may be incremented (130), and the incremented message counter may be stored as a maintenance counter value (step 102). In step 132, a message containing the incremented message counter may be sent.

[0041] Preferably, devices in the network, including devices not directly addressed by the message, may detect the message and obtain a counter value from it. For this purpose, the counter value may be included in the message as clear text so that any device can read the counter value from the message. Any other content may be included in the message, either in clear text or encrypted for the receiving device. Step 104 shows that a device obtains a counter value from a message sent by any of the devices in the network.

[0042] Steps 110, 112, and 114 represent different comparison steps in which a counter value (104) obtained from a message may be compared with a maintenance counter value (102). In step 110, it may be determined whether the received counter value is greater than the maintenance counter value. In step 112, it may be determined whether the received counter value is equal to the maintenance counter value. In step 114, it may be determined whether the received counter value is less than the maintenance counter value.

[0043] It will be understood that the order of steps 110-114 may differ. Furthermore, steps 110-114 may be performed in any known computer implementation format.

[0044] If the received counter value is determined to be greater than the maintenance counter value (step 110), it may be concluded that the received message is not a replayed or delayed message and can be accepted. In step 116, the maintenance counter value may be updated to the received counter value. If the received message is a broadcast message for synchronizing maintenance counter values ​​in the network, or a message not addressed to this device, such as a unicast message, the process may return to step 102 and wait for another message. If the message is addressed to this device, for example as a unicast message, the message may be accepted (117), and its content may be further processed by the device. This further processing of the message content is outside the scope of this disclosure and will not be described further.

[0045] If the received counter value is determined to be equal to the maintained counter value (step 112), the message may be ignored (118), and the process may return to step 102.

[0046] If it is determined that the received counter value is smaller than the maintained counter value (step 114), there may be an out-of-sync counter value on one or more devices in the network, and the device may decide to broadcast a message containing the maintained counter value (as in step 102) to update the counter values ​​maintained by the other devices to this maintained counter value. To avoid network flooding by such sync messages, each device may implement a timer process (120-129). The timer process may decide to broadcast the sync message unless further messages with further counter values ​​greater than the maintained counter value are received within the timer period. If further messages with further counter values ​​greater than the maintained counter value are received within the timer period, the sync message is no longer needed.

[0047] In step 120, the timer may be started. The timer interval may be pre-set or conditionally set, as will be further described below.

[0048] In step 122, it may be determined whether the timer has expired. If the timer has expired and no further messages containing a further counter value greater than the maintenance counter value have been received, the device may broadcast its maintenance counter value to other devices (as in step 102) (128). In this case, any further messages received containing an incorrect further counter value may be rejected (129).

[0049] In step 106, a further message may be received, and a further counter value may be obtained from the further message. In step 124, if the further counter value is less than or equal to the maintenance counter value, the message may be ignored, and the process may wait for another further message until the timer expires. If the further counter value is greater than the maintenance counter value, the received counter value may be stored as the maintenance counter value (126), i.e., the maintenance counter value may be updated with the received further counter value. In this case, the device no longer needs to send a synchronization message to other devices, i.e., step 128 can be avoided.

[0050] It will be understood that the order of steps 122 and 124 may differ. Furthermore, steps 122 and 124 may be performed in any known computer implementation format.

[0051] If a further message is addressed to this device, for example as a unicast message, the further message may be accepted (127), as in step 117, and its content may be further processed by the device.

[0052] For optimal operation of the shared message counter, it is preferable that the receiver (i.e., a device in the network that receives messages containing the counter value) processes all messages (e.g., as in 104 and 106) so that the counter value used in the network can be tracked. Typically, processing only messages destined for the receiver is insufficient. All messages may be tracked, for example, by reading all messages on the network bus in promiscuous mode.

[0053] Before sending a message, the device typically composes the message, queues it, and waits to send it when media becomes available. The message includes a counter value, possibly message content (typically encrypted), and possibly a MIC.

[0054] Shared message counters, maintained by a sustained counter value, can go out of sync for several reasons. Depending on the way to access the network media, messages with higher counter values ​​may be sent before messages with lower counter values. Two (or more) devices may attempt to send data simultaneously: in this case, collisions can occur, and the receiver may not be able to process either message correctly. If two (or more) devices increment the counter while none of the receivers do, this can lead to a "rollback" of the counter value on the media. Messages may be delayed in the sending queue. For example, some receivers may simply miss broadcast messages due to power failures, network media failures, sampling timing, etc.

[0055] To address such mis-synchronization scenarios, the timer processes (120-129) ensure that the network is not flooded with synchronization messages to synchronize the maintenance counter values ​​in such cases. Furthermore, devices may be permitted to send and receive messages containing lower counter values ​​offset by delta values, as further described below.

[0056] A receiver may be permitted to accept a message containing a previous counter value. In such a case, the counter value of the message is expected to be greater than the maintenance counter value minus the delta value. The delta value should be as small as possible. The delta value may depend on how many consecutive messages the device is expected to miss (e.g., based on collisions and missed messages). Alternatively or additionally, the delta value may depend on the number of times the device has failed to send a queued message due to, for example, a burst of traffic. For example, if such a situation occurs rarely and the system behavior when correctly sent messages are ignored is acceptable, the delta value may be set to 0 (zero), i.e., the delta may not be permitted.

[0057] By allowing offset counter values, i.e., accepting messages with counter values ​​>= maintained counter value - delta value, an attacker could potentially listen to and replay a message multiple times (i.e., until the shared message counter maintained as the maintained message counter exceeds the message counter + delta). This could be particularly undesirable for certain types of messages, such as toggle-on / off messages.

[0058] To avoid replay attacks when offset counter values ​​are allowed, a device may track on a source-by-source basis whether a counter value has been used previously. For example, if a device receives a message from a sender with a counter value equal to the maintenance counter value - 2, the device may be configured to accept only subsequent messages from the same sender with a counter value greater than or equal to the maintenance counter value - 1. Unlike known solutions where separate counter values ​​are tracked per source, this replay protection when offset counter values ​​are allowed has much lower resource requirements. A table may be implemented with used counter values ​​per source. The table may slide as the maintenance counter value increases, and tracked counters below the maintenance counter value - delta value may be removed from the table. For example, device X may send a message with a counter value equal to the maintenance counter value instead of using a counter value equal to the maintenance counter value + 1 (i.e., the maintenance counter value has already been used and the next message should have a larger counter value). For all other devices, device X may be stored in the table at the position of counter value - 0. When a new message is received from another device, this entry slides in the counter value -1, counter value -2, ... until it drops to counter delta. Once it drops to counter delta, device X may be removed from the table. By using a sliding table, for example, a device identifier can be stored in a table position that indicates its position relative to the delta value without actually storing the counter value. Thus, the size of the table can be limited.

[0059] Figure 2 shows an exemplary embodiment of the process for allowing an offset counter value. In the example in Figure 2, steps 112 and 114 in Figure 1 are replaced by step 210. In Figure 2, the dashed lines indicate the steps before and after step 110 and after step 120, and these steps may be the same as or identical to the steps shown in Figure 1.

[0060] In step 210, the received counter value 104 may be compared with the individual counter value 202 for each source. If the counter value 104 is greater than the individual counter value 202, the message may be accepted (220), and the process may proceed to step 120. If the counter value 104 is less than or equal to the individual counter value 202, the message may be discarded (230), and the process may proceed to step 120.

[0061] The individual counter value 202 may be stored in a table, for example, the slide table described above. Each time the maintenance counter value is incremented, the slide table of individual counter values ​​may be updated, and if individual counter value < maintenance counter value - delta value, individual counter value 202 can be removed from the table. This may be achieved by dropping it from the table by comparing the values ​​or by pushing the device identifier from the table.

[0062] In an exemplary use case, a device may not know the current value of a network's shared message counter when it wakes up from sleep mode or powers on. In this case, the device may trigger a counter synchronization protocol and send a broadcast message, for example, in the form of a "Counter Beacon" (CB). This CB contains the device's last known counter value, i.e., a maintenance counter value stored in the device's NVRAM, etc. All devices that receive a CB message may respond as follows: if maintenance counter value < received counter value, take over the new received counter value; if maintenance counter value = received counter value, ignore the message; and if maintenance counter value > received counter value, start a timer with a random duration for a potential response from its own CB message. The random duration may be used as the timer and may depend on the difference in counter values ​​(maintenance counter value - received counter value). The larger the difference, the shorter the timer may be. If a message (functional or broadcast) with a counter value higher than the maintenance counter value is received during the timer period, the device may update its own maintenance counter value and cancel the CB response timer.

[0063] During normal operation, all devices typically update their maintenance counter values ​​based on the counter values ​​received from authenticated functional messages.

[0064] The maintenance counter value may be stored in RAM. Preferably, the maintenance counter value is stored in NVRAM, so that the device can power cycle without losing its maintenance counter value. NVRAM may be used instead of RAM, or in addition to RAM. For example, to reduce flash wear-out, the device implementation may apply the storage of the maintenance counter value in RAM and also store the maintenance counter value in NVRAM in block units. For example, the maintenance counter value may be stored in NVRAM every n counts. For example, if n = 1024, when the counter value = 1, the maintenance counter value may be stored in NVRAM as, for example, 1024; when the counter value = 1025, the maintenance counter value may be stored as 2048; and for counter values ​​from 2 to 1024, the maintenance counter value may not be stored in NVRAM.

[0065] In one example, the counter value and the maintenance counter value may be 4 bytes in size. For example, in large-scale networks including thousands or more devices, and / or when jumps in the maintenance counter value are permitted due to the aforementioned power-up and NVRAM depletion solutions, larger counter values, e.g., 5-6 bytes, may be used. 4-6 byte counter values ​​are particularly suitable for use in IoT devices.

[0066] An exemplary broadcast message for synchronizing the maintenance counter values ​​of devices in a network, e.g., a CB message, may include the following data fields: (i) a header containing one or more flags indicating a counter synchronization protocol, a destination address in the form of a broadcast address, and the source address of the device; (ii) a counter value equal to the last known counter value (i.e., the maintenance counter value stored in the device); (iii) an optional, preferably encrypted, payload; and (iv) an MIC.

[0067] Figure 3 shows an exemplary counter synchronization state machine 300 of the device in its operating mode. The following states and state transitions are shown:

[0068] 310: Operating status.

[0069] 311: If a normal message is received with a counter value = <maintenance counter value, ignore the message, or if a normal message is received with a counter value > maintenance counter value, update the maintenance counter value.

[0070] 312: When a broadcast message with a counter value < maintenance counter value is received, the system transitions to synchronization-with-response state 320.

[0071] 313: If a broadcast message with a counter value equal to the maintenance counter value is received, the system transitions to a synchronization-without-response state 330.

[0072] 314: When a broadcast message is received where the counter value > the maintenance counter value, the maintenance counter value is updated and the system transitions to the unresponsive synchronization state 330.

[0073] 320: Synchronized state with response. When this state is entered, timer T1 may be started.

[0074] 321: If a broadcast message or regular message is received where the counter value is less than the maintenance counter value, the message is ignored.

[0075] 322: If a broadcast message is received where the counter value >= the maintenance counter value, the maintenance counter value is updated and the system transitions to the unresponsive synchronization state 330.

[0076] 323: When a normal message is received in which the counter value >= the maintenance counter value, the maintenance counter value is updated and the system transitions to the unresponsive synchronization state 330.

[0077] 324: When Timer T1 expires, a message containing the maintenance counter value is broadcast, and the system transitions to unresponsive synchronization state 330.

[0078] 330: No response, synchronous state. Timer T2 may be started when this state is entered.

[0079] 331: If a normal or broadcast message is received where the counter value > the maintenance counter value, update the maintenance counter value; otherwise, if a normal or broadcast message is received where the counter value = < the maintenance counter value, ignore the message.

[0080] 332: When Timer T2 expires, the system transitions to operating state 310.

[0081] Operational state 310 may be a normal operating state in which the device sends and responds to messages. The device may monitor traffic and update its maintenance counter value as follows: increment the counter before sending any messages except broadcast (e.g., CB) messages, and update the counter if a received message is authenticated and the counter is greater than the current maintenance counter value.

[0082] Broadcast messages, such as CB messages, may be processed differently from normal messages. If the CB receive counter value > the maintenance counter value, the maintenance counter value may be updated, and the system may enter the no-response synchronization state 330. If the CB receive counter value = the maintenance counter value, the system may enter the no-response synchronization state 330. If the CB receive counter value < the maintenance counter value, the system may enter the responsive synchronization state 320. The latter may be a primary use case where another device is powered up, the counter value is unknown, and thus synchronization is triggered by sending a CB message.

[0083] The purpose of the synchronous response state 320 may be to randomize the CB response delays of all receivers, minimize network traffic, and thus prevent network flooding by synchronous broadcast messages. If all devices attempt to respond immediately with their counter beacons, it will cause an avalanche of responses, with only one relevant (i.e., the first CB with the highest counter value). Furthermore, the device with the highest counter value may be blocked from actually sending a CB: that CB may be delayed across many sending slots in the sending queue.

[0084] Timer T1 in state 320 is an example of a timer used in timer functions 120-129 in Figure 1. In non-restrictive examples, Timer T1 may be set depending on a delta counter, which may be calculated as follows: delta counter = maintain counter - receive counter. In one example, if delta counter > 1000, the random response time T1 may be set to 100ms-200ms. In this example, if delta counter > 100, the random response time T1 may be set to 200ms-300ms. In this example, if delta counter > 10, the random response time T1 may be set to 300ms-400ms. In this example, if delta counter >= 1, the random response time T1 may be set to 400ms-500ms. It will be understood that other criteria and timer values ​​may be used as preferred for the network.

[0085] In another non-restrictive example, timer T1 may be set using an expression such as T1 = (500ms - log(delta counter) * 100ms) (minimum value is 100ms) + (random value between 0 and 1) * 100ms. It will be understood that other values ​​may be used for 500ms and 100ms, as is preferable for the network.

[0086] In another non-restrictive example, if a responder is the "last sender," Timer T1 may be set to a random value, for example, a random value between 0 and 100 ms. The concept of "last sender" can minimize traffic during synchronization protocols. A device may assume it is the "last sender" when it sends a message (normal or CB). A device may assume it is no longer the "last sender" when it receives a message (normal or CB) with a counter value greater than or equal to the maintenance counter value. A device during wake-up or power-on is typically not the "last sender." Preferably, only one device assumes it is the "last sender," but due to bus collisions, missed messages, sending queues, etc., it is possible that no device assumes this status or that multiple devices assume this status. Advantageously, the "last sender" may have the shortest random delay time to respond to CB messages, thus minimizing traffic and synchronization time.

[0087] In the responsive synchronization state 320, a CB with a received counter value < a sustained counter value may not affect the state machine. In this case, another device may have responded to the initial CB, and the response may be faster due to randomized time.

[0088] In the responsive synchronous state 320, a CB with a received counter value >= the sustained counter value may result in a switch to the unresponsive synchronous state 330. The device no longer needs to respond because some other device with the same / higher sustained counter value may have already responded. If the received counter value is higher, the device may update its own sustained counter value.

[0089] In responsive synchronization state 320, a normal message with received counter value < sustained counter value may not affect the state machine, but the device may wait to send its own beacon. Note that received messages may still be accepted for execution based on the rules of counter delta handling.

[0090] In the responsive synchronization state 320, a normal message with a received counter value >= the maintenance counter value may result in the device no longer needing to send a CB, and the device may switch to the unresponsive synchronization state 330 and update its own maintenance counter value.

[0091] When Timer T1 expires, the device may create a CB containing its own maintenance counter value and place the CB in a sending queue for broadcast to the network.

[0092] The purpose of the unresponsive synchronization state 330 may be to block the re-triggering of the synchronization protocol (potential infinite loop) caused by delayed CB messages in the sending queue. State 330 may also provide a delayed return to operational state 310 if the device does not respond to a CB message with a counter value lower than a specified time period T2 (for example, using timer T2).

[0093] In the following example, the first device starts synchronizing with beacon counter = 1000 (e.g., CB counter value = 1000). In this example, 50 devices might have a sustained counter value of 1001, another 50 devices might have a sustained counter value of 1002, and yet another 50 devices might have a sustained counter value of 1003. Due to random timing T1, all other devices might attempt to send beacons at similar times, and many devices might place beacons with counter values ​​1001, 1002, and 1003 into the sending queue. The first CB response on the bus (e.g., from the second device) might have a counter value of 1003. This is the best-case scenario as it represents the highest counter value in the network. Devices that have not yet placed a message in the queue may back off and return to operational state 310. Effectively, all devices in the network should be in operational state 310 at this point. On the other hand, if one of the devices with a maintenance counter value of 1001 sends a message, this may trigger the synchronization protocol again, and all devices with maintenance counter values ​​of 1002 or 1003 will still attempt to respond.

[0094] In the unresponsive synchronization state 330, Timer T2 may be used to set an amount of time that allows the message to remain in the sending queue before the sender discards it.

[0095] Figure 4 shows an exemplary power-up state machine 400 applicable when a device powers up after sleep mode or turns on after being powered off. The following states and state transitions are shown:

[0096] 401: Power up the device from sleep mode or powered off mode.

[0097] 410: Startup state. Timer T3 may start when the system enters this state.

[0098] 411: If a normal message is received that has a retained counter value (e.g., stored in NVRAM), ignore the message.

[0099] 412: When a normal message is received in which the counter value > maintenance counter value, the maintenance counter value is updated and the system transitions to operating state 440. Operating state 440 may be the same as or identical to operating state 310 in Figure 3.

[0100] 413: When a broadcast message is received where the counter value is less than the maintenance counter value, the system transitions to synchronous state 420 with response.

[0101] 414: When a broadcast message is received where the counter value >= the maintenance counter value, the maintenance counter value is updated and the system transitions to unresponsive synchronization state 430.

[0102] 415: When Timer T3 expires, a synchronization message containing the maintenance counter value, such as a CB message, is broadcast, and the system transitions to unresponsive synchronization state 430.

[0103] 420: Synchronized state with response. Timer T4 may be started when this state is entered.

[0104] 421: If a broadcast message or regular message is received where the counter value is less than the maintenance counter value, the message is ignored.

[0105] 422: If a normal message is received where the counter value >= the maintenance counter value, the system transitions to unresponsive synchronization state 430.

[0106] 423: If a broadcast message is received with a counter value >= the maintenance counter value, the system transitions to unresponsive synchronization state 430.

[0107] 424: When Timer T4 expires, broadcast a message containing the maintenance counter value and transition to unresponsive synchronization state 430.

[0108] 430: No response, synchronous state. Timer T5 may be started when this state is entered.

[0109] 431: If a normal or broadcast message is received where counter value > maintenance counter value, update the maintenance counter value; or if a normal or broadcast message is received where counter value = < maintenance counter value, ignore the message; or if timer T5 expires and there is a repeat, broadcast a message containing the maintenance counter value.

[0110] 432: When Timer T5 expires and there are no repetitions, the system transitions to the operating state.

[0111] 440: Operating state. When this state is entered, the app layer may be notified.

[0112] In startup state 410, the device may load its last known maintenance counter value from NVRAM. This last known maintenance counter value may be higher or lower than the actual counter value on the network, for example, due to a flash wear protection scheme in which the maintenance counter value is stored in NVRAM in block units. The start timer T3 may have a random value. If the timeout T3 expires and no message (function or broadcast) is received during the timer T3 period, the counter synchronization protocol may be initialized, and a CB containing the maintenance counter value from NVRAM may be broadcast to the network.

[0113] The startup state 410 may be entered when the device wakes up. After wakeup, the device may be configured to send a broadcast message, such as a CB message, to synchronize its maintained message counter with the actual shared message counter of the network. If many devices wake up simultaneously, a random timer T3 may be used to randomize the transmission of CBs. The processing of received messages may be as follows: A normal message with a received counter value <= maintained counter value may not affect the state machine, but the device may still wait to send its own beacon. The received message may still be accepted for execution based on the rules. A normal message with a received counter value > maintained counter value may result in the device no longer needing to send a broadcast message, and thus the device may switch to the operational state 440 and update its maintained counter value.

[0114] An attacker might attempt to replay a message with a counter value higher than the maintenance counter value loaded from NVRAM, but lower than the actual shared counter value of the network. The device would not be properly synchronized, and thus the device might accept other replayed messages while its own messages are not accepted by other devices. The first valid "normal message" received would resynchronize the device. Therefore, the probability of this risk is very low, the impact on the system is minimal, and it is acceptable without additional mitigation. To avoid the possibility of such replays, the device may be configured to remain in a wait-to-synchronize state (not shown in the diagram) before accepting a message.

[0115] If a CB is received with a received counter value < maintained counter value, it is possible that some other device has started the synchronization protocol with an older counter value. In this case, the device no longer needs to send a startup beacon, but may respond to the received beacon by switching to a responsive synchronization state 420 (similar to the operating state machine 300).

[0116] If a CB is received with a received counter value >= the maintained counter value, some other device may have initiated a synchronization protocol with a higher or equal counter value. In this case, the device no longer needs to send its own beacon and may thus switch to an unresponsive synchronization state 430 (similar to the operating state machine 300). In this case, the device may update its own maintained counter value.

[0117] When timer T3 expires, the device may trigger the synchronization protocol by broadcasting a CB containing its own maintenance counter value, or it may transition to unresponsive synchronization state 430.

[0118] The purpose and message processing of the responsive synchronization state 420 may be similar to that of the responsive synchronization state 320 in Figure 3. Several other devices may trigger the synchronization protocol, and all receivers with higher maintenance counter values ​​may respond in this state.

[0119] The purpose and message processing of the unresponsive synchronization state 430 may be similar to those of the unresponsive synchronization state 330 in Figure 3.

[0120] When a device reaches operational state 440 (end up), it may notify its application layer that its network layer is ready to send and receive messages.

[0121] Figure 5 shows an exemplary network 500, illustrating that different types of devices 510-522 and different types of communication links 502, 504 between the devices may be used when applying any method of the present disclosure. In the exemplary network 500, IoT devices 510-514, a server system 520, and a storage device 522 are connected communicably via fixed or wired communication links 502 and / or wireless communication links 504. Each device 510-522 may be configured to use a synchronized shared message counter, as described in Figures 1-4, which may be stored in each device as a maintenance counter value 102. The network 500 may include one or more types of devices, and it will be understood that the present disclosure is not limited to any type of device or any type of communication link.

[0122] In exemplary embodiments, devices 510-514 may be smart lighting fixture devices that are communicably connected, for example, by a Zigbee® or LTE communication link.

[0123] In an exemplary embodiment, the network 500 may be based on the secure Dynet® protocol.

[0124] Figure 6 shows an exemplary embodiment of a computing system 600 for implementing a particular aspect of the present technology. In various examples, the computing system 600 may be devices 510-522, or any computing device that constitutes any other computing system described herein.

[0125] In some implementations, the computing system 600 can implement the methods described herein, such as the method of disclosure.

[0126] The computing system 600 includes any components of the computing system described herein, and the components of the system can communicate with each other using connections 605. Connections 605 can be physical connections via a bus, or direct connections to a processor 610, for example in a chipset architecture. Connections 605 can also be virtual connections, network connections, or logical connections.

[0127] In some implementations, the computing system 600 is a distributed system in which the functions described herein can be distributed across a data center, multiple data centers, a peer network, etc. In some embodiments, one or more of the system components described represent many such components, each performing some or all of the functions described. In some embodiments, the components can be physical or virtual devices.

[0128] An exemplary system 600 includes at least one processing unit (CPU or processor) 610 and connections 605 that connect various system components, including system memory 615 such as read-only memory (ROM) 620 and random access memory (RAM) 625, to the processor 610. The computing system 600 may include a cache of high-speed memory 612 that is directly connected to, adjacent to, or integrated as part of the processor 610.

[0129] The processor 610 may include an arbitrary general-purpose processor, hardware or software services such as services 632, 634, and 636 stored in a storage device 630, and a dedicated processor in which software instructions are incorporated into the actual processor design, configured to control the processor 610. The processor 610 may be a fully self-contained computing system that includes multiple cores or processors, buses, memory controllers, caches, etc. A multicore processor may be symmetrical or asymmetrical.

[0130] To enable user interaction, the computing system 600 includes an input device 645 which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, speech, etc. The computing system 600 may also include an output device 635 which can be one or more of several output mechanisms known to those skilled in the art. In some cases, a multimodal system may allow a user to provide multiple types of inputs / outputs for communicating with the computing system 600. The computing system 600 may generally include a communication interface 640 which can control and manage user inputs and system outputs. There are no restrictions on operating on any particular hardware configuration, and therefore the basic features described herein can be easily replaced with improved hardware or firmware configurations as they are developed.

[0131] The storage device 630 may be a non-volatile memory device and may be a hard disk or other type of computer-readable medium capable of storing computer-accessible data, such as a magnetic cassette, flash memory card, solid-state memory device, digital versatile disk, cartridge, random access memory (RAM), read-only memory (ROM), and / or any combination thereof.

[0132] The storage device 630 may include software services, servers, services, etc., that cause the system to perform functions when the code defining the software is executed by the processor 610. In some embodiments, a hardware service that performs a particular function may include software components stored on a computer-readable medium in relation to the necessary hardware components, such as the processor 610, connection 605, and output device 635, in order to perform the function.

Claims

1. A computer implementation method for replay protection on a device among multiple communicably connected devices operating in a broadcasting communication network, the method being: Store the maintenance counter value in memory. Obtaining a received counter value from a message received via a broadcasting network. To obtain the comparison result, the received counter value and the maintenance counter value are compared, and Depending on the above comparison results, If the received counter value is greater than the maintenance counter value, the received counter value is stored as the maintenance counter value. If the aforementioned received counter value is smaller than the aforementioned maintenance counter value, Starting the timer and If a further message containing an additional counter value is received via the broadcasting network before the timer expires, the received additional counter value is compared with the maintenance counter value. If the received additional counter value is greater than the maintenance counter value, the received additional counter value is stored as the maintenance counter value, and the timer is stopped. When the timer expires, a counter beacon message containing the maintenance counter value is transmitted via the broadcasting network. Includes, This method further, Before sending a data message via the broadcasting network, the maintenance counter value is incremented each time to obtain the incremented counter value. Updating the maintenance counter value with the incremented counter value, Sending a data message containing the incremented counter value via a broadcasting network, Methods that include...

2. This method further, If the received counter value or the further received counter value is greater than the maintained counter value, accept the content of the message or the further message, and If the received counter value or any further counter value is less than or equal to the maintenance counter value, the content shall be rejected. The method according to claim 1, including the method described in claim 1.

3. This method further, If the received counter value is greater than the value obtained by subtracting a predetermined delta value from the maintenance counter value, the content of the message is accepted, and If the received counter value is less than or equal to the value obtained by subtracting a predetermined delta value from the maintenance counter value, the content shall be rejected. The method according to claim 1, including the method described in claim 1.

4. The method according to any one of claims 1 to 3, wherein the duration of the timer is set according to the difference between the received counter value and the maintenance counter value.

5. The method according to claim 4, wherein the duration of the timer and the difference between the received counter value and the maintained counter value are inversely proportional.

6. The method according to any one of claims 1 to 3, wherein the duration of the timer is randomized.

7. The method according to any one of claims 1 to 6, further comprising storing the maintenance counter value in the non-volatile memory of the device.

8. The method further includes initializing the device, and the initialization is Loading the aforementioned maintenance counter value from the non-volatile memory, Start the initialization timer, If the initialization timer expires without detecting or receiving a message via the broadcasting network, a counter beacon message containing the maintenance counter value is transmitted via the broadcasting network. The method according to claim 7, including the method described in claim 7.

9. A device comprising means for performing the method described in any one of claims 1 to 8.

10. The device is an IoT device, as described in claim 9.

11. A broadcasting network comprising two or more devices according to claim 9 or 10.

12. A computer program, when executed by one or more processors, that includes instructions causing one or more processors to perform the method according to any one of claims 1 to 8.

13. A computer-readable storage medium that, when executed by one or more processors, includes instructions causing one or more processors to perform the method according to any one of claims 1 to 8.

Images