U.S. patent application number 14/316404 was filed with the patent office on 2015-08-27 for device authentication.
This patent application is currently assigned to Cambridge Silicon Radio Limited. The applicant listed for this patent is Cambridge Silicon Radio Limited. Invention is credited to Robin Heydon.
Application Number | 20150245204 14/316404 |
Document ID | / |
Family ID | 50737759 |
Filed Date | 2015-08-27 |
United States Patent
Application |
20150245204 |
Kind Code |
A1 |
Heydon; Robin |
August 27, 2015 |
DEVICE AUTHENTICATION
Abstract
A method for authenticating a first device capable of operating
according to a wireless communications protocol, the method
comprising: at a second device, receiving a first message
comprising an identifier for the first device and an authorisation
code associated with the first device, the first message not being
received from the first device in accordance with the wireless
communications protocol; at the second device, receiving a second
message comprising a value, the second message being sent from the
first device in accordance with the wireless communications
protocol; and authenticating the first device if the authorisation
code received via the first message relates, according to a
predetermined algorithm, to the received value.
Inventors: |
Heydon; Robin; (Cottenham,
GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cambridge Silicon Radio Limited |
Cambridge |
|
GB |
|
|
Assignee: |
Cambridge Silicon Radio
Limited
Cambridge
GB
|
Family ID: |
50737759 |
Appl. No.: |
14/316404 |
Filed: |
June 26, 2014 |
Current U.S.
Class: |
713/171 ;
726/7 |
Current CPC
Class: |
Y02D 70/142 20180101;
Y02D 70/144 20180101; H04W 76/14 20180201; H04W 84/18 20130101;
H04L 9/0861 20130101; H04W 24/06 20130101; Y02D 30/70 20200801;
H04L 69/22 20130101; H04B 7/14 20130101; H04L 41/082 20130101; H04W
52/0251 20130101; H04L 63/08 20130101; H04W 40/24 20130101; H04W
88/06 20130101; H04W 12/003 20190101; H04W 76/11 20180201; H04L
43/065 20130101; H04L 43/0852 20130101; Y02D 70/1262 20180101; H04H
20/71 20130101; H04L 63/0853 20130101; Y02D 70/162 20180101; H04L
47/16 20130101; G06F 21/44 20130101; H04L 5/0055 20130101; H04W
12/06 20130101; Y02D 70/164 20180101; G06Q 10/0833 20130101; H04L
67/30 20130101; H04L 63/061 20130101; H04L 41/14 20130101; H04W
52/38 20130101; H04W 72/12 20130101; H04W 4/80 20180201; H04W
12/00522 20190101; Y02A 10/40 20180101; H04L 43/10 20130101; H04L
47/115 20130101; H04W 4/06 20130101; H04L 43/0882 20130101; H04W
12/04 20130101; H04L 45/02 20130101; Y02D 70/166 20180101; H04L
43/0817 20130101; H04L 49/1584 20130101; Y02A 10/46 20180101; Y02D
70/22 20180101; H04W 16/18 20130101; H04W 4/029 20180201 |
International
Class: |
H04W 12/06 20060101
H04W012/06; H04L 29/06 20060101 H04L029/06; H04W 12/04 20060101
H04W012/04 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 25, 2014 |
GB |
1403312.0 |
Feb 25, 2014 |
GB |
1403314.6 |
Mar 31, 2014 |
GB |
1405789.7 |
Claims
1. A method for authenticating a first device capable of operating
according to a wireless communications protocol, the method
comprising: at a second device, receiving a database identifier and
sending a request message comprising the database identifier to a
computer, the database identifier not being received from the first
device in accordance with the wireless communications protocol; at
the second device, receiving a response message from the computer
comprising an identifier for the first device and an authorisation
code associated with the first device; at the second device,
receiving a second message comprising a value, the second message
being sent from the first device in accordance with the wireless
communications protocol; and authenticating the first device if the
authorisation code received via the response message relates,
according to a predetermined algorithm, to the received value.
2. A method as claimed in claim 1, further comprising: at the
second device and in response to authenticating the first device,
sending an association message to the first device, the association
message comprising an encrypted network key by means of which the
first device can access a network comprising the second device.
3. A method as claimed in claim 2, further comprising, at the
second device: receiving a public key from the first device; and
calculating an encryption key in dependence the received public key
and a private key stored at the second device, the network key
being encrypted using the encryption key.
4. A method as claimed in claim 3, said calculation being in
accordance with a Diffie-Hellman-Merkle key exchange.
5. A method as claimed in claim 1, the database identifier being
received via an analysis of an image.
6. A method as claimed in claim 5, the image being a QR-Code,
barcode or text representing the database identifier.
7. A method as claimed in claim 5 further comprising, at the second
device: scanning the image, the image representing the database
identifier, sending the request message, via the internet; and in
response to the request, receiving the response message, via the
internet.
8. A method as claimed in claim 7, the response message comprising
one or more further identifiers and identification codes associated
with respective one or more further devices.
9. A method as claimed in claim 1, the value being dependent on an
authorisation code stored at the first device.
10. A method as claimed in claim 1, the value being different to
the authorisation code.
11. A method as claimed in claim 1, the value being calculated
using the predetermined algorithm having as inputs: the
authorisation code stored at the first device, a public key of the
first device and a random number generated by the first device.
12. A method as claimed in claim 11, said authenticating step
comprising: receiving the random number from the first device; from
the value, authorisation code and the public key, calculating a
number according to the predetermined algorithm; and comparing said
calculated number with the received random number and, if said
numbers match, authenticating the first device.
13. A method as claimed in claim 1, further comprising: at the
first device, broadcasting the identifier for the first device in
accordance with the communications protocol.
14. A method as claimed in claim 1, the second message being
received via a third device capable of operating according to the
communications protocol.
15. A method as claimed in claim 1, the second device being capable
of communicating in a mesh network.
16. A method as claimed in claim 1, wherein the wireless
communications protocol is Bluetooth Low Energy protocol.
17. A method as claimed in claim 1, the wireless communications
protocol defining a broadcast packet type, said second message
being received via a packet of the broadcast packet type.
18. A wireless communications device capable of operating according
to a wireless communications protocol, the wireless communications
device comprising: an input configured to receive a database
identifier, the database identifier not being received from the
first device in accordance with the wireless communications
protocol; an interface configured to send a request message
comprising the database identifier to a computer and to receive a
response message from the computer comprising an identifier for a
first device and an authorisation code associated with the first
device; a transceiver capable of operating according to the
wireless communications protocol and configured to receive a second
message comprising a value, the second message being sent from the
first device in accordance with the wireless communications
protocol; and a controller configured to authenticate the first
device if the authorisation code received via the response message
relates, according to a predetermined algorithm, to the received
value.
19. A wireless communications device as claimed in claim 18, the
input being a camera or barcode reader configured to analyse an
image.
20. A wireless communications device capable of operating according
to a wireless communications protocol, the wireless communications
device comprising: a transceiver configured to broadcast an
identifier for the device in accordance with the communications
protocol, wherein the identifier is associated with a database
identifier; a memory configured to store an authorisation code, the
transceiver being further configured to: send a first message
comprising a value, the value being related, according to a
predetermined algorithm, to the authorisation code; and in response
to sending the first message, receive a second message comprising
an encrypted network key; and a controller configured to decrypt
the encrypted network key by means of which the device can access a
network, wherein the device is configured to not send and not
display the authorisation code unencrypted.
Description
TECHNICAL FIELD
[0001] This invention relates to a method for securely
authenticating a device.
BACKGROUND OF THE INVENTION
[0002] There is an increasing need for a variety of objects to be
equipped with the ability to send and receive messages. In the case
of a home, for example, it may be desirable that the objects in a
room be capable of communicating with each other, and also
potentially to be able to communicate with the internet or cloud.
For example, the room may have a light, light switch, window and
door. It may be desired that each of these objects be able to
communicate with the others so that the home can be automated.
[0003] To enable objects to communicate, they may be equipped with
a communication device that can communicate with similar
communication devices attached to other objects. For this
architecture to be of greatest use, a large number of objects need
to be able to communicate with each other. The result can be a
network of many communication devices, each associated with a
respective object. As many of these objects will not have access
to, or require, power themselves (for example, a window, door,
packages sitting on a shelf, etc.), it may be desirable for the
devices that communicate on the objects' behalf to be
battery-powered devices that consume only a small amount of power.
It may also be desirable that these devices be able to communicate
wirelessly with each other so that there is no need for cables
running between them.
[0004] One suitable method of communication for such a network is
to use a mesh networking protocol. This permits a first device to
send a message to a second device, which may be outside the
communication range of the first device, by transmitting the
message via one or more intermediate devices. Historically, mesh
networking protocols are typically designed around the concept of
devices sending messages using complex routing tables. Such complex
routing requires processing power which tends to increase power
consumption of the devices. Such mesh networking protocols also
tend to operate according to proprietary protocols. This means
devices may have to be manufactured specifically for the task of
communicating according to a particular mesh network. This may be
undesirable because it increases the cost of devices that might be
installed in a multitude locations and/or attached to a multitude
of different devices.
[0005] Another consideration is to provide adequate security to the
mesh network against potential attackers. The mesh network may be
especially vulnerable to attacks when new devices added to the
network. One possible type of attack is an "eavesdropper attack"
where an attacker passively listens to messages exchanged between
devices in the mesh network. Another type of attack is a
"man-in-the-middle attack" where an attacker intercepts messages
between two devices FIG. 1a shows how these types of attacks may be
carried out when a new device is to be added to an existing mesh
network.
[0006] A new device "B", which may be a newly purchased light, is
to join a mesh network that is configured by a configuring device
"C", which may be a smartphone belonging to the purchaser. B may be
required to be associated with the mesh network and C can perform
that association. An eavesdropper "E" can passively listen to
messages exchanged between C and B. Also, a man-in-the-middle "M"
can intercept messages and pretend to be C to B and pretend to be B
to C and so all messages between B and C are passed through M. The
association process can involve C sending a network key, which
allows access to the network, to B. As E and M can observe these
messages, the security of the network may be compromised if E or M
obtain the network key.
[0007] One method of preventing the eavesdropper attack by E is to
encrypt messages between the B and C. To allow any device within
the network to send and receive messages from any other device in
the network, a single network key may be used. Because this single
network key is critical to the security of the network, this
network key should never be distributed to a device insecurely.
Therefore, a key exchange mechanism (e.g. a Diffie-Hellman-Merkle
key exchange) could be performed before the network key is
distributed to a new device.
[0008] However, the key exchange mechanism may not prevent a
man-in-the middle attack. As shown in FIG. 1b, when devices B and C
send their public keys PK.sub.B and PK.sub.C respectively, M can
intercept the messages and insert its own keys PK.sub.MB and
PK.sub.MC, which are then sent to devices C and B respectively.
Device M can then calculate two sets of secret keys
S.sub.MC=S.sub.CM and S.sub.MB=S.sub.BM that would be used for
communication between devices C and B through device M. Thus the
security of the network may still be compromised using known key
exchange mechanisms.
[0009] There is therefore a need for improving the security of a
mesh network.
SUMMARY OF THE INVENTION
[0010] According to a first aspect there is provided a method for
authenticating a first device capable of operating according to a
wireless communications protocol, the method comprising: at a
second device, receiving a first message comprising an identifier
for the first device and an authorisation code associated with the
first device, the first message not being received from the first
device in accordance with the wireless communications protocol; at
the second device, receiving a second message comprising a value,
the second message being sent from the first device in accordance
with the wireless communications protocol; and authenticating the
first device if the authorisation code received via the first
message relates, according to a predetermined algorithm, to the
received value.
[0011] The method may further comprise: at the second device and in
response to authenticating the first device, sending an association
message to the first device, the association message comprising an
encrypted network key by means of which the first device can access
a network comprising the second device.
[0012] The method may further comprise, at the second device:
receiving a public key from the first device; and calculating an
encryption key in dependence the received public key and a private
key stored at the second device, the network key being encrypted
using the encryption key.
[0013] The calculation may be in accordance with a
Diffie-Hellman-Merkle key exchange.
[0014] The first message may be received via an analysis of an
image.
[0015] The image may be a QR-Code, barcode or text representing the
identifier and the authorisation code.
[0016] The method may further comprise, at the second device:
scanning the image, the image representing a database identifier;
sending, via the internet, a request message comprising the
database identifier to a computer; and in response to the request,
receiving, via the internet, the first message from the
computer.
[0017] The first message may comprise one or more further
identifiers and identification codes associated with respective one
or more further devices.
[0018] The value may be dependent on an authorisation code stored
at the first device.
[0019] The value may be different to the authorisation code.
[0020] The value may be calculated using the predetermined
algorithm having as inputs: the authorisation code stored at the
first device, a public key of the first device and a random number
generated by the first device.
[0021] The authenticating step may comprise: receiving the random
number from the first device; from the value, authorisation code
and the public key, calculating a number according to the
predetermined algorithm; and comparing said calculated number with
the received random number and, if said numbers match,
authenticating the first device.
[0022] The method may further comprise: at the first device,
broadcasting the identifier for the first device in accordance with
the communications protocol.
[0023] The second message may be received via a third device
capable of operating according to the communications protocol.
[0024] The first device may be sited at a location that is out of
range of transmission from the second device.
[0025] The second device may be capable of communicating in a mesh
network.
[0026] The wireless communications protocol may be Bluetooth Low
Energy protocol.
[0027] The wireless communications protocol may define a broadcast
packet type, said second message may be received via a packet of
the broadcast packet type.
[0028] According to a second aspect there is provided a wireless
communications device capable of operating according to a wireless
communications protocol, the wireless communications device
comprising: an input configured to receive a first message
comprising an identifier for a first device and an authorisation
code associated with the first device, the first message not being
received from the first device in accordance with the wireless
communications protocol; a transceiver capable of operating
according to the wireless communications protocol and configured to
receive a second message comprising a value, the second message
being sent from the first device in accordance with the wireless
communications protocol; a controller configured to authenticate
the first device if the authorisation code received via the first
message relates, according to a predetermined algorithm, to the
received value.
[0029] The transceiver may be further configured to, in response to
authenticating the first device, send an association message to the
first device, the association message comprising an encrypted
network key configured to allow the first device access to a
network comprising the wireless communications device.
[0030] The transceiver may be further configured to receive a
public key from the first device, the controller being further
configured to calculate an encryption key in dependence the
received public key and a private key stored at the wireless
communications device, the network key being encrypted using the
encryption key.
[0031] The controller may be further configured to calculate the
encryption key in accordance with a Diffie-Hellman-Merkle key
exchange.
[0032] The input may be a camera or barcode reader configured to
analyse an image.
[0033] The image may be a QR-Code, barcode or text representing the
identifier and the authorisation code.
[0034] The wireless communications device may further comprise a
camera or barcode reader configured to analyse an image
representing a database identifier, the input being a network
interface capable of communicating via the internet and configured
to: send, via the internet, a request message comprising the
database identifier to a computer; and in response to the request,
receive, via the internet, the first message from the computer.
[0035] The first message may comprise one or more further
identifiers and identification codes associated with respective one
or more further devices.
[0036] The value may be dependent on an authorisation code stored
at the first device.
[0037] The value may be different to the authorisation code.
[0038] The controller may be configured to calculate the value
using the predetermined algorithm having as inputs: the
authorisation code stored at the first device, a public key of the
first device and a random number generated by the first device.
[0039] The transceiver may be further configured to receive the
random number from the first device; the controller may be further
configured to: calculate, according to the predetermined algorithm,
a number from the value, authorisation code and the public key, and
compare said calculated number with the received random number and,
if said numbers match, authenticate the first device.
[0040] The first device may be sited at a location that is out of
range of transmission from the transceiver.
[0041] The transceiver may be capable of communicating in a mesh
network.
[0042] The wireless communications protocol may be Bluetooth Low
Energy protocol.
[0043] The wireless communications protocol may define a broadcast
packet type, said second message being received via a packet of the
broadcast packet type.
[0044] According to a third aspect there is provided a wireless
communications device capable of operating according to a wireless
communications protocol, the wireless communications device
comprising: a transceiver configured to broadcast an identifier for
the device in accordance with the communications protocol; a memory
configured to store an authorisation code, the transceiver being
further configured to: send a first message comprising a value, the
value being related, according to a predetermined algorithm, to the
authorisation code; and in response to sending the first message,
receive a second message comprising an encrypted network key; and a
controller configured to decrypt the encrypted network key by means
of which the device can access a network.
[0045] The device may be configured to not send the authorisation
code unencrypted.
BRIEF DESCRIPTION OF THE DRAWINGS
[0046] The present invention will now be described by way of
example with reference to the accompanying drawings. In the
drawings:
[0047] FIG. 1a shows devices in a scenario in which the security of
a network may be compromised:
[0048] FIG. 1b shows devices in a man-in-the-middle attack
scenario;
[0049] FIG. 2 shows a method of authorising a device;
[0050] FIG. 3 shows a message exchange for another method of
authorising a device; and
[0051] FIG. 4 shows a schematic diagram of a configuring
device.
DETAILED DESCRIPTION
[0052] The following description is presented to enable any person
skilled in the art to make and use the invention, and is provided
in the context of a particular application. Various modifications
to the disclosed embodiments will be readily apparent to those
skilled in the art.
[0053] The general principles defined herein may be applied to
other embodiments and applications without departing from the
spirit and scope of the present invention. Thus, the present
invention is not intended to be limited to the embodiments shown,
but is to be accorded the widest scope consistent with the
principles and features disclosed herein.
[0054] To protect against man-in-the-middle (MITM) attacks, the
identity of a new device must be verified before a configuring
device in the network can trust the new device. Given that a new,
unverified device may not be accessible or have any form of user
interface, and may possibly be a long distance from the configuring
device as it may be in a mesh network, the concepts typically used
in, for example. Bluetooth to "pair" devices may not be suitable.
To verify the identity of new devices, each device is provided with
an "authorisation secret" that is only known by that device. To
allow the configuring device to verify the new device, it needs to
securely obtain the authorisation secret.
[0055] FIG. 2 shows one method for the configuring device 201 to
obtain the authorisation secret of a new device 202 that is to be
added to a mesh network comprising configuring device 201. Devices
201 and 202 and the mesh network may operate according to a
wireless communications protocol such as Bluetooth Low Energy. The
authorisation code of the new device 202 could be made available to
the configuring device 201 so that new device 202 can be
authenticated. However, transmitting the authorisation code over
the network would allow an eavesdropper or a MITM attacker 203 to
obtain the code. Thus, in order to protect against an attack,
device 202 should not transmit its authorisation code in accordance
with the protocol over the network. In other words, configuring
device 201 would have to acquire the authorisation code by means
other than via messages sent according to the wireless
communications protocol used by the new device 202 and the mesh
network. Thus, device 201 should not receive (directly or
indirectly via an intermediate device) the authorisation code for
device 202 from a message originating from device 202, wherein the
message is sent by device 202 in accordance with the wireless
communication protocol of the mesh network.
[0056] The authorisation code may instead be obtained by the
configuring device 201 using another method such as via a QR-Code
or a Short Code that might be printed on the new device 202 or the
packaging of the device 202. The code could be presented as a
one-dimensional or two-dimensional bar code, or in some other way
that permits a device to reliably interpret the code using a sensor
installed on the device. That sensor could be a camera, an audio
sensor, a magnetic sensor and so on. As shown in the example of
FIG. 2, the authorisation code may be conveyed to the configuring
device 201 via a QR-Code. The QR-Code may have encoded thereon an
authorisation code and an identifier for the device 202. The
authorisation code and the identifier may be unique to each device.
Device 202 may also have a matching authorisation code and
identifier stored in a memory on the device 202. For the
configuring device 201 to verify that the new device 202 is that
device and not a man-in-the-middle device 203, the configuring
device 201 is required to match the identifier and authorisation
code obtained via means other than via the network (such as the
QR-Code) and the authorisation code and identifier stored on the
device 202 without that stored information being transmitted over
the mesh network.
[0057] Device 202 can generate a random number RANDOM.sub.B and
calculate a confirmation value CONFIRM.sub.B by having RANDOM.sub.B
and the authorisation code as inputs to a predetermined algorithm,
which may be, for example, a cryptographic hash function such as
HMAC-SHA256 (e.g. CONFIRM.sub.B=HMAC (RANDOM.sub.B, authorisation
code)). The predetermined algorithm may be known to both devices
201 and 202. Device 202 sends value CONFIRM.sub.B to device 201.
Device 202 can then send value RANDOM.sub.B to device 201 so that
device 201 can calculate, using the same predetermined algorithm, a
confirmation value from RANDOM.sub.B and the authorisation code
obtained via the OR-Code. CONFIRM.sub.B and RANDOM.sub.B could be
sent in the same message. If the confirmation value calculated by
device 201 matches CONFIRM.sub.B, then device 202 is verified and
is therefore trusted. The MITM device 203 does not know the
authorisation code and thus cannot generate the correct inputs to
the predetermined algorithm and thus will not be able to generate
the correct RANDOM.sub.B value that will allow device 201 to arrive
at the correct confirmation value CONFIRM.sub.B.
[0058] Additional messages may be exchanged between devices 201 and
202 to further enhance the security of the verification procedure
to allow device 202 to be associated with the mesh network. Such an
enhanced procedure is described with reference to the sequence
chart of FIG. 3.
[0059] At step 301, configuring device 201 scans a QR-Code to
obtain an authorisation code and an identifier (ID) for new device
202. This information can be obtained at any time, for example by
taking a picture of the QR-Code on the box that the device 202
arrived in. It could also be obtained by typing in the
authorisation code into a user interface at the configuring device
201.
[0060] At step 302, device 202 advertises its ID by broadcasting it
in accordance with the wireless protocol used by the mesh network.
Configuring device 201 receives this information. This information
may be received via an intermediate device within the mesh network
if devices 201 and 202 are out of range from each other. The
configuring device 201 determines that new device 202 is to be
added to the network and starts a verification procedure. An
eavesdropper or a MITM device 203 may also observe the broadcasted
ID.
[0061] At step 303, the configuring device 201 sends its public key
PK.sub.a to new device 202 and, in response at step 304, device 202
send its public key PK.sub.b to configuring device 201. An
eavesdropper may be able to receive both of these messages. A MITM
device 203 could have placed itself between the two devices 201 and
202 and inserted its own public keys, PK.sub.ma and PK.sub.mb into
the communications in an attempt to become a man-in-the-middle.
[0062] At step 305, configuring device 201 and the new device 202
calculate a shared secret S from their respective private keys and
the peer device's public key. This may be achieved using the
Diffie-Hellman-Merkle key exchange method. The eavesdropper cannot
calculate the shared secret because it does not have knowledge of
the private keys used. The MITM 203 may be able to calculate two
shared secrets, one that it could use when communicating with
device 201, S.sub.ma, when pretending to be new device 202 and one
that it would use when communicating with device 202, S.sub.mb,
when pretending to be the configuring device 201.
[0063] At step 306, the configuring device 201 sends a confirmation
value CONFIRM.sub.a to new device 202. The confirmation value can
be determined based on a random number RANDOM.sub.a, the public key
of device 201 and the authorisation code obtained via the QR-Code
CONFIRM.sub.a may be calculated using a predetermined algorithm.
For example, the predetermined algorithm could be a cryptographic
hash function such as HMAC-SHA256 with RANDOM.sub.a and a
concatenation of the public key for device 201 and the
authorisation code as inputs (e.g. CONFIRM.sub.a=HMAC
(RANDOM.sub.a, Public key for 201 .parallel. authorisation
code)).
[0064] In response, at step 307, new device 202 sends its
confirmation value CONFIRM.sub.b to device 201. CONFIRM.sub.b can
be determined based on a random number RANDOM.sub.b, the public key
of device 202 and the authorisation code stored at the device 202.
CONFIRM.sub.b may be calculated using the same predetermined
algorithm. As in the example above, the predetermined algorithm
could be HMAC-SHA256 with RANDOM.sub.b and a concatenation of the
public key for device 202 and the stored authorisation code as
inputs (e.g. CONFIRM.sub.b=HMAC (RANDOM.sub.b, Public key for 202
.parallel. authorisation code)). The eavesdropper can receive the
confirmation values. However, the values do not reveal any useful
information as they appear to be random numbers to the
eavesdropper. The MITM 203 does not know the authorisation code and
therefore whilst it can generate the appropriate messages, it
cannot calculate the inputs required to obtain the confirmation
values.
[0065] At step 308, the configuring device 201 sends the random
number RANDOM.sub.a to new device 202. In response, at step 309,
new device 202 sends random number RANDOM.sub.b to device 201. Both
devices 201 and 202 can then confirm, using the predetermined
algorithm, that the received random numbers, the authorisation code
available to each device and the peer's public key generate the
same confirmation value that was previously received. Thus the
configuring device 201 has determined that the messages from the
new device 202 are authentic and so new device 202 is a trusted
device. The eavesdropper can receive these random number messages,
however it does not have the authorisation code. The MITM 203
cannot generate two random numbers that, when sent, would match the
confirmation values that were previously sent. Thus devices 201 and
202 are able to verify that they are communicating with each other
and not a MITM device 203.
[0066] At step 310, the configuring device 201 sends an encrypted
network key to new device 201. The network key may be encrypted
using S and a concatenation of RANDOM.sub.a and RANDOM.sub.b. The
configuring device 201 may also send an encrypted allocated ID to
new device 202 which will be its allocated ID for use within the
mesh network. The eavesdropper cannot decrypt this message as it
does not have knowledge of S. The MITM 203 is no longer trusted by
either device 201 or 202 as the MITM 203 could not generate the
correct random numbers and therefore any messages from MITM 204
message will be ignored.
[0067] As well as in step 310, the secret key S could be used to
encrypt the messages sent in any of steps 306 to 309.
[0068] Using the network key, the new device 202 is then able to
securely join the mesh network and securely send and receive
messages, which may be encrypted using the network key.
[0069] The messages in steps 302 to 310 may be sent in accordance
with the wireless communications protocol of the mesh network.
Devices 201 and 202 may communicate directly with each other if
they are in communications range. If they are out of direct
communications range with each other, then the messages may be sent
via one or more intermediate devices within the mesh network which
can forward the messages so that they can reach device 201 or
202.
[0070] The authorisation code and device ID for a device may be
assigned at manufacture and stored in the memory of the device. The
authorisation code and ID may be static for the lifetime of the
device. The authorisation code and the ID information may also be
made available to a purchaser of the device so that the device can
securely be added to their network. The authorisation code and ID
information can be made available by number of different means such
as encoding the information into a QR-Code or a ShortCode and
displaying it, for example, on the device or the packaging of the
device.
[0071] The QR-Code or ShortCode may contain a URL that can provide
a link to the device manufacturer's database which contains the
authorisation code for the device. Thus the authorisation code and
ID for the device may be received in a message sent over the
internet. In a situation where a purchaser buys a large number of
grouped devices, e.g. a group of lights, that are to be connected
to a mesh network, it may be time consuming to scan the QR-Code for
each individual light. Thus, there may be a single QR-Code that is
associated with that group which links to a manufacturer's
database. The purchaser can scan in the QR-Code, which contains a
group identifier and links to the manufacturer's database, e.g. via
the internet, to allow a configuring device 201 to communicate with
the database and extract all the authorisation codes and associated
IDs for each light in that group. The received authorisation codes
and ID can then be used to verify each device as described
above.
[0072] FIG. 4 shows an example schematic of a configuring device
201. The configuring device 201 may comprise a transceiver 401, a
scanner 402, a network interface 403 and a controller 404. The
configuring device 201 may be a smartphone, tablet, laptop, a
computer, etc.
[0073] The transceiver 401 may be configured to operate according
to a wireless communication protocol such as Bluetooth low energy
and is able to wirelessly send and receive messages over the mesh
network.
[0074] The scanner 402 may be any suitable device that is capable
reading an image such as a OR-Code or barcode or text. For example,
the scanner 202 may be a camera that can capture an image of a
QR-Code or barcode or text. The image may be analysed by, for
example, the controller 404 to decode and retrieve the information
in the QR-Code or barcode. If the captured image is of text, the
controller 404 may perform character recognition on the image to
extract the information in the text. Thus the scanner 402 is
capable of receiving a message coded in the image which may contain
an authorisation code and ID of a device. Alternatively, the
scanner 402 may be a barcode reader which is capable of scanning
and decoding QR-Code and/or barcodes and providing the decoded
information to the controller 404.
[0075] In another example, instead of encoding the authorisation
code and ID information on an image, the information could be
stored on a short-range NFC device or RFID tag on the new device
202 or the packaging of the new device. The scanner 402 may then be
a NFC or RFID reader which is capable of reading and extracting the
information stored on the NFC device or RFID tag.
[0076] As mentioned above, the message coded in the image may be a
link to a database containing the authorisation code and ID of a
device. The controller 404 may access the database via the network
interface 403. The network interface 403 may be, for example, a
WiFi or mobile data interface which allows connection to the
internet. The controller 404 may request, via the internet, one or
more authorisation codes and associated IDs based on the
information retrieved using the scanner 402. In response to the
request, the database may send the configuring device 201, via the
internet, the one or more of the requested authorisation codes and
associated ID and is received via the network interface 403.
[0077] The controller 404 can control the transceiver 401, scanner
402 and network interface 403 to carry out the verification
procedure described above. The controller 404 can be configured to
cause the configuring device 201 to carry out the verification and
messaging procedures described above. The controller 404 may be
configured to carry out the processing described above such as
calculating the confirmation values and encryption keys, generating
random numbers, comparing the values, etc.
[0078] The new device 202 may be used with appliances such as light
switches, lights, sensors, lire alarms, sensors, thermostats, etc.
The new device 202 may comprise a transceiver configured to operate
according to a wireless communication protocol such as Bluetooth
low energy. The new device 202 may also comprise a memory
configured to store data such as the authentication code and device
ID, network key, allocated ID, etc. The new device 202 may also
comprise a controller that is configured to cause the new device
202 to carry out the verification and messaging procedures
described above. The controller and/or transceiver can be
configured to cause the new device 202 to not send the
authorisation code via transceiver, unless it is encrypted.
[0079] Devices 201 and 202 may be wireless communication devices
that operate according to the same wireless communication protocol.
The wireless communication protocol could be a relatively
short-range protocol. For example the effective range of each
device could be less than 25 m. That characteristic can permit the
devices to use less power for transmitting and/or receiving than
would be expected in a longer range protocol. In one example, the
devices could operate according to the Bluetooth protocol,
specifically the Bluetooth Low Energy (BLE) protocol. The devices
could use other protocols, for instance IEEE 802.11.
[0080] The devices described above could form a mesh network with
other wireless communication devices. The devices could be
configured to forward some or all messages they receive. The
messages could be sent and received via a broadcast packet type
defined in the wireless communication protocol. All the devices in
the network could be peers in that they have identical roles at a
network level.
[0081] Devices 201 and 202 could operate according to two different
wireless communications protocols, e.g. BLE and IEEE 802.11.
Devices 201 and 202 may be connected via an IEEE 802.11 network,
which can allow secure communication between the two devices. New
device 202 may then wish to join a mesh network (that comprises
device 201) that is operating according to the BLE protocol. Device
202 may securely transmit a message comprising its authentication
code and ID via IEEE 802.11 to device 201. Device 201 can trust
this message as it is sent over a secure IEEE 802.11 channel and
can use the authentication code received via IEEE 802.11 (instead
of via the QR-Code, for example) in the authentication procedure
described above for adding the new device 202 to the BLE mesh
network.
[0082] The devices configured in accordance with the examples
described herein could be embodied in hardware, software or any
suitable combination of hardware and software. The receiving device
of the examples described herein could comprise, for example,
software for execution at one or more processors (such as at a CPU
and/or GPU), and/or one or more dedicated processors (such as
ASICs), and/or one or more programmable processors (such as FPGAs)
suitably programmed so as to provide functionalities of the data
processing system, and/or heterogeneous processors comprising one
or more dedicated, programmable and general purpose processing
functionalities. In the examples described herein, the devices
comprise one or more processors and one or more memories having
program code stored thereon, the data processors and the memories
being such as to, in combination, provide the claimed data
processing systems and/or perform the claimed methods.
[0083] Data processing units described herein (e.g. controller 404)
need not be provided as discrete units and represent
functionalities that could (a) be combined in any manner, and (b)
themselves comprise one or more data processing entities. Data
processing units could be provided by any suitable hardware or
software functionalities, or combinations of hardware and software
functionalities.
[0084] Any one of more of the methods described herein could be
performed by one or more physical processing units executing
program code that causes the unit(s) to perform the data processing
methods. Each physical processing unit could be any suitable
processor, such as a CPU or GPU (or a core thereof), or fixed
function or programmable hardware. The program code could be stored
in non-transitory form at a machine readable medium such as an
integrated circuit memory, or optical or magnetic storage. A
machine readable medium might comprise several memories, such as
on-chip memories, computer working memories, and non-volatile
storage devices.
[0085] The applicant hereby discloses in isolation each individual
feature described herein and any combination of two or more such
features, to the extent that such features or combinations are
capable of being carried out based on the present specification as
a whole in the light of the common general knowledge of a person
skilled in the art, irrespective of whether such features or
combinations of features solve any problems disclosed herein, and
without limitation to the scope of the claims. The applicant
indicates that aspects of the present invention may consist of any
such individual feature or combination of features. In view of the
foregoing description it will be evident to a person skilled in the
art that various modifications may be made within the scope of the
invention.
* * * * *