GB2560894A

GB2560894A - Secure transfer of data between internet of things devices

Info

Publication number: GB2560894A
Application number: GB1704639.2A
Authority: GB
Inventors: Taberner Neil
Original assignee: Individual
Current assignee: Individual
Priority date: 2017-03-23
Filing date: 2017-03-23
Publication date: 2018-10-03
Anticipated expiration: 2037-03-23
Also published as: GB201704639D0; GB2560894B

Abstract

A method to establish ownership of one device by another. A first device 10, 30a sends ownership data over a point-to-point communication link 330 to a second device 20, 30b. The first device 10, 30a is already registered with a registration entity 40 as being owned by an ownership entity, the second device 20, 30b is unregistered. The ownership data sent identifies the ownership entity and the network address of the registration entity 40. The second device 20, 30b contacts the registration entity 40 via the Internet 320 for authentication of the ownership data. If the registration entity 40 returns a confirmation that the authentication is successful the second device 20, 30b stores the ownership data. The point-to-point link 330 may be a wireless link such as Near Field Communication (NFC) or a RFID communications link. The first device 10, 30a may be a smartphone or similar device, the second device 20, 30b may be an IoT device. The second device 20, 30b may encrypt the data sent to the registration entity 40 using a key sent by the first device 10, 30a.

Description

(54) Title of the Invention: Secure transfer of data between internet of things devices

Abstract Title: Sending data to an Internet of Things (loT) device over a point-to-point link so that its ownership may be authenticated at a registration entity (57) A method to establish ownership of one device by another. A first device 10, 30a sends ownership data over a point-to-point communication link 330 to a second device 20, 30b. The first device 10, 30a is already registered with a registration entity 40 as being owned by an ownership entity, the second device 20, 30b is unregistered. The ownership data sent identifies the ownership entity and the network address of the registration entity 40. The second device 20, 30b contacts the registration entity 40 via the Internet 320 for authentication of the ownership data. If the registration entity 40 returns a confirmation that the authentication is successful the second device 20, 30b stores the ownership data. The point-to-point link 330 may be a wireless link such as Near Field

Communication (NFC) or a RFID communications link. The first device 10, 30a may be a smartphone or similar device, the second device 20, 30b may be an loT device. The second device 20, 30b may encrypt the data sent to the registration entity 40 using a key sent by the first device 10, 30a.

FIG 10

1/18

FIG 1 PRIOR ART

2/18

CO

FIG 2 PRIOR ART

3/18

FIG 3

Ο

4/18

ο

ΙΌ

FIG 4

5/18

FIG 5

6/18

FIG 6

J

7/18

FIG 7

8/18

9/18

FIG 9

10/18

33b

FIG 10 ο

11/18

FIG 11

12/18

330

FIG 12 ο

CD

13/18

330

FIG 13

14/18 /1_κ / Οϊ,ϊίΙΝ,ϊικχΝΐ?; ί®\ < ^«Sf^SSki Jt \ C««nnw.--wtwn /

I		1
	sssX	1
r--~-~--

'\.X_X $W>

ϊ «.·>'.·\ν\<^ΛΛ·*· }ΐ}.ν<.·> A A Λ X .’X .·\Λ <\Χ·ί i-X-KJ'

S''—<ί\ί\··ν!κ Ά’ λν\^<·\·«; A~ Χξ-V&XitS.·'? L:NK.AC<~ A3 A

S»- MfS. Cxsreci®?·· «<<$«>\ s ΚβΜλ

M k

K-?®»τ ««w<?' k

z?-*\ \ ,-/

I k us

$$k s? Sfssiy WiSXsiAste S r& As s'A<s® swS A«s$i.s«si jsgsj ξ«8 ?wsii$s $S.®S«SS<®«!

-R£C\i£ST CO^CUOsY

ASA ISfeSi' -it $>&>' KtCKjgg i&A ® ¥?>s &$. $A^s· xW® SsxsssssS

TO sw Ajss^ tosjsissc ssssss <»

-^SUSS.* COWCViON { <

..............ACK t ......

’ Ssss« C'SSSACiSS?·

Ob$S-S««SSS88Sto

$.»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»>»»»»»»»^ £:^K.A.\5vV \>T ?§.' i i

--CSSS* Cs»«WKfS i !

C sjsss < aws*«ss??

e^rASTtov rxwssί%κ Cxs'fiAAssf; -Cs>$A Cssf'XW&OS

FIG 14

15/18

FIG 15

16/18

/

FIG 16A FIG 16B

17/18

1700

FIG 17

18/18

1761

1762

1763

1764

1765

1766

1767

FIG 18

Intellectual

Property

Office

Application No. GB1704639.2

RTM

Date :13 September 2017

The following terms are registered trade marks and should be read as such wherever they occur in this document:

WiFi (Page 30)

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

SECURE TRANSFER OF DATA BETWEEN INTERNET OF THINGS DEVICES

TECHNICAL FIELD

The present invention relates to the secure transfer of data between Internet of Things devices.

BACKGROUND

The Internet of Things (loT), which refers to internetworked electronic devices (referred to as ‘Things’) that are able to collect and exchange data and/or send or receive control commands to control operations of the devices, is increasingly widely used and relevant to our daily lives. While loT devices may be fully functioning computer systems, such as portable devices like smart phones and tablets, they may also be everyday objects, or even biological systems, embedded with electronics, software, sensors, actuators and network connectivity. Common examples include fridges, cars and so-called ‘smart home’ devices such as lighting, heating, air conditioning and security systems. The inclusion of such everyday objects in the loT increasingly allows users to remotely manage their lives, through their loT devices, using the Internet.

Use of the loT inherently involves the transfer of data between loT devices, especially between loT devices owned by the same ownership entity. For example, a person may have a smart thermostat installed in their home and also own a smart phone. In this case, the thermostat can generate data indicating its current temperature setting, and the user can receive this data through an application (or ‘app’) installed on their smart phone. The user can then use the app on their phone to send control commands to the thermostat in order to remotely change the temperature setting.

Most known implementations of this data transfer involve a cloud service provided by the manufacturer of the loT device. This is illustrated in Figure 1, where data is being transferred between two loT devices, a smart phone 1 and a car 2. As can be seen, data sent from the car 2 to the smart phone 1 over the Internet is first sent over the Internet to a cloud service 3, before being sent on over the Internet to the smart phone 1. Likewise, data sent from the smart phone 1 to the car 2 is first sent over the Internet to the cloud service 3 before being sent on over the Internet to the car 2.

Before transferring data between the car 2 and the smart phone 1, it is desirable to first verify that the car 2 and phone 1 are commonly owned, or at least that a user of the phone has permission to transfer data between the phone 1 and car 2. To this end, the user will download an app that is distributed by the manufacturer of the car 2 onto their smart phone 1. At a point prior to or after downloading the app, the user registers for a user account with the manufacturer of the car 2, and can sign in to the user account through the app on their smart phone 1. The user can then request, via the app, for the manufacturer of the car 2 to send a registration code to the car 2. Upon receiving the code at the car 2, the user inputs the code into the app on their phone 1. This verifies that the user of the app has access to the car 2, and therefore has permission to communicate with the car 2. From this point on, data can be sent between the car 2 and smart phone 1, over the Internet, via the cloud service 3.

Another known implementation, which also uses a cloud service, is illustrated in Figure 2.

In this example there are two loT devices, a fridge 2a and a thermostat 2b, that are located in the vicinity of each other, such as in the same house. This is illustrated by the dotted lines enclosing the loT devices 2a, 2b. The house also includes a wireless router 4, which is connected to the Internet and provides wireless network coverage to the house, and a ‘hub’ 5. Rather than communicating directly with the wireless router 4, the loT devices 2a, 2b communicate with the hub 5, and the hub 5 communicates with the wireless router 4. While the hub 5 communicates with the router 4 using standard IEEE 802.11 WLAN communication protocols, the hub 5 communicates with the loT devices 2a, 2b using a different communication protocol. For example, some hubs sold by Samsung (Registered Trade Mark) use the ZigBee (Registered Trade Mark) protocol. Data is transferred between the loT devices 2a, 2b and the smart phone 1, over the Internet, via the cloud service 3 which is provided by the manufacturer of the hub 5.

Before transferring data between the loT devices 2a, 2b and the smart phone 1, it is desirable to first verify that the loT Devices 2a, 2b and the smart phone 1 are commonly owned, or at least that a user of the phone 1 has permission to transfer data between the phone 1 and the loT devices 2a, 2b. To this end, the user will download an app that is distributed by the manufacturer of the hub 5 onto their smart phone 1, register a user account with the manufacturer of the hub 5, and sign in to the user account through the app. When the smart phone 1 is within the range of the wireless router 4, the user can see the hub 5 on the WLAN and connect to it if they know a password of the hub 5. Once connected to the hub 5, the user can see the loT devices 2a, 2b that are connected to the hub 5 and can choose to place the loT devices 2a, 2b in an accessible mode. This verifies that the user of the phone 1 has permission to communicate with the loT devices 2a, 2b. From now on, the data can be transferred between the loT devices 2a, 2b and the smart phone 1, over the Internet, via the cloud service provided by the hub manufacturer.

SUMMARY OF THE INVENTION

The inventor has appreciated problems with these known implementations.

Referring to the implementation of Figure 1, the inventor has appreciated that a user requires a separate user account and app for each loT device manufacturer. While the implementation of Figure 2 somewhat reduces this problem using a single hub that communicates with multiple loT devices, it is limited to communicating with loT devices which are compatible with the hub. Extending the implementation to multiple locations may require a user to purchase multiple hubs, which may be expensive, and/or to configure and maintain a wireless network in multiple locations, which may be laborious and sometimes impractical. Further, should the hub become unavailable, communications between devices via the hub may not be possible.

The inventor has also appreciated problems with the use of cloud services by manufacturers of hubs and device in the loT . Firstly, a manufacturer’s cloud service, which is a network node for all communications involving loT devices made by a manufacturer, represents a single point of network failure and a network bottleneck. Users may therefore lose all loT functionality, or experience a slow service, when the cloud service is subject to heavy data traffic, experiences technical problems or is down for maintenance. Secondly, since all data is sent via the cloud service, the manufacturer who maintains the cloud service has access to all of the data. In some cases this data is stored and mined for further use, and in some cases the Terms of Service require a user to consent to this. Further, while data sent to and from the cloud service may be encrypted using public key encryption techniques, in some cases data stored by the cloud service may be stored in an unencrypted form and be vulnerable to hackers and leaks. The inventor has appreciated that it would be desirable for a user of loT devices to have control of their data and how it is distributed, without losing the loT functionality.

The inventor has further appreciated security issues that can provide third parties with an opportunity to obtain data from loT devices they do not own, or to take control of loT devices they do not own. Referring to the implementation of Figure 2, it is possible for any third party to download the hub manufacturer’s app and to register a user account with the manufacture. If the third party is within range of another person’s home LAN, which may be possible from outside of a house, then in some cases the only things preventing the third party from obtaining complete control of the loT devices are the LAN password and/or hub password. This may not be a significant hurdle in view of the tendency of some people to choose weak passwords. Additionally, loT devices that use the known implementations may be vulnerable to conventional remote hacking techniques.

Embodiments of the inventions described herein address these and other problems. In particular, embodiments described herein provide a system that allows all of a user’s loT devices to be managed through a single user account, and the ownership of new loT devices can be established in a secure and convenient manner. Communications are sent directly between loT devices, and not via a cloud service, giving the user the ability to control how their data is distributed. Further, steps are taken to ensure that all communications between loT devices are encrypted using encryption that is unique to each device pairing, and that cannot practically be derived from outside of the pair of devices. This results in a secure system in which loT devices are highly resistant to hacking.

The scope of protection is defined by the independent claims, to which reference should now be made. Advantageous features are set out in the dependent claims.

Electronic Device

According to a first aspect of the present invention, there is provided an electronic device, connectable to an Internet of Things (loT) device, for managing communications between a connected loT device and other loT devices over a network. The electronic device comprises: a communication interface for communicating with a connectable loT device; a communication interface for communicating with other loT devices over a network connection; a separate communication interface for communicating with other electronic devices over a point-to-point communication link; memory; and processing circuitry communicatively coupled to the memory and the communication interfaces.

An Internet of Things (loT) device is also provided. The loT device comprises: a component configured to generate data and/or a component configured to control one or more operations of the loT device; and the electronic device for managing communications between the loT device and other loT devices over a network. The electronic device and the component are configured to communicate using the communication interface of the electronic device that is for communicating with a connectable loT device. The one or more components may include a sensor or an actuator.

The presence of a communication interface for communicating with other, like electronic devices over a point-to-point communication link, separate from a network interface, provides a number of advantages. These include that security-sensitive information, the knowledge of which could make a connected loT device vulnerable to hacking, never needs to be communicated over a network. Instead, such security-sensitive information can be sent over a separate point-to-point communication link, which by definition can only include two endpoints and is therefore less vulnerable to third parties snooping. This means that, unlike known techniques for sending encrypted communications over networks, which rely on a publicly known encryption key and the sending of secret keys over a public network, the encryption to be used can be derived entirely based on secure point-to-point communications. Additionally, it allows the network interface to be implemented in a straightforward, high assurance manner.

The communication interface for communicating with a connectable loT device and the communication interface for communicating with other loT devices over a network connection can be separate physical interfaces, or can be the same physical interface. Where these two interfaces are separate physical interfaces, the communication interface for communicating with other loT devices over a network connection may be a network interface in the electronic device, such as an Ethernet port, or may be an interface for physically connecting to a data bus of a connectable loT device in order to make use of a network interface of the connectable loT device. Where these two interfaces are the same physical interface, there may be separate logical interfaces for communicating with a connectable loT device and for communicating with other loT devices over a network connection. In this case, since the electronic device has no network interface of its own, it can make use of a network interface of a connectable loT device.

The electronic device may be configured to send only encrypted data over the point-topoint communication link. In this case, the memory of the electronic device may store data for decrypting encrypted data received via the point-to-point communication link, and the processing circuitry may be further configured to use the data to decrypt encrypted data received via the point-to-point communication link. Such data may be preinstalled in the memory of the electronic device and never communicated outside of the electronic device in order to maintain its security. Sending only encrypted data over the point-to-point communication link provides additional security because even if a third party electronic device is able to establish point-to-point communications with the electronic device, and thereby receive security sensitive information over the point-to-point communications link, the received information will be encrypted and the third party will not be able to decrypt it. Even in the event a third party was able to position themselves between the two endpoints, the third party would not be able to decrypt any obtained data.

The data for decrypting data received via the point-to-point communication link may comprise instructions for performing a plurality of different encryption methods. Data sent by the electronic device over the point-to-point communication link may then include an identifier identifying one of the plurality of encryption methods. The identifier may be appended or prepended to the encrypted data. The memory of the electronic device may store data associating each of the plurality of different encryption methods to an identifier, and the processing circuitry may then be configured to use the received identifier to identify an encryption method with which encrypted data received via the point-to-point communication link is encrypted. The use of one of a number of different possible encryption methods adds further security, as additional information beyond the encryption key must be obtained to allow a third party to decrypt data received over the point-to-point communication link.

The electronic device may be configured to send encrypted data in which the encryption key with which the encrypted data is encrypted is embedded. This can improve security because it means that data sent over the point-to-point communication link does not need to be encrypted using a single predefined encryption key, the public knowledge of which would make the devices vulnerable. Additionally, there is no need to implement a separate communications path and/or protocol for the transfer of the encryption key. The memory of the electronic device may store data for recovering an encryption key embedded within encrypted data received via the point-to-point communication link, which the processing circuitry may use to recover the encryption key. Such data can be stored in the permanent memory of the electronic device and never communicated outside of the electronic device in order to maintain their security.

The electronic device may also store instructions for encrypting data before sending it over the point-to-point communication link, and may store instructions for embedding the encryption key within the data. The processing circuitry may then be further configured to use the stored instructions to encrypt data and embed an encryption key within the data before sending the data via the point-to-point communication link. The instructions may be instructions for performing one or more scatter methods. If the electronic device is able to encrypt data and embed an encryption key itself, the electronic device does not send preencrypted data. This means the electronic device can use one of a large number of predefined encryption keys without having to store a large amount of pre-encrypted data, or can use a randomly generated encryption key. This improves the security of the system.

The communication interface for communicating with other electronic devices over a pointto-point communication link may be a wireless communication interface, such as a Near

Field Communication (NFC) interface or a Radio Frequency Identification (RFID) interface. Wireless point-to-point communication interfaces are more convenient and easy to use than wired point-to-point interfaces. Interfaces such as NFC and RFID are advantageously relatively short range, meaning data such as security-sensitive data sent over the point-topoint communication link can only be sent to physically local electronic devices. This improves security as the user of an electronic device has more control over the electronic devices to which security-sensitive data is sent.

The electronic device may be configured to automatically send data to a like electronic device that is in range of the wireless communication interface via the point-to-point communication link. Interfaces such as NFC and RFID also allow a communication link to be established automatically, and data to be sent over the communication link automatically, when sufficiently near to another like electronic device. This makes the electronic devices more convenient to use.

The electronic device may be configured to send only encrypted data over the communication interface for communicating with other loT devices over a network connection. This improves the security of data that is sent over a network, which could potentially be received or intercepted by a third party which the user of the electronic device does not wish to have access to the data. If the data is encrypted, such a third party cannot access the data unless it is able to decrypt it. However, the presence of the separate communication interface for communicating with other electronic devices over a point-to-point communication link allows security-sensitive data to be exchanged by devices without it ever being sent over a network, and therefore such a third party should never have access to data necessary to decrypt encrypted data sent via the communication interface for communicating with other loT devices over a network connection. This makes it extremely difficult for a third party to obtain the necessary information.

The memory may store one or more encryption keys, each associated with a network address. The electronic device may then be configured to encrypt or decrypt data using a respective encryption key when sending or receiving data to or from the respective network address over a network. This allows the electronic device to use encryption that is unique to each device pairing, and since such security-sensitive data can be exchanged via the point-to-point communication link, without communication over a network. This allows for highly secure communications between electronic devices.

The memory may store data comprising data identifying an ownership entity with which the electronic device is registered with a registration entity as being owned. The electronic device may then be configured to send the data identifying the ownership entity to other electronic devices via the point-to-point communication link. Such data can be used to confirm the identity of the ownership entity associated with another electronic device with which the electronic device is communicating over the point-to-point communication link, and in particular to confirm that the ownership entity is the same as the ownership entity receiving the data over the point-to-point communication link.

The data identifying the ownership entity may be a string of sufficient length that each ownership entity can be assigned a unique string. The string may have a length of at least 64 bits, may be a randomly generated string and/or may have been assigned in a random order and not in a numerically consecutive order. Such measures make the string more difficult to guess, making it very difficult for a third party to impersonate another ownership entity.

The memory may store data identifying a network address associated with the registration entity, such as a network address associated with a user account of the ownership entity held with the registration entity. The electronic device may then be configured to send the data identifying the network address associated with the registration entity to other electronic devices via the point-to-point communication link. This allows an electronic device in receipt of data over the point-to-point communication link to initiate an initial communication with the registration entity, which allows an unowned electronic device to be registered with the registration entity as being owned by the ownership entity. Since the data is sent over the point-to-point communication link, the data can be sent securely to prevent third parties attempting to register or promote themselves as being owned by the ownership entity.

The memory may store an encryption key for encrypting data sent to the registration entity over the network during an initial communication with the registration entity. The electronic device may then be configured to send the encryption key to other devices over the pointto-point communication link. As well as ensuring data sent over the network cannot be obtained by third parties, the use of an encryption key can be used by the registration entity as a security factor in the authentication of an electronic device from which it is receiving communications. The memory may store data identifying an encryption method for use with the encryption key, and the electronic device may be configured to send the data identifying the encryption method to other electronic devices via the third communication interface. The use of a specific encryption method can be used by the registration entity as a further security factor in the authentication of an electronic device from which it is receiving communications.

The memory may store data identifying the electronic device, and the electronic device may be configured to send the data identifying the electronic device to other electronic devices via the point-to-point communication link.

The communication interface for communicating with a connectable loT device may be configured to connect to a communication bus of a connectable loT device.

The network may be a public network such as the Internet or a private network such as a Local Area Network (LAN) or Wide Area Network (WAN).

The communication interface for communicating with other loT devices over a network connection may be connected to a network interface of the loT device. Making use of the network interface of the loT device allows for implementations where data can be sent and received over the network without passing through the electronic device. This can allow the loT device to communicate over the network, without the intervention of the electronic device, in all or some circumstances, which may be desirable for reducing computation requirements of the electronic device and/or allowing the loT device to operate as it normally would without the electronic device.

Establishing Ownership

According to a second aspect of the present invention, there is provided a method of establishing ownership of an electronic device. The method comprises: sending ownership data from a first electronic device to a second electronic device over a point-to-point communication link, wherein the first electronic device is registered with a registration entity as being owned by an ownership entity, and the second electronic device is not registered as being owned by the ownership entity, and wherein the ownership data comprises data identifying the ownership entity with which the first electronic device is registered as owned, and data identifying a network address of the registration entity; authenticating the ownership data with the registration entity, wherein authenticating the ownership data comprises sending data from the second electronic device to the registration entity over a network connection using the data identifying the network address of the registration entity, and receiving data from the registration entity confirming the ownership data has been authenticated; and storing the data identifying the ownership entity at the second electronic device.

An electronic device is also provided. The electronic device comprises: a communication interface for communicating with other electronic devices over a network; a separate communication interface for communicating with other electronic devices over a point-topoint communication link; and memory. The electronic device is configured to: receive ownership data from another electronic device over the point-to-point communication link, wherein the ownership data comprises data identifying an ownership entity with which the other electronic device is registered as owned with a registration entity, and data identifying a network address of the registration entity; authenticate the ownership data with the registration entity, wherein authenticating the ownership data comprises sending data from the electronic device to the registration entity over a network connection using the data identifying the network address of the registration entity, and receiving data from the registration entity confirming the ownership data has been authenticated; and store the data identifying the ownership entity in the memory.

Another electronic device is also provided. The electronic device comprises: a communication interface for communicating with other electronic devices over a point-topoint communication link; and memory storing ownership data, the ownership data comprising data identifying an ownership entity with which the electronic device is registered as owned with a registration entity, and a network address of the registration entity. The electronic device is configured to: send the ownership data to another electronic device over the point-to-point communication link so that the other electronic device can authenticate the ownership data with the registration entity.

A system is also provided. The system comprises a plurality of electronic devices, wherein each of the plurality of electronic devices are registered with a registration entity as being owned by a common ownership entity, and wherein the ownership of the plurality of electronic devices has been established in accordance with the method of establishing ownership of an electronic device.

A computer system comprising one or more computers is also provided. The computer system is configured to authenticate data received from electronic devices over a network and to establish ownership of the electronic devices in accordance with the method of establishing ownership of an electronic device.

Sending the data identifying the network address associated with the registration entity, which is necessary to register an unowned electronic device with a network-based registration entity, via a point-to-point communication link provides a secure and convenient way of propagating the ownership of one electronic device to another electronic device. By definition, a point-topoint communication link can only include two endpoints and is therefore less vulnerable to third parties snooping to obtain the information.

The ownership data sent from the first electronic device to the second electronic device may further comprise an encryption key, and the data sent from the second electronic device to the registration entity may then comprise data encrypted using the encryption key. In this case, authenticating the ownership data may further comprise the registration entity being able to decrypt the encrypted data. Sending encrypted data over a network advantageously improves security, since third parties in receipt of the data cannot recover the data without access to the encryption key. Additionally, since the second electronic device is not associated with any ownership entity, and has therefore not been involved in any communications with the registration entity over the network in order to establish an encryption key, the use of the encryption key in the method of establishing ownership acts as a security factor. In other words, only an electronic device that has been involved in a point-to-point communication with another electronic device that is associated with a specific ownership entity, and therefore has knowledge of the encryption key, could have acquired the encryption key. Therefore, the use of the encryption key is a security factor in the authentication of the second electronic device’s request to be registered as owned by the ownership entity.

The ownership data sent from the first electronic device to the second electronic device may further comprise data identifying an encryption method with which to encrypt the data using the encryption key. In this case the data from the second electronic device to the registration entity may be encrypted using the encryption key and the identified encryption method. The use of a specific encryption method, as well as the encryption key, provides additional security and provides an additional security factor in the authentication of the second electronic device’s request to be registered as owned by ownership entity.

The second electronic device may use instructions stored in its memory to perform the identified encryption method. Pre-loading such instructions in the memory of electronic devices helps preserve the secret nature of the encryption methods, as they never have to be transferred outside the bounds of an electronic device.

The ownership data sent from the first electronic device to the second electronic device may be sent in an encrypted form, and the second electronic device may decrypt the encrypted ownership data received from the first electronic device. Sending the ownership data in an encrypted form helps preserve the secret nature of the ownership data, and therefore helps prevent third parties making fraudulent requests to register ownership with the registration entity.

An encryption key used to encrypt the encrypted ownership data received from the first electronic device may be embedded within the encrypted ownership data received from the first electronic device, and the second electronic device may recover this encryption key from the received data. By sending the encryption key hidden within the encrypted data, the second electronic device does not need prior knowledge of the encryption key. This reduces the amount of security sensitive information that needs to be pre-loaded to the memory of electronic devices, and allows randomly generated or unique encryption keys to be used to encrypt the data that is communicated over the point-to-point communication link.

The second electronic device may use instructions stored in its memory to recover the encryption key embedded within the encrypted ownership data. The instructions may be instructions for performing one of one or more predefined scatter methods. By preloading such instructions into the memory of electronic devices, the encryption key can be embedded in a complex manner that can be practically unrecoverable for a third party that is not in possession of the instructions.

The encrypted ownership data may be encrypted using an encryption method, and the second electronic device may use instructions stored in its memory for performing the encryption method to decrypt the encrypted ownership data.

The communicated encrypted ownership data may include an identifier that identifies the encryption method used to encrypt the ownership data from amongst a plurality of possible encryption methods, and the second electronic device may use the identifier to identify the encryption method from amongst a plurality of encryption methods stored in its memory. The identifier may be appended or prepended to the encrypted data. Making multiple different encryption methods available makes it even more difficult for third parties to decrypt the ownership data. Further, since different encryption methods can be associated with different encryption key lengths, the second electronic device may use the identifier to identify the length of the encryption key, which adds a further security factor to the recovery of the embedded encryption key.

The point-to-point communication interface may be provided by a wireless communication interface, such as a Near Field Communication (NFC) interface or a Radio Frequency Identification (RFID) interface. Wireless point-to-point communication interfaces are more convenient and easy to use than wired point-to-point interfaces. Interfaces such as NFC and RFID are advantageously relatively short range, meaning data such as securitysensitive data sent over the point-to-point communication link can only be sent to physically local electronic devices. This improves security as the user of an electronic device has more control over the electronic devices to which security-sensitive date is sent.

The data sent from the second electronic device to the registration entity over the network connection may comprise the data identifying the ownership entity with which the first electronic device is registered as owned. In this case, authenticating the ownership data may further comprise the registration entity comparing the received data to a version of the same data stored by the registration entity. Since the data identifying the ownership entity is sent via the point-to-point communication link of an electronic device, it can only be known by an electronic device that has been involved in a point-to-point communications with an electronic device associated with the ownership entity. This means that the data identifying the ownership entity can be used as a further security factor in the authentication of the second electronic device’s request to be registered as owned by the ownership entity.

The data identifying the ownership entity may be a string of sufficient length that each ownership entity can be assigned a unique string. The string may have a length of at least 64 bits, may be a previously randomly generated string and/or may have been assigned in a random order and not in a numerically consecutive order. Such measures make the string difficult to guess, making it very difficult for a third party to impersonate another ownership entity.

The data sent from the second electronic device to the registration entity over the network connection may comprise data identifying the second electronic device, and the registration entity may use the data identifying the second electronic device and data stored by the registration entity to determine whether the second electronic device has been reported as lost or stolen.

The ownership data sent to the second electronic device may comprise data identifying the first electronic device, and the data sent from the second electronic device to the registration entity over the network connection may comprise the data identifying the first electronic device. The registration entity may then use the data identifying the first electronic device and data stored by the registration entity to determine whether the first electronic device has been reported as lost or stolen.

The ownership data sent to the second electronic device may comprise data identifying the registration entity, and the data received by the second electronic device from the registration entity may comprise data identifying the registration entity. In this case, the second electronic device may authenticate the registration entity by comparing the data identifying the registration entity received from the first electronic device and the data identifying the registration entity received from the registration entity. The use of such data helps prevent a third party from impersonating the registration entity.

The second electronic device may perform one or more authentication steps, such as entering a personal identification number (PIN) associated with the ownership entity and/or entering an authentication code associated with the second electronic device. Such authentication steps prevent third parties from adding the ownership of a device they possess but do not own to an electronic device with no registered ownership, and prevent third parties from adding the ownership of their own devices to electronic devices with no registered ownership but which they do not own.

Linking loT Devices

According to a third aspect of the present invention, there is provided a method of establishing communications over a network. The method comprises: receiving ownership data from a second electronic device at a first electronic device over a point-to-point communication link, wherein the ownership data comprises data identifying an ownership entity associated with the second electronic device; comparing data identifying an ownership entity associated with the first electronic device stored in memory of the first electronic device with the data identifying the ownership entity associated with the second electronic device; determining, based on the comparison, whether the ownership entity associated with first electronic device and the ownership entity associated with the second electronic device are the same ownership entity; and communicating with the second electronic device over a network if the ownership entity associated with first electronic device and the ownership entity associated with the second electronic device are the same. Communicating with the second electronic device may comprise sending or receiving data over the network.

An electronic device is also provided. The electronic device comprises: a communication interface for communicating with other electronic devices over a network; a separate communication interface for communicating with other electronic devices over a point-topoint communication link; memory configured to store ownership data, the ownership data comprising data identifying an ownership entity associated with the electronic device; and processing circuitry. The electronic device is configured to: receive ownership data from another electronic device over a point-to-point communication link, the ownership data comprising data identifying an ownership entity associated with the other electronic device; compare the data identifying the ownership entity associated with the electronic device with the data identifying the ownership entity associated with the other electronic device; determine, based on the comparison, whether the ownership entity associated with the electronic device and the ownership entity associated with the other electronic device are the same ownership entity; and communicate with the other electronic device over a network if the ownership entity associated with electronic device and the ownership entity associated with the other electronic device are the same. Communicating with the second electronic device may comprise sending or receiving data over the network

If electronic devices can only communicate over a network if they are verifiably owned by the same ownership entity, a device’s owner can be sure that their data will not be accessed by third parties that do not have their permission to access the data. However, such verification ordinarily requires some initial two-way communication between the two devices over the network in order to determine whether they are commonly owned, and this two-way communication may not be secure. This can leave an electronic device vulnerable to hacking, or to a third party impersonating a device owned by the ownership entity. However, by exchanging the ownership data that is necessary to identify whether the devices are commonly owned over a point-to-point communication link, and not a network, no initial network-based communications are necessary. This means communications between two devices over a network can be established without requiring initial communications over a network.

The first electronic device may obtain an encryption key and encrypt data using the encryption key before sending data to the second electronic device over the network connection. In combination with sending the ownership data that is used to verify the common ownership of the devices over a point-to-point communication link, the use of encryption for communications over the network helps ensure third parties cannot access the ownership entity’s data.

The encryption key may be obtained using the data received from the second electronic device over the point-to-point communication link. The encryption key may be included in the data received from the second electronic device over the point-to-point communication link.

The method may further comprise sending ownership data from the first electronic device to the second electronic device over the point-to-point communication link, in which case the encryption key may be obtained using the data sent to the second electronic device over the point-to-point communication link. The ownership data sent from the first electronic device to the second electronic device over the point-to-point communication link may include the encryption key.

Encrypting the data using the encryption key may comprise using a predefined encryption method stored in memory of the first electronic device. The predefined encryption method may be one of a plurality of predefined encryption methods stored in memory of the first electronic device.

The method may further comprise obtaining an encryption method identifier from the data received from the second electronic device over the point-to-point communication link. In this case, encrypting data using the encryption key may comprise using one of a plurality of predefined encryption methods stored in memory of the first electronic device, the encryption method used corresponding to the obtained encryption method identifier. Alternatively, the data sent to the second electronic device over the point-to-point communication link may include an encryption method identifier. In this case, encrypting data using the encryption key may comprise using one of a plurality of predefined encryption methods stored in memory of the first electronic device, the encryption method used corresponding to the encryption method identifier.

The association between the electronic devices and the ownership entity may include that the electronic devices are registered with a registration entity as being owned by the ownership entity.

The data identifying the ownership entity associated with the first electronic device may be a string having at least 64 bits, and the data identifying the ownership entity associated with the second electronic device may be a string having at least 64 bits. The strings may have been randomly generated or randomly selected from amongst a predefined number of possible strings. Such a string cannot be practicably be guessed, making it very difficult to a third party to impersonate another ownership entity.

The ownership data received from the second electronic device may comprise a network address of the second electronic device. This allows the first electronic device to locate the second electronic device on the network, and may allow devices to be addressable without the need to find the address in a public Domain Name System (DNS), making it more difficult for third parties to communicate with the electronic devices.

The ownership data received over the point-to-point communication link may be encrypted, and the first electronic device may decrypt the encrypted ownership data. Communicating the ownership data over the point-to-point communication link in an encrypted form provides additional security because even if a third party electronic device is able to establish point-to-point communications with the electronic device, and thereby receive security sensitive information over the point-to-point communications link, the received information will be encrypted and the third party will not be able to decrypt it. Even in the event a third party was able to position themselves between the two endpoints, the third party would not be able to decrypt any obtained data.

An encryption key used to encrypt the ownership data received over the point-to-point communication link may be embedded within the encrypted ownership data, and the first electronic device may recover the encryption key from the encrypted ownership data. This can improve security because it means that data sent over the point-to-point communication link does not need to be encrypted using a single predefined encryption key, the public knowledge of which would make the devices vulnerable. The memory of the electronic device may store instructions for recovering an encryption key embedded within encrypted data received via the point-to-point communication link, which the processing circuitry may use to recover the encryption key. The instructions may be instructions for performing one of one or more predefined scatter methods stored in the memory. Such instructions can be stored in the permanent memory of the electronic device and never communicated outside of the electronic device in order to maintain their security.

The encrypted ownership data may be encrypted using an encryption method, and the first electronic device may use instructions stored in its memory to decrypt the encrypted ownership data. The encryption method used to encrypt the ownership data may be one of a plurality of encryption methods for which instructions are stored in memory of the first electronic device. An identifier identifying the encryption method may be included in the transferred data, and wherein the first electronic device uses the identifier to identify the encryption method from amongst the plurality of encryption methods. The use of one of a number of different possible encryption methods adds further security, as additional information beyond the encryption key must be obtained to allow a third party to decrypt data received over the point-to-point communication link.

The first electronic device may authenticate a user of the first electronic device by requesting a personal identification number (PIN) associated with the ownership entity.

The point-to-point communication link may be provided by a wireless communication interface, such as an NFC or RFID communication interface. Wireless point-to-point communication interfaces are more convenient and easy to use than wired point-to-point interfaces. Interfaces such as NFC and RFID are advantageously relatively short range, meaning data such as security-sensitive data sent over the point-to-point communication link can only be sent to physically local electronic devices. This improves security as the user of an electronic device has more control over the electronic devices to which securitysensitive date is sent.

The first and/or second electronic devices may be connected to a communication bus of an loT device, and the first/second electronic device may send data received from their loT device via the communication bus to the other of the first and second electronic device over the network. The first/second electronic device may also receive data from the other of the first and second electronic device over the network and send the received data to their respective loT device via the communication bus. The received data may be command data.

The network may be a public network such as the Internet or a private network such as a Local Area Network (LAN).

Encrypted Data Transfer

According to a fourth aspect of the present invention, there is provided a method of establishing encrypted communications between electronic devices over a network. The method comprises: sending data from a first electronic device to a second electronic device over a point-to-point communication link, the data comprising encrypted data and a first encryption key embedded within the encrypted data, wherein the embedded first encryption key is an encryption key used to encrypt the encrypted data, and wherein the encrypted data comprises, in an encrypted form, a second encryption key or data from which a second encryption key can be obtained; and using, at the first electronic device, the second encryption key supplied within the encrypted data sent to the second electronic device, for communicating with the second electronic device over a network connection.

This provides a secure way, involving a single transfer of data over a point-to-point communication link, of establishing encrypted communications over a network without having to rely to transmission of an encryption key in an unencrypted form, and without having to rely on any public key. Since the second encryption key is sent in an encrypted form, and is sent over a point-to-point communication link which by definition can only include two endpoints and is therefore less vulnerable to third parties snooping, it is very difficult for third parties to obtain the encryption key,

The first electronic device may comprise memory storing instructions for embedding an encryption key within encrypted data. The instructions may be instructions for performing one of one or more predefined scatter methods stored in the memory. By preloading such data into the memory of electronic devices, the encryption key can be embedded in a complex manner that can be practically unrecoverable for a third party that is not in possession of the instructions.

The first electronic device may comprise memory storing instructions for performing one or more encryption methods, and the encrypted data sent from the first electronic device to the second electronic device may be encrypted using one of the encryption methods and the first encryption key. The use of one of a number of different possible encryption methods adds further security, as knowledge of the encryption key alone does not allow a third party to decrypt data received over the point-to-point communication link.

The data sent from the first electronic device to the second electronic device may comprise an identifier for the encryption method with which the encrypted data is encrypted using the first encryption key. The identifier may identify the length of the first encryption key and/or a scatter method used to embed the first encryption key within the encrypted data. The identifier may be appended or prepended to the encrypted data. The use of different length encryption keys and/or different scatter methods adds further security factors in the exchange of data over the point-to-point communication link.

The encrypted data may comprise, in an encrypted form, data uniquely identifying the first electronic device, data identifying a network address of the first electronic device, and/or data identifying an ownership entity associated with the first electronic device.

Using the second encryption key for communicating with the second electronic device over a network connection may comprise sending encrypted data to the second electronic device over the network connection, the encrypted data having been encrypted using the second encryption key.

Using the second encryption key for communicating with the second electronic device over a network connection may comprise receiving encrypted data from the second electronic device over the network connection and decrypting the received data using the second encryption key.

The encrypted data sent to or received from the second electronic device over the network may comprise, in an encrypted form, an encryption key to use during a future communication session between the first and second electronic devices over the network. This allows a different encryption key to be used for each new communication session, thereby increasing security.

The encrypted data may further comprise an identifier for an encryption method with which the second encryption key is to be used, the encryption method being one of a plurality of different encryption methods for which instructions are stored in memory of the first electronic device. In this case, using the second encryption key for communicating with the second electronic device over a network connection may comprise using both the second encryption key and the encryption method with which the second encryption key is to be used.

The method may further comprise: receiving data from the second electronic device over the point-to-point communication link, the data comprising encrypted data and a third encryption key embedded within the encrypted data, wherein the embedded third encryption key is an encryption key used to encrypt the received encrypted data; recovering the embedded third encryption key from the received data using data stored in the memory of the first electronic device; and decrypting the encrypted data using the recovered third encryption key.

The memory may store instructions for performing one or more encryption methods, and the first electronic device may decrypt the encrypted data received from the second electronic device using one of the encryption methods and the third encryption key.

The data received from second electronic device may comprise an identifier for the encryption method with which the encrypted data is encrypted using the third encryption key, and the first electronic device may use the identifier to identify the encryption method from amongst a plurality of encryption methods. The identifier may identify the length of the third encryption key and/or a scatter method used to embed the third encryption key within the encrypted data, and the first electronic device may use the identified length and/or scatter method to recover the third encryption key. The identifier may be appended or prepended to the encrypted data.

The encrypted data received from the second electronic device over the point-to-point communication link may comprise, in an encrypted form, data uniquely identifying the second electronic device, data identifying a network address of the second electronic device and/or data identifying an ownership entity associated with the second electronic device. The inclusion of data identifying a network address allows the first electronic device to locate the second electronic device on the network easily, and may allow devices to be addressable without the need to find the address in a public Domain Name System (DNS), making it more difficult for third parties to communicate with the electronic devices.

The method may further comprise comparing, by the first electronic device, the data identifying the ownership entity associated with the second electronic device and data identifying the ownership entity associated with the first electronic device that is stored in memory of the first electronic device, and sending encrypted data, encrypted using the encryption key, to the second electronic device over the network connection in response to the determining that the ownership entity associated with the first electronic device is the same as the ownership entity associated with the second electronic device.

A further method of establishing encrypted communications between electronic devices over a network according to the fourth aspect of the present invention is also provided, comprising: receiving data from a first electronic device at a second electronic device over a point-to-point communication link, the data comprising encrypted data and a first encryption key embedded within the encrypted data, wherein the embedded first encryption key is an encryption key used to encrypt the encrypted data, and wherein the encrypted data comprises, in an encrypted form, a second encryption key or data from which a second encryption key can be obtained; recovering the embedded first encryption key from the received data using data stored in the memory of the second electronic device; decrypting the encrypted data using the recovered first encryption key; obtaining the second encryption key from the decrypted data; and using, at the second electronic device, the second encryption key for communicating with the first electronic device over a network connection.

The memory may store instructions for performing one or more encryption methods, and the second electronic device may use one of the encryption methods to decrypt the encrypted data using the recovered first encryption key.

The data received from the first electronic device may comprise an identifier for the encryption method with which the encrypted data is encrypted using the first encryption key, and the second electronic device may use the identifier to identify the encryption method from amongst a plurality of encryption methods. The identifier may identify the length of the first encryption key and/or a scatter method used to embed the third encryption key within the encrypted data, and the second electronic device may use the identified length and/or scatter method to recover the first encryption key. The identifier may be appended or prepended to the encrypted data.

The encrypted data may comprise, in an encrypted form, data uniquely identifying the first electronic device, data identifying a network address of the first electronic device and/or data identifying an ownership entity associated with the first electronic device.

The method may further comprise: comparing, by the second electronic device, the data identifying the ownership entity associated with the first electronic device and data identifying the ownership entity associated with the second electronic device that is stored in memory of the second electronic device, and sending encrypted data, encrypted using the second encryption key, to the first electronic device over the network connection in response to the determining that the ownership entity associated with the first electronic device is the same as the ownership entity associated with the second electronic device.

Using the second encryption key for communicating with the first electronic device over a network connection may comprise sending encrypted data to the first electronic device over the network connection, the encrypted data having been encrypted using the second encryption key.

Using the second encryption key for communicating with the first electronic device over a network connection may comprise receiving encrypted data from the first electronic device over the network connection and decrypting the received data using the second encryption key.

The encrypted data sent to or received from the first electronic device over the network may comprise, in an encrypted form, an encryption key to use during a future communication session between the first and second electronic devices over the network.

The encrypted data may further comprise an identifier for an encryption method with which the second encryption key is to be used, the encryption method being one of a plurality of different encryption methods for which instructions are stored in memory of the second electronic device. In this case, using the second encryption key for communicating with the first electronic device over a network connection may comprise using both the second encryption

The method may further comprise: sending data to the first electronic device over the pointto-point communication link, the data comprising encrypted data and a third encryption key embedded within the encrypted data, wherein the embedded third encryption key is an encryption key used to encrypt the sent encrypted data.

The memory may stores instructions for performing one or more encryption methods, and the second electronic device may use one of the encryption methods and the third encryption key to encrypt the encrypted data sent to the first electronic device.

The data sent to the first electronic device may comprise an identifier for the encryption method with which the encrypted data is encrypted using the third encryption key. The identifier may identify the length of the third encryption key and/or a scatter method used to embed the third encryption key within the encrypted data. The identifier may be appended or prepended to the data encrypted data.

The encrypted data sent to the first electronic device over the point-to-point communication link may comprise, in an encrypted form, data uniquely identifying the second electronic device, data identifying a network address of the second electronic device and/or data identifying an ownership entity associated with the second electronic device.

An electronic device is also provided, comprising: a communication interface for communicating with other electronic devices over a network; a separate communication interface for communicating with other electronic devices over a point-to-point communication link; memory; and processing circuitry. The electronic device is configured to perform the methods of establishing encrypted communications between electronic devices over a network.

The point-to-point communications link may be a wireless communications link, such as an NFC communications link or a RFID communications link.

Wireless point-to-point communication interfaces are more convenient and easy to use than wired point-to-point interfaces. Interfaces such as NFC and RFID are advantageously relatively short range, meaning data such as security-sensitive data sent over the third communication interface can only be sent to physically local electronic devices. This improves security as the user of an electronic device has more control over the electronic devices to which security-sensitive date is sent.

Embedding and Recovering an Encryption Key

According to a fifth aspect of the present invention, there is provided a method of forming encrypted data. The method comprises forming a data package; encrypting data of the data package using an encryption key to form encrypted data; embedding the encryption key within the encrypted data; and adding information to the encrypted data indicating how to recover the encryption key from the encrypted data.

A method of decrypting encrypted data is also provided. The method comprises using information provided with the encrypted data to determine how to recover an encryption key embedded within the encrypted data; recovering the encryption key from the encrypted data; and decrypting the encrypted data using the recovered encryption key.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail, by way of example, with reference to the accompanying drawings, in which:

Figure 1 (prior art) is a schematic diagram illustrating the transfer of data between two loT devices;

Figure 2 (prior art) is a schematic diagram illustrating the transfer of data between two loT devices;

Figure 3 is schematic diagram illustrating the secure transfer of data between two loT devices in accordance with an aspect of the present invention;

Figure 4 is a schematic diagram illustrating how an ownership entity registers a user account with a registration entity;

Figure 5 is a schematic diagram of an electronic device for managing communications between a connected loT device and other loT devices over a network;

Figure 6 is a schematic diagram showing the electronic device of Figure 5 connected to an loT device;

Figure 7 is a schematic diagram showing the electronic device of Figure 5 connected to an loT device;

Figure 8 is a schematic diagram showing another embodiment in which the electronic device is connected to an loT device;

Figure 9 is a more detailed schematic diagram of the electronic device of Figure 5;

Figure 10 is schematic diagram illustrating how ownership of an electronic device is established in accordance with an aspect of the present invention;

Figure 11 is a sequence diagram illustrating a method of establishing the ownership of an electronic device in accordance with an aspect of the present invention;

Figure 12 is a schematic diagram illustrating how ownership of an electronic device is established in accordance with an aspect of the present invention;

Figure 13 is a schematic diagram illustrating a linkage procedure for linking two electronic devices owed by the same ownership entity so that they can communicate over a network;

Figure 14 is a sequence diagram illustrating a linkage procedure for linking two electronic devices owned by the same ownership entity so that they can communicate over a network;

Figure 15 is a sequence diagram illustrating how two linked loT devices communicate securely over the Internet;

Figure 16A is an example of an encryption method table for use in securely sending data over a point-to-point communication link;

Figure 16B is an example of a scatter table for use in securely sending data over a point-topoint communication link;

Figure 17 is a flow diagram illustrating a method of forming data to be sent from one electronic device to another over a point-to-point communication link; and

Figure 18 is a flow diagram illustrating a method of embedding an encryption key within an encrypted data package.

In the drawings, like parts are denoted by like reference numbers.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Electronic Device

By way of an initial overview, Figure 3 illustrates the transfer of data between two loT devices 10, 20 in accordance with embodiments of the invention. It will be appreciated by comparison with Figures 1 and 2 that, according to the invention, data is sent directly between the loT devices 10, 20 over the Internet, and not via a third party intermediary such a cloud service or a hub. As with all communications over the Internet, data may be transferred via intermediate relay nodes such as network routers and network switches which route data from its origin to its destination, but according to the invention the data is not routed via an intermediate third party such as a cloud service.

With reference to Figure 3, the first loT device 10 includes an electronic device 30a for managing communications over the Internet between the first loT device 10 and other loT devices, such as the second loT device 20. Likewise, the second loT device 20 includes an electronic device 30b for managing communications over the Internet between the second loT device 20 and other loT devices, such as the first loT device 10.

There is a one-to-one correspondence between electronic devices such as electronic devices 30a, 30b and their respective loT devices 10, 20. That is, the nature of the connection between an loT device 10, 20 and its electronic device 30a, 30b is such that the electronic devices may be viewed as part of their respective loT device. For example, the electronic devices 30a, 30b may be integral with, or physically connected to, their respective loT devices 10, 20, having been connected either during or after the manufacture of the loT devices. An loT device 10, 20 is not connected to its electronic device 30a, 30b via a network.

As will be explained in more detail below with references to Figures 5 to 18, the electronic devices 30a, 30b manage communications between their respective loT devices 10, 20 and other loT devices over networks by managing if, and what, data generated by their loT devices can be sent over a network to other loT devices. Likewise, they manage if, and what, data received over a network can be communicated to their loT device. In particular, the electronic devices 30a, 30b ensure that, where a user’s ownership of the loT device 10, 20 has been registered with a registration entity, the user’s data can only be transferred between pairs of loT devices which are owned by the same user or ‘ownership entity’, that is the entity associated with the user when a device is registered with the registration entity, and which have undergone a “linkage procedure” linking the pairs of devices. Linked devices are able to communicate directly, using encryption that is unique to the pairing of the devices, using “linkage data” established during the linkage procedure. The linkage procedure is described in more detail below with reference to Figures 13 and 14.

Through these procedures and the configuration of the electronic devices 30a, 30b, where an ownership entity has registered its ownership of the devices, any attempted communications with their respective loT devices 10, 20 over the Internet do not result in data being transferred to or from the loT devices 10, 20, unless the devices are commonly owned and have been linked using the linkage procedure.

It should be appreciated that while the Figures show loT devices 10 and 20 as a smartphone and a fridge, this is merely for illustrative purposes. The loT devices 10, 20 could be any loT devices, such as cars, smart home devices such as lighting, heating, air conditioning and security systems, or general purpose computers such as tablets, laptops and desktop computers.

Also by way of an initial overview, Figure 4 illustrates a process by which an ownership entity 50, such a person or organisation that owns one or more loT devices, registers a user account with a registration entity 40. The registration entity 40 will be referred to herein as an ‘ownership service provider’ 40, and the user account will be referred to herein as an ‘ownership account’.

In order to register an ownership account, the ownership entity 50 accesses a computer platform implemented by the ownership service provider 40, for example a website on the Internet. The ownership entity uses the platform to provide their personal details such as their name, address and other contact details, and may also choose identifiers such a username, a password and a personal identification number (PIN). The ownership service provider 40 creates an account with a ownership account number (such as a relatively short numerical string) and stores the user’s details.

In addition, the ownership service provider 40 assigns a special identification string, which for ease of reference will be referred to herein as the ‘ownership ID’. The ownership ID, rather than being a simple identifier such as the account number, is a preferably long sequence that cannot in any practical way be ‘guessed’, for example using a brute force method. The ownership ID may be randomly selected from amongst a very large number of possible ownership IDs such that the particular ID being used cannot be guessed. By way of a specific example, the ownership ID may be randomly selected from amongst all possible 32, 64 or 128-bit strings. A longer string provides greater security because it is more difficult to guess, and the number of possible strings, defined by the length of the ownership ID, should be at least large enough that the assigned ownership ID is unique for each ownership entity. As will be explained in more detail below, the ownership ID is a secret string that it used to establish and maintain the ownership of loT devices that are owned by the ownership entity, and is used to establish direct and secure communications between loT devices over a network.

In addition, the ownership service provider assigns a network address, such as a Uniform Resource Identifier (URI) or an IP address, that is unique to the ownership entity’s ownership account. It further generates an encryption key and selects an encryption method from amongst a number of predefined available encryption methods or algorithms. As will be explained below with reference to Figures 10 to 12, this network address, encryption key and encryption method allows for an initial communication between an loT device and the ownership service provider 40 for the purposes of establishing the ownership of an unowned loT device.

Finally, the ownership service provider 40 assigns a further identifier, which for ease of reference will be referred to herein as the ‘chip ID of the ownership account’. As will be explained in more detail below, the chip ID of the ownership account may be used to verify communications sent between loT devices and the ownership service provider 40.

The ownership account forms a data package of the assigned account data. In one embodiment the data package contains the ownership account number, the ownership ID, the chip ID of the ownership account, the network address of the ownership account, the encryption key and an encryption method identifier, such as a flag indexed to a look-up table of encryption methods. However, not all of this data is necessarily included in this data package; the data package may include additional data, less data, and different combinations of data. In one example, the data package only includes the ownership ID, the network address and the encryption key and encryption method identifier.

As will be explained in more detail with reference to Figure 12, the data package is stored in an encrypted form in the memory of a ‘seed device’ 60 that is provided to the ownership entity 50, for example by sending the seed device 60 to the ownership entity 50 by mail.

The ownership service provider 40 may be implemented as a cloud service using servers on the Internet, and that loT devices will be connected to the Internet. However, embodiments described herein can also be implemented on networks other than the Internet, including public and private networks, for example LANs or WANs, which may not connected to the Internet. In this case, the ownership service provider may be implemented as a server on a LAN or WAN, managed by a network administrator, and networked loT devices are able to provide their normal loT functionality, but limited to communications over the LAN or WAN. The term ‘network’ is therefore used herein not just to refer to the Internet, but also LANs, WANs and other kinds of public and private networks.

Figure 5 shows an electronic device 30, as per the electronic devices 30a, 30b of Figure 3, in accordance with embodiments of the invention. The electronic device 30 of Figure 5 is implemented as a system on a chip (SoC) and, for ease of reference, will be referred to as an Ownership chip’. However, it should be appreciated that the electronic device 30 could be implemented in other ways, and does not need to be a SoC.

The ownership chip 30 includes a local interface 31, a network interface 32 and a near field communication (NFC) interface 33, as well as memory 34 and processor(s) 35. Figure 5 shows the memory 34 as a single block and shows a single processor 35, but it will be appreciated that this is for ease of explanation and that any suitable combination of processing circuitry and memory can be used.

The local interface 31 provides the ownership chip 30 with an interface to the components of a connected loT device, such as sensors that generate data, actuators that can control operations of the loT device, and software running on the loT device. The local interface 31 therefore physically allows the ownership chip 30 to receive data from, and transmit data to, components of a connected loT device. As explained above, the connection between an ownership chip and the connected loT device is such that there is a one-to-one correspondence between ownership chips and loT devices. A single ownership chip does not serve multiple loT devices.

The network interface 32 provides the ownership chip with an interface to external, networked resources, including other ownership chips connected to other loT devices. This allows the ownership chip 30 to receive data from, and to transmit data to, other loT devices over a network such as the Internet. The network interface 32 can be a wired network interface, a wireless network interface, or both may be provided. As explained below with reference to Figures 7 and 8, in some embodiments the network interface provides access to external networked resources through a network interface of the connected loT device. Whilst, for ease of explanation, the network interface 32 and the local interface 31 are shown as separate interfaces, the network interface 32 and the local interface 31 may be implemented as a single physical interface.

The NFC interface 33 provides for short-range, point-to-point, wireless communications with other NFC-enabled devices, including like devices, in particular other ownership chips. When the ownership chip 30 is placed sufficiently close to another NFC enabled device such as an ownership chip, the ownership chip 30 automatically initiates NFC communication with the other NFC enabled device.

While the ownership chip 30 of Figure 5 uses an NFC interface, other interfaces such as RFID could be used, and it will be appreciated that an NFC interface is able to receive data from both NFC and RFID senders. NFC and RFID are preferred because they are wireless, automatic, easy to use and cheap to implement, but other interfaces, including wired interfaces, could also be used. What is important is that the interface provides point-topoint communications. Interfaces that provide networked communications, such as WiFi and ZigBee (Registered Trade Mark) provide networked communications and are therefore not point-to-point.

The memory 34 stores data that is used by the processor(s) 35 to recover, for example decrypt, data received by the ownership chip 30 via the NFC interface 33 or network interface 32. In particular, the memory 34 stores instructions for performing one or more encryption methods, one or more encryption method tables indexing the encryption methods, and one or more scatter tables, for recovering useful data from data received by the ownership chip via the NFC interface 33 or network interface 32. Such data can be preloaded to the memory 34 of the ownership chip 30 during manufacture, and is never communicated outside the ownership chip 30 via any of the communication interfaces 31, 32, 33. A detailed example of decrypting data received over the NFC interface using such pre-loaded data is given below with reference to Figures 16 to 18.

The memory 34 also stores Ownership data’, which includes data identifying the ownership entity 50 with which the ownership chip 30 (and by association, the loT device to which the ownership chip is connected) is registered as owned with the ownership service provider 40. This includes the ownership ID, a network address of the ownership account and an encryption key and encryption method identifier to be used during communications between loT devices and the ownership service provider 40. It may also include data such as the ownership account number and the chip ID of the ownership account, which may be used for authentication purposes in some embodiments of the inventions described herein. As will be explained in more detail with reference to Figures 10 to 12, this data is stored after manufacture, during a process of establishing the ownership of the loT device to which the ownership chip 30 is connected.

The memory 34 also stores data specific to ownership chip 30 and to the loT device to which it is connected. This includes data such an ownership chip ID which uniquely identifies the ownership chip 30, an loT device ID uniquely identifying the loT device, and a network address of the ownership chip 30. This data may be stored in the memory 34 during the manufacture and initial configuration of the ownership chip 30 and the loT device to which it is connected. Some data, for example the network address of the ownership chip 30, may not be allocated until a later stage.

The ownership chip 30 is configured to automatically send data including an encrypted data package to another ownership chip via the NFC interface when another ownership chip is placed sufficiently close to the ownership chip 30 to initiate NFC communication. The encrypted data package may be stored in the ownership chip in its encrypted form, or may be stored in an unencrypted form and then encrypted by the ownership chip 30 before it is sent. As well as the encrypted data package, the data sent and received via NFC also includes data which, in conjunction with the data preloaded to ownership chips 30 during manufacture or configuration, allows an ownership chip in receipt of such data to recover the contents of the encrypted data package. A detailed example is given below with reference to Figures 16 to 18.

The data package includes ownership data such as the ownership ID, the network address of the ownership account, an encryption key and an encryption method identifier to be used during initial communications between loT devices and the ownership service provide 40. It may also include the chip ID of the ownership chip 30, the ownership account number and the chip ID of the ownership account. All or only some of this data is included in the data package, depending on the desired implementation. For example, the ownership account number and the chip ID of the ownership account may not be included if certain optional verification steps described herein are not used. In another example, there is only one available encryption method, in which case no identifier is necessary. As will be explained in more detail below with reference to Figures 10-14, the ownership chip ID may be used to authenticate an ownership chip, and to derive linkage data for direct, encrypted communications between loT devices over a network.

The memory 34 may also store data that is used by the processor(s) 35 to manage communications between the ownership chip 30 and the loT device to which it is connected via the local interface 31.

Finally, the memory stores linkage data that is used by the processor(s) 35 to manage communication between i) the ownership chip 30 and the ownership service provider 40 via the network interface 32, and ii) between the ownership chip 30 and networked loT devices over a network, via the network interface 32. As will be explained in more detail below, this linkage data includes data for forming a direct, encrypted communication channel with i) the ownership service provider 40; or ii) another loT device over a network. Such data is established i) during the process of establishing ownership of the loT device to which the ownership chip is connected via a process described with reference to Figures 10 to 12; and ii) during a linkage procedure that takes place between loT devices equipped with ownership chips, after ownership of the loT devices has been established, via a linking process described in Figures 13 and 14.

Figure 6 shows the ownership chip 30 connected to an loT device 10 via the local interface 31. The loT device 10 includes memory 101, processor(s) 102, one or more components 103, 104 and a communications bus 100 via which these components 103, 104 and software running on the loT device 10 can communicate with the ownership chip 30 via its local interface 31.

The components 103, 104 of the loT device 10 are hardware and/or software components that are capable of generating data and/or controlling one or more operations of the loT device. That is, the components 103, 104 provide the functionality of sensors that generate data and/or actuators that control operations of the loT device 10. For example, one of the components may be a thermometer that can generate data in the form of a temperature reading. As another example, one of the components may be a camera that can generate data in the form of a camera image, and be controlled by being turned on or off.

The memory 101 of the loT device 10 stores an operating system (OS) of the loT device; software drivers associated with the components 103, 104; data generated by the components; and software applications that gather data from or exert control over one or more of the components. For example, the software drivers, under the control of the OS, may take data generated by sensors of the loT device 10 and store the data in a data store in the memory 101. In order to send data generated by one or more sensors over a network, a software application running on the loT device reads data from the data store and provides it to the ownership chip 30 over the local interface 31. The ownership chip 30 then encrypts the data and sends the encrypted data over the network. Similarly, control commands received by the ownership chip 30 over the network interface 32 may be decrypted by the ownership chip and then communicated to the application over the local interface 31, and the application may then store the control commands in the data store. The software drivers of the components may then read the control commands from the data store, which causes them to execute the control commands.

The memory 101 of the loT device may store data that allows the loT device 10 to download, via the ownership chip 30, the OS. In particular, the ownership chip 30 can be preconfigured so that upon first power up it seeks a network address of a download site for downloading the OS over its local interface 31, for example if the memory 101 does not contain a current version of the OS. The loT device 10 can store such a network address in its memory 101 and provide it to the ownership chip 30 upon request, and the ownership chip 30 downloads the OS using the network address via its network interface 32. The memory 101 can also store data that allows the ownership chip to verify the authenticity of the OS. For example, the manufacturer of the loT device may be registered with the ownership service provider 40 and have a unique manufacturer ID. The loT device 10 can then provide the ownership chip 30 with the manufacturer ID, which the ownership chip 30 can compare to an ID provided with the OS download. In a similar manner, the loT device may download, via the ownership chip 30, software drivers and software applications.

Figure 7 illustrates an alternative embodiment to the embodiment of Figure 6, in which an ownership chip 30 makes use of a network interface 105 of the loT device 10 to which it is connected.

As in Figure 6, the ownership chip 30 sends and receives encrypted data via its network interface 32. However, unlike Figure 6, encrypted data sent via the network interface 32 is sent to the external network via a network interface 105 of the loT device 10. Likewise, encrypted data received via the network interface 32 is first received via the network interface 105 of the loT device.

In this case, the OS, software drivers and software applications that run on the loT device 10 are configured to behave as described above, such that data generated by the components 103, 104 is always communicated to the ownership chip 30 via the local interface 31, and is not sent straight to external networked devices via the network interface 105 of the loT device. Similarly, data received via the network interface 105 of the loT device is routed to the network interface 32 of the ownership chip 30, and not sent straight to the components 103, 104 of the loT device 10. Since the OS, software drivers and software applications can be pre-installed by the manufacturer or downloaded via the ownership chip 30, they can be trusted to behave as intended.

In some embodiments, the OS, software drivers and software applications may be replaced, or their behaviour changed, when an ownership entity’s ownership of the loT device 10 is registered with the ownership service provider 40. For example, when an loT device 10 and the associated ownership chip 30 are not registered as owned by any ownership entity, the OS, software drivers and software applications can be configured to send data directly via the network interface 105 of the loT device, and not via the ownership chip 30. In this way, an loT device 10 with no ownership may behave essentially as loT devices do currently. However, when an ownership entity’s ownership is added, new, trusted software may be installed to the loT device or the software’s behaviour may be changed, under the control of the ownership chip 30, in order to provide the behaviour described above.

In some embodiments, certain components or software applications are allowed to send and/or receive data directly via the network interface 105 of the loT device 10, even when the loT device 10 and the ownership chip 30 are registered as owned by an ownership entity. This may be particularly advantageous where the loT device 10 runs third-party software applications that generate and receive data that a user may not consider to be sensitive, or is not related to the command, control or operational status of the loT device. For example, some loT devices run third party video streaming services such as BBC iPlayer (Registered Trade Mark). Such an application receives video data from a third party server for presentation on a display of the loT device, and generates and sends data in the form of requests to receive particular video data and possibly data relating to a user’s watching habits. It may be preferable not to communicate such data via the ownership chip 30 to reduce the ownership chip’s processing requirements, especially received video data which can be computationally expensive to process but which does not command, control, obtain or alter the operational status of the loT device, and is therefore unlikely to pose a threat to the loT device 10.

Figure 8 illustrates a further alternative embodiment to those shown in Figures 6 and 7, in which, as well as making use of a network interface 105 of the loT device 10 to which it is connected, the ownership chip includes a single physical interface 34 with two logical interfaces in place of separate local and network interfaces 31,32.

In the embodiment of Figure 8, the single physical interface 34 is connected to communication bus 100 of the loT device 10, as per the local interface 31 of Figures 6 and

7. However, in Figure 8, encrypted data that is sent and received via the network interface 105 of the loT device is sent and received over the physical interface 34, and not via a dedicated network interface of the ownership chip 30. To facilitate this, two different logical interfaces are implemented at the single physical interface 34; a first logical interface for communications between the ownership chip 30 and components 103, 104 of and software running on the loT device 10, and a second logical interface for communications between the ownership chip 30 and other network entities over a network connection, via the network interface 105 of the loT device 10. In this case, the ownership chip 30 will see the network interface 105 as another component, but one to which it sends and receives data in the form on the encrypted network traffic.

While Figures 5-8 show an ownership chip 30 and loT device 10 having a relatively small number of functional blocks, this is for ease of explanation. As noted previously, an ownership chip 30 may include more memory and processing blocks for achieving its functional requirements, and similarly an loT device may include more memory and processing blocks, as well as more or less components such as sensor and actuator components. To illustrate this, Figure 9 shows the ownership chip 30 of Figure 5-8 in more detail.

As can be seen, the ownership chip 30 of Figure 9 additionally includes a local interface manager 311 for managing communications over the local interface 31, a network interface manager 321 for managing communication over the network interface 32, and an NFC interface manager 331 for managing communications over the NFC interface.

The ownership chip 30 further includes an encryption/decryption unit 36 (which may include sub-functions for key and MAC generation and comparison), a component and application registry 37, a component and application manager 38 and an ownership account manager 39.

The encryption/decryption unit 36 uses the pre-loaded data described above to encrypt data before sending it over the network interface 32 or over the NFC interface 33, and to decrypt data received over the network interface 32 or over the NFC interface 33. A dedicated encryption/decryption unit may be able to handle encryption/decryption operations more efficiently than a general purpose processor, and provide improved security.

The component and application registry 37 and the component and application manager 38 store data relating to the components and applications of the connected loT device 10, and use this data to manage communications with and between the OS, software drivers and software applications of the loT device 10.

Once an ownership entity’s ownership has been installed onto the ownership chip 30, the ownership account manager 39 stores data relating to the ownership account and manages the communications between the ownership account and the ownership chip 30.

It also manages communications between the ownership account and the loT device 10, for example for the download of software.

Establishing Ownership

Figures 10 and 11 illustrate a method for establishing the ownership of an loT device 20 equipped with an ownership chip 30b.

In Figures 10 and 11, a first loT device 10 is equipped with an ownership chip 30a and is already registered with an ownership service provider 40 as being owned by an ownership entity 50. A second electronic device 20 is equipped with an ownership chip 30b, but is not currently registered with the ownership service provider 40 as being owned by any ownership entity. Using the process illustrated in Figures 10 and 11, the ownership of the first loT device 10 is added to the second loT device 20. In other words, the ownership of the first loT device 10 is propagated from the first loT device 10 to the second loT device 20. During this process, the second loT device 20 is registered as owned by the ownership entity 50, and a linkage is established between the second loT device 20 and the ownership service provider 40 that allows for direct, encrypted communication between the second loT device 20 and the ownership service provider 40 using encryption that is unique to the pairing of the second loT device 20 and the ownership service provider 40.

Since the first loT device 10 is already registered with the ownership service provider 40 as owned by the ownership entity 50, the memory of its ownership chip 30a stores ownership data. This includes the ownership ID, the network address of the ownership chip 30, the network address of the ownership entity’s ownership account that is held with and maintained by the ownership service provider 40 and an encryption key and an identifier for an encryption method to use during a communication with the ownership service provider 40. In this example it also includes the ownership account number and the chip ID of the ownership account.

Additionally, the memories of both the first ownership chip 30a and the second ownership chip 30b store data specific to respective ownership chips and connected loT devices. In this example, this includes respective ownership chip IDs and loT device IDs. An loT device ID may be any device identifier, for example a phone’s International Mobile Equipment Identity (IMEI).

To begin the process of propagating the ownership of the first loT device 10 to the second loT device 20, the devices are placed sufficiently close to one another to establish an NFC connection 330 between the NFC interface 33a of the ownership chip 30a of the first loT device 10 and the NFC interface 33b of the ownership chip 30b of the second loT device 20.

With the NFC connection 330 established, the ownership chip 30a of the first loT device 10 automatically sends data (“ADD OWNERSHIP”) to the ownership chip 30b of the second loT device 20, over the point-to-point communication link provided by the NFC connection. The data includes an encrypted data package that includes, in an encrypted form, the ownership ID, the network address of the ownership entity’s ownership account that is held with and maintained by the ownership service provider 40 and an encryption key and an identifier for an encryption method to use during an initial communication with the ownership service provider 40. In this example the encrypted data package also includes, in an encrypted form, the ownership account number, the chip ID of the ownership account and the chip ID of the first ownership chip 30a. The data also includes, embedded within the data, the encryption key with which the encrypted data package is encrypted, and data that allows an ownership chip in receipt of the data package to recover the encryption key and decrypt the encrypted data. An example of how this data can be formed is given below with reference to Figures 16 to 18.

Once this data has been sent from the first ownership chip 30a to the second ownership chip 30b, which occurs almost instantaneously, the first electronic device 10 can be moved away from the second electronic device to close the NFC connection 330.

Since the contents of the data package are encrypted using a secret encryption method and key, were a third party NFC-enabled device that is not an ownership chip to be in receipt of the data, the third party device would not be able to recover the contents of the data package. However, as explained above with reference to Figure 5, and as will be explained in more detail below with reference to Figures 16 to 18, ownership chips such as ownership chip 30b are preloaded with data that allows the ownership chip 30b to recover the secret encryption key and method and therefore decrypt the received data.

Once the second ownership chip 30b has recovered the contents of the data package, the second ownership chip 30b stores the data in its temporary memory for use during the remainder of the process. The second ownership chip 30b then initiates (“REQUEST CONNECTION”) an initial communication with the ownership service provider 40 over the Internet 320 in order to authenticate the data it has received from the first ownership chip 30a. To this end, the second ownership chip 30b uses its network interface 32b, the recovered network address of the ownership account with ownership service provider 40, the recovered encryption key and encryption method identifier, and the preinstalled encryption method instructions to form an initial, encrypted communication channel with the ownership service provider 40 over the Internet 320.

The initial, encrypted communication sent from the second ownership chip 30b to the ownership service provider 40 specifies the ownership ID. In this example it also specifies the chip ID of the first ownership chip 30a, the chip ID of the second ownership chip 30b, the loT device ID of the second loT device 20, and the network address of the second ownership chip 30b.

As explained above with reference to Figure 4, the ownership service provider 40 itself generated the encryption key and selected the encryption method for use in initial communications between loT devices such as device 10, 20 and stored the encryption key and method. The ownership service provider 40 should therefore be able to decrypt this initial communication and recover its contents. If the ownership service provider 40 is unable to decrypt a communication, this suggests a third party may be trying to take advantage of the ownership system, and so the ownership service provider does not respond and the process of adding ownership to the second loT device 20 fails. This use of a secret encryption key and method for initial communications, known only to the ownership service provider 40 and ownership chips registered as owned by the ownership entity 50 (or ownership chips such as the ownership chip 30b which is in the process being registered), acts as a security factor in the process of adding ownership to an loT device 20/ownership chip 30b.

If the ownership service provider 40 is able to decrypt the initial communication, it performs several checks on the recovered contents.

The ownership service provider 40 verifies that the ownership ID recovered from the initial communication matches the ownership ID it has stored for the ownership account. Since the ownership ID is a secret string that cannot in any practical way be guessed, verification of the ownership ID serves as a second security factor in the process of adding ownership to an loT device 20. The use of two security factors, as well as the use of encrypted communications over both NFC and the Internet, makes it difficult for a third party to take advantage of the ownership system described herein.

The ownership service provider 40 can also perform checks on the ownership chip ID of the first ownership chip 30a and the ownership chip ID of the second ownership chip ID 30b. For example, the ownership service provider 40 could implement a system which allows ownership entities to report their loT devices as lost or stolen. In this case, the ownership service provider could prevent ownership being added from the first loT device 10 to the second loT device 20 if either has been reported lost or stolen.

After performing these checks, the ownership service provider 40 responds to the second ownership chip 30b with a first acknowledgement (“ACK”). The first ACK contains a new encryption key to use in the next communication session with the ownership service provider 40, and an identifier for an encryption method with which to use the new encryption key. Additionally, the first ACK contains the chip ID of the ownership account 40, which the second loT device 20 may use to verify the identity of the ownership service provider 40 as the sender of the first ACK. This data is communication in an encrypted form, using the current encryption method and key.

In response to the second ownership chip 30b receiving the first ACK, the second loT device 20 requests an activation code of the second electronic device 20 through a user interface of the second electronic device 20. The activation code entered by the user is then verified against an activation code stored in the memory of the second loT device 20, or by the ownership service provider 40. A new activation code can be provided to a new owner of an loT device when they buy the loT device, for example by a retailer. This prevents a person who does not own an loT device, and therefore does not have access to the activation code, from adding their own ownership to the device. For example, it prevents a person adding their ownership to an unowned device in a shop showroom. Similarly, it prevents a person adding their ownership to a device they do not own when they visit another person’s home or are in another person’s car or another organisation’s building, for example.

Before or after verifying the activation code, the second loT device 20 requests an identifier, such a PIN, of the registered owner of the first electronic device 10 through a user interface of the second electronic device 20. The PIN is verified against a version stored by the ownership service provider 40 (“REQUEST VERIFICATION”). This measure prevents a person (‘Person A’) in possession of a device owned by another person (‘Person B’) from adding Person B’s ownership to unowned devices. For example, it would prevent a person (‘Person A’) who has borrowed a smart phone from a friend (‘Person B’) from adding Person B’s ownership to a fridge owned by Person A. This is because Person A will not know Person B’s PIN.

Once the activation code and PIN have been verified, the ownership service provider 40 sends a second ACK and the existing encrypted connection is closed.

In order to complete the process of adding the ownership of the first loT device 10 to the second loT device 20, the second ownership chip 30b uses its network interface 32b of the second ownership chip 30b, the network address ownership account, and the new encryption key and method identified in the first ACK to initiate (“REQUEST

CONNECTION”) a new encrypted connection over the Internet connection 320. Using this new encrypted connection, the second ownership chip 30b sends the ownership ID, the chip ID of the second ownership chip 30b, and the device ID of the second loT device 20.

If the ownership service provider 40 is able to decrypt the communication, it verifies the received data and sends a third ACK to the second loT device 20. The third ACK includes a new encryption key and method to use for the next communication session between the second loT device 20 and the ownership service provider. It also includes the chip ID of the ownership account, so that the second loT device can verify the source of the third ACK.

At this point, the second ownership chip 30b stores the ownership ID permanently in its memory. It also stores the linkage data for future encrypted communications with the ownership account with the ownership service provider, namely the encryption key and encryption method with which to communicate with the ownership service provider 40, and the network address of the account. The second ownership chip 30b may also store other data, such as the ownership account number and the chip ID of the ownership account.

To complete the process of establishing the ownership of the second loT device 20 and second ownership chip 30b by the ownership entity 50, the ownership service provider 40 sends a communication (“ADD ADD OWNERSHIP”) to the second loT device 20 that includes an encrypted data package for sending to other ownership chips via its NFC interface 33b for the purposes of propagating ownership. In response to this communication, the second loT device 20 stores the received data in its memory and responds to the ownership service provider with a message (OWNERSHIP STATUS”) confirming that ownership has been added to the second loT device. This message may contain further identification data of the second loT device 20, such as a text description of the second IoT device 20, to be stored by the ownership service provider 40. This completes the process of registering the second IoT device 20 and its ownership chip 30b with the ownership service provider 40 as being owned by the ownership entity 50.

It should be appreciated that what has been described with reference to Figures 10 and 11 is only a specific example of the message flow and message contents that can be used to propagate ownership from one IoT device to another. More or fewer messages may be sent, in different orders, and the messages may contain more or less data according to the desired implementation.

For example, one or both of the PIN and activation code verification are optional and could take place in the opposite order, and the sending of a second ACK is optional. Additionally, while sending the ownership ID between the second IoT device 20 and ownership service provider 40 provides an additional security factor, the use of a secret encryption key and method may, by itself, be sufficient verification for some implementations. Similarly, while sending chip IDs of the first ownership chip 30a, second ownership chip 30b, the chip ID of the ownership service provider 40, and the ownership account number allow for additional verification and security steps, these are not necessary. These and other modifications will be apparent to those skilled in the art.

It will be understood that what is necessary is that the data sent via the point-to-point NFC communication link from the first IoT device 10 to the second IoT device 20 allows the second IoT device to communicate with the ownership service provider 40 over the Internet, in order to authenticate the data sent via the point-to-point NFC communication link from the first IoT device 10 to the second IoT device 20, and to register the second IoT device 20 with the ownership service provider 40. The additional measures described herein provide greater levels of security and verification according to the desired level of security, but need not be present in all embodiments of the inventions described herein.

It will be appreciated that the above description with reference to Figures 10 and 11 only considers the cases where the first IoT device 10 is already registered as owned by an ownership entity 50, and the second IoT device 20 is not registered as owned by any ownership entity.

In the event neither the first nor the second IoT device are registered, there is no ownership data to send via NFC, and therefore placing the devices 10, 20 within NFC range will have no effect.

In the event both the first and second loT devices 10, 20 are registered as being owned by the same ownership entity, the first and second loT devices 10, 20 will exchange encrypted data packages via NFC and recognize that their ownership IDs match. This will cause a menu to open on the interface of each device 10, 20. One option on this menu is to begin a linkage procedure between the devices 10, 20, as described below with reference to Figures 13 and 14. Another option on this menu is to remove the ownership from a device, 10 and/or 20, the selection of which leads to the deletion of the ownership entities credentials, including the ownership ID and any linkages, from the device. When the ownership of one ownership entity 50 has been removed in this way, another ownership entity can add its ownership to the loT device.

Another way for an ownership entity 50 to remove its ownership from an loT device is to login to its ownership account through the platform implemented by the ownership service provider 40. The ownership account stores the details of the loT devices owned by the ownership entity, and ownership of loT devices can be removed through the account area. A further way to remove the ownership from the loT device is through an interface of the loT device, without the need to place the loT device in near field communication with another loT device.

In the event that the first and second loT devices 10, 20 are registered as owned, but with different ownership entities, first and second loT devices 10, 20 will exchange encrypted data packages via NFC and recognize that their ownership IDs do not match. In this case, the ownership chips are configured to not exchange any further data. An exception to this may be where an ownership entity that owns an loT device places their loT device in a “temporary ownership mode”, which allows third parties to temporarily add their ownership to an loT device, for a limited time period for example. This is particularly useful where a party temporarily provides loT devices to customers, for example car rental services and hotels.

Seed Device

In order to carry out the method illustrated by Figures 10 and 11, it is necessary for the first loT device 10 to have been registered as owned by the ownership entity. In this respect, there may be a ‘seed device’ which is the first device in the chain of propagating the ownership entity’s ownership.

Figure 12 illustrates such a seed device 60 propagating ownership to the first loT device 10. The method by which ownership is propagated from the seed device 60 to the first loT device 10 is effectively the same as the method described above with reference to Figures and 11, by which ownership is propagated from the first loT device 10 to the second loT device 20. However, the seed device 60 does not need to include an ownership chip.

Instead, the seed device 60 only needs to include an NFC/RFID interface and memory storing data that includes an encrypted data package and, embedded within the data, the encryption key with which the encrypted data package is encrypted and an identifier for an encryption method. As will be appreciated from the previous discussion, the data package includes the ownership ID, a network address of the ownership account, and an encryption key and encryption method identifier to be used during initial communications between loT devices and the ownership service provider 40. It may also include the ownership account number, the chip ID of the ownership account and the chip ID of seed device 60, for additional authentication. The seed device does not need to include a network interface 32 or a local interface 31, and does not need to include any significant processing capabilities. This is because its only function is to propagate data to ownership chips 30 over a point-topoint communication link, so that ownership chips in receipt of the data can be registered as owned by the ownership entity 50 that owns the seed device 60, as described above with reference to Figures 10 and 11.

The seed device 60, which may take the form of an NFC or RFID-enabled card, bracelet or the like, is issued to the ownership entity (in the case of Figure 12, the “Smith Family”) by the ownership service provider 40 when the ownership entity registers their ownership account with the ownership service provider. At the time the ownership entity registers with the ownership service provider, the ownership service provider assigns the ownership ID, the network address of the ownership entity’s ownership account and an encryption key and selects an encryption method. The ownership service provider 40 stores these for future use when communicating with ownership chips, as described above with reference to Figures 10 and 11. The ownership service provider 40 also issues the ownership entity 50 with the seed device 60, by sending the seed device 60 to the ownership entity by mail for example.

The seed device 60 does not need to be a single use device (although it may have restrictions on its use, such as the number of times it can be used or the duration of time it can be used from being issued by the ownership service provider). While Figures 10 and show the first loT device 10 being used to propagate the ownership entity’s ownership to the second loT device 20, the seed device 60 could also have been used in place of the first loT device 10 in Figures 10 and 11. However, users may find it more convenient to first use the seed device 60 to establish the ownership of a portable loT device such as a smartphone, and from then on use the smartphone, which they routinely carry on their person, to propagate ownership to other loT devices.

Linking loT Devices

Turning to Figures 13 and 14, these illustrate a linkage process by which two loT device 10, 20, and their respective ownership chips 30a, 30b, which are registered as being owned by the same ownership entity 50 with the ownership service provider, can be linked. The linkage process establishes linkage data. Linkage data is data that is unique to the device pairing and only known by the pair of devices, and which allows the devices to engage in direct, encrypted communication over the Internet. Ownership chips are configured to use linkage data to communicate with other linked devices over the Internet, and to disregard communications received over the Internet that are not encrypted, or are not encrypted using encryption corresponding to that defined by any linkage data stored in the ownership chip’s memory.

In Figures 13 and 14, the first loT device 10 with first ownership chip 30a, and the second loT device 20 with second ownership 30b, are registered with the ownership service provider 40 as being owned by the same ownership entity 50. Both ownership chips 30a, 30b therefore have stored in their memory the same ownership ID, as well as other ownership data including their own ownership chip IDs.

To begin the linkage process, the loT devices 10, 20 are placed sufficiently close to one another to establish an NFC connection 330 between the NFC interface 33a of the ownership chip 30a of the first loT device 10 and the NFC interface 33b of the ownership chip 30b of the second loT device 20.

With the NFC connection 330 established, the ownership chip 30a of the first loT device 10 automatically sends data to the ownership chip 30b of the second loT device 20, over the point-to-point communication link provided by the NFC connection. Additionally, the second loT device 20 automatically sends data to the ownership chip 30a of the first loT device 10, over the point-to-point communication link provided by the NFC connection.

As will be understood from the discussion above with reference to Figures 10 to 12, the data sent over the point-to-point communication link provided by the NFC connection includes an encrypted data package that includes, in an encrypted form, the ownership ID, the chip ID of the ownership chip 30a, 30b that is sending the data, a network address of the ownership account, and an encryption key and encryption method identifier to be used during initial communications between loT devices. It may also include data such as the chip ID of the ownership account and the ownership account number.

The encrypted data package also includes, in an encrypted form, the network address of the respective ownership chip, an encryption key (or data from which an encryption key can be obtained) and an identifier for an encryption method with which the encryption key is to be used. As will be explained in more detail below, this encryption key and method are for use in an initial encrypted communication over a network between the first and second electronic device. In some cases, only one encryption method may be known to the ownership chips, in which case no identifier is necessary.

This encryption key (or data from which an encryption key can be obtained) may a predefined key stored in the memory of the ownership chip, or may advantageously be randomly generated in order to increase security.

Where data from which an encryption key can be obtained is included, rather than an encryption key itself, the encryption key may be obtained by performing a predefined key derivation algorithm on the data. The data from which an encryption key can be derived may be any data, for example randomly generated data or data uniquely identifying the respective ownership chip 30a, 30b.

The encrypted data package also includes, embedded within it, the encryption key with which the encrypted data package is encrypted, and data that allows the ownership chip in receipt of the data to recover the encryption key and decrypt the encrypted data package.

Once this ownership data has been sent and received to and from the first and second ownership chips 30a, 30b, which occurs almost instantaneously, the first electronic device 10 can be moved away from the second electronic device 20 to close the NFC connection 330.

As will be appreciated from the previous description, the first and second ownership chips 30a and 30b are able to use their preinstalled data, and data included in the data received over NFC, to recover the contents of the encrypted data package. A detailed example of this is given below with reference to Figures 16 to 18.

Unlike in the methods described above with reference to Figures 10 to 12, both of the ownership chips 30a, 30b in receipt of ownership data via NFC are registered as owned with the ownership service provider 40. Because of this, once the ownership chips 30a, 30b have recovered the contents of the encrypted data packages, they will compare the recovered ownership ID to the ownership ID stored in their memory. This is in contrast to the situation of Figures 10-12, in which the ownership chip 30b in receipt of ownership data via NFC is not registered as owned, and therefore responds by beginning the process of adding the ownership of the first loT device 10 to the second loT device 20.

Upon determining that the ownership IDs match, meaning that the first and second loT devices 10, 20 are owned by the same ownership entity 50, the user is asked, via the user interface of the first loT device 10, whether they would like to link the first loT device 10 with the second loT device 20. If the user indicates that they do wish to the link the devices 10, 20, they are asked to enter their PIN. The PIN is then verified with the ownership service provider 40 by forming an encrypted communication with the ownership service provider 40 using the linkage data previously established. That is, using the network address of the ownership account and the encryption key and method that is unique to the pairing of the ownership service provider 40 and the first ownership chip 30a, as described above with reference to Figures 10 to 12.

Likewise, upon determining that the ownership IDs match, meaning that the first and second loT devices 10, 20 are owned by the same ownership entity 50, the user is asked, via the user interface of the second loT device 20, whether they would like to link the second loT device 20 with the first loT device 10. If the user indicates that they do wish to link the devices 10, 20, they are asked to enter his PIN. The PIN is then verified with the ownership service provider 40 by forming an encrypted communication with the ownership service provider 40 using the linkage data previously established. That is, using the network address of the ownership account and the encryption key and method that is unique to the pairing of the ownership service provider 40 and the second ownership chip 30b, as described above with reference to Figures 10 to 12.

In response to a successful verification of the PIN, one of the ownership chips, in the case of Figure 14 the second ownership chip 30b, attempts to initiate an encrypted communication link with the other, first, ownership chip 30a over the Internet (“REQUEST CONNECTION” in Figure 14). This is done using the network address of the first ownership chip 30a recovered from the encrypted data package received via NFC, the encryption key that was included, in an encrypted form, in the encrypted data package sent to the first ownership chip 30a, and the encryption method corresponding to the encryption method identifier that was included in an encrypted form, in the encrypted data package sent to the first ownership chip 30a. Alternatively, the second ownership chip 30b may use the encryption key and encryption method corresponding to the encryption method identifier that it received, via NFC as part of an encrypted data package, from the first ownership chip.

If the first ownership chip 30a has successfully verified the PIN when it receives the attempted communication from the second ownership chip 30b, the first ownership chip 30a will attempt to decrypt the communication. Since the communication from the second ownership chip 30b is encrypted using the encryption key and method that was included in the initial NFC communication sent from the second ownership chip 30b to the first ownership 30a (or sent from the first ownership chip 30a to the second ownership chip 30b), the first ownership chip 30a should have the necessary information to decrypt the communication. In the event that the first ownership chip 30a cannot decrypt the communication, this indicates that the two loT devices have not been linked, and so the first ownership chip can discard or ignore the communication. Such a communication may originate from a third party networked device which is trying to ‘hack’ or obtain control of the first loT device.

In the event that PIN verification has not yet been completed at the time it receives the attempted communication from the second ownership chip 30b, the second ownership chip 30b will retry attempts to connect until PIN verification is complete, or until a timeout.

If the first ownership chip 30a successfully decrypts the communication from the second ownership chip 30b, the first ownership chip 30a responds with an ACK to confirm that the linkage between the two ownership chips 30a, 30b has been successful. The first and second ownership chips 30a, 30b then confirm the linkage with the ownership account (“LINKAGE STATUS”) so that the ownership account has an up-to-date record of the linkage status of the ownership chips 30a, 30b. Additionally, the ownership chips 30a, 30b can exchange current operational statuses (“DATA FROM PRODUCER”), such as current data from sensors in the loT devices.

In some embodiments, all future network communications between the first and second ownership chips 30a, 30b are encrypted using the encryption key and method used for the initial communication.

However, in other embodiments, a different encryption key and/or method are used for each communication instance between the first and second ownership chips 30a, 30b. This can be achieved by providing, during each new encrypted communication instance, the encryption key and method to be used in a future communication instance. For example, the second ownership chip 30b, wishing to send data to the first ownership chip 30a, establishes an encrypted communication channel with the first ownership chip 30a using encryption established in the previous communication instance, and during the new communication instance generates and sends an encryption key and method to be used in the next communication instance. In this way, using only a single initial exchange over the NFC communication link (or RFID or other point-to-point communication link) during the linkage procedure, a new encryption key and/or method can be established for each communication instance without ever sending data in an unencrypted form, and without the use of public keys. This provides highly secure transfer of data between loT devices.

In the event that an ownership entity wishes to unlink two loT devices, there are two options.

Firstly, as explained above with reference to Figures 10 and 11, when two loT devices 10, 20 that are owned by the same ownership entity 50 are placed sufficiently close that NFC communication takes place between their ownership chips 30a, 30b, the ownership chips recognize that they are commonly owned and a menu is presented on the user interface of the respective loT devices. Where the two devices 10, 20 are linked, one option available on the menu is to unlink the devices. Selecting this option on either device causes the respective linkage data to be deleted from the memory of each ownership chip 30a, 30b. The selection can be made on both devices, but only needs to be made on one device to be effective. In the even the selection is only made on one device, the other device can be notified of the linkage removal by the ownership account, or on its next attempt to use this linkage.

Alternatively, the ownership entity 50 can unlink the two devices 10, 20 by logging into its ownership account using the platform provided by the ownership service provider 40. The ownership account stores the details of linkages between loT devices, and specific linkages can be removed through the account area. In this case, the ownership account notifies the effected loT devices. A further way to remove the linkage is through an interface of either of the loT devices, without the need to place the loT devices in near field communication with each other.

Transfer of Data

Figure 15 is a sequence diagram illustrating how two linked loT devices 10, 20 with ownership chips 30a, 30b (not shown) communicate over the Internet in a secure manner.

In Figure 15, the first loT device 10 acts as a “consumer” device and the second loT device 20 acts as a “producer” device. Producer devices generate data, such as sensor data, and communicate it to consumer devices. Consumer devices request data from, and receive data from, producer devices. Producer devices can also exercise control over their components, for example actuators such as door locks, and receive control commands from consumer devices to exercise control over these components. Consumer devices can issue control commands to producer devices to exercise control over the components.

According to this example, the producer device 20 initiates, via its ownership chip 30b, communication with the consumer device by requesting an encrypted communication over the Internet (“REQUST CONNECTION”). This is done using linkage data for the specific device pairing, which is obtained as described above with reference to Figures 13 and 14. This linkage data includes the network address of the first ownership chip 30a of the consumer device 10, and the encryption key and method with which to encrypt communications.

In response to the request from the producer device 20, the first ownership chip 30a of the consumer device 10 attempts to decrypt the communication using the linkage data stored in its memory. If the first ownership chip 30a is able to decrypt the request, it responds with an ACK. If the first ownership chip 30a is unable to decrypt the request, the first ownership chip 30a is, like all ownership chips, configured to not permit the communication link over the Internet, for example by simply disregarding the request.

If the first ownership chip 30a responds with an ACK, the second ownership chip 30b responds by sending data, such as sensor data, produced by the producer device 20 (“DATA FROM PRODUCER”). Additionally or alternatively, with the connection established, the consumer device 10 can make specific requests for data from the producer device 20, or issue commands to control assets of the producer device 20.

After no data has been transferred for a predefined amount of time, the communication session times out and the connection is closed.

The ownership chip of the producer device 20 can be configured to refuse or ignore all connection requests, and indeed other general communications, from other loT devices, including loT devices with which it is linked. This enhances security because it makes it difficult for third parties to obtain data from a producer loT device, since the producer loT device will simply refuse to communicate unless it has initiated the communication link, and since the producer device can only initiate communications with loT devices it knows through the linkage procedure. Further, such a simple interface, configured to simply ignore all incoming requests to communicate, can be implemented in a high assurance manner for which vulnerabilities will be very difficult to find.

While the producer device 20 can be configured to completely ignore all communications except communications over communication links it has initiated, in some cases an exception is made for requests from linked loT devices for the producer device 20 to initiate a communication link. That is, prior to the initial “REQUEST CONNECTION” step in Figure 14, the consumer device 10 may issue a request to the producer device 20 for the producer device to issue the “REQUEST CONNECTION” communication. This way, a consumer device 10 can obtain data on-demand or issue a command in a timely manner, but a high level of security can be maintained because it remains the case that only the producer device 20 can initiate a connection, and because the interface can still be implemented in a simple, high assurance manner, accepting only predefined inputs and responding with only predefined outputs.

While in the above description a particular loT device is a consumer device and the other is a producer device, it should be appreciated that these assignments could be the other way around, and also that a given loT device could behave as both a producer and a consumer.

Embedding and Recovering an Encryption Key

Turning to Figures 16 to 18, these illustrate an exemplary process by which data including an encrypted data package such as that described above with reference to Figures 10 to 14 can be formed, and how the contents of the encrypted data package can be recovered once the data has been received from another ownership chip via NFC, RFID or another communication interface providing a point-to-point communication link. It should be appreciated that this is only one example of how this can be implemented.

Figure 16A illustrates an encryption method table 70 which may be preloaded to the memory of ownership chip 30, and Figure 16B illustrates a scatter table 80 which may be preloaded to the memory of ownership chip 30. Together, the encryption method table 70 and scatter table 80 are used to securely send and receive encrypted data via NFC in accordance with embodiments of the invention.

As can be seen, the encryption method table 70 includes an “encryption method ID” that associates a number, in this case a four bit number (0-15), to one of four encryption methods (0-3). In this case the four encryption methods are each re-used four times, but it will be understood that more or less encryption methods could be used such that they are re-used less or more times, or not re-used at all, and that the encryption method ID may be more or less than four bits. Instructions for executing each of the four encryption methods are stored in the memory 34 of the ownership chip 30.

Associated with each encryption method is an encryption key length, in this case either 16 or 32 bits. The longer the encryption key, the more secure the encryption but the more computationally demanding the encryption/decryption process, so the length of the encryption key is chosen according to the demands of the system. In the case of the encryption method table of Figure 16A, there are two possible key lengths, but in other cases there may only one key length, or more than two key lengths.

The scatter table 80 includes a first column, “key bit”, which relates the bit number/position of the encryption key referred to in the encryption method table 70 to a “scatter indicator”. It should therefore be appreciated that the number of rows in the scatter table is equal to the length of the encryption key referred to in the encryption method table 70. The scatter indicator is a random number, where the number of possible values is equal to the length of the encryption key (sixteen or thirty-two in this example). It will be appreciated that since there are two possible encryption key lengths in this example, there could be two scatter tables, one for a key length of sixteen and another for a key length of thirty-two. In the case of Figure 16B, however, there is a single scatter table 80, but the value of the scatter indicator is limited to one of sixteen values for rows 0-15, but is allowed to be greater for rows 16-31.

In some embodiments there may be more than one scatter table (or more than one scatter indicator column in the scatter table 80) corresponding to different scatter methods. In this case, the encryption method table 70 could include an additional column (not shown) that identifies a particular scatter method to use to use with the identified encryption method.

For ease of illustration only a single scatter method is described herein, but it will be understood that the use of multiple scatter methods can be used to further increase security.

Figure 17 illustrates a method 1700 by which data including an encrypted data package is constructed using the encryption table 70 and scatter table 80 of Figures 16A and 16B. In this way, data such as ownership data, which for ease of explanation will be referred to as including data elements X, Y and Z, can be encrypted into an encrypted data package.

Data including the encrypted data package and an embedded encryption key for decrypting the encrypted data package can then be formed.

Firstly, in step 1710, a data package is formed. In this example, a data package including data elements X, Y and Z is formed. For example, if X, Y and Z have predefined lengths, the data package can simply be these three pieces of data in a predefined sequence, as an ownership chip 30 that has decrypted the data package can use the predefined lengths and sequence to identify each of the three data elements. Alternatively, a header can be formed indicating the length and/or position of each of the three data elements, and the header appended at the beginning of the data.

In step 1720, an encryption method is selected by selection of an encryption method ID. As explained above with reference to Figure 16A, an encryption method is associated with an encryption method ID and an encryption key length. The encryption method can be selected randomly, or in any other way. In other cases there may only be one encryption method, in which case there will be no selection step, no encryption method ID, and the encryption key length may be implicit.

In step 1730, if the length of data package formed in step 1710 is less than twice the encryption key length of the encryption method selected in step 1720, the data package is padded with bits until it is at least twice the length of the encryption key length. The padding bits can be a random string of bits. Although padding the data package in this way is not essential, it is desirable for the data package to be at least twice the length of the encryption key so that when the encryption key is embedded within the encrypted data package in step 1760, there is sufficient data for the key to be effectively scattered within the data. An indication of the number of padding bits added may be appended so that the ownership chip that decrypts the padded data package is readily able to remove the padding bits. Alternatively, no indication of the number of padding bits is necessary because the recipient of the data can determine the fields included in the message, and ignore all excess data (the padding bits).

In step 1740, an encryption key for encrypting the data package is selected. The encryption key should have a length equal to the encryption key length of the encryption method selected in step 1720. The encryption key can be randomly generated using a predefined algorithm, or can be one of one or more predefined encryption keys stored in the memory of the ownership chip.

In step 1750, the data package formed in steps 1710 and 1730 is encrypted using the encryption method selected in step 1720 and the encryption key selected in step 1740.

In step 1760, the encryption key used to encrypt the data package, selected in step 1740, is embedded within the encrypted data package. An example of embedding the encryption key within the encrypted data package using a scatter table 80 is described below with reference to Figure 18.

In step 1770, the encryption method ID of the encryption method selected in step 1720 is appended to the output of step 1760. For example, a tag or flag having a number of bits sufficient to identify the encryption method used to encrypt the encrypted data package can be appended to the beginning or to the end of the output of step 1760. Again, it will be appreciated that if there is only one encryption method, it is not necessary to append an encryption method ID.

The data output from step 1760 can then be sent from one ownership chip to another via the NFC interface, or from a seed device to an ownership chip as explained above with reference to Figure 12. The ownership chip in receipt of the data is then able to recover the data elements X, Y and Z by following the steps of method 1700 in reverse. That is, the ownership chip in receipt of the data uses the encryption method ID appended in step 1770 to determine the encryption method and encryption key length; recover the encryption key from the data as will be explained below with reference to Figure 18; decrypt the encrypted data package using the encryption key and the encryption method to determine the unencrypted data package; and recover the data elements X, Y and Z from the data package.

It will be appreciated that data elements X, Y and Z could generally be any data elements (including three, more than three or less than three data elements), but in the context of the inventions described herein, X, Y and Z represent data required for an ownership chip in receipt of an encrypted data package to initiate an initial encrypted communication with the ownership service provider in order to add ownership to the loT device in receipt of the encrypted data package, or as part of the process of linking loT devices. It will therefore be appreciated from the above description with reference to Figures 10 to 14 that X, Y and Z preferably include an ownership account number, an ownership ID, a chip ID of the ownership account, a chip ID of the ownership chip sending the encrypted data package, a network address of the ownership account, and an encryption key and encryption method identifier to be used during initial communications between loT devices and the ownership service provider.

Figure 18 illustrates a method of embedding an encryption key in encrypted data. In particular, it illustrates step 1760 of method 1700 illustrated in Figure 17 in more detail.

Firstly, an “offset” of the encrypted data, such as the data output by step 1750 of method 1700, that has been encrypted using a known encryption key of known length is determined in step 1761. Although not essential, the use of an offset is desirable because it helps ensure that the encryption key is scattered throughout the encrypted data. In one example, the offset value, O, is equal to the quotient when the length of the encrypted data is divided by the length of the encryption key. It will be understood that the quotient is the whole number part of the division, ignoring any remainder. In other words, the quotient is the largest integer number of times the length of the encryption key will divide into the length of the encrypted message. That is, if the length of the encrypted data is E and the length of the encryption key is K:

E

- = ° ₊ R

Where R is the remainder of the division E/K, where O and R are integers, and R < K.

In step 1762, a counter n is set equal to an initial value of zero.

In step 1763, a “scatter location” of the data at which to embed the next bit of the encryption key is determined. The scatter location is determined using a scatter indicator, which is an effectively random value, and can be obtained from the scatter table 80 for the current value of the counter, n. The scatter indicator obtained from the table can then be multiplied by the offset value O calculated in step 1761 to give the scatter location at which to store the next bit of the key within the data.

In step 1764, all of the bits of the encrypted data falling to right of the scatter location are right shifted by one bit, and in step 1765 the n^th bit of the encryption key is stored in the empty scatter location, thus embedding the n^th bit of the encryption key within the data.

In step 1766, the counter n is incremented by one.

In step 1767, the counter n is compared to the encryption key length. If n is less than the encryption key length, such that not all bits of the encryption key have been embedded within the data, the method proceeds back to step 1763 so that the next bit of the encryption key is embedded. If n is equal to the length of the encryption key, such that all bits of the encryption key have been embedded within the data, the method 1760 ends, for example outputting to step 1770 of method 1700.

Described above are a number of embodiments with various optional features. It should be appreciated that, with the exception of any mutually exclusive features, any combination of one or more optional features are possible. It will be appreciated that variations and modifications may be made to the described embodiment that are within the scope of the present invention.

Claims

1. A method of establishing ownership of an electronic device, comprising: sending ownership data from a first electronic device to a second electronic device over a point-to-point communication link, wherein the first electronic device is registered with a registration entity as being owned by an ownership entity, and the second electronic device is not registered as being owned by the ownership entity, and wherein the ownership data comprises data identifying the ownership entity with which the first electronic device is registered as owned, and data identifying a network address of the registration entity;

authenticating the ownership data with the registration entity, wherein authenticating the ownership data comprises sending data from the second electronic device to the registration entity over a network connection using the data identifying the network address of the registration entity, and receiving data from the registration entity confirming the ownership data has been authenticated; and storing the data identifying the ownership entity at the second electronic device.

2. A method according to claim 1, wherein the ownership data sent from the first electronic device to the second electronic device further comprises an encryption key, wherein sending data from the second electronic device to the registration entity comprises sending data encrypted using the encryption key, and wherein authenticating the ownership data further comprises the registration entity being able to decrypt the encrypted data.

3. A method according to claim 2, wherein the ownership data sent from the first electronic device to the second electronic device further comprises data identifying an encryption method with which to encrypt the data using the encryption key, and wherein sending data from the second electronic device to the registration entity comprises sending data encrypted using the encryption key and the identified encryption method.

4. A method according to claim 3, wherein the second electronic device uses instructions stored in its memory to perform the identified encryption method.

5. A method according to any preceding claim, wherein the ownership data sent from the first electronic device to the second electronic device is sent in an encrypted form, and wherein the method further comprises decrypting, by the second electronic device, the encrypted ownership data received from the first electronic device.

6. A method according to claim 5, wherein an encryption key used to encrypt the encrypted ownership data received from the first electronic device is embedded within the encrypted ownership data received from the first electronic device, and wherein the method further comprises recovering the encryption key.

7. A method according to claim 6, wherein the second electronic device uses instructions stored in its memory to recover the encryption key embedded within the encrypted ownership data.

8. A method according to claim 6 or 7, wherein the encrypted ownership data is encrypted using an encryption method, and wherein the second electronic device uses instructions stored in its memory for performing the encryption method to decrypt the encrypted ownership data.

9. A method according to claim 8, wherein the encrypted ownership data includes an identifier that identifies the encryption method used to encrypt the ownership data, and wherein the second electronic device uses the identifier to identify the encryption method from amongst a plurality of encryption methods stored in its memory.

10. A method according to any preceding claim, wherein the point-to-point communication link is a wireless communication link.

11. A method according to claim 10, wherein the wireless communication link is an RFID or NFC communication link.

12. A method according to any preceding claim, wherein the data sent from the second electronic device to the registration entity over the network connection comprises the data identifying the ownership entity with which the first electronic device is registered as owned, and wherein authenticating the ownership data further comprises the registration entity comparing the received data to a version of the same data stored by the registration entity.

13. A method according to any preceding claim, wherein the data identifying the ownership entity with which the first electronic device is registered as owned is a string having a length of at least 64 bits.

14. A method according to any preceding claim, wherein the data identifying the ownership entity with which the first electronic device is registered as owned is a randomly generated string or is a string randomly selected from amongst a predefined number of possible strings.

15. A method according to any preceding claim, wherein the data sent from the second electronic device to the registration entity over the network connection comprises data identifying the second electronic device, and wherein the method further comprises the registration entity using the data identifying the second electronic device and data stored by the registration entity to determine whether the second electronic device has been reported as lost or stolen.

16. A method according to any preceding claim, wherein the ownership data comprises data identifying the first electronic device, wherein the data sent from the second electronic device to the registration entity over the network connection comprises the data identifying the first electronic device, and wherein the method further comprises the registration entity using the data identifying the first electronic device and data stored by the registration entity to determine whether the first electronic device has been reported as lost or stolen.

17. A method according to any preceding claim, wherein the ownership data comprises data identifying the registration entity, wherein the data received by the second electronic device from the registration entity comprises data identifying the registration entity, and wherein the method further comprises authenticating, by the second electronic device, the registration entity by comparing the data identifying the registration entity received from the first electronic device and the data identifying the registration entity received from the registration entity.

18. A method according to any preceding claim, further comprising performing, by the second electronic device, one or more authentication steps, the one or more authentication steps being selected from: entering a personal identification number (PIN) associated with the ownership entity; and entering an authentication code associated with the second electronic device.

19. An electronic device, comprising:

a communication interface for communicating with other electronic devices over a network;

a separate communication interface for communicating with other electronic devices over a point-to-point communication link; and memory;

the electronic device being configured to:

receive ownership data from another electronic device over the point-to-point communication link, wherein the ownership data comprises data identifying an ownership entity with which the other electronic device is registered as owned with a registration entity, and data identifying a network address of the registration entity;

authenticate the ownership data with the registration entity, wherein authenticating the ownership data comprises sending data from the electronic device to the registration entity over a network connection using the data identifying the network address of the registration entity, and receiving data from the registration entity confirming the ownership data has been authenticated; and store the data identifying the ownership entity in the memory.

20. An electronic device according to claim 19, wherein the ownership data further comprises an encryption key, wherein the electronic device is configured to encrypt data before sending it to the registration entity, and wherein authenticating the ownership data further comprises the registration entity being able to decrypt the encrypted data.

21. An electronic device according to claim 20, wherein the ownership data received from the other electronic device further comprises data identifying an encryption method with which to encrypt the data using the encryption key, and wherein the electronic device is configured to encrypt the data using the encryption key and the identified encryption method.

22. An electronic device according to claim 21, wherein the electronic device is configured to use instructions stored in its memory to perform the identified encryption method.

23. An electronic device according to any of claims 19 to 22, wherein the electronic device is configured to receive the ownership data from the other electronic device over the point-to-point communication link in an encrypted form, and wherein the electronic device is configured to decrypt the encrypted ownership data.

24. An electronic device according to claim 23, wherein an encryption key with which the encrypted ownership data is encrypted is embedded within the encrypted ownership data received from the other electronic device, and wherein the electronic device is further configured to recover the encryption key and use it to decrypt the ownership data.

25. An electronic device according to claim 24, wherein the electronic device is configured to use instructions stored in its memory to recover the encryption key embedded within the encrypted ownership data.

26. An electronic device according to claim 24 or 25, wherein the encrypted ownership data is encrypted using an encryption method, and wherein the electronic device is configured to use instructions stored in its memory for performing the encryption method to decrypt the encrypted ownership data.

27. An electronic device according to claim 26, wherein an identifier identifying the encryption method is included with the encrypted ownership data, and wherein the electronic device is configured to use the identifier to identify the encryption method from amongst a plurality of encryption methods stored in its memory.

28. An electronic device according to any of claims 19 to 27, wherein the second communication interface is a wireless communication interface.

29. An electronic device according to claim 28, wherein the wireless communication interface is an RFID or NFC communication interface.

30. An electronic device according to any of claims 19 to 29, wherein the data sent to the registration entity over the network connection comprises the data identifying the ownership entity with which the other electronic device is registered as owned, and wherein the registration entity authenticating the ownership data further comprises the registration entity comparing the data received from the electronic device to a version of the same data stored by the registration entity.

31. An electronic device according to any of claims 19 to 30, wherein the data identifying the ownership entity with which the other electronic device is registered as owned is a string having a length of at least 64 bits.

32. An electronic device according to any of claims 19 to 31, wherein the data identifying the ownership entity with which the other electronic device is registered as owned is a randomly generated string or is a string randomly selected from amongst a predefined number of possible strings.

33. An electronic device according to any of claims 19 to 32, wherein the data sent from the electronic device to the registration entity over the network connection comprises data identifying the electronic device, and wherein the registration entity uses the data identifying the electronic device and data stored by the registration entity to determine whether the electronic device has been reported as lost or stolen.

34. An electronic device according to any of claims 19 to 33, wherein the ownership data comprises data identifying the other electronic device, wherein the data sent from the electronic device to the registration entity over the network connection comprises the data identifying the other electronic device, and wherein the registration entity uses the data identifying the other electronic device and data stored by the registration entity to determine whether the other electronic device has been reported as lost or stolen.

35. An electronic device according to any of claims 19 to 34, wherein the ownership data comprises data identifying the registration entity, wherein the data received by the electronic device from the registration entity comprises data identifying the registration entity, and wherein the electronic device is further configured to authenticate the registration entity by comparing the data identifying the registration entity received from the other electronic device and the data identifying the registration entity received from the registration entity.

36. An electronic device according to any of claims 19 to 35, wherein the electronic device is further configured to perform one more authentication steps, the one or more authentication steps being selected from: entering a personal identification number (PIN) associated with the ownership entity; and entering an authentication code associated with the second electronic device.

37. An electronic device, comprising:

a communication interface for communicating with other electronic devices over a pointto-point communication link; and memory storing ownership data, the ownership data comprising data identifying an ownership entity with which the electronic device is registered as owned with a registration entity, and a network address of the registration entity, the electronic device being configured to:

send the ownership data to another electronic device over the point-to-point communication link so that the other electronic device can authenticate the ownership data with the registration entity.

38. An electronic device according to claim 37, wherein the ownership data further comprises an encryption key for other electronic devices to use to encrypt data sent to the registration entity.

39. An electronic device according to claim 38, wherein the ownership data further comprises data identifying an encryption method with which to encrypt the data using the encryption key.

40. An electronic device according to any of claims 37 to 39, wherein the electronic device is configured to send the ownership data to the other electronic device over the point-to-point communication link in an encrypted form.

41. An electronic device according to claim 40, wherein the encryption key used to encrypt the encrypted ownership data is embedded within the encrypted ownership data.

42. An electronic device according to claim 40 or 41, wherein the encrypted ownership data is encrypted using an encryption method, and wherein an identifier identifying the encryption method used to encrypt the ownership data from amongst a plurality of possible encryption methods is included in the encrypted ownership data.

43. An electronic device according to any of claims 37 to 42, wherein the communication interface is a wireless communication interface.

44. An electronic device according to claim 43, wherein the wireless communication interface is an RFID or NFC communication interface.

45. An electronic device according to any of claims 37 to 44, wherein the data identifying the ownership entity with which the electronic device is registered as owned is a string having a length of at least 64 bits.

46. An electronic device according to any of claims 37 to 45, wherein the data identifying the ownership entity with which the electronic device is registered as owned is a randomly generated string or is a string randomly selected from amongst a predefined number of possible strings.

47. An electronic device according to any of claims 37 to 46, wherein the ownership data comprises data identifying the first electronic device.

48. An electronic device according to any of claims 37 to 47, wherein the ownership data comprises data identifying the registration entity.

49. A system comprising an electronic device according to claim 19 and an electronic device according to claim 37.

50. A system comprising a plurality of electronic devices, wherein each of the plurality of electronic devices are registered with a registration entity as being owned by a common ownership entity, and wherein the ownership of the plurality of electronic devices has been established in accordance with the method of claim 1.

51. A computer system comprising one or more computers, the computer system configured to authenticate data received from electronic devices over a network and to establish ownership of the electronic devices in accordance with the method of claim 1

Intellectual

Property

Office

Application No: GB1704639.2 Examiner: Mr Jonathan Richards