Patent Description:
IoT devices are being used increasingly in commercial and residential environments, such as for example in media, environmental monitoring, infrastructure management, manufacturing, agriculture, energy management, medical/healthcare, building and home automation, transportation, and others.

An intrinsic issue of all network-connected computing devices, such as computers and servers, but also nowadays including IoT devices, relates to security. As recent cyberattacks have shown, malware and ransomware is present that can infect a large number of computers within hours. With the rise of IoT devices, it is expected that such cyberattacks will also extend to this type of connected device. In this context, the high number of IoT devices, expected to be installed in the near future and the limiting computing power of typical IoT devices provide challenges.

<CIT> discloses computing device configuration and management using a secure decentralized transaction ledger. In embodiments, a device publishes a broadcast message to one or more nodes that participate in a peer-to-peer network for inclusion in a block in a block chain. In embodiments, the broadcast message requests a provider to provide configuration information or other data. The broadcast message is added to the block chain in the normal course of maintaining the block chain. In embodiments, a provider retrieves the block chain and identifies whether the broadcast message in the block chain is relevant to it. Responsive to the message being relevant to the provider, in embodiments, the provider publishes a response message to one or more nodes in the peer-to-peer network, and the message is then added to the block chain.

The publication "<NPL>, discusses various aspects of blockchains.

<CIT> discloses a method, device and electronic device for recording application program configuration information, used for solving the technical problems in the prior art that the security of application programs is low and the operation of recovery configuration is complicated. The application program is a node in a block chain network where block chains formed by multiple blocks are stored, wherein each block is used for storing information.

Accordingly, an object exists to enable secure configuration and/or secure reconfiguration of electronic devices and in particular network-connected "smart" or "IoT" devices.

In one aspect of the present invention, a computer-implemented method of secure configuration of at least one electronic device is provided. According to the method, the electronic device connects to a blockchain database; determines from said blockchain database a configuration block comprising block identification data, where the block identification data corresponds to device identification data, stored with the electronic device; obtains configuration information from said configuration block; and using the configuration information, conducting configuration of the electronic device.

According to another aspect of the present invention, an electronic device is provided, comprising a network interface for connecting to a communications network and comprising a processing device, connected with the network interface for communicating with at least one blockchain database. According to this aspect, the processing device is configured for connecting to the blockchain database; determining from said blockchain database a configuration block comprising biock identification data, where the block identification data corresponds to device identification data, stored with the electronic device; obtaining configuration information from said configuration block; and using the configuration information, configuring the electronic device.

Reference is also made to the enclosed dependent claims, which describe further embodiments.

Technical features described in this application can be used to construct various embodiments of electronic devices and methods of secure configuration of at least one electronic device according to the preceding and following description. Some embodiments of the invention are discussed so as to enable one skilled in the art to make and use the invention.

In the following explanation of the present invention according to the embodiments described, the terms "connects", "connected to" or "connected with" are used to indicate a data connection between at least two components, devices, units, or modules. Such a connection may be direct between the respective components, devices, units, or modules; or indirect, i.e., over intermediate components, devices, units, or modules. The connection may be permanent or temporary; wireless or conductor based.

For example, a connection may be provided over a WAN (wide area network), LAN (local area network), or PAN (personal area network), comprising, e.g., the Internet, Ethernet networks, Wi-Fi-networks, and cellular networks. A connection may also be provided using the Bluetooth (low energy) protocol, ZigBee protocol, Z-Wave protocol, Wi-Fi protocol and/or other home automation network protocols.

According to a first exemplary aspect, a computer-implemented method of secure configuration of at least one electronic device is provided, wherein the electronic device connects to a blockchain database; determines from said blockchain database a configuration block comprising block identification data, where the block identification data corresponds to device identification data, stored with the electronic device; obtains configuration information from said configuration block; and using the configuration information, conducting configuration of the electronic device.

In the context of the present invention, we refer to a blockchain as having a plurality of (data) blocks, where each block comprises at least information (payload), and a link to a previous block. The link provides that, once a first block and a second subsequent block is recorded in the database, the information in the first block cannot be altered retroactively without the alteration of the second block and all eventual subsequent blocks. Certainly, according to typical blockchain technology, the first "genesis" block does not require a link.

The link may in an embodiment be a cryptographic link, typically also depending on the contents of the referred block itself, such as a cryptographic hash of the previous block, for example using a one-way function (e.g. MD5, SHA-<NUM>, SHA-<NUM>, SHA- <NUM>, BLAKE, BLAKE2). The blockchain certainly and in corresponding embodiments may comprise further elements. For example, each block of the blockchain database may comprise a time stamp.

In the context of the present invention, the term blockchain database may refer to the following setups, where (<NUM>) information is stored as payload in the blocks of the blockchain itself and/or (<NUM>) information is stored by any conventional means outside of the blockchain and in addition has a reference to an entry of the blockchain, for instance, by hashing the information and putting a corresponding hash into the blockchain or by providing a chain or tree of hashes in which a path leads from the hash of the information to the final hash in the blockchain.

According to the above first exemplary aspect, the electronic device connects to a blockchain database. Such connection may be established over a suitable data connection, such as discussed in the preceding. A connection may be established by the electronic device, the blockchain database, or another device in according embodiments. All of these options are summarized herein under the wording that the electronic device "connects to" the blockchain database.

Once connected, the electronic device determines a configuration block from the blockchain database. In the present context, the configuration block is a block of the blockchain database that comprises block identification data where the comprised block identification data corresponds to device identification data, stored with the electronic device. Various subroutines may be used to determine the configuration block from the blockchain database, embodiments of which are discussed in the following description and claims. The device identification data may in an embodiment be predefined, e.g., during manufacturing. In another embodiment, the device identification data may be set by a user of the electronic device. Both procedures provide the benefit of being able to produce identical devices without necessarily requiring to embed individualized tags like unique identifiers or device addresses.

The electronic device then obtains configuration information from the configuration block, i.e., stored in the configuration block in a corresponding embodiment. Then, the electronic device conducts configuration, e.g., a configuration subroutine. For example, the electronic device during configuration may configure components, such as a network interface, an I/O interface, a user interface, a processing device, or any other suitable component. Alternatively or additionally, the electronic device may set device parameters, such as for example network parameters, security parameters, operations parameters, or any other suitable parameter.

The configuration information may be of any suitable type to allow the electronic device to conduct configuration.

In one embodiment, the configuration information comprises a configuration script or a link to a storage location of a configuration script. In an additional embodiment, the configuration script is executed by the electronic device to facilitate configuration. In terms of the present invention, a "configuration script" comprises data that allows configuration of the electronic device. The configuration script/data may be of any suitable type. In one additional or alternative embodiment, the device may create or receive an individual device identifier in the process.

In another alternative or additional embodiment, the configuration information comprises an operating software or a link to a storage location of an operating software. In an additional embodiment, the operating software is obtained (in the case of a link) and installed in suitable memory of the electronic device.

In another alternative or additional embodiment, the configuration information comprises a firmware or a link to a storage location of a firmware, in an additional embodiment, the firmware is obtained (in the case of a link) and installed in memory the electronic device. In one example, the firmware is "flashed".

In another alternative or additional embodiment, the configuration information comprises a software update or a link to a storage location of a software update. In an additional embodiment, the software update is obtained (in the case of a link) and installed in suitable memory of the electronic device.

In another alternative or additional embodiment, the configuration information comprises a configuration update or a link to a storage location of a configuration update, in an additional embodiment, the configuration update is obtained (in the case of a link) and installed in suitable memory of the electronic device.

Reference will now be made to the drawings in which the various elements of embodiments will be given numerical designations and in which further embodiments will be discussed.

Specific references to components, process steps, and other elements are not intended to be limiting. Further, it is understood that like parts bear like reference numerals, when referring to alternate figures. It is further noted that the figures are schematic and provided for guidance to the skilled reader and are not necessarily drawn to scale. Rather, the various drawing scales, aspect ratios, and numbers of components shown in the figures may be purposely distorted to make certain features or relationships easier to understand.

<FIG> shows a schematic illustration of an embodiment of an exemplary electronic device <NUM> according to the invention. The electronic device <NUM> in this embodiment is an IoT (Internet of Things) device, and more precisely a network-connected camera. The electronic device <NUM> comprises a network interface <NUM> for connecting to a communications network <NUM> (not shown in <FIG>), which in this embodiment is provided to communicate using the Wi-Fi (IEEE <NUM>) protocol. The electronic device <NUM> further comprises a processing device <NUM>, a camera module <NUM>, and internal memory <NUM>.

The processing device <NUM> in this embodiment comprises a microcontroller having a suitable microprocessor for processing the images, obtained by camera module <NUM>. The microcontroller may be provided as an ASIC (application specific integrated circuit) in a further embodiment. Camera module <NUM> provides video (image) data to processing device <NUM> for transmission to a server or user device over network interface <NUM>. Memory <NUM> serves as temporary cache for the video data and also to hold configuration settings or software updates, as will be explained in the following.

Electronic device <NUM> further comprises a PSU <NUM> (power supply unit), which may be provided for connection to mains (for example the 120V or 240V power grids) and/or may comprise suitable batteries for independent operation. Connections from PSU <NUM> to the other components of electronic device <NUM> are not shown to not unnecessarily obscure the present explanation.

Electronic device <NUM> may certainly in further embodiments comprise additional components, such as a housing, a user interface (display or touchscreen), motors for camera module <NUM>, etc..

The electronic device <NUM> or more precisely the processing device <NUM> is pre-configured to conduct a secure configuration procedure - in the following also referred as to "bootstrap" -for initial configuration of the device <NUM>. During the bootstrap procedure, the processing device <NUM>, over the network interface <NUM> and communications network <NUM> contacts a blockchain database <NUM>. This is schematically shown in the exemplary system overview of <FIG>.

As can be seen from <FIG>, electronic device <NUM> contacts blockchain database <NUM> over communications network <NUM>, the latter of which may in one example be the Internet. Blockchain database <NUM> is hosted on a suitable server (not shown) as known in the art. The blockchain database <NUM> is in this example being provided as a distributed blockchain database system, which may comprise further servers (not shown) hosting blockchain databases 11a and lib, which increases the security of the discussed method and electronic device <NUM>. According to this embodiment, the blockchain database <NUM> corresponds to the Bitcoin database.

<FIG> shows a first embodiment of a computer-implemented method of secure configuration according to the invention in a schematic flow diagram.

The operation according to the present embodiment begins in step <NUM> with the initialization of the electronic device <NUM>, e.g. by powering the device <NUM> up. The processing device <NUM> in step <NUM> contacts blockchain database <NUM> using network interface <NUM> over communications network <NUM>. The connection parameters to connect to the Bitcoin blockchain database <NUM> are pre-defined by the manufacturer in memory <NUM> of the electronic device <NUM>. The correspondingly contacted instance (e.g. server, cloud service, etc.) is either a blockchain node itself or is provided as a gateway to a blockchain node. The blockchain node may use a peer discovery protocol to initially contact the network of other blockchain nodes. Such a peer discovery protocol typically contacts IP addresses of peers known from its previous run. If that fails, the electronic device <NUM> may be provided with a list of DNS seed addresses pointing to known nodes and if that fails one or more hardcoded addresses of known stable nodes are used.

Once connected, the processing device <NUM> in steps <NUM> - <NUM> determines a configuration block from the blockchain database <NUM>. Configuration blocks in this embodiment in general comprise block identification data, allowing to identify the configuration block using a search procedure as discussed in the following, and further comprises configuration information.

The processing device <NUM> in step <NUM> begins searching for a configuration block, where the block identification data corresponds to device identification data, stored in memory <NUM> of the electronic device <NUM>. The device identification data is also pre-defined by the manufacturer of the electronic device <NUM> and allows to identify the correct configuration block, intended for electronic device <NUM>.

In this embodiment, both, the block identification data and the device identification data are the same random number of a sufficient length, i.e., chosen from a set of numbers big enough to render picking the same number by chance virtually impossible, for instance between <NUM> and <NUM> to the power of <NUM>. This number can be determined randomly at electronic device design time and is kept secret for a short period of time (e.g. <NUM> mins), during which it is put into the blockchain together with its configuration block. Then, one waits until sufficiently many confirmation blocks arrived on top of the block used for configuration (typically about an hour). After that the random number no longer needs to be kept secret. In particular, the electronic devices <NUM> which are later produced and contain that number do not have to be designed to keep that number secret.

Herein, the processing device <NUM> searches for the oldest block of the blockchain database <NUM>, where the block identification data corresponds to the device identification data.

In case of multiple electronic device types, models, and/or classes <NUM>, each electronic device class <NUM> can be programmed with unique device configuration data, allowing to access a similarly unique configuration block. Alternatively, groups of electronic devices <NUM> can share common device identification data to access the same configuration block and bootstrap procedure, which facilitates a particularly easy manufacture of electronic device <NUM> since no or less individualization is needed.

According to the present embodiment, the processing device <NUM> begins searching for the configuration block at a block that corresponds to a minimum block height value, pre-defined in memory <NUM> of the electronic device. In case the minimum block height value is zero, the processing device <NUM> begins searching for the configuration block at the genesis block of the blockchain database <NUM>. Otherwise, the search is started at the block of the blockchain database <NUM> that corresponds to the minimum block height value.

In step <NUM>, the processing device <NUM> determines, whether the currently checked block is the desired configuration block, i.e., where the block identification data corresponds to the device identification data, if this is not the case and in step <NUM>, a next block pointer, stored in memory <NUM>, is set to the next block, i.e., the following (younger) block of the blockchain database <NUM>. it is noted that the blockchain database <NUM> is searched in reverse order, i.e., from "older" blocks to "younger" blocks.

In step <NUM>, the block is retrieved from the blockchain database <NUM>, which corresponds to the next block pointer. The operation then proceeds with step <NUM> and a determination, whether the currently checked block is the desired configuration block as explained in the preceding.

If this is the case and in step <NUM>, the configuration information is obtained from the configuration block. In a simple case, the configuration information is read from the configuration block, which has been obtained from the blockchain database <NUM> previously. To allow simple obtention of the configuration information, memory <NUM> of the electronic device <NUM> comprises a configuration pointer, which points to the configuration information in the configuration block. In one embodiment, the configuration information is concatenated to the block identification data, to simplify storing the configuration information in the blockchain <NUM>.

In step <NUM>, the processing device <NUM> of the electronic device <NUM> conducts a configuration (sub)routine using the obtained configuration information from the configuration block.

During the configuration routine, the processing device <NUM> configures the electronic device <NUM>. Configuring may include one or more of setting of device, security, and network parameters; and download operating software, firmware, software updates, and configuration updates, depending on the specific requirements of the electronic device <NUM>.

According to the present embodiment, the configuration information comprises a configuration script. The configuration script in this embodiment comprises instructions on how to reach a configuration/update server (e.g. a "link") and a public key for encrypted communication with the update server. Usually, the link may be in the form of an IP address.

During the configuration routine, the processing device <NUM> of electronic device <NUM> may thus contact the configuration/update sever and first of all check for the latest operating software and/or firmware. If newer software/firmware is available, it will be installed automatically during the configuration routine. Then, configuration settings are retrieved from the configuration/update server or, if configuration settings are already comprised in memory <NUM> of the electronic device <NUM>, a configuration update is retrieved. The configuration settings/update may comprise, for example, URLs of one or multiple servers to deliver information to, e.g. camera pictures or sensor data. By this, a device might still use conventional methods of data delivery while employing a secure update and configuration mechanism provided by a blockchain.

After successful configuration in step <NUM>, the present method of secure configuration according to the embodiment of <FIG> then ends in step <NUM> and the electronic device <NUM> switches to an operational mode, in which the intended device operation is provided. In case of the camera, video data from the camera module <NUM> is provided to a corresponding server or user device, as discussed in the preceding. The method is re-executed in predefined intervals, e.g., every week, to check for software/firmware/configuration updates and thus to re-configure the electronic device <NUM> if necessary.

<FIG> shows a second embodiment of a computer-implemented method of secure configuration according to the invention in a schematic flow diagram. The method according to <FIG> corresponds to the embodiment, discussed in the preceding with reference to <FIG>. Consequently, the reference numerals "4x", i.e., <NUM>-<NUM>, refer to the like steps of <FIG>, i.e., the corresponding "3x" reference numerals <NUM>-<NUM>.

As will be apparent from <FIG>, the inventive method according to the present embodiment corresponds to the embodiment of <FIG> with the exception of the determination of the configuration block (steps <NUM>-<NUM> in <FIG>).

In this embodiment, the device configuration data comprises a block identifier, stored in memory <NUM>. The block identifier unambiguously identifies a certain block of the blockchain database <NUM> as the configuration block. This simplifies the determination of the configuration block and may be advantageous for electronic devices <NUM> with limited computing power.

According to this embodiment, the block identifier comprises a time stamp (date / time) of the blockchain database <NUM>. The time stamp may relate to the date / time, the block was written to the blockchain database <NUM>. Consequently, the determination of the configuration block in step <NUM> comprises querying the blockchain database <NUM> for the block that corresponds to the block identifier. As will be easily apparent, the time stamp in this embodiment servers as block identification data and device identification data.

Once the configuration block is determined, the configuration information is retrieved in step <NUM> and the device configuration is conducted in step <NUM> as discussed in the preceding with reference to steps <NUM> and <NUM> of <FIG>.

<FIG> shows a further embodiment of a computer-implemented method of secure configuration according to the invention in a schematic flow diagram. The method according to <FIG> corresponds to the embodiment, discussed in the preceding with reference to <FIG>. Consequently, the reference numerals "5x", i.e., <NUM>-<NUM>, refer to the like steps of <FIG>, i.e., the corresponding "3x" reference numerals <NUM>-<NUM>.

As will be apparent from <FIG>, the inventive method according to the present embodiment corresponds to the embodiment of <FIG> with the exception of the determination of the configuration block.

In this embodiment and in step <NUM>, the electronic device <NUM> contacts a blockchain search server (not shown) to search for the configuration block.

Accordingly, the electronic device in step <NUM> sends the device identification data and the minimum block height value, if present, to the blockchain search server. The blockchain search server then conducts the steps <NUM>-<NUM> of <FIG> until the configuration block is found. As will be easily apparent, the searching thus is "outsourced" in this embodiment, so that it also is advantageous for electronic devices <NUM> with limited computing power.

Once the blockchain search server has found the configuration block, the latter is provided to the electronic device <NUM> for obtention of the configuration information in step <NUM> and the device configuration is conducted in step <NUM> as discussed in the preceding with reference to steps <NUM> and <NUM> of <FIG>.

In an alternative embodiment, the electronic device <NUM> also transmits the configuration pointer to the blockchain search server in step <NUM>. Then, the blockchain search server only returns the configuration information to the electronic device <NUM>.

<FIG> and <FIG> show a further embodiment of a computer-implemented method of secure configuration according to the invention in a schematic flow diagram. The method according to <FIG> corresponds to the embodiment, discussed in the preceding with reference to <FIG>. Consequently, the reference numerals "6x", like in the preceding, refer to the like steps of <FIG>, i.e., the corresponding "3x" reference numerals <NUM>-<NUM>.

The embodiment of <FIG> provides a so-called "forward-chained update routine" to allow for secure configuration updates by the manufacturer after the configuration block has been written to the blockchain.

As the instant inventions' inventors have recognized, and due to the inherent resistance of blockchains to modification of data, a particular routine is required to allow the configuration of the electronic device with updated configuration information. Such routine may for example be necessary in case the original configuration information comprises a link to an update server, e.g., "update. iot-device. com", and said domain address should no longer be available.

As will be apparent from <FIG> and <FIG>, the current embodiment comprises additional steps <NUM> - <NUM>. According to this embodiment, the configuration block comprises an additional forward update indicator. The forward update indicator can be regarded as a "chain link" to a new, updated configuration block that is written to the block chain in the future, i.e., after the "initial" configuration block.

In general, the forward update indicator can comprise any suitable data. In this embodiment, the forward update indicator comprises a hash of verification data, such as a suitably long random bit string, the latter of which is kept secret by the device manufacturer until an updated configuration block needs to be written to the blockchain database. The length of the random bit string is chosen long enough to make a brute force attack of enumerating potential candidates that create the same hash value computationally infeasible. By way of example, the verification data comprises a random bit string of <NUM> bit. The corresponding SHA-<NUM> hash is of a length of <NUM> bit and is provided as part of the forward update indicator.

According to <FIG> and after the determination of the configuration block in step <NUM>, which step and all previous steps correspond to the embodiment of <FIG>, the electronic device <NUM> obtains the forward update indicator from the configuration block in step <NUM>. Certainly, and in case no forward update indicator should be present in the configuration block, the method could revert to the procedure of <FIG>.

In the current embodiment of <FIG> and in step <NUM>, the processing device <NUM> searches for an updated configuration block. The updated configuration block comprises correspondingly updated configuration information, the identical block identification data of the initial configuration block, the discussed verification data, and a further forward update indicator. Accordingly, the processing device <NUM> in step <NUM> searches the blockchain database for another configuration block, where the block identification data corresponds to the device identification data. The processing device <NUM> in this example applies a subroutine in step <NUM>, which corresponds to steps <NUM>-<NUM>, explained in the preceding, however using the block height of the initial/original configuration block as minimum block height value, since the updated configuration block cannot be older than the initial/original configuration block.

In step <NUM> it is determined, whether an updated configuration block was found in step <NUM>. If this is not the case, the configuration information of the initial/original configuration block is obtained in step <NUM> and the electronic device <NUM> is configured in step <NUM> using the configuration information, according to the embodiment of <FIG>. The method then ends in step <NUM> and the electronic device <NUM> switches to an operational mode, in which the intended device operation is provided.

In case the determination in step <NUM> provides that an updated configuration block was found in step <NUM>, the processing device <NUM> in step <NUM> determines, whether the updated configuration block comprises a further forward update indicator, if this is not the case, the current updated configuration block is verified in step <NUM>, The verification will be discussed in detail in the following.

Once the verification is complete, the updated configuration information of the current updated configuration block, i.e., the last updated configuration block, is obtained in step <NUM>. Corresponding to step <NUM>, configuration is then conducted in step <NUM>. Again, the method ends in step <NUM> and the electronic device <NUM> switches to an operational mode, in which the intended device operation is provided.

If, in step <NUM>, the processing device <NUM> determines that the current updated configuration block comprises a further forward update indicator, the processing device <NUM> in step <NUM> searches for a further updated configuration block.

Again, the updated configuration block comprises correspondingly updated configuration information, the identical block identification data of the initial and all previous configuration blocks, further verification data, and a further forward update indicator.

Accordingly, the processing device <NUM> in step <NUM> searches the blockchain for another updated configuration block, where the block identification data corresponds to the device identification data. The processing device <NUM> again applies a subroutine, which corresponds to steps <NUM>-<NUM>, explained in the preceding, however using the block height of the current updated configuration block as minimum block height value, since any new updated configuration blocks cannot be older than the previous ones.

In case no further updated configuration block exists, the determination in step <NUM> results in the execution of steps <NUM>-<NUM>, as discussed in the preceding using the updated configuration information of the current (last found) updated configuration block. In case a further updated configuration block was determined in step <NUM>, the determination in step <NUM> provides a positive result and the method continues with step <NUM>.

As will be apparent, the current embodiment provides an iterative procedure to find the most recent, i.e., youngest (updated) configuration block of the blockchain database. When it is found, the electronic device <NUM> is configured with the (updated) configuration information of the youngest configuration block determined so as to apply the most recent configuration to the electronic device <NUM>.

As discussed in the preceding, the forward update indicator can be regarded as a "chain link" to a new, updated configuration block that is written to the block chain in the future, i.e., after the "initial" configuration block, A particular issue with such forward-chained updated configuration blocks relates to security. Only authorized parties, such as the manufacturer of the electronic device <NUM>, should be able to write valid configuration blocks for electronic device <NUM> to the blockchain database.

Thus, in the embodiment of <FIG>, a verification subroutine is conducted in step <NUM>. During the verification, the processing device <NUM> considers the forward update indicator of the previous configuration block, i.e., the initial/original configuration block or a previous updated configuration block and the verification data, comprised in the current updated configuration block,.

For facilitating clarity of the present discussion, in the following, reference is made to an exemplary situation where the initial/original configuration block and one updated configuration block are verified in step <NUM>.

As discussed in the preceding, the forward update indicator of the initial/original configuration block comprises a hash of the verification data, and in this example some randomly chosen bit string. The subsequent updated configuration block comprises this very same bit string. This design allows to verify the integrity of the updated configuration block to assure that the updated configuration block actually originates from the manufacturer of the electronic device <NUM> or another authorized party. It will be apparent that while it is possible to determine the forward update indicator by hashing the verification data, a determination of the verification data on the basis of knowledge of the forward update indicator generally is impossible, at least when using a robust hash algorithm.

Correspondingly, it is possible to verify the authenticity of the updated configuration block by hashing the verification data provided therein and comparing the result with the hash, provided in the initial/original configuration block. If this is the case, both configuration blocks have the same origin, e.g., the manufacturer, under the assumption that the manufacturer kept the verification data secret until writing the updated configuration block into the blockchain database.

Certainly, after the verification data is public, no further updates are possible using the current verification data while maintaining security. Correspondingly, the updated configuration block again comprises a forward update indicator, which comprises a hash of further verification data, e.g., another (different) random bit string. Using this procedure, it is possible to daisy-chain a plurality of updated configuration blocks in the blockchain database.

Accordingly, in step <NUM>, the processing device <NUM> first calculates the hash of the verification data comprised in the updated configuration block. Then, the processing device <NUM> compares the result with the hash, comprised in the forward update indicator. If both hashes match, the configuration information of the current updated configuration block is obtained in step <NUM>, If not, the updated configuration block is discarded in step <NUM>. The method then may proceed to step <NUM> to find a further updated configuration block (not shown in <FIG>).

<FIG> and <FIG> show a further embodiment of a computer-implemented method of secure configuration according to the invention in a schematic flow diagram. The embodiment corresponds to the embodiment of <FIG> and <FIG> with the exception of the forward update indicator and that the verification, discussed in the preceding with reference to step <NUM>, in this embodiment is conducted in conjunction with obtaining the updated configuration information from the current updated configuration block in step <NUM>. Accordingly, a separate verification is not necessarily required in this embodiment.

The forward update indicator in the embodiment of <FIG> comprises a public update key of a typical private/public key pair. The manufacturer keeps the associated private update key secret.

The updated configuration information in the updated configuration block or a sufficiently long subset thereof or a sufficiently long nonce is then encrypted using the private update key. in this embodiment, the same private/public key pair can be used in all subsequent configuration blocks. Accordingly, the forward update indicator may be provided in all configuration blocks, or, to save data volume, just in the initial/original configuration block.

As will be apparent from <FIG>, the method of the current embodiment largely corresponds to the method, explained with reference to the embodiment of <FIG>. Accordingly, identical reference numerals have been used.

In step <NUM> of the current embodiment, the processing device <NUM> obtains the encrypted updated configuration information from the current updated configuration block. The processing device <NUM> then uses the public update key of one of the previous (older) configuration blocks, i.e., of the initial/original configuration block to decrypt the updated configuration information. The latter is used in case the decryption process completes successfully, otherwise the updated configuration information is discarded. The method then may proceed to step <NUM> to find a further updated configuration block (not shown in <FIG>).

For example, it is possible to operate the invention according to an embodiment, wherein:.

In the claims, the words "comprising" or "having" do not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor, module or other unit may fulfill the functions of several items recited in the claims.

Claim 1:
A computer-implemented method of secure configuration of a plurality of electronic devices without requiring to embed an individualized tag in each of the plurality of electronic devices, wherein each of the plurality of electronic devices comprises common device identification data and each of the plurality of electronic devices is configured to:
connect (<NUM>) to a blockchain database (<NUM>);
determine (<NUM>) from said blockchain database (<NUM>) a configuration block comprising block identification data, where the block identification data corresponds to the common device identification data, stored with the electronic device (<NUM>);
obtain (<NUM>) configuration information from said configuration block; and
using (<NUM>) the configuration information, conduct configuration of the electronic device (<NUM>).