communication protocol

Abstract

A computer-implemented method for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence is defined as being the most secure level, and a final security level in the sequence is defined as being the least secure level, the respective security of each security level in the sequence being defined as decreasing from the first security level to the final security level, each respective node having a respective security certificate associated with a respective security level, each node being configured to communicate with other nodes according to a communication protocol, and the method is performed by a first node having a first certificate communicating with a second node having a second certificate according to the communication protocol.

Description

[Technical Field]

[0001] The present disclosure relates to methods for communicating between nodes in a secure manner and methods for enabling nodes to communicate in a secure manner. [Background technology]

[0002] Nodes in computer networks, including the Internet, can be highly heterogeneous. These networked computers can range from IoT devices and smartphones to supercomputers and data centers for cloud computing. Each piece of hardware is characterized by its corresponding level of computational power, functionality, and data storage, among other things. At the same time, the software running on the hardware, both applications and operating systems, serves to define the device.

[0003] Devices on a network can also be characterized by the security they may provide and / or require. As an example, a large enterprise data center will require greater security measures than a random IoT device in a home network. Given the different levels of security assurance that some nodes can provide, it may be prudent for some nodes to constrain the nodes with which they communicate based on their trust in the security levels that these other nodes can provide. Summary of the Invention [Means for solving the problem]

[0004] According to one aspect disclosed herein, there is provided a computer-implemented method for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence is defined to be the most secure level and a final security level in the sequence is defined to be the least secure level, wherein respective security levels in the sequence are defined to decrease from the first security level to the final security level, each respective node having a respective security certificate associated with each security level, and each node configured to communicate with other nodes according to a communication protocol, the communication protocol following at least the following rules: i) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any less secure security level in the sequence; ii) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with the next more secure security level adjacent to the respective security level in the sequence; iii) each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with a less secure security level adjacent to the respective security level in the sequence; and iv) providing that each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with any more secure security level in the sequence; The method is performed by a first node having a first certificate communicating with a second node having a second certificate according to a communication protocol.

[0005] According to another aspect disclosed herein, a computer-implemented method for secure communication between a set of nodes is disclosed, wherein a sequence of security levels is defined, a first security level in the sequence is defined to be the most secure level and a final security level in the sequence is defined to be the least secure level, a respective security of each security level in the sequence being defined to decrease from the first security level to the final security level, each respective node having a respective security certificate associated with each security level, and each node configured to communicate with other nodes according to a communication protocol, the communication protocol following at least the following rules: i) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any less secure security level in the sequence; ii) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any one, but not all, of the next more secure security levels in the sequence; iii) each node having a respective certificate associated with each security level can receive messages from each node having a respective certificate associated with any one or more, but not all, of the less secure security levels in the sequence; and iv) providing that each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with any more secure security level in the sequence; The method is performed by a first node having a first certificate communicating with a second node having a second certificate according to a communication protocol.

[0006] Embodiments of the present disclosure provide a protocol for communication between nodes in a network having n security levels, where nodes can only engage in communications with other nodes based on the node's relative security level. Each node in the network is assigned a security certificate that attests to the node's security level. In some examples, the node's proof of security is represented on a blockchain. The protocol allows nodes to communicate securely within the network.

[0007] According to another aspect disclosed herein, there is provided a computer-implemented method for issuing security certificates for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence is defined to be the most secure level and a final security level in the sequence is defined to be the least secure level, wherein a respective security of each security level in the sequence is defined to decrease from the first security level to the final security level, each respective node has a respective security certificate associated with a respective security level, each certificate authority in a set of certificate authorities is associated with a respective security level, each security certificate associated with each security level is signed by a respective certificate authority associated with the respective security level, and each certificate authority is configured to issue the security certificate according to a certificate issuance protocol, wherein the certificate issuance protocol follows at least the following rules: i) Certification authorities associated with each security level can issue security certificates associated with the same respective security level; ii) a certificate authority associated with each security level can issue security certificates to nodes that have security certificates with less secure security levels adjacent to the respective security level in the sequence; and iii) providing that a certification authority associated with each security level may reissue security certificates to nodes that have expired or revoked certificates associated with the same respective security level; The method is performed by a first certificate authority and comprises issuing a security certificate to a requesting node according to a certificate issuing protocol.

[0008] According to another aspect disclosed herein, a computer-implemented method for issuing security certificates for secure communication between a set of nodes is disclosed, wherein a sequence of security levels is defined, a first security level in the sequence is defined to be the most secure level and a final security level in the sequence is defined to be the least secure level, and a respective security of each security level in the sequence is defined to decrease from the first security level to the final security level, each respective node has a respective security certificate associated with a respective security level, each certificate authority in a set of certificate authorities is associated with a respective security level, and each security certificate associated with each security level is signed by a respective certificate authority associated with the respective security level, and each certificate authority is configured to issue security certificates according to a certificate issuance protocol, the certificate issuance protocol following at least the following rules: i) Certification authorities associated with each security level can issue security certificates associated with the same respective security level; ii) a certificate authority associated with each security level can issue security certificates to nodes that have security certificates with one or more, but not all, of the less secure security levels in the sequence; and iii) providing that a certification authority associated with each security level may reissue security certificates to nodes that have expired or revoked certificates associated with the same respective security level; The method is performed by a first certificate authority and comprises issuing a security certificate to a requesting node according to a certificate issuing protocol.

[0009] Embodiments also provide a protocol for the issuance of security credentials to nodes, where a node can only obtain a security credential for a given security level from a certificate authority that is authorized to provide security credentials for that level. In some examples, the security credential is published on the blockchain.

[0010] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made by way of example only to the accompanying drawings, in which: [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of an exemplary system having multiple security levels (zones). [Figure 4] FIG. 2 is a diagram illustrating an exemplary communication link between nodes in different security zones. [Figure 5] FIG. 2 is a diagram illustrating an exemplary communication link between a node and a certification authority. [Figure 6] FIG. 2 is a diagram illustrating an exemplary relationship between security and CA certificates. [Figure 7] FIG. 1 illustrates a schematic diagram of an exemplary process for node certification. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1. Communication Protocol and Certificate Issuance Protocol 3 illustrates an exemplary system 300 for implementing an embodiment of the present disclosure. The system 300 includes a plurality of nodes 301. Each node 301 is a computing device. Some or all of the nodes 301 may take the same form of a computing device, or some or all of the nodes 301 may take different forms of computing devices. Together, the nodes 301 form a network of devices. It should be noted that the nodes 301 should not be confused with the blockchain nodes 104 described below with reference to FIG. 1, but it should not be excluded that the nodes 301 may be blockchain nodes 104.

[0013] Each node 301 comprises a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0014] The system 300 comprises multiple security layers, or security levels, or security zones 302. It should be noted that these layers 302 may or may not be physical, e.g., different zones of a building; i.e., the system 300 need not have any physical barriers or partitions between the layers 302. The security layers 302 are defined in a sequence starting with the first (or initial) layer and ending with the last (or final) layer. The first layer is the most secure layer, and the last layer is the least secure layer. With each layer from the first to the last, the layers become less secure. For simplicity, the most secure layer is labeled “Level 1” in FIG. 3 and the least secure layer is labeled “Level 4” (there are only four layers in this example). However, it should be noted that Level 4 may be the most secure layer and Level 1 may be the least secure layer. It should be appreciated that the system 300 may include any number of nodes 301 and have any number of layers 302.

[0015] Each node 301 is associated with a “security certificate,” i.e., a digital certificate signed by a certificate authority 303 (not shown in FIG. 3 ). The certificate authority 303 is an entity assigned the responsibility and authority to issue security certificates for use by the nodes 301 of the system 300. The security certificate may comprise an identifier of the node 301 to which the security certificate is issued. The identifier may comprise a network identifier of the node 301, such as an IP (e.g., IPv6) address. The identifier may comprise the public key of the node 301, i.e., a public key for which the node 301 has control of its corresponding private key. The security certificate may comprise the signature of the certificate authority 303 that issued the certificate, or may be signed by such certificate authority 303. The security certificate may be stored on the blockchain 150, as described below.

[0016] A security credential is associated with a given security layer 302. For example, a security credential may be associated with the most secure layer (e.g., level 1) or the least secure layer (e.g., level 4), or an intermediate layer (e.g., level 2). A security credential is associated with only a single security layer 302.

[0017] The nodes 301 are configured to communicate with each other based on a communication protocol, i.e., according to the rules defined by the communication protocol. More specifically, the nodes 301 can only communicate if the communication complies with all of the rules; i.e., no other communication is allowed.

[0018] The first rule of the communication protocol is that a node 301 having a security certificate associated with a given security layer 302 can send a message to a node 301 having a security certificate associated with any less secure security layer 302.

[0019] The second rule of the communication protocol is that a node 301 having a security credential associated with a given security layer 302 can send a message to a node 301 having a security credential associated with the next more secure security layer 302, but cannot send to any security layer above (i.e., more secure than) the next more secure security layer 302. For example, a node at level 1 can send messages to nodes 301 at levels 2, 3, and 4 (satisfying the first rule). A node 301 at level 2 can send messages to nodes 301 at levels 3 and 4 (satisfying the first rule) and to nodes at level 1 (satisfying the second rule). A node 301 at level 3 can send messages to nodes at level 4 (satisfying the first rule) and to nodes at level 2 (satisfying the second rule), but cannot send to nodes at level 1 (due to the second rule). A node 301 can also send messages to other nodes 301 having the same security credential (i.e., a security credential associated with the same security layer 302).

[0020] The third rule of the communication protocol is that a node 301 having a security certificate associated with a given security layer 302 can receive messages from a node 301 having a security certificate associated with any more secure security layer 302.

[0021] The fourth rule of the communications protocol is that a node 301 having a security certificate associated with a given security layer 302 can receive messages from a node 301 having a security certificate associated with the next less secure security layer 302, but cannot receive messages from any security layer below (i.e., less secure than) the next less secure security layer 302.

[0022] For example, a node at level 1 can receive a message from node 301 at level 2 (satisfying rule 4), but cannot receive from a node at level 3 or level 4 (due to rule 4). Node 301 at level 2 can receive a message from node 301 at level 1 (satisfying rule 3) and level 3 (satisfying rule 4), but cannot receive from a node at level 4 (due to rule 4). Node 301 at level 3 can receive messages from nodes 301 at levels 1 and 2 (satisfying rule 3) and from nodes at level 4 (satisfying rule 4). Node 301 can also receive messages from other nodes 301 that have the same security credentials (i.e., security credentials associated with the same security layer 302).

[0023] In some examples, the second and fourth rules of the communication protocol may be less strict than the examples described above. For example, the second rule may be relaxed to allow a node to send messages to nodes at more secure adjacent security levels as well as above. Similarly, the second rule may be relaxed to allow a node to receive and accept messages from nodes at less secure adjacent security levels as well as above. In general, a node may send messages to nodes at any, but not all, more secure security levels and may receive messages from nodes at any, but not all, less secure security levels. For example, a node may send messages to nodes at the next more secure n security levels, where n is less than the number of more secure remaining security levels in the sequence, and the node may receive messages from nodes at the next less secure m security levels, where m is less than the number of less secure remaining security levels in the sequence. In some examples, n and m are the same number. n and m may define a threshold number of security levels. The threshold may be defined by a user of the system of nodes. The threshold may be based on one or more characteristics of the system, such as one or more characteristics of the nodes, e.g., the type of communication (e.g., wired or wireless) between the nodes and / or the type of data communicated between the nodes (e.g., based on a sensitivity measure), and / or one or more characteristics of the sequence of levels (e.g., the total number of levels in the sequence). As a particular example, the threshold may be set to be at least a function of the number of levels (e.g., round, ceiling, or truncate), e.g., equal to round(number of levels / 4).

[0024] A communications protocol may specify that messages should be sent in encrypted form, and therefore any reference to sending a message may be understood to mean that the message is an encrypted message, unless the context requires otherwise.

[0025] The communication protocol may specify that messages sent between nodes 301 (i.e., to and from nodes 301) within and between security layers 302 may be encrypted using symmetric or asymmetric encryption keys. In some examples, symmetric encryption is used to encrypt messages sent between nodes 301 within security layer 302. In some examples, asymmetric encryption is used to encrypt messages sent between nodes 301 between security layers 302.

[0026] As a specific example, the communication protocol may specify that messages sent between (i.e., to and from) nodes 301 of adjacent security layers 302 are encrypted using an encryption key based on the public key of the node 301 receiving the message (receiving node) and the private key of the node 301 sending the message (sending node). The encryption key may also be generated using the private key of the receiving node and the public key of the sending node. The encryption key may be a symmetric encryption key. The encryption key may be generated using a Diffie-Helman key exchange (described below). The public and private keys may be elliptic curve keys.

[0027] The communication protocol may specify that messages sent between (i.e., to and from) nodes 301 of non-adjacent security layers 302 are encrypted using an encryption key that is based solely on the public key of the receiving node. The public key may be an RSA key.

[0028] 4 illustrates schematically that messages are sent between adjacent nodes 301 (i.e., nodes 301 associated with adjacent security layers 302) and between non-adjacent nodes 301 (i.e., nodes 301 associated with non-adjacent security layers 302). As shown, messages sent between node n1 (Level 1) and node n2 (Level 2) are encrypted using a symmetric key S generated using the key of node n1 and the key of node n2. 1,2 Messages sent between node n1 (level 1) and node n3 (level 3) are encrypted using the asymmetric key As3 generated using the public key of node n3.

[0029] Other encryption schemes may be used for either type of message.

[0030] The communication protocol may specify a process, e.g., a handshake procedure, that must be performed before a message can be communicated for the first time between adjacent security layer 302 nodes. The sending node 301 first sends a request to the receiving node 301. The request includes the sending node's certificate or a reference to where the certificate is located. For example, the reference may include a transaction identifier for a transaction on the blockchain 150, where the transaction includes the certificate. The receiving node 301 validates the security certificate. This may include verifying that the certificate includes or is signed by a certificate authority authorized to issue security certificates. This may also include verifying that the sending node's 301 certificate is associated with an appropriate security level, i.e., a security level at which the sending node is permitted to send communications from it to the receiving node 301, based on the rules of the communication protocol.

[0031] If the security certificate verification passes, the receiving node 301 sends a verification message to the sending node (this message may or may not be encrypted). The sending node 301 signs the verification message using its private key and sends the resulting verification signature to the receiving node 301. The receiving node 301 verifies the verification signature; that is, the receiving node 301 verifies that the signature is valid for the sending node's public key. If the signature verification passes, the receiving node 301 accepts the message from the sending node 301. This may comprise performing a Diffie-Helman key exchange or similar with the sending node 301 to establish encryption keys.

[0032] The communication protocol may specify the process that must be performed for messages to be communicated between nodes in non-adjacent security layers 302 when the receiving node 301 is located in a more secure layer than the sending node 301. In this case, the sending node 301 shall send a message (which may be encrypted) to an intermediate node in an adjacent, more secure layer and request that the message be forwarded to the receiving node 301. If the intermediate node 301 is in an adjacent layer to the receiving node 301, the intermediate node 301 sends the message to the receiving node. If the intermediate node 301 is not in an adjacent layer to the receiving node 301, the intermediate node 301 forwards the message to another intermediate layer in an adjacent, more secure layer and requests that the message be forwarded to the receiving node 301. This process may be repeated one or more times until the message is finally received by the receiving node 301.

[0033] In some examples, further rules may be specified by the communication protocol. In these examples, each security layer is associated with the most secure security layer to which a node in a given security layer can communicate. That is, when this rule is implemented, an upper limit is placed on the security layers to which a node can communicate. A node in a security layer can communicate with nodes in more secure layers up to the specified most secure security layer, but cannot communicate with nodes in more secure layers. Note that the "most secure security layer" does not necessarily mean the most secure security layer in a sequence of security layers. Furthermore, this rule specifies that, with respect to adjacent layers, a node in a less secure layer cannot communicate with a node that is more secure than a node in a more secure layer can communicate with. In other words, let n be a security layer, and let L(n) be the most secure layer to which a node can directly message from layer n. This rule specifies that L(n) <= L(n+1).

[0034] In some embodiments, the security layers also configure certificate authorities (CAs) 303, i.e., each CA 303 is associated with a respective security layer. In these embodiments, each CA 303 is configured to issue security certificates according to a certificate issuance protocol, i.e., according to rules defined by the certificate issuance protocol. More specifically, a CA 301 can only issue a certificate if the issuance complies with all of the rules.

[0035] The first rule of the certificate issuance protocol is that a CA 303 can issue a certificate associated with the same security level 302 that the CA 303 is associated with. That is, a CA 303 can issue a certificate to a node 301 for the security level 302 occupied by the CA 303. For example, referring to FIG. 5, a CA at level nn is the node n n Certificates can be issued to:

[0036] The second rule of the certificate issuance protocol is that CA 303 can issue certificates associated with adjacent less secure security levels, but cannot issue any certificates associated with any less secure non-adjacent security levels. n-2 is the node n at level n-1 n-1 can issue certificates to node n at level n n It cannot be issued to.

[0037] The third rule of the certificate issuance protocol is that CA 303 may reissue a certificate to a node 301 that previously had a security certificate associated with the same security level as CA 303. For example, node 301 may seek a certificate again after its previous certificate has been revoked or expired.

[0038] The fourth rule of the certificate issuance protocol is that CA 303 cannot issue certificates associated with a more secure security level.

[0039] In some examples, the second rule of the certificate issuance protocol may be less strict than the examples described above. For example, the second rule may be relaxed to allow issuance of certificates to nodes at less secure adjacent security levels as well as above. In general, a CA may issue certificates to nodes at any, but not all, of the less secure security levels. For example, a CA may issue certificates to nodes at the next less secure x security levels, where x is less than the number of remaining less secure security levels in the sequence. x and m may define a threshold number of security levels. The threshold may be defined by a user of the system of nodes. The threshold may be based on one or more characteristics of the nodes, e.g., the type of communication (e.g., wired or wireless) between the nodes and / or the type of data communicated between the nodes (e.g., based on a sensitivity measure), and / or one or more characteristics of the sequence of levels (e.g., the total number of levels in the sequence). As a particular example, the threshold may be set to be at least a function of the number of levels (eg, round, ceiling, or truncate), for example, equal to round(number of levels / 4).

[0040] Node 301 and CA 303 may interact in the following manner to obtain a certificate: A node 301 requesting a certificate (requesting node) sends a request to a CA 303 associated with a particular security level 302 for a certificate associated with that level 302. The CA 303 performs one or more checks to determine that the requesting node 301 is eligible for such a certificate. This may include determining whether the requesting node 301 has a valid certificate for a less secure adjacent level 302. If the validation passes, the CA 303 generates a security certificate associated with the requesting node 301 and the security level associated with CA 303. The security certificate is sent to the requesting node 301. In some examples, the CA 303 submits a transaction to the blockchain 150 that includes the security certificate and / or a hash of the security certificate.

[0041] A communication protocol may define how nodes 301 can communicate with CAs 303 and / or how CAs 303 can communicate with each other.

[0042] Starting with the interaction between node 301 and CA 303, the communication protocol may specify that a node 301 having a security certificate associated with a given security layer 302 can send messages to, and receive messages from, a CA 303 having a security certificate associated with the same layer 302 or an adjacent layer 302. A node 301 having a security certificate associated with a given security layer 302 can request a security certificate from a CA 303 associated with a more secure adjacent security layer 302, but not from a CA 303 associated with a more secure non-adjacent security layer 302.

[0043] With respect to interactions between CAs, a CA 303 associated with a given security layer 302 can communicate with CAs 303 associated with the same security layer 302 and with CAs 303 associated with adjacent security layers 302 .

[0044] Further optional examples are described below.

[0045] 2. Cryptographic techniques 2.1 X.509 Certificates X.509 is a standard format for public key certificates, digital documents that securely associate a cryptographic key pair with an identity such as a website, an individual, or an organization. Each X.509 certificate contains at least a public key, a digital signature, and information about both the identity associated with the certificate and its issuing certification authority (CA).

[0046] Information fields include details such as the name and address of the organization, details of the signature algorithm used, and the expiry date. X.509 certificates can be revoked before their expiry date.

[0047] The transparency and immutability properties of blockchain are often cited as being useful in issuing and storing digital certificates.

[0048] 2.2 Diffie-Hellman Secure communication between nodes can be accomplished through encryption. This can be done using either symmetric or asymmetric encryption solutions. In the case of symmetric encryption, a Diffie-Hellman exchange can be utilized to securely establish a shared key between a pair of nodes. In the case of elliptic curve cryptography, a Diffie-Hellman exchange can be accomplished through the following steps: 1. Each party creates their public-private key pair using secp256k1. Bob (v B ,P B ), Alice (v A ,P A ), but P B =vB G and P A =v A G. 2. Each party shares their public key with the others. Bob gives Alice the key P B Alice gives Bob the key P A This can be done via public channels. 3. Each party multiplies the other's public key by their (the original party's) private key. Bob multiplies v B P A Calculate v. A P B Calculate. 4. Both parties now possess a shared key that can be used for symmetric encryption. S AB =v B P A =v A P B =v B v A G=v A v B G

[0049] Neither party needs to know the other's private key; the third party only needs to know the private key v A or v B If S does not have knowledge of any of the AB cannot be determined.

[0050] 2.3 RSA Encryption For asymmetric encryption, RSA may be used. With RSA, both parties each have the same public-private key pair. The public key is used to encrypt a message, while the private key is used to decrypt the message. RSA encryption has several major steps: - Generate the RSA modulus (n). Choose two large prime numbers p and q, both of which are kept secret. Calculate n = p × q. The length n is often referred to in bits. For strong encryption, n should be a large number, usually at least 512 bits. - Find the derived number (e). 〇Choose an integer e greater than 1 and less than (p - 1)(q - 1). Assume that e and (p - 1)(q - 1) have no common divisors except 1. In other words, the two numbers e and (p - 1)(q - 1) are relatively prime. - Create a public key. The number pair (n, e) forms an RSA public key. - Generate a private key. A private key d is calculated from p, q, and e. For a given n and e, there is a unique number d. The number d is the reciprocal modulo (p - 1)(q - 1). This means that: ed = 1 mod (p - 1)(q - 1) An extended Euclidean algorithm computes d from the values ​​p, q, and e.

[0051] To encrypt a message m using the public key (n, e) to generate ciphertext c, the following formula is used: C=m e (mod n)

[0052] To decrypt the ciphertext c using the private key d, the following calculation is used: c d =(m e ) d =m (mod n)

[0053] 3. Network Access Control Exchange Protocol This section describes exemplary protocols ("Network Access Protocols") that may be implemented using specific examples of the embodiments described above. It will be appreciated that some examples may be chosen.

[0054] 3.1 Communication between nodes This section describes a network access security protocol in which nodes in a network are certified to one of a distinct set of n (where n>2) security levels (see Figure 3). A node certified to security level i (where i∈[1,n]) is given a health (i.e., security) certificate Cer i is given.

[0055] Certificate i It involves the use of digital signatures by a certificate authority to sign messages that include the node's identity, which may include the node's registered public key.

[0056] Cer i A node with a certificate Cer j (where j>i) is considered more secure than a node with a certificate Cer i For a node with , communication with another node is governed by the following rules: - Certificate i Node n with i is Cer i+v' (where v≧1). - Certificate i Node n with i is Cer i-1 A communication can be sent to a node having - Certificate i Node n with i is Cer i+1 A node having a .times. ... - Certificate i Node n with i is Cer i-v' (where v≧1), it can receive communications from nodes with

[0057] The term "communication" may exclude the transmission of identification and certification. Any node can receive messages containing another node's identity and health certificate.

[0058] Figure 4 shows the communication lines between nodes from each of the security zones. Node n2 can be seen as having the ability to interact directly with a node one level higher in security (n1) and a node one level lower in security (n3). Node n2 can also send communications directly to the less secure node n4, but this cannot be reciprocated; that is, node n4 cannot send messages directly to n2. Another node of interest is node n1, which can interact with n2. Node n1 can send communications to the less secure nodes n3 and n4; however, neither of these two nodes can send messages to node n1.

[0059] 3.2 Communications for Certification Authorities The protocol utilizes multiple Certificate Authorities (CAs), which themselves operate within restricted security zones. i is expected to reside within security zone i. i is constrained as to who it can communicate with. Communications between CAs and nodes are governed by the following principles: - Authority CA i :i≠n is proof Cer i , Cer i+1 , or Cer i-1 A node is allowed to interact with any node that has - Lowest security tolerance CA n A CA with a certificate is allowed to interact with new nodes into the network (nodes that do not have a certificate). - Authority CA i is CA i-1 and CA i+1 It is permissible to interact with - node n in the network i+1to upgrade its health certificate. i ) shall directly interact with the CA. i is the certificate Cer i The node determines (either alone or through a third-party service) whether it satisfies the criteria for receiving the - Authority CA i is the security health level Cer i You can only prove a node to - Certification i A node with a certificate can submit its certificate to Cer i-1 You can only upgrade up to - All accepted certificates of soundness are stored and / or represented on the blockchain 150.

[0060] A depiction of these communication lines is shown in FIG.

[0061] 3.3 Secret messaging between nodes The protocol allows for secret messaging, which means that messages in transit to and from nodes should not be readable by unintended parties. This is achieved by encrypting the messages. In some examples: - each node n i has an EC public-private key pair. For example, node n i is a pair (k i ,P i ) (However, P i =k i G), which is either publicly registered or is a verifiable derivative of a registered public key. Each node has an RSA public-private key pair. For example, node n i is a pair (n i ,e i ), which is either publicly registered or a verifiable derivative of a registered pubkey.

[0062] To carry out a conversation between a pair of nodes, messages between them should be encrypted using a symmetric key, which may be obtained by both parties through a Diffie-Hellman exchange (described below). i+1 Node (n i+1 ) and Cer i-1 Node (n i-1 ) to interact with node n i Recall that a shared symmetric encryption key S can be involved. As an example (see Figure 4), node n2 may acquire a shared symmetric encryption key S through a Diffie-Hellman exchange with n1. 1,2 This key is used (by both nodes) to encrypt messages in communication between the two nodes. Similarly, node n2 generates a shared value S 2,3 with node n3.

[0063] One-way communication between one node and another, i.e., node n i to a less secure node n j (where j>i+1), the sending node uses the RSA public key As j =(n j ,e j ) to encrypt its messages. As an example (see Figure 4), node n1 encrypts messages to n3 using As3 and to n4 using As4. Node n2 also communicates with n4 using As4.

[0064] 3.4 Protocol Process This section describes some of the processes in the network access protocol. 1. Establishment of a Certification Authority. 2. Nodes are certified to the security zones they satisfy. 3. Nodes communicate based on their assigned health level certificates.

[0065] 3.4.1 Establishing a Certification Authority Hierarchy Certificate authority establishment refers to the creation of n+1 certificate authorities for the purpose of certifying the health and security level of the applying node.

[0066] Root Certificate Authority One of these is a root certificate authority (CA) Rt This CA is the initiator of this protocol and is the central, most trusted entity in the network. Its identity and public key

number

number

number

number

[0067] Root Certificate Authority CA Rt has no responsibility to determine or assign health certificates to any non-CA nodes in the network.

[0068] Certification Authority 1-n Non-root Certificate Authority (CA) i :i∈[1,n]) is a trusted server in a hierarchy of trusted authorities on the network, each of which is assigned a security level and is expected to adhere to the corresponding rule set for that security level. This is called the health level Cer i+1 , Cer i , or Cer i-1 CA to be involved in interactions with nodes that do not have i This means that CA's CA is not allowed. i The competent authority shall have the following responsibilities: · CA as CA i+1 This proves that Cer i+1 CA as one of the authorized certification authorities to which authority is delegated to certify nodes for having a health security level of i+1 To prove CA1, i Certificate

number

number

[0069] These CA servers may or may not have different hardware and software installed, and the main thing that distinguishes the security level of a CA is the security level of the nodes that the CA is allowed to communicate with. i is the node n i and n i+1 It is permissible to interact with

[0070] CA

number

number

number

number

number

[0071] Figure 6 shows the health certificate Cer i, and how that certificate interfaces with the CA certificate. As an example, consider the health security certificate Cer1. Each certificate contains a signature from its issuer. CA1 provides a digital signature that signs most, if not all, of the other data in the certificate. The certificate also contains the issuing certificate authority's certificate.

number

number

number

[0072] 3.4.2 Node Proof This section describes the process by which a node obtains a health certificate with reference to FIG.

[0073] New Node Node n does not have any health certificate New The CA with the lowest integrity certificate (CA n ) is only allowed to communicate with -n New is the certificate Cer n A request to be granted to a CA n It will be sent to. - CA n is n Newperforms the necessary checks to determine whether the - If so, CA n is the node n New Certificate for Cer n Create a copy of n New and submit a copy to the blockchain. - Previous n New is n n and can interact with: New node 〇Cer n A node with 〇Cer n-1 A node with 〇CA n 〇CA n-1

[0074] Node n i -n i is the certificate Cer i-1 A request to be granted to a CA i-1 Send to. - CA i-1 is n i performs the necessary checks to determine whether the - If so, CA i-1 is the node n i Certificate for Cer i-1 Create a copy of n i and submit a copy to the blockchain. - Previous n i is n n-1 and can interact with: 〇Cer i A node with 〇Cer i-1 A node with 〇Cer i-2 A node with 〇CA n-1 〇CA n-2 〇CA n

[0075] 3.4.3 Node Communication New Node New node n New is the least secure node n n Node n is allowed to interact with n To communicate with the new node, the following steps are performed: -n New sends a communication request to node n n This communication is sent to New 's identity (e.g., its public key P new ) is included. -n n is a random message m Rnd n New Send to. -n New is P new Sign this message using n n Send to. - If the signature is valid, Both parties engage in a Diffie-Hellman exchange to discover a shared secret, S n,New Generate. 〇S n,New is used to encrypt messages between both parties in any future interactions.

[0076] Node n i ~More secure node n i-1 -n i is node n i-1 This communication is sent to n i 's identity (e.g., its public key P i ) and its health certificate Cer i (or a reference to a transaction that has a certificate on the blockchain). -n i-1 is the node n i against the certificate CA i Verify. -n i-1 is a random message m Rnd n i Send to. -n i is P i Sign this message using n n-1 Send the signature to - If the signature is valid and the certificate is verified, Both parties engage in a Diffie-Hellman exchange to discover a shared secret, S i-1,i Generate. 〇S i-1.i is used to encrypt messages between both parties in any future interactions.

[0077] Node n i ~ less secure node n i+1 -n i is the node n i+1 This communication is sent to n i 's identity (e.g., its public key P i ) and its health certificate Cer i (or a reference to a transaction that has a certificate on the blockchain). -n i+1 is the node n i against the certificate CA i Verify. -n i+1 is a random message m Rnd n i Send to. -n i is P i Sign this message using n n+1 Send the signature to - If the signature is valid and the certificate is verified, Both parties engage in a Diffie-Hellman exchange to discover a shared secret, S i,i+1 Generate. 〇S i.i+1 is used to encrypt messages between both parties in any future interactions.

[0078] Node n i ~ less secure node n j (where j>i+1) -n i is the node n j RSA public key (n j ,e j ) Note that this RSA public key is either a registered public key or a verifiable derivative of a registered public key. [RSA public key (n j ,e j )n j is node n j Note also that we are referring to the RSA modulus (described below) rather than the . -n i is used to authenticate node n using its RSA public key. j Encrypt that message to -n i sends the encrypted message to node n j Send to.

[0079] Node n i ~More secure node n k (However, k <i-1) Node n i is a more secure node n whose security level is at least two levels higher. k If a node n wishes to communicate with another node, it cannot do so directly. The communication must pass through intermediate nodes and their respective security protocols before reaching the intended recipient. i sends a message to node n with instructions for its final destination. i-1 Send to node n i-1 sends a message to node n with instructions for its final destination. i-2 This means that the node sends the k Continue until it reaches

[0080] More formally, node n i is node n k(However, if it is necessary to communicate with k < i - 1 and message m, the message shall be transferred sequentially through the set of nodes {n a : i - 1 ≤ a ≤ k + 1}).

[0081] If privacy is desired, node n i may encrypt message m using the RSA public key (n k , e k ) of node n k and then transfer it along the chain.

[0082] 3.5 Revocation and Isolation 3.5.1 Revocation The soundness certificate usually includes an expiration date, i.e., the date after which the certificate is no longer valid. This gives an opportunity for re-evaluation of the node and its continuing ability to meet the criteria for the certificate. In addition, if a node has failed to comply with its security level agreement, the authorities may wish to revoke the node's certificate (before the expiration date).

[0083] If node n i wishes to renew in case of revocation or expiration of the certificate Cer i for it, the node shall request Cer i from the CA again. The node may request renewal while its current certificate is still valid if it knows that the expiration of its certificate is approaching. i When Cer

[0084] Cer i+1 has expired, a node having the certificate Cer i shall have a valid certificate Cer i+1It may be unsafe to assume that all certificates for various security zones have the same lifetime. It is assumed that the lifetime of all certificates for various security zones is the same. In some cases, the lifetime of security certificates may be uniform across all security zones, or may be uniform only within a security zone but vary across zones. Lifetimes may be customized to individual nodes. It may be considered prudent for high security certificates to have shorter lifetimes in order to continually reassess and ensure that standards are met. This may be unsafe for the Cer i Nodes that lose any Cer automatically default to j Cer i+1 (where j>i+1) does not mean that the node owns the certificate Cer i has already expired, a condition may be built into the protocol where the expired / revoked certificate Cer i Nodes with expired certificates can use their expired certificates to i You can communicate with new Cer i Again CA i can be found in.

[0085] Alternatively, the certificate Cer i (And at least Cer i+1 ) is lost by node n i is CA i Node n may not be allowed to communicate with the i where, by default, node n x where x is the highest valid security certificate level for which the node still has a valid certificate, and x>i+1. The worst case scenario is when a node backs down and New This is the case when the certificate authority is considered to be a CA. i To reacquire x / n New shall again engage in seeking security certificates at higher levels in the sequence until returning to level i.

[0086] 3.5.2 Isolation In some cases, a node may be prohibited from interacting with other nodes in the network at any time. In such cases, a blacklist with the identity of the set of nodes may be maintained. This list may be stored in a location (e.g., a blockchain) accessible to all nodes.

[0087] Any node that receives a request for communication from another node may first check the blacklist to see if the requesting node is blacklisted, and if the node is blacklisted, it is not allowed to interact with the requesting node.

[0088] 3.6 Representing Certificates via Blockchain Blockchain offers several properties and functionality applicable as a store or representation of digital certificates: content transparency provides access and visibility to any interested party of the certificate data, while blockchain's cryptographic and smart contract capabilities provide opportunities for integrating and improving various aspects of digital certificates.

[0089] 3.6.1 Certificate Storage The (OP_RETURN) output of a blockchain transaction can be used to store arbitrary data. This data is stored in a security certificate, Cer i or CA certificate

number

[0090] An example of certificate storage within a transaction is shown in Table 1 below.

[0091] [Table 1]

[0092] Note that the entity signing the transaction inputs is not constrained to be a certificate authority: anyone could theoretically sign the transaction inputs, and the certificate stored in the (OP_RETURN) output contains all the information that gives the certificate its validity, including the issuer's digital signature.

[0093] 3.6.2 Signature Rather than storing the issuer's signature in the (OP_RETURN) output, the certificate issuer instead stores the signature in the attestation transaction TxID Cer The CA may sign the input of the certification transaction. The output may include other unsigned data that would be found in a digital certificate. i See Table 2 for an example of what the

[0094] The unspent transaction output may be used to represent the continuing validity of a certificate. Consuming an output may be interpreted as meaning that the certificate has expired or been revoked. In the example transaction shown in Table 2, the output at index 0 is i If a CA were to consume this output, the certificate would no longer be considered valid.

[0095] [Table 2]

[0096] 4. Example Blockchain System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (often referred to as "miners") that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be organized as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0097] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0098] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, with a transaction in this context referring to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout.

[0099] Blockchain nodes 104 may be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Blockchain nodes 104 may be configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Blockchain nodes 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0100] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output or allocating an output to one or more outputs in another forward transaction. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even transmitted to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" in this specification refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or transmission in a temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0101] Due to the resources involved in transaction validation and publishing, at least each of the blockchain nodes 104 typically takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0102] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action identified herein as being in a blockchain node 104 may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0103] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node may specialize in a particular operation. For example, a node 104 may focus on transaction validation and transaction propagation, or on block mining. In some examples, a blockchain node 104 may perform two or more of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0104] Also connected to the network 101 are computing devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0105] Some or all of the parties 103 may be connected as part of a different network, for example, a network layered on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and his / her respective computer device 102a, and a second party 103b and his / her respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0106] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any action identified herein as belonging to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 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 computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0107] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0108] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to enable each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that it currently owns. In an output-based system, this second functionality comprises matching the amounts specified in the outputs of the various transactions 152 belonging to that party and scattered throughout the blockchain 150.

[0109] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may alternatively be implemented as a set of two or more separate applications, for example, interfacing via an API or one plugging into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be appreciated that this is not limiting.

[0110] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which its respective party 103 is a recipient (or, in embodiments, can certainly inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that grants credibility in transactions, in part, through its public visibility). The wallet function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 to propagate them throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another, and a given transaction protocol is used with a given node protocol that together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0111] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance, rather than by referencing back to the UTXO of a preceding transaction in a sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction balance (also called a "position" or "nonce"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field within a transaction may also be signed. This data field may point back to a previous transaction, for example, if the data field contains a previous transaction ID.

[0112] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as described above, the data fields of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction, which references the output point of the previous transaction. Thus, both models allow for linking between transactions. As another example, an account-based transaction includes a "recipient" field (in which the receiving address of the account is specified) and a "value" field (in which the amount of a digital asset may be specified). Together, the recipient field and value field are equivalent to the output of an output-based transaction, which can be used to assign the amount of a digital asset to a blockchain address. Similarly, account-based transactions have a "signature" field that contains a signature for the transaction. The signature is generated using the sender's private key and verifies that the sender has authorized this transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes a signature for the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., send or "release" digital assets to a recipient address) in response to one or more inputs (provided by a transaction) that meet one or more conditions specified by the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some examples, a smart contract may be considered equivalent to a locking script for an output-based transaction that can be triggered by a subsequent transaction, checking whether one or more conditions specified by the locking script are met by the inputs of the subsequent transaction.

[0113] 5. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based protocol or a "UTXO"-based protocol. However, this is not limiting for all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0114] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0115] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. In FIG. 2, the preceding transaction 152i is labeled "Tx0." Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 150, nor that Tx1 is the immediately adjacent transaction in the pool 154. Tx1 can point back to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0116] The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence, as defined by transaction pointers specified within the transactions (e.g., which transactions point back to which other transactions). They may be equivalently interchanged with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent,” and “child,” etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or node behavior.

[0117] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO 0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid, and therefore for the UTXO to be successfully redeemed.

[0118] A locking script (also called scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume a transaction output 203, for example, Alice's signature requirements. A locking script appears in the output of a transaction. An unlocking script (also called scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0119] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 comprises a pointer that points back to Tx1 (e.g., by its transaction ID, i.e., TxID0, which in an embodiment is a hash of the overall transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0, to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). <Sig P AThe data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a locking script, or by a node protocol, or a combination of these.

[0120] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions specified in the locking script (where the conditions may comprise one or more criteria).

[0121] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0122] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0123] A locking script may be referred to as a "scriptPubKey," since it typically includes the public key of the party to which the respective transaction is locked. An unlocking script may be referred to as a "scriptSig," since it typically provides the corresponding signature. However, more generally, not all applications of blockchain 150 require that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0124] 6. Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 120b, respectively, may include additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the prompting of either party or a third party). Side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as “off-chain” communication. For example, this may be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner may be referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0125] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a variety of networks, such as a local area network, such as a mobile cellular network or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications media, for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange some information or data, etc., over the side channel 107, this does not necessarily imply that all of this data must be transmitted over exactly the same links, or even the same type of network.

[0126] 7. Further Observations Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments.

[0127] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of the blockchain 150, and that the above description may apply generally to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0128] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the suitable Bitcoin network 106).

[0129] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0130] Also more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0131] Some embodiments are described with respect to a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The chosen node is often called a validator. Blockchain nodes can lock up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks up the largest stake for the longest period of time has the best chance of becoming the next validator.

[0132] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0133] Statement 1. A computer-implemented method for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence is defined to be the most secure level, and a final security level in the sequence is defined to be the least secure level, the respective security of each security level in the sequence being defined to decrease from the first security level to the final security level, each respective node having a respective security certificate associated with each security level, and each node configured to communicate with other nodes according to a communication protocol, the communication protocol following at least the following rules: i) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any less secure security level in the sequence; ii) each node having a respective certificate associated with a respective security level can send messages to each node having a respective certificate associated with the next more secure security level adjacent to the respective security level in the sequence, but cannot send to each node having a respective certificate associated with a respective security level that is more secure than the next more secure security level adjacent to the respective security level in the sequence; iii) each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with a less secure security level adjacent to the respective security level in the sequence, but not from each node having a respective certificate associated with a less secure security level than the less secure security level adjacent to the respective security level in the sequence; and iv) providing that each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with any more secure security level in the sequence; The method is performed by a first node having a first certificate communicating with a second node having a second certificate according to a communication protocol.

[0134] Statement 2. The method of statement 1, wherein the communication protocol specifies that the message is transmitted in encrypted form.

[0135] Statement 3. The method of statement 2, wherein the communication protocol specifies that messages sent between respective nodes having respective security certificates associated with adjacent security levels in the sequence are encrypted using an encryption key based on the public key of the receiving node and the private key of the sending node.

[0136] Statement 4. The method of statement 3, wherein the communication protocol includes the following steps for messages to be transmitted between respective nodes having respective security certificates associated with adjacent security levels in the sequence: a sending node sending a communication request to a receiving node, the communication request including or a reference to the sending node's respective security certificate; the receiving node verifying the security certificate of each of the sending nodes; the receiving node sending a verification message to the sending node; the sending node sending a verification signature to the receiving node, the verification signature being based on the verification message and a private key corresponding to the sending node's public key; and It specifies that the receiving node should verify the verification signature.

[0137] Statement 5. The method of any statement dependent on statement 2, wherein the communication protocol specifies that messages sent between respective nodes having respective security certificates associated with non-adjacent security levels in the sequence are encrypted using an encryption key based on the public key of the receiving node.

[0138] Statement 6. The method of statement 5, wherein the communication protocol is such that messages are transmitted between respective nodes having respective security certificates associated with non-adjacent security levels in a sequence such that a receiving node has a respective security level associated with a more secure level than a sending node, and the method comprises the steps of: It specifies that what should be done is for the sending node to send a message to each node having a security certificate associated with the next more secure security level adjacent to the respective security level in the sequence, and for each node to request that the message be forwarded to the receiving node.

[0139] Statement 7. The method of any preceding statement, wherein each certification authority in the set of certification authorities is associated with a respective security level, and each security certificate associated with each security level is signed by a respective certification authority associated with the respective security level.

[0140] Statement 8. The method of statement 7, wherein each node is configured to communicate with the certificate authority according to a communication protocol, the communication protocol following at least the following rules: v) each node having a respective security certificate associated with a respective security level can send messages to and receive messages from a respective certificate authority associated with the same respective security level or an adjacent security level in the sequence; vi) providing that each node having a respective security certificate associated with a respective security level can obtain a respective security certificate associated with the next more secure security level in the sequence from a respective certificate authority associated with the next more secure security level.

[0141] Statement 9. The method of any of the preceding statements, wherein part or all of each security certificate, or its respective hash, is stored on the blockchain.

[0142] Statement 10. The method of any preceding statement, wherein each security certificate comprises a respective identifier of each node and / or a respective public key of each node.

[0143] Statement 11. A computer-implemented method for issuing security certificates for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence being defined as being the most secure level and a final security level in the sequence being defined as being the least secure level, wherein the respective security of each security level in the sequence is defined as decreasing from the first security level to the final security level, each respective node having a respective security certificate associated with a respective security level, each certification authority in a set of certification authorities being associated with a respective security level, each security certificate associated with each security level being signed by a respective certification authority associated with each security level, and each certification authority being configured to issue security certificates according to a certificate issuance protocol, wherein the certificate issuance protocol follows at least the following rules: i) Certification authorities associated with each security level can issue security certificates associated with the same respective security level; ii) a certificate authority associated with each security level can issue security certificates to nodes having security certificates with less secure security levels adjacent to the respective security level in the sequence, but cannot issue security certificates to nodes having security certificates with security levels less secure than nodes having security certificates with less secure security levels adjacent to the respective security level in the sequence; and iii) providing that a certification authority associated with each security level may reissue security certificates to nodes that have expired or revoked certificates associated with the same respective security level; The method is performed by a first certificate authority and comprises issuing a security certificate to a requesting node according to a certificate issuing protocol.

[0144] Statement 12. The method of statement 11, wherein issuing a security certificate to a requesting node comprises: receiving a request from a requesting node having a respective security certificate associated with a respective security level; determining that each security certificate associated with the next more secure security level adjacent to each security level in the sequence may be issued to the requesting node; generating respective security certificates associated with the next more secure security levels; and transmitting the respective security certificate or a reference thereto to the requesting node.

[0145] Statement 13. The method of statement 12, The method includes submitting a blockchain transaction to a blockchain network, the blockchain transaction comprising a respective security certificate or a hash thereof and a signature associated with a first certificate authority.

[0146] Statement 14. The method of any statement subject to statement 11, wherein each certification authority is configured to communicate with other certification authorities according to a communication protocol, the communication protocol complying with at least the following rules: i) the certificate authority associated with each security level can communicate with each certificate authority having a respective security certificate associated with an adjacent security level in the sequence; and ii) providing that a certificate authority associated with each security level can communicate with each certificate authority having a respective security certificate associated with the same respective security level;

[0147] Statement 15. A computer device, a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 14.

[0148] Statement 16. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1-14 when executed on one or more processors.

[0149] According to another aspect disclosed herein, there may be provided a method comprising actions of a first node and a first certification authority. According to another aspect disclosed herein, there may be provided a system comprising computer devices of a first node and a first certification authority.

[0150] According to another aspect disclosed herein, a method may be provided comprising an action of a set of nodes. According to another aspect disclosed herein, a system may be provided comprising a computer device of a set of nodes.

[0151] According to another aspect disclosed herein, a method may be provided that comprises actions of a set of certification authorities. According to another aspect disclosed herein, a system may be provided that comprises computer devices of a set of certification authorities. [Explanation of symbols]

[0152] 100 systems 101 Packet Switched Network 102 Computer Equipment 103 Parties, Users, and Agents 103a First Party, Alice 103b Second Party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client Applications 106 Peer-to-peer (P2P) network, decentralized network, blockchain network, Bitcoin network 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 blocks 152 transactions 154 Ordered Sets, Ordered Pools 201 Header 202 Input 203 Output 300 System 301 Node 302 Security Layers, Security Levels, and Security Zones 303 Certification Authority

Claims

1. 1. A computer-implemented method for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence being defined as being the most secure level and a final security level in the sequence being defined as being the least secure level, wherein respective security levels in the sequence are defined as decreasing from the first security level to the final security level, each respective node having a respective security certificate associated with a respective security level, and each node being configured to communicate with other nodes according to a communication protocol, wherein the communication protocol adheres to at least the following rules: i) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any less secure security level in the sequence; ii) each node having a respective certificate associated with a respective security level can send a message to each node having a respective certificate associated with any one, but not all, of one or more of the next more secure security levels in the sequence; iii) each node having a respective certificate associated with a respective security level is capable of receiving messages from each node having a respective certificate associated with any one or more, but not all, of the less secure security levels in the sequence; and iv) each node having a respective certificate associated with a respective security level can receive messages from each node having a respective certificate associated with any more secure security level in the sequence; the method being performed by a first node having a first certificate communicating with a second node having a second certificate according to the communication protocol; Computer-implemented methods.

2. The method of claim 1 , wherein the communication protocol specifies that messages are transmitted in encrypted form.

3. 3. The method of claim 2, wherein the communication protocol specifies that messages sent between respective nodes having respective security certificates associated with adjacent security levels in the sequence are encrypted using an encryption key based on the public key of the receiving node and the private key of the sending node.

4. The communication protocol comprises the following steps for messages to be transmitted between respective nodes having respective security certificates associated with adjacent security levels in the sequence: the sending node sending a communication request to the receiving node, the communication request including or a reference to the respective security certificate of the sending node; the receiving node verifying the respective security certificates of the sending nodes; the receiving node sending a verification message to the sending node; the sending node sending a verification signature to the receiving node, the verification signature being based on the verification message and a private key corresponding to the public key of the sending node; and the receiving node verifying the verification signature; shall be carried out, The method of claim 3.

5. 3. The method of claim 2 or any one of its dependent claims, wherein the communication protocol specifies that messages sent between respective nodes having respective security certificates associated with non-adjacent security levels in the sequence are encrypted using an encryption key based on the public key of the receiving node.

6. The communication protocol is configured such that messages are transmitted between respective nodes having respective security certificates associated with non-adjacent security levels in the sequence, the receiving node having respective security levels associated with a more secure level than the sending node, and the communication protocol comprises the following steps: the sending node transmitting a message to each node having a security certificate associated with a next more secure security level adjacent to the respective security level in the sequence, and requesting that the respective node forward the message to the receiving node. shall be carried out, The method of claim 5.

7. 7. The method of claim 1, wherein each certificate authority in the set of certificate authorities is associated with a respective security level, and each security certificate associated with a respective security level is signed by a respective certificate authority associated with the respective security level.

8. Each node is configured to communicate with the certification authority according to said communication protocol, said communication protocol having at least the following rules: v) each node having a respective security certificate associated with a respective security level can send messages to and receive messages from a respective certificate authority associated with the same respective security level or an adjacent security level in said sequence; vi) each node having a respective security certificate associated with a respective security level can obtain a respective security certificate associated with the next more secure security level in the sequence from a respective certificate authority associated with the next more secure security level; stipulates, The method of claim 7.

9. 9. The method of claim 1, wherein some or all of the respective security certificates, or their respective hashes, are stored on a blockchain.

10. 10. The method of claim 1, wherein the respective security certificate comprises a respective identifier of the respective node and / or a respective public key of the respective node.

11. 11. The method of claim 1, wherein, for rule ii) of the communications protocol, one or more but not all of the next more secure security levels consist of the next more secure security levels adjacent to the respective security level in the sequence.

12. 11. The method of claim 1, wherein for rule ii) of the communications protocol, one or more but not all of the next more secure security levels comprise one or more security levels within a threshold number of levels from the respective security level in the sequence.

13. The threshold value is the total number of levels in said sequence; security settings defined and / or configured by a user of one or more of said respective nodes; a formula based on said sequence of one or more characteristics and / or security levels of said set of nodes; based on one or more of The method of claim 12.

14. Said communication protocol shall adhere to at least the following rules: vii) each respective security level is associated with a respective most secure security level at which a node having a certificate associated with that respective security level can communicate, and for each adjacent security level, the respective most secure security level associated with a less secure adjacent security level is less secure than the respective most secure security level associated with a more secure security level; stipulates, 14. The method according to any one of claims 1 to 13.

15. 1. A computer-implemented method for issuing security certificates for secure communication between a set of nodes, wherein a sequence of security levels is defined, a first security level in the sequence being defined as being the most secure level and a final security level in the sequence being defined as being the least secure level, wherein respective security levels in the sequence are defined as decreasing from the first security level to the final security level, each respective node having a respective security certificate associated with a respective security level, each certification authority in a set of certification authorities being associated with a respective security level, each security certificate associated with each security level being signed by a respective certification authority associated with the respective security level, and each certification authority being configured to issue security certificates according to a certificate issuance protocol, wherein the certificate issuance protocol follows at least the following rules: i) Certification authorities associated with each security level can issue security certificates associated with the same respective security level; ii) a certificate authority associated with each security level can issue security certificates to nodes that have security certificates with one or more, but not all, of the less secure security levels in the sequence; and iii) providing that a certification authority associated with each security level may reissue security certificates to nodes that have expired or revoked certificates associated with said same respective security level; the method comprising, performed by a first certificate authority, issuing a security certificate to a requesting node in accordance with the certificate issuance protocol; Computer-implemented methods.

16. issuing a security certificate to the requesting node, receiving a request from the requesting node having a respective security certificate associated with a respective security level; determining that a respective security certificate associated with a next more secure security level may be issued to the requesting node; generating a respective security certificate associated with said next more secure security level; and transmitting the respective security certificate or a reference thereto to the requesting node.

16. The method of claim 15.

17. submitting a blockchain transaction to a blockchain network, the blockchain transaction comprising the respective security certificate or a hash thereof and a signature associated with the first certificate authority; 17. The method of claim 16.

18. Each certification authority is configured to communicate with other certification authorities according to a communication protocol, said communication protocol having at least the following rules: i) a certificate authority associated with each security level can communicate with a respective certificate authority having a respective security certificate associated with any one of one or more, but not all, of the more or less secure security levels in said sequence; and ii) providing that a certificate authority associated with each security level can communicate with each certificate authority having a respective security certificate associated with said same respective security level; 16. A method according to claim 15 or any one of its dependent claims.

19. 19. The method of claim 15, wherein, with respect to rule ii) of the certificate issuance protocol, the one or more, but not all, of the next less secure security levels consists of the less secure security levels adjacent to the respective security level in the sequence.

20. 19. The method of claim 15, wherein, with respect to rule ii) of the certificate issuance protocol, one or more but not all of the next less secure security levels comprise one or more security levels within a threshold number of levels from the respective security level in the sequence.

21. 19. The method of claim 18 or any one of its dependent claims, wherein, with respect to rule ii) of the communications protocol, one or more but not all of the next more secure security levels consist of the next more secure security levels adjacent to the respective security level in the sequence.

22. 19. The method of claim 18 or any one of its dependent claims, wherein, with respect to rule ii) of the communications protocol, one or more but not all of the next more secure security levels comprise one or more security levels within a threshold number of levels from the respective security level in the sequence.

23. The threshold value is the total number of levels in said sequence; security settings defined and / or configured by a user of one or more of said respective nodes; a formula based on said sequence of one or more characteristics and / or security levels of said set of nodes; based on one or more of 23. The method of claim 20 or 22.

24. a memory comprising one or more memory units; a processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 23. Computer equipment.

25. 24. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 23 when executed on one or more processors.

Images