GB2607589A

GB2607589A - Blockchain based device certification

Info

Publication number: GB2607589A
Application number: GB2108005.6A
Authority: GB
Inventors: Rakic Dean
Original assignee: Taal DIT GmbH
Current assignee: Taal DIT GmbH
Priority date: 2021-06-04
Filing date: 2021-06-04
Publication date: 2022-12-14
Anticipated expiration: 2041-06-04
Also published as: GB202108005D0; GB2607589B

Abstract

A computer-implemented method of enabling certification of a device using a blockchain, wherein the method is performed by a certification entity and comprises: creating a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device; and causing the first blockchain transaction to be recorded on the blockchain.

Description

BLOCKCHAIN BASED DEVICE CERTIFICATION

TECHNICAL FIELD

The present disclosure relates to a method of certifying a device using blockchain transactions.

BACKGROUND

A sensor (device) has a role to detect changes in its work environment and pass information to other system components. Before such a sensor can be placed on the market, it must be adequately certified by an authorized certification body. The certification confirms that the given sensor is designed in accordance with regulations and standards. This also means that the sensor certification ensures safe and reliable operation in a given system and thus guarantees the efficiency and usability of the designed sensor in the user environment. If sensor certification fails, it means that the sensor does not comply with regulatory, operational and/or standard requirements.

A large number of newly designed sensors fail to be certified and are returned to the designers or manufacturers for finishing, or they are simply not released on the market. This has the effect of, amongst other things, increasing costs and extending time to market for new sensors.

The measurement factor, especially in the loT environment and complex industrial processes, is the form and content of the information itself that the sensor collects and transmits. It is in fact an informative object or structured information about data that also carries content and context. This information object is called metadata.

SUMMARY

According to a first aspect disclosed herein, there is provided a computer-implemented method of enabling certification of a device using a blockchain, wherein the method is performed by a certification entity and comprises: creating a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device; and causing the first blockchain transaction to be recorded on the blockchain.

According to a first aspect disclosed herein, there is provided a computer-implemented method of certifying a device using a blockchain, wherein the blockchain comprises a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, and wherein the method is performed by a device entity and comprises: creating a second blockchain transaction, wherein the second blockchain transaction references the first blockchain transaction and comprises a respective answer to each of the plurality of questions for a target device; and causing the second blockchain transaction to be recorded on the blockchain, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device.

The certificatation entity (e.g. a regulatory body) publishes, to the blockchain, a smart contract which lists questions (e.g. requirements) that the device must satisfy (i.e. comply with). The smart contract resides in the first blcockchain transaction. The device entity (e.g. the device manufacturer or vendor) submit a second transaction to the blockchain that calls the smart contract, and provides answers to the questions. In other words, the second blockhcain transaction references (e.g. spends) the first blockchain transaction. The answers may include, for example, one or more properties, characteristics, capabilities, functionalities, etc., of the device. If the requirements dicated by the questions are satisfied, the smart contract then issues a certificate. In fact, the second blockchain transaction itself is the certificate as the second blockhcain transaction will only be recorded on the blockchain if the requirements of the smart contract are satisfied. In this way, the device certificate is automatically issued if the device entity provides the correct information to the smart contract, by way of the second blockchain transaction.

Blockchain as a technology has a simple infrastructure that allows sensors (or other forms of devices), through the form of transactions, to directly transfer metadata (e.g. between other sensors, or to a central system). The metadata may include or illustratea measure of compliance with regulations and standards. As certification is performed through a central instance and the certificate is issued by an authorized certification body (in this case through a lockchain smart contract) the sensor is allowed to function autonomously in the data exchange system with system components without the need for a central authority. This confirms both the origin of the metadata and ensures the completion of the certification of conformity testing.

Embodiments of the present invention may be used to certify a device using certificates, e.g. sensors used in a variety of industrial applications, including but not limited to loT devices. However, it is important to note that the sensor certification process does not depend on the hardware or performance of the sensor itself, and thereforethe described techniques for sensor certification may be applied to any device that requires certification to be part of the system, e.g. in order to exchange metadata.

The present invention allows any loT sensor (or more generally, any device) to be automatically certified based on a certification body's questionnaire. The certification questionnaire, as well as the vendor's response containing the answers to the questions are stored on the blockchain. The validation conditions for issuing the certificate are enforced by a smart contract. The issuance of the certificate (which may be used to certify the content of the sensor's metadata) is performed automatically based on the vendor's request through the process of validating the response by blockchain nodes and the storage of the response in a new block.

BRIEF DESCRIPTION OF DRAWINGS

To assist understanding of the present disclosure and to show how embodiments may be put into effect, reference is made by way of example to the accompanying drawings in which: Figure 1A schematically illustrates an example method for mining a new block to a blockchain, Figure 1B schematically illustrates a pair of blockchain transactions, Figure 2 schematically illustrates an example system for certifying a device using a blockchain, Figure 3 illustrates an example sensor metadata structure, Figure 4 shows schematically an example sensor metadata certification process, Figure 5 schematically illustrates another example system for certifying a device using a blockchain. sensor metadata certification.

DETAILED DESCRIPTION

EXAMPLE BLOCKCHAIN SYSTEM

Figure 1A schematically illustrates an example method for mining a new block 101n on a blockchain 102. A blockchain 102 is a form of distributed database (or ledger) that acts as a record of all valid transactions 103 that have ever been transmitted to the blockchain network.

Valid transactions 103 that are broadcast on the blockchain network are recorded on the blockchain 102 by miners (also referred to as mining nodes) in blocks. A blockchain transaction 103 is used to transfer custody of an amount of a digital token. A pair of transactions 103 are shown in Figure 1B. As shown, each transaction 103 includes, amongst other things, at least one input and at least one output. An input is a reference to an unspent transaction output (UTXO) from a previous transaction. For example, in Figure 1B, Txi contains an input that references a UTXO of Txo. A transaction 103 uses unspent transaction outputs (UTX05) as inputs and distributes their value to new outputs. An output typically includes a locking condition that locks the value of that output, requiring certain data (e.g. a set of keys or other information) to be provided in an input of a new transaction 103 in order to be unlocked. Outputs can also be used to inscribe data onto the ledger. An input of a transaction 103 usually includes a digital signature that signs over a transaction 103. A chain of transactions 103 therefore includes a chain of digital signatures that maps out the entire history of valid exchanges of the digital tokens all the way back to their creation.

Returning now to Figure 1A, the blockchain 102 begins with a "genesis block" 101g, which is the first block 101 ever created. Each block on the blockchain 102 references a previous block, all the way back to the genesis block. That is, the nth block 101 reference the n-1th block 101, the n-1th block reference the n-2' block 101, and so on, back to the genesis block 101g.

A block 101 contains an ordered list of blockchain transactions 103 and a block header 104. The block header 104 includes a Merkle root 105 that is generated by hashing the ordered list of blockchain transactions 103 into a Merkle tree, a timestamp, a reference 106 to the previous block 101 that the present block 101 builds upon and the means to validate the "proof-of-work" needed for other miners to accept the block 101 as valid. That validation means is an answer to a hash puzzle which is unique to each block 101. The blockchain protocol run by nodes of the blockchain network uses a hashing algorithm that requires miners to pre-build their candidate block 101c before trying to solve the puzzle. New blocks 101n cannot be submitted to the network without the correct answer -the process of "mining" is essentially the process of competing to be the next to find the answer that "solves" the current block 101. The hash puzzle in each block 101 is difficult to solve, but once a valid solution is found, it is very easy for the rest of the network to confirm that the solution is correct. There are multiple valid solutions for any given block 101 -only one of the solutions needs to be found for the block 101 to be solved.

The following briefly describes the process of attempting to mine a new block 101n to the blockchain 102. When a blockchain transaction 103 is transmitted to a mining node, it is first validated according to the consensus rules of the blockchain network. If the transaction 103 is valid it is added to a pool 107 of unconfirmed transactions 103. The pool 107 is sometimes referred to as a "mempool". The mempool 107 acts as a temporary store of transactions 103 to be mined into the next block 101n. Each mining node will have its own mempool 107, and any given transaction 103 may be included in more than one mempool 107 if it has been broadcasted to more than one mining node.

A hash function is a function that converts a string of data of arbitrary length into a fixed length value, called the hash value or a hash digest. Hashing is a one-way function, meaning it is infeasible to determine what the input data is by looking at the hash value produced from it. On the other hand, it is trivial to run the same input data through the same hash function and reproduce the same hash. Some blockchain protocols use the SHA-256 hashing algorithm, and some protocols use the SHA-256 hashing algorithm twice, i.e. the candidate block header is passed through the same hashing algorithm twice.

A Merkle tree is a data structure in the form of a tree of hash values. In the context of the blockchain 102, a transaction 103 is hashed to form a leaf node of the tree. As shown in Figure 1A, transaction Tx1 is hashed to form leaf node D1, transaction Tx2 is hashed to form leaf node D2, and so on. Pairs of leaf nodes are concatenated and then hashed to form a node in a higher layer of the tree. For example, leaf nodes D1 and D2 are concatenated and hashed to give a node in a higher layer. Pairs of nodes in that layer are then concatenated and hashed to form a node in a yet higher layer of the tree. The process is repeated until only a single node is left, referred to as the root node, or the Merkle root 105.

A miner takes the transactions 103 it intends to include in the next block 101 and hashes them into a Merkle tree structure and includes the resulting Merkle root 105 within a candidate block header 104. The miner then hashes this candidate block header 104, attempting to find a valid proof-of-work.

A valid proof-of-work if found by hashing the candidate block header 104 (in combination with other data, as discussed below) until the result is less than another value, called the target value. The target value is automatically adjusted by the blockchain protocol so that, on average, it takes the blockchain network ten minutes to find a valid proof-of-work.

In order to change the hash value, a mining node must add additional information to the candidate block header 104. Mining nodes typically use two "nonce fields" to alter the value to be hashed, and thus alter the resulting hash value. A first nonce field 108 is included in the block header itself, and the second nonce field is included in a "coinbase transaction". A coinbase transaction is a transaction created and included in the candidate block by the mining node. Each field includes a counter parameter that can be incremented. The hash function cycles through all values of the first nonce 108 field then increments (or otherwise changes) the second nonce field, before going through all permutations of the first nonce field 108 again. Incrementing the second nonce field involves recomputing the Merkle root 105 as it modifies the hash of the coinbase transaction, which is included in the Merkle tree.

When a mining node finds a valid proof-of-work hash for a block 101 (i.e. a candidate block header 104 that hashes to a value less than the target value), it broadcasts the new block 101n to the rest of the blockchain network. The other nodes on the network accept this new block 101n only if all the transactions 103 in it are valid and have not yet been included in a block. Every block 101 is timestamped and references the hash of the block 101 preceding it, thus resulting in a chain of blocks (i.e. the blockchain 102).

The above has been described in terms of an "output-based" transaction model. An alternative type of transaction model is an "account-based" model. In this model, each transaction 103 does not define the amount of the digital token to be transferred by referring back to an unspent transaction output, but instead rather by reference to an absolute account balance. The current state of all accounts is stored by the miners separate to the blockchain 102 and is updated constantly. In such a system, transactions 103 are ordered using a running transaction tally of the account (also called the "position"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation.

Figure 2 schematically illustrates an example system 200 for delivering hash values from a set of hashing devices 201a, 201b to a hashing pool 202. In this example system 200 there are two hashing devices 201a, 201b but the system 200 may in general comprise any number of hashing devices 201. The system also comprises a set of blockchain client applications 203a, 203b, 203c. Whilst only three client applications 203a, 203b, 203c are shown, the system may comprise any number of client applications 203. In general, the client applications 203 are configured to submit blockchain transactions to the hashing pool 202. The hashing pool is configured to construct a block template 101c and send the block template 101c (or at least the candidate block header 104 of the block template 101c) to the hashing devices 201a, 201b. Each hashing device 201 is configured to generate candidate PoW solutions based on the candidate block header 104. The system further comprises a blockchain network 204 comprising a plurality of blockchain nodes.

DEVICE CERTIFICATION

Figure 2 illustrates an example system for certifying a device according to embodiments of the present invention. As shown, the system comprises a certification body (also referred to as a certificaiton entity 501). In general, "certificaiton entity" is used herein as a label for the party (e.g. user, groups of users, company, organiation, etc.) responsible for generating a questionnaire transaction, as discussed below. The certification entity 501 may be a standards setting agency, or the like. The certification entity 501 may be responsible for generating certificate questionnaires for a single type of device or for multiple types of devices. The system also comprises a device entity 502. In general, "device entity" is used herein as a label for the party (e.g. user, group of users, company, organisation, etc.) responsible for generating a questionnaire response transaction for a target device, as discussed below. The device entity 502 may comprise or otherwise operate the target device. The target device being certified may be a sensor, e.g. an autonomous sensor. The target device may be an internet-of-things (loT) device. In some examples, the device entity 502 may be the manufacturer and/or vendor of the target device. As shown, the system also comprises one or more nodes of a blockchain network. For example, the nodes may be configured to implement a blockchain system as described with reference to Figures 1A and 1B.

The certification entity 501 and the device entity 502 operate respective computer equipment. The computer equipment of each entity comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, CPUs, other accelerator processors, application specific processors, and/or FPGAs. The computer equipment of each entity further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and/or an optical medium such as an optical disc drive. The memory on the computer equipment of each entity may store software comprising at least one client application arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given entity 501, 502 may be performed using the software run on the processing apparatus of the respective computer equipment. The computer equipment of each entity comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment of each entity may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

The certificaiton entity is configured to generate a first blockchain transaction (also refererred to as a questionnaire transaction). The questionnaire transaction comprises a smart contract. The smart contract comprises a questionnaire for certifying a device. The questionnaire comprises a plurality of questions requiring answers. Some or all questions may take the form of data fields to be populated. For example, a question may be "device type", which would be answered by providing the device type of the device. Some or all questions may provide one or more options to be selected. For example, a question may be "wired / wireless", which would be answered by providing one of the options (i.e. either wired or wireless). Some or all questions may be yes/no questions. The certificaiton entity is configured to submit the questionnaire transaction to the blocckhain network. Alterantively, the certifiation entity may provide the questionnaire transaction to a differenty entity (e.g. the device entity 502) who submits the questionnaire transaction to the blockchain network. In some examples, the questionnaire transaction is signed by the certificate entity, e.g. with a signature corresponding to a public key assocaited with the certificate entity.

The questionnaire transaction, and therefore the smart contract, exists on the blockchain and can be called by a later submitted transaction. When called (i.e referenced) by a second blockchain transaction, the smart contract is configured to verify that the second transaction comprises an answer to each of the questions of the questionnaire. The second transacton is also referred to as a response transaction. The smart contract is configured such that the response transaction will only be validated and therefore stored on the blockchain if the questions are answered. In other words, the smart contract enforces that the response transaction comprises the required answers. If the response transaction does not comprise the answers it will not be validated and stored on the blockchain.

The skilled person will be familiar with blockchain technology and smart contracts in general. Smart contracts can be implemented on both output-based and account-based blockchains. On an output-based blockhain, the smart contract is implemented using a locking script in an output of the questionnaire transaction and imposes conditions on the input of the response transaction. If the conditions are met, the response transaction will be recorded on the blockchain (assuming any other validation conditions are met). On an account-based blockchain, the smart contract takes the form of an executable program, which may be written in a high-level computer programming language. In this case, the smart contract imposes conditions on a payload (containing input values) of the response transaction. If the transaction execution is successful, the internal state of the blockchain will be updated. The smart contract may also consider the input to be invalid and reject the transaction as failed, in which case the state is not affected.

The device entity 502 is configured to generate the second (response) transaction. The resone transaction comprises an answer to each of the questions contained in the smart contract of the questionnaire transaction. The set of answers is also referred to as metadata of the device. If the answers are valid (the meaning of which will be discussed below), the response transaction will be successfully recorded on the blockchain. This may be depend on the response transaction satisfying other conditions set by the blockchain protocol. In some examples, the response transaction is signed by the device entity 502, e.g. with a signature corresponding to a public key assocaited with the device entity 502. In addtional or alterantive examples, the quesitonnaire transaction may be locked to a public key of the device entity 502 and require the response transaction to include a signature corresponding to that public key.

The response transaciton, once successfully recorded on the blockchain, acts as (e.g. is interprted as) a certificate for the target device. In this way, the certificate for the device is automatically issued in response to the device entity 502 providing answers to the questionnaire. In examples, the certificate may certify that the target device is capable of and/or permissioned to perform one or more tass. As another example, the certificate may be used by other entities to verify that data provided by the target device is presumed to be, for example, legitimate, trusted, accurate, etc. The device entity 502 may provide the response transaction, or a reference thereto (e.g. a transacton identifier) to a third party as evidence that the target device has been certified.

The smart contract may be configrued to verify that each answer is valid. This may comprise determining that an answer satisfies one of more of the following requirements. The answer may have to take a particular form, e.g. it may have to be a particular data type, such as a string or a number. In some examples, the answer may have to a particular value, e.g. a particular number, or a particular word, or phrase. In some examples, the answer may have to a particular one of a set of options (e.g. "yes" or "no"). The answer may have to have a minimum length and/or a maximum length. The answer may have to fall within a length range. The answer may have to satisfy other requirements.

In embodiments where the blockchain is an account-based blockchain, the smart contract may be configured such that it can be executed more than once. This allows the same questionnaire L1 to be called by mutliple response transactions. In alternative embdoiments, the blockchain is an output-based blockchain meaning the smart contract can only be called once.

The target device may be configured to generate (e.g. output) one, some or all of the answers to be included in the response transaction. In some examples, the target device may be configreud to generate the response transaction, or at least part of the response transaction. In additional or alternative examples, the target device may provide the response transaction (or a reference thereto) when sending data to a different device, e.g. to prove that the target device has been certified.

Further examples of the described embodiments will now be discussed.

In order to effectively implement sensor certification, it is necessary to focus on the metadata itself and on the steps leading to sensor certification. Before explaining what the values of certification are and why certification based on the process of testing sensor technology in operational terms is introduced, it is necessary to clarify the process of creating sensor metadata and then further connect to the regulatory segment.

Starting from the point of view that in the process of exploitation of sensors, already from the design process, it is necessary to provide all the prerequisites for the process of data collection and sharing in accordance with existing standards regardless of the field of sensor implementation in practice.

The base functionality of the sensor relies on sensor metadata. The metadata is also often defined as structured information about data or data about data. The information structure may describe who the creator is, what constitutes the content and context of the metadata, and where, when, and why the metadata is used. To make metadata easier to handle, especially in a distributed environment, the structure may be supplemented with elements of metadata categorization. At the current level, the categorization of the following types is recognized: descriptive, technical, structural and administrative. From the point of view of the sensor itself as a creator of metadata, categorization is important for establishing the relationship between the elements of data identification and connecting with technical aspects in terms of the purpose and management of metadata.

Viewed from the point of view of a digital resource, sensor metadata as the backbone of digital curating is very important. If they do not exist, the digital resource may become irreversible and unidentified and thus unusable.

Likewise, looking at an information resource, both sensor metadata as descriptive and contextual information form the building blocks of connections to other objects and resources. If there is no valid and certified information resource, there may be a lack of identification, locating and retrieval by the user. This creates an aggravating element of control and access to metadata or the sensor as a device.

How metadata is stored in a digital format is described using metadata standards that also define the characteristics and attributes of the sensor. Metadata standards are normally predefined rules and requirements on the basis of which a common understanding of the semantic structure can be established. This, furthermore, ensures the correct use and interpretation of the data by both the owner and the user. For this purpose, several standards have been developed and represent the so-called metadata schemes and grouped in relation to the domain or type of information resource.

Metadata standards, which are in active use, also apply to metadata produced by sensors. Based on the standards, so-called schemas are also identified and specify in which syntax the metadata elements must be encoded. The most commonly used syntax form is Standard Generalized Markup Language (SGML) or Extensible Markup Language (XML).

Responsibility for the development and maintenance of standards is typically performed by standard organizations such as the International Standard Organization (ISO) and their associated or certified organizations and initiatives. In order to unambiguously mark and harmonize schemes with metadata application processes, standardization bodies have formed metadata registers. These are centralized instances that store metadata definitions and maintain them in a controlled environment, so-called metadata repositories. In technical terms, these are databases where metadata definitions are stored, along with the formulation of metadata types.

Additional elements, which make sensor certification desirable at the metadata level, are conditioned by a large number of sensor forms of different domains and thus by the open possibilities for potential abuse. Certification enables verified sensors or devices to exchange information within a network (e.g. an loT infrastructure) and thus helps to prevent fraud and misuse while increasing safety and ensuring privacy and protection of property.

Conventionally, the first steps towards sensor certification occur on the vendor side. Each step consists of a set of operations that need to be met in order to perform certification and thus generate the content that the device should possess before the operation process. In addition to the technical prerequisites that a vendor sensor needs to meet, this process requires a manual process, which can be a lengthy process (e.g. multiple days). Also, this certificate is required for each new broadcast of information generated by the sensor in a particular domain.

This process can be simplified and the efficiency of certification increased using blockchain technology. The present disclosure provides a novel tecnique for issuing certificates which can be applied to any sensor or device undergoing a certification process.

Elements of this method include: a. Storage of a questionnaire issued by a certification body on a blockchain, and b. Storage of a questionnaire response issued by a vendor on a blockchain. The questionnaire response, once stored on the blockchain, acts as the issuance of a certificate for a given sensor.

a. Traditionally, a questionnaire for a given sensor (e.g. a type of sensor) is prescribed by the certification body and includes a list of questions (e.g. technical requirements) for the sensor. For example, the questions may relate to potentially sensitive elements in the information object generated by the manufacturer. If the conditions are met and there are no identified problems with data disclosure, then the first step towards certification is completed and the set of data is entered in the certification protocol. This process, of course, takes a certain number of days/people from the beginning to the end of the certification and it can usually be up to 5 working days.

Shortening this process by storing data on a blockchain is achieved by digitizing the questionnaire and storing it on a blockchain. This questionnaire improves the following aspects of the traditional, physical process: - Tamper -records: evidence of unauthorized changes that may occur in the process of exploiting the questionnaire. Recording the question and response data on the blockchain provides an accurate insight into whether the data set that makes up the questionnaire has changed, and proof of when it has changed.

- Decentralization of the process: due to the possibility of mistrust and manipulation of the data involved by the parties involved in the traditional process, by using blockchain storage, control over the questionnaire data is given to the network and thus excludes manipulation by a central authority.

- Transparency: trust in the data is established as, by recording the data on the blockchain, the questionnaire and response is visible to any interested party.

b. The next step is to store the response to the questions (e.g. a sensor information object) on the blockchain. This data set belongs to the initial form of sensor metadata, generated by the vendor. Smart sensors may automatically generate this data during the initial start-up of the sensor. This data set, also known as the Vendor Questionnaire (VU), may be a technically oriented document that contains instructions to the vendor initiating the Target of Evaluation (TOE).

The answers to these questions are in practical terms the evidence that the vendor has supported and ensured the sensor evaluation process. The answers themselves are in accordance with the norms and elements provided by the certification body. By storing this questionnaire on the blockchain, there is no additional generation of the so-called Generic Protection Profile (GPP) report. The need for the introduction of the Security Profile in the certification process is also removed. The aim of the security risk analysis in relation to the reference loT architecture and the security profile is to clarify the problems addressed by the ToE in relation to the sensitivity of the data from the operational environment of the sensor as the main risk factor.

The blockchain imposes itself as a solution and secures sensor metadata from external risks by storing a hash of the data. Converting data into a hash, i.e. a computer-generated string based on an input data set prevents the impact of the aforementioned risks because the output data is linked to to the initial-input data. It is now easy to determine whether a modification of the questionnaire occurred in the process of forming the VQ.

The original questionnaire can also be stored in a traditional (i.e. off-chain) database. By using blockchain transactions, the vendor can be convinced at any time that the original questionnaire is on the blockchain. This is achieved by checking the raw data during the check and comparing it with the hash in the targeted blockchain transaction.

Issuance of a certificate for a given sensor on the fulfilment of the conditions of the certification body and validation that the sensor is certified can be requested at any time. In the traditional process, the certificate is given to the lot Service Provider (loTSP) or to one of the industry service providers in which the given sensor participates. Such a document is called a Metadata Certification Statement (MCST). It contains data on sensor characteristics, capabilities and features in a structured form of metadata. As such, it is readable and understandable by the service provider. The format of the certificate is generic, i.e. universal and can be used with any device and regardless of which vendor came on the market.

To make the document easier to access, the Certification Services Method (MCSE) is used. The metadata statement must be signed by a certification body and can be done by the vendor with their consent. It is loaded and made available to users and service providers through a web tool. As this is about the trust of key parties and actors who want to use a certified sensor (device), it is natural to look for additional elements that ensure trust. The format and status of today's certificates is a very suitable ground for manipulation and can be abused in many ways. On the one hand, it is possible to modify the data on the characteristics of the sensor and replace the certificate with the service provider that guarantees the characteristics and measurement and test values. If the data of the certified sensor (device) does not match the actual data, it can cause great damage in the process of exploitation, both material and human. In addition, it is possible to modify the certificate itself and thus extend the manipulation to the segment of intellectual property and thus violate legal regulations, regardless of the country or region in which the sensor is used.

The use of the blockchain in the described embodiments is advantagous from a serurity perspective. The sensor metadata certification process is performed directly at the blockchain transaction level. If any of the participants are interested in a certificate, they only need to initiate a request for a certificate by creating a new transaction. As the questionnaires and responses of the certification body and vendors, respectively, are already stored on blockchain, the blockchain transaction should verify them with the help of consensus and thus confirm that the sensor with the metadata set is valid for use.

This certification procedure shortens the existing certification system for a sensor (device). The device itself is quickly ready to launch on the market. If additions or technical changes are needed, the process of creating the questionnaire is shortened and thus does not affect the launch process. This speeds up the processes when the engagement of new devices is needed in the shortest possible time and frees up human resources for further research and production of new ones.

The costs of the certification process have been reduced. Certification bodies only once perform the process of creating a questionnaire in a particular domain and when stored on the blockchain it always remains available without the need for additional verification of regulatory violations and the process of re-creating and re-broadcasting the questionnaire at each request. The regulatory body has the cost of only one blockchain transaction to store the questionnaire per given domain.

Likewise, vendor costs are minimized in time and also have the obligation to pay only one transaction when feeding the response transaction to the blockchain.

Upon request, the end-user receives a certificate that meets all technical and safety prerequisites. The certificate is available to him at any time and has a minimum cost of issuance at the price of one blockchain transaction.

These elements are very important in all fields of sensor operation, regardless of whether loT home appliances or complex industrial processes that use metadata as a pattern for the proper functioning and management of their production processes and thus a reliable prediction of functionality and production volume.

Figure 3 shows one of the possible sensor metadata structure. The structure may differ depending on the type of sensor, vendor and area of application. The metadata is a description of the sensor, and the vendor can provide as much data as he wants but the vendor is still expected to provide enough data describing the given sensor model. Some of the typical data and attributes 301 found in most metadata are type, model, nodelD information, a unique identifier as well as additional descriptions that describe the characteristics and essential functional units. There are usually detailed descriptions of identifiers, classifiers as well as security and legal constraints. When the customer purchases the sensor, during the installation, the sensor or device is initialized to the desired system with the help of metadata and based on the content of the metadata. Information is obtained regarding whether the sensor's characteristics and description meets the required standards or certificate.

The format in which metadata is displayed to the end-user can be one of the text-descriptive and standardized languages such as XML or JSON. In addition to the tabular list, the example shows sensor metadata described with SensorML (Sensor Model Language) 302, based on XML encoding, and is a component of OGC (Open Geospatial Consortium) and the open standard known as SWE (Sensor Web Enablement). Vendors generally provide metadata from the sensor metadata created in this way and more recently in JSON format, so that the reading of metadata content by users is technically acceptable and feasible without additional conversions.

Figure 4 is a simplified view of the steps in the sensor certification process from questionnaire 201a to certificate issuance. From top to bottom of Figure 4, the first part shows the flow of the traditionally oriented certification model. The second and third parts illustrate the improved flow according to the described embodiments with a reduced number of steps in the certification process using blockchain technology.

The first step 201a in the flow shown is the production of a technically oriented document. It contains elements that identify (with most sensors) the product characteristics, i.e., sensors, safety determinants and key elements related to the field of application of the sensor. When it comes to product characteristics, then it is mainly classifications based on product types (e.g. over twenty different types: analogue, digital, virtual, merit, necessity, durable, consumer...) in which sensors are implemented or used as complete devices. The next segment that can be found in the questionnaire of the certification body typically belongs to the group of so-called industrial classification. The questionnaires here additionally define material and parts, manufactured materials & parts as well as whether the sensor device is classified as (non) durable and (non) tangible. All these elements, as well as others that the certification body may prescribe on the basis of standards (e.g. national or international), aim to prepare to classify the sensor (device) and identify potentially sensitive elements that can be identified in the certificate and presented to the end-user. According to the described embodiments, the questionnaire is stored on the blockchain. Although the questionnaire is submitted in a raw version, the content of the questionnaire is also stored in encrypted form on the blockchain when forming a new block 203c of the blockchain as part of the process of adding new blocks to the Blockchain 203. This can be used to verify the integrity of the questionnaire.

The content of the questionnaire created by the certification body is encoded in the form of a smart contract that digitally conveys the elements that need to be met during the certification process. The certificate stored in the digital form of the smart contract remains on the blockchain forever and cannot be changed. Smart contracts not only define the rules of mutual agreements but are also responsible for the automatic execution of the certification questionnaire when the sensor appears, i.e., the request for verification and certification of the content of sensor metadata (loT devices). Here, the advantages of the blockchain implementation can be seen in the first step, because the start of a smart contract does not require the existence of a central instance that will allow the start, but instead now the process is executed automatically.

The next step 201b in the traditional certification process is the identification and generation of security profile. This step comprises several causally related actions -steps on a specific domain of the sensor usage area. As this is data that the sensor collects or processes and transmits to downstream users, the security profile must in the first step of defining the domain scope of risk refers to whether the domain is in industry, consumer, critical -enterprise environment and defines likelihood, impacts, scope, assumptions in the operating environment. The result of these steps, which are very demanding and involve a large number of days in the engagement of different human resources, aims to show the elements through risk classification and relevant safety requirements. In most cases, the security profile decision is a risk in the form of Man in the Middle, as well as the security requirement for data encryption, which is the basis for achieving the goal of the security profile, i.e., overall confidentiality. According to the described embodiments, this step can be removed from the physical process by utilizing blockchain technology because the very nature of blockchain technology already has all the necessary elements that overcome security risks, so that decentralizing the process no longer requires a central instance and thus solves the Man in the Middle problem. Encryption is also an integral process that blockchain technology uses in data storage and transaction processes. It is particularly important to cover the scope of data encryption in transit which is the next element of the security requirement. In addition to this, cryptographic keys can be utilized to prove, for example, authorship of the questionnaire and response. Furthermore, with the utilization of the blockchain, the Security profile can be completely eliminated from the physical certification process because security authentication and access to control policies are obtained through the data management that blockchain brings in its technical architecture. In conclusion, it can be said that the blockchain provides innovation and improvement in the process of creating a security profile and thus shortens the process to establish and obtain certification, and reduces costs because no additional resources are needed to research and identify security risks.

The next step 201c in the flow is the production of the vendor's response. In the art, the vendor's response is also referred to as the vendor questionnaire (VQ). In the group of actions related to the VQ is the preparation of the questionnaire by the vendor. It usually contains relevant information about the vendor, technical data on the type of product and its basic classification. Furthermore, there is typically information on the type of sensor (device) and elements related to the certificate of analysis (COA), the material built into the device and, elements of measuring ranges, and functional elements directly related to the method and the type of data obtained from the measurements, their processing if any and the method of transfer to the selected form of metadata. These latter elements are important from the perspective of the metadata generated by the device. These elements relate to the conceptual and technical content of the metadata but also to the contextual content.

The VQ is stored in the blockchain by writing the contents of the metadata to the transaction and becoming part of the newly created block 203d. The metadata may be encrypted. It is also possible to store the (encrypted) content of the metadata in the same block 203c as the questionnaire of the certification body, depending on the number of possible transactions in one block and when the transactions are submitted to the blockchain. The outputs or answers to these questions are considered evidence within the traditional VQ procedure implemented by ToE (Target of Evaluation) as a technology provider and must be presented in the process of evaluation or verification of answers. The responses are also an integral part of the ToE Security Functionality (TSF) which documents the overall functionality of the hardware, software and all firmware variants implemented by the vendor in the sensor itself (loT device). As the questionnaire can be misused in the traditional process, storing it on the blockchain prevents the risk of attacks and changes to the data or responses that the questionnaire should save as evidence for further exploitation of sensors in the system. The goals achieved by storing the VU on blockchain are significant, from both low-risk and high-risk ones. Of particular relevance are those that relate to the data in the questionnaire and are directly related to data privacy, confidentiality and data availability. With the use of strong authentication and encryption in its core, blockchain solves the above high-risk data problems as the data is made unchangeable in the process by storing the transactions on the blockchain.

As sensors or loT devices are mainly related to operational engagement, it is beneficial that the VQ contains references to security requirements. Some of the security requirements that are initiated by a traditional questionnaire are difficult to achieve and so the blockchain facilitates them as an integral element of the architecture via secure storage and tamper-resistant encryption (e.g. with SHA-256) and digital signatures.. In addition to the above security requirements that are part of the technical and functional characteristics of sensors and metadata production, a large share is in reducing costs because it reduces the engagement of additional expert resources and speeds up the digital transformation process in general.

The next step 201dof the traditional sensor metadata certification is the verification (or evaluation) process. The purpose of verification is to provide evidence and assurance that the sensor (loT device) has met the requirements set by the certification body. Verification ensures that the content of the certified sensor metadata is fully supported by industry targets for availability with the aim of originality, protection, confidentiality and immutability of stored and transactional data covering functions and services during the life cycle of an loT device. Particular attention in this process is paid to the security objectives and requirements that have already been mentioned and in the verification, process contribute to the confirmation of the definition and fulfilment of cybersecurity laws.

The verification system of these elements is very suitable for the application of blockchain smart contracts by which the verification system can be executed according to the automated execution principle. Although smart contracts are not executed independently it is necessary to initiate action by the user, in this case, the certificate applicant, who uses a blockchain public key to initiate a smart contract and thus triggers the execution of a smart contract which is also a verifier in this case. If the smart contract is successfully executed over the certification body specification from 201a with its metadata content 201c, then certification is achieved. This shortens the process for the physical step of verification and the blockchain application enables, in addition to saving resources, the fulfilment of all security and legal conditions for automatic verification of metadata of a given sensor through the form of a smart contract.

The final step 201e in the traditional process is the issuance of a certificate. In the written-paper form that is traditionally in use and in some cases also available as a download option via web tools, a certificate called loT Metadata Certification Statement (MCST) is issued. This document carries all the information about the certified device but as such is quite unreliable -if it is in paper form or vulnerable if it is in the existing electronic form. Especially in electronic form, it is still susceptible to Fraud & Misuse abuses as well as security issues. According to the described embodiments, verification of sensor metadata via a smart contract allows for the transaction that stores the response to be the certificate. This certificate remains permanently inscribed on the Blockchain and cannot be modified. This makes it available to everyone and at any time.

Figure 4 also shows the principle of adding a new block 203c to the blockchain. In the process of forming a new block 203c, in addition to the list of transactions, the new block comprises a header of the block which contains a reference to the previous block. Validation of transactions is performed based on the consensus of the network. If a transaction is valid it is added to unconfirmed transactions, to the so-called mempool or temporary store of transactions which saves them for inclusion in the next block 301n.

The certification body questionnaire and the vendor sensor metadata response are submitted to the blockchain in the form of transactions, which ensures the integrity of the sensor metadata and provides constant access to any external user to have insight into the verified transactions. In this way, the given sensor with the corresponding metadata content is certified using the blockchain.

The second flow in Figure 4 illustrates the adding of the certification body questionnaire and the vendor questionnaire to the blockchain using transactions. As shown, both transactions may appear in the same block 203c or in different blocks 203c, 203d.

The third flow in Figure 4 illustrates that according to the described embodiments, certification of a device can be achieved via a shortened process compared to the traditional process. Now, the new process involves in a first step 204a the storage of a certification body questionnaire on the blockchain and in a second step 204b the storage of a vendor questionnaire on the blockchain. Although shown as a separate step 204c, the successful recording of the vendor questionnaire on the blockchain acts as the issuance of the certificate 204.

Figure 5 shows the principle of sensor metadata verification using the blockchain 402. At the request of a user -e.g. client 403a-403n, a new transaction is broadcast for enrollment in a new block 401n aimed at verifying the certificate of a sensor (e.g. loT device) 404a-404n. Data on the newly initiated transaction comes to the hash pool 405 (or other type of blockchain node). A new mining process is initiated from the hash pool, which aims to validate a transaction that has been broadcasted by one of the client's 403. In order for the validation to be performed, the initiated transaction automatically calls a smart contract or a digital script that contains predefined rules on the required certificate for a given sensor 404. The smart contract is automatically executed and generates output information about the validation of the sensor 404 or the content of the metadata for a given sensor based on the client's request 403. Such a valid transaction in the hash pool 405 is subjected to the process of blasting and solving a complex task or hash puzzle. When the solution is found, a new block 401n is created and it can be assumed that the metadata validation process has been carried out and that the 406c certificate has been obtained automatically.

Autonomous sensor (e.g. loT device) metadata certification occurs, in the current circumstances, after the construction and also during the operation of the sensor (loT device). Data on sensor functionality and technical characteristics are contained in metadata to be certified. This data provides evidence that the sensor meets the technical and safety requirements prescribed by the certification body for standardization. The usual certification procedure involves the following steps: generating a questionnaire, creating a security profile, generating a vendor Questionnaire, evaluation, and certification. With the introduction of blockchain technology, it is not necessary to carry out the steps relating to the security profile and evaluation. Security profiles are filled in by blockchain itself by the nature of the technology and evaluation is not required because the evaluation process is combined with certification. As the questionnaires are stored and remain available on the blockchain, the user, upon request for a sensor certificate, initiates a blockchain transaction which, if valid, provides proof that the data contained in the sensor metadata is correct. Thus, certified for exploitation without the participation of the central instance that performs the certification of the sensor, i.e., the sensor is able to independently respond to the certification process in a given operating environment.

Storage of questionnaires issued by a certification body on a blockchain reduces the questionnaire process as it requires only a single iteration of the process of digitization and storage of the questionnaire. Once stored, the questionnaire remains stored on the blockchain network and does not need to be re-created, but only called at the moment of sensor metadata verification, regardless of which sensor it is and whether a first or repeated sensor certification is in progress. With this procedure, manipulation of the questionnaire data is avoided.

The step of storing the VU on the blockchain enables questionnaire verification at any time of suspicion of unauthorized modification without the participation of a central instance that checks and verifies the security profile. This process in the current conditions of manual preparation and data processing lasts typically from several days to several weeks. With the utilization of the blockchain, the process is reduced to a negligible amount of time and denies the necessity of operations of the vast majority of manual risk analysis.

When everything is fulfilled as specified, the sensor behaves as an autonomous object in a given system. The vendor is sufficient to produce a physical device and initialize into it the metadata available in the form of a VQ. The sensor is ready to certify itself at the request of the client (user or service provider) at any time from activation by providing the certificate applicant with information stored on the blockchain with all the security and technically valid elements described in the metadata. The participation of the vendor itself or some central instance that will confirm the parameters that are written as sensor metadata is no longer required.

The application of blockchain technology in the process of searching and validating metadata sensors via smart contract and blasting process differs from the requirements that already exist as web tools for issuing certificates. An advantage is that the data entered in the blockchain as well as the smart contract itself, once entered and available to everyone via the blockchain network, can no longer be deleted or modified. In this way, all security risks described in the sensor metadata certification process are removed. This process is also advantageous in relation to the existing method of metadata certification because it shortens the process in relation to the number of days/experts required to carry out the certification. That number of days has been reduced to a minimum, i.e., to the simple digitization of the existing questionnaires of the certification body and the vendor questionnaire.

Automatic execution of a smart contract, initiating and executing a transaction verification process that contains questionnaires about a given sensor or questionnaires, makes the process almost independent in all steps when issuing certificates, which in its current form requires the human factor and thus centralized and subject to numerous repetitive errors and manipulations.

This approach in the certification of sensors and their metadata in loT devices -systems accelerates the process of appearance of sensors on the market while supporting the security, transparency and immutability of certificate data.

It will be understood that the processor or processing system or circuitry referred to herein may in practice be provided by a single chip or integrated circuit or plural chips or integrated circuits, optionally provided as a chipset, an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), digital signal processor (DSP), graphics processing units (GPUs), etc. The chip or chips may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor or processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry, which are configurable so as to operate in accordance with the exemplary embodiments. In this regard, the exemplary embodiments may be implemented at least in part by computer software stored in (non-transitory) memory and executable by the processor, or by hardware, or by a combination of tangibly stored software and hardware (and tangibly stored firmware).

Reference is made herein to data storage for storing data. This may be provided by a single device or by plural devices. Suitable devices include for example a hard disk and non-volatile semiconductor memory.

Although at least some aspects of the embodiments described herein with reference to the drawings comprise computer processes performed in processing systems or processors, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of non-transitory source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other non-transitory form suitable for use in the implementation of processes according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may comprise a storage medium, such as a solid-state drive (SSD) or other semiconductor-based RAM; a ROM, for example a CD ROM or a semiconductor ROM; a magnetic recording medium, for example a floppy disk or hard disk; optical memory devices in general; etc.

CONCLUSION

The examples described herein are to be understood as illustrative examples of embodiments of the invention. Further embodiments and examples are envisaged. Any feature described in relation to any one example or embodiment may be used alone or in combination with other features. In addition, any feature described in relation to any one example or embodiment may also be used in combination with one or more features of any other of the examples or embodiments, or any combination of any other of the examples or embodiments.

Furthermore, equivalents and modifications not described herein may also be employed within the scope of the invention, which is defined in the claims.

More generally, according to one aspect disclosed herein there is provided a computer-implemented method of enabling certification of a device using a blockchain, wherein the method is performed by a certification entity and comprises: creating a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device; and causing the first blockchain transaction to be recorded on the blockchain.

According to another aspect disclosed herein there is provided a computer-implemented method of certifying a device using a blockchain, wherein the blockchain comprises a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, and wherein the method is performed by a device entity and comprises: creating a second blockchain transaction, wherein the second blockchain transaction references the first blockchain transaction and comprises a respective answer to each of the plurality of questions for a target device; and causing the second blockchain transaction to be recorded on the blockchain, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device.

In embodiments, the blockchain may be an account-based blockchain.

In embodiments, first blockchain transaction may be configured such that the smart contract can be successfully called multiple times by different second blockchain transactions.

In embodiments, the blockchain may be an output-based blockchain.

In embodiments, the first blockchain transaction may be configured such that the smart contract can be successfully called only a single time by a second blockchain transaction.

In embodiments, the device may be an autonomous sensor.

In embodiments, the device may be an internet-of-things, loT, device.

In embodiments, the smart contract may be configured to verify that the respective answer to each respective question comprises one, some or all of: a predefined data type, a predefined minimum length, a predefined maximum length, a predefined length range.

In embodiments, the first blockchain transaction may comprise a signature corresponding to a public key associated with the certification entity.

In embodiments, the second blockchain transaction may comprise a signature corresponding to a public key associated with the device entity.

In embodiments, the first blockchain transaction may be locked to a public key associated with the device entity.

In embodiments, the method may comprise making the second blockchain transaction and/or an identifier of the second blockchain transaction available to a third entity for proving that to the third party that the target device has been certified by the certificate body.

In embodiments, the device entity may comprise the target device, and wherein the target device may be configured to generate one, some or all of the respective answers.

In embodiments, the device entity may comprise the target device, and wherein the target device may be configured to generate the second blockchain transaction.

According to another aspect disclosed herein there is provided computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of the embodiments described herein.

According to another aspect disclosed herein there is provided a computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of the embodiments described herein.

Claims

CLAIMS1. A computer-implemented method of enabling certification of a device using a blockchain, wherein the method is performed by a certification entity and comprises: creating a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device; and causing the first blockchain transaction to be recorded on the blockchain.
2. A computer-implemented method of certifying a device using a blockchain, wherein the blockchain comprises a first blockchain transaction, wherein the first blockchain transaction comprises a smart contract, wherein the smart contract comprises a plurality of questions relating to properties of a device to be certified, and wherein the smart contract is configured to, when called by a second blockchain transaction, verify that the second blockchain transaction comprises a respective answer to each of the plurality of questions, and wherein the method is performed by a device entity and comprises: creating a second blockchain transaction, wherein the second blockchain transaction references the first blockchain transaction and comprises a respective answer to each of the plurality of questions for a target device; and causing the second blockchain transaction to be recorded on the blockchain, such that the second blockchain transaction, once successfully recorded on the blockchain, is the certificate for the device.
3. The method of claim 1 or claim 2, wherein the blockchain is an account-based blockchain.
4. The method of claim 3, wherein the first blockchain transaction is configured such that the smart contract can be successfully called multiple times by different second blockchain transactions.
5. The method of claim 1 or claim 2, wherein the blockchain is an output-based blockchain.
6. The method of claim 5, wherein the first blockchain transaction is configured such that the smart contract can be successfully called only a single time by a second blockchain transaction.
7. The method of any preceding claim, wherein the device is an autonomous sensor.
8. The method of any preceding claim, wherein the device is an internet-of-things, loT, device.
9. The method of any preceding claim, wherein the smart contract is configured to verify that the respective answer to each respective question comprises one, some or all of: a predefined data type, a predefined minimum length, a predefined maximum length, a predefined length range.
10. The method of any preceding claim, wherein the first blockchain transaction comprises a signature corresponding to a public key associated with the certification entity.
11. The method of any preceding claim, wherein the second blockchain transaction comprises a signature corresponding to a public key associated with the device entity.
12. The method of any preceding claim, wherein the first blockchain transaction is locked to a public key associated with the device entity.
13. The method of claim 2 or any claim dependent thereon, comprising making the second blockchain transaction and/or an identifier of the second blockchain transaction available to a third entity for proving that to the third party that the target device has been certified by the certificate body.
14. The method of claim 2 or any claim dependent thereon, wherein the device entity comprises the target device, and wherein the target device is configured to generate one, some or all of the respective answers.
15. The method of claim 2 or any claim dependent thereon, wherein the device entity comprises the target device, and wherein the target device is configured to generate the second blockchain transaction.
16. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 15.
17. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 15.