WO2022248258A1 - Replay attack protection - Google Patents

Replay attack protection Download PDF

Info

Publication number
WO2022248258A1
WO2022248258A1 PCT/EP2022/063094 EP2022063094W WO2022248258A1 WO 2022248258 A1 WO2022248258 A1 WO 2022248258A1 EP 2022063094 W EP2022063094 W EP 2022063094W WO 2022248258 A1 WO2022248258 A1 WO 2022248258A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic device
sequence
identifier
value
message
Prior art date
Application number
PCT/EP2022/063094
Other languages
French (fr)
Inventor
Frank AUNE
Original Assignee
Nordic Semiconductor Asa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nordic Semiconductor Asa filed Critical Nordic Semiconductor Asa
Publication of WO2022248258A1 publication Critical patent/WO2022248258A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • This invention relates to devices, methods and software for determining whether cryptographically-signed messages, received by an electronic device, are valid.
  • Electronic devices that communicate with other devices can be vulnerable to replay attacks, in which an imposter replays a copy of a message, legitimately sent to a device by another party, in order to try to trick the device into believing the message has come from the other party, rather than the imposter, so as to take control of the device.
  • a known defence against replay attacks is to include a monotonically-increasing sequence value in each successive message the other party send to the device, and to sign the messages cryptographically so that the device can authenticate them as originating from the other party.
  • the recipient device checks that the sequence value in each message it receives is greater than the value contained in any preceding message it has received from the other party. It can reject the message if this check fails.
  • Embodiments of the present invention seek to provide an approach that can secure electronic devices against replay attacks even when if the device is reinitialised.
  • the invention provides an electronic device configured: to store a device-specific identifier for the electronic device; to store a local sequence value, associated with an external party; to receive a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; to determine whether the received message is valid by checking that:
  • the cryptographic signature is associated with the external party
  • the cryptographic signature confirms the integrity of the identifier field and the sequence-value field
  • the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and in response to determining that the message is valid, to update the stored local sequence value to correspond to the received sequence-value field.
  • the invention provides a method of operating an electronic device, comprising: storing a device-specific identifier for the electronic device on the electronic device; storing a local sequence value, associated with an external party, on the electronic device; the electronic device receiving a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; the electronic device determining that the received message is valid by checking that:
  • the cryptographic signature is associated with the external party
  • the cryptographic signature confirms the integrity of the identifier field and the sequence-value field
  • the electronic device in response to determining that the message is valid, updating the stored local sequence value to correspond to the received sequence- value field.
  • the message for a message to be considered valid by the device, the message must contain not only a valid sequence value and cryptographic signature, but must also contain the same device-specific identifier that is currently stored by the recipient device. If all the data stored on the device is erased or reset, this will erase or reset not only the stored local sequence value but also the stored device-specific identifier. Any message received after the reinitialisation, containing the device-specific identifier that was formerly stored on the device, will no longer be determined as valid, because its identifier field will no longer match with a stored identifier.
  • a replay attack based on replaying a message that was intercepted before the device was reinitialised, will fail, even though it might pass the checks makes on the sequence value and signature, because it will no longer comprise a valid device-identifier for the device.
  • the device may be configured to perform any of the steps disclosed herein in hardware — e.g. using an application-specific integrated circuit (ASIC) or a field- programmable gate array (FPGA). However, in preferred embodiments, some or all of the steps are performed in software.
  • the device may comprise one or more processors and a memory storing software for execution by the device.
  • the software preferably comprises instructions for determining whether the cryptographically-signed message is valid, and for updating the stored local sequence value.
  • the invention provides computer software comprising instructions which, when executed on an electronic device comprising one or more processors and storing a device-specific identifier for the electronic device, and storing a local sequence value associated with an external party, cause the electronic device: to determine whether a cryptographically-signed message, received by the electronic device, and comprising an identifier field, a sequence-value field, and a cryptographic signature, is valid by checking that:
  • the cryptographic signature is associated with the external party
  • the cryptographic signature confirms the integrity of the identifier field and the sequence-value field
  • the device is preferably configured so that the stored local sequence value cannot be erased, reset or decremented unless the device-specific identifier is also erased or reset.
  • This configuration may be provided by software stored on the device, or it may be provided, at least in part, by electronic hardware of the device.
  • the device may be configured to store the local sequence value and the device-specific identifier in a region of memory (e.g. a common page of flash memory) that cannot be erased except by an erase operation that erases the whole region.
  • the device may comprise a hardware counter for storing the local sequence value, and may comprise protection circuitry for preventing the counter from being reset unless a memory storing the device-specific identifier has first been erased.
  • the device may be configured to receive the device-specific identifier from outside the device (e.g. within a firmware update for the device). However, in preferred embodiments, the device is configured to generate the device-specific identifier.
  • the device-specific identifier is preferably randomly generated — i.e. using a hardware or software random-number generator.
  • the device-specific identifier may be at least 128 bits, or preferably at least 256 bits, long. This can ensure, or make it extremely unlikely, that, if the device ever receives or generates a new device-specific identifier — e.g. after being reinitialised — the new identifier will not be the same as any previous identifier used by the device. It can also ensure that no two devices share the same device-specific identifier.
  • the device-specific identifier is a public key associated with the electronic device, or is derived from a public key associated with the electronic device (e.g. being a hash of such a key).
  • the public key may be part of an asymmetric key pair comprising the public key and a private key.
  • the private key may be stored on the electronic device. This can be desirable as many devices are already configured to generate and store such public-private key pairs, and established mechanisms exist for sharing public keys with external parties — e.g. within standardised radio protocols such as Bluetooth. Repurposing a public key as a device specific identifier for preventing replay attacks may therefore be more efficient and easier to implement than using a separate identifier.
  • the device may be configured for performing an initialisation process in which the device generates a device-specific identifier and writes the device-specific identifier to a memory of the device.
  • the device may be configured to send the device-specific identifier to the external party — e.g. during a pairing process.
  • the device may perform the checks for determining the validity of received cryptographically-signed messages in any order.
  • the electronic device may be configured, in response to determining that a received message comprising a command for the device is valid, to process the command.
  • the message may, in some embodiments, comprise a command to erase or reinitialise the electronic device.
  • the device may be configured, in response to receiving such a message, to erase or replace the device-specific identifier; it may also erase the stored local sequence value; it may perform an initialisation process to generate a new device-specific identifier for the device.
  • Such embodiments may advantageously provide support for an erase command for the device that can be sent in a one-way communication exchange, such that the command is “single use” and robust against replay attack. This may provide a convenient mechanism for decommissioning or reinitialising devices in the field.
  • the electronic device is preferably configured, in response to determining that a received message is not valid, not to update the stored local sequence value. It may be configured to reject the message — e.g. to ignore the message or not to process any command contained in the message. It may signal or report a validation error, e.g. to a user of the electronic device and/or to the external party.
  • the electronic device may receive or generate an updated device-specific identifier for the electronic device, and may update the stored device-specific identifier on the electronic device with the updated device-specific identifier.
  • the device may thereafter receive a second cryptographically-signed message, being a copy of the aforesaid message.
  • the second cryptographically-signed message may be received from a second party, which may be an imposter performing a replay attack, by sending a copy of a message sent previously by the first party to the electronic device.
  • the cryptographic signature of the second message may therefore be valid.
  • the electronic device may determine that the received message is not valid by determining that the identifier field of the second message does not match the updated stored identifier.
  • the device may, in response, reject the second message.
  • the received identifier field may be determined to match the stored identifier when and only when the two identifiers are equal.
  • another matching condition may be used, e.g. a condition that allows the received identifier to be a hash of the stored identifier.
  • the sequence value may be a value from any ordered set of values. It may be an integer count value, although this is not essential.
  • the sequence condition may, in some embodiments, be satisfied when and only when the received sequence value is greater than (or, in some embodiments, greater than or equal to), the stored local sequence value. Greatness may be determined according to any appropriate metric that orders the set of possible sequence values.
  • Updating the stored local sequence value to correspond to the received sequence- value field may comprise storing the received sequence value as an updated local sequence value (or, in some embodiments, storing the next value after the received sequence value in an ordered set of possible sequence values).
  • the electronic device may comprise a wired or wireless interface for receiving the cryptographically-signed message.
  • the device comprises a radio transceiver and is configured to receive cryptographically-signed messages by radio. It may support a short-range radio protocol, such as Bluetooth, Bluetooth Low Energy, an IEEE 802.15.4-based protocol, or WiFi, or it may support a cellular network protocol.
  • the device is battery-powered device. It may be an wireless sensor device, Internet-of-Things device, or other embedded device.
  • the device may be an integrated-circuit device, such as a system-on-chip.
  • Software as disclosed herein may be firmware for the device. It may comprise instructions for performing a firmware update process for the device — e.g., for replacing itself with updated firmware.
  • the updated firmware preferably also comprises instructions for reinitialising the device and for determining that received messages are valid, as disclosed herein. In this way, the device can continue to be protected against replay attacks even after a firmware update.
  • the external party may be a natural or legal person or other entity. It may comprise a further electronic device or electronic apparatus.
  • the invention provides a communication system comprising a first electronic device, as disclosed herein, and further comprising a second electronic apparatus configured to send the cryptographically-signed message to the first electronic device.
  • the second electronic apparatus may be the external party, or may be associated with (e.g. controlled by) the external party.
  • the second electronic apparatus may be a second electronic device that also embodies the invention as disclosed herein. It may have some or all of the same optional features as the first electronic device, although this is not essential.
  • the first electronic device may be configured for sending cryptographically-signed messages to the second electronic device, each cryptographically-signed message comprising a respective identifier of the first electronic device, a respective sequence value, and a respective cryptographic signature.
  • the cryptographic signature may be associated with the first electronic device, or associated with a party that controls or is associated with the first electronic device.
  • Computer software as disclosed herein may be stored in a memory of an electronic device, or on any other non-transitory computer-readable storage medium.
  • Figure 1 is a schematic diagram of a set of devices communicating by radio, including an electronic device embodying the invention
  • Figure 2 is a diagram of an example radio packet structure received by the electronic device.
  • Figure 3 is a flow chart showing steps of a message authentication process embodying the invention.
  • Figure 1 shows three electronic devices 1, 2, 3 each equipped with a radio for digital radio communication.
  • Each could be a smart phone, laptop computer, sensor device, cellular network base station, wireless router, domestic appliance, wireless loud speaker, vehicle, or any other types of radio-equipped device. They may all embody the invention, but in this example, at least the first device 1 embodies the invention.
  • the first device 1 contains a microcontroller 3, radio circuitry 4, and a power supply 5 (e.g. a battery or a mains electrical supply connection).
  • the radio circuitry 4 includes a radio antenna 6, as well as analog and digital circuitry for receiving and demodulating radio packets received at the antenna 6, and for modulating and transmitting radio packets from the antenna 6, under the control of the microcontroller 3.
  • the microcontroller 3 includes a processor 7 and a memory 8, for storing data and software for execution by the processor 7.
  • the memory 8 may be entirely volatile (e.g. RAM), or it may include volatile (e.g. RAM) and non-volatile (e.g. flash) regions.
  • the microcontroller 3 and at least some of the radio circuitry 4 may, in some embodiments, be integrated on a single radio-on-a-chip component.
  • the radio circuitry 4 may be arranged to support any short-range or long-range digital radio communication protocol, which may be standardised or proprietary. In some embodiments it supports Bluetooth Low Energy and/or one or more IEEE 802.15.4- based protocols such as Zigbee or Thread and/or an IEEE 802.11 protocol. It may support a cellular network standard, e.g. a 4G or 5G protocol, such as LTE-M (Cat M1) or NB-loT.
  • a 4G or 5G protocol such as LTE-M (Cat M1) or NB-loT.
  • a second device 2 which is capable of communicating with the first device 1 using a common radio protocol. It may be similar to the first device 1 (e.g. both being mobile telephones), or it may be a different type of device. It may be a user device, operated by an individual. However, it may alternatively or additionally be controlled by a larger entity, such as a company, e.g. by being coupled to a corporate network. It may, at least in some embodiments, be able to communicate radio data to the first device 1 under the control of an operator or manufacturer of the first device 1.
  • a third device 3 is also shown, which is assumed to be under the control of a malicious attacker.
  • the attacker desires to control the first device 1 by first eavesdropping on communications between the electronic device, and then launching a replay attack on the first device 1.
  • the third device 3 impersonates the second device 2 by sending, at a later time, a copy of a radio message that the third device 3 has overheard the second device 2 sending to the first device 1 at an earlier time.
  • a replay attack may be launched, for instance, by a thief who controls the third device 3, to attempt unlock a locked vehicle or a building lock (embodying the first device 1) by eavesdropping on an unlock command, sent legitimately from a wireless key fob (embodying the second device 2) under the control of the owner, and then replaying the command at a later point in time, when the owner is no longer present.
  • replay attacks can succeed even if cryptographic signing is used by a sender to cryptographically sign messages it sends to the recipient, with the recipient being arranged to reject any message that are not validly signed. This is because an attacker can simply include the same valid signature in the replayed message and thus fool the recipient.
  • an incremental monotonic counter (which could be a software or hardware-based counter or clock, or any other way generating an ordered sequence of values) may be maintained by the sender and used to include a unique sequence value (an integer count value, timestamp, etc.) in each signed message that it sends to the recipient.
  • the recipient maintains a synchronized counter, or keeps a copy of the latest-received sequence value, and rejects any signed message that contains a sequence value that is lower than an output of the synchronized counter or than a locally-stored sequence value. This can prevent replay attacks.
  • the security of this approach is undermined if it is possible for the local counter (e.g. a clock) or stored sequence value on the recipient device to be reinitialised back to a default starting value (e.g. zero) after the device has been deployed.
  • a reinitialisation may occur, for example, when a battery is swapped on a battery-powered device, or if all the memory of the device is erased during a firmware update process. This may then render the recipient device vulnerable to a replay attack, since it will no longer identify a previously-received message as having an invalid sequence value.
  • This risk may be especially acute for simpler, battery- powered or resource-constrained devices, such as a wireless Internet-of-Things device or sensor devices (e.g.
  • a wireless thermostat or door lock which will typically lack the resources (e.g. an always-on network connection) that might otherwise allow a device to securely re-synchronize a counter or stored local sequence value after such a reinitialisation.
  • resources e.g. an always-on network connection
  • This can mean that such a recipient device may still be vulnerable to replay attacks, under certain circumstances (e.g. after a firmware upgrade that erases and reinitialises the memory of the device). It can therefore be impossible, using conventional approaches, for sensitive commands to be sent to such devices with a high assurance of security against abuse through a replay attack.
  • Two-way interactive authentication and communication protocols may mitigate this in some situations, but real-time, two-way interaction between sender and recipient may be undesirable or impossible in many situations.
  • the first device 1 and the second device 2 are configured to communicate using a protocol that provides protection against replay attacks, and which can be used even for sending one-way messages.
  • the first device 1 storing a device-specific identifier, and being configured so that, if the first device 1 is ever reinitialised, the stored device-specific identifier will be reinitialised to a new value, alongside any counter or locally-stored sequence values on the first device 1 being reinitialised.
  • the second device 2 then includes the device-specific identifier associated with the first device 1 , as well as an incrementing sequence value, in each signed message that the second device 2 sends to the first device 1.
  • the first device 1 can check that signed messages it receives are valid by checking that the device-specific identifier in the message is the same as its currently-stored device identifier, as well as checking the sequence value and verifying the signature.
  • the old device-specific identifier will be replaced with a new device-specific identifier, which the first device 1 will immediately start using for checking the validity of any messages received after the reinitialisation.
  • the third device 3 then sends a copy of any older message, originally sent to the first device 1 by the second device 2, containing the old device-specific identifier, this will be rejected by the first device 1, even if it contains a valid signature and contains a sequence value that would pass a sequence-value check based on the reinitialised counter of the first device 1.
  • the first device 1 were subsequently re-initialized (e.g. re-paired) to accept signed messages from the second device 2, any previous in-field erase or decommissioning command cannot be successfully replayed, even though the signature is valid.
  • the device-specific identifier is preferably randomly generated. It may, in some embodiments, conveniently be a public key of the first device 1. This may reduce the amount of additional data storage and communication required to implement this approach, since many radio protocols already include mechanisms for generating, storing and distributing public keys, which can conveniently be harnessed.
  • Figure 2 shows an example of a radio data packet format that could be used when implementing this approach. However, it may readily be integrated into any existing or future radio protocol, e.g. through appropriate modifications to the packet header fields, or by including relevant data in a message body of a packet.
  • the packet 20 in Figure 2 comprises a recipient address field (“RX addr”) 21, a transmitter address field (“TX addr”) 22, a length field 23, a recipient-device public-key field (“keypubiic”) 24, a sequence value field 25, a message data field 26, and a signature field 27.
  • RX addr recipient address field
  • TX addr transmitter address field
  • length field 23
  • keypubiic recipient-device public-key field
  • the signature field 27 stores a cryptographic signature for the preceding fields 21-26 of the packet 20. It may be signed by the sender using any appropriate symmetric or asymmetric signature algorithm.
  • the recipient-device public-key field 24 should contain the public key of the recipient device (e.g. “key pUbiicj ” in the example below), which here serves as a device-specific identifier.
  • the recipient device e.g. “key pUbiicj ” in the example below
  • Other embodiments might, however, use an identifier that is not part of a cryptographic key pair.
  • Figure 3 illustrates exemplary steps performed by the first device 1 (Device A) when it is initialised and when it receives a message allegedly sent by the second device 2 (Device B), but which possibly has been sent by the third device 3 in an attempted replay attack.
  • the first device 1 is initialised. This could be a first initialisation after manufacturing or deployment, or it could be a reinitialisation, e.g. after an in-the-field firmware update that causes all data stored in the memory 8 of the device 1 to be erased, including any stored device keys and stored sequence values.
  • firmware executing on the device 1 causes it to use a software or hardware random-number generator of the device 1 to generate a new key pair for the device ⁇ key P ri Vatej , key pUbiicj ⁇ , which it stored in its memory 8.
  • the first device 1 pairs with the second device 2 using a radio pairing process. During this process, it sends its new public key, key pUb n c _i, to the second device 2. It also receives the public key, key pUb n c _2, of the second device 2, which it stores in the memory 8. It also exchanges an initial sequence value, seq ⁇ , with the second device 2 (e.g. generated by one or other of the devices 1 , 2 and sent to the other device 2, 1). Alternatively, in some embodiments, the sequence value, seq ⁇ , might simply start at zero by default after pairing.
  • Both devices 1, 2 store this initial sequence value, seq ⁇ , in their respective memories and/or use it to initialise respective hardware counters (e.g. linear-feedback shift registers).
  • the first device 1 may be able to store and maintain a plurality of different sequence values for a plurality of different devices with which it is paired.
  • the first device 1 receives a signed message packet 20, having a recipient address field 21 corresponding to the second device 2.
  • the packet 20 has a value key pUb n c _x stored in the recipient-device public-key field 24, and a sequence value, seqx in the a sequence value field 25. It also has a cryptographic signature in the signature field 27.
  • the first device 1 checks that the received key pUb n c _x equals its stored device-specific identifier key pUb n c _i. If they do not match, it rejects 38 the packet. If they do match, processing proceeds.
  • the first device 1 checks that the received sequence value seqx is greater than the sequence value it has stored for the second device 2, seq ⁇ . If not, it rejects 38 the packet. If so, processing proceeds.
  • the first device 1 uses the public key of the second device 2 to check that the received signature is valid — i.e. that it confirms the integrity of the packet fields 21-26 and that it is authentically associated with the second device 2. If the signature is not valid, it rejects 38 the packet. If it is valid, processing proceeds.
  • a seventh step 36 the first device 1 updates its local store of the sequence value for the second device 2 to equal the received value seq2.
  • the first device 1 processes the message body of the packet, e.g. by executing any commands it may contain.
  • the first device 1 then waits to receive any further packets.
  • the first device 1 is programmed so that the stored seq ⁇ value cannot be erased or reset without the device 1 immediately performing an initialisation step 30 so as to generate a new key pair, that renders the old key pUb n c _i obsolete.
  • One example use case that highlights a benefit of this approach is when the radio message received from the second device 2 contains a command to erase the memory 8 of the first device 1 — e.g. as part of a remote decommissioning action or within a firmware update command.
  • Such a one-way procedure may be useful for erasing a device 1 that is unable to respond in real time for some reason — e.g. when it is in radio reception range but is out of radio transmission range.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The invention provides an electronic device (1) and method of operating an electronic device. The device (1) is configured to store (30) a device-specific identifier for the electronic device and a local sequence value associated with an external party. The device receives (32) a cryptographically-signed message (20) including an identifier field (24), a sequence-value field (25), and a cryptographic signature (27), and determines whether the received message is valid. To determine validity the device checks that the cryptographic signature is associated with the external party (35), the cryptographic signature confirms the integrity of the identifier field and the sequence- value field, the received identifier field matches the stored identifier (33); and the received sequence-value field satisfies a sequence condition (34) determined in dependence on the stored local sequence value. In response to determining that the message is valid, the device updates (36) the stored local sequence value to correspond to the received sequence-value field.

Description

Replay Attack Protection
BACKGROUND OF THE INVENTION
This invention relates to devices, methods and software for determining whether cryptographically-signed messages, received by an electronic device, are valid.
Electronic devices that communicate with other devices, e.g. by radio, can be vulnerable to replay attacks, in which an imposter replays a copy of a message, legitimately sent to a device by another party, in order to try to trick the device into believing the message has come from the other party, rather than the imposter, so as to take control of the device.
A known defence against replay attacks is to include a monotonically-increasing sequence value in each successive message the other party send to the device, and to sign the messages cryptographically so that the device can authenticate them as originating from the other party.
The recipient device checks that the sequence value in each message it receives is greater than the value contained in any preceding message it has received from the other party. It can reject the message if this check fails.
However, this requires the recipient device to store a local copy of the sequence value securely on the device. This may not always be straightforward, especially for resource-constrained devices. In particular, if a device is reinitialised such that its stored data is erased or reset, its local copy of the sequence value will also be reset (e.g. to zero) and the device may then be vulnerable to a replay attack.
Embodiments of the present invention seek to provide an approach that can secure electronic devices against replay attacks even when if the device is reinitialised.
SUMMARY OF THE INVENTION
From a first aspect, the invention provides an electronic device configured: to store a device-specific identifier for the electronic device; to store a local sequence value, associated with an external party; to receive a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; to determine whether the received message is valid by checking that:
- the cryptographic signature is associated with the external party;
- the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and in response to determining that the message is valid, to update the stored local sequence value to correspond to the received sequence-value field.
From a second aspect, the invention provides a method of operating an electronic device, comprising: storing a device-specific identifier for the electronic device on the electronic device; storing a local sequence value, associated with an external party, on the electronic device; the electronic device receiving a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; the electronic device determining that the received message is valid by checking that:
- the cryptographic signature is associated with the external party;
- the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and the electronic device, in response to determining that the message is valid, updating the stored local sequence value to correspond to the received sequence- value field.
Thus it will be seen that, in accordance with embodiments of the invention, for a message to be considered valid by the device, the message must contain not only a valid sequence value and cryptographic signature, but must also contain the same device-specific identifier that is currently stored by the recipient device. If all the data stored on the device is erased or reset, this will erase or reset not only the stored local sequence value but also the stored device-specific identifier. Any message received after the reinitialisation, containing the device-specific identifier that was formerly stored on the device, will no longer be determined as valid, because its identifier field will no longer match with a stored identifier. Thus, a replay attack, based on replaying a message that was intercepted before the device was reinitialised, will fail, even though it might pass the checks makes on the sequence value and signature, because it will no longer comprise a valid device-identifier for the device.
The device may be configured to perform any of the steps disclosed herein in hardware — e.g. using an application-specific integrated circuit (ASIC) or a field- programmable gate array (FPGA). However, in preferred embodiments, some or all of the steps are performed in software. The device may comprise one or more processors and a memory storing software for execution by the device. The software preferably comprises instructions for determining whether the cryptographically-signed message is valid, and for updating the stored local sequence value.
Thus, from another aspect, the invention provides computer software comprising instructions which, when executed on an electronic device comprising one or more processors and storing a device-specific identifier for the electronic device, and storing a local sequence value associated with an external party, cause the electronic device: to determine whether a cryptographically-signed message, received by the electronic device, and comprising an identifier field, a sequence-value field, and a cryptographic signature, is valid by checking that:
- the cryptographic signature is associated with the external party;
- the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and in response to determining that the message is valid, to update the stored local sequence value to correspond to the received sequence-value field. The device is preferably configured so that the stored local sequence value cannot be erased, reset or decremented unless the device-specific identifier is also erased or reset. This configuration may be provided by software stored on the device, or it may be provided, at least in part, by electronic hardware of the device. For example, in some embodiments the device may be configured to store the local sequence value and the device-specific identifier in a region of memory (e.g. a common page of flash memory) that cannot be erased except by an erase operation that erases the whole region. In some embodiments, the device may comprise a hardware counter for storing the local sequence value, and may comprise protection circuitry for preventing the counter from being reset unless a memory storing the device-specific identifier has first been erased.
The device may be configured to receive the device-specific identifier from outside the device (e.g. within a firmware update for the device). However, in preferred embodiments, the device is configured to generate the device-specific identifier. The device-specific identifier is preferably randomly generated — i.e. using a hardware or software random-number generator. The device-specific identifier may be at least 128 bits, or preferably at least 256 bits, long. This can ensure, or make it extremely unlikely, that, if the device ever receives or generates a new device-specific identifier — e.g. after being reinitialised — the new identifier will not be the same as any previous identifier used by the device. It can also ensure that no two devices share the same device-specific identifier.
In a preferred set of embodiments, the device-specific identifier is a public key associated with the electronic device, or is derived from a public key associated with the electronic device (e.g. being a hash of such a key). The public key may be part of an asymmetric key pair comprising the public key and a private key. The private key may be stored on the electronic device. This can be desirable as many devices are already configured to generate and store such public-private key pairs, and established mechanisms exist for sharing public keys with external parties — e.g. within standardised radio protocols such as Bluetooth. Repurposing a public key as a device specific identifier for preventing replay attacks may therefore be more efficient and easier to implement than using a separate identifier. The device may be configured for performing an initialisation process in which the device generates a device-specific identifier and writes the device-specific identifier to a memory of the device.
The device may be configured to send the device-specific identifier to the external party — e.g. during a pairing process.
The device may perform the checks for determining the validity of received cryptographically-signed messages in any order.
The electronic device may be configured, in response to determining that a received message comprising a command for the device is valid, to process the command. The message may, in some embodiments, comprise a command to erase or reinitialise the electronic device. The device may be configured, in response to receiving such a message, to erase or replace the device-specific identifier; it may also erase the stored local sequence value; it may perform an initialisation process to generate a new device-specific identifier for the device. Such embodiments may advantageously provide support for an erase command for the device that can be sent in a one-way communication exchange, such that the command is “single use” and robust against replay attack. This may provide a convenient mechanism for decommissioning or reinitialising devices in the field.
The electronic device is preferably configured, in response to determining that a received message is not valid, not to update the stored local sequence value. It may be configured to reject the message — e.g. to ignore the message or not to process any command contained in the message. It may signal or report a validation error, e.g. to a user of the electronic device and/or to the external party.
The electronic device may receive or generate an updated device-specific identifier for the electronic device, and may update the stored device-specific identifier on the electronic device with the updated device-specific identifier. The device may thereafter receive a second cryptographically-signed message, being a copy of the aforesaid message. The second cryptographically-signed message may be received from a second party, which may be an imposter performing a replay attack, by sending a copy of a message sent previously by the first party to the electronic device. The cryptographic signature of the second message may therefore be valid. However, the electronic device may determine that the received message is not valid by determining that the identifier field of the second message does not match the updated stored identifier. The device may, in response, reject the second message.
In some embodiments, the received identifier field may be determined to match the stored identifier when and only when the two identifiers are equal. However, in some embodiments, another matching condition may be used, e.g. a condition that allows the received identifier to be a hash of the stored identifier.
The sequence value may be a value from any ordered set of values. It may be an integer count value, although this is not essential. The sequence condition may, in some embodiments, be satisfied when and only when the received sequence value is greater than (or, in some embodiments, greater than or equal to), the stored local sequence value. Greatness may be determined according to any appropriate metric that orders the set of possible sequence values.
Updating the stored local sequence value to correspond to the received sequence- value field may comprise storing the received sequence value as an updated local sequence value (or, in some embodiments, storing the next value after the received sequence value in an ordered set of possible sequence values).
The electronic device may comprise a wired or wireless interface for receiving the cryptographically-signed message. In a preferred set of embodiments, the device comprises a radio transceiver and is configured to receive cryptographically-signed messages by radio. It may support a short-range radio protocol, such as Bluetooth, Bluetooth Low Energy, an IEEE 802.15.4-based protocol, or WiFi, or it may support a cellular network protocol.
Approaches to mitigating replay attacks as disclosed herein may be particularly well- suited to devices that have constrained processing capacity and/or power supply and/or connectivity, such as battery-powered sensors or appliances, since they do not rely on two-way, real-time interactions involving relatively complex cryptographic processing, but may be applied even to one-way messages received by the electronic devices. Thus, in some preferred embodiments, the device is battery-powered device. It may be an wireless sensor device, Internet-of-Things device, or other embedded device. The device may be an integrated-circuit device, such as a system-on-chip.
Software as disclosed herein may be firmware for the device. It may comprise instructions for performing a firmware update process for the device — e.g., for replacing itself with updated firmware. The updated firmware preferably also comprises instructions for reinitialising the device and for determining that received messages are valid, as disclosed herein. In this way, the device can continue to be protected against replay attacks even after a firmware update.
The external party may be a natural or legal person or other entity. It may comprise a further electronic device or electronic apparatus.
From a further aspect, the invention provides a communication system comprising a first electronic device, as disclosed herein, and further comprising a second electronic apparatus configured to send the cryptographically-signed message to the first electronic device. The second electronic apparatus may be the external party, or may be associated with (e.g. controlled by) the external party. The second electronic apparatus may be a second electronic device that also embodies the invention as disclosed herein. It may have some or all of the same optional features as the first electronic device, although this is not essential.
The first electronic device may be configured for sending cryptographically-signed messages to the second electronic device, each cryptographically-signed message comprising a respective identifier of the first electronic device, a respective sequence value, and a respective cryptographic signature. The cryptographic signature may be associated with the first electronic device, or associated with a party that controls or is associated with the first electronic device.
Computer software as disclosed herein may be stored in a memory of an electronic device, or on any other non-transitory computer-readable storage medium.
Features of any aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment described herein. Where reference is made to different embodiments or sets of embodiments, it should be understood that these are not necessarily distinct but may overlap.
BRIEF DESCRIPTION OF THE DRAWINGS
Certain preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
Figure 1 is a schematic diagram of a set of devices communicating by radio, including an electronic device embodying the invention;
Figure 2 is a diagram of an example radio packet structure received by the electronic device; and
Figure 3 is a flow chart showing steps of a message authentication process embodying the invention.
DETAILED DESCRIPTION
Figure 1 shows three electronic devices 1, 2, 3 each equipped with a radio for digital radio communication. Each could be a smart phone, laptop computer, sensor device, cellular network base station, wireless router, domestic appliance, wireless loud speaker, vehicle, or any other types of radio-equipped device. They may all embody the invention, but in this example, at least the first device 1 embodies the invention.
The first device 1 contains a microcontroller 3, radio circuitry 4, and a power supply 5 (e.g. a battery or a mains electrical supply connection). The radio circuitry 4 includes a radio antenna 6, as well as analog and digital circuitry for receiving and demodulating radio packets received at the antenna 6, and for modulating and transmitting radio packets from the antenna 6, under the control of the microcontroller 3. The microcontroller 3 includes a processor 7 and a memory 8, for storing data and software for execution by the processor 7. The memory 8 may be entirely volatile (e.g. RAM), or it may include volatile (e.g. RAM) and non-volatile (e.g. flash) regions. The microcontroller 3 and at least some of the radio circuitry 4 may, in some embodiments, be integrated on a single radio-on-a-chip component.
The radio circuitry 4 may be arranged to support any short-range or long-range digital radio communication protocol, which may be standardised or proprietary. In some embodiments it supports Bluetooth Low Energy and/or one or more IEEE 802.15.4- based protocols such as Zigbee or Thread and/or an IEEE 802.11 protocol. It may support a cellular network standard, e.g. a 4G or 5G protocol, such as LTE-M (Cat M1) or NB-loT.
Also shown is a second device 2, which is capable of communicating with the first device 1 using a common radio protocol. It may be similar to the first device 1 (e.g. both being mobile telephones), or it may be a different type of device. It may be a user device, operated by an individual. However, it may alternatively or additionally be controlled by a larger entity, such as a company, e.g. by being coupled to a corporate network. It may, at least in some embodiments, be able to communicate radio data to the first device 1 under the control of an operator or manufacturer of the first device 1.
Finally, a third device 3 is also shown, which is assumed to be under the control of a malicious attacker. The attacker desires to control the first device 1 by first eavesdropping on communications between the electronic device, and then launching a replay attack on the first device 1. In such a replay attack, the third device 3 impersonates the second device 2 by sending, at a later time, a copy of a radio message that the third device 3 has overheard the second device 2 sending to the first device 1 at an earlier time.
Replay attacks can potentially be launched from a considerable distance away, even when using short-range protocols, since the third device 3 does not necessarily respect normal transmission power limits imposed by standards or regulators. A replay attack may be launched, for instance, by a thief who controls the third device 3, to attempt unlock a locked vehicle or a building lock (embodying the first device 1) by eavesdropping on an unlock command, sent legitimately from a wireless key fob (embodying the second device 2) under the control of the owner, and then replaying the command at a later point in time, when the owner is no longer present.
In general, replay attacks can succeed even if cryptographic signing is used by a sender to cryptographically sign messages it sends to the recipient, with the recipient being arranged to reject any message that are not validly signed. This is because an attacker can simply include the same valid signature in the replayed message and thus fool the recipient. In order to strengthen the protection provided by a signature, an incremental monotonic counter (which could be a software or hardware-based counter or clock, or any other way generating an ordered sequence of values) may be maintained by the sender and used to include a unique sequence value (an integer count value, timestamp, etc.) in each signed message that it sends to the recipient.
The recipient maintains a synchronized counter, or keeps a copy of the latest-received sequence value, and rejects any signed message that contains a sequence value that is lower than an output of the synchronized counter or than a locally-stored sequence value. This can prevent replay attacks.
However, the security of this approach is undermined if it is possible for the local counter (e.g. a clock) or stored sequence value on the recipient device to be reinitialised back to a default starting value (e.g. zero) after the device has been deployed. Such a reinitialisation may occur, for example, when a battery is swapped on a battery-powered device, or if all the memory of the device is erased during a firmware update process. This may then render the recipient device vulnerable to a replay attack, since it will no longer identify a previously-received message as having an invalid sequence value. This risk may be especially acute for simpler, battery- powered or resource-constrained devices, such as a wireless Internet-of-Things device or sensor devices (e.g. a wireless thermostat or door lock), which will typically lack the resources (e.g. an always-on network connection) that might otherwise allow a device to securely re-synchronize a counter or stored local sequence value after such a reinitialisation. This can mean that such a recipient device may still be vulnerable to replay attacks, under certain circumstances (e.g. after a firmware upgrade that erases and reinitialises the memory of the device). It can therefore be impossible, using conventional approaches, for sensitive commands to be sent to such devices with a high assurance of security against abuse through a replay attack. Two-way interactive authentication and communication protocols may mitigate this in some situations, but real-time, two-way interaction between sender and recipient may be undesirable or impossible in many situations.
The first device 1 and the second device 2, however, are configured to communicate using a protocol that provides protection against replay attacks, and which can be used even for sending one-way messages.
This is accomplished by the first device 1 storing a device-specific identifier, and being configured so that, if the first device 1 is ever reinitialised, the stored device-specific identifier will be reinitialised to a new value, alongside any counter or locally-stored sequence values on the first device 1 being reinitialised. The second device 2 then includes the device-specific identifier associated with the first device 1 , as well as an incrementing sequence value, in each signed message that the second device 2 sends to the first device 1. The first device 1 can check that signed messages it receives are valid by checking that the device-specific identifier in the message is the same as its currently-stored device identifier, as well as checking the sequence value and verifying the signature.
If the first device 1 is reinitialised, e.g. after an unexpected power loss or a firmware update, or following an in-field (i.e. post-deployment) command to erase and/or decommission the device 1 (which it might receive from the second device 2), the old device-specific identifier will be replaced with a new device-specific identifier, which the first device 1 will immediately start using for checking the validity of any messages received after the reinitialisation. If the third device 3 then sends a copy of any older message, originally sent to the first device 1 by the second device 2, containing the old device-specific identifier, this will be rejected by the first device 1, even if it contains a valid signature and contains a sequence value that would pass a sequence-value check based on the reinitialised counter of the first device 1. In particular, if the first device 1 were subsequently re-initialized (e.g. re-paired) to accept signed messages from the second device 2, any previous in-field erase or decommissioning command cannot be successfully replayed, even though the signature is valid.
The device-specific identifier is preferably randomly generated. It may, in some embodiments, conveniently be a public key of the first device 1. This may reduce the amount of additional data storage and communication required to implement this approach, since many radio protocols already include mechanisms for generating, storing and distributing public keys, which can conveniently be harnessed.
Figure 2 shows an example of a radio data packet format that could be used when implementing this approach. However, it may readily be integrated into any existing or future radio protocol, e.g. through appropriate modifications to the packet header fields, or by including relevant data in a message body of a packet.
The packet 20 in Figure 2 comprises a recipient address field (“RX addr”) 21, a transmitter address field (“TX addr”) 22, a length field 23, a recipient-device public-key field (“keypubiic”) 24, a sequence value field 25, a message data field 26, and a signature field 27.
In a valid packet, the signature field 27 stores a cryptographic signature for the preceding fields 21-26 of the packet 20. It may be signed by the sender using any appropriate symmetric or asymmetric signature algorithm.
In a valid packet, the recipient-device public-key field 24 should contain the public key of the recipient device (e.g. “keypUbiicj” in the example below), which here serves as a device-specific identifier. Other embodiments might, however, use an identifier that is not part of a cryptographic key pair.
Figure 3 illustrates exemplary steps performed by the first device 1 (Device A) when it is initialised and when it receives a message allegedly sent by the second device 2 (Device B), but which possibly has been sent by the third device 3 in an attempted replay attack.
In a first step 30, the first device 1 is initialised. This could be a first initialisation after manufacturing or deployment, or it could be a reinitialisation, e.g. after an in-the-field firmware update that causes all data stored in the memory 8 of the device 1 to be erased, including any stored device keys and stored sequence values. As part of the initialisation process, firmware executing on the device 1 causes it to use a software or hardware random-number generator of the device 1 to generate a new key pair for the device {keyPriVatej , keypUbiicj}, which it stored in its memory 8.
In a second step 31, the first device 1 pairs with the second device 2 using a radio pairing process. During this process, it sends its new public key, keypUbnc_i, to the second device 2. It also receives the public key, keypUbnc_2, of the second device 2, which it stores in the memory 8. It also exchanges an initial sequence value, seqå, with the second device 2 (e.g. generated by one or other of the devices 1 , 2 and sent to the other device 2, 1). Alternatively, in some embodiments, the sequence value, seqå, might simply start at zero by default after pairing. Both devices 1, 2 store this initial sequence value, seqå, in their respective memories and/or use it to initialise respective hardware counters (e.g. linear-feedback shift registers). The first device 1 may be able to store and maintain a plurality of different sequence values for a plurality of different devices with which it is paired.
In a third step 32, which could occur immediately, or hours or days later, the first device 1 receives a signed message packet 20, having a recipient address field 21 corresponding to the second device 2. The packet 20 has a value keypUbnc_x stored in the recipient-device public-key field 24, and a sequence value, seqx in the a sequence value field 25. It also has a cryptographic signature in the signature field 27.
In a fourth step 33, the first device 1 checks that the received keypUbnc_x equals its stored device-specific identifier keypUbnc_i. If they do not match, it rejects 38 the packet. If they do match, processing proceeds.
In a fifth step 34, the first device 1 checks that the received sequence value seqx is greater than the sequence value it has stored for the second device 2, seqå. If not, it rejects 38 the packet. If so, processing proceeds.
In a sixth step 35, the first device 1 uses the public key of the second device 2 to check that the received signature is valid — i.e. that it confirms the integrity of the packet fields 21-26 and that it is authentically associated with the second device 2. If the signature is not valid, it rejects 38 the packet. If it is valid, processing proceeds.
In a seventh step 36, the first device 1 updates its local store of the sequence value for the second device 2 to equal the received value seq2.
In an eighth step 37, the first device 1 processes the message body of the packet, e.g. by executing any commands it may contain.
The first device 1 then waits to receive any further packets.
The first device 1 is programmed so that the stored seqå value cannot be erased or reset without the device 1 immediately performing an initialisation step 30 so as to generate a new key pair, that renders the old keypUbnc_i obsolete. One example use case that highlights a benefit of this approach is when the radio message received from the second device 2 contains a command to erase the memory 8 of the first device 1 — e.g. as part of a remote decommissioning action or within a firmware update command. By means of the protocol described above, it is possible for an operator to issue such a message to the first device 1 as a single, one way radio packet, without needing an encrypted or authenticated two-way communication exchange in order to provide security against malicious replay attacks. Such a one-way procedure may be useful for erasing a device 1 that is unable to respond in real time for some reason — e.g. when it is in radio reception range but is out of radio transmission range.
It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.

Claims

1. An electronic device configured: to store a device-specific identifier for the electronic device; to store a local sequence value, associated with an external party; to receive a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; to determine whether the received message is valid by checking that:
- the cryptographic signature is associated with the external party;
- the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and in response to determining that the message is valid, to update the stored local sequence value to correspond to the received sequence-value field.
2. The electronic device of claim 1, wherein the electronic device is configured so that the stored local sequence value cannot be erased, reset or decremented unless the device-specific identifier is also erased or reset.
3. The electronic device of claim 1 or 2, wherein the electronic device is configured to generate the device-specific identifier.
4. The electronic device of claim 3, configured to generate the device-specific identifier using a hardware or software random-number generator, and wherein the generated device-specific identifier is at least 32 bits long.
5. The electronic device of any preceding claim, wherein the device-specific identifier is a public key associated with the electronic device, and wherein the device additionally stores a private key of a key pair comprising the public key.
6. The electronic device of any preceding claim, wherein the electronic device is configured for performing an initialisation process in which the electronic device generates a device-specific identifier and writes the device-specific identifier to a memory of the device.
7. The electronic device of any preceding claim, wherein the electronic device is configured, in response to receiving a message comprising a command to erase or reinitialise the device, and determining that the message is valid, to erase or replace the device-specific identifier.
8. The electronic device of claim 7, wherein the electronic device is further configured, in response to receiving said message comprising a command to erase or reinitialise the device, to erase the stored local sequence value.
9. The electronic device of any preceding claim, wherein the electronic device is configured, in response to determining that a received message is not valid, not to update the stored local sequence value.
10. The electronic device of any preceding claim, wherein the electronic device is a battery-powered device comprising a radio transceiver and is configured to receive cryptographically-signed messages by radio.
11. The electronic device of any preceding claim, wherein the electronic device comprises one or more processors and a memory storing software for execution by the device, wherein the software comprises instructions for determining whether the cryptographically-signed message is valid, and for updating the stored local sequence value in response to determining that the message is valid.
12. A method of operating an electronic device, comprising: storing a device-specific identifier for the electronic device on the electronic device; storing a local sequence value, associated with an external party, on the electronic device; the electronic device receiving a cryptographically-signed message comprising an identifier field, a sequence-value field, and a cryptographic signature; the electronic device determining that the received message is valid by checking that:
- the cryptographic signature is associated with the external party; - the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and the electronic device, in response to determining that the message is valid, updating the stored local sequence value to correspond to the received sequence- value field.
13. The method of claim 12, further comprising the electronic device receiving or generating an updated device-specific identifier for the electronic device, and updating the stored device-specific identifier on the electronic device with the updated device specific identifier.
14. The method of claim 13, further comprising, after said updating of the stored device-specific identifier, the electronic device receiving a second cryptographically- signed message, being a copy of the aforesaid cryptographically-signed message, and the electronic device determining that the received message is not valid by determining that the identifier field of the second message does not match the updated stored identifier.
15. Computer software comprising instructions which, when executed on an electronic device comprising one or more processors and storing a device-specific identifier for the electronic device, and storing a local sequence value associated with an external party, cause the electronic device: to determine whether a cryptographically-signed message, received by the electronic device, and comprising an identifier field, a sequence-value field, and a cryptographic signature, is valid by checking that:
- the cryptographic signature is associated with the external party;
- the cryptographic signature confirms the integrity of the identifier field and the sequence-value field;
- the received identifier field matches the stored identifier; and
- the received sequence-value field satisfies a sequence condition determined in dependence on the stored local sequence value; and in response to determining that the message is valid, to update the stored local sequence value to correspond to the received sequence-value field.
PCT/EP2022/063094 2021-05-24 2022-05-13 Replay attack protection WO2022248258A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2107397.8 2021-05-24
GB2107397.8A GB2606035B (en) 2021-05-24 2021-05-24 Replay attack protection

Publications (1)

Publication Number Publication Date
WO2022248258A1 true WO2022248258A1 (en) 2022-12-01

Family

ID=76637601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/063094 WO2022248258A1 (en) 2021-05-24 2022-05-13 Replay attack protection

Country Status (2)

Country Link
GB (1) GB2606035B (en)
WO (1) WO2022248258A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009029169A1 (en) * 2007-08-27 2009-03-05 Lucent Technologies Inc. Method and system of communication using extended sequence number
US20100306538A1 (en) * 2009-05-28 2010-12-02 Qualcomm Incorporated Trust Establishment from Forward Link Only to Non-Forward Link Only Devices
US20150270975A1 (en) * 2014-03-20 2015-09-24 Certicom Corp. Method for validating messages

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160134607A1 (en) * 2014-11-07 2016-05-12 Telefonaktiebolaget L M Ericsson (Publ) Method of rsvp authentication with non-directly connected neighbor

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009029169A1 (en) * 2007-08-27 2009-03-05 Lucent Technologies Inc. Method and system of communication using extended sequence number
US20100306538A1 (en) * 2009-05-28 2010-12-02 Qualcomm Incorporated Trust Establishment from Forward Link Only to Non-Forward Link Only Devices
US20150270975A1 (en) * 2014-03-20 2015-09-24 Certicom Corp. Method for validating messages

Also Published As

Publication number Publication date
GB202107397D0 (en) 2021-07-07
GB2606035B (en) 2023-09-06
GB2606035A (en) 2022-10-26

Similar Documents

Publication Publication Date Title
WO2021121125A1 (en) Control method for smart home devices and medium and terminal thereof
JP4812830B2 (en) Low power transmit provisioning for wireless network devices
KR101229703B1 (en) Anonymous authentication method based on pre-shared cipher key, reader-writer, electronic tag and system thereof
US8001381B2 (en) Method and system for mutual authentication of nodes in a wireless communication network
US20200259667A1 (en) Distributed management system for remote devices and methods thereof
CN108738017A (en) Secure communication in network access point
US5475763A (en) Method of deriving a per-message signature for a DSS or El Gamal encryption system
US20050266798A1 (en) Linking security association to entries in a contact directory of a wireless device
KR101256284B1 (en) Electronic label authenticating method and system
JP2015532557A (en) Wireless communication system
EP1277299A1 (en) Method for securing communications between a terminal and an additional user equipment
Bilal et al. Security analysis of ultra-lightweight cryptographic protocol for low-cost RFID tags: Gossamer protocol
CN101247605A (en) Short information enciphering and endorsement method, mobile terminal and short information ciphering system
US9773129B2 (en) Anti-replay protected flash
US20200084552A1 (en) Hearing device with service mode and related method
CN106850540A (en) A kind of terminal control method, terminal and system
KR20190134924A (en) Hardware secure module
JP2002232962A (en) Mobile communication authentication interworking system
CN108182048B (en) Hearing system, apparatus and method for protecting communication of user applications
WO2021159506A1 (en) Method and apparatus for automatic identity recognition, and chip
WO2022248258A1 (en) Replay attack protection
CN114827998B (en) Satellite terminal network access authentication device based on encryption chip
Khalfaoui et al. Security Analysis of Out‐of‐Band Device Pairing Protocols: A Survey
CN112423277B (en) Security certificate recovery in bluetooth mesh networks
CN111651740B (en) Trusted platform sharing system for distributed intelligent embedded system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22729511

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22729511

Country of ref document: EP

Kind code of ref document: A1