WO2019129346A1

WO2019129346A1 - Wireless authentication apparatus, system and method

Info

Publication number: WO2019129346A1
Application number: PCT/EP2017/084698
Authority: WO
Inventors: Jukka Pekka Reunamäki; Arto Tapio Palin
Original assignee: Nokia Technologies Oy
Priority date: 2017-12-28
Filing date: 2017-12-28
Publication date: 2019-07-04

Abstract

This disclosure relates to device authentication for connectionless communication. According to a first aspect, this disclosure describes apparatus configured: to cause transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticate the device in dependence on the authentication response.

Description

Wireless Authentication Apparatus, System and Method

Field

This disclosure relates to device authentication for connectionless communication.

Background

Modern society has adopted, and is becoming reliant upon, wireless communication devices for various purposes, such as, connecting users of the wireless communication devices with other users. Wireless communication devices can vary from battery powered handheld devices to stationary household and / or commercial devices utilizing a m ains electrical network as a power source. Due to rapid development of the wireless communication devices a number of areas capable of enabling entirely new types of communication applications have emerged. An example of a wireless short-range communication technology is Bluetooth™ communication protocol, which operates in the 2.4 GHz ISM band. Bluetooth™ is a short-range radio network, originally intended as a cable replacement. Bluetooth™ Technical Specifications are published by the Bluetooth™ SIG, Inc. The Bluetooth™ Core Specification, Version 4.2, Bluetooth™ SIG, December 2, 20 14 (incorporated herein by reference), describes the Bluetooth™ protocol (BT) and the Bluetooth™ Low Energy protocol (BLE). The Bluetooth™ Low Energy protocol was first introduced in the Bluetooth™ Core Specification, Version 4.0. The Bluetooth™ Core Specification, Version 5.0 , Bluetooth™ SIG, December 6, 20 16 (incorporated herein by reference) describes an evolution of Version 4.2.

Sum m ary

Various embodiments of the invention include a method, an apparatus and a computer program, which are characterized by what is stated in the independent claims. Various embodiments of the invention are disclosed in the dependent claims.

According to a first aspect, this specification describes apparatus configured: to cause transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticate the device in dependence on the authentication response. The address field of the first packet may further comprise a hash value based on the first random number and an identifier associated with the apparatus. The authentication response may be contained within the address field of the second packet.

The authentication response may comprise a hash value based on the first random number and the identifier of the device.

The address field of the second packet further may comprise a second random number.

The apparatus may be further configured to compare a function of the first random number to the second random number during authentication of the device, and to authenticate the device only the function of the first random number matches the second random number.

The apparatus may be further configured to: following authentication of the device, generate a third packet, the third packet comprising a further authentication response based on the second random number and an identifier associated with the apparatus; and cause transmission of the third packet to the device.

The third packet may comprise a payload field, and wherein the payload field comprises the further authentication response.

The first random number may be regenerated periodically.

The authentication response may be a hash value based on the first random number and the identifier of the device.

According to a second aspect, this specification describes apparatus configured: to receive, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number; to generate an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and to cause transmission of a second packet comprising the authentication response to the advertiser device. The address field of the first packet may further comprise a hash value based on the first random number and an identifier associated with the advertiser device. The apparatus may be configured to authenticate the advertiser device in dependence on the first random number and the hash value.

The authentication response may be contained within the address field of the second packet.

The address field of the second packet may further comprise a second random number.

The second random number m ay be generated based on the first random number. The first random number may be regenerated periodically.

The authentication response may be a hash value based on the first random number and the identifier of the apparatus. According to a third aspect, this specification describes a system comprising apparatus according to the first aspect, and apparatus according to the second aspect.

According to a fourth aspect, this specification describes a method comprising: causing transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticating the device in dependence on the authentication response. The authentication response may be contained within the address field of the second packet.

The address field of the second packet may further comprise a second random number. The method may further comprise comparing a function of the first random number to the second random number during authentication of the device, and to authenticate the device only the function of the first random number matches the second random number.

According to a fifth aspect, this specification describes a method comprising: receiving, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number; generating an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and causing transmission of a second packet comprising the authentication response to the advertiser device.

The address field of the first packet may further comprise a hash value based on the first random number and an identifier associated with the advertiser device.

The method may further comprise authenticating the advertiser device in dependence on the first random number and the hash value.

The authentication response may be contained within the address field of the second packet. According to a sixth aspect, this specification describes apparatus comprising one or more processors and a memory, the memory comprising instructions that, when executed by the one or more processors, cause the apparatus to perform : causing transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticating the device in dependence on the authentication response.

According to a seventh aspect, this specification describes apparatus comprising one or more processors and a memory, the memory comprising instructions that, when executed by the one or more processors, cause the apparatus to perform : receiving, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number; generating an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and causing transmission of a second packet comprising the authentication response to the advertiser device. According to an eighth aspect, this specification describes a non-transitory computer readable medium having computer readable code stored thereon, the computer readable code, when executed by at least one processor, causing performance of:

causing transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticating the device in dependence on the authentication response.

According to a ninth aspect, this specification describes a non-transitory computer readable medium having computer readable code stored thereon, the computer readable code, when executed by at least one processor, causing performance of:

receiving, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number; generating an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and causing transmission of a second packet comprising the authentication response to the advertiser device. Brief description o f the figures

For a more complete understanding of the methods, apparatuses and computer- readable instructions described herein, reference is now made to the following drawings in which: Figure lA is an illustration of a network with an example wireless advertiser device 102 and a wireless scanner device 100 ;

Figure IB is an illustration of further operations performed by the network of Figure 1A;

Figures 2a to 2c show schematic examples of methods of authenticating a scanner and / or an advertiser in a wireless network;

Figures 3a to 3c show schematic examples of further methods of authenticating a scanner 100 in a wireless network;

Figures 4a and 4b show examples of packet address formats containing a random part; Figure 5 is an illustration of an example flow diagram of an example process in the wireless advertiser device, carrying out the example operations, in accordance with at least one embodiment of the present invention; and Figure 6 is an illustration of an example flow diagram of an example process in the wireless scanner device, carrying out the example operations, in accordance with at least one embodiment of the present invention . D e tailed de s criptio n

This section is organized into the following topics:

A. Overview

B. Wireless Short-Range Communication Networks

C. Bluetooth™ Low Energy (BLE) Technology

D. Creating an Authenticated Relationship Between Wireless Devices

A. Overvie w

This disclosure describes apparatus, methods and systems for providing connectionless authentication in a wireless network. The authentication method comprises using address fields that comprise a random number in packets exchanged across the wireless network, thereby hiding the addresses of the devices being authenticated.

Authentication is based on responses that use the random part of the address of the device m aking authentication and adding a calculated component to the response packet that is based on that random part.

By hiding the address of the scanning and / or advertiser devices in packets transmitted across a wireless network during scanning and / or advertising, security can be improved. For example, a malicious third party will be unable to discern permanent addresses of the scanning and / or advertiser devices, and will hence be unable to imitate those devices in the network.

B . Wirele s s Sho rt-Ran ge Co m m un icatio n Ne tw o rks

Short-range communication technologies provide communication solutions appropriate for many data applications, without the cost, traffic and legislative concerns of longer-range communication technologies. Popular short-range communication technologies include Bluetooth basic rate/ enhanced data rate

(BR/ EDR), Bluetooth Low Energy (BLE), IEEE 802.11 wireless local area network (WLAN), IEEE 802.15.4, and near field communication technologies, such as radio frequency identification (RFID) and near field communication (NFC) technology that enable contactless identification and interconnection of wireless devices. Bluetooth Technology provides an example of wireless short-range communication establishment.

C. Bluetooth™Low Energy (BLE) Technolo gy

The Bluetooth™ Core Specifications, Versions 4.0 , 4, 1, 4.2 and 5.0 include the

Bluetooth LE protocol for products that require lower power consumption, lower complexity, and lower cost than would be possible using the BR/ EDR protocol.

Bluetooth LE is designed for applications requiring lower data rates and shorter duty cycles, with a very-low power idle mode, a simple device discovery, and short data packets. Bluetooth LE devices may employ a star topology, where one device serves as a m aster for a plurality of slave devices, the master dictating connection timing by establishing the start time of the first connection event and the slave devices transmitting packets only to the master upon receiving a packet from the master.

According to Bluetooth LE communication protocol all connections are point-to-point connections between two devices (the master and the slave). The following description refers in places to the Bluetooth™ Core Specification, Versions 4.2, but equivalent corresponding passages can be found in at least one of the Bluetooth™ Core

Specifications, Versions 4.0 , 4.1 and / or 5.0. The Bluetooth LE protocol allows a star network topology in connections, where one device serves as a master for a plurality of slave devices. The master device dictates the connection timing and communication operations of the one or more slave devices. Bluetooth LE communicates over a total of 40 RF channels, separated by 2 MHz. Data communication between Bluetooth LE devices occurs in 37 pre-specified data channels, of the 40 RF channels. All data connection transmissions occur in connection events wherein a point-to-point connection is established between the master device and a slave device. In the Bluetooth LE protocol, a slave device provides data through Bluetooth LE communication to the master device to which it is connected. The remaining 3 channels, of the 40 RF channels, are advertising channels used by devices to advertise their existence and capabilities. The Bluetooth LE protocol defines a unidirectional connectionless broadcast mode on the advertising channels.

The Link Layer provides a state machine with the following five states: Standby State, Advertising State, Scanning State, Initiating State, and Connection State. The Link Layer state machine allows only one state to be active at a time. The Link Layer in the Standby State does not transmit or receive any packets and can be entered from any other state. The Link Layer in the Advertising State will be transmitting advertising channel packets and possibly listening to and responding to responses triggered by these advertising channel packets. A device in the Advertising State is known as an advertiser. The Advertising State can be entered from the Standby State. The Link Layer in the Scanning State will be listening for advertising channel packets from devices that are advertising. A device in the Scanning State is known as a scanner. The Scanning State can be entered from the Standby State. The Link Layer in the Initiating State will be listening for advertising channel packets from a specific device and responding to these packets to initiate a connection with that specific device. A device in the Initiating State is known as an initiator. The Initiating State can be entered from the Standby State. The Connection State of the Link Layer may be entered either from the Initiating State or the Advertising State. A device in the Connection State is known as being in a connection over a data channel. Within the Connection State, two roles are defined: the Master Role and the Slave Role. When a device in the Initiating State, enters the Connection State, it is in the Master Role, it exchanges data packets with a slave device in a data channel, and it defines the timings of transmissions. When a device in the Advertising State, enters the Connection State, it is in the Slave Role and exchanges data packets with a m aster device in a data channel, wherein the master device defines the timings of transmissions.

The Bluetooth LE radio operates in the unlicensed 2.4 GHz ISM band, in the same m anner as does the Bluetooth Basic Rate / Enhanced Data Rate (BR/ EDR) radio. Bluetooth LE supports very short data packets, from 10 octets to a maximum of 265 octets, giving it a low duty cycle. Bluetooth LE employs a frequency hopping transceiver with many frequency hopping spread spectrum (FHSS) carriers, with a bit rate of 1 Megabit per second (Mb/ s).

Bluetooth LE employs two multiple access schemes: Frequency division multiple access (FDMA) and time division multiple access (TDMA). Forty (40 ) physical channels, separated by 2 MHz, are used in the FDMA scheme. Three (3) are used as advertising channels and 37 are used as data channels . A TDMA based polling scheme is used in which one device transmits a packet at a predetermined time and a corresponding device responds with a packet after a predetermined interval. The physical channel is sub-divided into time units known as events. Data is transmitted between Bluetooth LE devices in packets that are positioned in these events. There are two types of events: Advertising and Connection events.

Devices that transmit advertising packets on the advertising Physical Layer (PHY) channels are referred to as advertisers. Devices that receive advertising on the advertising channels without the intention to connect to the advertiser device are referred to as scanners. Devices that form a connection to another device by listening for connectable advertising packets, are referred to as initiators. Transmissions on the advertising PHY channels occur in advertising events.

In Bluetooth™ Core Specifications there are four advertising event types: connectable undirected advertising (ADV_IND), connectable directed advertising

(ADV_DIRECT_IND), scannable undirected advertising (ADV_ SCAN_IND), and non- connectable undirected advertising (ADV_NONCONN_IND). At the start of each advertising event, the advertiser sends an advertising packet corresponding to the advertising event type. The header of the advertising channel packet identifies the packet type in a four-bit PDU Type field encoding. There are seven values currently assigned to the four-bit PDU Type field, ranging from 0000 to 0 110 , with the values 0 111 to 1111 being reserved for future use.

In Bluetooth™ Core Specifications, the initiator device receives the advertising packet, m ay m ake a connect request (CONNECT_REQ) to the advertiser device on the same advertising PHY channel. The CONNECT_REQ request includes fields for access address AA, CRC, WinSize, Win Offset, Interval, Latency, Timeout, ChannelMap, Hop count, and sleep clock accuracy SCA. The four-bit PDU Type field in the header of the CONNECT_REQ advertising channel packet, is 0 10 1. When the advertiser device accepts the CONNECT_REQ request, a point-to-point connection results between the initiator device that becomes the master device, and the advertiser device that becomes the slave device in a piconet. The m aster and the slave devices know at what time and in which frequency the connection is in operation . The data channel changes between every connection event and the start of connection events are spaced regularly with the connection interval that is provided in the CONNECT_REQ packet.

In the connectable undirected advertising (ADV_IND) channel packet, the ADV_IND PDU has a payload field containing AdvA and AdvData fields. The AdvA field contains the advertiser’s public or random device address and the AdvData field may contain Advertising data from the advertiser’s host. The PDU may be used in connectable undirected advertising events. The four-bit PDU Type field in the header of the ADV_IND advertising channel packet, is 0000. In the connectable directed advertising (ADV_DIRECT_IND) channel packet, the ADV_DIRECT_IND PDU has the payload field containing AdvA and InitA fields. The AdvA field contains the advertiser’s public or random device address. The InitA field is the address of the device to which this PDU is addressed. The InitA field may contain the initiator’s public or random device address. The PDU may be used in connectable directed advertising events. This packet may not contain any host data. The four-bit PDU Type field in the header of the ADV_DIRECT_IND advertising channel packet, is 0001

In a non-connectable undirected event type advertising channel packet,

ADV_NONCONN_IND, a scanner device is allowed to receive information in the advertising channel packet, but scanner devices are not allowed to transmit anything in the advertising channels upon receiving the ADV_NONCONN_IND advertising channel packets. When the non-connectable undirected event type is used, non- connectable advertising indications ADV_ NONCONN_IND packets are sent by the Link Layer. The non-connectable undirected event type allows a scanner to receive information contained in the ADV_NONCONN_IND from the advertiser. The advertiser may either move to the next used advertising channel index or close the advertising event after each ADV_NONCONN_IND that is sent. The four-bit PDU Type field in the header of the ADV_NONCONN_IND advertising channel packet, is 00 10.

In the scannable undirected advertising (ADV_ SCAN_IND) channel packet, the ADV_ SCAN_IND PDU has the payload field containing AdvA and AdvData fields. The AdvA field contains the advertiser’s public or random device address. The PDU may be used in scannable undirected advertising events. The AdvData field may contain Advertising Data from the advertiser’s host. The four-bit PDU Type field in the header of the ADV_ SCAN_IND advertising channel packet, is 0 110.

In Bluetooth™ Core Specifications, if the advertiser is using a connectable advertising event, an initiator m ay make a connection request using the same advertising PHY channel on which it received the connectable advertising packet. The advertising event is ended and connection events begin if the advertiser receives and accepts the request for a connection to be initiated. Once a connection is established, the initiator becomes the master device in a piconet and the advertiser device becomes the slave device. Within a connection event, the master and slave alternate sending data packets using the same data PHY channel.

According to Bluetooth™ Specifications, Bluetooth LE device discovery involves different operational processes for devices with different roles. In particular:

• Advertiser device performs an advertising process during which the device repeatedly enters Advertising Events. The interval of each start of Advertising Event,

Ta, composes of a fixed-length“advlnterval” and a random-length“advDelay”. In Advertising Event, the device sends advertising Packet Data Units (PDUs) in broadcasting channel 37, 38 and 39, respectively.

• Scanner device performs the scanning process. A scanning process consists of repeated“scanlnterval”, each of which contains a“scanWindow”. In a different

“scanWindow”, the device changes the RF module to receive the state and listens to advertising PDUs on different broadcasting channels; while out of the“scanWindow”, it does routine scheduling, or turns off the RF module. If any advertising PDU is received by an initiator / scanner, it means the initiator / scanner successfully discovers the advertiser device. For the initiator, it can directly send back a“CONNECT_REQ” to establish a connection with that advertiser. For a scanner, it can send out a“SCAN_REQ” to ask for more information from that advertiser.

The CONNECT_REQ PDU has a payload field that consists of InitA, AdvA and LLData fields. The InitA field contains the Initiator’s public or random device address, as indicated by a transmit address flag. The AdvA field contains the advertiser’s public or random device address, as indicated by a receive address flag. The LLData consists of 10 fields, such as the Link Layer connection’s Access Address, a channel map, a hop count increment, and other parameters needed to set up the connection .

The SCAN_REQ PDU has a payload field that consists of Scan A and AdvA fields. The ScanA field contains the scanner’s public or random device address, as indicated by a transmit address flag. The AdvA field is the address of the device to which this PDU is addressed and contains the advertiser’s public or random device address, as indicated by a receive address flag.

Example non-limited use cases for Bluetooth LE technology include sports and fitness, security and proximity and sm art energy. Bluetooth LE technology is designed for devices to have a battery life of up to one year such as those powered by coin-cell batteries. These types of devices include watches that will utilize Bluetooth LE technology to display Caller ID information and sports sensors that will be utilized to monitor the wearer's heart rate during exercise. The Medical Devices Working Group of the Bluetooth SIG is also creating a medical devices profile and associated protocols to enable Bluetooth applications for Bluetooth LE devices.

A Bluetooth LE advertising channel may be shared by any number of Bluetooth LE devices. Any number of Bluetooth LE devices may transmit advertising packets while sharing the same three advertising PHY channels. In high-density environments, however, since there are a large number of nodes to be discovered, the probability of broadcasting conflict will inevitably increase, causing network access time to increase, and also lowering the energy efficiency of the whole network. 1. _ B lue to o th™LE dis co ve ry:

At the start of each advertising event, the advertiser sends an advertising packet corresponding to the advertising event type. Depending on the type of advertising packet, the scanner may make a request to the advertiser on the same advertising PHY channel, which may be followed by a response from the advertiser on the same advertising PHY channel. The advertising PHY channel changes on the next advertising packet sent by the advertiser in the same advertising event. The advertiser m ay end the advertising event at any time during the event. The first advertising PHY channel is used at the start of the next advertising event. Initiator devices that are trying to form a connection to another device listen for connectable advertising packets. If the advertiser is using a connectable advertising event, an initiator m ay make a connection request using the same advertising PHY channel on which it received the connectable advertising packet. The advertising event is ended and connection events begin if the advertiser receives and accepts the request for a connection is initiated. Once a connection is established, the initiator becomes the m aster device in a piconet and the advertiser device becomes the slave device.

Connection events are used to send data packets between the m aster and slave devices. Devices are identified using a device address. Device addresses may be either a public device address or a random device address. A public device address and a random device address are both 48 bits in length. A device shall contain at least one type of device address and may contain both.

The public device address shall be created in accordance with section 9.2 ("48 - bit universal LAN MAC addresses") of the IEEE 802-200 1 standard (http:/ / standards. ieee.org/ getieee802/ download/ 802-200 l.pdf) and using a valid Organizationally Unique Identifier (OUI) obtained from the IEEE Registration Authority

(http :/ / standards.ieee.org/ regauth/ oui/ forms/ and sections 9 and 9.1 of the IEEE 802- 200 1 specification) . The public device address is divided into the following two fields:

• company_assigned field is contained in the 24 least significant bits

• company_id field is contained in the 24 most significant bits.

For the purposes of this profile, the random device address may be of either of the following two sub-types:

• Static address

• Private address

The private address may be of either of the following two sub-types:

· Non-resolvable private address

• Resolvable private address

Static and non-resolvable private address both contains address that is random . The m ain difference is that the device shall not change its static address value once initialized until the device is power cycled.

The random resolvable private device address is divided into the following two fields which can be used to identify the device:

• hash field is contained in the 24 least significant bits, as defined, for example, in Bluetooth™ Core Specification, Version 4.2 [Vol. 3] Part C, Section 10.8.2.3. • random field is contained in the 24 most significant bits, as defined, for example, in Bluetooth™ Core Specification, Version 4.2 [Vol. 3] Part C, Section 10 8 2 2 2. Bluetoo th™LE Link Laver Security

a. Authorization

In a Bluetooth LE (BLE) connection authorization, a user of a Bluetooth device may grant a specific (remote) Bluetooth device access to a specific service. Authorization implies that the identity of the remote device can be verified through authentication. It is the act of granting a specific Bluetooth device access to a specific service. It may be based upon user confirmation, or given the existence of a trusted relationship . A service may require authorization before allowing access. Authorization is a confirmation by the user to continue with the procedure. Authentication does not necessarily provide authorization . Authorization may be granted by user confirmation after successful authentication. Authentication and authorization may be defined by a higher layer specification or be implementation specific. b. Authenticatio n and Encryption

Authentication is a generic procedure based on LMP-authentication if a link key exists or on LMP-pairing if no link key exists. LMP-authentication is an LMP level procedure for verifying the identity of a remote device. The procedure is based on a challenge- response mechanism using a random number, a secret key and the BD_ADDR of the non-initiating device. The secret key used can be a previously exchanged link key.

The Link Layer provides encryption and authentication using Counter with Cipher Block Chaining-Message Authentication Code (CCM) Mode, which shall be

implemented consistent with the algorithm as defined in IETL RLC 3610 in conjunction with the AES- 128 block cipher as defined in NIST Publication FIPS- 197. The Link Layer connection may be either encrypted and authenticated or unencrypted and unauthenticated. In an encrypted and authenticated connection, all the Data Channel PDUs with a non-zero length Payload shall be encrypted and authenticated.

Authentication is performed by appending a Message Integrity Check (MIC) field to the Payload. c. _ Pairin g and Bonding

LMP-pairing is a procedure that authenticates two devices, based on a PIN, and subsequently creates a common link key that can be used as a basis for a trusted relationship or a (single) secure connection . The procedure consists of the steps:

creation of an initialization key (based on a random number and a PIN), creation and exchange of a common link key and LMP-authentication based on the common link key.

Bonding is a dedicated procedure for performing the first authentication, where a common link key is created and stored for future use. Trusting is the marking of a paired device as trusted. Trust marking can be done by the user, or automatically by the device (e.g. when in bondable mode) after a successful pairing.

Pairing and key distribution over a BLE physical link is defined by the Security Manager specification (Bluetooth™ Core Specification, Version 4.2 [Vol. 3] , Part H Section 2.3). The pairing process may be initiated if either slave or master device request pairing to enable link encryption and possible authentication.

The purpose of bonding is to create a relation between two Bluetooth devices based on a stored security and identity information . A transport specific key distribution is performed during pairing process to share the keys which can be used to encrypt a link in future reconnections, verify signed data and random address resolution .

LE security uses the following keys and values for encryption, signing, and random addressing:

1. Identity Resolving Key (IRK) is a 128 -bit key used to generate and resolve random addresses.

2. Connection Signature Resolving Key (CSRK) is a 128 -bit key used to sign data and verify signatures on the receiving device.

3. Long Term Key (LTK) is a 128 -bit key used to generate the contributory session key for an encrypted connection. Link Layer encryption is described, for example, in Bluetooth™ Core Specification, Version 4.2 [Vol 6] Part B, Section 5.1.3.

4. Encrypted Diversifier (EDIV) is a 16-bit stored value used to identify the LTK. A new EDIV is generated each time a unique LTK is distributed.

5. Random Number (Rand) is a 64-bit stored valued used to identify the LTK. A new Rand is generated each time a unique LTK is distributed.

In order for devices using the privacy feature to reconnect to known devices, the device addresses used when the privacy feature is enabled, private address, must be resolvable to the other devices’ identity. The private address is generated using the device’s identity key exchanged during the bonding procedure.

The Identity Resolving Key (IRK) is used for resolvable private address construction (see, for example, [Part C] , Generic Access Profile, Section 10.8.2 of the Bluetooth™ Core Specification, Version 4.2). A m aster that has received IRK from a slave can resolve that slave’s random resolvable private device addresses. A slave that has received IRK from a master can resolve that master’s random resolvable private device addresses. The privacy concept only protects against devices that are not part of the set to which the IRK has been given.

While a device is in the Peripheral or the Central role the device may support the Bonding procedure. While a device is in the Broadcaster or the Observer role the device shall not support the bonding procedure. The Host of the Central initiates the pairing process, for example as defined in Bluetooth™ Core Specification, Version 4.2 [Vol. 3] , Part C Section 2.1 with the Bonding_Flags set to Bonding as defined in [Vol. 3] , Part H Section 3.5.1. If the peer device is in the bondable mode, the devices shall exchange and store the bonding information in the security database. If a device has privacy enabled (as defined, for example, in Bluetooth™ Core

Specification, Version 4.2, Table 10.7), the Host should send it’s IRK to the peer device and request the IRK of the peer device during the pairing procedure. The Host can abort the pairing procedure if the authentication requirements are not sufficient to distribute the IRK. If the pairing procedure fails due to authentication requirements and IRK distribution was requested, the pairing procedure should be retried without requesting IRK distribution. _. _ Blue to o th LE Tim in g in the Advertis in g. Scan nin g, an d In itiato r

State s :

a. Blue to o th LE Advertis in g State :

For all undirected advertising events or connectable directed advertising events used in a low duty cycle mode, the time between the start of two consecutive advertising events (T_ advEvent) is computed as follows for each advertising event:

T_advEven t = advlnterval + advDelay The advlnterval shall be an integer multiple of 0.625 ms in the range of 20 m s to 10.24 s. If the advertising event type is either a scannable undirected event type or a non- connectable undirected event type, the advlnterval shall not be less than 100 ms. If the advertising event type is a connectable undirected event type or connectable directed event type used in a low duty cycle mode, the advlnterval can be 20 ms or greater. The advDelay is a pseudo-random value with a range of 0 ms to 10 ms generated by the Link Layer for each advertising event. Bluetooth™ Core Specification, Version 4.2, Figure 4.1 shows an example timing diagram of advertising events perturbed in time using advDelay. b. Bluetoo th LE Scanning State :

If the advertiser receives a SCAN_REQ PDU that contains its device address from a scanner allowed by the advertising filter policy, it shall reply with a SCAN_RSP PDU on the same advertising channel index. After the SCAN_RSP PDU is sent, or if the advertising filter policy prohibited processing the SCAN_REQ PDU, the advertiser shall either move to the next used advertising channel index to send another ADV_IND PDU, or close the advertising event. Bluetooth™ Core Specification, Version 4.2,

Figure 4.3 shows an example timing diagram of a connectable undirected advertising event with SCAN_REQ and SCAN_RESP PDUs in the middle of an advertising event. c. _ Bluetoo th LE Initiato r State and Co nnection Setup :

If an initiator sends the advertiser receives a CONNECT_REQ PDU that contains the advertiser’s device address, and the initiator is allowed by the advertising filter policy, the Link Layer of the advertiser shall exit the Advertising State and transition to the Connection State in the Slave Role. If the advertising filter policy prohibited processing the received CONNECT_REQ PDU, the advertiser shall either move to the next used advertising channel index to send another ADV_IND PDU, or close the advertising event. Bluetooth™ Core Specification, Version 4.2, Figures 4.13 and 4.14 show example timing diagrams of a Connection setup

4. Challen ge-Respo nse Authentication

In challenge-response authentication, one party sends a question or challenge and the other party must provide a valid answer or response to be authenticated. The simplest example of a challenge-response protocol is password authentication, where the challenge is asking for the password and the valid response is the correct password. Authentication protocols often employ a nonce as the challenge to maintain the uniqueness of every challenge-response sequence, which protects against a replay attack. An example nonce may be generated as a pseudorandom number. The value of the nonce is frequently updated and its use may not be repeated. An authentication test value or message authentication code may be generated by cryptographically combining the nonce with a shared secret value or key. For example, the nonce may be exclusive-ORed with the shared secret value to generate an authentication test value. An authentication test value or message authentication code may also be generated with a cryptographic hash function operating on the nonce. The cryptographic hash function converts the digital string of the nonce into a fixed-length hash value, which is the authentication test value. A cryptographic hash function, such as MD5 or SHA- 1, may be used in the calculation of an authentication test value. An authentication test value or message authentication code m ay also be generated with a block cipher algorithm operating on the nonce. The block cipher converts fixed-length groups of bits, called blocks or plaintext, to ciphertext which can be transformed back into the original plaintext using the same encryption key. The nonce can be used as an initialization vector or plaintext for block cipher algorithm . Block ciphers, such as AES- 128 , AES- 192 and AES-256, may be used in the calculation of an authentication test value.

To authenticate another party, the sender m ay generate a nonce and cryptographically combine it with a shared secret key to produce an authentication test value, which the sender stores. The sender may then send the generated nonce to the other party. The other party then cryptographically combines the received nonce in the same way and with the shared secret key to produce a second copy of the authentication test value, which the other party returns to the original sender. The original sender then compares the received second copy of the authentication test value with the original sender’s stored value. If the values compare, then the other party is authenticated. D . Creatin g an Au the nticated Re latio n s h ip B e tw e en Wire les s De vices

Bluetooth™ Low Energy technology as described above provides one example of a method for connectionless advertising process for delivering the data from the advertiser to the scanner. The scanner m ay also request more inform ation from the advertiser by sending SCAN_REQ packet as described above. However, if the scanner is authenticated based on the SCAN_REQ, this can result in security concerns. For example, a malicious third party could build a system which stores the address of the scanner, and could then act as scanner in different locations using the scanner address.

For example, one use case is a personal safety device used to locate a person during an emergency. One can use a Bluetooth™ Low Energy home beacon for positioning of the device, for example to find out when a device is at a home location. In some examples, in order to save power in the personal safety device, the device is advertising and the “beacon” is not beaconing but scanning and the scan responses are used to detect the presence of the“beacon” to know when the device is at home. However, even if devices have been bonded, i.e. they have shared an identity resolving key, the beacon can be mimicked by using the beacon address at a false beacon. The address of the real beacon can be determined after only being heard once. As a personal safety device should always know its location in order to be effective, it is especially vulnerable to this type of “cheating”.

In accordance with various embodiments, devices use an enhanced authentication method. A random address is used when sending a packet. The random address comprises at least one random part. In some examples, the random part can be the whole of the address. In other examples, the random address can from a part of the full address, such as being a prand (i.e. a pseudo random number). When a peer device to be authenticated receives the random address, it formulates a response which is at least in part based on the random part of the address.

Figure lA is an illustration of a network with an example wireless advertiser device 102 and a wireless scanner device 100. The wireless scanner device 100 is shown scanning for wireless advertising messages (herein also referred to as a first packet) 150 , for example Bluetooth™ Low Energy advertisements.

The advertiser device 102 is shown generating a random address, at 136, to be used by the advertiser device 102 to authenticate other devices. The random address may be generated by the advertiser device, as a random or a pseudorandom number (prand). The random part of the random address can be referred to as a first random number. The random address comprises at least one random part comprising the first random number. The random address may be regenerated periodically. The random address does not include any hardware identifier or other identifier that is permanently associated with the advertiser device 102. The random address is used in challenge- response authentication as a challenge and the other party must provide a valid answer for response to be authenticated.

The advertiser device 102 is shown broadcasting wireless advertising messages in the form of a first packet 150 over any of the available channels used by devices to advertise their existence and capabilities. The wireless advertiser device 102 is in the process of authenticating the wireless scanner device 100 by transmitting a first packet 150 including a random address for authenticating wireless devices responding to the first packet 150 , in accordance with at least one embodiment of the present disclosure.

The scanner device 100 is shown receiving the advertising messages 150 , extracting the random address, and computing an authentication response based on the first random number in the random address. The authentication response may be generated by cryptographically combining the random part of the random address with a shared secret value or key 130. For example, the first random number may be exclusive-ORed with the shared secret key 130 to generate an authentication response. An

authentication response may also be generated with a cryptographic hash function operating on the first random number and the shared secret value. The cryptographic hash function converts the digital string of the first random number and the shared secret key into a fixed-length hash value or digest, which is the authentication response. A cryptographic hash function, such as MD5 or SHA- 1, may be used in the calculation of the authentication response. An authentication response (also referred to as a message authentication code and / or authentication test value) may also be generated with a block cipher algorithm operating on the first random number. The block cipher converts fixed-length groups of bits, called blocks or plaintext, to ciphertext which can be transformed back into the original plaintext using the same encryption key. The random part of the random address can be used as an initialization vector or plaintext for block cipher algorithm . Block ciphers, such as AES- 128 , AES- 192 and AES-256, may be used in the calculation of an authentication response. For example, the scanner computes, at 138 , the authentication test value, which is a hash digest expressed as

HASH [FIRST RANDOM NUMBER & SECRET KEY] , where the first random number and secret key value may be concatenated and used as the argument in the

cryptographic hash function. In example embodiments of the invention, the scanner device 100 and the advertiser device 102 m ay include a processor 122 that includes from one to many central processing units (CPUs) 124 and / or 125, a random access memory (RAM) / a read only memory (ROM) 126, and interface circuits to interface with one or more radio transceivers 116, antenna 132, 134, and battery or house power sources. The scanner device 100 and / or advertiser device may further include a keypad, display, etc. The RAM and ROM can be removable memory devices such as sm art cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, flash memory devices, etc. In an example embodiment of the invention, the RAM 126 or buffer 138 in the scanner device 100 may store the default service information contained in received advertising messages 150 , for example, a description of the capabilities of the sending device 102 in received advertising messages 150.

The RAM and / or ROM 126 may comprise a software application 110 which, when executed by the central processing units 125 and / or 125, causes the scanner 100 and / or the advertiser 102 to perform one or more of the operations described herein .

In some example embodiments, the scanner device 100 and the advertiser device 102 include the Bluetooth™ Low Energy protocol (BLE) 114. In some example

embodiments, the scanner device 100 and the advertiser device 102 include a 5G protocol.

In an example embodiment of the invention, the scanner device 100 and / or the advertiser device 102 may be, for example, a miniature device such as a key fob, smart card, jewellery, or the like. In an example embodiment of the invention, the scanner device 100 and / or the advertiser device 102 m ay be, for example, a relatively larger cell phone, smart phone, flip-phone, PDA, graphic pad. The scanner device 100 and / or the advertiser device 102 may also be in an automobile or other vehicle. In embodiments, the relative sizes of devices 100 and 102 may be arbitrary.

Figure IB is an illustration of further operations performed by the network of Figure 1A. The wireless scanner device 100 computes an authentication response that is based on output of the security function utilizing at least a combination of the first random number and a secret value shared by the wireless advertiser device 102 and the wireless scanner device 100. The example of the authentication response can be output of the hash function or the block cipher algorithm . The scanner device 100 sends a second packet 152 to the advertiser device 102, including the authentication response based on the first random number and the shared secret key, for example HASH [FIRST RANDOM NUMBER & SECRET KEY] . The authentication response can be transmitted as part of the address field of the second packet 152. In some embodiments, the random part of the random address is also included in the address field of the second packet 152. In some embodiments, a second random number is alternatively or additionally included in the address field of the second packet 152. The address field of the second packet 152 does include any hardware address or other permanent address of the scanner device 100.

In parallel, the advertiser device 102 computes another copy of HASH [FIRST

RANDOM NUMBER & SECRET KEY] , using its own stored values of the first random number and the shared secret key. The advertiser device 102 then compares the computed authentication test value with the received authentication response from the scanner device 100. The advertiser device 102 can then authenticate the wireless scanner device 100 , if the computed authentication test value compares with the received authentication response, in accordance with at least one embodiment of the present invention . Figures 2A to 2C show schematic examples of methods of authenticating a scanner device 100 and / or an advertiser device 102 in a wireless network. In these

embodiments, the scanner device 100 authenticates itself by using the address field 156 of the second packet 152. In Figure 2A, the advertiser device 102 generates a first packet 150 comprising an address field 154. The address field 154 comprises a first random number generated by the advertiser device 102. In the example shown, the address field comprises a first random number in the form of a prand and a first hash value, and is therefore a resolvable address. The first hash value can, for example, be determined in dependence on the first random number and an identifier of the advertiser device 102 shared by the advertiser device 102 and the scanner device 100. An example of such an identifier is a shared secret key. However, in other examples the address field may comprise an unresolvable address, for example a wholly random number. The first packet 150 further comprises a first packet payload 156. In some

embodiments, such as the one shown, the first packet payload 156 is an advertisement payload. The advertiser device 102 transmits the first packet to the scanner device 100. The scanner device 100 receives the first packet 150.

In Figure 2B, the scanner device 100 determines the first random number in the address field 154 of the first packet 150. The scanner device 100 generates a second packet 152 to respond to the first packet 150. The second packet 152 comprises an authentication response based on the first random number and an identifier of the scanner device 100 shared by the scanner device 100 and the advertiser device 102. The authentication response can form part of the address 158 of the second packet 152. In some embodiments, such as the example shown, the address 158 of the second packet 152 comprises the authentication response in the form of a second hash value (hash X) and the first random number. The second packet 152 further comprises a second packet payload 160 , such as a scan request. In some embodiments, the authentication response is included in the second packet payload 160. In some embodiments, the first random number is obfuscated in the address 158 of the second packet 152 by the scanner device 100. The obfuscation can, for example, be achieved by calculating a function of the first random number and using the result in the address 158 of the second packet 152 in place of the first random number. The function can, for example, be a data whitening function. The obfuscation technique used by the scanner device 100 is known to the advertiser device 102.

The scanner device 100 is configured to transmit the second packet 152 to the advertiser device 102. The advertiser device 102 receives the second packet 152. In some embodiments, the scanner device 100 can authenticate the advertiser device 102 based on the first hash value and first random number included in the address 154 of the first packet 150. An identity resolving key can be used to authenticate the advertiser device 102. The advertiser device 102 can, for example, be authenticated by hashing the first random number with identifiers of known advertiser devices to generate authentication test values. The authentication test values can be compared to the first hash to determine if it matches in order to authenticate the advertiser device 102

In Fig. 2C, the advertiser device 102 extracts the random part of the address 158 from the second packet 152. This is compared with a function of the first random number. In embodiments where the second packet address 158 comprises the first random number in an unaltered form, the function is the identity function, i.e. the extracted part of the second packet address 158 is compared to the first random number without any function being applied. In other embodiments, the function used to generate obfuscation of the random part of the address by the scanner device 100 is applied to the first random number by the advertiser device 100. The result of applying the function to the first random number is then compared to the extracted part of the address 158. If the comparison (of either type) results in a match, then the advertiser device 102 proceeds with the authentication process.

Authentication of the scanner device 100 by the advertiser device 102 is achieved by comparing the second packet address to known identity resolving keys. The identity resolving keys can, for example, comprise the identifiers of known scanner devices 100 hashed with the first random number. If an identity resolving key in the advertiser device 102 matches the authentication response, for example the second hash value, the scanner device 100 is determined by the advertiser device 102 as authenticated. If the identity resolving key in the advertiser device 102 does not match the authentication response, the scanner device 100 is determined by the advertiser device 102 as not authenticated .

In some embodiments, in response to authentication of the scanner device 100 , the advertiser device 102 transmits a third packet 158 to the scanner device 100. The third packet, in some embodiments, comprises the same address field 154 as the first packet 150. The third packet m ay further comprise a payload 162, such as a scan response. The content of the scan response 162 may depend on authentication of the scanner device.

Figures 3 A to 3C show schematic examples of further methods of authenticating a scanner device 100 in a wireless network. In these embodiments, the advertiser device 102 authenticates itself based on the random part of the second packet 152. In Figure 3A, the advertiser device 102 generates a first packet 150 comprising an address field 154. The address field 154 comprises a first random number generated by the advertiser device 102. In the example shown, the address field comprises a first random number in the form of a prand and a first hash value, and is therefore a resolvable address. The first hash value can, for example, be determined in dependence on the first random number and an identifier of the advertiser device 102 shared by the advertiser device 102 and the scanner device 100. An example of such an identifier is a shared secret key. However, in other examples the address field may comprise an unresolvable address, for example a wholly random number.

The first packet 150 further comprises a first packet payload 156. In this example, the first packet payload 156 is an advertisement payload.

The advertiser device 102 transmits the first packet to the scanner device 100. The scanner device 100 receives the first packet 150.

In Figure 3B, the scanner device 100 generates a second packet 152 to respond to the first packet 150. The second packet 152 comprises an address field 158.. In the examples such as the one shown, the address field 158 of the second packet 152 comprises an identifier in the form of a second hash value (Hash X) and a second random number (prand X). The second hash value m ay comprise a hash of the second random number with an identifier of the scanner device 100. The second packet 152 further comprises a second packet payload 160 , such as a scan request. The scanner device 100 is configured to transmit the second packet 152 to the advertiser device 102. The advertising device 102 receives the second packet 152.

In Fig. 3C, the advertising device 102 extracts the second random number from the address 156 of the second packet 152. The second random number is used by the advertiser device 102 to generate a further authentication response. The further authentication response can, for example, be generated by hashing an identifier of the advertiser device 102 with the second random number. Other cryptographic functions can alternatively be used instead of or in addition to a hash function . Authentication of the scanner device 100 by the advertiser device 102 is achieved by comparing the second packet address to known identity resolving keys. The identity resolving keys can, for example, comprise the identifiers of known scanner devices 100 hashed with the first random number. If an identity resolving key in the advertiser device 102 matches the authentication response, for example the second hash value, the scanner device 100 is determined by the advertiser device 102 as authenticated. If the identity resolving key in the advertiser device 102 does not match the authentication response, the scanner device 100 is determined by the advertiser device 102 as not authenticated

If the scanner device 100 is authenticated by the advertiser device 102, the advertiser device 102 generates content for a third packet 158. The third packet comprises an address 154 that, in some embodiments, matches the address of the first packet 150.

The third packet also comprises a payload field 162. Included in the payload field 162 is the further authentication response (Hash Y) generated by the advertiser device 102. The further authentication response can, for example, be included into a standardised part of the payload field 162.

The third packet 158 is transmitted from the advertiser device 102 to the scanner device 100. The scanner device 100 receives the third packet 158 and extracts the further authentication response. In some embodiments, the further authentication response is only extracted if the third packet address 154 is determined to match the address of the first packet 150.

Authentication of the advertiser device 102 by the scanner device 100 is then performed. Authentication of the advertiser device 102 by the scanner device 100 is achieved by comparing the further authentication response to known identity resolving keys. The identity resolving keys can, for example, comprise the identifiers of known advertiser devices 100 hashed with the first random number. If an identity resolving key in the scanner device 100 matches the authentication response, for example the second hash value, the advertiser device 102 is determined by the scanner device 100 as authenticated. If the identity resolving key in the scanner device 100 does not match the authentication response, the advertiser device 102 is determined by the scanner device 100 as not authenticated.

While figures 2A-C and 3 A-C have been described with reference to a hash function to generate the authentication response and further authentication response, other cryptographic functions can alternatively be used. Furthermore, elements of the methods described with reference to Figures 2A to 2C and 3 A to 3C may be combined.

The second packet 152 address can, in some embodiments, be in a different format from the address of the first packet 150 advertising packet. As an example, first packet m ay use a resolvable address while the second packet 152 may use a non-resolvable address, and vice versa. This also applies to embodiments with a the third packet 158 , where appropriate.

In some embodiments, the device to be authenticated is configured only to respond using the methods described above when it receives a specific identifier in a received packet. Examples include a specific service UUID. The identifier may be received in the received packet payload.

Figures 4A and 4B show examples of packet address formats containing a random part.

Figure 4 A shows an example of a non-resolvable address. The non-resolvable address 164 comprises a forty-eight-bit address comprising a random number 166 and one or more“most significant bits” 168. The most significant bits 168 indicate that the address is non-resolvable. In the example shown, there are two most significant bits 168 , though other numbers are possible. In some embodiments, the non-resolvable address in a response packet address may, for example, be a hash of the random part of the received packet address. A non-resolvable address 166 cannot be resolved by an identity resolving key.

Figure 4B shows an example of a resolvable address. The resolvable address 170 comprises a forty-eight-bit address. The resolvable address comprises a hash value 172, a random number 174 (in this example in the form of a pseudorandom number - prand), and one or more“most significant bits” 176. The hash 172 comprises a hash of an identifier of the device to which the address corresponds with the random number 174. The most significant bits 176 indicate that the address is resolvable. In the example shown, there are two most significant bits 176, though other numbers are possible. A resolvable address 170 can be resolved by an identity resolving key using the random number. Figure 5 is an illustration of an example flow diagram of an example process in the wireless advertiser device 102 of figures 1A and IB, carrying out the example operations, in accordance with at least one embodiment of the present invention . The operations of the flow diagram represent computer code instructions stored in the RAM and / or ROM 126 memory of the device, for example in the form of an application 110 , which when executed by the central processing units (CPU) 124 and / or 125, carry out the functions of the example embodiments of the invention . The operations may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following operations:

Operation 5.1: causing, by the apparatus, transmission of a first packet to a device, the first packet comprising an address field comprising a first random number;

Operation 5.2: receiving, from the device, a second packet comprising an

authentication response formulated at least in part based on the first random number and an identifier of the device; and

Operation 5.3 : authenticating the device in dependence on the authentication response.

Figure 6 is an illustration of an example flow diagram of an example process in the wireless scanner device 100 of figures 1A and IB, carrying out the example operations, in accordance with at least one embodiment of the present invention . The operations of the flow diagram represent computer code instructions stored in the RAM and / or ROM memory 126 of the device, for example in the form of an application 110 , which when executed by the central processing units (CPU) 124 and / or 125, carry out the functions of the example embodiments of the invention. The operations may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following operations:

Operation 6.1: receiving, from a device, a first packet, the first packet comprising an address field comprising a first random number;

Operation 6.2: generating an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and Operation 6.3 : causing transmission of a second packet comprising the authentication response to the advertising device 102.

As will be appreciated, the apparatuses 100 , 102 described herein may include various hardware components which may not have been shown in the Figures. For instance, the scanner device 100 and the advertiser device 102 may in some implementations include a portable computing device such as a mobile telephone or a tablet computer and so m ay contain components commonly included in a device of the specific type. Similarly, the apparatuses 100 , 102 may comprise further optional software

components which are not described in this specification since they may not have direct interaction to embodiments.

Embodiments may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and / or hardware may reside on memory, or any computer media. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a“memory” or“computer-readable medium” may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system , apparatus, or device, such as a computer.

Reference to, where relevant,“computer-readable storage medium”,“computer program product”,“tangibly embodied computer program” etc., or a“processor” or “processing circuitry” etc. should be understood to encompass not only computers having differing architectures such as single/ multi-processor architectures and sequencers/ parallel architectures, but also specialised circuits such as field

programmable gate arrays FPGA, application specify circuits ASIC, signal processing devices and other devices. References to computer program, instructions, code etc. should be understood to express software for a programm able processor firmware such as the programmable content of a hardware device as instructions for a processor or configured or configuration settings for a fixed function device, gate array,

programmable logic device, etc.

As used in this application, the term‘circuitry’ refers to all of the following: (a) hardware-only circuit implementations (such as implementations in only analogue and / or digital circuitry) and (b) to combinations of circuits and software (and/ or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/ software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of‘circuitry’ applies to all uses of this term in this application, including in any claim s. As a further example, as used in this application, the term“circuitry” would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and / or firmware. The term“circuitry” would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in server, a cellular network device, or other network device.

If desired, the different functions discussed herein may be performed in a different order and / or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined. Similarly, it will also be appreciated that methods described in relation to figures 5 and 6 are examples only and that various operations depicted therein may be omitted, reordered and or combined.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and / or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

Claims

Claim s

1. Apparatus configured:

to cause transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and

following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticate the device in dependence on the authentication response.

2. The apparatus of claim 1, wherein the address field of the first packet further comprises a hash value based on the first random number and an identifier associated with the apparatus.

3. The apparatus of claims 1 or 2, wherein the authentication response is contained within the address field of the second packet.

4. The apparatus of any preceding claim, wherein the authentication response comprises a hash value based on the first random number and the identifier of the device.

5. The apparatus of any preceding claim, wherein the address field of the second packet further comprises a second random number. 6. The apparatus of claim 5, wherein the apparatus if further configured to compare a function of the first random number to the second random number during authentication of the device, and to authenticate the device only the function of the first random number m atches the second random number. 1. The apparatus of claim 5, wherein the apparatus is further configured to:

following authentication of the device, generate a third packet, the third packet comprising a further authentication response based on the second random number and an identifier associated with the apparatus; and

cause transmission of the third packet to the device.

8. The method of claim 7, wherein the third packet comprises a payload field, and wherein the payload field comprises the further authentication response.

9. The apparatus of any preceding claim, wherein the first random number is regenerated periodically.

10. The apparatus of any preceding claim, wherein the authentication response is a hash value based on the first random number and the identifier of the device.

11. Apparatus configured:

to receive, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number;

to generate an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and

to cause transmission of a second packet comprising the authentication response to the advertiser device.

12. The apparatus of claim 11, wherein the address field of the first packet further comprises a hash value based on the first random number and an identifier associated with the advertiser device.

13. The apparatus of claims 11 or 12, wherein the apparatus is configured to authenticate the advertiser device in dependence on the first random number and the hash value.

14. The apparatus of any of claims 11 to 13, wherein the authentication response is contained within the address field of the second packet.

15. The apparatus of any of claims 11 to 14, wherein the address field of the second packet further comprises a second random number.

16. The apparatus of claim 15, wherein the second random number is generated based on the first random number.

17. The apparatus of any of claims 11 to 16, wherein the first random number is regenerated periodically.

18. The apparatus of any of claims 11 to 16, wherein the authentication response is a hash value based on the first random number and the identifier of the apparatus.

19. A system comprising:

the apparatus of claims 1 to 10 ; and

the apparatus of claims 11 to 18.

20. A method comprising:

causing transmission of a first packet to a device, the first packet comprising an address field comprising a first random number; and

following reception from the device of a second packet comprising an authentication response formulated at least in part based on the first random number and an identifier of the device, to authenticating the device in dependence on the authentication response.

21. The method of claim 20 , wherein the authentication response is contained within the address field of the second packet.

22. The method of any claims 20 or 21, wherein the address field of the second packet further comprises a second random number.

23. The method of claim 22, further comprising comparing a function of the first random number to the second random number during authentication of the device, and to authenticate the device only the function of the first random number matches the second random number.

24. A method comprising:

receiving, from an advertiser device, a first packet, the first packet comprising an address field comprising a first random number;

generating an authentication response formulated at least in part based on the first random number and an identifier associated with the apparatus; and

causing tran sm ission of a second p acket comprising the authentication respon se to the advertiser device .

25. The method of claim 24, wherein the address field of the first packet further comprises a hash value based on the first random number and an identifier associated with the advertiser device.

26. The method of claims 24 or 25, further comprising authenticating the advertiser device in dependence on the first random number and the hash value.

27. The method of any of claims 24 to 26, wherein the authentication response is contained within the address field of the second packet.

28. Apparatus comprising one or more processors and a memory, the memory comprising instructions that, when executed by the one or more processors, cause the apparatus to perform :

29. Apparatus comprising one or more processors and a memory, the memory comprising instructions that, when executed by the one or more processors, cause the apparatus to perform :

causing transmission of a second packet comprising the authentication response to the advertiser device.

30. A non-transitory computer readable medium having computer readable code stored thereon, the computer readable code, when executed by at least one processor, causing performance of:

31. A non-transitory computer readable medium having computer readable code stored thereon, the computer readable code, when executed by at least one processor, causing performance of: