WO2023135008A1

WO2023135008A1 - Server assisted encryption of keys

Info

Publication number: WO2023135008A1
Application number: PCT/EP2022/087747
Authority: WO
Inventors: Ton Frederik Petrus VAN DEURSEN; Shankaran Sandeep KUMAR; Marinus Carolus Mathijs Muijen
Original assignee: Signify Holding B.V.
Priority date: 2022-01-13
Filing date: 2022-12-23
Publication date: 2023-07-20

Abstract

:Some embodiments are directed to a digital network system comprising at least a first network device, an enrollment device, and a remote server. The remote server encrypts a cryptographic key for protecting communication on the network with the install key of the first network device. The enrollment device sends the encrypted data on to the first network device. The network device decrypts the encrypted data with its install key obtaining a cryptographic key for protecting communication on the network.

Description

SERVER ASSISTED ENCRYPTION OF KEYS

TECHNICAL FIELD

The presently disclosed subject matter relates to a digital network system, a network device, an enrollment device, a server device, a method or a network device, a method for an enrollment device, a method for as server device, a computer readable medium.

BACKGROUND

Lighting networks are often arranged with wireless network functionality which enables controlling of the lighting network. For example, lighting devices in the network may be turned on or off, a user may signal their wishes with wireless switches, dimmers, lighting schedules may be implemented, and so on. An implication of using a network is that its security is an issue. Preferably, network traffic is protected using cryptographic means, e.g., the data may be encrypted and/or integrity protected. Such protection may be achieved by installing in the lighting devices, and in a controller of the lighting network corresponding cryptographic keys. A known lighting system is disclosed in US patent 10356885 with title ‘Installing and commissioning transceivers coupled to loads’ and included herein by reference. The known lighting system includes a lighting device, a remote database, and a controller. The lighting device includes at least a transceiver which includes at least one identification information and at least one security information. The remote database contains the identification information and an associated security information for each lighting device. The controller is adapted to retrieve the identification information of the transceiver, to retrieve the associated security information from the remote database, and to then use the associated security information to enable secure communication between the controller and the lighting device.

US 2019/159031 Al discloses a device for permitting a remote device access to a secure network, the device comprising: a wireless transceiver; a memory storing a network key associated with the secure network; and a control module, wherein the control module is configured to: form a first network and form the secure network; allow the remote device to join the first network upon detection of the remote device having a network key associated with the first network, wherein the network key associated with the first network is also stored in said memory; and once the remote device has joined the first network, the control module is configured to: receive, via said wireless transceiver, a unique identifier of the remote device transmitted from the remote device; determine whether the remote device is authorised to access the secure network based on said unique identifier; and transmit, via said wireless transceiver, the network key associated with the secure network in encrypted form to the remote device to permit the remote device access to the secure network, in dependence on said determination.

SUMMARY

The known lighting system may still be improved. In particular the problem of transporting a key from an enrollment device to a network device, which is protected against attacks on the enrollment device, as well as against eavesdropping on the connection.

A typical dilemma when introducing a new device into a network, is that the network’s security information such as keys needs to be transferred to the new device in a secure manner, but that secure transfer requires that the new device shares security information with devices that are already in the network which they do not before joining. For example, if the new device and an enrollment device were to share a key, then the network information could be encrypted with the shared key. Unfortunately, such a shared yet secret key does not exist before joining the network.

The known system in the background tries to find a way out of this dilemma by creating a database of keys for new devices. If a new device is to join a network, the enrollment device can go to the database and retrieve a device specific key, e.g., an install key. At that point, the new device and the enrollment device have a shared key, which can be used to protect the transfer of the network’s security information.

Unfortunately, it turns out that the known system is hard to secure. It is difficult for the server with the database to verify if a request for a device unique key is genuine or not. The problem is that if a single enrollment device could be hacked to perform key requests, at will, and to reveal the retrieved install keys, then a resulting key exchange using the install key would still be insecure. If the key exchange is eavesdropped upon, then the network key can be obtained using the install key.

Embodiments allow a secure and user-friendly method to commission a new network device in an existing network. For example, in an embodiment, a new Zigbee device may be commissioned into an existing Zigbee network. For example, the install codes of a Zigbee device may be used to protect the communication. These install codes are typically unique per device and may be stored in the devices during manufacturing as well as in a cloud-based system, e.g., with a server. Interestingly, the enrollment device no longer receives the install code, or the install key that may be derived therefrom. Instead, the enrollment device asks the server to perform the encryption. As a result, a hacked enrollment device will not reveal install keys. The security information associated with the particular network of the enrollment device may be revealed, but the hacked enrollment device cannot be used to retrieve install keys for network devices.

An aspect of the invention is a network system comprising one or more network devices, an enrollment device, and a server device. The enrollment device may form a network in which possibly some network devices are already joined. A new network device needs to be commissioned, e.g., provided with the network security information, e.g., a network key.

The network devices, enrollment device, and the server device are electronic devices. The enrollment device may be a mobile device arranged for mobile enrollment of network devices. For example, a new network device may be a lighting device. For example, the enrollment device may be an installer device configured to commission new network devices. The enrollment device could also be a non-mobile device, e.g., a controller, a coordinator, e.g., a Zigbee coordinator, a bridge, and the like. Embodiments allows secure communication with a new network device across a computer network, even though the enrollment device may not initially share a key with the new network device. This makes it possible to perform remote commission without having to be physically present during commissioning.

Devices and methods according to an embodiment can be applied in a wide range of practical applications. A particular important application is a lighting network. A lighting network may comprise multiple lighting devices, and multiple light controllers, e.g., switches, dimmers, and the like. In a lighting network often many lighting devices need commissioning, while at the same time such devices might be installed in ill accessible locations. Other applications include internet of things application, home automation, HVAC control, business computer network installation, and so on.

Further aspects include methods for network devices, enrollment devices and server. An embodiment of the method may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing an embodiment of the method when said program product is executed on a computer.

In an embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

BRIEF DESCRIPTION OF DRAWINGS

Further details, aspects, and embodiments will be described, by way of example, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the Figures, elements which correspond to elements already described may have the same reference numerals. In the drawings,

Fig. la schematically shows an example of an embodiment of a network device,

Fig. lb schematically shows an example of an embodiment of an enrollment device,

Fig. 1c schematically shows an example of an embodiment of a server,

Fig. Id schematically shows an example of an embodiment of a network system,

Fig. 2 schematically shows an example of an embodiment of an enrollment of a network device joining a network,

Fig. 3 schematically shows an example of an embodiment of an enrollment of a network device joining a network,

Fig. 4 schematically shows an example of embodiment of an encryption operation,

Fig. 5a schematically shows an example of an embodiment of a method for a network device for joining a digital network,

Fig. 5b schematically shows an example of an embodiment of method for an enrollment device for joining a network device into a digital network, Fig. 5c schematically shows an example of an embodiment of a method for a server device in assisting an enrollment device in joining a network device into a digital network,

Fig. 6a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment,

Fig. 6b schematically shows a representation of a processor system according to an embodiment.

Reference signs list

The following list of reference signs refers to figures la-3, 6a, and 6b, and is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.

100 a network

110, 110.1, 110.2 a network device

113 a processor system

114 storage

115 communication interface

120 an enrollment device

123 a processor system

124 a storage

125 a communication interface

130 a server device

133 a processor system

134 a storage

135 a communication interface

140.1 a further network device

162 a database

172 a first network

173 a second network

180 a network system

210 a network device

220 an enrollment device

221 a key packaging 230 a server

231 a key encryption

241 a network association

245 first message

246 a second message

247 a third message

310 network device

320 enrollment device

321 construct transport key

322 construct transport key

330 server

331 look up install code

332 verify nonce 1

333 CCM encrypt plaintex 1 and produce MIC

334 look up install code

335 verify nonce2

336 CCM encrypt plaintex2 and produce MIC

341 beacon request

342 beacon

343 association request

344 association response

345 network device identifier, noncel, assoc datal, plaintextl

346 ciphertext, MIC

347 transport key (network key)

348 network device identifier, nonce2, assoc_data2, plaintext2

349 ciphertext, MIC

350 transport key (link key)

351 verify key

352 confirm key

1000 a computer readable medium

1010 a writable part

1020 a computer program

1110 integrated circuit(s) 1120 a processing unit

1122 a memory

1124 a dedicated integrated circuit

1126 a communication element

1130 an interconnect

1140 a processor system

DESCRIPTION OF EMBODIMENTS

While the presently disclosed subject matter is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the presently disclosed subject matter and not intended to limit it to the specific embodiments shown and described.

In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them.

Further, the subject matter that is presently disclosed is not limited to the embodiments only, but also includes every other combination of features described herein or recited in mutually different dependent claims.

In many networks, and especially wireless networks, there is a desire to keep installing of security related codes easy, in particular cryptographic keys. This is especially important in networks which are for example used domestically. Domestic end users are more likely to adopt security measures if the adoption thereof will be relatively straightforward. However, it is certainly not only domestic settings were a streamlined installation of network devices is important. For example, a network may require the installation of many network devices, which takes resources to install. Reducing the effort needed is therefore important. An example of networks where many network devices may need installation, are lighting networks. In a lighting network many network devices, e.g., arranged as lighting devices, may be involved, each of which may need installation.

Another example are Internet of Things (loT) devices with wired or wireless interfaces. Network devices such as these, may need to securely join a local network to be able to communicate with other devices. A network device such as loT devices typically lacks a user interface to configure the necessary security material such as a cryptographic network key to join the network. For example, in a joining or commissioning phase a new network device may receive the security material from another device on behalf of the user. This exchange of the security material is a sensitive operation because it may leak, e.g., the network key, to an attacker in radio range if the exchange is not properly protected.

Possibilities to transport security material, such as a network key, to a new device include the following:

• Insecure key transport: The security material is transferred without any additional protection. Any attacker in radio range can obtain the key by sniffing the communication using a wireless sniffer. This is the case for many Wi-Fi-based systems that assume a small window of opportunity for the attacker. However, by performing a Denial-of-Service attack, the user may be forced to re-perform this transfer operation insecurely within a time window when the attacker is present.

• Encrypted with a key known to all devices: The security material is first encrypted with a key that is known to all devices. This method is secure if the key is not known to the attacker. The default Trust Center Link Key in Zigbee is an example of such a global key. Unfortunately, these keys often leak or become known, which makes the method insecure.

• Encrypted with a device-specific key. Every device is equipped with a unique random key. This unique key is used to encrypt the security material during transport. This prevents the attacker from being able to read the security material.

For example, the device-specific unique key may be printed on the device, e.g., as an optically readable code such as a QR code, or may be provided separately. Zigbee install codes are an example of this mechanism. Wi-Fi products that set up an access point for which the password is printed on a sticker on the device are another example.

A device-specific unique key may be obtained by an enrollment device, e.g., an installer, e.g., a controller or the like, as suggested in the background from a database.

The current commissioning methods are either insecure or not user friendly, e.g., require a per-device manual intervention. The methods that do not require security or rely on a global secret do not require user interaction and are thus easy to use, but they are vulnerable to attack, e.g., network-key leaking. The methods that rely on a printed devicespecific key require a user to scan a QR code or type in a device secret for each device that it intends to join to a network. This means that the user needs to scan every device and, therefore, bulk-commissioning is not possible. In addition, the scanning of the QR code may be impractical because the devices are mounted out-of-reach in the ceiling or behind a cabinet.

Using a database to obtain a device-specific key as in the background system has the disadvantage that as soon as an enrollment device with access to the database is hacked, potentially the device unique keys of many devices are leaked.

Figure la schematically shows an example of an embodiment of a network device 110. Figure lb schematically shows an example of an embodiment of an enrollment device 120. Figure 1c schematically shows an example of an embodiment of server device 130.

Network device 110, enrollment device 120, and server device 130 may be part of a network system. The network devices form a network 100, or are to be commissioned into a network 100. In particular, one new network device, e.g., network device 110, is to be commissioned into network 100. Typically, the network comprises multiple network devices 110, e.g., at least 10, at least 100, at least 1000. The various network devices in network 100 may be identical, but this is not necessary. For example, in a lighting network there may be various kinds of lighting devices and control elements. The network devices that are already commissioned typically share a network key, allowing them to communicate securely on the network.

For example, the network system may comprise a lighting network. For example, the multiple network devices may comprise multiple lighting network devices. A lighting network device comprises an element for light emitting, such an element may comprise an LED, a fitting, a light bulb, and the like. For example, the multiple network devices may comprise multiple switching or dimming network devices. A switching network device or dimming network device allow a user to switch or dim a lighting network device. Network 100 may comprise one or more management devices for controlling the lighting according to user inputs, a lighting schedule and sensor inputs, in particular ambient light sensors.

Network 100 may comprise a home automation network, domotic network and so on, e.g., for control of heating, ventilation, and/or air conditioning (HVAC). Network 100 may comprise a security network to protect against physical intrusion. For example, the latter network may comprise network devices arranged as camera, sensors, e.g., motion sensors, e.g., PIR sensors, sensors arranged to detect the opening of doors, windows and the like, sensors arranged to detect smoke, heat, and the like. Various network types may be combined, e.g., controlling lighting, HVAC, security and so on. Generally speaking network 100 may comprise network devices arranged as computers, sensors, etc.

A network device is fully part of a network if it has been commissioned with security information, e.g., a key, such as a network key. Before being commissioned, a network device may already exchange messages with an enrollment device, this could be out of band, but it could also be over the network. For example, the network device may achieve an initial association with the enrollment device, allowing the network device and enrollment device to exchange messages. Messages using the initial association are not protected, and could be fake messages or eavesdropped upon.

Network device 110 may comprise a processor system 113, a storage 114, and a communication interface 115. Enrollment device 120 may comprise a processor system 123, a storage 124, and a communication interface 125. Server device 130 may comprise a processor system 134, a storage 134, and a communication interface 135.

Storage 114, 124 and 134 may be, e.g., electronic storage, magnetic storage, etc. The storage may comprise local storage, e.g., a local hard drive or electronic memory. Storage 114, 124 and 134 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 114, 124 and 134 may comprise a storage interface to the non-local storage. Storage may comprise multiple discrete sub-storages together making up storage 114, 124. Storage may comprise a volatile writable part, say a RAM, a non-volatile writable part, e.g., Flash, a non-volatile non-writable part, e.g., ROM.

Network device 110 is configured to store data representing a cryptographic install key for the first network device and an identifier for the first network device. For example, the data representing the cryptographic install key may be stored in storage 114. The representing data stored may be the key itself, or may be used to derive the key from, e.g., directly derive the key from. For example, a value N may be stored so that the install key is obtained when needed by the network device by applying a key derivation function, e.g., f(N). The install key, or the data representing it, may be random or contain a random element. For example, the install key may be at least 40 bits, 80 bits, 128 bits, 256 bits, etc. Typically, the install key is a symmetric key.

The identifier for the first network device, e.g., denoted ID, is typically unique across all network devices that may communicate with remote server 130. This is not strictly necessary though; for example, two devices could share an ID for the purpose of commissioning if they also share an install key; after commissioning the enrollment device may assign a network unique identifier to the network device. Using a globally unique identifier for the ID is however convenient. Such an identifier is sometimes referred to as a universally unique identifier (UUID), or as a globally unique identifier (GUID), or as EUI64, e.g., as used in Zigbee or elsewhere. In an embodiment, network device 110 may comprise multiple identifiers, e.g., for different purposes, e.g., to obtain different keys, join different networks and the like. For example, a network device may comprise a first identifier for enrolling in a Zigbee network, and a second identifier for enrolling in a Wi-Fi network. Communication interface 115 may be configured for communication with enrollment device 120, e.g., to send or receive enrollment messages, receive encrypted keys, and so on. Processor system 113 is configured for joining network 100. For example, processor system 113 may be configured with a protocol that processor system 113 performs together with enrollment device 120.

In an embodiment, the joining of network 110 comprises sending to enrollment device 120 the identifier (Id) of network device HO, receiving from enrollment device 120 encrypted data, and decrypting the encrypted data with the install key to obtain a cryptographic key for protecting communication on the network.

Because the cryptographic key is obtained from data that is transmitted in encrypted form, it is harder for an attacker to make use of data that he might eavesdrop upon. The cryptographic key that is thus obtain may be, e.g., a network key, link key or the like. The obtained key may be stored in storage 114.

The exchange of messages between the network device and the enrollment device may be over a wireless network, e.g., using an initial network association. Interestingly, a key can be securely transferred over such an unprotected wireless connection using an embodiment.

Enrollment device 120 is configured to store the cryptographic key for protecting communication on the network. This cryptographic key needs to be transferred to a new network device during its enrollment or commissioning. Enrollment device 120 itself may obtain the cryptographic key from various sources. For example, enrollment device 120 may receive the key from some other device in network 100, e.g., typically a controller or network device, or other device that has the key. Enrollment device may have the key because it is configured for operation on network 100; e.g., enrollment device may be a controller of network 100. For example, the key may be stored in storage 124. The key may be network key or link key, etc. Note that configuring an enrollment device is much less burdensome, as there is typically only one or few enrollment devices.

For example, the enrollment device may be a controller, e.g., configured to control aspects of the network operation, e.g., routing of data in the network, e.g., configured to control the network device themselves, e.g., in case of a lighting network, controlling light emitting parts comprised in the network devices.

Communication interface 125 is configured for two types of communication: to the network devices, e.g., to network device 110, but also to server 130. The modalities of the communication with a network device 110 and of communication with server 130 may be different. For example, the network devices may form or be part of a local network, e.g., first network 172. An example, of first network 172 and second network 173 is shown in figure Id. Communication in first network 172 may be, e.g., ZigBee, Wi-Fi, Ethernet, and so on, and combinations thereof.

For example, the ZigBee network may be as described in ZigBee Document 05-3474-21, August 5, 2015, included herein by reference; the ZigBee standard may be adapted according to an embodiment.

Enrollment device 120 is configured to send and receive messages in first network 172. For example, enrollment device 120 may be a controller in first network 172. For example, enrollment device 120 may be an installer for first network 172. An installer may be a mobile device configured to interact with a network device. For example, an installer may comprise a laser device for optical communication to a network device. A particular interesting option is that the enrollment device is a mobile phone. For example, a software package, e.g., a so-called app, may be installed on the mobile phone to configure the mobile phone as an enrollment device. Enrollment device 120 may be part of network 100, though this may be only temporarily, e.g., during enrollment.

Enrollment device 120 may communicate with server 130 over a second network 173, typically the Internet. It is not necessary though that enrollment device 120 and server 130 form a network, e.g., they may be directly connected, e.g., through a data line, e.g., a telephone line.

Processor system 123 is configured for joining network device 110 into network 100. For example, processor system 123 may be configured to perform a protocol together with network device 110. The joining on the side of enrollment device 120 may comprise receiving from the network device 110 the identifier for network device 110, sending to remote server 130 the identifier for network device 110 and the cryptographic key for protecting communication on the network, receiving from remote server 130 encrypted data, encrypted with the install key of the first network device, the encrypted data comprising the cryptographic key for protecting communication on the network, sending the encrypted data to network device 110.

Enrollment device 120 can provide remote server 130 with the cryptographic key as the possibility for attack are smaller than between enrollment device 120 and network device 110. For example, communication between enrollment device 120 and server 130 may be protected with conventional means, e.g., encrypted, integrity protected and the like, e.g., using key negotiated in a key exchange protocol, e.g., using asymmetric keys of the enrollment device and/or server 130. Protection of the link between the enrollment device and the server is less intrusive as this is only one link, or only few links, typically much less than the number of network devices.

Interestingly, enrollment device 120 does not receive network device 110’s install key, neither from network device 110 nor from server 130. This increases security, as a key that is not shared with the enrollment device cannot be leaked at the enrollment device either. This means that an attacker who wishes to obtain the install key needs either to obtain it from the network device, this will likely involve physical access and also make large scale attacks much harder, or from server 130. Obtaining the keys from server 130 is likely to be much harder, as server 130 can be better protected than the multiple network devices.

Server device 130 is configured to store multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys for said multiple network devices. For example, the multiple identifiers and/or their corresponding data may be stored in storage 134.

Server 130 may have access to a database 162. Database 162 is also external to network device 110 and enrollment device 120. Database 162 may store the multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys. Database 162 may be part of server 130 and/or local to server 130. Database 162 is part of storage 134. Database 162 may be external to server 130; for example, server 130 may be arranged with a database interface configured to access database 130, e.g., in the cloud, across a computer network, etc. Server 130 comprises a communication interface 135 configured for communication with enrollment device 120. Communication interface 135 may also be configured for other purposes, e.g., access to database 162, communication with a device manufacture to receive IDs and install keys, communication with other servers, and so on.

Processor system 133 is configured for assisting the enrollment device in joining the first network device into the network. Enrollment device 120 is not allowed access to the install key. Instead encryption with the install key is done by server 130. In an embodiment, the assisting comprises receiving from enrollment device 120 the identifier for network device 110 and the cryptographic key for protecting communication on the network, looking up the identifier for network device 110 to obtain the install key of network device 110, encrypting the cryptographic key for protecting communication on network 100 with the install key of network device 110 to obtain the encrypted data, sending the encrypted data to enrollment device 120.

Network device 110, enrollment device 120 and server 130 may communicate internally, with each other, with other devices, external storage, input devices, output devices, and/or one or more sensors over one or more computer networks. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. Network device 110, and enrollment device 120 comprise a connection interface which is arranged to communicate within network 100 or outside of network 100 as needed. Enrollment device 120 and server 130 comprise a connection interface which is arranged to communicate with each other, e.g., within a network, which may be a further network.

For example, the connection interfaces of network device 110, enrollment device 120 and server 130 may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna.

The communication interface 115 may be used to send or receive digital data. For example, network device 110 may send a request to join network 100, e.g., to enrollment device 120. For example, network device 110 may instead receive a request to join network 100, e.g., from enrollment device 120. For example, network device 110 may receive encrypted cryptographic key from enrollment device 120 over communication interface 115. The communication interface 125 may be used to send or receive digital data. For example, enrollment device 120 may receive a request to join network 100 from network device 110. On the other hand, the initiative may also come from enrollment 120, which may send a request to network device 110 to join network 100; this is sometimes referred to as a trigger signal. Enrollment device 120 may send a key to server 130 and receive the key back in encrypted form. The encrypted key may then be forwarded, packaged in a data packet, to network device 110.

The communication interface 135 may be used to send or receive digital data. For example, server 130 may receive a key and ID from server 120, possibly encrypted using a key known to server 130 and enrollment device 120, or using a private key of server 130, the public key being known the enrollment device 120. The key, possibly after decryption, is encrypted using the install key of network device 110.

The execution of network device 110, enrollment device 120 and server 130 may be implemented in a processor system. The devices 110, 120 and 130 may comprise functional units to implement aspects of embodiments. The functional units may be part of the processor system. For example, functional units shown herein may be wholly or partially implemented in computer instructions that are stored in a storage of the device and executable by the processor system.

The processor system may comprise one or more processor circuits, e.g., microprocessors, CPUs, GPUs, etc. Devices 110, 120 and 130 may comprise multiple processors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. For example, devices 110, 120 and 130 may use cloud computing.

Typically, network device 110, enrollment device 120 and server 130 each comprise a microprocessor which executes appropriate software stored at the device; for example, that software may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash.

Instead of using software to implement a function, the devices 110, 120 and/or 130 may, in whole or in part, be implemented in programmable logic, e.g., as field- programmable gate array (FPGA). The devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL, etc. In particular, network device 110 and enrollment device 120 may comprise circuits, e.g., for cryptographic processing, and/or arithmetic processing. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., cryptographic coprocessors, and partially in software stored and executed on the device.

Figure Id schematically shows an example of an embodiment of a network system. Network system 180 may comprise two networks: network 172 and network 173. Network 172 comprises multiple network devices; shown are a first network device 110.1 and a second network device 110.2. The second network 172 comprises server 130. Enrollment device 120 is part of both first network 172 and second network 173. In an embodiment, networks 172 and 173 could be the same network, e.g., both could be the Internet. In an embodiment, networks 172 and 173 could be different networks, possibly even using different network technologies. For example, first network 172 may be a ZigBee network, or a Wi-Fi network, or the like, while second network 173 may be a LAN, WLAN, internet, or Internet type network, etc. In a typical example, first network 172 is a wireless network, or a partially wireless network, for example, one or more of the network devices communicate wirelessly over network 172; network 173 is then typically wired, or partially wired. Enrollment of wireless devices, especially, in a situation where the number of network devices is large, or the network devices may not be easily accessible, an enrollment according to an embodiment is particularly advantageous.

Networks 172 and 173 may comprise additional elements, e.g., a router, a hub, etc., than are shown in the figures.

Network system 180 comprises network devices 110, enrollment device 120, and server device 130.

The network devices and enrollment device 120 are connected through a first computer network 172, e.g., a wireless network, such as a ZigBee network. Enrollment device 120 and server device 130 are connected through a second computer network 173.

Network 172 may comprise further network devices. One such further device 140.1 is shown. For example, enrollment device 120 may be an installer device which is specifically for enrollment, while further device 140 is a controller to control network 172. For example, device 140 may be network router, Wi-Fi hub or the like. For example, device 140.1 may be lighting controller, e.g., controlling the switching of lighting devices, e.g., comprised in the network devices. Further device 140 may also be a network device. Enrollment device 120 may cooperate with further device 140. For example, the enrollment device may be a mobile device for local communication with a network device, while the communication with server 130 is done by enrollment device 120. The enrollment device, in particular an installer device, may be configured for setting up/building a network 172 comprising the network devices. For example, an installer device may send a trigger signal to a network device. An example of such a trigger signal is a laser pointer signal or an infrared signal, or a wireless radio signal. The trigger signal causes the network device to send its identifier, e.g., to the enrollment device, e.g., wirelessly, or optically, etc. An installer may be a smartphone. A smartphone may send a trigger signal in the form of a wireless signal, e.g., Bluetooth, NFC, Wi-Fi, Zigbee signal. The smartphone may cooperate with a further enrollment device on the network, e.g., a controller, coordinator, bridge, or the like.

The enrollment device may also operate without using a mobile installer device. For example, commissioning could take place wirelessly over the network. A new network device may send its identifier wirelessly and receive, e.g., the network key in encrypted form. It is an advantage of such embodiments that no manual intervention is needed. The process could be initiated either by an existing device on the network, e.g., a controller, etc., or by the network device.

Figure Id shows a single enrollment device 120; this is not necessary though. For example, multiple persons could use multiple enrollment devices to enroll multiple network devices in parallel.

Enrollment device 120, may be a so-called coordinator device, e.g., a ZigBee coordinator. A coordinator may be a process that could run in one or more devices. For example, the coordinator could run in a bridge and/or gateway type of device, a phone, or even in the cloud. In the latter case, some other device may be configured to relay messages, e.g., further device 140. Enrollment device 120 is not restricted to a particular type of device. In particular, enrollment device 120 does not have to be a coordinator; in fact a coordinator may not even be present in network system 180. Enrollment device 120 may be, e.g., a phone, e.g., configured to relay messages between a network device and server. For example, one could adapt the mechanism for Zigbee Direct by configuring a phone to set up a local wireless connection with a network device, e.g., a light, e.g., using Bluetooth, e.g., BLE, or NFC, or the like, wherein the connection is protected with the install code of the light. In an embodiment, a cryptographic key is communicated from enrollment device 120 to network device 110, protected against eavesdropping because the cryptographic key is encrypted with an install key. Yet, enrollment device 120 does not learn the install key with which that cryptographic key is encrypted. The install key is therefore protected from attacks on enrollment device 120, e.g., from a hacked enrollment device 120. The cryptographic key that is thus transported from the enrollment device to the network device could be used for various purposes. For example, the cryptographic key may comprise a network key. The network key is stored at all network devices in the network. Messages between network devices may be encrypted with the network key.

The cryptographic key may comprise a link key. The link key is not stored at all network devices. Typically, the link key would be stored at few network devices, typically two or three other devices, e.g., the network device, the enrollment device and/or a controller, coordinator, or the like. For example, enrollment device 120 may be configured to use the link key to protect messages exchanged between the network device and the enrollment device.

The cryptographic key may be used for integrity protection as well as for encryption. Alternatively, a key specific for integrity protection may be transferred using an embodiment as well. For example, an authentication key may be transferred from enrollment device 120 to network device 110. The authentication key may be a symmetric key which may be used for integrity protection of network data on network 172; for example, message authentication codes may be computed with the authentication key.

Typically, the cryptographic key is a symmetric key. This is not strictly necessary, in an embodiment, an asymmetric key, or key-pair, may be transferred. This is advantageous, as the generation of an asymmetric key can be resource intensive, possibly, more so than can be conveniently done at a network device. For example, the enrollment device may generate an asymmetric key and transfer it to a network device according to an embodiment.

Server 130 has access to a list of network device identifiers and their corresponding install keys, e.g., in the form of a database. The information may typically be stored in database 162 together with manufacture of the network device. This is not necessary though; the information may be stored at server 130 at a later date. For example, server 130 may receive information concerning a set of network devices that are already in operation.

For example, a set of network devices may be conventionally enrolled, e.g., using an install code printed on the device, e.g., in a QR code. At that point the identifier of the network device and its install key may be stored at server 130. If the network device is at some point reconfigured, e.g., joined in a new network or the like, then the new network key(s) may be transferred to the network device according to an embodiment.

Server 130 is configured to encrypt a cryptographic key received from enrollment device 120 with an install key of a network device. Encrypting of the cryptographic key may depend on further information than the install key. For example, the identifier of network device 110 and/or an identifier of enrollment device 120 may be included in the encryption. This binds the particular encryption to network device 110 and/or to enrollment device 120.

The communication between enrollment device 120 and server 130 may be protected in various ways. This improves security. For example, server 130 may be configured to authenticate enrollment device 120 before sending an encrypted key or keys to enrollment device.

For example, enrollment device 120 may be configured to authenticate server 130 before sending the cryptographic key to server 130.

For example, server 130 may be configured to obtain, e.g., by means of the authentication, an authenticated identifier of the enrollment device 120 at the remote server 130. Such an authenticated identifier may then be included in the encryption of the cryptographic key. Including an identifier may be done in various ways, e.g., a key may be derived from the install key and the identifier. For example, the identifier may be included in a counter when using counter-mode block-cipher encryption. The network device may obtain the identifier from the enrollment device, and use it in its decryption. If an attacker interferes with the system, so that, e.g., the network device receives a different identifier of the enrollment device than the server, the decryption of the key will fail — more precisely, although some decryption will proceed, the authentication check will fail.

In an embodiment first network 172 is a ZigBee network, wherein the encrypted data is placed by the enrollment device 120 in a Transport Key Data field. For example, one could use the 'Transport-Key Command Frame', see., e.g., section 4.4.10.1 of the ZigBee specification, e.g., as in ZigBee Document 05-3474-21, August 5, 2015.

Figure 2 schematically shows an example of an enrollment of a network device joining a network. The figure shows three timelines in which some relevant steps are included. Time advances from the top of the page to the bottom. Arrows between the timelines indicate messages sent and/or received.

Shown is a timeline for a network device 210 that is to join the network (the joiner), an enrollment device 220, and a server 230. For example, network device 210 may be light in a lighting network; enrollment device 220 may be an installer device, a coordinator, a bridge, etc.; server 230 may be a service running in the cloud.

A contact is established between network device 210 and enrollment device 220 in network association 241. For example, this may be an 802.15.4 association. For example, network device 210 may send a join request to enrollment device 220, or vice versa, enrollment device 220 may send request to network device 210 to join. In association 241, network device sends at least the identifier of network device 210 to enrollment device 220. Association 241 may comprise multiple messages. After the association, messages may be exchanged digitally, although these are not encrypted with the network key or the like.

Enrollment device 220 sends first message 245 to server 230. First message 245 may comprise the identifier of network device 210, a key that is to be transported to network device 210, e.g., the network key or link key. Enrollment device 220 may also send additional data to server 230. For example, the additional data may be encrypted by server 230 as well. For example, additional data may be instead or in addition integrity protected. For example, additional data may be used in the encryption. For example, the additional data may include a nonce, or an identifier of enrollment device 220.

Additional data may comprise, e.g., MAC address of the enrollment device, a frame counter, etc. Additional data may be used for CCM mode block cipher encryption.

Server 230 is configured to retrieve the install key of network device 210 and use it to encrypt the key received from enrollment device 220. The encrypted key is then sent to enrollment device 220 in a second message 246. Enrollment device 220 forwards the encrypted data, but may perform a packaging operation 221, e.g., for compatibility. For example, enrollment device 220 may construct a transport key. Finally, in a third message 247 the encrypted key is sent to network device 210. Note that packaging operation 221 does not encrypt the network key with the install key, this is already done by server 230.

Not shown separately in figure 2 is that the encrypted data may be decrypted by network device 210 using its install key. Now that both network device 210 and enrollment device 220 have the same key, they may use the key to protect future communication. For example, network device 210 and enrollment device 220 may perform a key verification protocol, to verify that they have the same key. The key verification protocol may also be performed with a different device. For example, if enrollment device 220 is a dedicated installer, the key confirmation may be done with another network device, e.g., a controller, coordinator, or the like.

The network association 241may be a ZigBee association according to 802.15.4. After the association the network device and the enrollment device can communicate but do not have a shared network key. Communication between enrollment device 220 and server 230 may be implemented by other means, e.g., a web socket connection, protected by certificates. Below additional information, including additional embodiments are presented. Some examples are described in the context of enrolling a device in a ZigBee network. This is an important application. For example, ZigBee is an advantageous choice for a lighting network. For example, multiple lighting devices may be arranged with a ZigBee unit for receiving and sending ZigBee messages according to the ZigBee standard. However, it should be borne in mind, that other network technologies can be used to replace ZigBee. For example, instead of ZigBee one might use other communication protocols on both wired and wireless networks such as Bluetooth, Wi-Fi, Thread, Matter, etc.

In an embodiment, enrollment uses a remote server 130, e.g., to transfer a network key or a link key to a network device. Advantageously, an embodiment may extend the standard install-code-based joining flow with a cloud service. This improves enrollment while retaining backward compatibility for network devices. For example, an existing network device may expect an encrypted network key at a particular location in a network message; according to an embodiment, the network key may be encrypted in the same manner, but not performed by the enrollment device but by the server.

The server has access to a database that contains the install codes of manufactured devices. At manufacturing time a device’s install code may be added to the cloud database so it can be used later. During commissioning, an enrollment device, e.g., a bridge interacts with the cloud. The server uses the install code of a joining device to perform an encryption of, say, the network key of the local network.

In a process for joining a secured network multiple messages may be exchanged with the new network device. As an example, in Zigbee these may be the following, see, e.g., the Zigbee specification (section 4.6.3.1):

1. Beacon request sent by the j oiner to find open networks.

2. Beacon sent by a Zigbee router/coordinator to announce the network and to convey whether the network is open for joining.

3. Association request sent by the j oiner to request a network address.

4. Association response sent by the Zigbee router/coordinator to indicate whether joining was successful and assigning the new network address to the joiner.

5. Transport key message to send the network key from the router/coordinator to the joiner.

6. Optionally: Transport key to send a new trust center link key to the joiner. A coordinator may be configured for, e.g., admitting new devices, remove devices, roll the network key. Bridge and lights may be accessories. A bridge may perform coordinator tasks, but may also bridge too Wi-Fi, or the like.

For example, the network key may be used after installation to send messages to and from a switch, dimmer, light, etc., encrypted with the network key.

The trust center link key is typically only shared between two participants. For example, every network device has its own trust center link key with the trust center.

Typically, the trust center is the coordinator, though this is not necessary.

Typically, keys are finally verified and confirmed.

Messages 5 and 6 are encrypted with a link key. This could be done as follows:

• Default trust center link key. A global key that is shared across all Zigbee devices.

• Install code-. A device-specific key that is different for each device. The install code, or install key, is known to the device. The install code may be printed on the device in the form of a QR code or as ASCII. If the coordinator is to know the install key, it can be communicated to the coordinator before the device joins the network. This can, for instance, be done by scanning the QR code using a smartphone app and sending the install code to the coordinator.

However, according to an embodiment, it is avoided to share the install key with the coordinator.

A coordinator is an example of an enrollment device. A coordinator is not the only example of an enrollment device. For example, an enrollment device may be a dedicated installer. For example, an enrollment device may be a smartphone configured as an enrollment device. For example, the light, bridge, and cloud device could implement the embodiment of figure 2, implementing respectively a network device, an enrollment device, and a server.

The install code may be used in the joining flow to encrypt the Transport Key frames. Specifically, the APS layer in these frames may be encrypted with a key derived from the install code. The key is known to the joining device; thus it can decrypt that layer and obtain its plain-text contents. Because attackers do not know the key, they cannot decrypt the APS layer to obtain the network key. Note that the install key need not be stored directly, but may be derived from stored information.

A request for a database lookup may be performed by the coordinator or bridge after receiving an Association Request and before sending a Transport Key message. The coordinator sends all the relevant data, an identifier of the joining device, e.g., the EUI64 (Zigbee extended address), an encryption nonce, associated data, and a plaintext to the server. The server service performs a lookup of the install code for the specified EUI64 in the database and then performs an AES-CCM encryption of the plaintext with the received nonce and associated data. This produces a ciphertext and message integrity code (MIC). These are returned to the coordinator. The coordinator embeds the ciphertext and MIC in a networklayer frame to assemble the full Transport Key frame. This Transport Key frame is sent to the joining device. The joining device can successfully decrypt this message based on its install code to retrieve the network key and communicate securely after confirming this key. Figure 3 schematically shows an example of an enrollment of a network device joining a network. Shown in figure 3 is a light 310, which is an example of a network device, a bridge 320 which is an example of an enrollment device, a server 330. Server 330 may be implemented in the cloud.

Shown in figure 3 is a beacon request 341, beacon 342, association request 343, and an association response 344. In these four messages the light and the bridge establish an association. The light and bridge can now communicate, although they do have a shared key, e.g., no network or link key. This means that any communication between them can be eavesdropped upon by an attacker. These four messages could be replaced with some other exchanges of messages to establish communication, and/or establish that bridge 320 will continue with joining device 310.

Bridge 320 will then send to the server a message 345 with the network device identifier of light 310, a key, e.g., the network key, and possibly other information. For example, message 345 may comprise a network device identifier, nonce 1, assoc datal, and plaintextl. For example, the network device identifier may be the EUI64 of the light. Noncel may be computed by the bridge. Plaintextl may comprise the key to be encrypted.

Server 330 may then perform operation 331 comprising looking-up the install code of the light 310, operation 332 comprising verifying noncel and operation 333 comprising CCM encrypt plaintexl and producing MIC. Instead of CCM encryption one could choose another type of encryption. Instead of a MIC according to ZigBee some other type of message authentication code may be computed. Verifying noncel may comprise verifying that the nonce is used for the first time, and/or verifying that nonce comprises its mandatory parts. Instead of verifying a nonce, the server could compute the nonce itself. The encryption in operation 333 uses an install key derived from the install code. In message 346 the ciphertext containing the encrypted key and the MIC are sent to the Bridge 320. In operation 321, Bridge 320 constructs a transport key. In message 347 the transport key, in this case the network key, is sent to the light 310.

Optionally, a similar protocol may then be followed for a further key, e.g., the link key. In message 348, bridge 320 sends the network device identifier, nonce2, assoc_data2, and plaintext2 to server 330. The plaintext2 comprises the link key. In operation 334, server 330 then looks up the install code. In operation 335, server 330 verifies nonce2 and in operation 336, server 330 performs a CCM encryption of plaintex2 and produce the MIC. In message 439 the ciphertext, and MIC are sent to bridge 320. In operation 322, bridge 320 constructs the transport key. In message 350 the transport key, in this case the link key is sent to the light 310. Optionally, light 310 may send a verify key message, which Bridge 320 may respond to with a confirm key message 352.

In figure 3, the bridge may be instead by a coordinator or an installer, or more generally any enrollment device. Light 310 may be any other device in a lighting network, e.g., a switch, a dimmer, and the like. More generally, light 310 may be any other network device.

Note that the install code is never sent to the bridge or coordinator. Doing so would introduce a security vulnerability in the system. An attacker could record the messages exchanged between a joining device and the coordinator. He would then be able to fetch the install code from the server and decrypt the Transport Key frames. Therefore, all encryption operations are performed by the server and the bridge never needs to use the install code.

Zigbee describes how the AES-CCM encryption key is derived from the install code and how the nonce, associated data, and plaintext need to be constructed. Specifically:

• The encryption key is derived from the Install Code: o Key = HMAC-AES-MMO(AES-MMO(install code), key-type=0x00)) for the Transport Key frame that transports the network key. o Key = HMAC-AES-MMO(AES-MMO(install code), key-type=0x02)) for the Transport Key frame that transports the trust center link key.

• The nonce is composed of the source address of the trust center/coordinator, the current frame counter, and the security control byte that encodes the security settings.

• The associated data is composed of the frame control field, the counter, the security control, the current frame counter, and the source address of the trust center/coordinator. • The plaintext data comprises the command identifier, the key type (network key or trust center link key), the key, the key sequence number (in case of a network key), the destination address, and the source address of the trust center/coordinator.

The above is exemplifying. For example, an encryption key may be derived from an Install Code using any other key derivation function. Instead of an install code, one may use a key directly, etc. Instead of composing a nonce from specified data elements, the nonce could be selected randomly, possibly jointly with the other party. Instead of CCM mode encryption, one could use another block cipher mode, for example, CBC encryption. For example, the nonce may be used as an IV for the CBC encryption. If desired a separate MAC may be computed for the MIC, e.g., a CMAC, or HMAC or the like.

Figure 4 schematically shows an example of an encryption operation, summarizing possible inputs and outputs of the encryption operation, e.g., operation 333 and 336. Parts 420, 430 and 450 are performed by server 330. Parts 441, 442 and 443 are constructed by bridge 320, or a trust center coordinator, installer, or the like.

Part 420 is an AES-MMO receiving as input install code 401. Part 430 is an HMAC-AES-MMO receiving as input a key type 402 and a key 403. Part 430 produces a key 407, e.g., the install key. Parts 420 and 430 together show an example of deriving a key from data representing the key. Other key derivation functions are possible.

Part 450 is an CCM encrypt receiving as input a key 407, a nonce 408, associated data 409 and plaintext 410. Nonce 408 is constructed in part 441 from input 404. Part 441 concatenates the trust center EUI64, the frame counter and the sec ctrl byte. Associated data 409 is constructed in part 442 from input 405. Part 442 concatenates the frame control field, counter, security control, frame counter, and trust center EUI64. Plaintext 410 is constructed in part 443 from input 406. Part 443 concatenates the command identifier, key type, key, key sequence number, destination EUI64 and Trust center EUI64. Part 450 produces ciphertext 411 and MIC 412.

Part 450 is an example of encrypting a cryptographic key. Part 450 is an example of encrypting additional information to allow the network device to verify the authenticity of the encrypted data. Ciphertext 411 is an example of an encrypted key. MIC 412 is an example of a message authentication code.

The skilled person will realize that data elements of figure 4 can be omitted or varied.

The frame counter is the number of frames that has been sent with this key and with this install code. The bridge remembers device so that it can increase this number. The Frame counter in the associated data is the same as in the nonce. Note that the trust center and bridge have the same EUI64.

The key type is a 1 byte to identify the key type. The key may be for example, a network key or link key. The key sequence number may be used to roll the key, in which case it is increased. The destination EUI64 is the identifier of the light. Note that some EUI are used multiple times, which could be omitted in a variant. Note that the encryption operation shown in figure 4 represents a particular choice for an advanced encryption operation satisfying various other goals. This choice for an encryption operation is not needed for all embodiments.

Depending on the specific cryptographic algorithm that is used to protect key transport, the input from the bridge preferably satisfies certain properties. For example, for Zigbee one may verify the following various further elements.

The server may verify the uniqueness of the nonce 408. This is increases security, since it avoids that a key might be used for encryption with the same nonce twice. This is especially relevant for some encryption modes, such as AES-CCM mode of encryption (specifically the AES-CTR part thereof). If nonces are reused, then the server can be used as a decryption oracle by providing a ciphertext with the same nonce. The server would then simply decrypt the ciphertext and return the plaintext. One way to verify uniqueness of the nonce is by verifying the nonce before encryption and storing the nonce in a list of “used” nonces. Each time a new ciphertext is requested, the nonce is verified against this list. If it is there, then the request is refused. If it is not there, then it is stored and added to the list and the server continues with the request.

The server may verify that the sender identity matches the EUI64 in the nonce. If this is not done, then a rogue bridge might be used to decrypt a ciphertext obtained from a light joining after a QR code scan. For example, the serve may identify the bridge using an authentication mechanism, which produces an authenticated identity, e.g., the bridge’s EUI64. For example, the bridge certificate may contain the EUI64 and the public key, and certificate is signed. The server may verify that the bridge identity during authentication is the same as in the nonce. For example, a TLS connection may be set up between bridge 320 and server 330 that is authenticated.

There is a risk of denial-of-service attack if a rogue bridge can request ciphertexts for other bridges since those bridges would not be able to request ciphertexts for the same light with the same nonce. Verification can be done by extracting the coordinator EUI64 from the nonce and verifying that the request was received from the device that performs the request. Alternatively, the coordinator EUI64 can be substituted into the nonce by the server. The specific implementation is out of scope of this invention disclosure but can be solved using standard REST API security based on secure connections.

In an embodiment, an enrollment may be configured with a fallback enrollment method in which the cryptographic key is encrypted using a default link key, e.g., the default trust center link key.

In an embodiment, old devices may not have an install code. In that case, the server is not able to perform the encryption with the install code. For example, in an embodiment, the server may reject the request and inform the bridge that it does not have the install code for the joining device. In an embodiment, the processes the request but uses the default trust center link key for encryption or a proprietary global key. The server may additionally inform the bridge that it failed to retrieve the install code.

In both cases, the bridge may have the option to inform the user that it falls back to less secure legacy commissioning.

In an embodiment, the enrollment device is configured with a first mode and a second mode. The first mode uses the remote server for encryption, e.g., as in an embodiment. In the first mode a user does not need supply the enrollment device with an install key or install code or the like. The encrypted data is received from the remote server and is send on, possibly repackaged, to the network device.

In the second mode, the enrollment device is supplied with the install key. For example, a user may scan a QR code comprising the representing data, e.g., the install code. For example, a user may enter the install key, or an install code, at an input device, e.g., a keyboard. The enrollment device then proceeds itself with encrypting the cryptographic key with the install key without using the remote server. In both modes, the encrypted data is sent to the first network device.

For example, the enrollment may be configurable for which mode to use. For example, a user may select the mode. For example, the enrollment may be configured to switch to the first mode first, and if the first mode fails, to switch to the second mode.

There are several reasons why the server integration may still fail for devices with install codes. For instance, install codes of third-party Zigbee devices may not be available or devices for which the install codes have not yet been recorded may be absent. Temporary network failures may also make it impossible to reach the server. In this case, a user may scan a QR code encoding the install code on the device or read the install code of a device and input it to the coordinator via an out-of-band channel. In an embodiment, the coordinator is supported to receive the key.

If a joining device has an install code but this install code is not in the server’s database, then it can be added after manual scanning or reading. This is, for instance, the case for third-party lights or devices that have been manufactured before install codes were recorded in a database. These install codes can be added to the database after QR code scanning or manual input so that they are available in future commissioning sessions.

In an embodiment, only the user that added an install code can later use them. An additional field may be added in the database indicating which EUI64 added the install code. Upon retrieving the install code, this field must be checked against the requestor’s EUI64. If such a check is not performed, then a rogue bridge may add a known value for an install code of a device that a victim may commission. The server would then encrypt the network key with this key that is known to the attacker. This would leak the network key to the attacker.

Figures 5a, 5b and 5c relate to a network system comprising at least the network device, an enrollment device, and a server device.

Figure 5a schematically shows an example of an embodiment of a method 510 for a network device for joining a digital network. Method 510 is computer implemented and comprises, storing data (511) representing a cryptographic install key for the network device and an identifier for the network device, communicating (512) with the enrollment device, and j oining (513) a network, the j oining comprising sending (514) to the enrollment device the identifier for the network device for joining the network, receiving (515) from the enrollment device encrypted data, and decrypting (516) the encrypted data with the install key to obtain a cryptographic key for protecting communication on the network.

Figure 5b schematically shows an example of an embodiment of method 520 for an enrollment device for joining a network device into a digital network. Method 520 is computer implemented and comprises storing (521) the cryptographic key for protecting communication on the network, communicating (522) with the network device, communicating (523) with a remote server, and joining (524) the network device into the network, the joining comprising receiving (525) from the network device the identifier for the network device, sending (526) to the remote server the identifier for the network device and the cryptographic key for protecting communication on the network, receiving (527) from the remote server encrypted data, encrypted with the install key of the network device, the encrypted data comprising the cryptographic key for protecting communication on the network, sending (528) the encrypted data to the network device.

Figure 5c schematically shows an example of an embodiment of a method 530 for a server device in assisting an enrollment device in joining a network device into a digital network. Method 530 is computer implemented and comprises storing (531) multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys for said multiple network devices, communicating (532) with the enrollment device, and assisting (533) the enrollment device in joining the network device into the network, the assisting comprising receiving (534) from the enrollment device the identifier for the network device and the cryptographic key for protecting communication on the network, looking (535) up the identifier for the network device in the storage to obtain the corresponding install key, encrypting (536) the cryptographic key for protecting communication on the network with the install key of the network device to obtain the encrypted data, sending (537) the encrypted data to the enrollment device.

Many different ways of executing the methods are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be performed in the shown order, but the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, some steps may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.

Embodiments of the method may be executed using software, which comprises instructions for causing a processor system to perform methods 510, 520 and/or 530. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc. The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the Internet. The software may be made available for download and/or for remote usage on a server. Embodiments of the method may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform the method.

It will be appreciated that the presently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the presently disclosed subject matter into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the devices, units and/or parts of at least one of the systems and/or products set forth.

Figure 6a shows a computer readable medium 1000 having a writable part 1010, and a computer readable medium 1001 also having a writable part. Computer readable medium 1000 is shown in the form of an optically readable medium. Computer readable medium 1001 is shown in the form of an electronic memory, in this case a memory card. Computer readable medium 1000 and 1001 may store data 1020 wherein the data may indicate instructions, which when executed by a processor system, cause a processor system to perform a network device method, an enrollment method and/or a server method according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 comprises instructions for causing a processor system to perform the network device method, enrollment method and/or server method according to an embodiment. Figure 6b shows in a schematic representation of a processor system 1140 according to an embodiment of a network device method, an enrollment method and/or a server method according to an embodiment.

The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Figure 6b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and/or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and/or contact-less communication, using an antenna and/or connectors, respectively.

For example, in an embodiment, processor system 1140, e.g., a network device, enrollment device or server device may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. In an embodiment, the processor circuit may be ARM Cortex M0. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a nonvolatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.

It will be apparent that various information described as stored in the storage 1160 may be additionally or alternatively stored in the memory 1130. In this respect, the memory 1130 may also be considered to constitute a “storage device” and the storage 1160 may be considered a “memory.” Various other arrangements will be apparent. Further, the memory 1130 and storage 1160 may both be considered to be “non-transitory machine- readable media.” As used herein, the term “non-transitory” will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.

While device 1100 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processor 1120 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the device 1100 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 1120 may include a first processor in a first server and a second processor in a second server.

It should be noted that the above-mentioned embodiments illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb ‘comprise’ and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article ‘a’ or ‘an’ preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of’ when preceding a list of elements represent a selection of all or of any subset of elements from the list. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The presently disclosed subject matter may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In the device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

In the claims references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.

Claims

33 CLAIMS:

1. A digital network system comprising at least a first network device, an enrollment device, and a remote server, wherein

A: the first network device comprises a storage configured to store data representing a cryptographic install key for the first network device and an identifier for the first network device, a communication interface configured for communication with the enrollment device, and a processor system configured for joining a network, the joining comprising sending to the enrollment device the identifier for the first network device for joining the network, receiving from the enrollment device encrypted data, and decrypting the encrypted data with the install key to obtain a cryptographic key for protecting communication on the network, and wherein

B: the enrollment device comprises a storage configured to store the cryptographic key for protecting communication on the network, a communication interface configured for communication with the first network device, a communication interface configured for communication with the remote server, and a processor system configured for joining the first network device into the network, the joining comprising receiving from the first network device the identifier for the first network device, sending to the remote server the identifier for the first network device and the cryptographic key for protecting communication on the network, 34 receiving from the remote server encrypted data, encrypted with the install key of the first network device, the encrypted data comprising the cryptographic key for protecting communication on the network, sending the encrypted data to the first network device, and wherein

C: the remote server comprises a storage configured to store multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys for said multiple network devices, a communication interface configured for communication with the enrollment device, and a processor system configured for assisting the enrollment device in joining the first network device into the network, the assisting comprising receiving from the enrollment device the identifier for the first network device and the cryptographic key for protecting communication on the network, looking up the identifier for the first network device in the storage to obtain the corresponding install key, encrypting the cryptographic key for protecting communication on the network with the install key of the first network device to obtain the encrypted data, sending the encrypted data to the enrollment device.

2. A digital network system as in Claim 1, wherein neither the install key nor data representing the install key is communicated with or stored at the enrollment device (120).

3. A digital network system as in Claim 1 or 2, wherein the network is a lighting network and the first network device is a lighting device.

4. A digital network system as in any one of the preceding claims, wherein the cryptographic key for protecting communication on the network comprises a network key, the network key being stored at all network devices in the network, the processor system of the first network device and/or enrollment device being configured to decrypt and/or encrypt messages in the network with the network key, and/or the cryptographic key for protecting communication on the network comprises a link key, the link key being stored only at the first network device and the enrollment device, the processor system of the first network device and/or enrollment device being configured to decrypt and/or encrypt messages exchanged with each other in the network with the link key.

5. A digital network system as in any one of the preceding claims, wherein the encrypting of the cryptographic key for protecting communication on the network by the remote server, and the decrypting of the encrypted data by the first network device further depends on an identifier of the first network device and/or an identifier of the enrollment device.

6. A digital network system as in any one of the preceding claims, comprising an install device for storing identifiers for network devices and corresponding data representing cryptographic install keys at the remote server, wherein said storing is done after manufacture of the network device, but before first operational use of the network device, and/or said storing is done after first operational use of the network device.

7. A digital network system as in any one of the preceding claims, wherein the processor systems of the enrollment device and the remote server are configured for the remote server to authenticate the enrollment device and thereby obtain an authenticated identifier of the enrollment device at the remote server, and/or the encrypting of the cryptographic key by the remote server comprises applying a block cipher in counter mode, the counter used in the counter mode comprising the authentic identifier of the enrollment device.

8. A digital network system as in any one of the preceding claims, wherein the enrollment device is configured with a first mode and a second mode, in the first mode, the enrollment device is configured for receiving from the remote server encrypted data, encrypted with the install key of the first network device, and in the second mode, the enrollment device is configured for obtaining data representing a cryptographic install key for the first network device encrypting the cryptographic key for protecting communication on the network with the install key of the first network device to obtain the encrypted data, sending the encrypted data to the first network device.

9. A digital network system as in any one of the preceding claims, backward compatible with ZigBee wherein the encrypted data is placed by the enrollment device in a Transport Key Data field.

10. An enrollment device for use in a digital network system, the network system comprising at least a network device, the enrollment device, and a remote server, wherein the enrollment device comprises a storage configured to store the cryptographic key for protecting communication on the network, a communication interface configured for communication with the network device, a communication interface configured for communication with the remote server, and - a processor system configured for joining the network device into the network, the joining comprising receiving from the network device the identifier for the network device, sending to the remote server the identifier for the network device and the cryptographic key for protecting communication on the network, receiving from the remote server encrypted data, encrypted with the install key of the network device, the encrypted data comprising the cryptographic key for protecting communication on the network, sending the encrypted data to the network device.

11. A server device for use in a digital network system, the network system comprising at least a network device, an enrollment device, and the server, wherein the server comprises a storage configured to store multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys for said multiple network devices, 37 a communication interface configured for communication with the enrollment device, and a processor system configured for assisting the enrollment device in joining the network device into the network, the assisting comprising receiving from the enrollment device the identifier for the network device and the cryptographic key for protecting communication on the network, looking up the identifier for the network device in the storage to obtain the corresponding install key, encrypting the cryptographic key for protecting communication on the network with the install key of the network device to obtain the encrypted data, sending the encrypted data to the enrollment device.

12. A method (520) for an enrollment device for joining a network device into a digital network, a network system comprising at least the network device, the enrollment device, and a server device, wherein the method comprises storing (521) the cryptographic key for protecting communication on the network, communicating (522) with the network device, communicating (523) with a remote server, and joining (524) the network device into the network, the joining comprising receiving (525) from the network device the identifier for the network device, sending (526) to the remote server the identifier for the network device and the cryptographic key for protecting communication on the network, receiving (527) from the remote server encrypted data, encrypted with the install key of the network device, the encrypted data comprising the cryptographic key for protecting communication on the network, sending (528) the encrypted data to the network device.

13. A method (530) for a server device in assisting an enrollment device in joining a network device into a digital network, a network system comprising at least the network device, the enrollment device, and a server device, wherein the method comprises storing (531) multiple identifiers for multiple network devices and corresponding data representing cryptographic install keys for said multiple network devices, communicating (532) with the enrollment device, and 38 assisting (533) the enrollment device in joining the network device into the network, the assisting comprising receiving (534) from the enrollment device the identifier for the network device and the cryptographic key for protecting communication on the network, - looking (535) up the identifier for the network device in the storage to obtain the corresponding install key, encrypting (536) the cryptographic key for protecting communication on the network with the install key of the network device to obtain the encrypted data, sending (537) the encrypted data to the enrollment device.

14. A transitory or non-transitory computer readable medium (1000) comprising data (1020) representing instructions, which when executed by a processor system, cause the processor system to perform the method according to any one of claims 12-13.