GB2494550A - Dynamic address allocation to a radio device - Google Patents

Dynamic address allocation to a radio device Download PDF

Info

Publication number
GB2494550A
GB2494550A GB1218296.0A GB201218296A GB2494550A GB 2494550 A GB2494550 A GB 2494550A GB 201218296 A GB201218296 A GB 201218296A GB 2494550 A GB2494550 A GB 2494550A
Authority
GB
United Kingdom
Prior art keywords
text
value
address
counter
radio device
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
GB1218296.0A
Other versions
GB201218296D0 (en
GB2494550B (en
Inventor
David Alexandre Engelien-Lopes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nordic Semiconductor ASA
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
Priority to GB1218296.0A priority Critical patent/GB2494550B/en
Publication of GB201218296D0 publication Critical patent/GB201218296D0/en
Publication of GB2494550A publication Critical patent/GB2494550A/en
Priority to PCT/EP2013/070285 priority patent/WO2014056744A1/en
Priority to CN201380052695.1A priority patent/CN104704771A/en
Priority to JP2015536059A priority patent/JP6328123B2/en
Priority to KR1020157012340A priority patent/KR20150068471A/en
Application granted granted Critical
Publication of GB2494550B publication Critical patent/GB2494550B/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • 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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • 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

Abstract

A short-range radio peripheral device (eg. Bluetooth heart monitor 7 slaved to a mobile phone 3) undergoes secure dynamic address allocation by taking a value derived from a counter and hashing a combination of this value and a stored 128-bit peer Identity Resolving Key (IRK) to produce a resolvable private address for data packets 2. Since each new address is generated by incrementing the counter (eg. every 15 minutes), the master or slave device can distinguish fresh addresses from old addresses, thus indicating a masquerade or mimic attack from peer 11 if an old address (eg. >1 year) is detected. The hash complies with the Advanced Encryption Standard (AES), and the address may comprise the most significant octet of the counter value (ie. a 24-bit count + bits 1 and 0 ) and the least significant octet of the IRK hash (ie. 24-bit hash ).

Description

Addressable Radio Device This invention relates to addressable radio devices.
A number of short-range radio communication protocols are known in which a master device communicates with a peripheral or slave device, e.g. to control the peripheral device and/or to receive data from it or to send data to it. Such protocols include Bluetooth, Bluetooth Low Energy, ANT and Zigbee. Such a radio device is typically an addressable device; i.e. it has an associated device address and is configured to respond (e.g. by performing an action or by transmitting a return message) to radio messages addressed to that device address (e.g. radio messages which contain the device address as part of the message). It will typically ignore at least some radio messages addressed to other devices in a system.
A slave device might, for instance, be a wireless heart-rate monitor, which could be controlled by a user's mobile telephone, acting as a master device. The mobile telephone could collect heart-rate information from the monitor and display it for the user.
Such radio devices typically have associated device addresses which are included in transmitted data packets in order to determine the sender and/or intended recipient of the data. A device address may be included in every data frame, or only at the beginning of an exchange, e.g. in an advertising message (after which some form of session or channel identifier may be used instead).
The possibility therefore exists for a person to be identified and/or tracked by listening for a device address or addresses known to be associated with that person; for instance, the address of a head-rate monitor or mobile telephone belonging to that person. This leads to privacy concerns.
One approach to addressing such concerns is exemplified in the Bluetooth Low Energy specifications (e.g. Bluetooth Core Specification 4.0, published 30 June 2010). This allows a device to use a "resolvable private address" instead of a static, public address. Figure 1 shows the structure of such a resolvable private address 1. The address consists of a randomly generated 24-bit random number, prand, which is concatenated with a hash value, hash. The two most-significant bits of prand always equal 0' and 1' as shown; the remaining bits are random and must not all equal 0' nor all equal 1'. The value of hash is the 24 least-significant bits of the result of encrypting prand (zero-padded to 128 bits) using the Advanced Encryption Standard (AES) encryption algorithm with a device-specific 128-bit "Identity Resolving Key" (IRK).
The device can change its private address at regular intervals by generating a new value of prand and calculating a corresponding new hash value. To an outside observer, the private address appears to be random data (with the exception of the two most-significant bits), such that the device cannot be consistently identified or tracked after each new change of address. However, the private address can still be used to determine the identity of the device by any other device with which the first device has previously shared its Identity Resolving Key (IRK). On receiving a resolvable private address, the second device tries to decrypt the hash component using the IRK of each device known to it, in turn. If a particular IRK results in a decrypted value that matches the prand component of the address, this reveals the identity of the first device, because the address must belong to the device whose IRK was successfully used. If a slave device (e.g. a heart-rate monitor) advertises itself using a resolvable private address, an eavesdropper should be unable to identify or track the slave device (and the person carrying it) for any longer than the interval between address changes. Similarly, if a master device (e.g. a mobile telephone) uses a resolvable private address when scanning for or connecting with a slave device, an eavesdropper should be unable to identify or track the master device (and the person carrying it) for any longer than the interval between address changes.
However, the applicant has recognised that such an approach can still be vulnerable to privacy attacks if a third party actively masquerades as a known peer (i.e. as a white-listed device). The present invention thus seeks to provide a better approach.
From a first aspect, the invention provides an addressable radio device having an address that comprises (i) a value deiived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device.
Thus it will be seen by those skilled in the art that, in accordance with the invention, a device uses an address based on a counter, which allows a new device address to be generated by incrementing the counter. Significantly, this allows old addresses to be readily distinguished from current and future addresses. A second, peered device, on receiving an address of the first device, can check that the address is fresh by checking that the value in the address is derived from a higher value of the counter than was the case for an address used by the first device in an earlier communication with the second device. Such a check (or similar) can be used to reduce the opportunity for a privacy attack on the second device in which an attacker masquerades as the known, first device by transmitting a message containing a device address of the first device, acquired through prior eavesdropping of radio communications, with the aim of eliciting an identifiable response from the second device. If the second device determines that the device address presented by the attacker is an old address, it can decide not to respond, thereby thwarting any attempt at identification or tracking.
The invention can be viewed from various aspects.
From a second aspect, the invention provides a method of generating an address for an addressable radio device, the method comprising: deriving a value from a counter; and calculating an address comprising (i) said value and (U) a hash of a combination of said value and an identity-resolving key for the device.
The method preferably further comprises incrementing the counter.
From a third aspect, the invention provides a method of operating an addressable radio device, the method comprising the device transmitting by radio an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device. The address may be included in an advertising message.
From a fourth aspect, the invention provides a method of operating an addressable radio device, wherein the radio device has an address that comprises (i) a value derived from a counter and (U) a hash of a combination of said value and an identity-resolving key for the device, the method comprising the device receiving and processing a radio transmission that includes the address of the radio device.
From a fifth aspect, the invention provides a method of operating a radio device, the method comprising the device receiving and processing a radio transmission, wherein the radio transmission includes an address of a second, sending radio device, and wherein the address comprises (i) a value derived from a counter and (U) a hash of a combination of said value and an identity-resolving key for the sending device. The first radio device may be addressable; i.e. it may be associated with a first device address and may be configured to respond to a radio message addressed to that device address (e.g. containing the address). Said radio transmission may also include an address of the first, receiving radio device, although this is not essential (e.g. the transmission may instead be an undirected advertising event).
In some embodiments, the device address may be contained in an advertising protocol data unit (PDU), scanning PDU or initiating PDU, substantially as defined in the Bluetooth Low Energy specifications (except for using the novel address format).
The radio device preferably comprises means for calculating or generating the address, such as hardware logic and/or a microcontroller running software. The device is preferably configured to derive said value from the counter. The counter may be remote from the device, but the device preferably comprises the counter.
For instance, the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device. The counter may comprise hardware and/or software configured to maintain and increment a count value. It may, for instance, comprise a number of flip-flops, or it may be implemented by firmware running on a microcontroller, e.g. as a variable stored in memory. The counter is preferably configured to store or maintain a current count value across multiple radio transmissions or sessions, which may include when other circuitry in the device is powered down or in a sleep state. The device may store a current count value in non-volatile memory, or it may be configured to maintain power to a counter memory while other circuitry in the device is powered down or asleep. A reset mechanism for the counter may be provided.
The counter may count in any appropriate way. In preferred embodiments, it is a counter that increments through successive integer values. The value derived from the counter may simply be the current value of the counter. However, it may be some function of the value of the counter, such as a multiple of the output of the counter. In one preferred set of embodiments, the value is the output of the counter, with two appended bits: a "1" in the next-to-most-significant bit position and a "0" in the most-significant bit position. The total length of the value may be 24 bits. Such a format can provide compatibility with existing Bluetooth Low Energy devices.
The device is preferably configured to increment the counter. It may be configured to do this at regular intervals, or when a particular condition is met. This is explained in more detail below. The counter is preferably initiated to a starting value (e.g. zero) when the device is commissioned. The device may be configured to reset the counter to a starting value when a reset condition is met.
The counter is preferably of sufficient capacity that, in normal usage, it will not roll over during the expected lifetime of the device. For instance, it may be a counter having at least 2b0 unique values, preferably at least 220 unique values. In a preferred set of embodiments, it is a 22-bit counter.
The hash may take any suitable form. The device is preferably configured to apply a hash algorithm to the value and the identity-resolving key. The hash algorithm preferably acts on the value and the identity-resolving key to generate an output in such a way that it is infeasible or impossible to determine the key from the output.
The hash is preferably such that it is infeasible or impossible, for a given output, to determine a value and key that would cause the function to generate this output.
The hash preferably uses the Advanced Encryption Standard (AES) algorithm; preferably using the identity-resolving key as the encryption key (preferably a 128-bit key); and preferably to encrypt the value derived from the counter (which may be padded to an appropriate length as necessary, e.g. with zero bits). The hash may be the truncated output of an encryption operations. Preferably! the hash is a function of the output of an AES operation, such as comprising the 24 least-significant bits of the output. This can reduce the size of the total address, leading to more efficient transmission. It can also provide compatibility with existing Sluetooth Low Energy devices. The hash is preferably calculated as the "Random Address Hash function ah" in a Bluetooth Core Specification (e.g. version 4.0), where r is the value derived from the counter.
The identity-resolving key may be a 128-bit number. It is preferably specific to the device. It may be stored in a memory of the device. Knowledge of the key by another device preferably allows that other device to determine the identity of the first device from the address. The nature and use of the identity-resolving key by devices embodying the present invention may be substantially as described for the identity-resolving keys in a Bluetooth Core Specification (e.g. version 4.0).
The device is preferably configured to generate the address from the value derived from a counter. The address is preferably the value concatenated with the hash. A least significant octet of the hash may become the least significant octet of the address, while a most significant octet of the value may become the most significant octet of the address. The device may comprise a memory and may store the address in the memory. The device may have multiple addresses, but in at least some embodiments the device has only the one address.
The device is preferably configured to operate substantially as a Bluetooth Low Energy device; i.e. as defined in a Bluetooth Core Specification (e.g. version 4.0).
The device may be configured to transmit a radio message containing, e.g. advertising, its address. Such a device may be configured to act as a slave device, e.g. substantially in accordance with a Bluetooth Low Energy slave role as defined in a Bluetooth Core Specification (e.g. version 4.0). The address may be encoded in any suitable way. The device may be configured to change its address at intervals by incrementing the counter; and preferably at regular intervals, e.g. about every 15 minutes.
The device may be configured to act as a master device, e.g. substantially in accordance with a Bluetooth Low Energy master role as defined in a Bluetooth Core Specification (e.g. version 4.0). It may be configured to transmit a scanning or connection radio message that includes its address. Such a device may be configured to change its address by incrementing the counter after completing a connection establishment with a slave device.
The device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device. The device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device, or until all the keys have been tried without a match (if the device is unknown). The first device preferably stores a local count value associated with each peer device or identity-resolving key. After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition. The freshness condition may include that the received value is derived from a counter that is greater than the local count value. This can be used to ensure that an attacker is not mimicking the known device by replaying a captured address used previously by the device.
The condition may also include that the received value is derived from a counter that is not more than a freshness threshold amount greater than the local count value. This freshness threshold can effectively set a limit on how long the second device can be out of communication with the first device and still satisfy the freshness condition. If the second device is a slave device that changes its address every 15 minutes, the freshness threshold may be around 35,000, which would correspond to about a year. It may, however, be much less than this, e.g. around or 1,000, or it may be more, e.g. around 100,000 or more. Applying such a freshness threshold can limit the opportunity for an attacker to capture an address transmitted by the second device after its last communication with the first device and to use such an address to masquerade as the first device. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed.
In some embodiment, the first device may increment a local count value at regular intervals, e.g. every 15 minutes; this may allow the local count value stored by a master device to remain approximately synchronised with a counter used by a second, slave device, which could further limit an attacker's opportunity to masquerade as the second device by allowing a smaller freshness threshold to be
acceptable.
In some implementations, the counter and/or a local count value may be stored using finite precision, e.g. 22 bits. It may be subject to modulo-arithmetic roll-over.
A first value being "greater" than a second value may be given any appropriate definition in such contexts; e.g. the first value may be understood as being greater than the second if it is ahead of the second value by up to half, or some other suitable fraction, of the modulus.
From a six aspect, the invention provides a radio device configured to: receive a radio transmission that includes an address of a sending radio device, wherein the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the sending device; determine that the received hash is a combination of the received value and a stored identity-resolving key associated with the sending radio device; and determine that the received value satisfies a predetermined freshness condition.
Such a radio device may itself have an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device, but this is not essential. It may implement any of the optional features described above concerning freshness conditions.
From a further aspect, the invention provides a communication system comprising a first radio device and a second radio device, wherein the first radio device is configured to: send a radio transmission that includes an address of the first radio device, wherein the address comprises (i) a value derived from a counter and (U) a hash of a combination of said value and an identity-resolving key for the first device, and wherein the second radio device is configured to: receive said radio transmission; determine that the received hash is a combination of the received value and a stored identity-resolving key associated with the first radio device; and determine that the received value satisfies a predetermined freshness condition.
A radio device according to any of the foregoing aspects is preferably configured to send its identity-resolving key to another device and/or to receive an identity-resolving key from another radio device. Such a key transmission or exchange preferably occurs substantially as described in a Bluetooth Core Specification (e.g. version 4.0).
A radio device according to any of the foregoing aspects preferably comprises a radio transmitter and/or radio receiver. It preferably comprises processing means for carrying out steps described herein. Such processing means may comprise any one or more of: a CPU, a microcontroller, a microprocessor, an ASIC and an FPGA.
The invention extends to software (e.g. firmware) comprising instructions which, when executed on a radio device comprising processing means, causes the processing means to carry out any of the methods described herein.
In one set of embodiments, the value derived from a counter in the device address may be, or may comprise, an encrypted value derived from a counter (e.g. an encrypted count value). It may be encrypted with a device-specific key, such as the identity-resolving key. The value may be encrypted using the Advanced Encryption Standard (AES) encryption algorithm (e.g. occupying 128 bits in the device address), or some other algorithm (e.g. an encryption algorithm that outputs a 24-bit encrypted value). A receiving radio device may use a corresponding decryption key to decrypt the received encrypted value. The use of such encryption may further reduce the potential for an attacker to track a device, by making the value part of the address appear random and unpredictable to anyone without possession of an appropriate key.
A similar effect may be achieved in other embodiments by the value derived from a counter being, or comprising, a hash of a value derived from a counter (e.g. a 24-bit hash of a count value). The hash is preferably calculated using a key such as the identity-resolving key, for instance using the same hash algorithm as previously described. Since a receiving device cannot necessarily reconstruct, from a received hash, the original value derived from the counter (because hash functions are typically one-way functions), the receiving device may be configured to generate a set of allowable hash values based on successive local count values, and check that the received hash matches one of the set of allowable hash values.
The set may contain a freshness threshold number of different hash values, based on incremental local count values starting from a stored local count value as described previously.
In another set of embodiments, the value derived from a counter may be derived from a linear feedback shift register (LFSR) or other pseudo-random number generator, with each successive LFSR or pseudo-random output corresponding to a counter increment. Again, a receiving device may be configured to compare a received value against a sequence of locally-generated LFSR or pseudo-random values, which may be seeded from a local count associated with the sending device, and which may contain a freshness threshold number of member values.
Optional or preferred features of one aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment.
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 figurative representation of a radio device address known from
the prior art;
Figure 2 is a figurative representation of a radio device address according to the invention; Figure 3 is a schematic diagram of two radio devices embodying the invention and a malicious device; Figure 4 is a flow diagram of steps carried out by a master radio device embodying the invention; and Figure 5 is a flow diagram of steps carried out by a slave radio device embodying the invention.
Figure 2 shows an address of a radio device embodying the invention. It has a 24-bit count portion, count, which consists of a numerical count value from a counter, concatenated with the bits "1" and "0". It also has a 24-bit hash portion, hash, which is the 24 least-significant bits of the result of encrypting count (zero-padded to 128 bits) using the Advanced Encryption Standard (AES) encryption algorithm with a device-specific 128-bit key (referred to as an identity-resolving key or IRK).
Figure 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6. Also shown is a second radio device 7, which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10. For the present purposes, the second device 7 is assumed to be peered (paired) with the first radio device 3. As a consequence of this peering, the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9.
Finally, a third radio device 11 is also shown, which is assumed to be under the control of a malicious attacker. The attacker desires to determine when the first radio device 3 is in the vicinity of the third device 11, e.g. for the purposes of tracking the movements of the owner of the first radio device 3. If the first device 3 transmits messages containing its static device address, this is straightforward.
The Bluetooth Core Specification 4.0 provides a mechanism of resolvable private addresses (RPA) to thwart this. However, an attacker can circumvent this by eavesdropping on communication by the second radio device 7, such as an advertising message; noting the device address of the second device 7 contained in the message; and subsequently transmitting its own advertising messages containing this address (i.e. impersonating the second radio 7), so as to elicit a -12-response from the first device 3. If it receives such a response from the first device 3, it can use this to determine that the first device 3 is in the vicinity of the third device 11.
However, by having the first and second radio devices 3, 7 embody the present invention, such an attack can be detected by the first device 3 with high probability.
This is because the second radio device 7 uses an address such as that shown in Figure 2, and updates the count value at regular intervals. The attacker can only cause the third device 11 to replay an address that it has heard from the second device 7; it cannot generate future addresses because it does not know the IRK for calculating the hash portion of the address. The first device 3 can identify if it receives an expired address in an advertising message from the third device 11 and choose not to respond, thereby thwarting the attack.
Figure 4 shows steps taken by a radio device embodying the invention and acting in a master role, in respect of a peered slave device, substantially as defined in the Bluetooth Core Specification 4.0. The master device knows the IRK of the slave device from a pairing operation (not shown), and maintains a local variable Remotecounter for the slave device which it updates with the latest-resolved address of the slave device after successful receipt and validation of an advertising message from that slave device. It also stores a 22-bit variable LocalCounter which it uses to generate its own master-device address having the format shown in Figure 2. The value count in the master-device address is given by the current value of Loca/Counter concatenated with a "1" bit and "0" bit as shown in Figure 2.
These variables are initiated to zero when first created.
When the master device receives a directed or undirected advertisement message which includes a resolvable private address of a slave device according to an embodiment of the invention (e.g. in an AdvA field), it first tries to identify the slave device. It does this by applying each slave IRK known to master device to the count value of the received slave address it in turn, using the AES-based hash algorithm described above, until it finds one that generates an output that is identical to the hash value in the received address. If none is found, the advertisement is discarded. If a matching IRK is found, the device then checks whether the received count satisfies validity criteria. If not, the advertisement is discarded. A value ReceiveclCounter is extracted from count by stripping the two most-significant bits. The validity criteria are that ReceiveciCounter is greater than RemoteCounter, and that ReceivedCounter minus RemoteCounter is less than a freshness threshold, CountPrivacy. In some embodiments, CountPrivacy may be set equal to 35,000, which corresponds to approximate a year of regular slave counter increments. Other values may, of course, be used. The arithmetic is carried out using always-positive values, modulo 222. The 22-bit counter will roll over approximately every 120 years with 15-minute slave-counter increments.
If the checks are passed, the master device stores the received slave address (or updates a previously-stored version) for use in any response message. It also updates its own address using the current value of Loca/Counter. It then increments the value of LocalCounter and sets RemoteCounter equal to ReceivedCounter. It also continues with any required response to the slave device, such as establishing a connection with it.
As an example of possible behaviour when a 22-bit counter is near to rolling over (which is unlikely to happen in any real-world implementation), assume a master device receives an advertisement packet with a resolvable private address (RPA) having a Receivedcounter value of 1,000, and has set the CountPrivacy to 10,000.
Assume the master device's RemoteGounter is currently set to 4,194,000, Then the ReceivedCounter value minus RemoteCounter value, modulo 222 (4,194,304), is 1,304, which is less than CountPrivacy. A connect request packet may thus be sent and connection establishment initiated. The RemoteCounter is then set to the ReceivedCounter value. However, if CountPrivacy had instead been set to 1,000, then the ReceivedCounter value minus RemoteCounter value, modulo 4,194,304, would have been greater than CountPrivacy, in which case a connect request packet should not be sent.
If a software application running on the radio device sets CountPrivacytoo low, this may create usability issues since low values, when exceeded, will force a re-bond to occur to reset the counter values. However if CountPrivacy is set too high then the protection against active privacy attacks is reduced because the second device may not know that it is being tracked (by being tricked into responding to an attacker masquerading as the known, peered device) for some considerable time. -14-
Figure 5 shows steps taken by a radio device embodying the invention and acting in a slave role, in respect of a peered master device, substantially as defined in the Bluetooth Core Specification 4.0. The slave device knows the IRK of the master device from a pairing operation (not shown), and maintains a local variable RemoteCounter for the master device which it updates with the latest-resolved address of the master device after successful receipt and validation of a connection message from the master device (e.g. taken from an InitA field). It also stores a 22-bit variable LocalCounter which it uses to generate its own slave-device address having the format shown in Figure 2. The value count in the slave-device address is given by the current value of Loca/Counter concatenated with a "1" bit and "0" bit as shown in Figure 2. These variables are initiated to zero when first created.
After initialisation, the slave device sets its own address using the current value of LocalCounter. It also generates and stores the master device address using the master-device IRK (known to the slave from the pairing operation) based on the current value of RemoteCounter.
Whenever the slave device is not responding to a connection request, it increments Localcounter every 15 minutes. Of course, other increment intervals are also possible.
When the slave device receives a connection message which includes a resolvable private address of a master device according to an embodiment of the invention, it first verifies the identity of the master device. It does this by applying the master IRK to the count value of the received master address, using the AES-based hash algorithm described above, and checking that the output is identical to the hash value in the received address. If it does not match, the connection message is discarded. If it matches, the slave device then checks whether the received count satisfies validity criteria. If not, the connection message is discarded. A value Receivedcounter is extracted from count by stripping the two most-significant bits.
The validity criteria are that Receivedcounter is greater than Remotecounter, and that Receivedcounter minus RemoteCounter is less than a freshness threshold. In some embodiments, this threshold is 1,000, which is expected to give reasonable protection from attackers while maintaining acceptable usability. Other values may, of course, be used. The arithmetic is carried out using always-positive values, modulo 222.
If the checks are passed, the slave device increments the value of Loca/Counter and sets RemoteCounter equal to ReceivedCounter. It updates the stored master address and its own address using the new values. It also continues with any required response to the master device, such as establishing a connection with it.
In this way, both a master device 3 and a slave device 7 can reduce the potential for an attacker to identify and track them. For a master device 3 to be maximally protected, it should require that all the slave devices it is peered with use counter-based addresses according to the present invention. However, some protection may be obtained even if this is not the case, since some slave devices may only communicate with the master device relatively infrequently, or out of range of an attacker.

Claims (1)

  1. <claim-text>Claims 1. An addressable radio device having an address that comprises (i) a value derived from a counter and (U) a hash of a combination of said value and an identity-resolving key for the device.</claim-text> <claim-text>2. An addressable radio device as claimed in claim 1, wherein the value is 24 bits in length and the hash is 24 bits in length.</claim-text> <claim-text>3. An addressable radio device as claimed in claim 1 or 2, wherein the device comprises the counter.</claim-text> <claim-text>4. An addressable radio device as claimed in any preceding claim, wherein the counter increments through successive integer values.</claim-text> <claim-text>5. An addressable radio device as claimed in any preceding claim, comprising means for generating the address.</claim-text> <claim-text>6. An addressable radio device as claimed in any preceding claim, wherein the hash is a function of the output of an Advanced Encryption Standard (AES) encryption of the value derived from the counter, with the identity-resolving key as an encryption key.</claim-text> <claim-text>7. An addressable radio device as claimed in any preceding claim, wherein the identity-resolving key is a 128-bit number.</claim-text> <claim-text>8. An addressable radio device as claimed in any preceding claim, wherein the address is a concatenation of (i) the value derived from a counter and (ii) the hash.</claim-text> <claim-text>9. An addressable radio device as claimed in any preceding claim, configured to transmit a radio message containing the address.</claim-text> <claim-text>10. An addressable radio device as claimed in any preceding claim, configured to change its address at intervals by incrementing the counter.</claim-text> <claim-text>11. An addressable radio device as claimed in any preceding claim, configured to receive and respond to a radio message containing the address.</claim-text> <claim-text>12. An addressable radio device as claimed in any preceding claim, configured to operate substantially as a Bluetooth Low Energy device.</claim-text> <claim-text>13. A method of generating an address for an addressable radio device, the method comprising: deriving a value from a counter; and calculating an address comprising (i) said value and (U) a hash of a combination of said value and an identity-resolving key for the device.</claim-text> <claim-text>14. A method as claimed in claim 13, further comprising incrementing the counter.</claim-text> <claim-text>15. A method of operating an addressable radio device, the method comprising the device transmitting by radio an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device.</claim-text> <claim-text>16. A method of operating an addressable radio device, wherein the radio device has an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device, the method comprising the device receiving and processing a radio transmission that includes the address of the radio device.</claim-text> <claim-text>17. A method of operating a radio device, the method comprising the device receiving and processing a radio transmission, wherein the radio transmission includes an address of a second, sending radio device, and wherein the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the sending radio device.</claim-text> <claim-text>18. A method as claimed in claim 17, further comprising the device: determining that the received hash is a combination of the received value and a stored identity-resolving key associated with the sending radio device; and determining that the received value satisfies a predetermined freshness condition.</claim-text> <claim-text>19. A method as claimed in claim 18, wherein the freshness condition includes that the received value is derived from a counter that is greater than a stored local count value associated with the sending radio device.</claim-text> <claim-text>20. A method as claimed in claim 18 or 19, wherein the freshness condition includes that the received value is derived from a counter that is not more than a freshness threshold amount greater than a local count value associated with the sending radio device.</claim-text> <claim-text>21. A radio device configured to: receive a radio transmission that includes an address of a sending radio device, wherein the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the sending device; determine that the received hash is a combination of the received value and a stored identity-resolving key associated with the sending radio device; and determine that the received value satisfies a predetermined freshness condition.</claim-text> <claim-text>22. A radio device as claimed in claim 21, wherein the freshness condition includes that the received value is derived from a counter that is greater than a stored local count value associated with the sending radio device.</claim-text> <claim-text>23. A radio device as claimed in claim 21 or 22, wherein the freshness condition includes that the received value is derived from a counter that is not more than a freshness threshold amount greater than a local count value associated with the sending radio device.</claim-text> <claim-text>24. A radio device substantially as described herein with reference to the accompanying drawings.</claim-text> <claim-text>25. A method substantially as described herein with reference to the accompanying drawings.</claim-text>
GB1218296.0A 2012-10-11 2012-10-11 Addressable radio device Expired - Fee Related GB2494550B (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
GB1218296.0A GB2494550B (en) 2012-10-11 2012-10-11 Addressable radio device
PCT/EP2013/070285 WO2014056744A1 (en) 2012-10-11 2013-09-27 Addressable radio device
CN201380052695.1A CN104704771A (en) 2012-10-11 2013-09-27 Addressable radio device
JP2015536059A JP6328123B2 (en) 2012-10-11 2013-09-27 Addressable wireless device
KR1020157012340A KR20150068471A (en) 2012-10-11 2013-09-27 Addressable radio device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1218296.0A GB2494550B (en) 2012-10-11 2012-10-11 Addressable radio device

Publications (3)

Publication Number Publication Date
GB201218296D0 GB201218296D0 (en) 2012-11-28
GB2494550A true GB2494550A (en) 2013-03-13
GB2494550B GB2494550B (en) 2016-06-01

Family

ID=47324646

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1218296.0A Expired - Fee Related GB2494550B (en) 2012-10-11 2012-10-11 Addressable radio device

Country Status (1)

Country Link
GB (1) GB2494550B (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2565280A (en) * 2017-08-01 2019-02-13 Nordic Semiconductor Asa Radio communication
WO2019221904A1 (en) * 2018-05-16 2019-11-21 Bose Corporation Secure systems and methods for establishing wireless audio sharing connection
WO2019221906A1 (en) * 2018-05-17 2019-11-21 Bose Corporation Secure systems and methods for resolving audio device identity using remote application
US11057303B2 (en) 2017-08-01 2021-07-06 Nordic Semiconductor Asa Radio communication method and apparatus for generating data channel access addresses
US11057772B2 (en) 2015-10-16 2021-07-06 Nokia Technologies Oy Message authentication
US11089510B2 (en) 2017-08-01 2021-08-10 Nordic Semiconductor Asa Generating radio data-channel access addresses from a base address seed
US11102655B1 (en) 2020-03-31 2021-08-24 Bose Corporation Secure device action initiation using a remote device
EP4009585A1 (en) * 2020-12-01 2022-06-08 Nordic Semiconductor ASA Digital radio communications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060274643A1 (en) * 2005-06-03 2006-12-07 Alcatel Protection for wireless devices against false access-point attacks
US20120257753A1 (en) * 2011-04-05 2012-10-11 Broadcom Corporation MAC Address Anonymizer

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009027770A1 (en) * 2007-08-31 2009-03-05 Nokia Corporation Method and apparatus for propagating encryption keys between wireless communication devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060274643A1 (en) * 2005-06-03 2006-12-07 Alcatel Protection for wireless devices against false access-point attacks
US20120257753A1 (en) * 2011-04-05 2012-10-11 Broadcom Corporation MAC Address Anonymizer

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11057772B2 (en) 2015-10-16 2021-07-06 Nokia Technologies Oy Message authentication
GB2565280A (en) * 2017-08-01 2019-02-13 Nordic Semiconductor Asa Radio communication
US11057303B2 (en) 2017-08-01 2021-07-06 Nordic Semiconductor Asa Radio communication method and apparatus for generating data channel access addresses
US11089510B2 (en) 2017-08-01 2021-08-10 Nordic Semiconductor Asa Generating radio data-channel access addresses from a base address seed
GB2565280B (en) * 2017-08-01 2022-02-16 Nordic Semiconductor Asa Radio communication
WO2019221904A1 (en) * 2018-05-16 2019-11-21 Bose Corporation Secure systems and methods for establishing wireless audio sharing connection
WO2019221906A1 (en) * 2018-05-17 2019-11-21 Bose Corporation Secure systems and methods for resolving audio device identity using remote application
US10637651B2 (en) 2018-05-17 2020-04-28 Bose Corporation Secure systems and methods for resolving audio device identity using remote application
US11102655B1 (en) 2020-03-31 2021-08-24 Bose Corporation Secure device action initiation using a remote device
EP4009585A1 (en) * 2020-12-01 2022-06-08 Nordic Semiconductor ASA Digital radio communications
US11917402B2 (en) 2020-12-01 2024-02-27 Nordic Semiconductor Asa Digital radio communications

Also Published As

Publication number Publication date
GB201218296D0 (en) 2012-11-28
GB2494550B (en) 2016-06-01

Similar Documents

Publication Publication Date Title
US9107069B2 (en) Addressable radio device
GB2494550A (en) Dynamic address allocation to a radio device
WO2014056744A1 (en) Addressable radio device
EP2850862B1 (en) Secure paging
Tsai et al. Secure session key generation method for LoRaWAN servers
JP5877623B2 (en) Transmission terminal, reception terminal, and information distribution system
Zeng et al. On the security of an enhanced novel access control protocol for wireless sensor networks
US20220417015A1 (en) Key update method and related apparatus
CN101986726A (en) Method for protecting management frame based on wireless local area network authentication and privacy infrastructure (WAPI)
EP2720404A1 (en) Addressable radio device
CN103595529A (en) A switching method for a unidirectional secret key and a realization apparatus
KR20090012248A (en) Method and system for the manipulation-protected generation of a cryptographic key
US20150188703A1 (en) Key processing method and apparatus
US11019037B2 (en) Security improvements in a wireless data exchange protocol
CN103200563A (en) Subliminal channel hiding communication method based on authentication code
CN110572261A (en) data encryption transmission method
Resner et al. Key establishment and trustful communication for the internet of things
KR101517909B1 (en) Session Key Cross Certification Method
CN111093193B (en) MAC layer secure communication method suitable for Lora network
CN105516105B (en) The secure accessing purpose equipment method and system of hardware identifier variation
Fernàndez-Mir et al. Secure and scalable RFID authentication protocol
CN117714055B (en) In-vehicle network communication method based on identity information
Eya et al. New user authentication and key management scheme for secure data transmission in wireless mobile multicast
Sunkari Framework for providing security and energy saving using elliptic curve cryptography in wireless sensor networks
JP5080837B2 (en) Network system

Legal Events

Date Code Title Description
PCNP Patent ceased through non-payment of renewal fee

Effective date: 20191011