Replay protection using synchronized shared network counter

Abstract

A method (100) for replay protection in a network. The method includes: storing (102) a maintained counter value in a device; obtaining (104) a counter value from a message transmitted by another device; if (110) the counter value is greater than the maintained counter value, storing (116) the counter value as the maintained counter value, and if (114) the counter value is smaller than the maintained counter value, starting (120) a timer function. The timer function includes: if a further message comprising a further counter value is received (106) before expiring of the timer, comparing (124) the further counter value with the maintained counter value, and, if the further counter value is greater than the maintained counter value, storing (126) the further counter value as the maintained counter value and stopping the timer; and if (122) the timer expires, broadcasting (128) a counter beacon message including the maintained counter value.

Description

[0001] REPLAY PROTECTION USING SYNCHRONIZED SHARED NETWORK COUNTER

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a computer-implemented method of 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 implemented the method. The present disclosure further relates to a computer program and a computer-readable storage medium incorporating the method.

[0004] BACKGROUND

[0005] An important aspects of securing communication between devices is replay protection. Replay protection is particularly important for Internet-of-Things (loT) devices. A replay attack is a form of network attack in which valid data transmission is maliciously repeated or delayed. Known communication protocols, such as Zigbee™, Bluetooth™ Low Emission (BLE), KNX, Matter and WiFi, include forms of replay protection.

[0006] A typical implementation of replay protection makes use of message counters. Each device sending messages keeps track of its own “outgoing” counter. The outgoing counter is incremented before sending any message. The outgoing counter is included in the message as clear text and is typically also used in generating a message integrity code (MIC). The MIC allows receivers to validate if any part of the message has been modified. A typical message payload then consist of a receiver ID, sender ID, message counter, encrypted message, and MIC. Receivers keep track of the “last received counter” per every sender. Upon receiving a message, the receiver accepts the message if the message counter is higher than the “last received counter” for the message sender, otherwise the receiver rejects the message for being a replay.

[0007] Such replay protection mechanism has several disadvantages, in particular regarding working memory (e.g., RAM), storage memory (e.g., flash memory) and processing performance requirements. Each receiver has to track the “last received counter” for all senders on the network, which is particularly demanding for loT devices in larger loT networks. As an example, having 1000 devices, for 32 bit counters and 16 bit device IDs it would require about 6KB of RAM for tracking the last received counter per source on any device in the network. This may be difficult to implement for low specification loT devices. In an ideal case, devices should store the last received counters to NVRAM. This allows protection against replay when device powers up. As with RAM, 6KB NVRAM may be difficult to implement on a typical loT device.

[0008] Two devices may synchronize their counters. E.g., when a sender (device 1) sends a message to a receiver (device 2), and receiver does not have a last used counter for device 1, then it typically postpones message validation, triggers a synchronization protocol to obtains the counter of device 1, and then processes the received message. This is typically implemented as a two-message protocol. Using this protocol allows a device not to store message counters in NVRAM, but just run the synchronization protocol for messages from an unknow sender. Sync protocols can work quite well when a majority of messages on the network are unicast (1-1 message). A small performance penalty may be acceptable if it is done once, and receivers still need to track last used counters in RAM. Such sync protocols can become problematic with broadcast communication (1-N messages) where a single broadcast message can trigger the synchronization protocol by thousands of receivers.

[0009] US2018183591A1 is related to a network node having a normal mode and a coordinator mode. The network node comprises a counter and an incrementing unit, the incrementing unit being arranged to increment the counter at regular time intervals. If the network node does not receive counter synchronization messages it switches to coordinator mode.

[0010] SUMMARY

[0011] As indicated in the background section, known message replay protection mechanisms based on “outgoing” counters per sender and tracking these counters by receivers can have significant disadvantages for networks with larger number of devices, especially when communication protocols make use of broadcast messages. These disadvantages do apply to standards like Zigbee™, BLE mesh, KNX, Matter, and etcetera.

[0012] To overcome the disadvantages of the prior art, the present disclosure provides a replay protection mechanism that is based on a single, shared message counter for a whole network instead of the known mechanism where each device keeps track of its own sending counter. The mechanism of the present disclosure greatly reduces resource requirements for network devices. Instead of tracking thousands of counters, devices can basically maintain one synchronized and shared counter. A summary of aspects of certain examples disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects and / or a combination of aspects that may not be set forth.

[0013] According to an aspect of the present disclosure, a computer-implemented method of replay protection is provided. The method may be implemented in a device out of a plurality of communicatively connected devices operating in a broadcasting network. The method may include storing a maintained counter value in a memory. The method may further include obtaining a received counter value from a message received via the broadcasting network. The method may further include comparing the received counter value with the maintained counter value to obtain a comparison result. The method may further include, depending on the comparison result: if the received counter value is greater than the maintained counter value, storing the received counter value as the maintained counter value; and if the received counter value is smaller than the maintained counter value, starting a timer process. The timer process may include starting a timer. The timer process may further include, if a further message including a further counter value is received via the broadcasting network before expiring of the timer, comparing the received further counter value with the maintained counter value. If this received further 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 the timer process may be stopped. The timer process may further include, when the timer expires, transmitting via the broadcasting network a counter beacon message including the maintained counter value (i.e., which has not been changed by the received counter value or received further counter value), allowing the other devices to synchronize their maintained time values with the maintained timer value of this device.

[0014] The message and / or the further message received via the broadcasting network may be a data message or a counter beacon message sent by another device in the broadcasting network.

[0015] Thus, a single, shared message counter may be used in the network, where the single shared message counter is stored and updated as the maintained counter value in each device. The maintained counter value of a device may be updated upon sending a data message by the device or with each message received from any other device in the network, where the counter value in the received message may be checked against the maintained counter value for replay protection.

[0016] The received message can be a broadcast message including the current counter value of one of the devices, i.e., stored as maintained counter value in the other device, thereby allowing all devices to updated (sync) their maintained counter value. Alternatively, the received message can be a message to the device, where the message includes a counter value and content in any form for the device. Especially in the latter case, the receiving device may broadcast a counter beacon message including an updated message counter to all other devices to synchronize the maintained counter values in each of the devices.

[0017] If the received counter value is smaller than the maintained counter value, the message counter may need to be synchronized in all devices. The current device may then broadcast its maintained counter value. To avoid overflooding the network with counter beacon messages including current counter values, the timer process of the present disclosure allows for other devices to communicate their maintained counter value before the device transmits its own maintained counter value. If within the timer period another device indicates a higher counter value, the device can update its maintained counter value and need not transmit a counter beacon message anymore.

[0018] In an embodiment, the message may include the counter value and a content, and / or the further message may include the further counter value and a content. The content may be data in any form and for any purpose, typically intended for the receiving device. The method may further include, when the message is transmitted to the device by one of the devices, accepting the content if the received counter value or the received further counter value is greater than the maintained counter value; and rejecting the content if the received counter value or received further counter value is equal to or smaller than the maintained counter value. In this embodiment, the message is, e.g., unicast to the device.

[0019] In an alternative embodiment, the message may include the counter value and a further content, and / or the further message may include the further counter value and a further content. The further content may be data in any form and for any purpose, typically intended for the receiving device. The method may further include, when the message is transmitted to the device by one of the devices, accepting content in the message if the received counter value is larger than the maintained counter value minus a predefined delta value; and rejecting the content if the received counter value is equal to or smaller than the maintained counter value minus a predefined delta value. The delta value allows for one or more sending devices to have a, typically temporary, offset in counter value without its message being identified as a replay attack.

[0020] In an embodiment, the method may further include incrementing the maintained counter value to obtain an incremented counter value before sending a data message. The method may further include transmitting the data message to via the broadcasting network, with the data message including the incremented counter value. The maintained counter value is updated with the incremented counter value. The data message may also be another type of messages, such as for control and signaling, except the counter beacon message.

[0021] In an embodiment, the duration of the timer may is configurable according to the difference between the received counter value and the maintained counter value.

[0022] In an embodiment, the duration of the timer and the difference between the received counter value and the maintained counter value may inversely proportional, allowing for the timer to be set at a longer time interval when the difference is smaller, or vice versa.

[0023] In an embodiment, the duration of the timer may be randomized.

[0024] In an embodiment, the method may further include storing the maintained counter value in a non-volatile memory of the device. This allows the device to power cycle without loosing its last known maintained power value.

[0025] In an embodiment, the method may further include initializing the device. The initializing may include loading the maintained counter value from the non-volatile memory. The method may further include starting an initialization timer. The method may further include, when the initialization timer expires without detecting or receiving any message, transmitting, via the broadcasting network, a counter beacon message including the maintained counter value. This allows the maintained counter value to be synchronized to all other devices, while the initialization timer prevents overflooding of the network with counter beacon messages by initializing devices.

[0026] According to an aspect of the present disclosure, a device is provided. The device may include means for carrying out the method of one or more of the above described embodiments..

[0027] In an embodiment, the device may an Internet-of-Things, loT, device. The loT device is, e.g., a smart luminaire device, or any other loT device.

[0028] According to an aspect of the present disclosure, a broadcasting network is provided. The network may include two or more of the above described devices. According to an aspect of the present disclosure, a computer program is provided. The computer program may include instruction which, when the program is executed by one or more processors, cause the one or more processors to carry out the method of one or more of the above described embodiments.

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

[0030] BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbol indicate corresponding parts, in which:

[0032] Fig. 1 shows a flow diagram of an example method of the present disclosure;

[0033] Fig. 2 shows a flow diagram of another example method of the present disclosure;

[0034] Fig. 3 shows an example state machine for an active device of the present disclosure;

[0035] Fig. 4 shows an example state machine for an initializing device of the present disclosure;

[0036] Fig. 5 shows an example network topology including devices implementing the method of the present disclosure; and

[0037] Fig. 6 shows an example computing system for implementing certain aspects of the present disclosure.

[0038] The figures are intended for illustrative purposes only, and do not serve as restriction of the scope of the protection as laid down by the claims.

[0039] DETAILED DESCRIPTION

[0040] It will be readily understood that the components of the embodiments as generally described herein and illustrated in the appended figures could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of various embodiments, as represented in the figures, is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0041] The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present disclosure is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0042] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single example of the present disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, discussions of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same example.

[0043] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure. Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present disclosure. Thus, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0044] Invention focuses on design of replay protection mechanism that uses single, shared, message counter for whole network instead of standard mechanism where each device has own sending counter. The mechanism greatly reduces resource requirements for network devices. Instead of tracking thousands of counters, devices basically maintain one synchronized counter.

[0045] The present disclosure enables a shared counter replay protection, where the devices in a network keep track of one shared message counter. Different networks may have their own message counter, which may used by all devices of the network. The message counter may be synchronized between the devices of the network by transmitting broadcast messages. When sending unicast messages to one or more devices in the network, every sent message may increment the shared message counter. Devices may detect all network messages, including unicast messages transmitted to other devices and broadcast messages, allowing each device to keep track of the shared message counter. Each device may store the message counter as a maintained counter value. Received messages including a counter value greater than the maintained counter value may be accepted. Received messages including a counter value smaller than or equal to the maintained counter value may be replayed messages that should therefore not be accepted and may be ignored.

[0046] The present disclosure provides measures to prevent flooding of the network with update messages, also referred to as ‘counter beacon messages’, for synchronizing the maintained counter values in the devices.

[0047] Devices may conditionally accept messages with a smaller counter value using a delta value, to, e.g., deal with errors in communication. The present disclosure provides measures to protect against replays when conditionally accepting such messages.

[0048] The present disclosure allows a device to synchronize the shared message counter upon power-up. Hereto, devices may periodically store the maintained counter value in a non-volatile memory, such as NVRAM.

[0049] Fig. 1 shows an example embodiment of a process 100 of the present disclosure. The process may be computer-implemented in a device, e.g., an loT device. The device may be part of a network including other devices having implemented said process 100. The process enables replay protection, utilizing a message counter that is shared amongst the devices in the network.

[0050] In step 102 a current message counter has been stored as maintained counter value in a memory of the device and the device is waiting for a message. The maintained counter value may be stored in any suitable data format.

[0051] Each time the device transmits a message to another device, e.g., as a unicast message, the message counter may be incremented 130 and the incremented message counter may be stored as maintained counter value (step 102). In step 132 the message including the incremented message counter may be transmitted.

[0052] Devices in the network, preferably including the devices that are not directly addressed by the message, may detect the message and obtain the counter value from the message. Hereto, the counter value may be included in the message as clear text, allowing any device to 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 depicts the device obtaining a counter value from a message transmitted by any one of the devices in the network.

[0053] Steps 110, 112 and 114 depict different comparison steps, where the counter value (104) obtained from the message may be compared to the maintained counter value (102). In step 110 it may be determined whether the received counter value is greater than the maintained counter value. In step 112 it may be determined whether the received counter value is equal to the maintained counter value. In step 114 it may be determined that the received counter value is smaller than the maintained counter value.

[0054] It will be understood that the order of steps 110-114 may be different. Moreover, steps 110-114 may be implemented in any known computer-implemented manner.

[0055] If it is determined that the received counter value is greater than the maintained 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 maintained counter value may be updated to the received counter value. In case the received message was a broadcast message intended to synchronize the maintained counter values in the network or a message, e.g., unicast message, not addressed to this device, the process may go back to step 102 and wait for another message. If the message was addressed to this device, e.g., 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 content of the message is out of the scope of this disclosure and will not be further described.

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

[0057] 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 at one or more of the devices in the network and the device may decide to broadcast a message including the maintained counter value (as in step 102) to update the counter values maintained in the other devices to this maintained counter value. To avoid flooding the network with such synchronization messages, each device may implement a timer process (120-129), where it may be decided to broadcast the synchronization message unless within the timer period a further message is received with a further counter value that is greater than the maintained counter value, in which case no synchronization message need be transmitted anymore. In step 120 the timer may be started. The timer interval may be pre-set or conditionally set, as will be further explained in the description below.

[0058] In step 122 it may be determined whether or not the timer has expired. When the timer expires and no further messages including further counter values greater than the maintained counter value have been received, the device may broadcast 128 its maintained counter value (as in step 102) to the other devices. Any further messages received including incorrect further counter values may then be rejected 129.

[0059] 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 smaller than or equal to the maintained 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 maintained counter value, the received counter value may be stored 126 as the maintained counter value, i.e., the maintained counter value may be updated to the received further counter value. In this case, the device need not transmit a synchronization message anymore to the other devices, i.e., step 128 can be avoided.

[0060] It will be understood that the order of steps 122 and 124 may be different. Moreover, steps 122 and 124 may be implemented in any known computer-implemented manner.

[0061] If the further message was addressed to this device, e.g., as a unicast message, the further message may be accepted 127 and its content may be further processed by the device, similar to step 117.

[0062] For optimal operation of the shared message counter, receivers (i.e., the devices in the network receiving messages including counter values) preferably handle all messages (e.g., as in 104, 106) to be able to follow the counter value as being used in the network. It is typically not sufficient to handle only messages intended for the receiver. All messages may be followed, e.g., by reading all messages on a network bus in a promiscuous mode.

[0063] Before transmitting a message, devices typically create the message, put the message in a queue and wait to send when the medium is free. The message includes the counter value, possibly a message content (which is typically encrypted), and possibly a MIC.

[0064] The shared message counter, as maintained in the maintained counter value, may become out-of-sync for several reasons. It is possible that messages with a higher counter values are sent before messages with lower counter values, depending on the way network medium is accessed. Two (or more) devices may try to send data at the same time; collision can occur, and receivers may not be able to correctly process either of the messages. Two (or more) devices may increase their counters, while none of the receivers do, which may lead to "rollback" of counter values on the medium. Messages may be delayed in the sending queue. Some of the receivers may simply miss a broadcast message, e.g., due to a glitch on the power supply, glitch on the network medium, timing of sampling, and etcetera.

[0065] To cope with such out-of-sync scenarios, the timer process (120-129) ensures that the network is not flooded with synchronization messages for synchronizing the maintained counter values in such cases. Moreover, devices may be allowed to transmit and receive messages including lower counter values offset by a delta value, as will be further explained below.

[0066] Receivers may be allowed to accept messages including previous counter values. In such cases, the counter value of the message is expected to be greater than the maintained counter value minus a delta value. The delta value should be as small as possible. The delta value may depend on how many consecutive messages a device is expected to miss (e.g., based on collisions and missed messages). Alternatively or additionally, the delta value may depend on how many times a device does not manage to send queued message due to, e.g., the burst of traffic. The delta value may be set 0 (zero), i.e., no delta allowed, if, e.g., such situations occur rarely and the resulting system behavior when a correctly sent message is ignored is acceptable.

[0067] By allowing offset counter values, i.e., accepting messages with counter value >= maintained counter value - delta value, an attacker may be able to listen and replay a message multiple times (i.e., until the shared message counter as maintained as the maintained message counter goes over message counter + delta). This could be especially undesirable for some type of messages, such as Toggle on / off messages.

[0068] To avoid replay attacks when allowing offset counter values, devices may track per source if a counter value has been used before. If, e.g., a device receives a message from a sender with a counter value equal to the maintained counter value - 2, then the device may be configured to only accept next messages with a counter value of maintained counter value - 1 or higher from the same sender. Different from known solutions where individual counter values are tracked per source, this replay protection when allowing offset counter values has much lower resource requirements. A table with used counter values per source may be implemented, which may be sliding with the increase of the maintained counter value, and any tracked counter falling below the maintained counter value - delta value may be removed from the table. For example, a device X may send a message with a counter value equal to the maintained counter value instead of using a counter value equal to the maintained counter value + 1 (i.e., the maintained counter value has been used already, so the next message should have a larger counter value). In all other devices, device X may then be stored in a table at position counter value - 0. With the reception of new messages from other devices, this entry slides to counter value - 1, counter value - 2,.., until it falls to counter - delta, where device X may be removed from the table. Using a sliding table allows for, e.g., device identifiers to be stored at table positions indicative of the relative position to the delta value, without actually storing the counter values. The table may thus be kept limited in size.

[0069] Fig. 2 shows an example embodiment of a process allowing offset counter values. In the example of Fig. 2, steps 112 and 114 of Fig. 1 have been replaced by a step 210. In Fig. 2, the wavy lines indicate steps before and after step 110 and after step 120 that may be similar to or the same as shown in Fig. 1.

[0070] In step 210, the received counter value 104 may be compared against an individual counter value 202 per source. If the counter value 104 is larger than the individual counter value 202, then the message may be accepted 220 and the process may continue with step 120. If the counter value 104 is equal to or smaller than the individual counter value 202, the message may be discarded 230 and the process may continue at step 120.

[0071] The individual counter value 202 may be stored in a table, e.g., a sliding table as described above. With each increment of the maintained counter value, the sliding table for the individual counter values may be updated, possibly removing the individual counter value 202 from the table when the individual counter value < maintained counter value minus delta value. This may be achieved by comparing the values or by having the device identifier drop from the table by pushing from the table.

[0072] In an example use case, a device may wake up from a sleep mode or power on and does not know the current value of the shared message counter of the network. The device may then trigger a counter synchronization protocol and transmit a broadcast message, e.g., in the form of a "Counter Beacon" (CB). This CB includes the last known counter value of the device, i.e., the maintained counter value as stored in, e.g., NVRAM of the device. All devices that receive the CB message may respond as follows: If maintained counter value < received counter value, then take over the new received counter value; if maintained counter value = received counter value, then ignore the message; and if maintained counter value > received counter value, then start a timer with random duration for potential response with own CB message. A random time may be used as timer, which may depend on the difference in counter values (maintained counter value - received counter value). A higher difference may result in a shorter timer. If any message (functional or broadcast) is received during the timer period with a higher counter value then the maintained counter value, the device may update its maintained counter value and cancel the CB response timer.

[0073] During normal operation, all devices typically update their maintained counter value based on received counter values from authenticated functional messages.

[0074] The maintained counter value may be stored in RAM. Preferably, the maintained counter value is stored in NVRAM, allowing a device to power cycle without losing its maintained counter value. NVRAM may be used instead or RAM or in addition to RAM. For example, to reduce flash wear-out, a device implementation may apply storing of the maintained counter value in RAM and store the maintained counter value in NVRAM in blocks. For example, the maintained counter value may be stored in NVRAM every n counts, e.g., with n=1024 resulting in storing in NVRAM the maintained counter value as, e.g., 1024 when the counter value = 1, storing the maintained counter value as 2048 when the counter value = 1025, and not storing the maintained counter value in NVRAM for counter values 2 to 1024.

[0075] In an example, the counter value and maintained counter value may be 4 bytes in size. In larger networks, e.g., including thousands or more devices, and / or when allowing jumps in the maintained counter value due to the power up and NVRAM wear-out solution described above, a larger counter value, e.g., a 5-6 bytes counter value, may be used. Counter values of 4-6 bytes are particularly suitable for use in loT devices.

[0076] An example broadcast message, e.g., a CB message, for synchronizing the maintained counter value of the devices in the network, may include the following data fields: (i) a header, including one or more flag indicating a counter sync protocol, a destination address in the form of a broadcast address, and a source address of the device; (ii) a counter value, equal to the last know counter value (i.e., the maintained counter value as stored in the device); (iii) optionally a payload, preferably encrypted; and (iv) a MIC.

[0077] Fig. 3 shows an example counter synchronization state machine 300 of a device in operational mode. The following states and state transitions are shown:

[0078] 310: Operational state.

[0079] 311 : If normal message received with counter value =< maintained counter value, then ignore message; or if normal message received with counter value > maintained counter value, then update maintained counter value. 312: If broadcast message received with counter value < maintained counter value, then transition to synchronization-with-response state 320.

[0080] 313: If broadcast message received with counter value = maintained counter value, then transition to synchronization-without-response state 330.

[0081] 314: If broadcast message received with counter value > maintained counter value, then update maintained counter value and transition to synchronization-without- response state 330.

[0082] 320: Synchronization-with-response state. A timer T1 may be started when entering this state.

[0083] 321 : If broadcast message or normal message is received with counter value < maintained counter value, then ignore message.

[0084] 322: If broadcast message is received with counter value >= maintained counter value, then update maintained counter value and transition to synchronization- without-response state 330.

[0085] 323: If normal message is received with counter value >= maintained counter value, then update maintained counter value and transition to synchronization-without- response state 330.

[0086] 324: If timer T1 expires, then broadcast a message including maintained counter value and transition to synchronization-without-response state 330.

[0087] 330: Synchronization-without-response state. A timer T2 may be started when entering this state.

[0088] 331 : If normal or broadcast message is received with counter value > maintained counter value, then update maintained counter value; or if normal or broadcast message is received with counter value =< maintained counter value, then ignore message.

[0089] 332: If timer T2 expires, then transition to operational state 310.

[0090] The operational state 310 may be a normal operational state where the device sends and responds to messages. The device may monitor traffic and may updates its maintained counter value as: increment counter before sending any message with exception of broadcast (e.g., CB) messages; and update counter if a received message is authenticated and the counter is greater then currently maintained counter value.

[0091] Broadcast messages, such as CB messages, may be handled differently from normal messages. If a CB received counter value > maintained counter value, then the maintained counter value may be updated and the synchronize-without-response state 330 may be entered. If a CB received counter value = maintained counter value, then the synchronize-without-response state 330 may be entered. If a CB received counter value < maintained counter value, then the synchronize-with-response state 320 may be entered. The latter may be a main use case, where another device was powered up, does not know the counter value, thus it triggered synchronization by sending a CB message.

[0092] The purpose of the synchronize-with-response state 320 may be to randomize CB response delay for all receivers and minimize network traffic, thus preventing flooding the network with synchronization broadcast messages. If all devices would try to respond immediately with their own counter beacons, it could cause avalanche of responses, of which only one is relevant (i.e., the first CB with highest counter). Moreover, it could block the device with highest counter value to actually send CB; its CB could be delayed in a sending queue for many sending slots.

[0093] Timer T1 of state 320, is an example of the timer used in the timer function 120-129 of Fig. 1. In a non-limiting example, timer T1 may be set depending on a delta counter, which may be calculated as: delta counter = maintained counter - received counter. In an example, if delta counter > 1000, then random response time T1 may be set between 100 and 200ms. In this example, if delta counter > 100, then random response time T1 may be set between 200ms and 300ms. In this example, if delta counter > 10, then random response time T1 may be set between 300ms and 400ms. In this example, if delta counter >= 1, then random response time T1 may be set between 400ms and 500ms. It will be understood that other criteria and timer values may be used, as preferred in the network.

[0094] In another non-limiting example, timer T1 may be set using a formula, such as T1 = (500ms - log(delta counter) * 100ms) (with minimum of 100ms) + (random value between 0 and 1) * 100ms. It will be understood that other values for the 500ms and 100ms may be used, as preferred in the network.

[0095] In another non-limiting example, in case a responder is a ‘last sender’, timer T1 may be set to a random value, e.g., a random value between 0 and 100ms. The concept of ‘last sender’ may minimize traffic during the synchronization protocol. When a device sends a message (normal or CB), it may assume that it is the ‘last sender’. When a device receives a message (normal or CB) with counter value that is higher or equal to the maintained counter value, it may assume that it is no longer the ‘last sender’. Devices upon wake-up or power on are typically not ‘last senders’. Preferably, only one device assumes it is the ‘last sender’, however due to possibly bus collisions, missed messages and sending queues, it can happen that none or 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.

[0096] In the synchronize-with-response state 320, a CB with received counter value < maintained counter value may have no effect on the state machine. Another device may then have responded to an initial CB and due to the randomized time it may have been faster to respond.

[0097] In the synchronize-with-response state 320, a CB with received counter value >= maintained counter value may result in a switch to the synchronize-without-response state 330. The device need not respond anymore, because some other device with same / higher maintained counter value may already have responded. The device may update its maintained counter value if the received counter value is higher.

[0098] In the synchronize-with-response state 320, a normal message with received counter value < maintained counter value may not have an effect on the state machine, but the device may still wait to send its own beacon. Note that the received message may still be accepted for execution, based on rules for counter delta handling.

[0099] In the synchronize-with-response state 320, a normal message with received counter value >= maintained counter value may result in the device no longer needing to send CB, the device may switch to the synchronize-without-response state 330, and update its maintained counter value.

[0100] When timer T1 expires, the device may create a CB including its maintained counter value and put the CB in the sending queue for broadcast to the network.

[0101] The purpose of the synchronize-without-response state 330 may be to block re-triggering (potential infinite loop) of the synchronization protocol due to the CB messages delayed in sending queue. State 330 may provide a delayed return to the operational state 310 (e.g., using timer T2) when the device does not respond to CB messages with lower counter values for the specified period of time T2.

[0102] In the following example a first device initiates a synchronization with beacon counter = 1000 (e.g., CB counter value = 1000). In this example, 50 devices may have a maintained counter value of 1001, another 50 devices may have a maintained counter value of 1002, and another 50 devices may have a maintained counter value of 1003. Due to the random timing Tl, all other devices may try to send a beacon at similar time, and many of the devices may put beacons with counter values 1001, 1002 and 1003 in a sending queue. The first CB response (e.g., from a second device) on the bus may have a counter value of 1003. This is the best possible outcome, as indeed this indicates the highest counter value of the network. Devices that have not yet placed messages in the queue may then back off and go back to the operational state 310. Effectively, all devices in the network should now be in operational state 310. If on the other hand one of devices having a maintained counter value of, e.g., 1001 sends the message, this may re-trigger the synchronization protocol, where all devices with maintained counter values of 1002 or 1003 still want to respond.

[0103] Timer T2 in the synchronization-without-response state 330 may be used to set an amount of time that senders allow any message to be kept in a sending queue before discarding the message.

[0104] Fig. 4 shows an example power up state machine 400 of a device, as may be applicable to a device powering up after a sleep mode or when turning on after being powered off. The following states and state transitions are shown:

[0105] 401 : Power up the device from sleep state or power off state.

[0106] 410: Startup state. A timer T3 may be started when entering this state.

[0107] 411 : If normal message received with counter value =< maintained counter value (e.g., stored in NVRAM), then ignore message.

[0108] 412: If normal message received with counter value > maintained counter value, then update maintained counter value and transition to operational state 440. Operational state 440 may be similar or the same as operational state 310 of Fig. 3.

[0109] 413: If broadcast message received with counter value < maintained counter value, then transition to synchronization-with-response state 420.

[0110] 414: If broadcast message received with counter value >= maintained counter value, then update the maintained counter value and transition to synchronization-without- response state 430.

[0111] 415: If timer T3 expires, then broadcast synchronization message, e.g., CB message, including maintained counter value and transition to synchronization-without- response state 430.

[0112] 420: Synchronization-with-response state. A timer T4 may be started when entering this state.

[0113] 421 : If broadcast message or normal message is received with counter value < maintained counter value, then ignore message.

[0114] 422: If normal message is received with counter value >= maintained counter value, then transition to synchronization-without-response state 430.

[0115] 423: If broadcast message is received with counter value >= maintained counter value, then transition to synchronization-without-response state 430. 424: If timer T4 expires, then broadcast a message including maintained counter value and transition to synchronization-without-response state 430.

[0116] 430: Synchronization-without-response state. A timer T5 may be started when entering this state.

[0117] 431 : If normal or broadcast message is received with counter value > maintained counter value, then update maintained counter value; or if normal or broadcast message is received with counter value =< maintained counter value, then ignore message; or if timer T5 expires and repeat, then broadcast a message including maintained counter value.

[0118] 432: if timer T5 expires and no repeat, then transition to the operational state. 440: Operational state. The app layer may be notified when entering this state. In the startup state 410, the device may load its last known maintained counter value from NVRAM, which may be higher or lower than the actual counter value of the network due to, e.g., a flash wear-out protection scheme where the maintained counter value is stored in NVRAM in blocks. Start timer T3 may have a random value. After timeout T3 expired and no messages (functional or broadcast) have been received during the timer T3 period, a counter synchronization protocol may be initialized and a CB including the maintained counter value from NVRAM may be broadcast to the network.

[0119] In the startup state 410 may be entered upon wake-up of the device. After wake-up, the device may be configured to send a broadcast message, e.g., CB message, to synchronize its maintained message counter with the actual shared message counter of the network. A random timer T3 may be used to randomize the transmission of CBs when many devices wake-up at the same time. Handling of received messages may be as follows. A normal message with received counter value <= maintained counter value may have no effect on the state machine; the device may still wait to send its own beacon. Received messages might still be accepted for execution, based on rules. A normal message with received counter > maintained may result in the device no longer needing to send a broadcast message, thus it may switch to operational state 440 and update its maintained counter value.

[0120] An attacker may try to replay a message that has a counter value higher than the maintained counter value loaded from NVRAM, but lower than actual shared counter value of the network. The device would not be properly synchronized, thus it may accept other replayed messages and its own messages may not be accepted by other devices. The first valid "normal message" received would re-synchronize device. Therefore, the probability of risk is very low, with minimal impact on the system and acceptable without extra mitigation. To avoid such replay possibility, the device may be configured to stay in a wait-to-synchronize-state (not shown in the drawings) before accepting messages.

[0121] If a CB with received counter value < maintained counter value is received, some other device may have started the synchronization protocol with an older counter value. The device then no longer needs to send a startup beacon, but it may respond to the received beacon by switching to synchronize-with-response state 420 (similar to operational state machine 300).

[0122] If a CB with received counter value >= maintained counter value is received, some other device may have started the synchronization protocol with higher or equal counter value. The device then no longer needs to send its own beacon, thus it may switch to the synchronize-without-response state 430 (similar to operational state machine 300). The device may then update its own maintained counter value.

[0123] When timer T3 expires, the device may trigger the synchronization protocol by broadcasting a CB including its maintained counter value, and may transition to the synchronize-without-response state 430.

[0124] The purpose and message handling of the synchronize-with-response state 420 may be similar to the synchronize-with-response state 320 of Fig. 3. Some other devices may have triggered a synchronization protocol and all receivers with higher maintained counter values may respond in this state.

[0125] The purpose and message handling of the synchronize-without-response state 430 may be similar to the synchronize-without-response state 330 of Fig. 3.

[0126] When device ends up in operational state 440, it may notify the application layer of the device that the network layer of the device is ready for sending and receiving messages.

[0127] Fig. 5 shows an example network 500 illustrating that different kind of devices 510-522 and different kind of communication links 502, 504 between the devices may be used when applying any of the methods of the present disclosure. In the example network 500, loT devices 510-514, a server system 520 and a storage device 522 are communicatively connected via fixed or wired communication links 502 and / or wireless communication links 504. Each of the devices 510-522 may be configured to use the synchronized shared message counter as described with Figs. 1-4, which may be stored as a maintained counter value 102 in each of the devices. It will be understood that the network 500 may include one or more kind of devices and that the present disclosure is not limited to any kind of device or type of communication link. In an example embodiment, the devices 510-514 may be smart luminaire devices that are communicatively connected, e.g., by Zigbee™ or LTE communication links.

[0128] In an example embodiment, the network 500 may be based on a secure Dynet™ protocol.

[0129] FIG. 6 shows an example embodiment of a computing system 600 for implementing certain aspects of the present technology. In various examples, the computing system 600 can be any computing device making up the device 510-522, or any other computing system described herein.

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

[0131] The computing system 600 can include any component of a computing system described herein which the components of the system are in communication with each other using connection 605. The connection 605 can be a physical connection via a bus, or a direct connection into processor 610, such as in a chipset architecture. The connection 605 can also be a virtual connection, networked connection, or logical connection.

[0132] In some implementations, the computing system 600 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the functions for which the component is described. In some embodiments, the components can be physical or virtual devices.

[0133] The example system 600 includes at least one processing unit (CPU or processor) 610 and a connection 605 that couples various system components including system memory 615, such as read-only memory (ROM) 620 and random-access memory (RAM) 625 to processor 610. The computing system 600 can include a cache of high-speed memory 612 connected directly with, in close proximity to, or integrated as part of the processor 610.

[0134] The processor 610 can include any general -purpose processor and a hardware service or software service, such as services 632, 634, and 636 stored in storage device 630, configured to control the processor 610 as well as a special -purpose processor where software instructions are incorporated into the actual processor design. The processor 610 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. 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, keyboard, mouse, motion input, speech, etc. The computing system 600 can also include an output device 635, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input / output to communicate with the computing system 600. The computing system 600 can include a communications interface 640, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0135] A storage device 630 can be a non-volatile memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read-only memory (ROM), and / or some combination of these devices.

[0136] The storage device 630 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 610, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as a processor 610, a connection 605, an output device 635, etc., to carry out the function.

Claims

CLAIMS:

1. A computer-implemented method (100) of replay protection in a device (510-522) out of a plurality of communicatively connected devices operating in a broadcasting communication network (500), the method comprising: storing (102) a maintained counter value in a memory (615, 630); obtaining (104) a received counter value from a message received via the broadcasting network (500); comparing (110-114) the received counter value with the maintained counter value to obtain a comparison result; and depending on the comparison result:- if (110) the received counter value is greater than the maintained counter value, storing (116) the received counter value as the maintained counter value;- if (114) the received counter value is smaller than the maintained counter value: starting (120) a timer; if a further message comprising a further counter value is received (106) via the broadcasting network (500) before expiring of the timer, comparing (124) the received further counter value with the maintained counter value, and, if the received further counter value is greater than the maintained counter value, storing (126) the received further counter value as the maintained counter value and stopping the timer; and if (122) the timer expires, transmitting (128), via the broadcasting network (500) a counter beacon message comprising the maintained counter value; the method further comprising: incrementing (130) the maintained counter value to obtain an incremented counter value each time before sending a data message via the broadcasting network; updating the maintained counter value with the incremented counter value; and transmitting (132) the data message comprising the incremented counter value via the broadcasting network (500).

2. The method according to claim 1, the method further comprising: accepting (117, 127) content in the message or in the further message if (110, 124) the received counter value or the received further counter value is greater than the maintained counter value; and rejecting (118, 129) the content if (112, 122) the received counter value or the further counter value is equal to or smaller than the maintained counter value.

3. The method according to claim 1, the method further comprising: accepting (220) content in the message if (210) the received counter value is larger than the maintained counter value minus a predefined delta value; and rejecting (230) the content if (210) the received counter value is equal to or smaller than the maintained counter value minus a predefined delta value.

4. The method according to any one of the preceding claims, wherein the duration of the timer is configured according to the difference between the received counter value and the maintained 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 the claims 1-3, wherein the duration of the timer is randomized.

7. The method according to any one of the preceding claims, further comprising storing the maintained counter value in a non-volatile memory of the device.

8. The method according to any claim 7, further comprising initializing the device, wherein the initializing comprises: loading the maintained counter value from the non-volatile memory; starting an initialization timer; when the initialization timer expires without detecting or receiving any message via the broadcasting network (500), transmitting via the broadcasting network (500) a counter beacon message comprising the maintained counter value.

9. A device (510-522) comprising means for carrying out the method according to any one of the claims 1-8.

10. The device according to claim 9, wherein the device is an Internet-of-Things, loT, device.

11. A broadcasting network (500) comprising two or more devices (510-522) according to claim 9 or claim 10.

12. A computer program comprising instruction which, when the program is executed by one or more processors (610), cause the one or more processors to carry out the method (100) according to any one of the claims 1-8.

13. A computer-readable storage medium comprising instructions which, when executed by one or more processors (610), cause the one or more processors to carry out the method (100) according to any one of the claims 1-8.

Images